[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 :)