PL calculations on SW, not HW

[spaderkung]

In a safety circuit it's clear how to use sistema or similar to calculate the PL given hardware components. But how are various degrees of pure SW handled? For instance, in a PLC with a safety program, there's a CIP-phase status (running, held...), , sent in to the safety program, and there combined with other logic to stop a motor. So, no HW input HW output circuit, instead a Code input, HW output circuit.

 

[mk42]

In theory, the PLC and programming software compiler have been pre-certified, and have diagnostics and error checking built in to ensure that the PLC does what the program says to do, up to a given reliability value. In AB land, my understanding is that the safety CPU itself has one reliability value (good for SIL2) and another reliability value in conjunction with the safety partner (crosschecking/reliability/diagnostics get it to SIL3). This is what you would use for sistema evaluation, regardless of the programming that happens inside of the PLC.

At least in Siemensland, profisafe has enough errorchecking built in that networking is considered a negligible enough source of error that it can be ignored in the safety reliability calc; I assume the same is true for CIP safety, but I have no experience there. HOWEVER, network architecture can have an influence on reaction time, so keep that in mind for those calcs.

However, you still need validation/system test afterwards to prove that the program in the system actually does what it was it was intended to, which is very different from the system reliability itself.

 

[spaderkung]

In theory, the PLC and programming software compiler have been pre-certified, and have diagnostics and error checking built in to ensure that the PLC does what the program says to do, up to a given reliability value. In AB land, my understanding is that the safety CPU itself has one reliability value (good for SIL2) and another reliability value in conjunction with the safety partner (crosschecking/reliability/diagnostics get it to SIL3). This is what you would use for sistema evaluation, regardless of the programming that happens inside of the PLC.

At least in Siemensland, profisafe has enough errorchecking built in that networking is considered a negligible enough source of error that it can be ignored in the safety reliability calc; I assume the same is true for CIP safety, but I have no experience there. HOWEVER, network architecture can have an influence on reaction time, so keep that in mind for those calcs.

However, you still need validation/system test afterwards to prove that the program in the system actually does what it was it was intended to, which is very different from the system reliability itself.

Thanks,
As long as the SW is in the safety part, then a SW change also has to be re-validated. Fine.
But we usually send signals from the rest of the program in to the safety part. And in this case the safety program is unchanged, but the actual output can be different.
Of course, the validation of the normal program should be performed as always. But in this case the behaviour of safety code can be different without any changes in the safety program. It is this discrepancy I'm unsure about.
But as I understand you is what we have discussed ourselves, that the code is always ok after validation (it does not change by itself), and that the PL calculations handles hardware errors where components have a failure rate.

 

[mk42]

The safety program should always be able to shut down if it wants to, regardless of data in the standard program. The safety program can also shut down if the standard program requests it. The "behavior" of the safety code doesn't change, but it may be reacting to non-failsafe data in addition to the safe data.

As an example, you could, if you so chose, trigger the same reaction in the safety code to a standard stop as an Estop (standard button is put in the estop chain in the logic). If the standard stop bit triggers a safety shutdown when it isn't expected, that's a bummer for productivity, but doesn't cause an unsafe condition. If the standard stop bit doesn't trigger when you expected it to, it might be bad for the process, but nothing "unsafe" happened, and you still have your estops if needed. In this scenario, as long as there isn't any way the standard stop bit can prevent your estop bit from shutting the system down, you're good. You've just added a SIL1 or PLa or whatever stop function to all your potentially sil3/ple estops.

 

[spaderkung]

Yes.. That first part "shut down ... regardless of data in the standard program" is what it's about... Thanks.