CLICK HERE to Read how LISI Automotive successfully implemented and went live with Plex and…
Internet Standard Protocols (HTML, RSS, XML, etc.): A Toolset to Bridge the Gap
As the Internet continues to evolve in it’s scope and functionality within an intra and extra-corporate network, more and more companies are seeking a way to leverage their existing machine infrastructure to provide faster, more accurate information to their already integrated business systems. The need for real-time plant floor information is becoming more critical than ever as companies focus on OEE, KPIs and Six Sigma initiatives. The ability to extract data from plant floor equipment in real-time has always existed, but the multitude of software, hardware and network topologies and protocols present in a typical factory floor have made the task fairly monumental. The challenges facing an end user when trying to collect and use live data are fairly universal, regardless of the type of equipment being monitored.
The first challenge is typically getting a communication network in place that can talk to each of the necessary machines. In most facilities multiple control vendors are used, meaning multiple brands and types of machine controllers. Even if one control vendor is used, there are almost always different families, models and sizes of the controllers in place. In an ideal world, all of the controllers would have a simple Ethernet interface and an open protocol with readily available, low cost (?even free?) communication drivers for integrating with PCs. In the real world, machines are generally islands within a facility with no connection to the rest of the site. The good news for this challenge is that most vendors newer products are far more open and networkable than those produced in the past. There are also innumerable companies out there producing bridge type products and drivers to connect older equipment to newer networks. So, we’ll assume that with a reasonable investment it is possible to connect the machines to the rest of your facility physically.
The next challenge is to actually get access to the information needed within each piece of equipment. To do so, you must have driver software on the PC network to poll the PLCs and make their data points accessible. Today, the most common driver technology used to allow PCs to access PLCs is OPC. This is a DCOM based standard that is supported by almost all plant floor integration software. Again, here the good news is there are dozens of major companies out there that create these drivers and they are reasonable inexpensive.
So now you can talk to your equipment – what do you ask for? It is reasonable to assume that the information you need in your upper level management system is not the same information the machine needs to perform it’s assigned task. Therefore, the chance that what you are trying to get out of the machine currently exists in the machine is slim. The difficulty here lies in the fact that the machines are probably all different in how they are programmed. Do you have software to be able to modify the PLCs to add the data your system requires? Do you have the expertise to make changes to the logic in-house? Does the PLC have spare processing and memory capacity to add the logic and fields necessary? Will you have to add inputs and outputs to the system to collect additional information? Here the answer might not be so easy and an engineering study would probably be best.
OK, the last challenge is to extract this newly created data from your machine via your newly implemented control network and make it useful to your business system. Here’s where the existing Internet technologies come into play. Most higher-level business systems today provide a way to integrate external systems using some sort of standard networking technology, such as HTML, XML, SOAP or Web Services. So, we have now arrived at the gap. What tools are available to take data collected from the factory floor and present that data using a standard Internet format – preferable without writing a lot of custom code?
A Toolset to Bridge the Gap
You’re here, so you have probably already Googled some combination of PLC, XML, integration, HTML, etc. I have too. The first exciting thing you will find is the OPC XML standard – it was a great idea that never really came to fruition and there are very few vendors supporting it. Next you will find a handful of questions and a few answers on various blogs, but no real answer. We were in the same situation when we were asked to create a web based machine integration system to connect a plant floor to an offsite, web hosted business system.
Doing it the Old Fashioned Way
The version 1.0 solution of performing the integration was via the tried-and-true method of using an off-the-shelf HMI package, lots of proprietary scripting and a handful of custom-written DLL objects. With a few hundred hours of development and testing, the system was launched with great success and is still running today. The customer does have changing needs and the plant floor is always changing in content and function, so when something has to be done differently, they call us, we add/change some scripting or possibly edit and recompile the DLLs and deploy. It is the standard way of doing things, right?
The Need for a Better Tool
That customized HMI solution worked great for the first customer, and when the second customer asked us to do the same type of integration – we naturally started with the same model. We took the original code, modified it to meet the second customers needs – new scripts, new DLLs. It all went well, and they are still running today. Then the third customer called.
The idea of continually developing custom solutions to each customers needs, making each pay for the customization was becoming harder to justify. As usual, brainstorming started and we decided that there must be a better, more modular way of solving the custom needs of each user. What we set out to find was the right base system we could use to allow web integration (not just display and interaction) of plant floor systems. It had to be open, it had to be powerful, it had to be modular, it had to be customizable, it had to include all of the tools we would need to make it a robust, re-usable base platform for a huge variety of machine types and platforms. And most of all, it had to provide the ability to make system logic and machine layout/quantity changes without scripting or compiled code.
The Better Tool
After exhausting all of the major HMI vendors and eliminating each for one reason or another, we ended up going a non-traditional route. While each of the HMI packages had most of what we required, none of them were the total solution, particularly when it came to allowing integration with external, Internet based systems. What we eventually found was a package from Tridium, Inc. called NiagaraAX. At first glance, the product is not designed for factory floor integration – it is very focused on the building automation market. Marketing aside, the product itself is extremely powerful and robust, does most of the things a traditional HMI does (graphics, alarms, trending, security, etc.) but at it’s core it is web based. It has block diagram type logic and is based on an open Java API that allows developers to create re-usable custom object to perform tasks not included in it rather large internal toolset.
Let’s go back to that third customer. What we were able to do, based on the Niagara platform is to create objects whose task it was to detect a machine state change, package the new machine state into an XML document and upload it, via the internet, to a web hosted business system. By creating the web transaction as an object, with a handful of properties needed to perform the transaction, we were able eliminate the need for any scripting or customizing at the site. In the picture below, you can see what the object and necessary logic look like.
Machine Status Transaction Object, with Logic
By dragging and linking property objects and other logic elements to the ProductionStatus object, we were able to drastically simplify what it takes to make the web transactions occur. What you see above is all that is needed to detect the state of the machine changing to “Production” (ProductionBit in the top left corner), package the “Production/OK” message for the “DemoPress” Machine Id into an XML document and, using basic authentication with the supplied username and password, upload this transaction to the web server provided in the Destination field. If the upload were to fail, the contents of both the outgoing XML request and any provided response from the server would be packaged into an email and sent to the provided email address based on the logic elements to the right of the ProductionStatus object.
What makes this so powerful is that the complicated piece, the XML transaction object, is completely re-usable. Within the Niagara environment, making copies is literally matter of right-click and “duplicate”. What makes that even better is that the system is tree and folder base. Each machine, for example, is represented by a folder. All data points, logic, graphics etc. configured for that machine are within that folder. So, to add another similar machine to the system, the end user simply duplicates the machine folder, renames it and changes the address/names of the data points. No scripting, no compilation, no custom code.
The example above is specific to sending outbound XML transactions from a factory floor network of PLCs to a web server. In addition to sending data, the same system can also receive incoming commands from the web to enable/disable the machine. Using a similar approach to the ProductionStatus object, a “Listener” object was create to accept incoming XML transactions from the web, validate username/password and then update the PLC with the data contained in the transaction. No scripting, no compilation, no custom code.
The above example discusses how, with the Tridium NiagaraAX platform, Kors Engineering was able to create relatively simple, re-usable modules to perform tasks that would be significantly more complicated using a standard HMI package. Because the Niagara system is 100% web based and the API is open, using the platform to provide interaction between PLC networks and business networks using standard Internet technologies is very straightforward. The example discussed used XML transactions via HTTP post transactions, but since then Kors Engineering has developed additional components that provide data via RSS, HTML tables and using the OBIX protocol. We are currently developing a means to use Web Services to perform the same types of data interaction. If you have questions or comments, please feel free to contact us at firstname.lastname@example.org.
Click to download this white paper