Web-enabling your PLC

Advantech Australia Pty Ltd
http://www.advantech.net.au/
By
Thursday, 13 January, 2005

Enough has been written during the past couple years to convince most plant managers of the benefits of connecting plant floor equipment and processes to the internet or intranet.

For remote viewing of the data and/or web pages, the only requirement is a standard browser interface. For applications requiring SPC, optimisation, or enterprise level software to exchange real time data with the machine/process, a remote server PC and a compatible data exchange service are required.

In this system, the web server/data service device ('thin server') provides the connection between the machine or process and the internet. In a typical installation, a connection to an existing PLC or proprietary controller will be required to extract data or enable control over the equipment. Most PLCs, including products from ABB, Schneider/Modicon, and Siemens, support at least a serial connection using communication protocols available from the PLC vendor or third-party suppliers. In many cases, the communication driver will be available from the thin server vendor as part of the embedded software application.

If the equipment uses a standard PLC protocol or supports another open standard protocol such as Modbus RTU or TCP, then the job of connecting the thin server is usually greatly simplified. However, this is not always the case.

If the equipment in question uses a non-standard PLC or a proprietary controller, a connection to the thin server device is still possible as long as the controller supports some kind of serial protocol and the vendor can provide the protocol documentation. In this situation, either the thin server vendor or a third-party developer will be involved to implement the driver required to connect the thin server to the equipment controller.

In the extreme case, the equipment to be monitored may have a controller with no external communication port, or the protocol may be unavailable for some reason. In this situation, it may be necessary to externally instrument the equipment or process using additional sensors and I/O. These I/O devices can be installed to monitor strategic data or control points on the equipment. If this is required, the I/O devices should be chosen so that they support a standard communication protocol (eg, Modbus or an open ASCII protocol) and can be connected to the thin server. Alternatively, an I/O device may be selected that includes an integral thin server function. If the I/O device includes an integrated server, then the separate thin server may not be required.

With the thin server installed in the equipment enclosure and the proper driver installed or selected, the next step is to configure the thin server to link the equipment communication data and control (inputs and outputs) to the network link. The details of this step vary depending on the features and configuration software provided with the thin server. For example, a gateway server may simply map PLC registers to network variables or a remote PC connection. More sophisticated thin servers may allow configuration of a web page to view equipment data, enable alarm monitoring and data trending, add standard connectivity interfaces such as OPC, and may even support paging on programmable equipment fault conditions. Make sure that the thin server selected for the project supports an adequate feature set to allow for future expansion.

The internet or intranet (LAN) connection to the thin server may include a standard hardwired ethernet line, a modem/phone line, or a wireless connection (802.11b ethernet, for example). The type of connection is typically determined by the type of thin server and the existing plant network infrastructure - or lack of network infrastructure.

If a hardwired LAN already exists near the equipment to be connected, then a network connection is relatively simple with the addition of another cable drop to the equipment. If a hardwired connection is difficult or expensive due to complex cable runs or distances, a wireless connection may be the best alternative.

With a LAN connection established, the remote system with its application software can now access the machine equipment at the thin server's assigned IP address via the factory network. Applications such as an SPC package can now take advantage of two-way data exchange with the equipment, made possible by the thin server. If the thin server and remote application software support a common interface, such as OPC, setting up the data exchange can usually be accomplished in a matter of minutes.

Using this same internet connection, a browser PC (desktop, laptop, PDA, or a 'thin client') can access a web page resident in the thin server. This web page can be used to monitor data from the equipment as well as send data to the equipment via the thin server. And, since the web page is resident in the thin server, no software is required on the browser other than Internet Explorer or Netscape.

As a side benefit to this implementation, if the only requirement of the browser PC is to view web pages from the thin server, the PC can be solely dedicated to this task. In this case, the browser PC can be a very simple device. It requires only an LCD, CPU, and a small amount of memory; a thin client device. This can result in a lower installed cost and lower maintenance cost than a standard PC. Another advantage is that the device is not limited to viewing web pages from only the thin server. It can also view web pages from any source accessible via the network. So, a browser PC or thin client located on the shop floor could be used by an assembler to access HTML help files, with graphics and instructions, located on a remote server. The ruggedness and low cost of this type of thin client browser make it possible to provide data and control access in places previously not possible with standard or even industrial PCs.

For data exchange with the application software running on a remote system a common 'language' is required. Several possibilities exist, including OPC, mentioned previously, as well as XML. XML, or Extensible Markup Language, is a standard defined by the World Wide Web Consortium (W3C) that provides for a method of exchanging data between systems via the internet and is an important element of Microsoft's .NET architecture. The data is exchanged along with a 'tag' that defines the data in a manner that is independent of the sender's and receiver's hardware platform, OS, and application. This makes XML very powerful when implementing open systems within a company or between different companies, as in business-to-business applications.

Since web enabled automation is all about enabling the use of data within and between companies to improve processes and reduce costs, XML is a good fit in this distributed web architecture. Choosing a thin server that supports XML can be a real benefit to future plant floor connectivity.

For further information contact Advantech Australia Pty Ltd
PO Box 82 Sandringham 3191

Related News

Mount Thorley Warkworth mine extension approved

Rio Tinto has been given the go-ahead on its planned Mount Thorley Warkworth mine extension by...

Researchers increase pipeline oil flow with electric fields

Researchers have discovered that oil flow in pipelines can be smoothed by applying a strong...

Australian company TSG Consulting launches new services and technology

Australian advanced analytics company TSG Consulting is responding to growing demand for...


  • All content Copyright © 2024 Westwick-Farrow Pty Ltd