Today, April 15th, is tax-day in the US.  Ok, the Internal Revenue Service (IRS) has given us a few extra days this year (the tax filing deadline is not until April 18th).

There are a lot of similarities between how you do your taxes and how you handle your functional safety.  As for filing taxes, some choose to:

• Hire an accountant (3rd party)
• Buy a software program to guide them through the process
• Manually complete the required tax forms

When it comes to functional safety, I see the same approach. There are end-users (owners/operators) that:

• Hire a 3rd party to assist
• Buy a software program
• Use an in-house program /spreadsheet

I’m using a software program to guide me through my tax forms. My taxes are relatively straightforward, and the program guides me through the various forms. Despite that, I still want a second opinion on some of my selections, in my case that means I’m asking my wife.  It did trigger a thought:  Am I competent enough to complete my own taxes?

This same question should be asked when it comes to functional safety: Am I competent enough to perform a certain task? Sometimes that question becomes a question of my 3rd party consultant’s competency.

I have a current project where we are being asked to review the Safety Requirements Specification (SRS) and SIL verification produced by another consulting company. Why would an end-user hire a 3rd party to review the work done by another 3rd party? Well in this case, something smells bad.

• The SRS doesn’t address all the required attributes per IEC 61511, nor is it clear on what the safe state is of each SIF.
• The relationship between inputs and outputs documented in the SRS is not specific enough for SIF identification, contradicts what is modeled during the SIL verification, and doesn’t agree with what is documented in the project Cause and Effect Matrix.
• The SIL verification uses proof test coverage factors of 100% and diagnostic coverage factors of 100% for logic solver dangerous failures.

One may expect that even a novice in functional safety would realize that these assumptions are unrealistic. Furthermore, in some cases the SIL verification doesn’t address minimum hardware fault tolerance requirements, whereas in other cases it is indicated that a mix of IEC 61511 and IEC 61508 architectural constraints are applied without clearly specifying which are considered, and for what subsystem.

I am glad that in this case the end-user realized that the provided reports are inadequate, and rather than blindly accepting the 3rd party outcome, is looking further into the matter. Similar to the IRS, you’d rather not have an incident/accident investigation, or a tax audit.

I hope you will receive a large refund ?