A Technical History of the SEI

in those developments. The SEI was, however, instrumental in making many of the early adopters
successful and in providing balanced, unbiased guidance to those faced with the language decision.
The SEI Provided an Engineering Basis for Real-Time Systems
Development
A major factor in developing real-time software for any language, including assembly language,
was the development of the real-time scheduler. There simply was no analytic technique available
to ensure that all deadlines could be met. Consequently, practicing engineers relied on experience
and gross calculations. When two professors at Carnegie Mellon University (CMU) proved that
constraints of an obscure scheduling theory could be relaxed, they approached the SEI for help in
making that new theoretic result practical for software. The SEI responded by launching the rate
monotonic analysis (RMA) effort. One of the faculty joined the SEI full time and was joined by
experienced engineers in the SEI who had Ada and real-time experience. Together they applied
the theory, helped develop further modifications, and demonstrated that a previously poorly understood
concept of priority inversion could be analytically predicted and prevented. Rate monotonic
analysis was quickly transitioned to enable defense industry software engineers to build realtime
schedulers that avoid priority inversion and meet all required schedule constraints [Sha
1984]. RMA was applied in the Navy’s BSY-1 (Submarine Special Surveillance and Control)
Trainer, and the Air Force’s F-22. RMA has become state of the practice in developing real-time
systems. RMA influenced several standards, including Futurebus, POSIX, real-time CORBA, the
Ada language, and the Navy Next Generation Computer Resources (NGCR), and is credited with
helping NASA restart the Mars Pathfinder in 1998 after a system shutdown. The transition was so
successful that it became the model for effective technology transition at the SEI [Fowler 1993,
1995].
Another complication for DoD real-time embedded systems is that they often have a safety-critical
component that must interact with other components. For example, the flight control component
in an autopilot is certified to DO178B Level A (the highest level); however, it needs to accept
guidance commands from a flight guidance system that is only certified to Level C.
Nevertheless, avionics certification requires that Level A software must still function correctly in
spite of the software failures in less critical components [DO-178B 1992, RTCA 1992]. The SEI
developed an architecture template, called the Simplex architecture, that supports overall safety
when a system is composed of both reliable/safe components and less reliable/less safe components
[Sha 2001]. This architecture divides a system into two parts: a complex component that
cannot be fully verified but is needed to provide important services, and a high-assurance control
subsystem that is simple and fully verified. It is designed so that (a) complex components cannot
corrupt or interfere with the execution of the high-assurance system, and (b) the data and/or commands
from the complex component will not be used unless the resulting system state can be
checked in real time that it remains well within the safety and stability envelope. Otherwise, the
safety controllers put the system into safety mode. The Simplex architecture also ensures predictable
and guaranteed timing behaviors in spite of failures of complex components and provides the
ability to restart or replace complex components during operation. Simplex architecture also enables
switching the control to alternative components safely. The prototype software was used to
demonstrate the concept on an F-16 advanced maneuvering control study using Lockheed Mar-
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 21
Distribution Statement A: Approved for Public Release; Distribution is Unlimited