5 common mistakes when implementing supervisory logic in your LabVIEW based ATS

We work a lot with batteries and fuel cells. Our client can really take advantage of the advanced troubleshooting features of our platform but they need to be certain that the system is fail safe. A good supervisory circuit begins with a hardware protection layer in case the software “fails” but this is not as simple as it seems to properly detect.

Symplify has 4 layers of safeties within the software alone to guarantee a safe operation and our SBX enclosure typically handles the hardware interlocks and e-stop chain.

If you have to implement your own supervisory logic, be aware of the following 5 typical mistakes we’ve seen in the past:

1. Limiting the protection up to the software
   Protection in the software is the first layer of safety and will protect you 99% of the time from typical fault conditions. Be it over voltage, over-temperature, over-pressure, etc. but what happens when the control software becomes un-responsive? Under speed relay is one of the most common hardware protection. The control software communicates with this component using one or more digital output (we reserve output 2 lines from the NI 9375 – LINK inside our SBX enclosure)
2. “Kicking the watchdog” with a hardware timed DAQmx task
   Relying on a hardware task to generate a train pulse pretty much voids the purpose of the watchdog device. The application health is pretty much taken out of the safety loop and nothing can detect that the software is unable to complete its task of monitoring pressure and temperatures.
3. Not monitoring other software code modules
   What happens if the communication with the power supply driver hangs and the voltage feedback is no longer updated in your application? Having a “blind” portion of the control software generate the “Kick” for the watchdog only protects your automated test system if the entire OS or application fails, not from localized failure.
4. Putting the hardware timer too fast
   Windows can do 10ms most often but every now and then, it slows down to run other processes. This is especially true if some logic runs with their Front Panel visible. We typically set the watchdog timer to 2.5-10s delay. As most catastrophic situation take minutes to build up (over-temperature conditions), keep your watchdog timer generous to Windows to prevent unnecessary test interruptions.
5. Cutting powers to power everything
   Adding a good protection circuit must only prevent further energy from being supplied to the system (current, pressure, gas, etc.) Sensors should keep power to allow you to analyze the entire events, including cooldown. Some digital outputs also need to keep their power so the Supervisor can recover from the fault state. Look at our SBX Flyer to see how we offer both “Safe” and “Always On” outputs.

Last, don’t forget to complete a thorough validation of the supervisor logic during the initial development as well as with any release of your source code!

1. Test the warning level and alarm levels along with durations. You can either enter simulated values directly in the software or generate hardware signals (typically directly a 0-10V, 4-20mA)
2. Verify that if one portion of the code stop executing, the supervisor detects it and stops kicking the watchdog
3.  Confirm that once the watchdog relay opens up, restarting the kick doesn’t turn it on. Further action, typically manual, is required to reset it.