Is Ignition a real-time control system?
If so, how is this implemented?
I do not understand what is the speed of obtaining timestamps…
I suppose it depends on your definition of “real-time”.
It’s hard to answer your question without more details. In the most common case, data points are polled from PLCs at some rate defined in Ignition and the timestamps are applied to those values as they are received. This is a bit of a simplification of how things work but without a better question I’m not sure it’s worth going into.
Ignition is not Real Time control system.
Real-Time timestamps come from Controler.
(also, PLCs are NOT Real-Time Controllers).
Real-Time timestamp means the actual time, when the signal change occurred, not when the value was registered.
No. Not by any definition I’ve ever encountered.
Pretty much every timestamp that Ignition generates uses millisecond resolution. However, due to java garbage collection and the lack of priority configuration, the best accuracy you can expect is a few tens of milliseconds, after spending considerable effort and using superior hardware. Otherwise, you’ll probably do no better than the low hundreds of milliseconds, and occasionally, >1000ms.
Ok. Then I do not understand what is meant by “Real-Time Historical Data”?
What is the context? These are 2 different things - real-time data is what is happening right now and historical data is what has happened previously.
Real-Time Control has a very specific engineering meaning: response time to control inputs has a provable upper limit in a specific system. Modern Real Time Control Systems generally guarantee very short latencies, like, often measured in microseconds, from an input signal change to the corresponding output signal change.
Real-Time Data is simply regularly updating readings of specific signals from a control system, typically with adjustable pacing. In Ignition, each individual signal (tag) is assigned a pace (read interval) via a scan class.
Historical Data is simply recordings of the above Real-Time Data, not necessarily at the same pace as originally read, and possibly skipping or statistically compressing unchanging values.
That’s great! Came closer to scan class… But the Ignition works on Java’s virtual machine… I understand correctly, don’t I? The ignition is not embedded in the core of the operating system?
Perhaps I do not know the specifics of the communication drivers, perhaps the Ignition records an archive of events regardless of the execution cycle of the program itself on the virtual machine. Please explain.
In the INDUCTIVE AUTOMATION work package, I see projects in the food processing, construction materials, petrochemical industry. But what could push the engineers to approve such a project I do not understand.
What projects of yours do you think have such hard real-time requirements and what other software packages are you under the impression meets those requirements?
Correct. Ignition is not a real-time control system because Java does not provide any response time guarantees. Nor do the operating systems it runs on.
No. If anything in the JVM or the OS delays a device read that Ignition is doing, then there will be jitter. And there is always some jitter. And if the delays pile up, you can miss an interval.
If you must record precise timestamps, code in the origin device (PLC) is usually needed, along with precision clock synchronization. Ignition can read the captured timestamps as regular data, as long as the corresponding events don’t happen too fast for the OPC driver to keep up. All of this is non-trivial.
I’m actually talking about soft real-time control systems.
In the Ignition, I’m concerned about the fact that with a PLC scan cycle <50ms, (e.g. Siemens S7-416 CS Brewmaxx/ProLeit) in conjunction with OPC, the Ignition can skip a series of events.
Brewmaxx/ProLeit somehow negate it, and logging comes with a timestamp accuracy of <100ms. It works all on WinServer2003 with not the most productive hardware.
Began to understand and then came across You
On systems that have met: Ammann 2000 Plus control system asphalt plant (QNX), DeltaV, is another story , RSU oil terminal (WinServ2003). Brewmaxx - brewery(WinServ2003). ProLeit-milk factory (WinServ2003). Intouch + Historian - through OPC but you can configure <10ms.
That’s what I meant.
You might find my Ethernet/IP Class1 Communication driver interesting. Won’t help you with Siemens hardware, though.
All of the above running on Windows, unless they use a real-time shim in place of its normal HAL, are not really guaranteeing <100ms accurracy. But they achieve it to four or five nines, and it isn’t in the control loop, so no one really cares about a rare skip.
And this driver it uses to connect? PG interface?
Ignition’s Siemens driver uses the “PC/Other” interface. It’s not currently configurable to use anything else.
You might be able to configure 10ms, but that does not guarantee that you receive an actual value every 10 ms. Like others already mentioned in this thread, there are a lot of factors to consider, like network delays, operating system delays, hardware overload, time synchronisation…,
To put it short, there is no SCADA system i know that can guarantee a sampling time.
If you can not accept a data loss, you have to program data acqusition and buffering in a real-time task in the controlling plc. Then use a handshake mechanism to transfer the data to your SCADA system. To qoute pturmel: This is not trivial and you won’t get it out of the box with any SCADA.
I don’t think that any engineer would come up with the idea to use a SCADA as a real-time control system.
I raised the question about the accumulation of historical data in real time. I apologize for off topic. And of course this SCADA operational control, nothing more.
You don’t have to apologize, in part because it’s not off-topic. Ignition and other SCADA systems aren’t real-time control systems – not even soft real-time control – but SCADA systems are supervising real-time control systems. PLCs are real-time control systems, after all. Latency guarantees keep getting tighter, but even 1970’s era PLCs would reliably read their inputs, run their scan, and set their outputs in a bounded number of milliseconds. They couldn’t do much in that scan, but they’d do it every time.
You just started your topic with a confusing collection of engineering terms.
Okey. Back to top.
I’m afraid I do not have enough English to describe the operation of the data archiving system in InSQL, DeltaV or OSI PI. Judging by the drivers you have an idea about these systems.
So my question is:
what are the means of collecting, compressing, archiving real - time data coming from PLC? In what format is this data stored? That’s what I meant when I asked about the real-time system, meaning that Ignition is a SOFTWARE complex.
Thanks for your patience.
There’s a whole section of the manual describing the historian. Ignition’s tag historian only does very limited compression, using a linear extrapolation algorithm that I can’t find right now. The SQL Bridge’s transaction groups do no compression at all.