A Checklist for Software Safety
By: Dr. Connie Clayton
Why do I need to worry about Software Safety? What does it mean? What will it get me in the long run?
The Department of Defense has many System Safety standards written to support embedded systems software development. Shouldn't the regulations be good enough? I recently tackled these issues in a study involving a DoD contract.
MIL-STD-882 has multiple versions released and is referred to when working with software safety. Other guidelines are listed in the references.
Having to refer to standards when developing a software system takes extra time and money. It would be so much easier to not have to refer to guidelines to make sure software followed the same guidelines from beginning to the end of a project or from one project to another. It also costs so much more to have to do this.
There have been multiple occasions that prove that if there was a systematic approach to developing system software, mistakes could be detected before, for instance, the pilot found out too late that there was not a fail safe setup for the engine that failed, or there were too many final checks for a fighter pilot to release a missile and it was too late. These type of examples show that if time and money was spent at Day 1 for a good safety software program, money and lives would be saved at the end of the project. It is important to take a long term view from the beginning. There must be some type of tracking system. The end user should have an active voice in the decisions. All players including the system engineer, the hardware engineer and the software engineer should be involved from the beginning throughout the life time of the project. It is unrealistic to expect a software engineer to walk in after a project has been in the works for years and ask them to figure out what the problem is with the code. This a very costly way of doing business. The software engineer must do, essentially years of research to discover what was previously done, in a few months and then give an educated guess as to what the problem might be.
It was the goal of this study to develop a basic checklist that could be used by software safety engineers to use from the beginning, throughout the life cycle, and throughout deployment of a project.
A good Safety Program must be in place on Day 1. This includes doing requirements and design before starting to code. It is important to take a long term view from the beginning. There must be some type of tracking system.
The checklists have been developed mainly from MIL-STD-882D. They are set up to be used individually or in a combination. The checklists should be selected according to the type of work being done. A list of the checklists follows. Select the corresponding the lists and follow the guidelines for each to make sure each item has been included in each particular project.
GENERAL SECTION 100 PROGRAM MANAGEMENT AND CONTROL
Task 101 SYSTEM SAFETY PROGRAM
DI-SAFT-80100A SYSTEM SAFETY PROGRAM PLAN
Task 103 INTEGRATION/MANAGEMENT OF ASSOCIATE CONTRACTORS, SUBCONTRACTORS, AND ARCHITECT AND ENGINEERING FIRMS
Task 104 SYSTEM SAFETY PROGRAM REVIEWS/AUDITS
Task 105 SYSTEM SAFETY GROUP/SYSTEM SAFETY WORKING GROUP SUPPORT
Task 106 HAZARD TRACKING AND RISK RESOLUTION
DI-SAFT-80105A SYSTEM SAFETY PROGRAM REPORT (SSPPR) (refer to Task 106 or Task 107)
Task 107 SYSTEM SAFETY PROGRESS SUMMARY
Task 108 LAUNCH SAFETY PROGRAM REQUIREMENTS
GENERAL SECTION 200 DESIGN AND INTEGRATION
Task 201 PRELIMINARY HAZARD LIST
Task 202 PRELIMINARY HAZARD ANALYSIS
DI-SAFT-80101A System Safety Hazard Analysis Report (SSHA) (Refer to Task 201, 203, 204, 205 or 206)
Task 203 SAFETY REQUIREMENTS/CRITERIA ANALYSIS
Task 204 SUBSYSTEM HAZARD ANALYSIS
Task 205 SYSTEM HAZARD ANALYSIS
Task 206 OPERATING AND SUPPORT HAZARD ANALYSIS
Task 207 HEALTH HAZARD ASSESSMENT
DI-SAFT-80106A HEALTH HAZARD ASSESSMENT Report (HHAR), (refer to Task 207)
GENERAL SECTION 300 DESIGN EVALUATION
Task 301 SAFETY ASSESSMENT
Task 302 TEST AND EVALUATION SAFETY
Task 303 SAFETY REVIEW OF ENGINEERING CHANGE PROPOSALS, SPECIFICATION CHANGE NOTICES, SOFTWARE PROBLEM REPORTS, AND REQUESTS FOR DEVIATION/WAIVER
DI-SAFT-80103A ENGINEERING CHANGE PROPOSAL SYSTEM SAFETY REPORT (ECPSSR) (refer to Task 303)
DI-SAFT-80104A WAIVER OR DEVIATION SYSTEM SAFETY REPORT (WDSSR) (refer to Task 303)
GENERAL SECTION 400 COMPLIANCE AND VERIFICATION
Task 401 SAFETY VERIFICATION
Task 402 SAFETY COMPLIANCE ASSESSMENT
Task 403 EXPLOSIVE HAZARD CLASSIFICATION AND CHARACTERISTICS DATA
Task 404 EXPLOSIVE ORDNANCE DISPOSAL SOURCE DATA
DI-SAFT-80102A SAFETY ASSESSMENT REPORT (SAR) (refer to Task 301, 401 or 402)
SUMMARY and CONCLUSIONS
This checklist should provide a better understanding of the safety process. It will provide the ability to determine where in the life-cycle an error occurred. Using a tracking system, previous projects can provide information for new safety projects and intelligent decisions can be made from past experiences.
To read more articles, visit http://sqa.fyicenter.com/art/