Sure, you might think I’ve got it made… sitting here on my perch telling you what you need to do to meet IEC 61508, while you sit there with all the work to do.  Well, it wasn’t always that way.  I was in your shoes, responsible for achieving functional safety on systems and product development for a large international company.  And I worked with development teams to help them understand safety integrity techniques and measures.  And I helped draft the FSM plan and SRS and test plans and impact analyses.  And I presented our arguments to the certification agency to show why our product satisfied the requirements.  And the agency would say “Hmmm, what about this?   It’s not quite good enough.  Can you give more details?”  And I would wonder “How are we ever gonna get this done?”

Those development days may be behind me, but I still think about ‘getting the job done’.  I just have a different perspective now, and I try to focus on things that make sense.  Here are a couple:

Full system and software architecture descriptions

Even if good requirements exist, the architecture step is often bypassed in lieu of getting something done (which usually means writing the code).  The time spent on architecture design (connecting the big blocks), especially in a graphical way, allow you to see how things fit together.  Moreover, it puts everyone on the design team on the same page.  This may not seem so important in the first release (when everything is fresh in your head) but it is VERY important for subsequent modifications that might be done years later.

Software module testing

This is usually the most informal of all development steps in normal development teams.  Once the design is behind schedule, folks start to move to implementation as a shortcut to ‘catch-up’ (since everyone uses self-documenting code, right?), and they really believe they can test their software by just combining it with everyone else’s software.  If you think about every software module as a building block that may later get reused, you start to understand the importance of getting it right and meeting the requirements.  Having a set of dedicated and re-usable SW module tests is an invaluable tool for retesting after a future modification.  Getting a good tool to automate the module testing has shown to pay big dividends in development time… after the initial training and setup is complete.

These are two areas that are problematic in new certification projects where the company and project teams have little experience with functional safety.  So if you start thinking about these things early and included them in your project scope, the certification effort will probably be a lot smoother.