cRIO in safety application

[AndyClegg]

Hi,

NI removed all of the old case studies some years ago. I've attached it just here.

A key thing in our system was that there was an independent safety system for major problems, and the cRIO/FPGA had to operate along side that and what the operator procedures were when faults arose - so the safety of the overall system has to consider all of these things, not just what is coded in LV.

I had a quick look at your other question, and it is more for somebody with experience in functional safety - see my reply above. The system we developed had a third party specialist do all of that stuff and we implemented what was needed in terms of the combination of cRIO with LVRT and FPGA with watchdog to meet the specific safety requirements derived for our application. In addition to good engineering practice, a lot of what was needed was driven by the requirements from the organisation doing the certification of the system.

[~Its_Me~]

Hello Andy,

Thanks for the upload. Think it looks impressive what you guys made! 

It is kind of hard to understand the safety part of the system though. In the system a cRIO was used and a safety relais. If there is fault which is dangerous for the people involved e.g. a dangerous high temperature. Is that handled by the cRIO and the safety relais or is it only handled by the cRIO? Maybe the safety relais is only used for the safety switch?

Thank you for the help!

[~Its_Me~]

Hello Andrew,

I am checking what needs to be done for a new testsystem I am designing. I am unable to get the proper reasoning if a CompactRIO can be used as a category 2 or 3 controller. It seems you have experience with safety of control systems. Can you please have a look at the forum link below and see if you can answer my question?

https://forums.ni.com/t5/Real-Time-Measurement-and/Can-a-cRIO-be-used-for-safety-of-a-testmachine-wh...

[AndyClegg]

Hello,

We've followed the same approach in several cRIO based systems which have to be linked to an external safety logic system for overall system safety:

• The saftey relay (e.g. Pilz is a well known brand) has the physical e-stop buttons wired into it, and pressing any e-stop activates the shutdown - which may involve removing power or stopping motion / closing valves. This is totally independent of the cRIO and any sw application it is running. If you have any very critical variables for safety (e.g. a high temp or extreme motion) then you may need a separate threshold sensor (normally on) and connect that to the Pilz relay, so that a high temp or whatever it is, also trips the system without relying on the cRIO to do anything.
• The cRIO also links to the Pilz. It can instigate an e-stop (via a DO), e.g.if cRIO detects a signal out of range or any abnormal condition (which can include CPU usage, free memory, timing jitter in a critical loop). The cRIO sw also needs to monitor the state of the Pilz relay (via a DI) so it knows if an external (to the cRIO) trip has happened and then do some additional things in the sw - like report to operator (for fault recovery and reseting the Pilz), put in system into a safe state etc. A watchdog running on the FPGA is also possible - which monitors that the RT sw is running normally - if the RT application hangs the FPGA can detect that and also instigates an e-stop (via the same DO). This watchdog was a important aspect of the functional saftey design in our system.
• In our particular application an e-stop was still a fairly extreme thing to do (last resort), so there was lots of layers of monitoring. This included reporting to operator when values were outside expected levels (so the operator could decide if any early intervention is needed), then if values got higher the software would automatically try to do a "soft-stop" bringing the system smoothly to a safe state - but still fully under control of the cRIO sw. It was only when the system detected extreme values would it do a full hard e-stop. This made the sw quite complicated - but our application needed that.

The thing to note is that the resulting safety level of the system is totally dependent on how it is engineered (design and implemented) and potential fault and risks involved, and the hardware used is just one aspect of that. A proper functional safety activity is essential to define the requirements of all the individual components, including people (users and operators), processes (standard operating proceedures, testing, certification), saftey relay, software functionality, and deep formal testing of full system (not just the sw). What we did for that application was sufficient for the particular faults / risks associated with that application, you may have something far more critical and needing a different safety functionality (for example, we didn't have redundant controllers).