Selecting the best industrial HMI for any particular project is becoming an increasingly complex decision. Using an HMI from the manufacturer of the particular control platform used in the project may not always be the best choice. The selection process begins with a determination of the HMI’s communication capabilities. Two ways of transferring information between the HMI and the host control device are native addressing and translation tables. Native addressing directly reads and writes the memory locations or tags used when programming the control device. If the on/off status of a particular output bit is required, the communication driver reads the memory location, such as “Q1.03”, or the variable tag name, “Warning Lamp.” The direct memory locations are used in controlling the true/false condition of a graphic indicator lamp on the HMI screen. Using a translation table sets the HMI indicator reference to something such as “Lamp_103.” Then, in the HMI communication driver, a statement such as “Lamp_103 = Q1.03” points the HMI fixed tag to the correct location in the host device. Using direct controller memory addresses or tag variables will reduce the amount of work required to develop the application as each variable needs to be defined only once. Some software allows the export of tag names and data types from the controller and then importing into the HMI development software. However, using a translation table, an HMI application can be developed before the control software is written or can be used to quickly move an application between different controllers and addressing schemes.
If the communication system of the HMI allows multiple devices to be interconnected and addressed, determine if the application will be utilizing that feature and apply the communication test to all potential data sources (direct addressing or translation table). If all of the devices in the system can communicate with an OPC server, that may be a solution to investigate.
After the ease or difficulty of creating the communication path is determined, the next decision may be to consider if the HMI program will be performing machine-level operations or supervisory-level operations, or some combination of the two. Machine-level monitoring and control typically utilizes the control device’s memory for all dynamic information. Bit-level operations such as transferring a key press will write to the controller’s memory location. Lighting a graphic lamp reads the controller memory location’s value. This direct information is not stored in the HMI’s memory; it resides in the control device’s memory. Supervisory control reads and stores variable information from the controller and is used to create histograms, production data and alarm history. The supervisory operation may also load different recipes, motion profiles or predetermined setpoints. This information is often stored in the HMI’s memory and requires a greater nonvolatile memory area in the HMI.
Perhaps the next decision will be regarding which type of host will run the HMI software. For less featured, more straightforward applications, the host may run a proprietary operating system. These systems are considered closed; an application developed for one piece of hardware cannot be directly loaded into some other manufacturer’s hardware. A nonproprietary operating system may include some form of Microsoft, Linux or, if the target host is a mobile platform, Google Android.
Developing the user interface (UI) section of the HMI application may involve selecting graphic symbols to display different parts of the machine or process. Many HMI software development packages include different symbols that can be used to display the present machine state or process flow. Standard devices such as motors, indicators, valves and blowers are often included in the programming library. Depending on the specific equipment or industry, you may want to add specialty devices that are not included in the standard library. If this is required, evaluate the drawing tools available to create the new symbols and the import capability to use standard symbols used in the industry. It may save considerable time if existing CAD symbols or industry-standard diagrams can be imported into the UI screens. Some HMI software supports importing existing drawings, schematics, videos and tables.
Many companies include the ability of the HMI to perform calculations that use information from the controller as operands, for example, displaying a runtime in hours and seconds when the actual control program uses milliseconds to control the logic, converting a 4-20 mA signal into human readable units such as psi or kPa. The calculation feature can also be used to globally convert metric values to imperial, based upon a software switch or bit value in the controller program. Some software packages allow multiple descriptions to be defined for all dynamic elements allowing descriptive text to be written in multiple languages. Using these features requires more development time and effort up front, but it is less effort than developing a different program for each locality where the system is marketed.
Often a scripting language is supported. Scripting is used when some function or action is required that is not included in the base HMI software. Scripts can be used to do simple things such as changing to color of a lamp based on multiple conditions. Scripts can also be used on complex operations such as logging onto a remote database and executing SQL commands based upon some condition or event. Some software uses Microsoft VBScript, JavaScript or some proprietary scripting language.
There are two methods of creating the graphic display on the HMI. The first method a manufacturer can use is to write a program that generates all of the graphic and text elements, places them in the correct positions, updates the values as they change and decodes any key press. Manufacturers that develop proprietary graphic engines typically go to great lengths to support older applications on newer versions of the runtime software. A second way is to build or use an existing Web-page-rendering engine. The current HTML5 standard provides most of the graphical display and control functions found in proprietary HMI design software. The HTML5-based systems lend themselves to automatically resizing the pages if different screen sizes are used to run the application, making it easier to port to mobile devices such as smartphones and tablets.
About the author: Thomas Stevic
