Defence Science Journal, Volume 63, Issue 2 , March 2013, pp. 192-197
DOI : 10.144029/dsj.63.4263
© 2012, DESIDOC
Received 15 September 2012, Revised 08 February 2013, Online published 23 March 2013
A Blue Print for the Future Electronic Warfare Suite Development
Mastering increasing complexity of electronic warfare (EW) airborne equipment systems needs new architectural concepts mainly based on modular design, generic resources and reliable communication buses. Less is more architectural concept replaces separate EW line replaceable units with fewer centralized processing units. This approach leads to a robust architecture for the next generation EW suite development in a unified fashion and thereby promising significant weight reduction and maintenance savings. In general, this approach is represented by a blanket term called integrated modular avionics (IMA). IMA architecture based EW suite development concentrates with the main goals of IMA such as technology transparency, resource sharing, incremental qualification, reduced maintenance cost, and so on.
This paper explains the approach to develop an unified electronic warfare (EW) suite that transforms various LRUs performing different EW functions into a single line replaceable module (LRM) with the concept of lower size, weight and power (SWaP) higher modularity and bigger supportability for open standards that promotes the public, commercially off-the-shelf (COTS) standards for communication and computation resources development against the proprietary standards.
The techniques and technologies that led to the construction of devices capable of electronically identifying and countering a weapon system and also to the development of counter-countermeasures go under the name ‘Electronic Warfare’. The main electronic defense systems that perform the functions of electronic warfare has been controlling /using the electromagnetic spectrum and they are broadly classified into the following categories1:
Electronic support (ES) which supplies the necessary intelligence and threat recognition to allow effective attack and protection. The main objective is tactical interception. It allows commanders to search for, identify and locate sources of intentional and unintentional electromagnetic energy.
Electronic attack (EA) which applies the use of electromagnetic energy to prevent or reduce the effective use of the electromagnetic spectrum by hostile forces through jamming and deception. Deception is central to electronic attack.
Electronic protection (EP), which ranges from designing systems resistant to jamming, through hardening equipment to resist high-power microwave attack, to the destruction of enemy jammers using anti-radiation missiles.
Based on the above classification, the EW suite for any combat platform with the full EW capability has the subsystems as shown in Fig 1.
Figure 1. The existing EW suite architecture.
Radar warning receiver (RWR) – it is a passive system (i.e., reception of electro magnetic (EM) spectrum) that detects the weapon radar in terms of its parameters and provides warning to the pilot.
Electronic support measures (ESM) – it is a passive ES system (only reception of EM spectrum) that has the feature of high probability of interception and processing of RF signals in support of tactical military operations with the current picture of electronics order of battle (EOB) and electronic intelligence (ELINT).
Missile approach warning system (MAWS) – it is a passive system (only reception of EM spectrum) that detects and tracks an incoming missile’s hot plume as it appears within a protective sphere surrounding the aircraft. The MAWS system discriminates between threatening and non-threatening missiles, by evaluating the missile’s trajectories.
Laser warning system (LWS) – is a passive system (only reception of EM spectrum) that is designed to detect, track and warn of hostile laser sources aiming at the platform.
Jammer - is an active system (receives and transmits the signal) that generates noise and deception jamming techniques to either deny threat system automatic tracking capability or generate sufficient tracking errors to prevent a successful engagement.
Decoy – Towed decoys are designed to defeat enemy missiles in the final stages of an engagement.
Chaff – Ribbon-like pieces of metallic materials or metalized plastic that are dispensed by aircraft to mask or screen other aircraft or to cause tracking radar to break lock.
Flares – are the primary countermeasure used to defeat the IR missile which has the ability of the IR missile seeker to discriminate between the IR signature of the aircraft and the IR signature of background interference.
Infrared counter measure (IRCM) – it is an active system that can reduce the effectiveness of IR threat systems. The first is to reduce the intensity of the heat signature of the aircraft by reducing the power setting.
Flares rejection unit (FRU) – it is the counter-countermeasure device which is capable of rejecting the flares.
RDR-EP (RADAR_EP) is a counter-countermeasure device which is built with the features of radar receiver protection, jamming avoidance, jamming signal exploitation, overpowering the jamming signal.
The general tendency towards the increase in these EW systems complexity has some major side effects on the aircraft cost all along its life cycle in terms of development (number of different equipment), maintenance (number of alternative equipment), and evolution (equipment specificity, technology dependence), performance, etc. To answer this pitfall in the existing EW suite model, an evolution is required.
An innovative architecture is needed to master the complexity. The proposed architecture is ‘Less is More’ architecture, in other words integrated modular avionics (IMA) architecture. Figure 2. gives a statistical data about the historical background for the emergence of IMA3. From this figure it is clear that the exponential increase of the application SW code made the demand for signal interfaces between the systems into highly raised quantities which were beyond imagination some years ago, i.e. in 1960s in comparison with 2005 and this tremendous increase brings out the need for IMA.
Figure 2. Emergence of integrated modular avionics.
Integrated modular avionics (IMA) architecture allowed the aviation industry to transit from the federated architecture where one LRU, means a dedicated equipment, i.e., one LRU = one function. This dedicated LRU concept has hit its natural limit when the functions of the aviation industry increased to a great height. Each of the LRUs and the communication between them becomes the most critical issue of higher looming volume, electrical interface complexity and physical maintenance. Hence the transition is into the IMA architecture that potentially leads to a concept that integrates multiple avionics functions housed in a single integrated computing environment called line replaceable module (LRM) i.e. one LRM = Multiple functions.
IMA was first presented by Honeywell for cockpit functions on the Boeing 777 aircraft in 1995 which featured a modularized cabinet packaging. Figure 3. illustrates the example of the federated and IMA architecture4.
Figure 3.Sample Federated & IMA architecture. Components of a rule based system.
From the above figure it can be easily understood that the IMA architecture optimizes the computing resources
The IMA architecture based requires high speed through-put, modularity, rapid reconfiguration, and an open architecture. In order to achieve these goals, the following are the major considerations:
As the processing requirements of the computing element in specific to the aviation industry is rapidly growing, in the order of MIPS/TFLOPS, the IMA based system shall be based on high speed/multi-core modular processors. These processors shall be able to communicate through a point-to-point high speed links and to the external systems through a deterministic, low latency switch fabric network, preferably as specified in ARINC664 (Aeronautical Radio Inc. 664) standards,
The modularity shall be incorporated through a robust functional partitioning in terms of both time and space. As the IMA based system always represents the system of systems (SoS) architecture, the functional partitioning is extensively supported by the use of ARINC653 specifications. For more details on the behavior of these partitioning, refer the specifications by Rushby5.
The modularity design in turn provides expansion for functional reconfiguration through the incorporation of replaceable computing resources. A reconfigurable IMA based system shall be able to change the configuration of the platform by moving applications hosted on a faulty computing hw/sw module to spare or other computing hw/sw modules rapidly, non-transparent to the user. The reconfigurable feature increases the system availability and also induces the other major feature of the IMA architecture which is the resource sharing.
Finally the open architecture shall be through the use of standards and COTS in the entire IMA system development, i.e. in hardware, software, and system packaging. The hardware will comply with open standard form factors and support standard chassis interfaces making them interchangeable for higher reliability and maintainability. The software will comply with the open standard APIs. The open architecture also provides the extent support for future growth/scalability.
Towards the packaging of the system, the high density packaging is recommended for optimizing the SWaP. Also the standardised backplanes shall be used for the internal communication
With all these system development considerations, the key benefits of IMA can be summarized as:
- Optimizes the resource allocation
- Optimizes SWaP
- Increases the development efficiency
- Promotes multiple independent levels of security (MILS)
This section explains the approach for the development of IMA based unified EW suite (UEWS) architecture.
The main principle of standardisation applied for the UEWS architecture is combining computing as well as input and output functions to produce a standardised UEWS.
The UEWS architecture shall be defined in mainly by two main computing platforms called EW core computing system (ECCS) and a common remote data concentrator (CRDC).
The ECCS performs the functions of more than one EW subsystem functions like ES, EA, and EP. The multiple functions of EW subsystems will be performed by high-speed processors. The processor boards are general single board computers (SBC) supporting specific communication interfaces required for EW subsystems functioning. The specific communication interfaces are realized through the use of mezzanine cards. The mezzanine cards will be like 1553B, ARINC429, A&D, graphics processing module (GPM), mass memory module (MMM),network support module (NSM), etc. The ECC system hosts more than one SBCs and the no. of SBCs is highly based on the EW subsystem functions that are being performed by the ECCS. The details on SWaP are not detailed in this paper.
The CRDC concentrates data from the associated EW sensors and then communicates this data to the ECCS system. Using new technologies such as high speed communication interfaces/optical interfaces, the CRDC replaces a significant number of input/output units previously specific for each on-board application. Both the ECCS and the CRDC systems will communicate over the IMA recommended ARINC664 based communication network6. Fig 4. depicts the system architecture of UEWS.
Figure 4. The UEWS system architecture.
- Application layer (AL)
- OS support layer (OSAL)
- Module support layer (MSL)
The implementation of this architecture as recommended in IMA is easily achievable with the use of ARINC 653 supported real time operating system (RTOS)7 as the platform development environment. The application layer represents the applications that are specific to a particular platform, but are independent of the enabling hardware. The OS support layer represents the system software usable across all hardware architectures. The module support layer represents the hardware specific software that allows the upper software layers to be hardware independent.
The interfaces between these layers are as mentioned in the Fig 5.
Figure 5. The UEWS SW architecture -interaction between the layers.
Further, this section details the application layer which brings the UEWS functions. The major design thrust in this layer is the functional partitioning. The main domains considered for the partitioning are memory space, computation time, I/O access and backplane access and hence each partition is assigned with the dedicated h/w resources. Using ARINC653 supported RTOS as the platform development environment, the I/O and the inter-application (partition) communication is established well through the off-line system configuration tables. These tables are managed by the platform software, i.e. by the OS Support Layer. The use of these offline table driven approach will maintain the system control and data movements between the applications effectively and reliably. As already mentioned, the basis for partitions defined in the ECCS is the functional partitioning. i.e., the main partitions are based on the EW subsystem functions. Also the other partitions defined are general prognostics health monitoring and I/O Handling for avionics communication, maintenance/monitor mode handling, etc. The unification of all these EW subsystems data is handled by a special partition called core computing where the data fusion is performed. This partition is responsible for processed data from each of the specific EW function partition and the fused data will be transferred to the respective avionics systems for further processing/pilot vehicle interface (PVI) processing.Figure 6. explains the detailed SW architecture of the ECCS.
The standardisation for the UEWS will be further extended in packaging of the UEWS in terms of size, power, construction material, cooling method and environmental attributes etc., as demanded by IMA development considerations.
Figure 6. The UEWS SW architecture.
The reconfiguration of the system will be achieved at both system level and at partition level. The full mesh network capability implemented in the system, indicated in the Fig 7. shall provide the spare/other computing module, the capability of handling the specific function of the failed module. Similarly, the failed partition will be restarted based on the criticality of the function as defined in the configuration table or will be handled by the spare/other partition, preferably in the degraded mode of operation. This kind of reconfiguration is achieved by a specific firmware solution called reconfiguration supervisor.
Figure7. The reconfigurable architecture. through PMR .
Triggering the reconfiguration which continuously monitors the fault detections
Selection of the configuration
The allocation of the supervisor function to the computing module can be a centralized/distributed solution. The concept of supervisor is adopted from the IMA architectures defined in the European SCARLETT project8.
Looking at the philosophy of the testing of UEWS-ECCS, the Incremental Qualification method will be adopted as per the recommendations detailed in RTCA, DO-2979.
This section exclusively discusses in brief about the challenges in IMA system development. The most important one is, the understanding the dependencies between applications due to resource sharing which results in an indirect dependencies. Hence the partitioning in terms of space and time are the major challenges in designing the IMA system. The next important concern is the reconfiguration capability in order to limit the effect of failures. A detailed failure hazard analysis (FHA), failure mode effect analysis (FMEA) and system safety analysis (SSA) should be carried out and the appropriate control parameters for reconfiguration should be defined. Another important challenge lies with the use of ARINC 664 based Avionics Full Duplex (AFDX) network switches in terms of defining the scheduling and network analysis etc.
Further the challenges continue during the certification process of the IMA system. As per the DO-297 specification, the major challenges lie in the definition of integration stages for incremental qualification
Currently DARE is in the process of implementing the IMA architecture development over the Mission Computer as well as the EW Core Computing System. As the IMA standard supports extensively the modularity and the incremental development, the IMA based UEWS development in DARE focuses with the incremental development of the following EW functions in the ECCS such as
RWR, ESM, MAWS functions as a part of ES functions
ECM functions as a part of EA functions
Highly flexible and versatile computing architectures are needed to meet the ever-changing EW mission needs with cost-effective and high speed through-put processors. The system can be enhanced for its high-speed computing requirements as a system based on multi-core modular processors with high bandwidth electromagnetic interference (EMI) protected data busses. These data busses shall need to support integrated data integrity, multi-level and have expansion options that will support multiple and future protocols. One such option for data buses are with dense wave division multiplexing optical bus technology (DWDM)10. The common processors may also be implemented as lock-step processors to achieve better redundancy. Impact on the use of DWDM buses in comparison with the other buses are studied. Figure 8. shows benefits of multi-core processors in high-performance computing11. A simple illustration can be taken from the use of dual core of the 2.0 GHz processor which increases the computing performance from 4 to 10 GFOPS.
Figure 8. Multicore system performance.
The technological growth of avionic systems has outpaced the service-life of aircraft, resulting in avionics upgrade as a preferred cost-effective option to new design, based on the IMA. IMA being the cost-effective solution providing a numerous key benefits like technology transparency, reduced maintenance cost, resource sharing, etc., the design may be adopted across the airborne EW system development
The authors would like to thank Director, Defence Avionics Research Establishment for his support towards the completion of this paper effectively
1. Grant, P.M. & Collins, J.H. Introduction to electronic warfare. IEE Proc. F : Comm., Radar Signal Process., 1982, 129(3), 113-32.
2. Electronic Warfare Fundamentals, An Open Source literature, a Student Supplement, Rel. Nov 2002, DSN: 682-4897
3. FAA. Integrated modular avionics hardware elements.TSO-C153, FAA, May 6, 2002.
4. Watkins, C. & Walter, R. Transitioning from federated avionics architectures to integrated modular avionics. In the Digital Avionics Systems Conference, 2007. DASC’07. IEEE/AIAA 26th, Oct 2007,pp.2.A.1–1–2.A.1–10.
5. Rushby, John. Partitioning in Avionics architectures: requirements, mechanisms, and assurance. FAA Technical Center and NASA Langley Research Center, Technical Report No. Contract NAS1-20334, March 1999.
6 AEEC. Aircraft Data Network. ARINC Specification 664P7. Annapolis, Maryland, Aeronautical Radio, Inc., June 30, 2006
7 AEEC. Avionics Application Software Standard Interface.ARINC Specification 653
8. ASAAC Consortium - ASAAC final draft of proposed guidelines for system issues - volume 4: System configuration and reconfiguration. 2004. http://www.scarlettproject.eu/ (Accessed on 12/01/2013)
9. RTCA DO-297/EUROCAE ED-124 : Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations. eBook ISBN: 978-0-8493-8442-4
10. Sutterfield, Brian. Hoschette, John A. & Anton, Paul.Future integrated modular avionics for jet fighter mission computers. In the Digital Avionics Systems Conference, 2008. DASC ’08. IEEE/AIAA, 26 Oct. 2008. pp.1.A.4-1 to 11
11. Mark, T. & Chapman. IBM Systems and Technology Group. The benefits of multi-core processors in high speed computing. In Supercharging your high performance computing, seminar, June 2005, , http://ibm.com/legal/copytrade.shtml. DOI : XSW01277-USEN-00.