I consistently find that with companies who are new to functional safety development, the SW process is not as structured or mature as the HW process. SW development is often more informal, and subject to the interpretation of one or more SW developers. But when project delays occur, it’s usually due to SW and chaos can result without a well-defined SW process. One key is to adopt and follow an overall lifecycle process that outlines the development phases and expected deliverables of each phase. However, even then it can be difficult to get the entire team on board. There’s a principle in reliability engineering called “stress vs. strength,” which simply means that failures occur when a given component’s strength factor is exceeded by some stress factor. If you think about your development process as a component, it has to stand up against a number of stresses. If you’re having trouble initiating, or getting buy-in to, a formal software process, it may be due to one of these stress factors:
|
Stress factor influence |
Strength factors to apply |
|
software developers may choose or use different tools; |
Create a procedure to evaluate and select tools based on objective criteria and functional safety requirements of IEC 61508. |
|
software developers may have various coding styles (comments, format, obfuscation); |
Create a coding standard that specifies code structure and style, advocates safe constructs to use and unsafe constructs to avoid, and is enforced by a static code analyzer. |
|
software developers may feel that some rules don’t make sense or don’t apply to them; |
Create code review guidelines with objective criteria and checklists; provide training on code review; incorporate a formal bug tracking system. |
|
software developers may have varying ideas of what unit and integration test means, or how much testing is required; |
Create test criteria based on the techniques and measures recommended in IEC 61508 Annex tables. Define integration test plans during architecture design. Define module test plans during detailed software design. |
|
Little or no formal test plans are created for unit testing; only have developer’s statement that any testing was performed (“my code always works right!”); |
Define test methods and techniques to be used when creating test plans. Use test plan reviews as a means to correct and enhance test techniques. Review module test results prior to integration and validation testing. |
|
It’s too easy to justify bypass of a formal process to meet deadlines; changes occur without any traceability to design or requirements; |
Create a verification plan with a checklist so that a development phase is not complete unless all planned activities are complete; create realistic schedules that include all safety activities; incorporate impact analysis techniques and a formal change request process. |
All of these strengths are needed to comply with IEC 61508. But even applying these strength factors gradually over time should help to promote a cooperative atmosphere and improve software quality.
Tagged as: stress strength John Yozallinas IEC 61508