This article was written by Greg Philbrook, a product manager at AutomationDirect.
Remote connectivity to plants, machines, and processes is growing in popularity along with the Industrial Internet of Things, and there is no end in sight to this trend due to a variety of enabling technologies (table 1).
These trends are making it easier and less expensive to connect fixed and mobile devices. Although the term used in this article and elsewhere is “remote access,” this device access can be via either an internal local or an external remote network. The access is generally remote from the machine or process being monitored.
Whether access is local or remote, the plant floor components and the remote-access devices are the same, with the difference being the network. In-plant remote access is generally through company intranets and Wi-Fi, while access away from the plant is usually through the Internet, often using the cloud.
No matter the network, data is collected by the automation system and distributed to PCs, tablets, and smartphones. Browser-based access is eased by the HTML5 standard, which lets users create screens once and distribute them to many devices. Cybersecurity is a concern, but tools are available to address this issue.
This remote connectivity goes beyond access for troubleshooting. In many cases, the remote devices are connected to the automation system to be eyes into the machine for optimizing the operation, to send data and production information to engineering, and to provide management with summary and analysis information.
HMIs display machine and process data locally on the plant floor, and they can also give this information to other platforms for a variety of uses (table 2) described below.
The most common remote-access use cases vary based on the application. Although controlling an application is feasible, it is not used often. Management and process engineers remotely monitoring operations usually cause a demand in the technology for network-accessible HMIs. Being able to remotely monitor the application gives decision makers access to methods and system screens that present process data in a visually understandable format. On-site personnel are no longer required to gather and send data to the decision makers, many of whom may be in other locations.
Systems errors defined in configurable event lists allow remote users to view and acknowledge critical events or alarms. They can respond faster when analyzing the root causes of these events and help improve the OEE. It also reduces the need to walk the plant floor or travel to the remote site. The extra time saved in travel can be applied toward studying the data more closely and applying any changes needed to increase the operational efficiencies.
When there is a major process issue, such as a reduction in production or a malfunction, responsible parties are not required to be on site for troubleshooting. In these situations, remote access reduces downtime by facilitating a quick response.
HMI as the hub
Not only are HMIs used to display machine and process data, they can also be the data concentrator for all of the plant’s automation systems (figure 1). This is true for PC-based HMIs and for HMIs running on either industry standard or proprietary embedded hardware and software systems.
In the not too distant past, programmable logic controllers and controllers were connected using discrete I/O, proprietary communication protocols, or maybe even simple ASCII communication. In other cases, a gateway or protocol converter was used. Those days are over for most users, because modern HMIs can act as the hub for tying a variety of controllers and communication protocols together.
HMIs, from lower-cost embedded versions to higher-end PC-based ones, can communicate with many of the leading industrial controllers via dozens or even hundreds of different protocols. With these expanding capabilities, the HMI can connect to most controllers, and Ethernet is becoming the communication standard of choice.
An HMI hub likely uses multiple Ethernet-based protocols simultaneously for communication with several controllers and smart devices. Adding the smarts and programmability of the HMI improves flexibility and functionality, especially when compared to protocol converters or discrete signals.
Particularly with the power of a PC-based HMI, the number of communication ports and configurations that can be deployed is virtually unlimited. New communication paths and networks can be established by just plugging in a new communication card to the PC and activating the appropriate I/O driver in the HMI software.
Connecting to HMIs
There are three main methods for connecting PCs, tablets, and smartphones to HMIs: intranets, the Internet, and the cloud. Methods for connecting to networked devices are continuously changing. Many of these methods are still based on familiar networking Ethernet configurations, but they vary based on the scale of network complexity and software services. These methods incorporate technology based on hardware, telecom, software, and Internet service providers.
An intranet is an internal private network and possible subnetworks, and it is most often used if access to an HMI will be restricted to sharing information and communicating within a single organization. Intranet complexity increases when organizations need to share data with remote locations, particularly if remote access needs to be mobile. In these situations, networking servers and routers must be configured to allow access to external service providers offering access to the Internet.
Remote access via the Internet is most often offered by regional Internet service providers that install and create local area networks and integrate these networks into wide area networks. These networks are then used to connect to the ever-increasing number of mobile devices. As complex as it may seem, if the proper configurations and security verifications are implemented, most remote users will not be able to tell the difference in network topography between a local intranet and the Internet when connecting to an HMI.
One other type of service using the existing Internet structure is the cloud. Providers maintaining remote servers allow clients or subscribers to store and send data through their network. This type of service usually requires a usage fee, particularly as the amount of data stored and the number of users increase.
In return for this subscription fee, server hardware, software services, and even desktop services are provided—reducing the need for organizations to maintain their own technology teams. An HMI can share data to the service provider’s cloud servers, and then access the data by logging into the cloud provider’s hosting service.
HTML5 eases access
Browser-based access is greatly facilitated by the HTML5 standard, which provides the capability to create screens once and distribute them to many devices. HTML5 supports and improves remote/mobile Web applications. Its capability to run on multiple platforms lets HMI developers design and maintain one mobile application that will function on a wide variety of mobile devices. This is true even when the devices are built by various manufacturers and are powered by different software operating systems.
When the HTML5 standard is supported, the remote device requires no additional software to be installed, and the remote device’s Web browser tools can be used without having to download operating system–dependent mobile apps. This is in contrast to app access, which requires users to download software from various app stores, and also requires frequent app updates. Unlike native applications, HTML5-compliant remote devices continue to function even when there are changes or upgrades to the operating system and hardware components. The user is not required to access and upgrade a file from a provider.
Although HTML5 has benefits when displaying data, native apps can offer users a more compelling user interface by taking advantage of unique functions relevant to the particular device. A native app can also reduce the required bandwidth for graphic-intensive deployments.
Security is improving
Cybersecurity is becoming more of a concern as production managers begin to understand that the lack of proper security can negatively affect productivity and endanger operators. A variety of policies, techniques, and built-in tools are available to help authenticate and restrict unauthorized access or misuse of a networked device.
When designing networks for control applications, organizations should apply a defense-in-depth method to offer multiple layers of security and protect all HMIs on a control network. These layers include hardware devices, such as routers, firewalls, and managed switches. Another layer includes implementation of authentication protocols and virtual private networks for a reliable and secure connection for remote users connecting through a public network.
At the HMI level, multi-authentication is commonly addressed by various methods. At the basic level, a user name and password can be configured to restrict unauthorized users from accessing the remote connection and gaining control or gathering data from the HMI. The next level is often implemented by creating predefined accounts restricting each user’s level of remote access or control. These accounts can be defined to give the remote user only the level of access required to do his or her job.
HMIs with built-in Web or FTP servers often use the same type of user authentication as standard network devices. Because every network varies in its security policies, many of the security configurations rely on the users to configure these settings during the design stages of the HMI application. The responsibility thus falls upon the network managers to make sure these security features are implemented correctly and in accordance with company policies.
Purchasing the right HMI, connecting it correctly, and configuring it with care gives organizations the required level of remote access to plant data. This can be done via a variety of methods and networks, with choices made based on the specific needs of each application.
About the Author
Greg Philbrook is a product manager at AutomationDirect in Cumming, Ga. He is responsible for product strategy, specifications, and development for HMI and communications products. In Philbrook’s nearly 20 years with the company, he has worked in roles including technical sales, support, engineering, and development.
A version of this article also was published at InTech magazine.