FRENCH%20PROPOSAL%20FOR%20ESARR6

1
FRENCH PROPOSAL FOR ESARR6
1 - BACKGROUND - 15/02/00 Kick-off meeting,
Presentation of the CAA/SRG input (SW01), Request
from the chairman to comment - 09/08/00 Second
meeting, Debrief of comments, Request from the
chairman to make proposals - 31/10/00 Third
meeting, Presentation of the French proposal 2 -
REQUIREMENTS FOR THE DRAFTING - High level
document (Rqt ? MoC) - Consistent with ESARR4 -
Consistent with the ESARR format - Achievable -
No retroactivity for existing SW
2
FRENCH PROPOSAL FOR ESARR6
3 - FRENCH PROPOSAL, GENERAL CONTENT - Scope
(p) - Rationale (n) - Applicability (n) - Safety
Objective (a) - Safety Requirements (a) - 1
subsection 4 general safety requirements
(principles) - 4 subsections 22 safety
requirements (high level safety requirements
derived from general safety requirements) (p)
partly addressed by this presentation (n) not
addressed by this presentation (a) addressed by
this presentation
3
FRENCH PROPOSAL FOR ESARR6
4 - SAFETY OBJECTIVE The objective of this
requirement is to ensure that the hazards
associated with implementing any software in a
safety related CNS/ATM system have been
eliminated or reduced to an acceptable level of
safety. To achieve this overall objective,
software assurance systems which provide
sufficient visibility that the software is
adequately safe, shall be implemented. These
software assurance systems shall ensure that the
CNS/ATM software can be entered into service with
an acceptable level of confidence and maintain
this confidence throughout the operational life
of the CNS/ATM software.
4
FRENCH PROPOSAL FOR ESARR6

• 5 - GENERAL SAFETY REQUIREMENTS
• - 4 general safety requirements
• The ATM SPs shall set up 4 software assurance
  systems
• - a SSAS (Software Safety Assurance System)
• - a SCMAS (Software Configuration Management
  Assurance System)
• - a SVAS (Software Verification Assurance
  System)
• - a SQAS (Software Quality Assurance System)
• SSAS SAL (SW criticality of the SW within the
  ATM system design)

5
FRENCH PROPOSAL FOR ESARR6

• SCMAS, SVAS, SQAS increase in stringency with
  the SAL
• The ATM SPs shall
• - expand the safety requirements into assurance
  objectives for SCMAS, SVAS, SQAS, SSAS
• - specify the variation in stringency of the
  assurance objectives per SALs (required to be
  achieved with independence, required to be
  achieved, not required)
• - ensure assurance objectives and levelling of
  assurance objectives ? acceptable level of
  design assurance and confidence in the CNS/ATM
  software
• SSAS, SCMAS, SVAS, SQAS ? accepted by the
  regulators

6
FRENCH PROPOSAL FOR ESARR6
6 - SAFETY REQUIREMENTS - SSAS ? 6 safety
requirements 2 Notes - SCMAS ? 5 safety
requirements - SVAS ? 6 safety requirements 1
Note - SQAS ? 5 safety requirements 7 - IN
SUMMARY The French proposal for ESARR6 gives -
ATM SPs a general framework to establish their
own MoCs (or to adopt existing ones), - and
regulators to play their roles.
7
FRENCH PROPOSAL FOR ESARR6

• 8 - SAFETY REQUIREMENTS FOR THE SCMAS
• - 5 safety requirements
• The ATM SPs shall define and implement a SCMAS.
  The SCMAS shall be documented.
• The SCMAS shall establish software configuration
  management assurance objectives. The safety
  requirements described in this section shall be
  used as a basis to develop software configuration
  management assurance objectives. The SCMAS shall
  specify the variation in stringency of the
  software configuration management assurance
  objectives per SALs.

8
FRENCH PROPOSAL FOR ESARR6

• The SCMAS shall state assurance objectives for
  configuration identification, traceability, and
  status accounting. These assurance objectives
  shall give sufficient confidence that the
  software life cycle data are under configuration
  control throughout the CNS/ATM software life
  cycle.
• The SCMAS shall state assurance objectives for
  problem reporting, tracking, corrective actions
  and change control. These assurance objectives
  shall give sufficient confidence that the safety
  related problems associated with the software
  life cycle data and activities are adequately
  addressed throughout the CNS/ATM software life
  cycle.
• The SCMAS shall state assurance objectives for
  retrieval and release. These assurance objectives
  shall give sufficient confidence that the
  software life cycle data can be regenerated and
  that delivery procedures are in place, throughout
  the CNS/ATM software life cycle.

9
FRENCH PROPOSAL FOR ESARR6

• 9 - SAFETY REQUIREMENTS FOR THE SVAS
• - 6 safety requirements 1 Note
• The ATM SPs shall define and implement a SVAS.
  The SVAS shall be documented.
• The SVAS shall establish software verification
  assurance objectives. The safety requirements
  described in this section shall be used as a
  basis to develop the software verification
  assurance objectives. The SVAS shall specify the
  variation in stringency of the software
  verification assurance objectives per SALs.
• The SVAS shall state assurance objectives for
  verification including testing, of the CNS/ATM
  software. These assurance objectives shall give
  sufficient confidence that the CNS/ATM software
  requirements comply with the CNS/ATM system
  requirements allocated to the software and that
  the software design and code satisfy the CNS/ATM
  software requirements.

10
FRENCH PROPOSAL FOR ESARR6
- .

• The SVAS shall state assurance objectives for
  verification of the target hardware and software
  resource usage by the CNS/ATM software, the
  CNS/ATM software timing performances, the CNS/ATM
  software adaptation data and the CNS/ATM software
  robustness to abnormal operating conditions or
  capability to recover. These assurance objectives
  shall give sufficient confidence that the CNS/ATM
  software properties related to the operational
  environment, are established.
• The SVAS shall state assurance objectives for
  verification of the CNS/ATM software verification
  correctness and completeness. These assurance
  objectives shall give sufficient confidence that
  the CNS/ATM software is adequately covered with
  analytic verification and testing.

11
FRENCH PROPOSAL FOR ESARR6

• The SVAS may state alternate assurance
  objectives for verification of non-developmental
  software (e.g. proprietary software, Commercial
  Off The Shelf software, etc.). These alternate
  assurance objectives shall give the same level of
  confidence than assurance objectives assigned to
  developmental software with the same software
  assurance level.
• NOTE The SVAS may use CNS/ATM system
  verification activities and/or CNS/ATM field
  service experience to achieve coverage of
  software verification assurance objectives.

12
FRENCH PROPOSAL FOR ESARR6

• 10 - SAFETY REQUIREMENTS FOR THE SQAS
• - 5 safety requirements
• The ATM SP shall define and implement a SQAS.
  The SQAS shall be documented.
• The SQAS shall establish software quality
  assurance objectives. The safety requirements
  described in this section shall be used as a
  basis to develop the software quality assurance
  objectives. The SQAS shall specify the variation
  in stringency of the software quality assurance
  objectives per SALs.
• The SQAS shall be independent from the SSAS,
  SCMAS and SVAS.

13
FRENCH PROPOSAL FOR ESARR6

• The SQAS shall include audits of the SSAS, SCMAS
  and SVAS for verification of efficiency and
  improvements.
• The SQAS shall include audits of the CNS/ATM
  software life cycle data to ensure that assurance
  objectives or alternate assurance objectives made
  applicable per the SSAS, SCMAS, SVAS and SQAS,
  are satisfied.

14
FRENCH PROPOSAL FOR ESARR6

• 11 - SAFETY REQUIREMENTS FOR THE SSAS
• - 6 safety requirements 2 Notes
• The ATM SP shall define and implement a SSAS.
  The SSAS shall be documented.
• The SSAS shall use the concept of SAL, which
  relate the CNS/ATM software criticality to the
  severity classification scheme in CNS/ATM. The
  safety requirements described in this section
  shall be used as a basis to rule the software
  assurance level determination. The SSAS shall
  provide the SAL as an input to the SCMAS, SVAS,
  SQAS.

15
FRENCH PROPOSAL FOR ESARR6

• Five SALs are identified which map onto the five
  severity classes given in ESARR4. SAL 1 indicates
  the most critical software which makes it be
  associated with severity class 1. SAL 5 indicates
  a software having no impact on safety which makes
  it can be associated with severity class 5.
  Intermediate SALs can be mapped onto the
  remaining severity classes, on a one-to-one basis.

16
FRENCH PROPOSAL FOR ESARR6

• The SSAS shall use ESARR4 and both the FHA and
  the SSA to determine the software assurance level
  
• ESARR4 is used to grade the severity of
  malfunctions or failures of the CNS/ATM software
  and corresponding adverse effects.
• The FHA is analysed for those CNS/ATM system
  requirements allocated to the software, potential
  malfunctions or failures of which may result in
  CNS/ATM safety related hazards.
• The SSA is continued with the process of
  investigating protective strategies or
  architectural attributes of the CNS/ATM system
  design that
• may preclude the CNS/ATM software from being the
  single source of CNS/ATM safety related hazards,
• and prevent those originating from the CNS/ATM
  software from being propagated outside the
  CNS/ATM system.

17
FRENCH PROPOSAL FOR ESARR6
NOTE Mitigation techniques used to minimise
CNS/ATM safety related hazard occurrences may be
architectural, procedural or both. Procedural
techniques for hazard reduction may involve
CNS/ATM operational procedures, preventive
maintenance procedures, etc. Architectural
techniques for hazard reduction may involve
partitioning, redundancy, monitoring, safe
subsets via encapsulation or wrappers, data
integrity checking, etc. Mitigation techniques
may allow to lower the SAL.
18
FRENCH PROPOSAL FOR ESARR6

• The SSAS shall allocate a SAL to any software
  pertaining to safety-related CNS/ATM systems
• The SAL shall be commensurate with the most
  severe effect as per ESARR4, that malfunctions or
  failures of the software may cause.
• The software may be apportioned a SAL higher
  (more stringent) than that originally determined
  by the SSAS, to address new functionality planned
  to be added during future developments or
  potential changes in system requirements
  allocated to software that may result in a more
  severe ESARR4 classification.

19
FRENCH PROPOSAL FOR ESARR6
NOTE CNS/ATM safety related hazards identified
in the FHA which are associated with software due
to design, may have no impact on the CNS/ATM
system as mitigation techniques may have been
implemented to make them transparent to CNS/ATM
system operations. In this case, the SSAS may
only require the SAL to be made consistent with
the actual impact of top level software related
events and corresponding safety burden that may
result on the CNS/ATM system operations. For this
purpose, the SSAS considers the number and
strength of procedural and/or architectural
defences established by the SSA, to determine
whether they affect the SAL.
20
FRENCH PROPOSAL FOR ESARR6

• The SSAS shall use the field service experience
  of the CNS/ATM software to confirm the SAL. For
  this purpose, the effects resulting from any
  software malfunction or failure reported from the
  operation field shall be assessed from the angle
  of their mapping to the ESARR4 classification
  scheme.

21
FRENCH PROPOSAL FOR ESARR6

• 12 - SCOPE
• This requirement applies to new software-based
  CNS/ATM systems.
• NOTE For the CNS/ATM systems already existing
  at the time of the production of this requirement
  and which are still subject to software changes,
  only the changes if any, may be affected by this
  requirement. The decision whether to apply this
  requirement, should be concerted with the
  regulatory body responsible for the safety of
  these CNS/ATM systems.

22
FRENCH PROPOSAL FOR ESARR6
13 - FRENCH PROPOSAL - Has been coordinated with
key STNA/DNA people - Is concise (5 pages long)
but complete and precise (safety requirements are
clear and cover the domain) - Is at the right
level in the ESARR hierarchy - Establishes
references with ESARR4 - Is consistent with the
ESARR table of contents - Is consistent with what
is done at present (COTS, well-known SW integrity
stds) - Gives responsibility to all players -
Does not prescribe any type of supporting MoC
(role of software assurance standards)