Evolution of Complex Safety-Critical Avionics Systems in an NCW Environment

1. Evolution of Complex Safety-Critical Avionics Systems in an NCW Environment Scott Simmonds, BAE Systems Sergey Nesterov, CEDISC

2. Introduction • The evolution of complex military platforms over substantial lifetimes is becoming recognised as a challenging problem • A factor being the complexity of the mission systems that are integrated onto the platforms • To be successful in undertaking this evolution, there is a need for • specialist methodologies, • processes, • tools, • techniques and • technical knowledge. • BAE Systems Australia Defence, and the Centre of Excellence in Defence & Industry Systems Capability (CEDISC) at the University of South Australia have entered into a collaborative research agreement to conduct Research and Development into safety and mission critical avionic systems in the Australian defence environment. • BAE Systems is funding a portion of the research program, with contribution from the South Australian Government.

3. Research Program • The research program includes • efforts to understand the historical background to avionic and weapons safety critical practices in Australia; • the discovery and analysis of the technical issues associated with system and software safety in evolving network enabled military avionic systems; • identification of international best practice in this area of interest; • proposing and validating Australianised methods, tools and practices to mitigate the issues previously identified; and • implementing selected proposals to reduce industry and Defence risk in conceptualising, acquiring, producing and operating evolving military avionic systems in an NCW environment. • This presentation provides an overview of the research program being undertaken and a summary of progress to date.

4. Background • In broad terms, there are two phases to the life of a complex military platform, • the acquisition of the platform from the platform vendor • foreign government military sale, • commercial acquisition from an Original Equipment Manufacturer or consortium, or • in country development • the sustainment phase • maintaining the capability over the platform lifetime and • introducing "small" capability increments commensurate with a maintenance of capability philosophy. • Defence acquisitions are typified by long acquisition cycle times. • Two pass Kinnaird process meant to mitigate risk, however it introduces considerable lag into the acquisition process • The effect of this lag is typically that the proponents of the original need identification have often long since departed • and the validation of the system being delivered to meet the need is often conducted by those with little knowledge of the history of the early part of the program. • It is the early part of the program however which defines the rationale for decisions and assumptions that have been made. • This of course provides plenty of opportunity for the claim of ignoring or overturning decisions made "Before My Time" ! • This leaves the build up of corporate knowledge on the platform to the OEM or system integration contractor.

5. Background • During transition to the sustainment phase, the effect of knowledge loss is often magnified • there is no guarantee that the system integrator or OEM will be engaged under contract to provide sustainment services. • the opposite is frequently the case, with third party organisations being engaged to provide these services. • Planning and execution of transition to sustainment is therefore of key importance to ensure no capability gap is introduced between delivery of the platform, and the ability to actually support it. • Sustainment of mission systems beyond the acquisition phase also has a unique set of problems, particularly where the planned life of a system is 25-30 years, • actual life having a tendency to extend well beyond this period.

6. Complexity of Military Systems • Mission and avionics systems of ADF aircraft can be described as complex, long lifetime, robust and "expensive" to acquire and maintain. • "Expensive" is a relative term, in the context of Australian defence acquisition, close attention is paid to the Value for Money argument in justifying the expenditure of government funds. • While the numbers sound large, they are generally comparable with other high budget programs such as major civil works and big budget movie productions. • The ability to maintain and augment capability in defence mission systems is one of the largest consumers of capital funding in the ADF • In recent years, issues with performance and integration of mission systems has plagued acquisitions projects driving schedules out and costs up • Collins Combat System, Wedgetail

7. Complexity of Military Systems • Methods and techniques to improve the maintainability and augmentationability of defence mission systems have the potential to significantly impact the consumption of capital and sustainment expenditure and funding. • A case study, the Project Air 5276 Phase 2A upgrade of the P-3C Orion Maritime Patrol Aircraft on the Mission Systems Architecture is considered at various times in the research program • Issues arising during the acquisition phase and issues arising through the sustainment of the platform are considered. • PA5276 put in place a Mission Systems Architecture that was standards based and flexible enough to allow adaptation to evolving roles and the necessary capability increments to support them that were envisaged for the AP-3C. • To support this adaptation, additional mission and support system hardware and software was procured and installed in purpose built facilities, the Edinburgh based Integration Test & Training Facility • A number of factors have impacted the adaptation of the mission systems to the evolving role of the platform • There are many reasons for this and include: • The perception of the difficulty in modifying software and systems, and • Continuing funding challenges to development of changes to a well defined but complex system

8. Complexity of Military Systems • Other considerations include • Application of COTS Software and System • Legacy systems • Disposal and Replacement • Ongoing Technical Airworthiness Management

9. Work conducted to date • Study of software safety issues related to the development of mission-critical avionics systems • Identification of modelling and simulation techniques for evolutionary systems development • Review of best practice in the evolving airborne mission systems

10. Study of software safety issues related to the development of mission-critical avionics systems • This work has reviewed addressing practical problems and issues associated with software safety in mission critical systems in all phases of the life cycle. • The review presents topics on: • Current defence acquisition and contractual practices dealing with software safety issues, based on the relevant standards and regulations  • Issues in the application of software safety standards • Issues in measuring safety • Safety case development issues • Application migration and safety issues • CMMI extension for safety • COTS and Safety issues • Issues and recommendations to come out of this work so far, • The introduction of safety case into the current software support practices. • This provides the following benefits: • Extended maintenance capabilities • Software modules classification based on safety criticality leads to more effective (targeted) testing practices

11. Study of software safety issues related to the development of mission-critical avionics systems • Clear safety critical software component isolation is likely to be a basis for a safe experimentation program in system/software upgrades • Issues with the Safety Case implementation are that it requires understanding (by all stakeholders) of how the safety case works within a standards based framework. • Safety issues from Management, Contractual and Regulatory perspective have also been considered

12. Identification of modelling and simulation techniques for evolutionary systems development • Modelling and simulation are key techniques to mitigate risk in acquisition projects • Typically, models are not maintained once the implementation or realisation phase of acquisition projects is reached • At this point, the model (which may or may not be machine realisable, or executable) starts to diverge from the actual implementation • the implementation becomes the focus of development and integration activity – the maintenance of the model is left, either • abandoned completely, or • revisited as a last project cleanup effort to capture the final element of contractually deliverable documentation • In either case, the model's utility as an accurate representation of the system under development that can be further used for analysis and improvement is unlikely, • only "accurate" model remaining of the "as implemented" system is held in the minds of OEM engineering staff • Techniques were examined and proposed that would assist in the transition and maintenance of the "as implemented" model into the community of practise responsible for system sustainment.

13. Techniques for Software Evolution • Techniques for software evolution examined include a variety of modern (and slightly older) software modelling and development paradigms, including • Domain Map • Structured Analysis, • Application of the Unified Modelling Language • Architectural Analysis and Design Language (AADL), • Model Based Integration of Embedded Systems (MoBIES), • Embedded Systems Modelling Language (ESML), • Automatic Integration of Reusable Embedded Software (AIRES), • Mission Orientated Architectural Legacy Evolution (MORALE), which contains a number of phases, including • Scenario based Inquiry Cycle (ScenIC), • Model based Evolution in Software Agents (MESA), • Synchronised Refinement and finally • Software Architecture Analysis Method. • The selection considered appears to either be appropriate to the context, or have significant potential for application within the target domain. • It could be observed that there are too many approaches to choose from, and that this is an indication of the pervasiveness and complexity of the problem • No final recommendations as to which of the selected approaches is better suited to the Aerospace and Defence context. • Further research, particularly by means of a trial is probably most appropriate.

14. Review of best practice in the evolving airborne mission systems • This work to date has reviewed a number of practises in airborne mission system evolution.  • The aim is to • determine international best practice in this area, • make a determination based upon experimentation as to whether the practises reviewed are "best practise" and • formulate or otherwise develop process, tools and techniques that are able to be applied to the evolution of airborne mission systems.

15. Challenges and Issues • Systems in general are increasingly dependent on software • The trends are: • An increased emphasis on users and end value • Increasing software-intensive systems criticality and need for software dependability • Increasingly rapid change in technology and user needs • Increasing software-intensive systems globalisation in development and need for interoperability, including national standards • Increasingly complex systems of systems interaction on software level • Increasing needs for COTS, reuse and legacy software-intensive systems integration

16. Relevant Practices and Approaches • Leveraging COTS Components • Network Data Buses • Software and Software Obsolescence • Open Architectures • Integrated Modular Avionics • Obsolescence Management • Diminishing Manufacturing Sources and Material Shortages • Maintaining Legacy Software • Other Practices and Approaches

17. Leveraging COTS Components • The cost and complexity of attaining the capability of modern airborne mission systems that can operate as part of a bigger system of systems pose challenges.  • These challenges are being met by new practices and approaches in systems development, sustainment and integration.  • The main responses are: • An increasing reliance on commercial-off-the-shelf (COTS) products • An emphasis on open architectures • Introduction of Industry Standards based architectures – e.g. Integrated Modular Avionics • Reliance on COTS products has also driven new practices to manage the obsolescence issue • This is becoming more severe because of the shortened product life cycles of COTS components

18. COTS Adaptation • Development of software has overtaken the development of hardware as the major design effort and • The highest costs that arise in the replacement of obsolete hardware are the effort and cost in the adaptation of the application software with increasing COTS usage, • the hardware will come to represent relatively low value

19. Porting Legacy Software • In practice, porting source code to a new system will involve recompilation to a new target using a new software development environment.  • The executable binaries generated will not be physically identical (although semantically equivalent).  • Testing therefore needs to be conducted to requalify and certify the software for safety and mission critical application.  • If the programming language of the source code is no longer “popular” in software development terms, (e.g., Ada83, OCCAM, and Fortran), software engineering tools may not be available for current generation hardware, and • software developers will be more difficult to engage compared with programmers for other, more modern languages such as C++, Java and C#.  • Rewriting the software in a current programming language is comparable to the original task of development. • An open architecture can provide some insulation of the impact of hardware changes on software • software applications do not directly access hardware resources but work through a standard application programming interface, • examples being ARINC 653, Service Oriented Architecture and Data Distribution Service

20. Porting Legacy Software • In a particular case study, modifications were made to address Ada83 to Ada95 language conversion, compiler specific extensions, and vendor libraries that required strong data types.  • It has been found that about one per cent of the legacy software required modifications to accommodate for differences in compilers.  • An abstraction layer (essentially a set of software wrappers) was introduced to emulate the required interfaces so that the legacy software could be hosted on different operating systems such as Solaris, Windows and VxWorks.  • This allowed the original optimisation in the legacy software to be retained.

21. Future work • Identify technical tools, techniques and practices that need to be introduced or enhanced to improve airborne mission system outcomes • Identification of appropriate processes, practices and tools for the evolution of airborne mission systems • Review of domain expertise required to perform the managed evolution of airborne mission systems • A study of human factors in mission and safety-critical software-intensive systems • Risk mitigation and resolution techniques for software in evolving mission-critical avionics systems

22. Summary • This presentation has outline the scope of work and activities undertaken to date in the Cooperative Research Agreement between the Centre of Excellence in Defence Industry Systems Capability and BAE Systems Defence. • The work conducted so far has examined some of the issues related to the acquisition and sustainment of complex mission and safety critical avionics systems, • in particular the acquisition and transition to sustainment of the upgraded AP-3C Orion Maritime Patrol Aircraft • Consideration of best practice in the application of COTS, the issues with COTS software, the use of open architectures and modular architectures. • The  examination of • methods, tools and processes to mitigate industry and Defence risk, • identification of processes, practises and tools related to the evolution of airborne mission systems and • the relationship of human factors in mission and safety critical mission software intensive mission systems are planned as a future component of this research activity.

23. Questions ?