Evolution of Complex Safety-Critical Avionics Systems in

Download Report

Transcript Evolution of Complex Safety-Critical Avionics Systems in

Evolution of Complex Safety-Critical Avionics
Systems in an NCW Environment
Scott Simmonds,
BAE Systems
Sergey Nesterov,
CEDISC
1
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.
2
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.
3
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
•
the sustainment phase
• foreign government military sale,
• commercial acquisition from an Original Equipment Manufacturer or consortium, or
• in country development
• 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.
4
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.
5
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
6
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
7
Complexity of Military Systems
• Other considerations include
•
•
•
•
Application of COTS Software and System
Legacy systems
Disposal and Replacement
Ongoing Technical Airworthiness Management
8
Work conducted to date
• Study of software safety issues related to the development of missioncritical avionics systems
• Identification of modelling and simulation techniques for evolutionary
systems development
• Review of best practice in the evolving airborne mission systems
9
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
10
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
11
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.
12
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
•
•
•
•
•
The selection considered appears to either be appropriate to the context, or have
significant potential for application within the target domain.
•
•
•
Scenario based Inquiry Cycle (ScenIC),
Model based Evolution in Software Agents (MESA),
Synchronised Refinement and finally
Software Architecture Analysis Method.
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.
13
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.
14
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
15
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
16
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
17
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
18
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
19
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.
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 softwareintensive systems
• Risk mitigation and resolution techniques for software in evolving
mission-critical avionics systems
21
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.
22
Questions ?
23