Building in RTOS support for safety- & security-critical systemsIn this Product How-To, LynuxWorks’ Will Keegan explain the differences between safety-critical and security-critical applications and how to use the company’s two independent RTOSes – LynxOS-178 and LynxSecure – to meet the demanding requirements of each.
Safety- and security-critical systems are both focused on building technology to protect peoples’ lives. But despite the similar critical nature of the two systems, they are designed to function in very different worlds. With different environmental assumptions, different problem spaces, and different governing legislation, each system has its own unique requirements when it comes to selecting the foundations for the technology, such as platform operating systems.
Safety- and security-critical systems are by no means mutually exclusive, but when building critical systems it is essential to have the right tool for the job. There is no such thing as a one-size-fits-all solution for both realms without sacrificing some aspect of safety or security. Therefore, LynuxWorks offers two independent RTOS products: LynxOS-178 for safety-critical platforms and LynxSecure for security-critical platforms.
LynxOS-178 for Safety-critical Systems
The primary objective for safety-critical systems is to maintain operation. Whether in avionics, medical, automotive, or SCADA systems, the slightest flaw can ripple down to a system failure and loss of life. Any technology integrated into these systems must be highly scrutinized to ensure system reliability is preserved. While robustness is a primary concern, these systems are constantly evolving to increase functionality, reduce footprint, and save operational cost. In order to meet these demands systems become more software intensive and more complex, making robustness difficult to achieve.
In an airplane, for example, multiple functions of different criticality levels are located on the same platform to reduce the cost of maintaining separate platforms. An aircraft’s cabin entertainment function might be hosted on the same operating system as its flight control function. If the cabin entertainment system corrupts the flight control function’s memory, it could lead to a deadly failure condition of the aircraft’s ailerons.
To mitigate this problem and increase system reliability, a new class of operating systems emerged: partitioning real-time operating systems or p-RTOS. P-RTOSes create isolated computing zones or “partitions” for software such that software running in one partition does not impact the behavior or performance of software running in another partition. LynxOS-178 (Figure 1 below) is a partitioning RTOS that allows safety-critical functions of varying degrees to run simultaneously on the same platform without having to worry about functions corrupting underlying platform resources or starving out other timing critical functions. LynxOS-178 achieves this partitioning framework through time, space, and resource partitioning.
Time partitioning allocates a strict budget of CPU time for each partition. Using these CPU budgets, a system timer and interrupt and a schedule, LynxOS-178 operates in a privileged mode to control the order in which a partition executes on the CPU and the amount of CPU time software in each partition is granted. If a function within a partition attempts to overrun its CPU budget, the timer interrupt fires, LynxOS-178 takes control of the CPU, preempts the offending function, and allows functions within the next partition in the schedule to run.
Space partitioning allocates an independent quota of memory (for example, RAM and stack space) to each partition. LynxOS-178 uses the CPU’s Memory Management Unit (MMU) to enforce this partitioning.
Resource partitioning grants each partition is explicit access (read/write, write-only, read-only, and none) to resources (interrupts and I/O devices), and LynxOS-178 enforces these access controls.
Figure 1 - LynxOS-178 Partitioning RTOS
LynxOS-178 is named after the aviation safety-critical software development guidelines, “DO-178B”, authored by the RTCA (Radio Technical Commission for Aeronautics) and accepted by the FAA as the standard for approving all new aviation software. DO-178B defines Design Assurance Levels (DAL) A through E to assign to software components. Software components go through safety assessment process and hazard analysis to determine which level is assigned to the software component. Assigning a higher level (A being the highest) to a software component increases the process rigor required to verify software correctness, which drastically increases cost and program schedule.
Using LynxOS-178’s partitioning platform, software components at varying criticality levels can be broken apart and placed into isolated partitions which increases system reliability, simplifies the system architecture, and ultimately reduces the cost of system development and certification.
Page 1 of 2Next >