If you’ve got lots of proven field history for a product, you should be able to claim that good work and get your product certified for use in functional safety applications.  It is certainly still a challenge, but it is easier than certifying a new product.  The premise is that if you have at least some basic project documentation and your field failure rate is low enough, your product was probably designed well in the first place even if strict adherence to IEC 61508 was not followed.  And there are a number of certified products in the field today.  

You might already have a certified product using Proven-In-Use (PIU) methodology.  And maybe you have more than one PIU product certified.  But sooner or later your old PIU products will be obsolete and you’ll need to develop a new product to replace them.  And this means compliance with all the prior waived requirements of the IEC 61508 standard.  So what do you do?

You can start with a gap analysis of your current processes against the process requirements of IEC 61508.  Nearly 60% of these requirements are process-related, so not having a compliant safety lifecycle process is a hurdle.  The gap analysis can be done on your own or can be facilitated by exida.  (The exida SIL3 safety book)  Once the gap analysis is done, you’ll have a list of identified actions (or gaps) to raise your process to compliance.  When you review the action list, determine what part of your current process can be changed or tailored, and what parts may need to be replaced or created.  It is usually possible to follow a current, simpler development process for non-safety projects and an extended process for safety projects.  You just need to meet the rigor of the appropriate techniques and measures describes in the standard for the SIL you want to achieve.  And you may need to meet different SILs for different projects so be aware of the differences (for example, between SIL 2 and SIL 3). 

Even if you can’t update your development process fast enough, a Functional Safety Management Plan (FSM) can serve as a temporary proxy.  In this case, the FSM plan would identify specific safety activities needed for a specific project.  The key is that it is comprehensive to define all the lifecycle activities and deliverables for each phase of the project.  When done correctly, the FSM can serve as a checklist for your other process improvements.

Once you identified all the new process things you need to support for functional safety, it’s time to create the project deliverables.  Assigned someone responsibility for each deliverable.  It is important to have a formal document trail that adheres to your new formal process.  The most frequent response I get while conducting a gap analysis is “we do that”.  But when asked to show evidence of the activity, the response is “well, we don’t write that stuff down”.  This is especially true for activity and phase reviews, which are important verification steps during the development.

Some key review areas are:

• Safety requirements
• Software safety requirements
• Software lifecycle support (module test plan, coding standard, code coverage metrics, code reviews)
• Test plans
• Traceability matrix

I hear you saying “we know what we’re doing”.  I bet you do.  But I have two words for you… “SHOW ME”.