IPT Guidance for Acquisition of Systems with Complex Programmable Hardware using RTCA DO-254 (February 2008) (74 Pages) Final
For UK military systems, the safety assurance of Complex Electronic Hardware (CEH) has been specifically addressed by Def Stan 00-54 introduced in 1999. However, the standard was withdrawn in December 2004 and replaced by the system level Def Stan 00-56 issue 3. It was thought that the less prescriptive approach to system safety assurance would facilitate the development and certification of novel systems including those with CEH.
One unintended effect of this approach to safety assurance has been the removal of detailed guidance for the specification and procurement of safe CEH. For a rapidly developing technology, guidance is required for most suppliers at some stage and its lack may actually discourage its exploitation due to the perception of increased project risk.
To address this deficiency, this document aims to guide the procurement and acceptance of military avionic systems based on the continuing technical advances that are being made in electronic system design, in general, and the capabilities of Programmable Logic Devices (PLDs), in particular.
ASSC/110/6/2 – Issue 3 : Guide to digital interface standards for military avionic applications (September 2006) (249 Pages)
This guide has been prepared and updated by the Data-Networks and Interfaces Working Group of the ASSC. Its purpose is to give introductory guidance on data networks and interfaces for use in avionic systems by providing information on the main features and status of existing and/or emerging standards, in a common format. The guide is intended for both MoD and Industry personnel involved in avionic systems engineering in order to help determine what choices of interface standards are available in the marketplace and provide information on the developments and features in relation to their use for avionics.
Issue 3 of this Guide represents a major revision. All commentary and references that appeared in version 2 has been reviewed on grounds of currency and correctness. A number of sections concerning non-current and lesser used standards have been removed. Details on new avionics standards, such as those that build upon the legacy of MIL-STD 1553B, and technologies that have the potential to play a major role in future avionics systems (e.g. WiFi /802.11x) have been introduced. Comments on this updated Guide are very welcome. These should be sent by Email to assc@era.co.uk.
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 - Beth Bateman - 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/6/1-Issue 1 - Guidance on open systems for avionics (November 2000) (42 pages)
This guidance on the use of Open Systems for Avionics has been prepared by the ASSC Open Systems Task Group. The guidance is intended to be brief and understandable in informing developers and managers about:
* the potential benefits of using Open Systems to reduce the lifecycle cost and enhance the supportability of future avionics systems
* the challenges of using Open Systems and the impact of the use of Open Systems on the system development and procurement process
* related guidance on the use of Open Systems being developed in the USA
* the standards currently available that may be applicable to avionic systems
It is intended to cover important topics without developing detail. This guidance specifically addresses military avionics. Many of the principles of using Open Systems apply in all domains, but the requirements specific to a real-time, embedded domain such as avionics are expected to increase the challenge of using Open Systems.
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)
ASSC Emerging Commercial Software Development Standards Presentation
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/210/2/37-Issue 10 : Signal Data Concentrator (SDC) requirements (Nov 98) (18 pages)
This document has been prepared by the ASSC Packaging Systems Subcommittee to provide guidance on the design and installation of Signal Data Concentrators (SDCs) for use in military aircraft. It is intended to be applicable both to future aircraft and to retrofits. As yet, it does not incorporate any practical experience gained by the use of SDCs.
An SDC is a device that translates information from a variety of sources on the aircraft into a standard digital form usable by the computing resources in avionic systems. It also converts data from the computing resources into formats desired by the aircraft systems.
An SDC as a whole is made up from a collection of standard elements, Line Replaceable Interface Modules (LRIMs), which are covered by these requirements. It gives the opportunity of 1st line maintenance at module level.
Although this requirements document has been prepared primarily for military application, much of the information is equally applicable to civil avionics, and wherever possible, commonality has been sought with the ARINC 655 Remote Data Concentrator.
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/510/2/10-Issue4 : The use of architecture reference models for architecture evaluation (Mar 97) (15 pages)
This document considered the use of an architecture reference model as a basis for assessing architecture options and standards. It covers the nature of architecture reference models, lists the relevant models available, discusses how models might be used and identifies potential limitations of models.
It concludes that there are good reasons to use a reference model for checking that an architecture specification includes all the major interfaces and that the interfaces are consistent. A reference model can only be used as one of one of many tools for architecture and standard evaluation, however. Recommendations for further work in order to develop or adapt a model that is most suited to the evaluation process are included.
ASSC/510/2/9-Issue5 : The use of metrics for architecture evaluation (Mar 97) (22 pages)
One of the activities of the ASSC is to consider methods for the assessment of candidate avionic architectures. Metrics offer a potentially useful tool for this purpose, and this report examines their possibilities and provides practical guidance for their application.
It covers the reasons for using metrics, typical metrics and details of how they might be used as well as their applications. It includes a section on metrics being used during the ASAAC Phase 1 military programme and another on their use during the civil Control Technology Programme (CTP).
Conclusions suggest that that metrics can provide a means of assessing architectures and are also useful in detailed system engineering tasks such as selecting data network standards or choosing between subsystem options. Though it also highlighted that in each case the methods and metrics need to be selected carefully.
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/136-Issue 1 : RTOS (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/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/210/2/30-Issue 2 : Heatpipe cooling of avionic modules (August 1995) (12 pages)
This brief document has been prepared by the ASSC Packaging Working Group to provide information on the potential use of heat pipes for cooling avionic modules. It is based on published information, not on practical tests.
The document reviews current methods used for avionic cooling and contains a digest of published information available on the capabilities of heat pipes in an avionic context. Risk areas and costs associated with heat pipes are described.
It concludes that heat pipes may have potential for cooling modules dissipating 80-200W, but warns that relatively little is known of their performance in the avionics environment, and recommends that practical work is necessary to address the following issues:
* Orientation and acceleration problems
* Vibration
* Manufacturing techniques for avionic modules.
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: Christopher Hall
Tel: +44 (0) 1372 367408
E-mail:assc@era.co.uk
