Development Of Framework For Acquisition Of Avionics Integration Capability
Development of Framework for Acquisition of Avionics Integration Capability
Fahad RIAZ*
*Corresponding author
Pakistan Aeronautical Complex, PAC Kamra, District Attock
[anonimizat]
DOI: 10.13111/2066-8201.2015.7.4.X
Received: 09 October 2015 / Accepted: 10 November 2015
Copyright©2015 Published by INCAS. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
The 36th “Caius Iacob” Conference on Fluid Mechanics and its Technical Applications
29 – 30 october, 2015, Bucharest, Romania, (held at INCAS, B-dul Iuliu Maniu 220, sector 6)
Plenary lecture
Abstract: With the rapid advancement in electronics technology, Avionics systems, in the last three decades, have evolved from standalone single function units to functionally correlated and interdependent systems. To harness the potential of this technological growth in the constraints of time, power and space, the specialty of Avionics Integration has emerged. Avionics Integration Technology is a multi-faceted discipline involving a myriad of activities starting from design conception and concluding on final qualification and acceptance of the avionics suite. Currently, a select few countries in the world possess this technology and no formal framework has been defined in literature or journals that encompass the range of activities involved in avionics Integration. This paper will present a formal framework required for development of Avionics Integration Capability. It will cover the core skill areas required and their interdependencies. The recognized “V” Development model will be presented with complete identification of Integrator and Sub Contractor roles and responsibilities. For the technical execution of Avionics Integration, specialist domains will be identified along broad definition of required tool sets and work flow of activities to be conducted.
Key Words: Avionics Integration, Avionics Systems, 1553B Integration, Mission Computer, Avionics Dynamic Simulation, Man Machine Interface Design Engineering.
1. INTRODUCTION
‘Avionics’ is a word derived from the combination of Aviation and Electronics [1]. The term ‘Avionics Subsystem’ means any system in the aircraft which is dependent on electronics for its operation. The range of modern avionics subsystems in military aircraft vary from simple single board computers to complex RF sensing Radar and Electronic Warfare Systems. An ‘Avionics System’ is broadly defined as a collection of Avionics Subsystems that display characteristics as shown in Fig 1 [2].
Fig. 1 – Avionics System as a system of subsystems
In this functional spacing, the total system lies at top of the pyramid however it is dependent upon all the lower level sub-systems, modules and components. Conversely, the large collection of lower level components, modules and subsystems serve the singular aim of working coherently for fulfilling the requirements of the total system. A typical product breakdown of a modern military avionics system is shown in Fig 2 [2].
Fig. 2 – Typical product breakdown of a Military Avionics System
Collaborated and coherent inter-relationship of all the subsystems and modules in the constraint of space and cost optimization is paramount for the success of a military avionics system. As the historically proven law: “Complexity of structure goes hand in hand with the division of labor”, avionics integration domain serves to systematically distribute and divide the functional labor between subsystems, modules and components, resulting in an overall system of systems that can sustain the harsh combat environment and fulfill its designated role.
2. EVOLUTION OF AVIONICS INTEGRATION
Avionics integration domain has evolved out of need to cater for the diminishing boundaries between major aircraft and avionics subsystems and to gain deterministic control over the inter-relationship of such highly complex and inter dependent systems.
Historically, 1st Generation aircraft were developed just after second world war and had independent systems for each function thus exhibiting simple subsystems working without any integration (as was not required). The 2nd Generation Aircraft saw rapid technological jump in terms of avionics, resulting in Navigation systems like TACAN and combat technologies like Radar, Radar Warning Receivers and Heads Up Displays. These technologies necessitated primitive integration thus resulting in emergence of first generation of Mission Computers. The computers would serve as data centers that collected all sensor information for display to the operator through point to point communication channels. As the computing technology gained pace in 1970s, airborne mission computers were designed to do more complex functions like target tracking and weapons aiming algorithms. However, the industry would soon start to face weight and space issues caused by the complex network of wires and cables required to ensure communication of all sensors and displays with the mission computers. To counter these constraints, 3rd Generation aircraft evolved with the concept of data-buses that would replace all point to point communication with a standard time division multiplexed data channels. Industry standards in the form of MIL-STD-1553B and MIL-STD-1760C served as forerunners in the databus concept and are still being widely used as the communication backbone of an integrated avionics system. Such 3rd generation aircraft with integrated avionics systems are still being developed in large quantities and used by almost all Air Forces in the world. Latest advancements in avionics aim to take the concept of avionics integration to its next level by introducing the concepts of common computing and integrated modular avionics (IMA). In such 4th Generation initiatives, all computing (sensors and mission management) is combined in a common computer thus utilizing modern computing technologies to their fullest. Moreover, modular computing modules for various aircraft functions can be plugged into a common box thus minimizing on required space and eliminating any duplication or wastage of computing capability.
This evolution of avionics integration from standalone subsystems to latest concepts of IMA has been driven by advancements in computing technologies and the need to save on space and power requirements so as to make the platform effective in combat environment. Fig 3 [2] presents this evolution in a pictorial form along with all its associated factors.
Fig. 3 – Evolution of Avionics Integration
3. AVIONICS INTEGRATION: MISSION DRIVEN DESIGN
Avionics system design initiates from clear definition of the mission requirements of the host aircraft. Thus the aircraft and its mission roles drive the avionics system design. The top level inputs of host aircraft and mission requirements are decomposed to understand their impact on avionics system design. In general, the avionics system is required to carry out following basic functions in any military aircraft [3]:
Enhance situational awareness of pilot,
Enable detection and engagement of targets,
Enable external communication,
Enhance aircraft survivability,
Provide navigation support.
Apart from the basic functions required out of any integrated avionics system, standard mission specific roles defined in military aircraft include the following:-
Air superiority role,
Ground attack role,
Strategic bombing role,
Maritime patrol role,
Battlefield surveillance role,
Airborne early warning role,
Electronic warfare role.
Each role has its own peculiar requirements, that must be met through an optimized avionics integration design. It is pertinent to mention that while the basic components, modules and subsystems remain more or less common, it is the integration design that ensures mission specific role is given to the whole system. As an example, the requirements and architecture for the roles of Air superiority and ground attack are compared in Fig 4 [4].
Fig. 4 – Comparison of Air Superiority and Ground Attack Roles
4. AVIONICS INTEGRATION: CONSTRAINTS
Avionics system varies drastically from ground based equipment of similar functions. The fundamental reasons for these differences include but are not limited to the following:
The importance of achieving minimum weight.
The adverse operating environment in military aircraft in terms of operating temperature range, acceleration, shock, vibration, humidity range and electro-magnetic interference.
The importance of very high reliability, safety and integrity.
Space constraints in military aircraft requiring an emphasis on miniaturization and high packaging densities.
The design is therefore made as a compromise between the extremes of fulfilling all mission requirements against staying within the bounds of constraints such as space, weight, power requirements, cost and timelines.
5. AVIONICS INTEGRATION: BUILDING BLOCKS
All military Avionics systems, independent of their role, must contain basic building blocks, subsystems, in the following configuration:-
Mission Computers. Mission computers form the backbone of avionics integration design and ensure fulfillment of mission specific roles through optimum design, architecture and communication scheme. Mission computers may be hard partitioned into various computers depending on role and computing power available at the disposal of integrator. Various types of mission computers include:
Mission Management Computers,
Weapons Management Computers,
Aircraft Systems Management Computers,
Flight Management Computers,
Fuel Management Computers,
Display Management Computers,
Electronic Warfare Management Computers,
Databus Management Computers,
Man Machine Interface Systems. All avionics integration design is focused towards assisting the pilot in performance of aircraft role therefore, display and input devices must also be defined concisely in the avionics integration design. These devices normally include:
HOTAS (Hands on Throttle and Stick),
MFD (Multi Function Displays),
HUD (Heads Up Displays),
HMD (Helmet Mounted Displays),
UFCP (Up Front Control Panel),
Light Warning System,
Audio Warning System.
Sensor Systems. Sensor systems embed specific hardware built for particular roles. These are primarily concerned with combat roles in which active and passive target detection and tracking is involved. Common sensor systems include:
Inertial Navigation Systems,
Pule Doppler Radar,
Radar Warning Receiver,
Infra Red Search and Track Systems,
Laser Designation Systems,
Self Protection Jammers,
Missile Approach Warning Systems,
Communication and Navigation Systems. Apart from the above mentioned sensors and mission computing systems that are specific to each platform, the communication and navigation systems are mostly generic and found in all modern military aircraft. These include:
UHF / VHF Voice Radios,
Identification of Friend or Foe System,
TACAN (Tactical Airborne Navigation),
ILS (Instrument Landing System),
Satellite Communication Systems,
Datalink Systems.
Databus Network. The mission computers along with sensors, displays and other avionics subsystems are connected through databus networks that ensure efficient communication and data exchange between them. Databus networks are also managed by mission computers and also fall in the critical area expertise of avionics integration. Various commonly used databus standards in military avionics systems include:
MIL-STD-1553B,
MIL-STD-1760C,
MIL-STD-1773.
Example architecture of F-16 C/D is shown in Fig 5 and illustrates an architecture built upon the MIL-STD-1553B databus with two mission computers, one for mission management and the other for stores management.
Fig. 5 – F-16 C/D Avionics Architecture
While the above architecture is a result of avionics integration design, it is important to realize that design and development of all the subsystems does not fall in the ambit of avionics integration. Avionics integration is rather focused on developing the requirements for every subsystem and defining the architecture. The main development in avionics integration revolves around software development of mission computers and development of software for display of vital information to the pilot through MFDs and SHUD. Details of the avionics integration design and processes involved will be presented in subsequent sections.
6. AVIONICS INTEGRATION DESIGN PROCESS
Avionics integration design process includes a myriad of varying activities, all focused towards achievement of a common aim of validating, verifying and qualifying an optimum system design that is accurately meeting the mission requirements and robust enough to sustain the harsh conditions of the platform. The integration design uses the fundamental building blocks defined in the previous sections. Some of these blocks like the sensors, Man Machine hardware and Communication systems are loosely controlled in avionics integration while others like mission computer and databuses form the core of avionics integration process.
In the simplest of form, avionics integration can be summarized as a “V” development model as shown in Fig 6. The design starts from the top left part of the “V” flowing down to the bottom in verification stages. The core part of system development lies at the bottom of the “V” while validation steps are undertaken on the right leg of the “V” on the way up. Each step of verification is interlinked with a corresponding validation step through test plans of different levels.
Fig. 6 – Generic “V” Development Model
Requirement Analysis. The integration design begins with requirement analysis of the avionics system and subsystems including databuses and pilot operating procedures viz a viz mission requirement framework. This requirement analysis caters for the constraints already covered in previous sections and must fall within the domain of possibility from all perspectives. Another important step is the requirement analysis for development of a full scale simulation facility or test bed for integration testing of the avionics system as a whole. The requirement analysis covers following main areas:-
Mission Computers Hardware and Software Requirements,
Sensors Requirements,
Databus Requirements and Simulation Analysis,
Acceptance Test Requirements for Avionics System,
Requirements for simulation facility / test bed.
Functional Specifications. The next step is to identify core subsystems required to be included in the architecture and lay down their functional specifications. Usually this includes development of technical specifications for all avionics subsystems planned in architecture. Moreover, basic specifications of the mission computer software called Operational Flight Program is also developed in this phase by the integrator. Another important step that integrator follows in this phase is to specify the details of communication databus for defined architecture.
High Level Design. Avionics system top level design is carried out in this phase. It includes the mission computer software design as well as the subsystem top level communication design. It is supported with an elaborate integration test plan to be undertaken on the earlier defined test bed / simulation facility.
Detailed Design. This phase usually includes development of communication design and Interface Control Documents for every avionics subsystem. Moreover, it also defines design of the integration simulation facility that would later be utilized to validate the avionics integration design. Various tools required for such validation are also defined in this stage.
Code/Development. This is the critical phase of the integration cycle where each sub-vendor develops its particular avionics subsystem based on design requirements specified in earlier steps while the integrator develops mission computer software (OFP) based on same requirements. In parallel the simulation facility development is also undertaken in this phase inclusive of test hardware and software.
Unit Testing. Unit testing phase includes stand-alone testing of each subsystem developed by sub-vendor to verify its performance and functionality. As the design requirements were laid out by avionics integrator, it is the responsibility of integrator to carry out this testing. On the OFP end, software test cases are developed to verify and validate the accuracy of developed OFP.
Integration Testing. This forms the most critical test phase where each individual subsystem is integrated with mission computer in the simulation facility. Using real world stimulus of the lab facility, the entire profile of flight is verified for both the subsystem and the mission computer OFP. Such testing and debugging usually results in errors that fall in one of the following three categories:
Subsystem Fault due to mis-interpretation of design by subsystem sub-vendor,
OFP fault due to mis-interpretation of design by integrator OFP team,
Design weakness or incomplete design realized through testing.
Any of the above failure is fedback to the design loop and re-validated through Integration Testing.
System Testing. This category is also known as the onboard testing or flight testing whereby the avionics system is subjected to platform testing with real environment. While integration testing is focused towards the functionality of the system, flight testing is used to analyze the real world performance of avionics system as well as the individual subsystems.
User Acceptance Testing. It is the final stage of induction of the avionics system in an Air Force whereby the user accepts and validates the system against earlier defined mission roles and applies the platform in real combat scenarios.
The above presented explanation to the generic “V” development model covers core steps involved in an avionics integration design. However, detailed “V” model specific to activities related to an avionics integrator is shown in Fig 7.
Fig. 7 – Avionics Integrator “V” Development Model
7. AVIONICS INTEGRATION STAKEHOLDERS AND WORKFLOW
Due to the complex technologies embedded in avionics subsystems, it is not possible for any one organization or industry to develop the avionics system in its entirety. While the onus of avionics system design remains on the integrator, various sub-vendors are used for development of specific hardware technologies like the sensor systems, display systems and even the hardware of the mission computers. The overall design is issued by avionics integrator and the sub-vendors follow that design to modify or develop their subsystems.
Even within the domain of avionics integration, three distinct specialties are required to undertake the entire activity. These include avionics systems engineering specialty, OFP development specialty and the simulation facility development specialty. While their detailed activities will be defined below in the workflow, core competencies required to be developed for establishing such sub specialties in an avionics integration team include:
Systems Engineering team must be familiar with avionics subsystem functionality and performance. They must be able to breakdown mission requirements and define the communication scheme and functional modes along with display logic and screens on MFDs and SHUD.
OFP team must be able to develop mission computer software in real time operating system using available languages like C, C++ or ADA.
Simulation Lab Team must be able to develop simulation and flight model software along with development of testers to debug communication channels used between avionics subsystems and mission computers.
The elaborate workflow followed in a typical avionics integration project is shown in Fig 8.
Fig. 8 – Avionics Integration Workflow
The workflow has been divided in three main areas, whereby, mainstream activities of an avionics integrator are shown in the middle rectangle while adjacent left and right areas define sub-vendor activities. The left rectangle specifies mission computer hardware sub-vendor while the right rectangle defines the workflow of all the other avionics subsystem sub-vendors. In between the main integrator’s rectangle, various activities in the flow are color coded on basis of responsibility demarcation between user, systems engineering, OFP or sim lab teams.
The steps defined in this workflow are ones already explained in the section for avionics integration process. However, here the focus is definition of responsibility. Arrows connecting various workflow objects also indicate major deliverables to be developed at each item.
Preliminary Design Phase. The flow starts with mission requirements laid down by user agency. These requirements are translated into avionics system scheme design by the integrator’s systems engineering team. Based on this system design scheme, subsystem technical requirements are delivered to the respective subsystem sub-vendors for preliminary design. Systems engineering then develops avionics system specifications that are translated into mission computer Hardware specification requirements to mission computer sub-vendor. Also detailed specification requirements are developed for each subsystem sub-vendor used for subsystem specification finalization.
Detail Design Phase. In this phase, systems engineering develops the avionics detail design in form of subsystem integration and ICD requirements and provides the same to sub-vendors for detailed subsystem design. In parallel the mission computer sub vendor would carry out hardware design and subsequent hardware development. In this phase, design requirements are developed by systems engineering for mission Computer OFP, Sim Lab Hardware, Sim Lab Software and databus software.
Development Phase. In this phase, the subsystem and mission computer sub-vendors would develop the hardware and software for their subsystems. This phase will be concluded with stand alone acceptance testing of the subsystems by systems engineering team. In parallel, the OFP, Sim Lab and databus design teams would carry out internal development of their respective products.
Integration Test Phase. Once all development is complete and stand alone testing has been carried out, the sub-vendor hardware is received by integrator. OFP is loaded on the received mission computer hardware and the sim lab facility is used to carry out the whole avionics system acceptance testing. This phase is generally iterative with all issues gradually resolved through hardware and software changes in subsystems. Once successfully concluded, the avionics suite is subjected to aircraft onboard ground testing.
Flight Qualification. After completion of onboard integration tests, the flight testing phase begins. In this phase, detailed test plans are developed by systems engineering to verify the performance of avionics system and subsystems against the earlier defined specification requirements.
User Acceptance and Lifecycle. Upon successful qualification of the avionics suite, it is offered to the user for induction and service.
8. CONCLUSION
With current technological advances in computing and sensor technologies, all modern fighter aircraft programs rely heavily on Avionics Integration for providing an optimized mission driven architecture. The integration domain encompasses all activities related to avionics from conception of design to the final flight qualification of avionics system. The core competencies required for such an avionics integration program have been elaborated in detail in this paper. It has been explained that avionics integration domain needs to control and steer the entire development and test cycle of the avionics system based on user mission requirements. For this purpose, the required framework and optimum workflow has also been presented in detail.
REFERENCES
[1] R. P. G. Collinson, Introduction to Avionics Systems, Kent, UK, Springer, 3rd ed., 2011.
[2] C. R. Spitzer, The Avionics Handbook, Williamsburg, Virginia, CRC Press, 2001.
[3] Gp Capt Arif Saleem, Anatomy of Avionics Integration, AIT Compendium, 2005.
[4] I. Moir and A. Seabridge, Military Avionics Systems, Wiley & Sons, 2005.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Development Of Framework For Acquisition Of Avionics Integration Capability (ID: 113825)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
