Real-time Operating Systems - 2 Technology and Architectures

2 Technology and Architectures

2.5 Real-time Operating Systems

As for a home computer or laptop, the operating system (OS) of an avionics system and its major subsystems is key to correct operation and achievement of performance goals. The OS needs to be reliable and robust, not prone to malfunctions or crashes. On an aircraft there are many functions that may be flight critical or mission critical, and therefore the software must be reliable and safe. Furthermore, the aircraft systems perform their functions in real time, and therefore the operational programs depend upon a real-time operating system (RTOS) to provide the means for them to execute their programs.

For many years individual companies developed their own operating systems which were used in their own products, often associated directly with a particular processor or computer application. Such dedicated or proprietary systems are still being developed today, but increasingly designers are seeking commercial solutions that are created, maintained and supported by technology specialists. This releases high-grade software resources to work on more specific application software that executes the aircraft or weapons systems functions.

An RTOS will be smaller, more modular and more focused in application than the commercial OS used on laptops and PCs. In particular, for high-integrity real-time applications the RTOS should be kept as compact as possible, featuring only essential functions. It also needs to provide a guaranteed level of service, always responding within specified time constraints.

2.5.1 Key Attributes

The key attributes expected of a COTS RTOS are:

1. Versatility. The RTOS must be applicable to multiple systems such that a minimum number of RTOSs are required across the aircraft.

Figure 2.24 Eight-port StarFabric switched fabric module.

2. Safety. The system must be capable of being partitioned such that software integrity and therefore aircraft safety are maintained.

3. Security. The RTOS must be capable of separating multiple levels of classified and sensitive data.

4. Supportability. The OS must be maintained and enhanced throughout its operational life.

2.5.2 Safety

The software developed for high-integrity or safety-critical systems used in aerospace applications is subject to intense scrutiny. All processes associated with developing the software are clearly identified, and extensive plans and documentation are produced to ensure that the correct validation and verification processes are undertaken. Within the civil aerospace community, the specification is issued by the Radio Technical Commission for Aerospace (RTCA). This body has issued DO-178B, entitled ‘Software considerations in airborne systems and equipment certification’, which was developed by the avionics industry to establish software considerations for developers, installers and users when aircraft equipment design is implemented using microcomputer techniques. DO-178B is recognised

‘as an acceptable means to secure FAA approval of digital computer software’, RTCA DO-178B. In Europe an equivalent specification is issued by the European Organisation for Civil Aviation Equipment (EUROCAE) under EUROCAE ED-12B. A joint RTCA/EURO-CAE committee is expected to commence work on a third revision standard, DO-178C.

DO-178B acknowledges that not all computer failures or software malfunctions affect an aircraft to the same degree. A malfunction in the aircraft flight control system is clearly more hazardous than the failure of a reading light. Accordingly, software is divided into five different categories, level A through to E, where level A represents the highest level of approval and level E the lowest.

During the initial aircraft design, all those failures that can cause the various levels of failure severity are identified and used to modify the aircraft systems design accordingly.

Therefore, long before an aircraft is built, all these conditions are identified and appropriate design steps taken and quality of design assured. This process helps to define the system architecture, the number of control and power channels, the level of redun-dancy, etc. It also specifies a design assurance level according to what the effects of a failure might be; these design assurance levels are reflected in the RTOS software certification levels (Table 2.2).

There are five main categories of failure severity. The most serious is a catastrophic failure which would result in the loss of the aircraft and passengers. The probability of such an event occurring is specified as extremely improbable, and in analytical or qualitative terms it is directed that a catastrophic failure should occur less than 1 10⁹ per flight hour. That is less than once per 1000 million flying hours. Other less significant failures are ‘hazardous’,

‘major’, ‘minor’ and ‘no-effect’; in each case the level of risk is reduced and the probability of the event occurring is correspondingly increased. Therefore, a minor failure – perhaps the failure of a reading light – can be expected to be reasonably probable, with the event occurring less than 1 10³ per flight hour or less than once every 1000 flying hours. A brief summary of the applicable failure severities is shown in Table 2.3.

DO-178B is not mandated for military aircraft use, indeed its use is not mandated within the civil community. However, as it is a recognised method of successfully achieving

REAL-TIME OPERATING SYSTEMS 79

certification, the industry effectively uses it as a de facto requirement. There are several reasons why the military avionics community should adopt the standard:

1. It should do so where dual-use software exists, for example flight management system (FMS) software developed for a civil application and adopted for a military program.

2. The adoption of ‘commercial best practices’ is encouraged, and the fact that DO-178B is the accepted best practice in the civil community offers some reassurance.

3. There is a need to adopt DO-178B in areas where military aircraft have to operate in situations governed by the civil regulations. FMS software designed to satisfy global air transport management (GATM) requirements will also be subject to communications, navigation, surveillance/air transport management (CNS/ATM) regulations imposed by the civil authorities.

4. The standard should be adopted to provide robust software products capable of future reuse.

2.5.3 Software Partitioning

In recent years there has been a tendency for software to be co-hosted on shared processor assets, and this has been given added impetus by integrated modular avionics architectures.

Table 2.2 RTOS software certification levels Software

certification level Definition

A Software whose anomalous behaviour would cause or contribute to a failure of a system function resulting in a catastrophic failure condition for the aircraft

B Software whose anomalous behaviour would cause or contribute to a failure of a system function resulting in a hazardous failure condition for the aircraft

C Software whose anomalous behaviour would cause or contribute to a failure of a system function resulting in a major failure condition for the aircraft

D Software whose anomalous behaviour would cause or contribute to a failure of a system function resulting in a minor failure condition for the aircraft

E Software whose anomalous behaviour would cause or contribute to a failure of a system function resulting in a no-effect failure condition for the aircraft

Table 2.3 Summary of the applicable failure severities

Failure severity Probability Analytical

Catastrophic Extremely improbable Less than 1 10⁹ per flight hour Hazardous Extremely remote Less than 1 10⁷ per flight hour Major Remote Less than 1 10⁵ per flight hour Minor Reasonably improbable Less than 1 10³ per flight hour

In federated architectures of the type already described earlier in this chapter there is little opportunity to rationalise processor usage in this way.

However, systems integrators have over the past 10 years embraced the modular concept and have confronted the new software issues that result. Multitasking of processors requires software partitioning such that the software applications cannot interfere with each other. In particular, there is a pressing need to ensure that high-integrity applications cannot be adversely affected by lower integrity functions co-hosted on the same processor.

ARINC 653 is an industry specification – again originating from the civil community – that defines partitioning of software and addresses these issues. Software partitioning is an important issue in its own right, but this methodology has helped to address other important issues that have proved very difficult to overcome in the past, including the obsolescence of hardware. This has always been a problem but has been greatly accentuated by the adoption of COTS technology with its rapid hardware development cycles and consequent early obsolescence.

The philosophy adopted is typified by the tiered approach illustrated in Figure 2.25. These tiers or layers provide the following:

1. At the top level, an ARINC 653 compliant software infrastructure or application program-ming interface (API) provides the partitioning of weapons systems functions that may have been developed in a previous program (legacy software) or may be new software developed specifically for the platform. These will generally, but not exclusively, be military-specific applications (the dual use of software has already been discussed).

2. The API infrastructure interfaces with the RTOS which will generally be a commercial package. In many cases the RTOS will be DO-178B compliant.

3. A board-level (i.e. sub-LRU-level) support package will provide the necessary software support to enable the COTS hardware to interface with the commercial RTOS and API layers.

4. The hardware layer based upon COTS technology will be the most dynamic and rapidly varying component of this implementation as the rapid evolution of processor and FO/FC network technology continues. The fact that the most rapidly varying hardware content is decoupled from the application software means that hardware obsolescence can be contained and technology advances enjoyed while the investment in software applications and system functionality is protected.

HARDWARE (PROCESSOR, MEMORY, I/O) BOARD SUPPORT PACKAGE

OPERATING SYSTEM INFRASTRUCTURE - API APPLICATIONS

Figure 2.25 Software and hardware integration.

REAL-TIME OPERATING SYSTEMS 81

Recent applications of partitioned and certifiable RTOS have included:

Green Hills software with level A, INTEGRITY-178B RTOS on the Sikorsky S-92 helicopter avionics management system (AMS);

Lynux Works Lynx-OS level operating system in association with Rockwell Collins on the adaptive flight display system on the Bombardier Challenger 300 business jet;

Wind River systems with AE653 on the Boeing 767 tanker transport and C-130 avionics modification program (AMP);

CsLEOS RTOS developed by BAE SYSTEMS and certified to DO-178B level A for a fly-by-wire flight control system upgrade to the Sikorsky S-92 helicopter.

2.5.4 Software Languages

An added complication to the portability of software application packages relates to the software language used. At an early stage in the use of digital technology it was recognised that the software burden in terms of initial programming effort and lifetime support was in many ways more difficult to quantify and manage than the development of the aerospace-specific hardware. By the mid-1970s the US services were in crisis owing to the vast proliferation in software languages: reportedly in 1976 there were more than 450, some as dialects of standard languages but generally all of which were low in interoperability and reliability and high in maintenance costs. This led to the development of Ada as a high-order language.

By the late 1970s/early 1980s the US services and others specified Ada as the preferred language, and Ada 83 was later upgraded to Ada 95 with additional features and capability.

As the number of compilers available, available expertise and development tools increased, Ada became the language of preference in the late 1980s and early 1990s, representing a large investment for the Pentagon and their supplier base.

During the 1990s the armed services withdrew their support for Ada, and new languages such as C and Cþþ were permitted. There have been and are on-going technical and business debates of great intensity about the merits and demerits of Ada versus these commercial languages. It is not the place of this publication to pass judgement on either approach. However, from the avionics systems designer’s viewpoint, the issue is how to integrate legacy software packages that might largely be written in Ada. In extreme cases, software may need to be recoded in order to be compatible with the new environment. The benefits accruing from the adoption of COTS in terms of increased performance and longevity therefore have to weighed against these issues.

2.5.5 Security

As well as the need to partition software functions for reasons of integrity, a more recent requirement is the need to partition for reasons of security. The US authorities now want the RTOS in some applications to be able to operate at multiple levels while maintaining security between them. The evolution of network-centric warfare doctrines means that the same pro-cessor that is handling flight management functions in the civil air traffic domain may also have to handle highly classified target data, weapons engagement profiles, rules of engagement, etc.

The rules for protecting sensitive data have evolved over the past three decades but originally resides in a publication issued in the United States in 1983 and known as the

‘orange book’. More recently, an international IT security project called ‘Common Criteria’

has replaced the original publication. ‘Common Criteria’ specifies seven evaluation assur-ance levels (EALs) that correspond to earlier classifications. The highest level, EAL-7, requires the system to be multilevel secure, and is able to separate three or more levels of data while processing them on shared hardware.

Usually, the necessary assurance levels are achieved using a combination of hardware [perhaps using the memory management unit (MMU) of the processor] and software means by using the core of the RTOS or ‘microkernel’. This concept, referred to as multiple independent levels of security (MILS), permits different levels of classified data to be accommodated. The MILS approach is under active consideration for a number of programs including C-130 AMP, F-22, F-35, the global positioning system (GPS) and the joint tactical radio system (JTRS). MILS can co-exist with ARINC 653/DO-178B implementations, as shown in Figure 2.26.

2.6 RF Integration

Earlier in this chapter the integration of aircraft at the top level using FC networks was examined. Another area where the aircraft can benefit from integration is in the area of the radio-frequency (RF) subsystems. Modern fighters are fitted with a plethora of RF systems, some of which are listed below:

Radar;

Electronic warfare (EW);

Identification friend or foe (IFF);

Radar warning in several RF bands;

Navigation aids: TACAN, ILS, MLS, GPS;

Communications: VHF, UHF, HF SatCom joint tactical information distribution system (JTIDS), Link 11; secure radio.

These systems each have their own antenna, RF sections, signal and data processing: the result is a vast collection of non-standard, heavy and sometimes unreliable hardware modules.

HARDWARE (PROCESSOR, MEMORY, I/O)

Figure 2.26 Integrity and security partitioning.

RF INTEGRATION 83

It has been recognised for some time that this is an area ripe for rationalisation and functional integration using a common suite of modules. In the past, initiatives such as integrated communications, navigation and identification architecture (ICNIA) and the integrated electronic warfare suite (INEWS) have attempted to address this problem. For whatever reason, these failed to attain the benefits sought, but advances in RF processing technology are now offering the prospect of fuller integration.

2.6.1 Primary Radar Evolution

2.6.1.1 Independent Systems of the 1950s

Integration of the radar, communications and navigation functions has been occurring over the past four decades, albeit at a slow pace. Figure 2.27 shows a 1950s era system with stand-alone radar, communications and navigation functions. By the standards of today the radar was quite rudimentary, with airborne search and tracking modes. Ground-mapping capabilities were incidental and a pulse Doppler facility with a look-down capability was not yet available. This system was analogue in nature and quite similar to the distributed analogue system described earlier. Systems were interconnected using a great deal of dedicated wiring; and computer and displays would be dedicated to the relevant system.

Typical aircraft in this category would be the North American F-86D, Lockheed F-94 Starfire and Northrop F-89 Scorpion.

Radar Comms

Nav

Figure 2.27 First-generation analogue system – 1950s.

2.6.1.2 Integrated Systems of the 1960s and 1970s

The next stage is typical of systems entering service during the 1960s, of which the McDonnell Douglas F/A-4 Phantom is a good example (Figure 2.28). In this system the radar, communications and navigation systems are integrated into a mission system with a display providing mission rather than subsystem data. Although these systems were largely analogue, later variants did introduce some digital subsystems. Most system interconnection was still very much undertaken by hardwiring as data buses were only just becoming mature at this stage. These systems introduced further complexity brought about by additional-functionality pulse Doppler radars and inertial navigation systems (INS) and by systems integration. The addition of other, new, more capable navigation aids and integrated radar warning radar (RWR) suites added a further twist of complexity. This integration had to be achieved without the advantage of mature and reliable data buses to enable a federated system to be constructed. These aircraft were very challenging to maintain, suffering from unreliable equipment, high power consumption, vast amounts of wiring and LRUs that were often buried deep in the aircraft as space was very much at a premium. The wiring-intensive nature of the system meant that modifications were always difficult and very expensive to embody. Nevertheless, in spite of the maintenance penalties, these systems brought a step change in aircraft functional capability.

Radar Comms

Nav

Mission

Figure 2.28 Integrated system – 1960s and 1970s.

RF INTEGRATION 85

During the 1980s the availability of mature and cost-effective data buses such as 1553 eased the integration task and removed much of the interconnecting wiring, leading to the multibus federated system seen in the F-16 Fighting Falcon and F/A-18 Hornet in the United States and in the Eurofighter Typhoon, SAAB Gripen and Dassault Rafale in Europe. The AH-64 Apache was one of the first helicopters to use a multiple 1553 bus network to integrate its weapons system. At this stage the need for standardisation and modularisation of hardware and software were recognised as the initial adoption of digital technology brought with it many teething problems as well as performance improvements.

2.6.1.3 Integrated Modular Architecture of the 1990s

The 1990s federated architecture built upon the lessons learned from the previous generation, and modular implementations were sought (Figure 2.29). The JIAWG architecture adopted a modular approach but ran into component obsolescence problems, as has already been described. However, in this generation of avionics systems, the performance explosion came in the form of additional RF and electrooptic (EO) sensors. By now, radar antennas had evolved from parabolic dishes into flat plates and used limited ‘beam-shaping’ techniques, but the antenna still needed to be mechanically scanned. Digital signal processing had

Radar

Comms

Common Integrated Processors

Figure 2.29 Integrated avionics architecture.

evolved to offer true multimode functionality, i.e. the ability to use the same radar for airborne intercepts, ground mapping and missile guidance, for example. Later radars such as those fitted in the F-15E, A/F-18E/F upgrade and block 60 F-16 upgrade (F-16E/F) included an active electronically scanned array (AESA) in place of the flat plate antenna. This antenna is fixed, and radar beams are shaped and steered entirely electronically, without the need for any moving parts. This also brought increased range performance, and highly reliable multimode radar capable of operating in several modes simultaneously. Common integrated processor cabinets provided a modular computing resource for all the mission functions.

However, as will be seen, the RF content of the avionics system was increasing and the need for true integration of the RF system, sharing receiver, signal processor and transmitter resources, became more pressing. Consequently, technology studies preceding the joint strike fighter (JSF) were conducted to consider the route map for future development. The

In document Military Avionics Systems - (Page 100-116)