The provider SMA ensure that any newly identified software contributions to hazards, event, or conditions found during testing are updated in the system safety data package. [SSS-060] Improper software safety implementation will be entered into the problem reporting system by the provider for resolution and eventual retest. Incomplete or ineffective test procedures can also be managed through the provider problem reporting and resolution process. The provider SMA checks the updated test procedures for completeness and approves the procedures prior to testing. The provider’s software safety test analysis will be available to the acquirer and the acquirer SMA at project formal reviews and system-level safety reviews and upon request. Refer to Section 6.3 of this Standard. Regression testing Regression testing (refer to SSS-051) can vary from a minimal retest of a few units to end-to-end testing. From a safety perspective, it is important that any changes made to the software be regression tested. Changes to the hardware will require hardware and software integration regression testing. From a safety perspective, regression testing needs to assure that any safety controls and mitigations, continue to work as required and that no additional hazard contributions have occurred as a result of the changes. The provider SMA needs to review the proposed regression test coverage and procedures to assure the safety features are adequately covered. Questions to consider: Do transitions between modes and states impact safety? Are changes to parameters, sequence or timing to change hazard controls, computing algorithms, and safety commands? Configuration managed software test suites, created during unit and CSCI testing to test the safety features such as controls, FDIR, and fault and failure recovery, will help make regression testing smoother and better assure safety coverage. SMA focuses on assurance that end-to-end functionality and known hazard controls still work. Software Safety Acceptance Safety critical software is considered accepted when it meets the requirements in this Standard and any additional contract, MOA, or MOU software safety requirements. Waivers and deviations to the safety requirements in this Standard are addressed in section 6.4 of this Standard. Software safety acceptance can be rolled into the system acceptance as long as the software safety features and ability to withstand faults and failures have all been proven at the appropriate level. of safety critical software is dependent on the functionality and “Certification” center implementation. Refer to individual center implementation of software “Certification” processes.
The provider SMA ensure that any newly identified software contributions to hazards, event, or conditions found during testing are updated in the system safety data package. [SSS-060] Improper software safety implementation will be entered into the problem reporting system by the provider for resolution and eventual retest. Incomplete or ineffective test procedures can also be managed through the provider problem reporting and resolution process. The provider SMA checks the updated test procedures for completeness and approves the procedures prior to testing. The provider’s software safety test analysis will be available to the acquirer and the acquirer SMA at project formal reviews and system-level safety reviews and upon request. Refer to Section 6.3 of this Standard. Regression testing Regression testing (refer to SSS-051) can vary from a minimal retest of a few units to end-to-end testing. From a safety perspective, it is important that any changes made to the software be regression tested. Changes to the hardware will require hardware and software integration regression testing. From a safety perspective, regression testing needs to assure that any safety controls and mitigations, continue to work as required and that no additional hazard contributions have occurred as a result of the changes. The provider SMA needs to review the proposed regression test coverage and procedures to assure the safety features are adequately covered. Questions to consider: Do transitions between modes and states impact safety? Are changes to parameters, sequence or timing to change hazard controls, computing algorithms, and safety commands? Configuration managed software test suites, created during unit and CSCI testing to test the safety features such as controls, FDIR, and fault and failure recovery, will help make regression testing smoother and better assure safety coverage. SMA focuses on assurance that end-to-end functionality and known hazard controls still work. Software Safety Acceptance Safety critical software is considered accepted when it meets the requirements in this Standard and any additional contract, MOA, or MOU software safety requirements. Waivers and deviations to the safety requirements in this Standard are addressed in section 6.4 of this Standard. Software safety acceptance can be rolled into the system acceptance as long as the software safety features and ability to withstand faults and failures have all been proven at the appropriate level. “Certification” of safety critical software is dependent on the functionality and center implementation. Refer to individual center implementation of “Certification” software processes.
nasa-std-8719.13c_0.docx