IPT Guidance for Acquisition of Systems with Complex Programmable Hardware using DO-254 (January 2009) (36 Pages) Final

For UK military systems, the safety assurance of Complex Electronic Hardware (CEH) was specifically addressed by Def Stan 00-54 introduced in 1999. However, this standard was withdrawn in December 2004 and stated to be superseded by the much wider system level Def Stan 00-56 issue 3. The MoD intended that the less prescriptive approach to system safety assurance introduced by Def Stan 00-56 issue 3 would facilitate the development and certification of novel systems, including those with CEH.

The effect of this approach to safety assurance has been the removal of detailed guidance for the specification and procurement of safe CEH for UK military systems. For a rapidly developing technology, guidance is required for IPTs and suppliers and its omission may discourage the exploitation of CEH due to the perception of increased project risk.

To address this deficiency, this booklet aims to guide the procurement and acceptance of military avionic systems. It is based on the continuing technical advances that are being made in electronic system design and the capabilities of Programmable Logic Devices (PLDs).

The guidance concentrates on the process by which a strategy to achieve the required Design Assurance for these devices can be developed and implemented.

The basis of this guidance is that the DO-254, Design Assurance Guidance For Airborne Electronic Hardware, civil guidance produced to aid the certification of systems and equipment for civil aviation can be adapted for military acceptance.

The July 2008 version of the guidance, containing additional appendices, can be found here.

Safety Analysis Strategy Guidance for a Previously Developed System (PDS) (September 2008) (48 Pages) Final
In its procurement strategies, the MoD has consistently recognised the potential benefits of the use of a Previously Developed (Deployed) System (PDS) compared with a bespoke development. These potential benefits include lower cost and reduced project risk as well as faster deployment. As well as the re-use of military systems, the MoD is striving to be as commercial as possible, military as necessary by encouraging the greater use of commercially available equipment and,
where appropriate, adopting commercial standards and guidelines. Consequently, the use of systems previously developed and used in civil applications is becoming increasingly common in military procurements.

The benefits of procuring PDSs have not always been realised due to lack of proper consideration of the differences in the proposed use of the system compared with its previous application(s). These problems tend to be revealed late in the programme when unplanned rework and testing is expensive.

The guidance presented is for general application and may be used to develop procurement requirements, acceptance criteria and help IPTs assess proposed solutions. The aim of this document is to provide IPTs with guidance to address the safety aspects for the following:

1. Procurement of a system consisting of, or adapted from, a PDS for incorporation into a military platform (sometimes referred to as the 'overall system').

2. A proposed platform modification based on the integration of a PDS which, it is claimed, has been installed and deployed safely in other similar platforms and/or operating environments.

Open systems for military avionics: A technology overview - ERA Report 2007-0669 (November 2007) (72 pages)
Issue 2 of this Report (formally the ASSC Guide to Open Systems) represents a major revision. All commentary and references that appeared in the original document have been reviewed on grounds of currency, relevance and correctness.  A number of passages concerning non-current and lesser used standards and frameworks have been removed, whilst new sections relating to recent and emerging concepts, standards and programmes have been introduced.  Additions include new sections on the:

- ASAAC Software Standard Def Stan 00-74 - See Section 13.2.1,
- The Open Groups Architectural Framework (TOGAF) - See Section 13.3, 
- The DoD's Open Systems Joint Task Force (OSJTF) - See Appendix D,
- The Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) - See Section 14.3.2. 
- Two short case studies on the UK Merlin Capability Sustainment Programme and the US Global Hawk Programme have also been included - See Appendix A & See Appendix B.

The Certification of Systems containing Software developed using RTCA DO 178B - ERA Report 2006-0036 (June 2006) (75 Pages) Final
Much of the avionics software now procured from the US has been previously developed to RTCA's DO-178B. However, in order to gain certification for use in a UK military application, much additional work appears to be required before a RTS can be provided.

The perceived weaknesses of DO-178B are investigated and outline approaches to certification for UK military applications are investigated that could overcome identified shortcomings.

ASSC C++ Strategy Paper - ERA Report 2005-0293 - (July 2005) (26 Pages)
The use of C++ for safety related and safety critical defence applications is becoming more prevalent. Certification of these applications is being carried out on a case-by-case basis. In order to reduce costs the MoD need to define a universal process for practitioners and assessors of these systems. It is therefore considered necessary for a guidance document to be produced for the practitioners of C++ for safety related and safety critical defence applications.

ASSC/330/6/2 - Issue 1 Comparison of Defence Standard 00-56 and ARP 4761 / 4754 (July 2002) (23 pages)
The objectives of this paper is to determine whether ARP 4754 and ARP 4761 can provide a model for a guidance document on the application of Def Stan 00-56 to military avionic and weapons systems and if so to provide an outline for such guidance.

There was an implication that if this were possible then it might be possible to make a claim that a system built to ARP 4754 complied with requirements of Def Stan 00-56. Put another way the implication might be that, with some qualification, civil aircraft standards could be applied to military aircraft projects.

Note: Comparison relates to Def Stan 00-56 Issue 2. Interim Issue 3 has now been released.

ASSC/330/3/478 Application of open systems principles to data bus API (October 2001)
A talk was given to the Systems Engineering Subcommittee by Mr. David Taylor, Technical Director, Generic Software Solutions on 9 October, 01 which covered the following:

The Problem:
The lack of standardised API's (Application Programming Interface) for Data bus interface cards gives the user limited flexibility, for example:

- Users applications, written for one card are not portable.
- Manufacturers have to develop their own analysis software.
- Users wishing to develop and use applications are tied to single card manufacturer.
This also has the effect that there is no third party application software being developed.

The Solution:
Application of Open Systems principles to Data bus API.

Develop standard language independent API specification for each Data bus protocol Support multiple development environments through use of COM (Component Object Model)/CORBA (Common Object Request Broker Architecture) API specification. Standard API for generic interface features (e.g. Signal management, Change Control) Develop common Compliance Test Procedure for each protocol standard Independent authority to perform tests and publish compliance reports.

The Generic Interface Manager {GIM} from Generic Software Solutions.
A proposed framework for Data bus API development.

Simple component framework to support an extendible Graphical User Interface.
Remove single source dependencies by provision of manufacturer specific implementations.
Encourage manufacturers to write compliant drivers and improve the implementation of card functions Enable direct comparison of card performances and functionality. A copy of the OHPs and notes is available by download from the title of this abstract

ASSC/210/2/69 : Outline Requirements for an Avionics Bay Environment Data Logger (Apr 01) (8 pages)
This document outlines the basic requirements for a data logging system that could be used to investigate key parameters of the real environment experienced by avionic equipment.

The background is that the operating environment specified for airborne electronic equipment is a major driver in both the technical design solution and in the final cost.

It is important not to mandate unrealistically high levels for environmental parameters, but to take a more pragmatic approach of using field data. Unfortunately there does not appear to be a great deal of such data available.

Therefore as some current air systems will be in-service for 30-40 years and their avionic systems subject to a number of upgrades addressing obsolescence and added capability, it would be cost effective if the real environment was correctly specified, when addressing these upgrades.

ASSC/330/2/165 : Processor obsolescence in avionics (May 99) (16 pages)
It reviews the reasons for processor obsolescence and the subsequent consequences. The paper considers briefly guidelines, which already exist, and how these fall short of the ideal. It then considers some of the techniques, which could be used to assist in mitigating against processor obsolescence.

The report concludes that guidance is needed in two contexts, one associated with existing systems where processor obsolescence is likely to become an issue and the other in the context of making systems more proof against future changes.

ASSC/330/2/159-Issue 1: Emerging Commercial Software Development Standards
(January 1999) (23 pages)
The introduction of the standards ISO/IEC-12207, IEEE/EIA-12207 and EIA/IEEE-J-STD-016 will have an impact on software development strategy for ASSC member companies. ERA has been tasked by the ASSC to review these three standards, compare them to other software development standards and assess their impact on ASSC member companies.
This report is the result of ERA's investigations. ISO/IEC-12207, IEEE/EIA-12207 and EIA/IEEE-J-STD-016 are described and contrasted. Then they are briefly compared to other software development standards used by ASSC members. They are found to be fundamentally different to those other software development standards, apart perhaps from MIL-STD-498. The responses to a questionnaire circulated amongst ASSC member companies are presented.
It is found that ISO/IEC-12207 is not currently being called up in ASSC member company contracts. However, there is little doubt that it will have a considerable impact on member companies and their software trade. It is concluded that the adoption of ISO/IEC-12207 for military avionics software trade should be advanced, building upon the progress already made in IEEE/EIA-12207 but also specifically considering the UK and military avionics contexts.

ASSC/130/2/38-Issue 1 : ASSC advisory document on the characteristics of avionic display performance (Feb 98) (61 pages)
The purpose of this document is to promote MoD (PE) Project Officers' understanding of the information supplied by vendors of display equipment and assist them in the procurement of displays. It is anticipated that its use will facilitate comparison between tenders from different equipment suppliers by ensuring that suppliers provide the information detailed in the document so as to facilitate the MoD decision making process.

This document is not prescriptive; its objective is to list the key characteristics of each type of display. It provides a description of each parameter, shows how it might be specified, and provides an example using typical "ballpark" figures.

ASSC/330/2/154-Issue 1 : Real Time Operating Systems (RTOS) (Feb 98) (4 pages)
This is a report brings together two reports written on RTOS in order to provide a covering document to preserve their original date and content. The reports covered are Real Time Operating Systems. (ASSC/330/2/136) dated April 1996 and Evaluation of Real Time Operating Systems: The Role of Standards (ASSC/330/2/141) dated March 1997.

Details are also included of possible future work in this area.

ASSC/330/2/141-Issue 1 : Evaluation of RTOS Systems (Mar 97) (52 pages)
This report has been prepared for the ASSC Processing Working Group as part of work to evaluate commercial real-time operating system (RTOS)products for avionics applications. A previous report ASSC/330/2/136 proposed a list of candidate RTOS products. The objectives of this report are to establish the role of operating system standards in the evaluation of RTOS products, to generate evaluation criteria and to determine whether sufficient information is available to carry out an evaluation against the criteria.

It is concluded that detailed evaluation of RTOS products cannot be carried out without specifying the architecture within which it is proposed that the RTOS is to be used. POSIX is the only standard with which an RTOS product could directly comply. An RTOS product, or the POSIX standard itself, could be evaluated for compatibility with an architecture-based standard such as ARINC APEX, in order to determine whether the RTOS could be used in the implementation of an APEX compliant system. The functionality provided by an RTOS product could be classified within an architectural framework such as GOA: this could assist in proposing system architecture which maximise use of commercial software and standards. The relationship between Ada 95, which has real-time extensions, and RTOS products is also complex since Ada can be used either with an RTOS or instead of one.

It is recommended that future work should focus on the evaluation of RTOS products, especially those which offer POSIX compliance or Ada compatibility, within architecture frameworks which promote the use of other standards and commercial software products. Further evaluation of non-commercial operating system standards or products, such as VRTOS or RTEMS from the US Army is also recommended. Non-functional criteria, especially long-term support and safety, should be considered in preference to more detailed consideration of functional criteria. Finally, emerging standards for interfaces between software objects, such as CORBA, should also be considered.

ASSC/330/2/134-Issue 1 : Software Reuse (Jun 96) (31 pages)
A literature search has been carried out for information about the application of software reuse in military avionics and other defence or embedded systems. The information found, including over 50 published papers and a number of World Wide Web pages, is described under three headings. The first heading considers reports of the application of software reuse to the production of real systems. The second heading describes a number of initiatives aimed at promoting software reuse or collecting libraries of reusable software. The final heading collects papers which consider the progress of software reuse and some of the issues raised by attempts to adopt reuse more widely.

It is not clear whether the relative lack of information from UK and other European countries is a result of a lack of activity or of a reluctance to release information about work in progress. There is no indication, however, that any European effort to adopt reuse has achieved the level of activity being undertaken in the USA.

ASSC/330/2/135-Issue 1 : Safety critical software standards survey and summary (Apr 96) (48 pages)
A literature search has been carried out for standards relating to the development of safety critical software. A total of approximately forty standards were found, including those concerned with the safety certification of programmable system as well as those covering software development.

Standards in five industry sectors were selected. The sectors are UK and US defence, civil aerospace, European rail transport and nuclear power. The applicable standards in each sector were summarised. Each summary uses the same headings so that the standards can be compared.

A notable standard covering safety critical software is draft IEC 1508, 'Functional Safety - Safety-Related Systems'. This is a generic standard, which is designed to be adapted to each industry sector. IEC 1508 not one of the standards selected for summary in this report, because of its complexity. However, the selected European railway standard, although based on an earlier draft of IEC 1508, is an example of an industry specific adaptation of IEC 1508

ASSC/330/2/136-Issue 1 : Real Time Operating Systems (Apr 96) (9 pages)
The objective of this report is to provide the Processing Working Group with information on the range and utility of commercially available (or under development) real-time operating systems.

There are currently a number of operating systems available which purport to support real-time operating system (RTOS) requirements. This report identifies and describes commercial off the shelf (COTS) operating systems which have features that may be applicable to real-time military avionics applications. Features such as system performance, through life support and adherence to standards such as the portable operating system interface for computing environments (POSIX) have been considered.

ASSC/310/2/28-Issue4 : Issues in the standardisation of hardware for high integrity systems for application to avionics systems (Apr 95) (10 pages)
The use of programmable digital hardware in high integrity systems has been increasing over the past ten years. Reasons for this include ease of use, adaptability, physical stability, potential for built-in integrity, etc. Areas where digital technology has been applied include fly-by-wire aircraft control systems, autonomous robotics and command and control systems.

The development of software for safety critical systems has been addressed at many levels and is the subject of standardisation activities sponsored by the UK MoD with Def Stan 00-55, the FAA in the US with RTCA 178, and the US DoD with DOD STD-2167A. These activities address software solely. The concept of the system and the use of a system wide approach to high integrity is given little or no concern. This is especially true for hardware.

The use of hardware in high integrity systems is usually decided at the requirements capture stage in the system life cycle. It will always be a system issue rather than isolated to individual components of the hardware. The techniques available for hardware are seen in this document in the context of the system as a whole and are not considered in isolation. It is important that all the individuals involved in the project realisation have a coherent view of the fault tolerance philosophy adopted. Establishing this philosophy at the outset of a project can be viewed as a risk reduction process.

ASSC/310/2/31-Issue 4 : Multi-processing systems technology review and standardisation issues (Apr 95) (13 pages)
There are five main issues associated with the use of technology in military avionics systems from the perspective of the procurement body. These are performance, through life costs, operability, availability, reliability and maintainability (generally considered together) and timescales. Typically reduced cost and higher performance are in conflict; higher performance invariably costs more.

High performance processing engines tend to be expensive to design, develop, use and support throughout the lifecycle. Processor/memory architecture has developed significantly to arrive at the sophisticated microprocessors available today. This architecture, despite improvements such as feature size reduction, load/store architectures, pipelining and Reduced Instruction Sets, is now approaching the limit of its capabilities with respect to processing performance. Further enhancements of this type of processing architecture are becoming increasingly more complicated and expensive.

Point of contact: Kevin Moore
Tel: +44 (0) 1372 367141
E-mail:era.assc@cobham.com