I am having a heated debate internally with my colleagues. I am proposing a process control system for a small GMP facility (around 750 datapoints).
My approach is to use smart devices on the floor (instrument, sensors and valves), that report locally to an RTU/PLC with an OPC server that we connect to Ignition. However, my proposal is to keep the RTU/PLC "dumb", so the Controls Logic is developed directly in Ignition. Being a validated environment, if I remove the programming from the RTU/PLC I am saving tons of money in validation, and putting my customer in a much better position for future changes, since they will only validate and maintain Ignition (CSV is extremely costly).
I understand the traditional approach is to maintain the PLC for real-time control logic execution, and SCADA to sit on top as a tool for monitoring, reporting and visualizing data. I also understand the reason behind this is PLC reliability (hardware has proved its function, it is understood by the community, plus it is hardwired). I have heard concerns about the entire operation going down if there is a failure in the network.
However, I strongly believe that network uptime can be optimized with redundancy, as well as business continuity can be enhanced with Ignition Gateway redundancy (automatic failover).
By removing PLC programming from the equation, the end user can implement much quicker changes, because now you don't have an arrange of PLCs on your floor, each from a different model and brand.
I would love for the community to comment on this. Is transferring control logic programming from PLC to SCADA a real opportunity? Would the size of the project and application influence this opportunity?
I probably should have used a different word other than "dumb". The PLC will be used to contextualized and configured data points (mapping, assigning attributes) and also to execute the logic, but they will not hold the programming. They sit between the floor and SCADA managing the communication. Logic to be fully developed in Ignition.
Your understanding of how a PLC works must be different than mine then. Last time I checked a PLC will continue to work without a SCADA system or HMI connected to it. So what wire to the PLC are you cutting?
Also, how exactly do you develop logic in Ignition and then download that to a PLC? What type of PLC are you using?
No, I understand what you meant. The PLC should do the controls, think of it as standalone... if the HMI is not operating or connected the PLC should still control. The HMI should just be thought of as visualization.
What you need is a virtual PLC like codesys. There is a trend towards running PLCs as soft PLCs into containers and virtual machines. This is called Industry 5 standard. A true IT/OT convergence where controls will run on containers and virtual networks not hardware PLCs!
Hello Pramanj. That is exactly the idea. The programming living in a centralized location, and being pushed from there into the PLC to execute the action. The PLC will still be present in the architecture proposed, but it will be a soft PLC as you indicated. Do you propose a more efficient tool to program tasks and SOO in a VM?
While soft PLCs might be an answer (unless they running Windows--Ugh), SCADA is usually not a good choice for direct control. (Ergo, the "S" in SCADA.) It is possible (and I'm the author of a module that adds I/O scanning capabilities to Ignition), but takes careful consideration of the operating environment, particularly the impact of pseudo-random java garbage collection pauses on your control algorithms. That by itself will probably prevent validation for a direct control application.
Having a true real-time control platform running the control algorithms, and not subject to any UI disruptions (a particular issue with Perspective), strikes me as a fundamental requirement of a validated system.
If you still keep PLCs for IO and do the logic/control in SCADA server, then it doesn't really save cost! If you just have IO (like OPTO 22 or National Instruments) connecting plant with SCADA server thru ethernet and do logic/control on virtual PLCs on SCADA server, then it saves you lot of cost. This IMO is doable provided your plant IO and logic is simple (which perhaps in your case I believe is!) and Server is of high end with large RAM and processing power so that the garbage collection etc like tasks don't hog the processor time and you still have deterministic response of the virtual PLCs for all practical purposes from your plants perspective.
NI's LabView allows you to program the control loops as well as do data acquisition and process visualization/control from PCs. It connects to their Compact RIO boards for IO thru USB/Ethernet ports etc. So it does both SCADA and controls from PCs for small automation tasks. Don't know if that meets your requirements.
I have yet to see someone implement a “soft” PLC that was not contained in some obscure black box. If you have access to credible event logs from the soft PLC to properly troubleshoot a problem, then I may be ok with a soft PLC.
The ones I have worked with from different OEMs all run on a Windows PC inside an InTime environment.
It sends cryptic event logs to Windows Events with worthless information when something crashes.
Maybe the big players have better implementations, but my experience has been awful.
May be technology is yet to mature, perhaps dedicated cores of a multicore CPU server, for each SoftPLC may bring more determinism and provide answers to and alleviate some of the problems faced by present day situations. Also use of compiled code on server side rather than today's interpreted or intermediate language code like JAVA, Python, JavaScript, C# for achieving platform independence would bring more real time, deterministic and low context switching response to servers. This is acceptable for IT applications but may not be ok for real time deterministic applications. That may sound futuristic but as of now your observations are absolutely correct !
