HMI – Human Machine Interface, is the link between machines and their Human operators or users. Moving right to the other end of the time scale in part two of this blog (you can check out part one here), let’s have a closer look at how HMI has evolved, and can further evolve.
If you start to look around for the HMI on CNC (Computerized Numerical Control) systems, the HMI component is usually referred to as the Controller or Operator Panel. When you look around for other systems that Humans use to access information, it’s usually called the UI (User Interface). Maybe a small and subtle difference, but words can mean a lot. It’s indicative of how these systems are designed in terms of how the HMI interacts with the rest of the system. In a simple form, the following diagram lays out the component parts. A Machine takes Input (e.g., materials) and produces Output (e.g., a physical part). The actions it takes to produce the Output are controlled by instructions from the Controller and its progress in performing those actions is monitored by Sensors that feed back into the Controller. While the Operator Panel (HMI) allows the Human Operator to Control and Monitor the whole system.
The main ”issue” with this common way of organizing the system is the Monolithic design of the system. There is a heavy interdependency between the Controller and the Operator Panel. They only need to be “connected” to the Machine via the Control and Sensor connections. However, these need to be high bandwidth connections so that the Controller can interact with the Machine in a near real-time manner. Thus, all parts of the system need to be physically close together. But that’s just the physical setup. A further “issue” is within the Controller and Operator Panel in that they are usually one and the same. These factors combine to make it very difficult to remove the Human Operators from the Physical Controllers and Machines. Applying automation at the HMI level also presents challenges.
In a manufacturing environment, this gives rise to “islands” around each Machine with Operators that are “bound” to their Machines.
Separating the Operator Panel from the Controller offers advantages over the Monolithic design and only requires there to be separation between the Operator Panel and the Controller. I say “only” but this does require a structured and secure Interface between the two parts. The most obvious way to achieve this separation is to use modern web access and APIs (Application Program Interfaces) implemented within the Controller, allowing the HMI to be implemented via Web Browser and Automation via APIs.
This arrangement allows the Operator to be remote from the Machine, except for the obvious case where Input needs to be manually loaded into the Machine and Output removed. However, even this case could be handled with robotic support of Inputs and Output removal. Robotic materials handling could be synchronized with Machine operation via the Automation that can be implemented through the APIs.
Let’s have a look at what’s inside the Controller having decomposed the Monolith. As above, from the outside world, the Human uses the HMI, which is now really just a network connected Web Browser, Automation can connect over the network, and Control/Sensor connections physically connect to the Machine. Within the Controller would be a Web Server that serves requests from the Operator Panel (Web Browser), a Content processor that deals with requests from the Operator Panel using the common API (also used by Automation) to interact with Controller’s internal Logic and generate the content passed back to the Operator Panel by the Web Server. The Controller’s internal Logic communicates with the Interfaces used to send Control signaling to the Machine and receive Sensor readings from the Machine.
This arrangement gives much greater flexibility than the Monolithic (all in one) approach. The Operator can be remote from the Controller and the Machine, potentially operating a number of machines from a Control location (on-site or a physically-remote location). Automation can connect to the Controller and have the same underlying functionality as the Operator because they both use the same Common API. Improvement and changes to the Operator UI can be implemented by just changing the Content processor without affecting other parts of the system.
None of this is “new”, it’s all part of the modern world of Web-based Services and the Internet, but implementing it for Manufacturing Machines will bring them into the modern world with improved Operational characteristics. The future is here and needs to be used.