This post was authored by Richard Clark, cybersecurity engineer at Schneider Electric.
A significant shift is occurring in the automation world: the PC, while still an important element in the technology mix, is no longer the dominant method for remotely accessing automation systems. This is the result of changes in technology and business practices.
The Great Recession precluded many companies from hiring additional staff, making them do more with less. Workers had to manage more systems over larger geographic areas. No longer could businesses afford to have operators spend the entire day in a control room, while technicians roamed the plant floor and communicated back to the operators via walkie-talkies.
Despite an improving economy, many industrial enterprises remain unwilling or unable to expand their headcounts for reasons ranging from a shortage of skilled automation workers to uncertainty about their future prospects. Fortunately, advances in handheld devices and remote capabilities can help fill the gap created by downsized workforces, helping businesses lower costs, improve operations, and reduce training expenses.
The 1980s saw the migration of human-machine interface (HMI) and supervisory control and data acquisition (SCADA) systems from proprietary hardware to PCs, which were overwhelmingly Windows based. This event was the beginning of the end of the island of automation in which HMIs only interacted with the plant floor or the control room. Once HMI/SCADA systems transitioned to the open PC platform, it became easy to network these systems to PCs throughout the plant, and eventually throughout the enterprise.
Common PC- and Windows-based standards and networking protocols also enabled HMI applications to be integrated with other automation and business systems. For the first time, data could easily be retrieved and manipulated remotely, marking the beginning of remote HMI access.
Initially, workers used their office PCs to view HMI data from their desks and sometimes from remote locations via a laptop and a modem. Accessing HMI data was relatively simple because their PCs used the same operating system as the HMI and had a similar screen size. The next step was implementing PC-based HMI that could send text messages to cell phones with alarm, alert, and other basic information. Once a message was received, the user could then go to a PC to further analyze the data and possibly perform a remote-control action, such as changing a set point or acknowledging an alarm.
PC-based HMI was a big improvement over proprietary systems, but was expensive for simpler applications like control of a single machine. For harsh-environment installations, industrial PCs were available but often cost prohibitive. Microsoft’s embedded operating systems addressed this issue by creating a standard software platform that could host embedded HMI applications on less expensive boxes with smaller form factors. These embedded HMIs were ideal for smaller scale applications, and for remote access to PC-based HMIs as thin clients.
Wide acceptance of the wired and wireless Internet in the 90s created the network infrastructure to support the introduction of Web servers with remote Web browser access. In this architecture, still widely used today, PC-based and embedded HMIs have Web server functionality, giving remote users access via any Web browser. This dramatically reduced implementation, maintenance, and licensing costs because client software no longer had to be installed on every user’s PC or remote device.
While browser-based access was a huge leap forward, it had limitations. Most implementations provided read-only access. Another issue arose as remote workers began to use handheld devices instead of a PC to retrieve and view data.
Obtaining information via a traditional browser-based solution often involves very slow download speeds, and can sometimes result in large data charges from cellular network providers. Moreover, screens incorrectly sized for smaller devices can make manipulating data unwieldy, requiring too much scrolling to view text and access various screens.
Because users often had difficulty communicating via browsers and were downloading apps for other uses at an exponential rate, some HMI suppliers developed apps to deliver improved remote access. These apps were designed specifically for smartphones and other handheld devices, providing a huge improvement over browser-based access in terms of ease of use and speed. However, apps have not been a perfect answer either. HMI suppliers were often slow to roll them out due to internal development issues related to the lack of standards.
The operating systems and programming languages used for iPhones and Androids are different. This means HMI suppliers must create separate applications for Apple devices and Android-based devices. Also, several smartphone and tablet hardware manufacturers offer a variety of screen sizes.
To accommodate this variety, SCADA suppliers had to write separate apps for each device type. This meant many users had to wait months or longer for a remote HMI app to be developed or upgraded for their particular device. Moreover, most HMI suppliers do not see a financial justification for investing the time required to write apps for all smartphones and tablets. To port even a simple application from one operating system to another could take developers months.
Fortunately, the HTML5 standard solved this problem, allowing HMI suppliers to develop an app once and roll it out to every smartphone and tablet supporting the standard, covering the vast majority of the market. This ushered in a new era, one that promises cost savings for companies and convenience for their employees.
The rapid escalation of bring your own device (BYOD) policies, in which employees can use their personal handheld devices for work purposes are becoming a popular way for businesses to cut hardware and software costs. BYOD is also prompting HMI suppliers to expand and improve their remote access options.
For BYOD policies to be successful for industrial environments, HMI access must be available for a large variety of handheld devices. Also, users must receive a functional user interface for the particular application.
HTML5 greatly improves users’ ability to access HMI data by enabling them to use any HTML5 browser. Before HTML5, most HMI packages only offered Internet Explorer support, meaning users were limited to Windows phones and tablets. It also allows HMI suppliers to “write once and run everywhere.” Some users may prefer native apps, and HMI suppliers will continue to offer this option, with both app and browser-based access providing a number of benefits (table 1).
Benefits of modern mobile access
Many HMI solutions today are largely developed for a traditional PC and keyboard, or at best for a single-point touchscreen. These solutions consist of drop-down menus, commands, and pointing devices—which force workers to navigate screens and interact with data exactly as they would on a PC, even when they are using smartphones and tablets.
In addition to BYOD policies, many companies prefer to issue workers tablets, because they are less expensive than PCs. Furthermore, the lack of moving parts and the availability of screens designed for harsh environments can make tablets more robust in dusty and damp locations. In fact, businesses can even improve worker safety, as many multitouch screens can be used by gloved hands, with certain safety-related functions requiring two-handed operation.
Multitouch functionality is vital for using touchscreens. Unlike traditional touchscreen designs, multitouch systems recognize the position of several touch contacts to perform user-requested actions. This technology is also intuitive for nearly all workers, who use it daily with their smartphones and tablets, especially the new generation of younger workers being trained to replace retirees (table 2).
Benefits of multitouch HMI
Fortunately, a few HMI solutions have started to offer multitouch functionality that lets users scroll, zoom, expand, and rotate items with familiar smartphone gestures, such as swipe and pinch. Compared to single-touch technology, multitouch technology enables operators to execute commands as much as three times faster.
Instead of scrolling through several screens, multitouch users can use gestures to zoom in quickly on areas of interest. They can easily rotate a piece of equipment and then magnify the area—all without lifting a finger from the screen.
Twenty years ago, HMI tethered workers to the plant floor and the control room. Today, HMI offers full-featured remote functionality that delivers lower costs, higher productivity, and improved operations. The ability of today’s remote HMI solutions to display information in actionable formats has enabled smaller workforces to manage more processes and physical locations. In turn, this has driven the demand for easier and less expensive remote access. As a result, innovative HMI suppliers have adopted the latest technologies, such as apps and multitouch functionality, to improve the remote user operating experience.
It is too soon to sound the death knell on PCs. Writing and coding are still easier on a keyboard, and the additional processing power and larger memory capacity of a PC easily handles tasks that would strain a tablet. No remote wireless device will ever match the user experience of a PC with its relatively huge display and lightning fast wired network access.
But the near future is not about one technology completely replacing another. Workers who currently use an app written for their smartphone or tablet to access HMI data will continue to do so successfully, and more will join them every day. And perhaps most importantly, remote access will be designed for the devices, making smartphones and tablets the preeminent technologies for mobile HMI.
About the Author
Richard Clark is part of the InduSoft team at Schneider Electric. Before InduSoft, he worked for Invensys as a staff engineer, an information security analyst, and a knowledge base engineer. Clark is also an ISA99 voting member and a member of InfraGard.
A version of this article also was published at InTech magazine.