I do agree that it would be nice to offer some slim options of ignition for smaller projects.
I dont think mqtt will ever take off and replace the various protocols like EIP, modbus, on end devices, etc. By using a gateway, you are basically just moving the tag creation from ignition to an edge device where you lose the great tools that ignition gives you for rapid tag development and configuration. bandwidth is getting cheaper than ever and there is much more of it. I dont know, but I just dont see this replacing the normal method of polling in your normal everyday industrial systems. My guess is that mqtt goes away long before modbus.
Also another scada software company that makes a good looking product has moved to a free licensing model. They basically give you a free license to the software but if you need support, training, or development they charge you an hourly fee. Im not sure if that is a sign of them going out of business or if it will be revolutionary in the same way that Ignition was when they came out with the one price fits all model. i looked at it some and it is definitely not as programmer friendly as ignition. Ignition really hit the mark with the sql integration and making so many properties of the objects available to scripting.
One big point where I think Ignition is lacking is html5 support and true mobile support. If someone comes along that can replicate the features of ignition but have true mobile and html5 they may just be able to grab some market share,.
comparing opc ua with MQTT is comparing apples with oranges! OPC UA is legacy protocol designed by non IT professionals from OT background, inspired by propitiatory COM/DECOM of Microsoft later migrated to XML then UA adapting to new IT technologies as it evolved to SOA and webservices and survived as a specification! Its time to think of a more suitable and simple alternatives like WOOPSA and PubNub etc which are lighter and easier to understand and implement !
Similarly people with IT backgroung try to apply all their knowledge of Enterprise applications like JAVA/EJB/Servlets/SQL/NOSQL etc to Automation which is an overkill! What is required is an optimum balance!
So far, SCADA has been mostly confined to a LAN, isolated from IT and internet. So entire bandwidth was freely available for OPC/OPC-UA to happily poll the PLCs/RTUs. I haven't seen more than 5 PLCs/RTUs connected to a OPC server in a manufacturing plant (not more than 20,000 tags). Beyond that, it will be a nightmare and performance will degrade. IOT is meant for data collection and remote management of hundreds and thousands of remote PLCs and RTUs talking to a cloud SCADA to build a smart infrastructure. OPC/OPC-UA is unthinkable for IOT, apart from security and encryption issues.
In short, OPC-UA is good for highly critical manufacturing plants within a LAN environment. I wish, Linux based OPC-UA servers too enter this market. IOT is for smart infrastructure management and cloud based SCADAaaS business.
Where do you get that idea from?
We have systems running ignition currently that are talking to over 10 PLCs and much higher tag counts than that.
We also have the Enterprise historian hitting multiple locations and logging tags over WAN connections with no slowdown or degradation of performance.
It depends upon how critical the process is and how much loss will a SCADA downtime would trigger?. 10 PLCs + 50,000 tags per OPC-UA server across WAN is definitely possible but not very common. I would prefer to divide the load across 2 OPC-UA servers.
In IOT, we are talking about data collection and remote management of 100's of remote PLCs/RTUs. It's simply not possible with OPC-UA technology. Having said this, for a critical manufacturing plant, i will definitely choose OPC-UA and not MQTT as of today.
I admire and respect your brutally honest views. cheers
It is possible, although maybe not ideal, but MQTT doesn't really solve the problem either. Unless an RTU has MQTT capabilities built in you still need a box sitting next to each RTU to poll the RTU and publish to a broker. If you're going to have a box sitting next to each RTU then that box could have an OPC UA server on it rather than be publishing to a broker and you'd just be looking at a set of trade-offs based on what each protocol offers.
It will be interesting to see what happens in the next few years in regards to the OPC UA PubSub spec.
Recently i had a discussion with cirruslink support. I found these links address some key issues.
1. Is MQTT a better alternative for OPC-UA?:
We need more demos, load tests, benchmarks, white papers, videos and webinars on this topic. MQTT embedded device and Edge device manufacturers must come out openly and deal with this issue head on.
Very interesting. Can you please share more details on this?.
RTU protocol?. (Modbus or DNP3 or MQTT etc)
a mix of Totalflow and Modbus
Which OPC server?. Autosol and Universal Serrver(formwer product of wonderware but no longer available)
Does the OPC server poll each RTU periodically or is it a MODBUS slave? periodically, usually 30 minutes or so but sometimes faster
How do you download the remote datalogs from each RTU and merge it with the Ignition historian?.
Totalflow supports storing archive data, opc servers that support this protocol will store the data after retrieving in a special database table structure. from there you could move it to your own table or ignitions historical table using the write tag history function.
If you like, you can explain the architecture in detail. May be we can work together when the opportunity comes up . Thanks.
The remote RTU data logs are time stamped by the RTU. If Ignition Historian reads and writes these tags again into the historical table, it will have only the local time stamp and remote time stamps will be lost. This is NOT acceptable. How to deal with this situation?. Any suggestion?.
Very interesting but i don't understand how it works. A demo project can help a lot. I have attached a sample datalog history from a remote rtu. You can modify to any format you like.
. Thanks.