Some automation vendors offer direct access to machine HMIs and OITs with iPhone apps. Apps are useful for personal purposes, particularly for quick access to online info. We're wondering if app access for machine operator interface is better than browser-based access through a smartphone, or just a sexier marketing of the same capability.
—From March '12 Control Design
Answers
Apps Faster, With More Features
When deciding whether an app is better than browser-based access via a smartphone, the inevitable question is: "Why would I want to pay for an app when I can get browser-based access for free?" One significant reason is that browser-based access usually provides only read-only information, whereas an app generally provides two-way access that can allow a user to control a machine via a smartphone.
An app also provides information much faster, unlike browser-based access, which requires the entire page, including graphics and headers, to be downloaded before the information can be accessed. This enables users to access the information and respond faster, making real-time monitoring and control feasible.
One of our customers, Joel Froese, owner/operator of the Red Bank Hydro Plant in Columbia, S.C., prefers an app for the control of the machinery at his hydroelectric plant from his iPhone via the onscreen buttons. As he notes in the recent Control Design article "Remote Access Makes New Connections," he can now start up and shut down the system just as if he were standing in front of the HMI. "And built-in safety features ensure that I don't accidentally push the wrong button."
We're integrating an ambitious manufacturing line project that has us a little out of our depth for one element of it. We use proximity and other presence sensors on our machines all the time, but we're being asked to spec presence sensing to detect unauthorized personnel in the areas where all the machines will operate. First glance shows us many pros and cons among several technologies: the more conventional photo cells that we know something about, but also laser-based sensors and infrared sensors. Anyone have some best/worst practices or tips about these two?
Send us your comments suggestions or solution for this problem.
Furthermore, some apps are actually very inexpensive, making the decision to choose app over web browser that much more straightforward.
Greg Philbrook,
product manager HMI/communications,
AutomationDirect, www.automationdirect.com
Features, Features, Features
There is no denying the smartphone and tablet market proliferation. iPhones, iPads and Android devices are sexy. Why not just use the built-in web browser for everything?!? Simply put: Features.
Natively developed apps can be tailored specifically to the device and offer access to features that a web page just can't duplicate. For example, a natively built iOS app can run in the background waiting for data to be pushed or pulled from a cloud-based web service. While accessing the data for an automation application, the app could keep a local database of trends and information without needing to be online at all times.
A native app also can provide a much more familiar look and feel with gestures and other input options not available in a traditional web-page model. The multimedia experience can enhance the HMI framework to be much more than the simple toggle switches and gauges of today.
Imagine a situation where you have a machine HMI without Internet access available. An app-based HMI could communicate with the automation controller, offer control functions, and gather logs and other useful statistical information. The next time that the user's mobile device is online, it could "phone home" and provide tracking and statistical information to a server running in the cloud.
Sexier marketing? Absolutely—but nowhere near the same capability. Native features make all the difference.
Keith Willis,
president,
ECXSystems, www.ecxsystems.com
Security is another advantage of an app. Since it can use additional communication methods beyond standard http, an app offers added security measures beyond user name and password that are entered in a web browser.
An app also is more convenient to launch on a smartphone because it has its dedicated place on the phone's desktop vs. the generic browser app, where the HMI to be accessed can be bookmarked, at best.
The disadvantage of an app could be that it's vendor-specific, so you need multiple apps if you have HMIs from different vendors on your production floor. Vendors also need to create apps for the different smartphone platforms, and users need to download multiple versions if they use different smartphone or tablet platforms in operations.
The value add of an app should easily justify any cost associated with an app because it is easier and more secure to handle than simple browser-based access.
Robert Muehlfellner,
director of automation,
B&R Industrial Automation, www.br-automation.com
Smaller Not Always Better
Smartphones have added an entirely new dimension to human-machine interaction. They're extremely portable and remarkably powerful, and they do a good job of providing access to web-based tools of all kinds. The flexibility they provide can be a nice advantage because you also don't have to drag cables around with you.
It's important to note, however, that websites and many web-based tools are designed to be used from a computer with a keyboard and mouse. Interacting with some of these tools via finger taps isn't always ideal. It might be hard to touch the right button or type in commands because the program wasn't designed for a smartphone, and everyone's fingers are a different size. A tablet can sometimes solve this problem, especially if the app has been designed with the tablet's size and capabilities in mind.
Bosch Rexroth offers web-based HMI that can be used as a command and status interface. We recommend using the command interface while being around the machine for safety concerns and because of the remaining concerns of wireless devices in general. Some of the concerns are software incompatibility, network dropouts, and the danger of remotely starting or stopping a machine without knowing if it was safe to do so. Also, because of the range of app platforms—Android, iOS, HTML5—the app might not stay as up to date as it should.
Abdulilah Alzayyat,
product manager,
Bosch Rexroth, www.boschrexroth-us.com
A few years ago, the answer would have been a resounding, "Yes." Apps changed the way people interact with mobile devices. Web apps were generally targeted at desktop users with high-resolution screens, and generally offered mostly static content. Trying to access these web apps on a mobile device was frustrating and often futile. Native apps provided new, dynamic interfaces and leveraged the specific size and features of mobile devices like touchscreens and redefined usability.
For HMI vendors, however, supporting iPhone apps was costly. Native iPhone apps created additional development and support costs, not to mention dependence on the App Store as the sole distribution channel. If you add in other smartphone competitors such as Android, RIM and Microsoft, then those costs multiply because each requires different development tools and distribution channels.
Fortunately, this is beginning to change. New standards such as HTML5 are emerging that allow HMI vendors to develop interfaces that can be packaged as native apps or web apps running in mobile web browsers. This enables HMI vendors to leverage the mobile-cloud connection to move seamlessly between the application, desktop and mobile devices.
Larry Combs
vice president of customer support,
InduSoft, www.indusoft.com
Six of One…
People from all walks of life carry smartphones, and these smartphones are the users' preferred secondary screen, primary or secondary camera, and preferred chat device. In fact, it is estimated that more than 90 million phones in the U.S. are smartphones. That's a cool one-third of all phones in the U.S.
Ubiquity has a definite value. Talk to industrial engineers and they will tell you that in the past their dream was to have many screens on the manufacturing floor for monitoring, reporting and moving the process forward; but cost, safety and device connectivity made this an impossible feat. Today, every person has a moving secondary screen on them: their smartphone.
For heavy applications, number-crunching and database lookups will be done at the server level, with the smartphone mostly acting as an interactive display. For lighter applications, the smartphone can be used for what it is: a mini computer.
Question: Do we just point the phone's browser to our system, or is it better to develop a local app on the phone? Answer: Yes. It just depends on your application, resources and needs.
If your application is light and does not require server connectivity, or if your manufacturing floor does not support good connectivity, then the decision is simple: local app it is. However, for the majority of cases, since the local phone app just displays the data from your system in the cloud, the decision isn't whether or not a cloud-based solution should be developed; it's whether or not to develop a local app in addition to your browser-based solution in order to access the data from the cloud.
From the perspective of the application developer, of course maintaining one system is easier. However, since many phone browsers are still in a rather primitive state, they might limit what can be done in the browser. Having a smartphone app will give you flexibility, but at the cost of maintaining two (or more) development trees. That spells longer release times and heavier QA costs.
From the user's perspective, the main value is readily accessible data. If the user has to download an app, it might present itself as a barrier—albeit a small one.
In addition, the smartphone email programs don'ft differentiate between links. In other words, if a link is emailed to the user, clicking on it will automatically open the browser and not the local app. This can cause confusion for many users and indirectly cause them to become used to the browser as opposed to the local app. Apps that are not used are useless.
If a developer wants a sexier approach, a boast of technical prowess, a sign of keeping up with the times, and has the resources to maintain it, a local app connecting to the server is the way to go.
If sexy matters less—for instance, when it is for internal manufacturing and not for customer eyes—then a developer might choose the easier and faster path of presenting the data through the browser.
Siamak Farah,
founder and CEO,
InfoStreet, www.infostreet.com
