It's interesting to watch the bring your own device (BYOD) movement leak into the manufacturing space, but we have concerns. Many larger customers or potential customers are doing it to some degree in their IT groups. We've been successful with the plug-in or wireless pendant for multi-station HMIs; we know it well, and it does the monitoring and control our customers need. It seems inevitable that any day now an RFQ will include tablet or smartphone wireless HMI requirements. We'd like to have a few legitimate, technical performance reasons that argue for keeping what we have. Or is it time look for a seat on the bandwagon?
—from February ‘13 Control Design
Hop on the Bandwagon
Yes, an RFQ with tablet or smartphone HMI is inevitable, and it's time to get on the mobile device bandwagon. The good news is that you can do this on your terms. In the manufacturing space, instead of supporting BYOD devices (which, by definition, are devices users already have and bring to work), consider supporting affordable commercial-off-the-shelf (COTS) smartphones and tablets specifically issued to users. This approach gives you better control over both application security and performance because you specify the device and accessories, configure security and application software, and maintain the device with OS and application updates.
You can even lock down mobile devices in "guided access," "kiosk" or similar secured modes to restrict application use.
COTS mobile devices benefit from the sheer scale of deployed devices. They're inexpensive, readily available, familiar and offer useful features. A COTS smartphone, for example, will cost much less than a wireless handheld terminal, use modern, non-proprietary networking standards like Wi-Fi and Bluetooth, and require little training to use. Ongoing software and hardware development occurs for an installed base of millions of units, not hundreds or thousands. Cases for industrial environments—even Class I Div. 2—are available to protect popular smartphones and tablets. Several mobile device management (MDM) software suites can secure off-the-shelf devices used at work.
Finally, one of the key features of COTS mobile devices is their capable web browsers. Some automation companies, such as Opto 22, offer tools to develop web-based mobile operator interfaces for securely monitoring equipment and systems, without the need for additional software. In a nutshell, using COTS mobile devices lets you retain device control for security reasons, while using the advantages of off-the-shelf mobile platforms.
The main problem of BYOD is found in the meaning of the acronym. You own the device, so you decide what is on the device and what you do with your device. This raises security concerns due to possible lack of control, and it demands extra measures. In exchange, companies obtain money savings and alleged increased employee productivity. For non-critical activities such as mailing or sharing a company's calendar, security issues can be worked out, and the BYOD movement reaches its full potential. However, for critical operations such as controlling machines through HMIs, the risks could be higher than the benefits. Even if security concerns can be overcome, a device misconfiguration or a temporary glitch on a device might prevent a worker from properly dealing with a system requiring real-time operation. Attempting to support many disparate devices might not be the best idea in real-time scenarios. As developers of mobile apps for the manufacturing industry, we do not encourage BYOD. We require both user and device identification in order to run our native HMI apps. Unregistered combinations will not work. This approach still allows companies to adopt BYOD if desired. Otherwise they can ban unidentified devices, not just users, by simply not registering them. Ultimately, we encourage companies to supply employees with devices (such as iPads) only for the purpose of process control, using HMIs, as opposed to allowing users to bring their own devices.
Also Read: Next-Generation, Intelligent Networked Devices
A control system continually produces valuable system and production data. But that information—and that system—is less valuable if you can access machine information only from a dedicated terminal.
If operators can be more productive by accessing terminal data from a remote location, or if an operator needs to do a quick unit count from an HMI, but isn't near a computer or the production line, HMI mobility options should be tapped. While the majority of industrial production companies likely will continue to use traditional HMIs as their main control interface for machine operations, remote access can bring valuable gains in accessible, convenient information and production control.
As a web-enabled HMI application, it extends access to machine displays and dashboards to users anywhere for improved real-time decision-making. Operators also have the freedom to perform maintenance and troubleshoot remotely or walk along the conveyor line to check sensors in commissioning. With HMI mobility remote users can:
- Gain access to download programs via FTP
- Increase diagnostic information gathering
and remote troubleshooting capabilities;
- Gain administrator login access to view terminal
diagnostics via the VNC, with no disruption to
- Check production rates and capacity or view key
performance indicators from the road, home or
an office terminal.
HMI mobility can usually be accomplished without the need for costly new software or infrastructure changes. For example, an embedded, remote-connectivity feature on the Allen-Bradley PanelView Plus 6 HMI terminals can provide data access to real-time, plant-floor operations by extending the HMI content to a Windows, iOS- or Android-based device using VNC technology. Typical smart device VNC or remote desktop applications can be used. Such applications are likely embedded in a dedicated terminal already, so don't wait to tap the power of mobile information. Remote visualization capabilities will put you ahead of the game in response time.
Global Product Manager,
[From LinkedIn's Automation Engineers Group, where we posted the question, comes this thread about the problem:]
Security the Bigger Issue
I would be far more concerned about security issues than performance issues. Often the security on a control system network consists of a firewall between the business and manufacturing network, but not much security within the manufacturing network. Allowing a consumer device onto a relatively unprotected manufacturing network is not advisable without additional protection against the device.
Senior PI Specialist,
ADM Systems Engineering
But There Are Security Answers
- Some mobile platforms address security really well. For example:
- Separate NICs on the server or device so you can separate the control network from the IT network;
- SSL-encrypted messaging;
- Authentication certificates;
- Ability to come in from the outside via VPN;
- Ability to layer user access with permissions;
- Ability to limit some screens to monitoring only.
Given these six points, mobile devices can be just as secure or more so than traditional HMIs and OIs. I think BYOD is inevitable, but like a lot of things in the industrial automation space, it won't replace traditional solutions, but it has its place for the right applications.
Director of Business Development,
[From LinkedIn's Industrial Automation Group:]
Who Owns the Data?
There is one compelling factor. The devices are getting dirt cheap at a staggering rate. The biggest concern about BYOD is around security, and not just the infection part with viruses. Who is the owner of the data stored on the device? There are different solutions for this problem and, of course, different vendors have different implementations. This is not optimal if you need to decide what you want to do or use.
We should step back from the BYOD and ask ourselves why do employees want to bring their own devices. To my understanding, this is mostly because they have more up-to-date, sexier devices than those provided by their employer. With the prices of the devices dropping like a bad habit, why not provide the employee with the devices as a tool with the permission to use it privately? If they leave the company, the device can be remotely wiped and they can keep it. The company is in control about what device, how to use the ecosystem and what security measures will be used.
Basically you want an ecosystem surrounding the device that supports the development of third-party modules. Next you need a way to be able to download this onto the device in a secure manner. The app store principle goes a long way in supporting this way of working.
Performance-wise, the devices get more powerful with every release. There is, however, a mindset that needs to be changed. This seems to be the hardest part of dealing with change. The general idea is that most of the time the device must be able to do exact the same things as the HMI or desktop application. This is wrong. The apps for the devices need to be developed for the way they will be used. Do you really stand still in your factory with a tablet in your hand trying to check up on all the thousands of I/Os? Or do you just want to quickly check some KPIs and copy the results into your presentation?
Where did I get my wisdom? Well partly from listening to several discussions and reading some magazines. I listened to a good discussion on this topic from a podcast by RunAsRadio: www.runasradio.com/default.aspx?showNum=335.
The debate is not an easy one and also heavily influenced by personal opinion and context. Personally, I have not taken a position yet. Just keeping my eyes and ears open.
Eye-Concept Industrial Automation BV