1 / 22

FRENCH PROPOSAL FOR ESARR6

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

xanthe
Download Presentation

FRENCH PROPOSAL FOR ESARR6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

More Related