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  

Other Blog Posts By John Yozallinas