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.
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/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/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.
Point of contact: Kevin Moore
Tel: +44 (0) 1372 367141
E-mail:assc@era.co.uk
