The Internet of Things (IoT) is essentially the culmination of the last 10 years of industrial automation (IA) and information technology (IT) convergence. The world is seeing the Internet and enterprise networks meld with industrial and manufacturing automation into massively distributed clouds where people, machines, business entities, public infrastructure, and our physical home and business environments are all constantly collecting, exchanging and acting upon real-time data.
Engineers on both sides of the IA/IT divide understand all too well the two technology environments are widely divergent, each featuring its own mutually incompatible protocols, interfaces, physical layers and software solutions. Each is often incomprehensible to an engineer from the other side, and thus, can present unique challenges for system integrators – challenges that are worsened when deploying and administering massively distributed IoT networks that will manage, process and analyse terabytes of real-time data.
One of the key areas where the differences between IA and IT become most problematic is at the edge of the network, where sensors that have traditionally used serial communications must be configured and translated to Ethernet and configured with added IT functionality. IA engineers tasked with configuring edge I/O devices will likely find scripting an email alarm both time-consuming and cryptic, while IT engineers will find Modbus setup and initialisation tedious and arcane. Without effective software automation, integration and optimisation of these competing technological environments involves a steep learning curve and many mistakes.
Obviously, the best solution is to automate and simplify these procedures as much as possible.
The challenge
Most often today, edge I/O is networked using RTUs or PACs, and on widely distributed systems wireless communication of some sort will typically be necessary. To deploy I/O stations, engineers are required to integrate the I/O controller into the overall network, which may involve several mutually incompatible communications protocols like Modbus, Ethernet, DNP3, or serial protocols like RS-485. When these networking interfaces are carried over wireless links, additional configuration will be required to secure these protocols and interfaces as they travel across the open airwaves. Finally, engineers deploying remote I/O stations will need to configure localised services at the PACs or RTUs that manage those remote I/O arrays. With the edge-to-core push communications now common, messaging, alarms and other services often originate at the network edge, with RTUs and PACs actively reporting state changes or event notifications without the need for polling from the scada or control centre.
Local RTU or PAC services and messaging have typically required substantial low-level programming, forcing engineers and system integrators to learn and apply device-specific APIs in scripts which they must then compile, sometimes for each feature. Configuring an edge controller to send an email notification, for instance, would require setting up a local SMTP client with a script that includes the IP address of the SMTP server, the port number over which the client will communicate, all encryption information, authentication and authorisation keys (such as username, passwords and public keys) for the local client, the entire contact list that should receive the notification, and all of the device-specific code that links these things together.
Most of this work is standard material that is time-consuming only because the specific APIs involved change from device to device. Email is used in the example above, but the example could just as easily be Modbus configuration, active OPC services, SNMP, FTP, or data-logging; any service that must be configured on a remote RTU or PAC will require the same basic work to get it up and running as intended.
With each protocol and service requiring completely different (typically device-specific) APIs and parameters to enable them, the time involved authoring each individual service script can be a barrier to entry for integrators looking to minimise their time to market by cutting development times. While the individual scripts that enable these services may be relatively short and trivial, time will still need to be spent writing and testing them. Manufacturers of PACs and RTUs should be looking to simplify and shorten the deployment of device-specific, localised services as much as possible and this is one area where integrated software enhancements can deliver substantial value to the customer.
The solution
The obvious solution is to eliminate engineers’ need to work on APIs and other low level, device-specific code as much as possible. Achieving this is relatively simple and direct. By pre-configuring the device with scripts that are already set up to enable local services on the RTU, it is possible to reduce system integration setup and deployment work to what is largely a point-and-click process. Engineers need only supply the device with the service variables specific to their deployment, export those variables to the device, and they will be automatically inserted into the script that requires them, thus enabling the service with the appropriate parameters. There are only two challenges that hinder this approach.
The first is the programming language used. For IA engineers, ladder logic and function block diagrams will be far more familiar than C, while for engineers coming from an IT background the reverse will be true. Nevertheless, any edge device integrated into a scada or DCS will always need to communicate with the rest of the system, so the required programming supplements will largely be determined by the designer’s personal experience and the needs of the system they have designed, making it imperative that any devices support either C or IEC 61131-3 languages, depending on what the designer requires. By providing each of these options, IT engineers may enjoy the full freedom of C programming objects, while IA engineers may use ISaGRAF to configure their device, using their own preferred tools.
The second obstacle is how best to integrate an automated setup and configuration process for local services and active messaging. It would be possible to create an entirely separate application for this purpose, but separate configuration applications are not really all that convenient because the device will of course require OPC tags for integration with an OPC server. Clearly, integrating services and messaging into the same interface used to configure OPC tags makes the most sense. This is where the idea of tag-centric setup takes form. By integrating the setup of services and messaging with OPC tagging, field engineers and system integrators may quickly and directly associate alarms, logging features, Modbus services and other active communications with tagged I/O events and process controls. In this way the need for applying low-level APIs is eliminated, allowing system integrators to focus solely upon the specific challenges and processes peculiar to their planned system. With a robust configuration tool, local services and communications features are reduced to simple programming objects that may be called as needed (in either C or ISaGRAF), for whatever purposes the engineer requires.
Making field programming easier
Field engineers must integrate behaviours across entire systems according to each customer’s need, always paying particular attention to robust and resilient logic control. Features like email or SMS notifications, data-logging and communication protocols like OPC or Modbus are just basic tools applied to specific requirements as needed. From the customer’s point of view these are standard, expected features, but for field engineers these are troublesome additions that can require more time for implementation than even the basic control algorithms. Integrating graphical configuration interfaces for OPC tags with these communication features is a powerful time saver, significantly shortening development and programming times.
How a tag-centric setup works
Software automations that configure services for massively distributed IoT deployments should reduce the development process to a few simple steps, with main services enabled and configured by choosing from selectable objects in a graphical menu. With the proper preparations, services as diverse as data-logging, email, SMS alarming, Modbus TCP, SNMP, DNP3, and CGI services may all be configured over a simple, high-level setup interface that requires as little user input as possible. Tagging tools for IA architectures already serve a very similar role, allowing IA engineers to streamline edge device deployments through convenient, high-level interfaces that associate I/O registers with ready-to-run services. By extending this functionality to include the configuration and scripting of basic services, configuration of these services may be reduced to creating software objects – or ‘tags’ – that may be used in other, more complicated customisations of event triggers and responses. This frees users from learning device-specific, low-level APIs to configure output signals.
RTUxpress – Moxa’s tag-centric configuration and setup utility
Moxa’s new ioPAC line of programmable automation controllers now features its most recent software enhancement, RTUxpress. RTUxpress extends the power of graphic tagging interfaces in precisely the ways discussed above, allowing users to configure and set up localised communications services like Modbus TCP/RTU, email or SMS alarms, and data-logging. By extending the graphical interface tagging utility to include local service configuration, system deployments and time-to-market are significantly streamlined for customers. Where system configuration once required a wide range of low-level scripts that utilised device and service-specific APIs, Moxa RTUxpress sets all that aside, allowing users to focus on the value added benefits. All with the promise that Moxa will remain committed to expanding these services to include every possible protocol and service needed to make engineering and design work easier.
| Tel: | +27 11 781 0777 |
| Email: | [email protected] |
| www: | www.rjconnect.co.za |
| Articles: | More information and articles about RJ Connect |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version