Control system specifications regularly involve deciding where operator interfaces will reside. More recently, a choice must also be made on whether or not to use mobile devices.
Traditionally, if there were a small number of operators looking after a large process area, portable displays were an option to reduce the number of operator stations. Often, these turned out to be desktop sessions on battery powered PCs connecting to a server. They often would be locked down to include just the HMI application and looked like shrunken versions of their full-size cousins. There was no fundamental difference between designing these screens from what has been done for years.
There is a stronger and stronger desire to have screens become mobile friendly. This requires that information is selectively displayed based on the user's needs for a given task. Is the task at hand to add an ingredient, to check on a process state, to fix a faulty sensor, or to improve a process step? Each of these requires related, but different, pieces of information. Traditionally, faceplates have been one means to allow information to be organized in tabs that break it down by operations, maintenance or graphical views. Faceplates are less convenient on touch interfaces in favor of accordion style interfaces with wider touch areas and sliding navigation.
Let's look at a real-life example. Consider this batch project with fifteen (15) batch units. It has two similar trains, each with an oxidizer (4 units) and mercapper (3 units) plus a shared stripper unit. The product flow is shown in the diagram below.
For this project there were four main process graphics (an oxidizer and mercapper per train). Each was designed with trend data, control targets, and batch information on a high definition display.
…there was a summary batch screen in a table view…
…and the top row provided alarm and status by process area.
Operators and maintenance personnel are accustomed to viewing large overview screens at their operation desks or common areas. This is very convenient. In this example, a user has just five screens to run a large production environment. High Definition screens can be wall mounted or projected.
To view these process screens on the production floor using a mobile device would be hard very clumsy. Making this type of information morph between the large and small screen sizes is a relatively new phenomenon in modern websites called responsive design. The tools of the trade are HTML5 and CSS3.
HTML5 has made the document object model (DOM) a standardized way to manipulate the properties of a browser page. A page's elements are now able to be changed programmatically and consistently across modern browsers. CSS3 extends the sizes, colors, visibility, and animation of these elements to be based on media queries with the enhanced ability to recognize the height/width of viewports or devices, orientation, and resolution. It is changing the tools we have to build our HMIs for the factory floor.
Their top ten tips are:
1: Think Small
2: Always Design for Touch
3: Make Content Easy to Find
4: Make Important Information Obvious
5: Keep Graphics Simple
6: Different Users have Different Experiences
7: Optimize for Performance
8: Know What’s Published (and what’s not)
9: Expand the System
10: Work from the Beach.... Maybe
Back to our example application, one option would be to start the process navigation from a system overview page that is broken down into process flow, alarms, batch units, and tags. Conceptually, this is similar to how most large display versions are already organized. All but the process flow are table based navigation, which is relatively friendly on a small screen. For the process flow navigation, each main process area could be on its own screen and slide between each one. Conceptually, it may go as shown below.
Now for the big challenge. It may seem that there are two separate screen development efforts; one for big screens and one for small screens. Indeed, many web sites handled this problem by having mobile links for their sites. But a responsive design needs various screen sizes to generate from the same source code. The suggestion is to design screen widgets for the small screens first with the various views and then have them reposition on the big screen. More information is exposed on larger screens or by the use buttons and/or targets. In this way the small screens drives the content design into manageable bites and the big screens drive how they are organized in the navigation tree.
As always, a good up front design methodology will provide reusable code modules to make this task more manageable and efficient. It would be great to hear what library users have today to achieve these type of results for their users.