Last week, I was looking at a customer's avionics software
architecture to determine whether it might be possible to migrate this
to an ARINC 653-based Integrated Modular Avionics (IMA) environment.
This raised some interesting questions in terms of performance and scalability.
If you consider the implementation of an avionics system using an ARINC
653 software architecture, the RTOS enforces temporal partitioning of
the safety critical applications running in the individual partitions
through the use of ARINC 653 time slot scheduling. (ARINC 653 defines
a schedule consisting of major frame comprised of a sequence of minor frames
which specify the execution time of an individual partition for a fixed
duration; at the end of the major frame the schedule repeats). However,
the ARINC 653 scheduling implementation needs to be deterministic, i.e.
the next partition should start execution at the exact time predefined
in the ARINC 653 schedule, or very close to it. The delta between the
defined time and the actual time is known as partition jitter.
So, what approaches can be used to minimize partition jitter?
Let's
consider the ARINC 653 architecture - it actually performs two types of
scheduling: (1) time slot scheduling of the partitions; and (2)
priority-based preemptive scheduling within the partitions. Let's
assume that the RTOS is running in the processor's privileged
supervisor mode, and the applications are running in the processor's
user mode and in different memory contexts (in order to provide spatial
partitioning - another key requirement of Integrated Modular Avionics).
Now, if the time slot scheduler and the priority preemptive scheduler are both
implemented in the RTOS kernel, this could create a significant
overhead for the RTOS kernel in handling a significant number of system
calls associated with each processes context switch within a partition.
This could lead to performance degradation as the number of
partitions in the system increases (as the ratio of the total number of
processes and partitions divided by the major frame duration is likely
to increase also).
However, an alternative approach would be to only implement the time
slot scheduler in the RTOS kernel, and implement the priority
preemptive scheduler within the partition in user mode. The advantage
of this approach is that the priority preemptive scheduler can perform
schedule application processes in user mode without having to perform a
system call into the RTOS kernel and the associated overhead of
user/supervisor context switch. This approach not only helps to
minimize partition jitter, but also make the architecture very
scalable, which is why it is used in VxWorks 653. (I mentioned this
scalability in an earlier blog, where VxWorks 653 was running with sixty-five ARINC 653 partitions at Avionics 2007 Show in Amsterdam).
Of course, it's also important to be able to detect at runtime
whether partition jitter ever exceeds a predefined threshold, and
VxWorks 653 implements this through the Temporal Violation Detection mechanism, which would raise an alarm to the Health Monitoring System.
By the way, the phrase Temporal Violation Detection sounds more like a concept from Einstein's Special Theory of Relativity (wikipedia) than software engineering, but I don't think we're going to have to consider the impact of Time Dilation (wikipedia) in ARINC 653 systems just yet, as we're still a long way from traveling close to the speed of light...
Recent Comments