[p_l]

Replaceable, modular designs, space for modifications, etc.

Also some sensors are pretty big (laser gyroscopes, for example which are part of ADIRU - air & intertial reference system.

Then you have the central computer clusters which might be separated physically (several computers running in a setup somewhat similar to statically assigned kubernetes) which run all kinds of software from lights management through navigation to brake control.

You also have a bunch of non-computer parts like power distribution units and such, which in a DC might be hidden elsewhere and you wouldn't notice it if you just looked at typical colocation cage.

[catern]

>(several computers running in a setup somewhat similar to statically assigned kubernetes)

This description of a server room makes me feel old.

[p_l]

Well, which explanation would you prefer then? JES3, which is the closest extant example of such tech?

I'm comparing it to statically assigned k8s not because it's manually assigned applications, but because it's a cluster system where the equivalent of k8s scheduler was run offline to resolve various performance and deadline constraints, both between specific application threads on the cluster, and between devices on the AFDX (modified ethernet) network that are managed from said cluster.

Comparing ARINC-653 partitions to k8s pods and the overall setup of typical IMA cluster with k8s makes for simplest way, IMO, to describe the setup to people who have some experience with servers and cloud, but none with aviation embedded :)

[catern]

>because it's a cluster system where the equivalent of k8s scheduler was run offline to resolve various performance and deadline constraints, both between specific application threads on the cluster, and between devices on the AFDX (modified ethernet) network that are managed from said cluster.

Oh, I genuinely didn't know that! I assumed you were just talking about something that had been manually hand-optimized by syadmins/developers, like a traditional Unix server room.

Can you share any more information about these static cluster schedulers? It indeed makes perfect conceptual sense to me with your explanation, I just had never heard of this being actually used!

[p_l]

The degree of automation varies - I'm not in avionics industry so I can't give exact data. However if you read through things like AFDX standard (what's published of it) and ARINC-653 and the like, there's enough to get the gist of it.

For example, AFDX ensures no congestion by statically assigned timeslots, effectively using Ethernet in a sort-of TDMA setup, coupled by special switches that effectively implement virtual circuits based on, again precomputed, mapping loaded into them (at least the standard implies there's no MAC-learning supposed to happen). This allows you to develop and do basic test with any random Ethernet switch before needing a proper AFDX one for more thorough testing, as the application-level protocol is essentially UDP over IP. However you need to consider a whole AFDX network segment when assigning the timeslots and virtual channels, and that's where tools come in :)