2 Technology and Architectures – Military Avionics Systems

2
Technology and Architectures

2.1 Evolution of Avionics Architectures

The introduction gave examples of how an avionics architecture may be structured and explained that, in the main, aircraft level and equipment level architectures would be addressed within the book.

The application of avionics technology to military aircraft has occurred rapidly as aircraft performance has increased. The availability of reliable turbojet engines gave a huge performance boost to both military and civil operators alike. New and powerful sensors such as multimode radars, electrooptics and other advanced sensors have provided an immense capability to modern military aircraft that enables them better to perform their roles. At the same time, the advances in digital avionics technology in the areas of processing and digital communication – by means of data buses – enabled the new systems to be integrated on a much higher scale.

This chapter addresses some of the developments and technology drivers that have led to many of today’s advanced platforms; in many cases significant barriers have defeated the attainment of the original aims. These may be summarised as:

  • The evolution of avionics architectures from analogue to totally integrated digital implementations (section 2.1).
  • Aerospace-specific data buses – the ‘electronic string’ that binds avionics systems together (section 2.2).
  • A description of the joint industrial avionics working group (JIAWG) architecture; originally conceived as a US triservice standard (section 2.3).
  • An overview of commerical off-the-shelf (COTS) data buses which are providing a new cost-effective means of integration for the latest avionics systems (section 2.4).
  • An overview of the latest developments in software real-time operating systems (RTOS); these developments are leading to increasing portability of software while also providing integrity and security partitioning (section 2.5).
  • The increasing integration of radio-frequency subsystems (section 2.6).
  • The evolution of the Pave Pace/JSF shared aperture radio-frequency architecture (section 2.7).

Figure 2.1 Evolution of avionics architectures.

To utilise these improvements, the aircraft avionics systems rapidly grew in terms of capability and complexity. Technology brought improvements in terms of increased performance, computing power, complexity and reliability, although all at an increase in cost. Other benefits included a decrease in weight, volume, power consumption and wiring (Figure 2.1).

Figure 2.1 portrays how avionics architectures for modern fighter aircraft have evolved from the 1960s to the present day. The key architectural steps during this time have been:

  • Distributed analogue architecture;
  • Distributed digital architecture;
  • Federated digital architecture;
  • Integrated modular architecture; also digital.

The evolution of these different architectures has been shaped in the main by aircraft-level design drivers (Moir and Seabridge, 2004). Their capabilities and performance have been both enabled and constrained by the avionics technology building blocks available at the time. As shown in Figure 2.1, there have been changes in many characteristics throughout the period.

Prior to the 1960s, military aircraft had been manufactured in a similar way to their World War II (WWII) forebears. Avionics units were analogue in nature and interconnected via a considerable quantity of aircraft wiring. Key advances were enabled by the advent of digital computing technology in the 1960s which first found application in the architectures reaching fruition during the 1970s. The availability of digital computers that could be adopted for the rugged and demanding environment of the aerospace application brought computing power and accuracies that had not been available during the analogue era. The development of serial digital data buses greatly eased the interconnection and transfer of data between the major system units. In the early days this was achieved by means of fairly slow half-duplex (unidirectional), point-to-point digital links such as ARINC 429 and Tornado serial data link.

The arrival of microelectronics technology and the first integrated circuits (ICs) enabled digital computing techniques to be applied to many more systems around the aircraft. At the same time, more powerful data buses such as MIL-STD-1553B provided a full-duplex (bidirectional), multidrop capability at higher data rates, of up to 1 Mbit/s. This enabled the federated architectures that evolved during the 1980s, when multiple data bus architectures were developed to cater for increased data flow and system segregation requirements. At this stage the aerospace electronic components were mainly bespoke, being dedicated solutions with few, if any, applications outside aerospace.

The final advance occurred when electronic components and techniques were developed, driven mainly by the demands of the communications and IT industry which yielded a far higher capability than that which aerospace could sustain. This heralded the use of COTS technology, the use of which became more prevalent, and integrated modular avionics architectures began to follow and adapt to technology developed elsewhere.

The key attributes of each of the evolutionary stages of architectural development are described below.

2.1.1 Distributed Analogue Architecture

The distributed analogue architecture is shown in Figure 2.2. In this type of system the major units are interconnected by hardwiring; no data buses are employed. This results in a huge amount of aircraft wiring and the system is extremely difficult to modify if change is necessary. This wiring is associated with power supplies, sensor excitation, sensor signal voltage and system discrete mode selection and status signals. These characteristics are evident in those aircraft conceived and designed throughout the 1950s and 1960s, many of which are still in service today.

Figure 2.2 Distributed analogue architecture.

These systems have dedicated subsystems, controls and displays. The displays are electro-mechanical and often extremely intricate in their operation, requiring instrument maker skills for assembly and repair.

The use of analogue computing techniques does not provide the accuracy and stability offered by the later digital systems. Analogue systems are prone to bias or drift, and these characteristics are often more pronounced when the aircraft and equipment are subject to a hot or cold soak over a prolonged operating period. The only means of signalling rotary position in an analogue system is by means of synchro angular transmission systems. The older analogue aircraft – termed classic in the industry – therefore contain a huge quantity of synchros and other systems to transmit heading, attitude and other rotary parameters. Pallet (1992) is an excellent source of information on many of the older analogue techniques.

The older equipment is very bulky and heavy and tends to be unreliable as there are many moving parts. This is not a criticism; the designers of the time did their best with the technology available, and many very elegant engineering solutions can be found in this type of equipment. Futhermore, the skills required to maintain some of the intricate instruments and sensors are gradually becoming scarcer, and consequently the cost of repair continues to rise even assuming spare parts are available. Many educational and training institutions no longer teach at this technology level, giving rise to a knowledge gap, which in turn has implications for organisations wishing to refurbish or maintain legacy aircraft and products.

As has already been mentioned, these systems are very difficult to modify, which leads to significant problems when new equipment such as a flight management system has to be retrofitted to a classic aircraft. This is required when military aircraft are upgraded to comply with modern Air Traffic Control (ATC) procedures or a global air transport system (GATM) which are described in Chapter 7.

Typical aircraft in this category are: Boeing 707, VC10, BAC 1-11, DC-9 and early Boeing 737s. Many of these types are still flying, and some such as the VC-10 and the KC-135 and E-3/E-4/E-6 (Boeing 707 derivatives) are fulfilling military roles. They will continue to do so for several years, but gradually their numbers are dwindling as aircraft structural problems are manifested and the increasing cost of maintaining the older systems takes its toll.

2.1.2 Distributed Digital Architecture

The maturity of digital computing devices suitable for airborne use led to the adoption of digital computers, allowing greater speed of computation, greater accuracy and removal of bias and drift problems. The digital computers as installed on these early systems were a far cry from today, being heavy, slow in computing terms, housing very limited memory and being difficult to reprogram – requiring removal from the aircraft in order that modifications could be embodied.

A simplified version of the distributed digital architecture is shown in Figure 2.3. The key characteristics of this system are described below.

Major functional units contained their own digital computer and memory. In the early days of military applications, memory was comprised of magnetic core elements which were very heavy and which in some cases could only be reprogrammed off-aircraft in a maintenance shop. This combined with the lack of experience in programming real-time computers with limited memory and the almost total lack of effective software development tools resulted in heavy maintenance penalties.

As electrically reprogrammable memory became available, this was used in preference to magnetic memory. A significant development accompanying the emergence of digital processing was the adoption of serial half-duplex (unidirectional) digital data buses – ARINC 429 (civil aircraft) and Tornado serial (UK military) – which allowed important system data to be passed in digital form between the major processing centres on the aircraft. Although slow by today’s standards (110 kbit/s for ARINC 429 and 64 kbit/s for Tornado serial), the introduction of these data buses represented a major step forward, giving navigation and weapon-aiming systems major performance improvements by adopting this technology.

Figure 2.3 Distributed digital architecture.

At this stage, individual system components and equipment were still dedicated in function, although clearly the ability to transfer data between the units had significantly improved. The adoption of data buses, particularly ARINC 429, spawned a series of ARINC standards which standardised the digital interfaces for different types of equipment. The uptake of this standardisation led manufacturers producing inertial navigation systems (INS) to prepare standard interfaces for these systems. This eventually led to the standardisation between systems of different manufacturers, potentially easing the prospect of system modification or upgrade. The ARINC data bus is still important in military systems since many civil platforms adopted for military use rely upon the bus for baseline avionics system integration. The Boeing 737 [maritime patrol and airborne early warning and command system (AWACS)], Boeing 767 (AWACS and tanker) and A330 (tanker) are all recent examples. The Nimrod MRA4 uses an Airbus-based architecture for the avionics and flight deck display system which was based on ARINC 429. This is a modern example of a new military aircraft successfully blending a commercial system with military standard systems.

Displays in the cockpit were dedicated to their function as for the analogue architecture already described. The displays were still the intricate electromechanical devices used previously, with the accompanying problems. In later implementations the displays become multifunctional and multicolour, and the following display systems were developed in the civil field:

  • Electronic flight instrument system (EFIS);
  • Engine indication and crew alerting system (EICAS) – Boeing and others;
  • Electronic checkout and maintenance (ECAM) – Airbus.

Data buses offered a great deal of flexibility in the way that signals were transferred from unit to unit. They also allowed architectures to be constructed with a considerable reduction in interunit wiring and multipin connectors. This led to a reduction in weight and cost, and also eased the task of introducing large and inflexible wiring harnesses into the airframe. This, in turn, led to reductions in the non-recurring cost of producing harness drawings, and the recurring cost of manufacturing and installing harnesses.

Although data buses did remove a great deal of aircraft wiring, the question of adding an additional unit to the system at a later stage was still difficult. In ARINC 429 implementations, data buses were replicated so that the failure of a single link between equipment did not render the system inoperable.

Overall the adoption of even the early digital technology brought great advantages in system accuracy and performance, although the development and maintenance of these early digital systems was far from easy.

Aircraft of this system vintage are:

  • Military – Jaguar, Nimrod MR2, Tornado and Sea Harrier;
  • Civil – Boeing 737 and 767 and Bombardier Global Express; these aircraft are relevant as many military platforms in the tanker, AWACs and intelligence gathering roles use these baseline civilian platforms.

2.1.3 Federated Digital Architecture

The next development – the federated digital architecture – is shown in Figure 2.4. The federated architecture – from now on all architectures described are digital – relied principally upon the availability of the extremely widely used MIL-STD-1553B data bus. Originally conceived by the US Air Force Wright Patterson development laboratories, as they were called at the time, it evolved through two iterations from a basic standard, finally ending up with the 1553B standard, for which there are also UK Def-Stan equivalents (UK Def Stan 00–18 series).

The adoption of the 1553B data bus standard offered significant advantages and some drawbacks. One advantage was that this was a standard that could be applied across all North Atlantic Treaty Organisation (NATO) members, offering a data bus standard across a huge military market, and beyond. The 1553B data bus has been an exceptionally successful application, and the resulting vast electronic component market meant that prices of data bus interface devices could be reduced as the volume could be maintained. It also turned out, as had been the case with earlier data bus implementations, that the interface devices and hence the data buses were far more reliable that anyone could have reasonably expected. Consequently, the resulting system architectures were more robust and reliable than preceding architectures and more reliable than the designers had expected.

Figure 2.4 Federated avionics architecture.

Federated architectures generally use dedicated 1553B-interfaced line replaceable units (LRUs) and subsystems, but the wide availability of so much system data meant that significant advances could be made in the displays and other aircraft systems such as utilities or aircraft systems where avionics technology had not previously been applied.

Although the higher data rates were most welcome – approximately 10 times that of the civil ARINC 429 and about 15 times that of the earlier Tornado serial data link – this standard was a victim of its own success in another way. The full-duplex (bidirectional), multidrop protocol meant that it was rapidly seized upon as being a huge advance in terms of digital data transfer (which it was). However, system designers soon began to realise that in a practical system perhaps only 10–12 of the 31 possible remote terminals (RTs) could generally be used owing to data bus loading considerations. At the time of the introduction of 1553B, it was the policy of government procurement agencies to insist that, at system entry into service for a military system, only 50% of the available bandwidth could be utilised to allow growth for future system expansion. Similar capacity constraints applied to processor throughput and memory. Therefore, system designers were prevented from using the last ounce of system capability either in terms of data transfer or computing capability. This led to the use of subsystem dedicated data buses, as shown in Figure 2.4, in which each major subsystem such as avionics, general systems and mission systems had its own bus, complete with a dual-redundant bus controller.

It was also recognised that it was not necessary to have every single piece of data bus equipment talking to every other across the aircraft. Indeed, there were sound systems reasons for partitioning subsystems traffic by data bus to enable all similar task-oriented systems to interchange information on the same bus. The provision of interbus bridges or links between different buses allowed data to be exchanged between functional subsystems. Therefore, during the late 1980s/early 1990s, many multibus architectures similar to the one portrayed in Figure 2.4 were evolved. With minor variations, this architecture is representative of most military avionics systems flying today, including the F-16 mid-life update, SAAB Gripen and Boeing AH-64 C/D.

The civil aircraft community was less eager to adapt to the federal approach, having collectively invested heavily in the single-source–multiple sink ARINC 429 standard that was already widely established and proving its worth in the civil fleets. Furthermore, this group did not like some of the detailed implementation/protocol issues associated with 1553B and accordingly decided to derive a new civil standard that eventually became ARINC 629. To date, ARINC 629 is not envisaged as having a military application.

MIL-STD-1553B utilises a ‘command–response’ protocol that requires a central control entity called a bus controller (BC), and the civil community voiced concerns regarding this centralised control philosophy. The civil-oriented ARINC 629 is a 2 Mbit/s system that uses a collision avoidance protocol providing each terminal with its own time slot during which it may transmit data on to the bus. This represents a distributed control approach. To be fair to both parties in the debate, they operate in differing environments. Military systems are subject to continuous modification as the Armed Forces need to respond to a continually evolving threat scenario requiring new or improved sensors or weapons. In general, the civil operating environment is more stable and requires far fewer system modifications.

ARINC 629 has only been employed on the Boeing 777 aircraft where it is used in a federated architecture. The pace of aerospace and the gestation time required for technology developments to achieve maturity probably mean that the Boeing 777 will be the sole user of the ARINC 629 implementation.

Along with the developing maturity of electronic memory ICs, in particular non-volatile memory, the federated architecture enabled software reprogramming in the various system LRUs and systems via the aircraft-level data buses. This is a significant improvement in maintainability terms upon the constraints that previously applied. For military systems it confers the ability to reprogram essential mission equipment on a mission-by-mission basis. For the civil market it also allows operational improvements/updates to be speedily incorporated.

The more highly integrated federated system provides a huge data capture capability by virtue of extensive high-bandwidth fibre-optic networks.

2.1.4 Integrated Modular Architecture

The commercial pressures of the aerospace industry have resulted in other solutions being examined for military aircraft avionics systems. The most impressive is the wholesale embracement of integrated modular architectures, as evidenced by US Air Force initiatives such as the Pave Pillar and JIAWG architectures which will be described later.

The resulting architectures use open standards, ruggedized commercial technology to provide the data bus interconnections between the major aircraft systems and integrated computing resources (Figure 2.5).

2.1.5 Open Architecture Issues

As the use of digital technology became increasingly widespread across the aircraft throughout the 1970s, a number of issues became apparent. The use of digital technology introduced new and difficult issues that the system designer and end-user had to embrace in order successfully to develop and support digital avionics systems.

The use of computers and, later, microprocessors, the functionality of which lay in the software applications that were downloaded, introduced a new and far-reaching discipline: that of software tools and software languages. Early processors were slow and cumbersome without the benefit of structured and standardised tools, instruction sets and languages. The memory available for the operational software was strictly limited and was a major constraint upon how the program was able to fulfil its task. A further compounding factor is that the avionics processor is required to perform its operational tasks in real time. At that point in the evolution of computer systems, such operational ‘real-time’ design experience as was available was centred on the use of mainframe applications where size and memory are less of an impediment. This stimulated a separate offshoot of the computing community that had new issues to address and precious few tools to help in its endeavour.

Figure 2.5 Integrated modular architecture.

Another factor had an impact upon the adoption of digital technology. In the main the aerospace community is and was conservative and generally prefers to adopt bespoke solutions more suited to its unique operational tasks, particularly where high integrity and safety are often primary considerations. Furthermore, airborne applications, particularly those on military aircraft designed for worldwide use, have to survive severe operational environments compared with a mainframe computer operating in a comfortable air-conditioned environment. As a consequence, the development timescales, particularly of large or multi-national projects requiring extensive software designs, became much longer than those of corresponding commercial projects. Therefore, while the military aerospace designers conservatively used technology that was proven and that would work within their severe environments, the commercial computer world was able to adopt more flexible approaches. As both worlds developed independently, the military tended to become a much smaller player in terms of component development and procurement while the commercial fields of IT and telecommunications became the major driving force. In particular, in this environment, the commercial computing world were early to adopt open architectures, whereas the military community did so much later.

2.1.6 Impact of Digital Systems

Although early implementations of digital technology followed the distributed digital architectures shown in Figure 2.3, the availability of dedicated specifications such as MIL-STD-1553B permitted the aircraft wide interconnection of functional aircraft and avionic functions. While somewhat limited in capacity at 1 Mbit/s, the standard proved to be reliable and the multidrop, full-duplex architecture was central to the adoption of the federated digital architecture described above. Digital avionics technology was used not only to implement navigation and weapon-aiming functions but also became embedded in sensors, communications, flight and engine control, stores management systems, displays and utility control functions.

As functionality and the use of digital technology increased, so the proliferation of processor types and software languages also increased. Therefore, while an aircraft system was integrated in the sense that the data buses were able readily to interchange data between major systems and subsystems, the individual lower-level equipment implementations were beginning to diverge.

One factor that became a major issue was the non-availability of a standardised software language. In many cases the time constraints imposed by the real-time application meant that the program had to be written in assembler or even machine code. The ability to modify and support such implementations once the original design team had dispersed became impossible. Reliable and detailed software documentation was generally sparse or non-existent, with comment fields to explain the design philosophy. As the scope of digital technology expanded, the need for widespread and standardised software tools, languages and procedures became recognised. The military community addressed these issues by developing more military specifications to enforce standardisation and impose disciplines to improve the visibility, documentation and supportability of software application programs.

Therefore, while the widespread application of digital technology in distributed digital and federated digital architectures brought considerable performance advantages, there was a significant downside that needed to be addressed.

2.1.7 Response of the Services to Digital Avionics Systems Issues

The problems resulting from widespread application of digital technology were addressed – at the risk of considerable oversimplification – by the adoption of the following measures:

  • Adoption of federated multibus architectures using a range of line replaceable units (LRUs), commonly known as ‘black boxes’ to the layman;
  • Standardisation of processors;
  • Standardisation of high-order language (HOL).

These measures were accompanied with a number of standards imposing defined hardware and software development methodologies.

The adoption of the federated bus architecture was generally a success inspite of the limited bandwidth of MIL-STD-1553B, and many so-called fourth-generation fighter aircraft are flying and enjoying the benefits of that approach. The embedded dual-redundant nature of the data bus standard coupled with the inherent reliability of the data bus interface devices has provided a robust and durable solution. The real problems existed at a lower level in the subsystems and LRUs that comprised the overall avionics system.

The US military took the approach of standardising upon a common processor in the hope that major benefits would result in terms of lower costs and enhanced supportability. It was hoped that the use of a standard machine used force-wide would provide these benefits across a range of platforms, and the standard adopted by the US Air Force was the MIL-STD-1750A limited instruction set processor. As often happens as a result of ambitious standardisation initiatives, there is a tendency to ‘round up’ the performance of the common device to meet the more demanding (and more risky) applications; this tends to result in a ‘fit-all’ product that is overly complex for many mundane applications. The standardisation focus within the US Navy was the AN/AYK-14 computer which suffered similarly. Therefore, while the Air Force and Navy were both pursuing standardisation initiatives, their chosen solutions differed.

The US Air Force also attempted to standardise the software language, and during the mid-1980s the JOVIAL language was commonly specified. However, by the 1970s, the US Department of Defense (DoD) was using more than 2000 languages for its mission-critical programming. Most of these were languages that were developed for one specific application. Finally, in 1975, the DoD formed the US Department of Defense High-Order Language Working Group (HOLWG) to find a solution to what was often called the ‘software crisis’.

The HOLWG group members decided that they needed to create a language that could be used for just about anything, whether it be systems programming, artificial intelligence or, most important of all, real-time programming and embedded systems. Rather than create this new language themselves, they decided to hold a contest. Coincidentally, all of the competing teams created Pascal-based languages. In the end, the winner was the French-led CII Honeywell-Bull. Eventually, the language was christened ‘Ada’, in honour of Lady Ada Lovelace, daughter of the poet Lord Byron and assistant to mathematician Charles Babbage, who invented the analytical machine. Lady Ada is often considered to be the world’s first programmer, and more details of her life can be found in Woolley (1999).

These initiatives were essentially aimed at producing a military off-the-shelf (MOTS) suite of products whereby the military system designer could select known products for the implementation of the design. The idea was that these military products would be supported by the commercial industry computer base, suitably funded, to provide the military community with the technology and devices that they desired. The drawback to this approach was that the commercial community was moving ahead faster than the military could keep pace, not only with regard to devices and software but also in the adoption of open system architectures. The military were therefore forced to consider open architecture modular integrated cabinet approaches that the commercial world was developing with success.

The adoption of modular architectures was not totally new to the services: the US Air Force in particular had initiatives under way throughout the 1970s and 1980s. The integrated communication navigation and identification architecture (ICNIA) was a serious attempt to use common radio-frequency (RF) building blocks to address the proliferation of RF equipment. A later initiative called Pave Pillar also addressed modular architecture issues. This programme questioned the black box approach to avionics. Pave Pillar architecture physically comprised a number of building blocks called common modules. Each module contained the circuitry to perform a complete digital processing function including interface control and health diagnosis. The common modules were developed from a limited very high-speed integrated circuit (VHSIC) chip set. A number of common module types could then be built up from a small family of VHSIC chips. Modules could then, in turn, be built up to form the basis of any of several avionic subsystems. Some uncommon modules are still required for the odd specific function; however, reduction in the types of spare required as a result of common module usage provided a significant cost improvement. Common modules result in increased production runs for specific modules, which reduces initial purchase cost, while the associated reduction in spares reduces maintenance and support costs. A modular concept allows maintenance engineers to remove and replace components while allowing system designers to adapt the avionics suite to new requirements, and at reduced risk. This concept eventually developed into the integrated modular avionics architecture discussed later in this chapter.

By the late 1980s the Joint Integrated Avionics Working Group (JIAWG) had adopted an approach that was mandated by the US Congress to be used on the three major aircraft developments. These were the US Air Force advanced tactical fighter (ATF), now the F-22 Raptor; the US Navy advanced tactical aircraft (ATA), or A-12 Avenger, which was cancelled in 1990; and the US Army LHX helicopter which became the RAH-66 Comanche and which was cancelled in early 2004. The JIAWG architecture as implemented on the F-22 and later IMA/open architectures will be described later in this chapter. Mean-while in Europe, the Allied Standards Avionics Architecture Council (ASAAC) developed a set of hardware and software architecture standards around the IMA/open architecture concept.

2.1.8 Need to Embrace COTS

As it became clear that the military aerospace community was a follower rather than a leader in terms of component technologies and architectures, a number of key issues had to be addressed if COTS were to embraced. These included:

  • The ability to obtain devices suitable for operation in specified military operating temperature ranges: – 55°C to + 125°C; other environmental issues such as vibration and humidity would also be important;
  • Achieving support for the military requirements of integrity/safety, security and certification: issues to which the donor technology is not necessarily exposed in the commercial field;
  • Determining the heritage of the hardware device or software program – integrity of development tools, documentation, design traceability and assurance;
  • Lack of control of the service authorities over the design standards used;
  • The relative short life span and volatility of commercial products, leading to huge lifetime support issues.

The federated architecture already described has proved to be successful but not without a number of drawbacks: the relatively limited bandwidth of MIL-STD-1553B has already been mentioned. In such a system, units are loosely coupled, and this may lead to non-optimum use of data owing to latency issues and overall system performance degradation. While system upgrades may be relatively easily accomplished at the data bus level simply by adding another remote terminal, this is only part of the story. Any change in data transfer leads to changes in the bus controller transaction tables. More importantly, system-wide upgrades usually affect a number of different units, each of which may have its own issues relating to the ease (or difficulty) of modification. Furthermore, if the units involved in the upgrade are provided by different vendors, as is often the case, the modification or upgrade process becomes even more complicated as all vendors need to be managed throughout the programme.

The fundamental advantage offered by an integrated modular avionics (IMA) approach is that, from the outset, the system is conceived using standard building blocks that may be used throughout the aircraft level system. Therefore, common processor modules, common memory modules and, where possible, common input/output modules offer the means of rapidly conceiving and constructing quite extensive system architectures. This approach reduces risk during the development phase, as well as offering significant supportability advantages. The IMA philosophy readily adapts to redundancy implementation in a most cost-effective manner so that economies of scale are easily achieved.

The adoption of COTS-based IMA architectures provides another significant advantage, that is, rapid prototyping. As the baseline modules are off-the-shelf produced in a commercial format, these may be readily purchased in order that a candidate architecture may be built and prototyped using mature commercial boards. Previously, prototyping had to wait until early development hardware was available for all the contributing subsystems; this hardware tended to be immature, and often featured development bugs.

A true comparison of the benefits to be attained by utilising COTS can only be reached after reviewing all the areas where the commercial technology offers benefits. In virtually every respect, COTS offers advantages:

  1. Data buses and networks. Evolution from the initial 1 Mbit/s MIL-STD-1553B data bus to high-speed COTS 1 Gbit/s, plus solutions such as the scalable coherent interface (SCI), the asynchronous transfer mode (ATM), fibre channel technology and the gigabit Ethernet (GE).
  2. Software. The adoption of a multilayer software model that segregates the application software from the functional hardware, thereby allowing software to be portable across a range of differing and evolving hardware implementations.
  3. Processing:
    • Signal processing. This offers significant advances in some of the more challenging tasks in the area of radar, electronic warfare (EW) and electroopics (EO); many technological advances have resulted from the development of the Internet.
    • Data processing. There is often a significant task involved in processing data for transmission or display. The pace at which commercial office IT processors are moving in terms of clock speed far outweighs any advance that could have been achieved using military drivers alone.

These issues and the competing technologies are discussed in detail by Wilcock et al. (2001).

In summary, there are many advantages that the military community may gain by the adoption of COTS technology. Apart from the obvious advantage of cost, much greater capability and functionality benefits result, and COTS solutions have been vigorously sought since around the mid-1990s. While not totally without drawbacks, COTS has been adopted for many of the new build or upgrade programmes launched in the last decade.

A few of the many examples of COTS technology in military systems are as follows:

  1. The US JSTARS aircraft is fitted with standard DEC Alpha operator workstations.
  2. The Israeli Python 4 air-to-air missile avionics system is powered by an Intel 486 processor.
  3. The Chinese F-7MG has been fitted with a Garmin GPS 150 receiver (as available at most good high-street electronics dealers!).

2.2 Aerospace-specific Data Buses

As has already been described, digital data buses have been one of the main enablers in the use of digital electronics in aircraft avionics systems. Early data buses were single-source, single-sink (point-to-point), half-duplex (unidirectional) buses with relatively low data rates of the order of a few tens to 100 kbit/s data rates. The next generation of data buses as typified by MIL-STD-1553B were multiple-source, multiple-sink (bidirectional) buses with data rates of around 1–10 Mbit/s. Later fibre channel buses achieve 1 Gbit/s data rates, with the prospect of expanding to several Gbit/s.

Figure 2.6 depicts a comparative illustration of the data bus transmission rates of buses used onboard military avionics platforms.

The dedicated aerospace data buses used within the military aerospace community are:

  • Tornado serial data bus;
  • ARINC 429;
  • MIL-STD-1553B and derivatives;
  • STANAG 3910.

Other bus standards such as the JIAWG high-speed data bus (HSDB), the IEEE 1394b and fibre channel buses are all commercial standards that have been adopted for military use.

2.2.1 Tornado Serial

The Tornado serial data bus – more correctly referred to by its PAN standard (Panavia standard) – was the first to be used on a UK fighter aircraft. The bus was adopted for the Tornado avionics system and also used on the Sea Harrier integrated head-up display/weapon-aiming computer (HUD/WAC) system. This is a half-duplex serial bus operating at a rate of 64 kbit/s and is used to pass data between the avionics main computer and other sensors, computers and displays within the Tornado nav attack and weapon-aiming system, as shown in Figure 2.7.

Figure 2.6 Comparative data bus transmission rates.

The bus comprised four wires implemented as a twisted screened quad format. The lines carried clock and complement and data and complement respectively.

The Tornado system architecture utilising this bus is depicted in the lower part of Figure 2.7. It shows the main computer interfacing via the Tornado serial bus with major avionics subsystems:

  • Doppler radar;
  • Radar (ground-mapping radar (GMR) and terrain-following radar (TFR);
  • Laser range finder/marked target receiver (MTR);
  • Attitude Sources – inertial navigation system (INS) and secondary attitude and heading reference system (SAHRS);
  • Autopilot/flight director system (AFDS);
  • Stores management system (SMS);
  • Front cockpit:
    • – head-up display (HUD),
    • – pilot’s navigation display,
    • – interface unit 1 (IFU 1) for front cockpit I/O;
  • Rear cockpit:
    • – navigator’s displays (2),
    • – interface unit 2 (IFU 2) for rear cockpit I/O.

Figure 2.7 Tornado serial data bus and application.

This system was designed in the early 1970s and entered service in 1980.

2.2.2 ARINC 429

ARINC 429 is a single-source, multiple-sink, half-duplex bus that operates at two transmission rates; most commonly the higher rate of 100 kbit/s is used. Although the data bus has its origins in the civil marketplace, it is also used extensively on civil platforms that have been adopted for military use, such as the Boeing 737, Boeing 767 and A330. High-performance business jets such as the Bombardier Global Express and Gulfstream GV that are frequently modified as electronic intelligence (ELINT) or reconnaissance platforms also employ A429.

The characteristics of ARINC 429 were agreed among the airlines in 1977/78, and it was first used throughout the B757/B767 and Airbus A300 and A310 aircraft. ARINC, short for Aeronautical Radio Inc., is a corporation in the United States whose stockholders comprise US and foreign airlines and aircraft manufacturers. As such it is a powerful organisation central to the specification of equipment standards for known and perceived technical requirements.

Figure 2.8 A429 topology and the effect of adding units.

The ARINC 429 (A429) bus operates in a single-source–multiple sink mode so that a source may transmit to a number of different terminals or sinks, each of which may receive the data message. However, if any of the sink equipment needs to reply, then each piece of equipment will require its own transmitter and a separate physical bus to do so, and cannot reply down the same wire pair. This half-duplex mode of operation has certain disadvantages. If it is desired to add additional equipment as shown in Figure 2.8, a new set of buses may be required – up to a maximum of eight new buses in this example if each new link needs to operate in bidirectional mode.

The physical implementation of the A429 data bus is a screened, twisted wire pair with the screen earthed at both ends and at all intermediate breaks. The transmitting element shown on the left in Figure 2.9 is embedded in the source equipment and may interface with up to 20 receiving terminals in the sink equipment. Information may be transmitted at a low rate of 12–14 kbit/s or a higher rate of 100 kbit/s; the higher rate is by far the most commonly used. The modulation technique is bipolar return to zero (RTZ), as shown in the box in the figure. The RTZ modulation technique has three signal levels: high, null and low. A logic state 1 is represented by a high state returning to zero; a logic state 0 is represented by a low state returning to null. Information is transmitted down the bus as 32 bit words, as shown in Figure 2.10.

Figure 2.9 A429 data bus and encoding format.

Figure 2.10 A429 data word format.

The standard embraces many fixed labels and formats, so that a particular type of equipment always transmits data in a particular way. This standardisation has the advantage that all manufacturers of particular equipment know what data to expect. Where necessary, additions to the standard may also be implemented. Further reading for A429 may be found in Moir and Seabridge (2004).

2.2.3 MIL-STD-1553B

MIL-STD-1553B has evolved since the original publication of MIL-STD-1553 in 1973. The standard has developed through 1553A standard issued in 1975 to the present 1553B standard issued in September 1978. The basic layout of a MIL-STD-1553B data bus is shown in Figure 2.11. The data bus comprises a screened twisted wire pair along which data combined with clock information are passed. The standard generally supports multiple-redundant operation with dual-redundant operation being by far the most common configuration actually used. This allows physical separation of the data buses within the aircraft, therby permitting a degree of battle damage resistance.

Control of the bus is performed by a bus controller (BC) which communicates with a number of remote terminals (RTs) (up to a maximum of 31) via the data bus. RTs only perform the data bus related functions and interface with the host (user) equipment they support. In early systems the RT comprised one or more circuit cards, whereas nowadays it is usually an embedded chip or hybrid module within the host equipment. Data are transmitted at 1 MHz using a self-clocked Manchester biphase digital format. The transmission of data in true and complement form down a twisted screened pair offers an error detection capability. Words may be formatted as data words, command words or status words, as shown in Figure 2.12. Data words encompass a 16 bit digital word, while the command and status words are associated with the data bus transmission protocol. Command and status words are compartmented to include various address, subaddress and control functions, as shown in Figure 2.12.

Figure 2.11 MIL-STD-1553B data bus.

Figure 2.12 MIL-STD-1553B data bus word formats.

Figure 2.13 MIL-STD-1553B typical data transactions.

MIL-STD-1553B is a command–response system in which transmissions are conducted under the control of a single bus controller at any one time; although only one bus controller is shown in these examples, a practical system will employ two bus controllers to provide control redundancy.

Two typical transactions are shown in Figure 2.13. In a simple transfer of data from RT A to the BC, the BC sends a transmit command to RT A, which replies after a short interval known as the response time with a status word, followed immediately by one or more data words up to a maximum of 32 data words. In the example shown in the upper part of the figure, transfer of one data word from RT A to the BC will take approximately 70 μs (depending upon the exact value of the response time plus propagation time down the bus cable). For the direct transfer of data between two RTs as shown from RT A to RT B, the BC sends a receive command to RT B followed by a transmit command to RT A. RT A will send its status word plus the data (up to a maximum of 32 words) to RT B which then responds by sending its status word to the BC, thereby concluding the transaction. In the simple RT to RT transaction shown in Figure 2.13, the total elapsed time is around 120 μs for the transmission of a single data word, which appears to be rather expensive on account of the overhead of having to transmit two command words and two status words as well. However, if the maximum number of data words had been transmitted (32), the same overhead of two command and two status words would represent a much lower percentage of the overall message time. For further reading, see MIL-STD-1553B (1986).

MIL-STD-1553B has proved to be a very reliable and robust data bus and is very well established as a legacy system. Attempts have been made to increase the data rate which is the only major shortcoming. A modification of 1553 called 1553 enhanced bit rate (EBR) running at 10 Mbit/s has been adopted for bomb carriage on the JSF/F-35 using the miniature munitions/store interface (MM/SI). Other vendors have run laboratory demonstrators at 100 Mbit/s and above, and a feasibility program has been initiated to demonstrate 1553 bit rates of 100 Mbit/s with the aim of extending data rates to 500 Mbit/s. This possible derivative is termed enhanced 1553 (EB-1553), and the US Air Force recently hosted a workshop to investigate the possibilities. In October 2003 the Society of Automotive Engineers (SAE) formed an ‘Enhanced Performance 1553’ task group to address the prospect of launching applications with throughputs of 200–500 Mbit/s using existing cables and couplers. A further standard using 1553 is MIL-STD-1760 – a standard weapons interface which is described in Chapter 9.

2.2.4 STANAG 3910

The evolution of STANAG 3910 was motivated by a desire to increase the data rate above the 1 Mbit/s rate provided by MIL-STD-1553B. The basic architecture is shown in Figure 2.14. The high-speed fibre-optic data terminals pass data at 20 Mbit/s and are connected using a star coupler. Control is exercised by MIL-STD-1553B using electrical connections. The encoding method is Manchester biphase, as for 1553, and data transactions are controlled by means of a bus controller, as is also the case for 1553.

The use of fibre optics passing data at 20 Mbit/s offers a significant improvement over 1553. Furthermore, the ability to transfer messages of up to 132 blocks of 32 words (a total of 4096 data words) is a huge advance over the 32 word blocks permissible in 1553. A total of 31 nodes (terminals) may be addressed, which is the same as 1553.

There are four possible implementations of STANAG 3910 (Table 2.1). The standard also makes provision for the high-speed channel to be implemented as an optical transmissive star coupler, a reflective star coupler or a linear Tee coupled optical bus. Eurofighter Typhoon utilises the type A network with an optical reflective star coupler in a federated architecture.

Figure 2.14 STANAG 3910 architecture.

Table 2.1 STANG 3910 implementations

Type A Low-speed channel 1553B data bus
High-speed channel Fibre-optic data bus
Type B High-speed channel Fibre-optic equivalent of 1553B
Low-speed channel Physically separate fibre-optic data bus
Type C High-speed channel Fibre-optic equivalent of 1553B
Low-speed channel Wavelength division multiplexed with low-speed channel
Type D High-speed channel 1553B data bus
Low-speed channel Physically separate wire data bus

Note: Both the low-speed and high-speed buses use Manchester biphase encoding.

The STANAG bus is used for the avionics bus and the attack bus while standard MIL-STD-1553B is used for the weapons bus. The Typhoon architecture is discussed in Chapter 9 of this book.

The similarity of transactions to 1553 may be seen by referring to the remote terminal (RT) to bus controller (BC) transaction on the low-speed bus as shown in Figure 2.15. The BC issues a standard 1553 command word followed by a high-speed (HS) action word (taking the place of a 1553 data word). After a suitable interval the RT issues a 1553 status word that completes the transaction. After an intermessage gap, the next transaction is initiated. This cues a high-speed message frame on the high-speed bus which enables the transmission of up to 132 blocks of 32 data words, up to a maximum of 4096 words, as has already been stated. A full description of all the STANAG data transactions may be found in Wooley (1999) which is also a useful source on many other data buses that may be used in avionics applications.

Figure 2.15 STANAG 3910 RT to BC data transaction.

Figure 2.16 STANAG 3910 HS word formats (low-speed bus).

The formats of the low-speed bus HS action word and HS status word are shown in Figure 2.16. It can be seen that the general format is similar to the 1553 words, except that these protocol words have positive-going synchronisation pulses as they are replacing the standard 1553 data word [which also has a positive-going synchronisation pulse (Figure 2.12)]. Also, the word content, instead of containing a 16 bit data word, contains message fields that relate to the high-speed bus message content or transmitter/receiver status. As for other 1553 words, the final bit (bit 20) is reserved for parity.

The format of the STANAG 3910 high-speed bus data structure is shown in Figure 2.17. The data content is preceded by 56 bits associated with the message protocol and followed by a further 20 bits, giving a total overhead of 76 bits in all. Therefore, a maximum 4096 data word transfer will take (56 + 4096 × 16 + 20) = 65 612 bits. At a the high-speed bus data rate of 20 Mbit/s, the total elapsed time is 3280.6 µs.

Figure 2.17 STANAG 3910 data structure.

The application of STANAG 3910 is confined to two European fighter aircraft programmes. Eurofighter Typhoon uses a variant called the EFA bus, which is a type A implementation, while the French Rafale employs type D, using the electrical high-speed bus version.

2.3 JIAWG Architecture

The Joint Integrated Avionics Working Group (JIAWG) was a body charged with developing an avionics architecture based upon the Pave Pillar principles of a modular integrated architecture. The resulting advanced avionics architecture (A3) was mandated by the US Congress to apply to the following major projects of the late 1980s:

US Air Force Advanced tactical fighter/F-22 Raptor
US Navy Advanced tactical aircraft (ATA)/A-12 (cancelled in the early 1990s)
US Army LH helicopter/RAH-66 Comanche (cancelled in early 2004)

2.3.1 Generic JIAWG Architecture

A generic avionics architecture embracing the main features of the JIAWG architecture is illustrated in Figure 2.18. The major functional elements are:

Figure 2.18 Generic JIAWG avionics architecture.

Figure 2.19 Generic JIAWG integrated cabinet architecture.

  • Radio-frequency (RF) apertures and sensor front ends associated with electrooptic (EO), missile warning, radar, electronic warfare/electronic support measures (EW/ESM), and communications, navigation and identification (CNI) systems;
  • A fibre-optic switched network handling incoming preprocessed sensor data;
  • Integrated avionic racks encompassing signal and data processing and interconnected using switched networks, parallel buses and serial buses;
  • A fibre-optic switched network handling video data destined for displays; Aircraft and weapons systems;
  • A high-speed data bus (HSDB) (fibre-optic bus) interconnecting the avionics major systems to the integrated cabinets.

The integrated cabinet architecture selected for the JIAWG architecture is portrayed in generic form in Figure 2.19. The main processor is called the common integrated processor (CIP) and two cabinets are provided in the F-22 architecture with space provision for a third. In fact the term processor is a misnomer as the CIP function contains a cluster of processors (up to seven different types) working together to perform the aircraft-level signal processing and data processing tasks. It has been reported that the combined throughput of the CIP is of the order of 700 million operations per second (MOPS). The F-22 CIP is the responsibility of Hughes.

The F-22 cabinet has space to accommodate up to 66 SEM-E size modules, but in fact only 47 and 44 modules are used respectively in CIP 1 and CIP 2; the remaining 19/22 modules are growth. The density of the packaging and the high power density mean that liquid cooling is used throughout for the cabinets.

To achieve the necessary communications to interchange data with the donor and recipient subsystems, the cabinet interfaces internally and externally using the following data buses:

  • A high-speed data bus (HSDB) – a fibre-optic (FO) bus connecting the cabinet with other aircraft subsystems, as shown in Figure 2.18;
  • A dual-redundant parallel interface bus (PI bus) (backplane bus) used to interconnect the modules within the rack;
  • A serial test and maintenance bus (TM bus) for test and diagnosis.

The FO buses and interconnects are provided by the Harris Corporation.

Figure 2.20 FO linear token passing topology (HSDB).

2.3.2 High-speed Data Bus

The high-speed data bus is a linear token ring FO bus operating at 80 Mbit/s. The protocol is in accordance with SAE AS4074.1, for a linear token passing multiplexed data bus. The key characteristics of the HSDB are:

  • Manchester biphase encoding;
  • Message length up to 4096 16 bit words;
  • Ability to service up to 128 terminals.

Figure 2.20 shows a FO liner token passing topology typical of that used for the HSDB.

The SAE linear token passing bus (LTPB) employs a broadcast technique whereby all the terminals can receive all the traffic passing on the bus. However, the transactions are structured such that only those stations whose address matches the destination address within the message header can copy the message. A token passing path is superimposed upon the linear transmission media, and it is this that provides the control logic for each bus interface unit (BIU).

A token is passed around the ring from the lowest address to the highest and then to the lowest again, forming a continuous loop. Stations that have data to transmit claim the token and send the message. The philosophy used is that known as a ‘brother’s keeper’ where every terminal is responsible for providing a valid token to pass to the next terminal. Therefore, in the example given in Figure 2.20, the token and therefore control of the bus would be passed as follows:

and the sequence would repeat.

The media access control (MAC) protocol adopted for the SAE TTPB is one in which timers are used to bound the time a station is allowed to pass data on the bus. As well as having bounded time constraints, each BIU has four message priority levels such that the highest-priority messages are transmitted first and those of lowest priority last. In the event that lower-priority messages cannot be passed owing to insufficient time, these messages can be deferred until the next period.

AIR4288, AIR4271, AS4290 and RTCA DO-178B in the references section of this chapter provide further information upon the operation, use and validation of SAE AS4074.

Unfortunately, this data bus standard, although adopted by the SAE, has not attracted the general support and take-up that the system designers had hoped for. Consequently, it will need to be replaced with a more recent alternative such as the fibre channel (FC) bus very early in the service life of the aircraft. Before its recent cancellation, the RAH-66 Comanche had already adopted a fibre channel implementation in place of the HSDB.

2.3.3 PI Bus

The PI bus is a fault-tolerant parallel backplane bus very similar in structure to VME. The bus operates using a 32 bit wide bus which can be expanded to 64 bit wide. The transfer rate is 50 Mbit/s and the JIAWG architecture employs a dual-redundant implementation. The PI bus is supported by the SAE 4710 and STANAG 3997 standards.

2.3.4 TM Bus

The TM bus is a serial bus comprising five wires that supports test and diagnostics according to the IEEE Std 1149.5-1995 which allows a master controller to interface with up to 250 slave units. Depending upon the precise implementation of the TM bus, diagnosis may be achieved at the board (module) or chip (component) level.

2.3.5 Obsolescence Issues

While the JIAWG architecture was a valiant attempt to achieve cross-service avionics standardisation, it has not succeeded owing to a number of factors, none of which could have been foreseen. At the outset, each of the services was expecting to procure several hundred ATFs, ATAs and LH helicopters. The Cold War had not ended and the USSR/Warsaw Pact was seen as the prime threat. The Navy ATA/A-12 was cancelled early for other reasons, but the remaining ATF/F-22 and LH/RAH-66 programmes had to contend with a post-Cold War and post-Desert Storm world. Inevitably, some of the momentum was lost once the USSR disintegrated and contempory weapons systems performed so well in the Iraq conflict. Finally, it would have been a visionary who could have forecast the true scale and pace of the impact of commercial technology upon military platforms.

Before cancellation of the RAH-66 Comanche, the following problems had been recognised with the JIAWG architecture:

  1. The JIAWG-driven processor (Intel 80960 MX) product line was closed down and the processor changed to the i86.
  2. The JIAWG-driven backplane (PI bus) product line was closed down.
  3. The JIAWG-driven test and maintenance (TM bus) is non-standard.
  4. The JIAWG/SAE-driven 80 Mbit/s HSDB failed to achieve commercial or military acceptance.
  5. The JIAWG-driven SEM-E module format is too small for some COTS technology.

Figure 2.21 JIAWG architecture upgraded using fibre channel buses.

These problems will probably be addressed on the F-22 by the adoption of a fibre channel (FC) for the aircraft-level and major subsystem interconnects, permitting the existing original architecture to be ‘grown’ in bandwidth while addressing the obsolescence issues. Figure 2.21 shows how the baseline JIAWG generic architecture could be modified to accept FC buses in place of the original HSDB, PI and TM buses. The overall impression is of simplification, as the original 80 Mbit/s linear token ring HSDB is replaced by FC buses capable of carrying 1 Gbit/s or more. The higher bandwidth provided is more suited to ‘data stream’ the sensor data to the signal and data processing areas within the integrated cabinets. Similar architectural upgrades have been examined for the Apache AH-64 C/D (which predates the JIAWG architecture) and RAH-66/Comanche helicopters.

Developments on more recent projects have provided a forward path for the integration of portable legacy software and new processor types without the need to invest further development work on the operational software packages. This approach is outlined later in the chapter.

2.4 COTS Data Buses

The lack of progress in sponsoring a sustainable high-speed military data bus has led systems designers towards developments in the commercial field, namely COTS. There are a number of possibilities, including the asynchronous transfer mode (ATM) and the fibre distributed data interface (FDDI), but those viewed with the most favour at the time of writing are:

  • The fibre channel bus;
  • IEEE 1394 firewire.

2.4.1 Fibre Channel

The fibre channel (FC) is a high-throughput, low-latency, packet-switched or connection-oriented network technology; in aerospace applications the latter configuration is usually employed. Data rates are presently available up to 1 Gbit/s, although 10 Gbit/s versions are under development. A whole series of standards are evolving, with one dedicated to avionics applications – the avionics environment project (FC-AE).

The FC bus is designed to operate in an open environment that can accommodate multiple commercial protocols such as the small computer system interface (SCSI) and transport control protocol/Internet protocol (TCP/IP). For avionics applications the FC-AE standard specifies a number of upper-level protocols (ULPs) that align more directly with aerospace applications. These are:

  • FC-AE-1553;
  • FC-AE-ASM (anonymous subscriber messaging);
  • FC-AE-RDMA (remote direct memory access);
  • FC-AE-LP (lightweight protocol).

FC-1553 is very useful as it allows the MIL-STD-1553 protocol to be mapped on to the high-bandwidth FC network, creating a low-overhead highly deterministic protocol with a high bandwidth capability. FC-AE-1553 allows a large number of nodes to communicate: increasing from 32 for the baseline 1553 implementation to 224, while the number of possible subaddresses increases from 32 to 232. Likewise, the maximum word count increases from 32 to 232. While these features offer an enormous increase in capability, a further benefit is that FC-AE-1553 provides a bridge between legacy 1553 networks and the much higher-bandwidth FC networks. Therefore, an upgrade introducing an FC network to provide additional bandwidth in certain parts of an avionics architecture can be readily achieved while maintaining those parts that do not require a bandwidth increase intact. The FC-AE-ASM, RDMA and LP options are lightweight protocols that can be variously adopted for specific avionics applications, depending upon the exact requirement.

SCSI is a widely used commercial mass storage standard that allows FC nodes easily to access SCSI-controlled disc space, while TCP/IP is a widely used networking protocol that allows modern computer peripherals and software to communicate. This allows the avionics system designer to utilise commercially available packages. The compatibility of SCSI and TCP/IP with the FC-AE specifications also allows rapid prototyping early in the development cycle.

The FC standards define a range of topologies, the basic four of which are shown in Figure 2.22. These are as follows:

  1. Point-to-point communication is used to provide a dedicated link between two computers. This is the least expensive option but one that may find application connecting a radar or EO sensor with its associated processor.
  2. Arbitrated loop is a ring topology providing a low-cost solution to connect up to 128 nodes on a shared bandwidth network, where each node is able to gain control of the loop and establish a connection with another node and generate traffic. Arbitrated loops are limited in their ability to support simultaneous operation and do not include fault tolerance to enable the network to withstand node or media failure. The available bandwidth is shared between the network nodes.
  3. Hubbed loop is a variation of the arbitrated loop in which the node connections are made by means of a central hub. In the event of failure, a port bypass circuit enables the failed or inoperative node to be bypassed and allows traffic to continue between the remaining nodes.
  4. Switched fabric is a network capable of providing multiple simultaneous full-bandwidth transfers by utilising a ‘fabric’ of one or more interconnected switches: this provides the highest level of performance. An offshoot of the switched fabric topology is the provision of arbitrated loops (called a public loop) enabling connection between low-bandwidth nodes (connected to the public loop) and high-bandwidth nodes connected directly to the fabric. Switched fabric represents the most powerful but also the most expensive option.

Figure 2.22 Fibre channel topologies.

To enable these topologies, a number of different node types are defined and used, as shown in Figure 2.22. These node types are as follows:

  1. Node port (N_Port). This provides a means of transporting data to and from another port. It is used in point-to-point and switched topologies.
  2. Fabric port (F_Port). This provides the access for an N_Port to the switched fabric.
  3. Loop port (L_Port). This port is similar to an N_Port but has additional functionality to provide the arbitrated loop and hubbed loop functions. It can also be used to connect loops and the switched fabric.
  4. Expansion port (E_Port). The E_Port is used to provide interconnection between multiple switches within the fabric.

Figure 2.23 Redundant switched fabric topology with bridges.

The switched fabric topology offers a high-capacity interconnect between a number of nodes which can in turn can link to their own shared or dedicated networks (Figure 2.23). Figure 2.23 depicts a six-port configuration that is dual redundant, the lower ‘ghosted’ network being a replica of the upper network. Although functionally this appears as a network in the figure, in practical terms it will probably be packaged as a module which can be located in an integrated modular cabinet with the other buses or systems being hosted within the same cabinet.

2.4.2 Fibre Channel Options

There are many ways in which the FC may be implemented and products are being offered by a range of vendors. At the time of writing, four main implementations appear to be attracting the most interest:

  • StarFabric;
  • Rapid IO;
  • Infiniband;
  • 100/1000 Gbit/s Ethernet.

Of these, StarFabric has been selected for applications on the joint strike fighter (F-35). Figure 2.24 shows an eight-port StarFabric switched fabric incorporating Quad PC processing.

2.4.3 IEEE 1394 Firewire

IEEE 1394 firewire is a widely used data bus scaleable in its original form from 50 to 400 Mbit/s. It has an extremely wide market capture, being commonly used in the electronic domestic consumer market: video cameras, etc. This marketplace has also paved the way for IEEE 1394 to be widely applied in civil aircraft in-flight entertainment (IFE) systems.

Figure 2.24 Eight-port StarFabric switched fabric module.

A significant disadvantage of the baseline standard is that it utilises a daisy-chain architecture to connect the network devices together. Like the arbitrated loop configuration already described, it is therefore unable to tolerate failures by the nodes or the transmission media and is not an attractive option for avionics applications.

Later versions developed under the IEEE 1394b standard are able to work in a network form up to 800 Mbit/s, and there are reports that this standard has been adopted for interconnecting portions of the vehicle management system (VMS) on the F-35.

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.
  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 redundancy, 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−9 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−3 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 certification, the industry effectively uses it as a de facto requirement. There are several reasons why the military avionics community should adopt the standard:

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
  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.3 Summary of the applicable failure severities

Failure severity Probability Analytical
Catastrophic Extremely improbable Less than 1 × 10−9 per flight hour
Hazardous Extremely remote Less than 1 × 10−7 per flight hour
Major Remote Less than 1 × 10−5 per flight hour
Minor Reasonably improbable Less than 1 × 10−3 per flight hour

Figure 2.25 Software and hardware integration.

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 programming 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.

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 processor 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 assurance 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.

Figure 2.26 Integrity and security partitioning.

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.

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.

Figure 2.27 First-generation analogue system – 1950s.

Figure 2.28 Integrated system – 1960s and 1970s.

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.

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 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.

Figure 2.29 Integrated avionics architecture.

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 joint advanced strike technology (JAST) program embraced a number of study and technology demonstrator programs to identify technologies suitable for the JSF and reduce risk where possible.

The JAST architecture highlighted the adoption of a number of technologies to aid systems integration, but perhaps the most innovative was the concept of using shared apertures and antenna, as shown in Figure 2.30, as well as a modular approach to the rest of the RF architecture. Much of the material gained from the JAST studies, combined with experience gained from the JIAWG and the F-22 Raptor, will be embodied in the F-35 joint strike fighter program. For more information, see the Joint Advanced Strike Technology Program Avionics Architecture Definition of 8 August and 9 August 1994.

2.6.2 JIAWG RF Subsystem Integration

The RF integration on the F-22 using the JIAWG architecture is indicative of the conservative state of the art 10 years ago when the F-22 program entered the engineering manufacturing and development (EMD) phase. The aim was to have a highly capable radar, EW and CNI suite that would enable the aircraft to survive and prosecute its mission in a high-threat environment, and to do so using stealth techniques. The resulting architecture and equipment suite, driven particularly by the need to carry all sensors and weapons internally to preserve stealth, led to a more complex system than other contemporary ‘fourth-generation’ fighters which, although being very capable in their own right, could not satisfy all the requirements of the F-22 mission. These aircraft do not have as comprehensive an avionics system, often needing to add additional ‘podded’ sensors for specific roles and carry weapons externally.

Figure 2.30 2000 + integrated architecture with shared apertures.

The major RF subsystems on the F-22 are regarded as separate entities containing dedicated RF processing, although signal processing and mission data processing is integrated within the CIPs. These subsystems are:

  • Active electronically scanned array (AESA) radar;
  • Electronic warfare (EW) suite;
  • Communications, navigation and identification (CNI) equipment.

Figure 2.31 depicts the F-22/JIAWG architecture, with these sensor subsystems and centralised processing functions highlighted.

Table 2.4 has been compiled with the help of the Joint Advanced Strike Technology Program Avionics Architecture Definition of 8 August 1994 and 9 August 1994. It is representative of the JIAWG/F-22 implementation and serves the purpose of demonstrating the RF architecture integration advances over the past decade or so.

Figure 2.31 F-22/JIAWG top-level avionics architecture.

Table 2.4 Summary of JIAWG apertures

Number System Type Elements Band (GHz) Location Functions
1 Radar AESA 2000 8–12 FWD Radar, active and passive targeting
2–7 EW Spiral 1 2–18 FWD Port and STBD AFT PORT and STBD TOP/BOT Radar warning receiver (RWR)
8–13 EW LP 1 2–6 WATERLINE ECM TX
14–19 EW LP 1 6–18 WATERLINE ECM TX
20–21 EW Spiral 1 2–18 TOP/BOT ECM RX
22–33 EW Spiral 1 2–18 6 PORT
6 STBD
Situational awareness (SA); Fwd sector – two arrays, each uses 1 RWR element: Az and El DF
34–35 CNI Slot 1 5 FWD-BOT AFT-BOT Microwave landing system (MLS)
36–43 EW Spiral 1 0.5–2 4 PORT
4 STDB
SA; fwd sector – two arrays, each uses RWR element: Az and El DF
44–45 CNI Linear array 8 1–1.1 FWD PORT FWD STDB IFF interrogater
46–47 CNI Slot 1 1–1–1 TOP/BOT IFF transponder
48 CNI Slot 1 0.9–1.2 TOP/BOT TACAN/JTIDS
49–52 CNI Slot 4 1.2–1.5 TOP GPS
53 CNI Slot 2 0.1–0.33 BOT ILS glideslope ILS localiser
54 CNI Slot 1 0.076 BOT ILS marker
55 CNI Slot 1 0.2–0.4 TOP UHF-SatCom
56 CNI LP 1 15 FWD BOT Special communications
57–59 CNI AESA 100 10 FWD PORT WING FWD STBD WING TAIL Common high-band data link (CHBDL)
60–62 CNI AESA 64 Class FWD PORT WING Cooperative engagement capability (CEC)
FWD STBD WING
TAIL
63–64 CNI CNI Ferrite 0.002–0.03 PORT/STBD HF Comm; Link 11

Note: CNI omnidirectional antenna in italics are not shown in Figure 2.31.

Table 2.4 identifies all the apertures – 64 in all – and gives a brief summary of the subsystem, type of antenna, number of active elements, frequency band (GHz) and location, and a brief summary of the associated function. A diagrammatic portrayal of these apertures – ignoring the omnidirectional antenna for clarity – is shown in Figure 2.32.

Figure 2.32 JIAWG RF aperture architecture.

The capabilities that this assembly of apertures offer, together with the appropriate electronics units, are summarised below:

  1. The AESA radar provides active and passive targeting. This includes ∼ 2000 active transmit/receive (TR) elements. The AESA radar is addressed in Chapter 4.
  2. The electronic warfare (EW) suite uses arrays to provide:
    • Radar warning and situational awareness (SA) around the aircraft using a combination of spiral antennas over the 0.5–18 GHz frequency bands. A total of 24 spiral antennas are located around the aircraft to provide full spherical coverage for any RF source and provide direction-finding capabilities for the detected signals.
    • Jamming directed at the aircraft is sensed by a further two spiral antennas. The aircraft can, if desired, respond by transmitting electronic countermeasures in the 2–12 GHz bands using a total of 12 log periodic (LP) antennas located on the water-line.

    The principles of EW are described in Chapter 6.

  3. The CNI functions are addressed by a total of 21 slot, linear array, LP, ferrite and phased array antennas that provide the aircraft CNI capability:
    • microwave landing system (MLS) – 2;
    • IFF interrogator – 2;
    • TACAN/JITDS – 2;
    • GPS – 1 array with 4 elements;
    • ILS glideslope, localiser and marker – 2;
    • UHF SatCom – 1;
    • Common high-band data link (CHBDL) – 3;
    • Cooperative engagement capability (data link) – 3;
    • HF communications and Link 11 – 2.

    The principles of CNI equipment are described in Chapter 7.

  4. The electronics units associated with these apertures are:
    • Rf integrated racks to provide the RF amplification, detection and signal demodulation for incoming signals and the modulation and power amplification for outgoing signals. In this architecture the RF ‘front end’ is dedicated to each subsystem.
    • Low-noise amplifiers (LNA) located throughout the aircraft to amplify signals before transmission to the RF racks.
    • Travelling wave tube (TWT) amplifiers to provide power for EW countermeasure transmissions and IFF transmitters for the IFF interrogator.

Figure 2.33 does not portray the full picture. In order to secure the best unimpeded fields of view, many of the apertures need to be located on or near the aircraft extremities. To illustrate this fact, Figure 2.33 shows the provision of the CNI apertures (upper aspect) for the F-22. This gives a true impression of the complexity of installing a highly capable system while abiding by the constraining factors that are imposed by the need for the aircraft to remain stealthy commensurate with its mission.

The situation with regard to the EW apertures is equally if not more complex. Figure 2.34 indicates a further aspect of distributing apertures in this manner. Many apertures need dedicated power supplies provided locally and the provision of LNAs for many functions. The RF signals that are gathered by the arrays have to feed through the aircraft to the integrated RF racks using coaxial wiring to avoid undue signal attenuation. The fact that the EW suite also embodies wide-band transmitters to provide radiated electronic counter-measures is a further complicating factor.

Figure 2.33 F-22 CNI apertures (upper aspect).

Figure 2.34 F-22 EW apertures.

2.7 Pave Pace/F-35 Shared Aperture Architecture

One of the objectives in developing the Pave Pillar architectures was to address the RF functional area and seek rationalisation of the receiver and demodulation and modulation and amplification/transmitting functions. In the JIAWG architecture above these are handled on a subsystem basis, and the aim of Pave Pace is to provide an integrated RF sensor system – sometimes called an integrated sensor system (ISS). The sharing of resources between the functional system can enable significant savings in cost, weight, volume and reliability. Studies have quantified these savings by comparing a third-generation ISS (JIAWG) with a fourth-generation version (Pave Pace) as shown in Table 2.5.

The basis of a fourth-generation RF ISS is shown in Figure 2.35. The primary arrays may typically comprise a large active array: multiarm spiral arrays (MASAs), slot arrays and multiturn loops (MTLs). These arrays are connected via an RF interconnect to a collection of receive frequency converters that convert the signal to intermediate frequency (IF). The IF receive signals are fed through an IF interconnect to the receiver modules. After detection, the baseband in-phase (I) and quadrature (Q) components are fed through the fibre-optic interconnect to the integrated core processing.

For transmission the reverse occurs, signals are passed to the multifunction modulators and through a separate IF interconnect to the transmit frequency converters. After modulation and power amplification the output signals are passed via the RF interconnect to the appropriate array(s). It is the sharing of these functions within a common RF host that enables the major savings to be made. In the comparison given above it is estimated that about a third was achieved by the use of more advanced components and improved packaging while the remainder came from the integration process.

The JAST documentation already mentioned produced the Pave Pace equivalent of the JIAWG RF architecture shown in Figure 2.32 and expanded in Table 2.4 above.

Figure 2.36 shows the rationalisation of apertures that can be gained from a fourth-generation integrated system, totalling 22 apertures as opposed to 64 apertures for its predecessor. Table 2.6 lists and groups these apertures by function.

Table 2.5 Comparison of third- and fourth-generation RF integrated sensor systems

Fourth-generation RF ISS Third-generation RF ISS
Cost* ($) 3.9 million 7.9 million
Weight (lb) 500 1245
Volume (ft3) 8 16
Reliability (h) 225 142

* 1989 US dollars.

Source: Reference 2 in JAST report.

Figure 2.35 Pave Pace integrated RF architecture.

Figure 2.36 Pave Pace – shared aperture RF architecture.

Table 2.6 Pave Pace aperture listing

Number System Type Elements Band (GHz) Location Functions
1 Radar, EW, CNI WBSA 3000 6–12 FWD A/A and A/G radar, RWR, ECM, SA, passive targeting, CHBDL, weapon data link
2,3 EW, CNI WBSA 200 6–18 PORT WING – AFT STBD WING – AFT RWR, ECM, SA, passive targeting, CHBDL
4–6 EW, CNI WBSA 64 2–6 PORT WING – FWD STBD WING – FWD TAIL – AFT RWR, ECM, SA, data link, MLS
7–8 EW Spiral 1 2–18 TOP/BOT RWR, ECM receive
9–12 CNI MASA 8-ARM 0.2–2 2 TOP 2 BOT UHF radio, GPS, have quick, glideslope, JTIDS, TACAN, IFF transponder, TCAS (functions spread among four apertures to match coverage and functional mix)
13–14 CNI MASA 8-ARM 0.2–2 TOP/BOT IFF interrogator
15–16 Radar, EW MASA 8-ARM 0.2–2 PORT/STBD RWR, SA, ECM, SAS
17–18 EW, CNI MTL 1 0.03–0.2 TOP/BOT VHF radio, SINCGARS, self-protect
19–20 EW, CNI MTL 1 0.03–0.2 BOT VOR, localiser, marker beacon, self-protect, SINCGARS, VHF radio
21–22 CNI MTL 1 0.002–0.03 PORT/STBD HF Comm, Link 11

Note: CNI HF Comms/Link 11 antenna are not shown in Figure 2.36.

It can be seen that there is considerable rationalisation compared with the previous architecture, particularly in terms of rationalising functions: Radar + EW, EW + CNI, etc. The AESA has been replaced by a wide-band synthetic array (WBSA) (number 1 in Table 2.6) containing ∼ 3000 elements that services radar, EW and CNI functions. Five similar but smaller arrays provide forward (numbers 4 and 5), rear (numbers 2 and 3) and aft (number 6) coverage for EW and CNI usage. A variety of spiral, MASA and MTL antennas provide the entire gamut of EW and CNI equipment coverage as described in Table 2.6.

References

ARINC Specification 429: Mk 33 digital information transfer system, Aeronautical Radio, Inc., 1977.

ARINC 653, Avionics application software standard interface, Aeronautical Radio Inc., January 1997.

AIR4271 – Handbook of system data communication.

AIR4288 – Linear token passing multiple data bus user’s handbook.

AS4290 – Validation test plan for AS4074.

Guide to digital interface standards for military avionic applications, Avionic Systems Standardisation Committee, ASSC/110/6/2, Issue 2, September 2003.

Joint Advanced Strike Technology Program, avionics architecture definition – issues/decisions/rationale document, Version 1, 8 August 1994.

Joint Advanced Strike Technology Program, avionics architecture definition – appendices, Version 1, 9 August 1994.

MIL-STD-1553B digital time division command/response multiplex data bus, Notice 2, 8 September 1986.

Moir, I. and Seabridge, A.G. (2004) Design and Development of Aircraft Systems – An Introduction, Professional Engineering Publishing, ISBN 1-86058-437-3.

Pallet, E.H.J. (1992) Aircraft Instruments and Integrated System, Longman, ISBN 0-582-08627-2.

RTCA DO-178B, Software considerations in airborne systems and equipment certification.

UK Def Stan 18-00 Series.

Wilcock, G., Totten, T. and Wilson, R. (2001) The application of COTS technology in future modular avionics systems. Electronics and Communications Engineering Journal, August 2001.

Wooley, B. (1999). The Bride of Science – Romance, Reason and Ada Lovelace, Macmillan.