Want to improve your safety lifecycle and be more compliant with IEC 61508?  Focus on the things that have the most benefit.  Like what?  What are some of these valuable things?  

One of the major deficiencies I see while doing certification assessments is the lack of good architecture design procedures and documentation.  The architecture design step is often bypassed or shortcut in lieu of moving ahead with the implementation efforts and ‘getting something done’ (i.e., writing the code for the software functionality).  But doing a good job on the architecture design IS getting something done… perhaps one of the most important things after writing the requirements.  As the architecture design is the most relevant part to the requirements, it makes sense to have iterative efforts between requirements reviews and architecture design reviews to develop a complete and cohesive product design.  If there are disagreements at this phase of the lifecycle, they can be resolved with fewer ripple effects on the entire project schedule.  Finding problems early is the goal.

The time spent on architecture design, especially in a graphical way (connecting the big functional blocks), is certainly worthwhile because it allows you to see how things fit together.  Moreover, it puts the whole design team on the same page as all team members can see and understand how their piece is connected to the whole.  This step lets you see the user interfaces between the parts (like HMI and configuration parameters) but it also shows the interfaces between the functional blocks themselves, what information is shared, and how it is shared.  This is also important for integration phase testing.

FMEA (for HW design or SW criticality analysis), also called DFMEA, is a systematic approach to finding holes in the design.  This methodology is used to identify failure modes and determine how to avoid or control them with mitigations.  It can be used to support independence needed when only parts of the design are involved with safety functions and other parts are not.  All parts of the design will need to meet safety criteria unless this independence can be demonstrated.  Check out the exida ARCHx tool for a look at an improved FMEA approach.

More specific to the software development side, a second deficiency I see is with software module testing. This step traditionally has been the most informal of all development steps; once the design is behind schedule, folks start to focus on implementation as a shortcut to ‘catch-up’ (self-documenting code, right?), and they really believe they can test their software with rudimentary tests and then combine it with everyone else’s software and let validation testing catch the defects.  If you think about every software module as a building block that may later get reused, you start to understand the importance of well-tested code that has a solid track record and is supported by well-planned tests.  Investigate equivalence class and boundary value techniques for software module testing to focus on meaningful tests without doing more than is required.  A little extra time spent in test planning can save a lot of time in repairing field defects.