Safety Related Software

Home
Members
Schedule
Archive
Search
Discussions
Contact Information
Members data area

Safety Related Software: Regulatory Framework and Standards

 1.0    Introduction

 This document  aims to provide the reader with a rudimentary understanding of the relationships between software assurance standards, the UK CAA Safety Regulatory Requirements (CAP670 SW01) and EUROCONTROL’s Safety Regulatory Requirements (ESARR).

 The information here is likely to be of interest to: 

bullet

Project Teams

bullet

Engineering managers

bullet

Inspectors

bullet

Senior Management

This is not intended to define how to comply with the relevant regulatory requirements. At the time of writing, the implications of the Single European Sky legislation are still being determined.

 2.0    Background

The regulatory regime for safety related software development has been evolving over a number of years. It is now no longer sufficient to simply develop software in accordance with a set of implementation standards; an argument must be provided that demonstrates that the software will fulfil its safety responsibility. This is in line with general trends within other safety related industries and, as a result of these developments, a number of software assurance standards have been developed.

Safety Management Systems provides the process that allows the system safety requirements to be determined, but it does not prescribe how to derive the corresponding software requirements nor to provide the necessary software assurance.

Aerospace systems providers are regulated by the UK CAA (Civil Aviation Authority) SRG (Safety Regulation Group) in part by ATSSD (Air Traffic Services Standards Department). In order to fulfil their regulatory responsibilities, SRG publish a number of regulatory requirements in a series of CAP (Civil Aviation Publication) documents. Regulatory requirements for safety related ATS (Air Traffic Services) software are published in CAP670 – ATS Safety Requirements – Part B Section 3 SW01.

 In parallel with UK activity, EUROCONTROL have developed and published a series of EUROCONTROL Safety Regulatory Requirements. The set of currently published ESARRs is:

ESARR1

Safety Oversight in ATM

ESARR2

Reporting and Assessment of Safety Occurrences in ATM

ESARR3

Use of Safety Management Systems by ATM Service Providers

ESARR4

Risk Assessment and Mitigation in ATM

ESARR5

ATM Services’ Personnel

ESARR6

Software in ATM Systems

In a statement to the SRC, EUROCONTROL Legal Services state that:

 “The legal effect of a EUROCONTROL ESARR, like the vast majority of other EUROCONTROL regulatory decisions, is that of a rule that creates an obligation for a Member State to implement and enforce such a rule in its own legal order.  It would not be directly applicable to third parties, e.g. the subjects of a State concerned.  In this context, it would be comparable with an EC Directive (which is also binding upon States to which it is addressed, but leaving to the national authorities the choice of form and methods).” This was documented in working paper AGC8.5 Agenda item 4.

It is the responsibility of SRG to ensure that the requirements of the ESARRs are encompassed in CAP documentation. The instantiation of ESARR6 is addressed in CAP670. This may change as the SES (Single European Sky) initiative evolves.

3.0    Software Regulatory Framework

This section explains the relationship between EUROCONTROL’s ESARR requirements and SRG’s CAP requirements, in relation to safety related software.

3.1       ESARR6

ESARR6 requires regulation of ATM (Air Traffic Management) software applications that can have an impact on safety. 

ESARR6 assumes that, in compliance with other ESARRs, where possible, quantitative safety requirements have been derived for the service to be provided. It also assumes that they have been apportioned between the people/procedures/equipment and where they have been apportioned to equipment they have been further apportioned to hardware and/or software for implementation. For the requirements to be considered to be necessary and sufficient, assurances are required that the requirements derivation process has considered, as appropriate: Functional behaviour; timing; capacity; accuracy; resource usage; robustness and overload tolerance. These seven attributes were identified by three independent European studies as necessary to fully specify a requirement.

ESARR6 requires service providers to include the provision of software safety assurance in the safety management system. This system is to ensure that:

bullet

The software requirements are valid;

bullet

The software requirements are traceable;

bullet

No software functions adversely affect safety;

bullet

All the software requirements are satisfied;

bullet

The evidence supporting the above claims comes from the software to be put in service

These were identified as the fundamental principles behind the major assurance standards. ESARR6 requires that the assurances provided be commensurate with the system risk presented by the software.

3.2    SW01

SW01 is the UK CAA elaboration of ESARR6 and is published in CAP670 Part B Section 3. In principle, it has the same scope, applies to the same software and makes the same assumptions with regard to the allocation of safety requirements to software.

The scopes of ESARR6 and SW01 do differ[1] in that SW01 explicitly addresses the inclusion of “derived requirements” and the need to address them as software safety requirements. Additionally, ESARR6 covers military systems whereas SW01 does not. This reflects the current regulatory regime in the UK and is a UK non-compliance with EUROCONTROL.

In the transition from ESARR6 to SW01 the first objective, seeking requirements validity, remains unchanged, as it requires the set of software safety requirements to be complete at the end of the project.

Requirements satisfaction is also unchanged, as it requires proof that the requirements have been met.

In contrast to ESARR6, which requires bi-directional traceability down to the level at which satisfaction is demonstrated; SW01 only requires downwards traceability.  This is sufficient to support the argument that the software safety requirement set is valid, and to establish satisfaction criteria to address the test data domain and non-interference.

However, there are well known issues in the use of complex software, whereby it may exhibit additional behaviour. Consequently it is also necessary to show that this additional behaviour is safe. Hence, the requirement for “no adverse effect on safety” (ESARR6 Section 1.2 (c)) is addressed by the non-interference objective in SW01.

The need for configuration consistency remains unchanged from ESARR6.

SW01 contains a guidance section which outlines SRG’s position on how compliance with the objectives of SW01 could be demonstrated; this is not mandatory and has been the subject of much debate.

The seven mandatory requirement attributes in ESARR6 are only mentioned in the guidance section of SW01. This is because it is expected that they will be mandated in CAP670 APP05 (Risk assessment and mitigation), currently in draft.

3.3    Software Assurance Standards

Neither ESARR6 nor SW01 mandate the use of software assurance standards. However, software assurance standards can be highly effective at providing methods of collecting assurance evidence for safety related software.

 A common misconception is that if an assurance standard is “complied with” to a “given level” then the software is guaranteed to perform to a “given reliability” or “that it is safe” or that “this is sufficient work for that level of requirement”, or even that “the evidence produced will be sufficient evidence of safety”. This is a false understanding of the intent and use of such standards.

Software assurance standards provide a set of techniques that: prevent the introduction of faults, remove any that are inadvertently introduced, generate evidence of their successful application or measure a property of the software. They do not make the software “safe” nor do they guarantee the achievement of a reliability figure. Instead they generate evidence, which can be analysed and used as a basis to provide the arguments that the software requirements have been met.

The two most common standards currently referred to, for software assurance in ATM systems, are IEC 61508 (Functional Safety of Electrical/Electronic/Programmable-Electronic Safety-Related Systems) and EUROCAE ED-109 (Guidelines for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance), a derivative of RTCA DO178-B (Software Considerations in Airborne Systems and Equipment Certification).

IEC 61508’s most significant shortcoming in addressing the needs of SW01 is that it does not address development of the safety case from the evidence that it generates. This is natural because it is not industry sector specific and therefore excludes any concept of a safety regulator.

ED-109 provides a solution to the absence of an ATM version of IEC 61508. It is a set of guidelines, not a standard, as it is produced by EUROCAE who are not legally recognised as a standards body. However, like its parent document DO178-B, ED-109 is a de facto standard.

If used, ED-109 has certain shortcomings in satisfying SW01. It does not address the validity of requirements and subsequently derived requirements adequately. For the same reason it also fails to address the attributes of a safety requirement. These shortcomings need to be addressed elsewhere in the service provider’s SMS.

A complication in the use either of ED-109 or IEC 61508 is that there is no body available to adjudicate whether an instantiation is valid or not. Not all of the regulatory material used by the airborne community to decide the validity of the instantiation of DO-178B is in the public domain and no such material exists for ED-109 or IEC 61508. Consequently if either standard were to be used, it would be prudent to involve the Lead Engineer in agreeing the method of compliance as early in the project as possible.

3.4    Def Stan 00-56

With the revision of Def Stan 00-56 a new kind of standard has been created. This standard has changed from a safety assurance development document into a safety assurance procurement control standard. The standard recognises that significant problems exist in allowing the safety lifecycle processes to modify the contracted deliverable. The standard attempts to provide guidance on how to successfully manage the transfer of information and design changes across the contractual boundaries. This is the only such standard publicly available.

4.0    Compliance with SW01

It is currently each project’s responsibility to develop a strategy for compliance with the objectives of SW01.If a project is audited by SRG it is expected that SW01 compliance arguments will be one of the areas to be examined.

In recognition of the scale of the problem associated with compliance with SW01, It is recommended that a  joint project and SRG Software Assurance review group be formed. The terms of reference for this group include the agreement of mutually acceptable means of compliance for the various types of projects that are routinely undertaken.

As this project progresses, agreements relating to SW01 compliance will be promulgated both within the project and SRG.

5.0    References

The following links provide access to the EUROCONTROL SRC (Safety Regulation Commission) ESARRs:

http://www.eurocontrol.int/src/public/standard_page/esarr1.html

http://www.eurocontrol.int/src/public/standard_page/esarr2.html

http://www.eurocontrol.int/src/public/standard_page/esarr3.html

http://www.eurocontrol.int/src/public/standard_page/esarr4.html

http://www.eurocontrol.int/src/public/standard_page/esarr5.html

http://www.eurocontrol.int/src/public/standard_page/esarr6.html

The following link provides access to the CAA SRG ATSSD publication CAP670, which includes SW01:

http://www.caa.co.uk/application.aspx?categoryid=33&pagetype=65&applicationid=11&mode=detail&id=200

The following link provides access to the IEC web page where information about IEC 61508 (Functional Safety of Electrical/Electronic/Programmable-Electronic Safety-Related Systems) can be found:

http://www.iec.ch/zone/fsafety/fsafety_entry.htm

The following link provides access to the RTCA home page where information about DO-178B (Software Considerations in Airborne Systems and Equipment Certification) can be found. Note that DO-178B is also published by EUROCAE as ED-12B.

http://www.rtca.org/

The following link may also be of interest when discussing DO-178B. It lists a series of papers published by the Certification Authorities Software Team (CAST) that provide clarifications on various aspects of software assurance.

http://www.faa.gov/certification/aircraft/av-info/software/CAST_Papers.htm

The following link provides access to the EUROCAE home page information about ED-109 (Guidelines for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance) can be found. Note that ED-109 is also published by RTCA as DO-278.

http://www.eurocae.org/

The following links provide access to Def Stan 00-56:

 http://www.dstan.mod.uk/data/00/056/01000300.pdf

http://www.dstan.mod.uk/data/00/056/02000300.pdf

6.0    Acronyms

ATM

Air Traffic Management

ATS

Air Traffic Services

ATSSD

Air Traffic Services Standards Department

CAA

Civil Aviation Authority

CAP

Civil Aviation Publication

CAST

Certification Authorities Software Team

EC

European Community

ESARR

EUROCONTROL Safety Regulatory Requirement

EUROCAE

European Organisation for Civil Aviation Equipment

IEC

International Electrotechnical Commission

RTCA

Radio Technical Commission for Aeronautics

SES

Single European Sky

SMS

Safety Management System

SRC

Safety Regulation Commission

SRG

Safety Regulation Group

[1] ESARR6 does not distinguish between software requirements required to fulfil non-safety functions and software requirements required to fulfil safety functions. This is because ESARR6 is only applicable to those software requirements that have been apportioned to software by the system safety process. Consequently ESARR6 only refers to software requirements, as by default they are software requirements that fulfil safety functions. However, this has been shown to cause confusion over the scope and applicability of ESARR6. To prevent this SW01 reminds the reader of the scope by explicitly referring to software requirements that fulfil non-safety functions as “software requirements” and software requirements that fulfil safety functions as “software safety requirements”.

Home | Members | Schedule | Archive | Search | Discussions | Contact Information | Members data area

 (c) Safeflight.co.uk
Last updated: 07-08-2005.