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 rise of the PC
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.