It’s interesting that the majority of the time when people talk about functional safety, they are usually thinking about hardware: what sensors to use, which logic solver, what actuator, solenoid or valve to select; what voting architecture, etc.  What often gets overlooked, initially, is the application program.

Essentially, when it comes to the application program, we need to follow a similar approach to the hardware.  For example, there needs to be a set of application requirements specified; validation planning; application architecture; simulation and integration test; verification.  In essence, this should be defined within the SIS SRS or could be a separate Application Requirements Specification, which defines the requirements for each SIF.  These requirements are covered under clauses 7, 10, 12, 13 & 15 of IEC61511.

IEC61511 defines 3 types of programming languages:

• Fixed Programming Language (FP)
• Limited Variability Language (LVL)
• and Full Variability Language (FVL)

It should be noted that only FPL and LVL should be used with SIS programmable devices, because if any function blocks and/or programs are written using FVL, then these SHALL have to be developed to comply with IEC61508-3.

One of the most common ways of defining the application requirements is using a form of function block or logical diagram.  Most logic solver suppliers provide tools to help with application program development and testing.  However, care should be taken when choosing which of the 5 programming languages listed under IEC61131 since only 3 are regarded as being “Limited Variability Language” (LVL).  These are: Function Block, Sequential function chart and Ladder Logic.  Instruction List and Structured Text (being the other two) are regarded as FVL and should not be used.

For this reason, it is highly recommended to develop a set of programming guidelines and/or procedure that Application Developers need to follow.  This is where a checklist approach can be useful too.  When I teach our FSE100 course this is something that I always emphasize strongly.  All too often, programming engineers love to reinvent the wheel.  This is because their software is so much better than anyone else’s, which may be true, but if they revert to using FVL to develop a specific function block and/or set of code, without following IEC61508, then this will compromise the SIF(s) SIL integrity and hence fail the SIL verification from a systematic point of view.

Furthermore, if the application program of the SIS is designed to implement safety and non-safety, then it must follow the requirements for safety.  In addition, it must be proven from assessment and/or testing that the non-safety functions cannot interfere with the safety functions.  This is another reason why the SIS should only be handling safety functions and the non-safety should be in the BPCS or other controller.

Reuse of proven, project-specific, library functions used previously should be encouraged, where applicable, to help minimize systematic errors.

If this blog has piqued your interest, then look out for the upcoming webinar on the topic of SIS Application Programming…