Wonderware Alternatives

[Shantelle Wenske]

Idont 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,.

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.

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.

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?.

I know this is a very specific question, but I'm hoping someone can help resolve this issue. We are hoping to start pulling in information from our PM8000 to our SCADA system using wonderware. I am using the default modbus registers. I have good quality in the connection to the device but only certain tags are pulling the correct information. For instance, Current A is pulling as an integer, Current B as a Float, and Current C and Current Average are showing 0. I am attaching the setup from System Management Console. Has anyone else encountered this issue? Volts mode is setup as 4W-WYE

Are you sure the master is polling Current C and Avg current? Lots of masters intializes holding registers (the tag for data it receives) to a value of zero. If not polled, the master register shows its initialized value of zero.

If you are using one based register numbers and mixing that with zero based numbering, you might be reading and interpreting the wrong set of registers. 32 bit floating point values require two adjactent registers, for instance Current B uses 43002 and 43003.

When attempting to read 43002 and 43003, you might be off by one and getting 43001 and 43002. The word/byte order changes when that happens, but I've seen where the resulting mixed-registeer value appear to be close to what it should be, yet be incorrect.

If it were me, I'd try disabling the zero based addressing function and then do whatever is necessary to try alternative word/byte orders until something reasonable appears and whether you get full FP values.

To expand on what PV_DAQ has said, have you tried to read the registers from the device with a modbus client other than the system you are using? tester.exe for example or modbus poll, ModScan etc. The idea would be to poll registers to get the explicit 16 bit values (some modbus clients can convert these into 32 bit floating point values for you). The point is to very that device is responding to modbus polls as expected. There are also online tools that can help you convert hex numbers into floating point numbers -schmidt.net/FloatConverter/IEEE754.html

regards,

I was contacted by a SAP customer looking to build a custom hana native adapters for Wonderware Enterprise Historian (as far as I can tell this is something different to the standard plan historian supported by the plant connector). The use case is to extract a batch of data for analysis. I was wondering if anyone has build something like this and has any code or advice to share - I didn't find anything on -native-adapters

The Java knowledge is the tough part as we don't have a Java programmer - 3 people on my team have experience programming in Java but all years ago. We can hire one of course or ask our customer to do so. We are waiting for feedback form the client's technical team on the alternatives but this does not seem likely to be successful at this point.

3a8082e126