The Human Machine Interface is responsible for the connection between the controller and a human-monitoring subsystem. The object-oriented design pattern called the model-view-controller (MVC) will be used as the HMI reference model. Figure 1 shows the relationship of the different control and human aspects within the MVC pattern. The MVC model “M” defines the state of the HMI objects. The MVC View “V” corresponds to the front-end or visual presentation with which the user interacts. The MVC controller “C” is not the same as the motion controller, but refers to an object that controls a View object in such a way that it responds to user input and delivers output.
Figure 1: MVC Design Pattern
Some clarifying objectives concerning the OMAC API HMI are in order. The goal of the OMAC API is to define an HMI specification that is independent of the visualization medium (i.e., V), the data entry mechanism, the operating system, or the programming language. The primary OMAC API objective is to specify a technology-neutral data and event model (i.e., M) for exchange of information between the Human subsystem and the Application Controller. The OMAC API would like to encourage the bundling of a control component with an HMI viewing component (i.e., supply component plus V & C). The OMAC API is not concerned with the “look and feel” of a HMI. The “look and feel” of an HMI is generally application-specific.
To understand the HMI for OMAC API, the elements M,V, and C will each be reviewed.
The primary emphasis of the OMAC API is to define a model “M” API that allows the exchange of data and events. The traditional standardization effort for “M” relates to the data collection or back end that would be defined as a Dynamically (or Shared) Linked Library.
The desired HMI “M” functionality is best understood in the context of simple problems. Three canonical “M” problems exist that an HMI module must be able to handle. First, the HMI must have the capability for solicited information reports about the state of the controller, such as current axes position. Second, the user must have command capabilities such as the ability to set manual mode, select an axis, and then jog an axis. Third, the user must be alerted when an exception arises, in other words, handle unsolicited information reports.
Figure 2 : HMI “M” Mirrors Controller
For “M” functionality, OMAC API specifies that every controller object has a corresponding HMI object “mirror”. Figure 2 illustrates an “M” that mirrors an application controller where each mirror object in the HMI has a reference to its companion object in the controller. The mirror object can then use the reference to get/set data, or to invoke methods to initiate events. In other words, these HMI and controller objects have identical interfaces for data manipulation and event-initiation. For event-notification (unsolicited reports), this is a special problem that really has to deal with the infrastructure. (See section on event-handling.) Compared to a conventional “M”, the use of get data mimics a data base copying the desired viewable values from the controller.
The major mirror assumption is that HMI objects communicate to control objects via proxy agents. An analysis of how the HMI mirror works will be developed.
Figure 3 : Close-up of HMI Proxy Interaction
1. To handle the information report functionality, an HMI mirror acts as a remote data base that replicates the state and functionality of the controller object and then adds different presentation views of the object. These HMI mirrors are not exact mirrors of the controller state, but rather contain a “snapshot” of the controller state. Figure 3 illustrates the interaction of the HMI mirror and the control object. In the basic scenario of interaction, the control object is the server and the HMI mirror object is the client. Each HMI mirror uses the accessor functions of “get” and “set” to interact with the control object. Notice that each host controller object and its corresponding HMI mirror have a proxy agent to mediate communication.
2. To handle command functionality, the HMI mirror contains the same methods as the controller object so that a command is issued by invoking a method remotely.
3. To handle abnormal events when not polling, an HMI mirror must serve as a client to the control object so that it can post alert events. For such unsolicited information reports, the control object uses an event notification function, updateCurrentView, in which to notify the HMI mirror that an event has occurred. This notification in turn may be propagated to a higher-authority object.
The MVC view “V” deals with the presentation medium, for example, whether it is a “V” for a GUI or a teach pendant. As previously stated, the OMAC API is not concerned with the “V” aspect pertaining to “look or feel” of a HMI.
Of importance to the OMAC API specification pertaining to the MVC control “V” is the aspect that deals with data views. Different data views correspond to different modes of presentation. For example, there can be a view for configuration, calibration, error handling - as well as normal operation. In addition, the view “V” can be used to offer different screens to different levels of authority, such as for operator, maintenance, or systems engineer.
Given this emphasis on data views, the OMAC API defines the following “V” interfaces to handle the different expected data views.
interface HMIControl
{
void presentView();
// Rest TBD
};
interface HMIDisplay
{
void presentView();
// Rest TBD
};
interface HMIConfig
{
void presentView();
// Rest TBD
};
The association of data views along with a control component offers a strong potential for “complete” off-the-shelf integration. Instead of buying a control component with a standalone calibration program, a control component would come with GUI control, GUI display and a GUI config components (most likely ActiveX compliant components.) Then, just as the control component can be integrated into the application controller, so too can its corresponding control view component be automatically integrated into the controller presentation. As an example of this technology, a tuning package can provide a Windows-based GUI to do some knob turning. Another example, is a tuning package that offers this capability to be plugged inside a Web browser. With this development, unlimited component-based opportunities are available.
Thus, three different HMI components per OMAC controller component are defined:
Figure 4 illustrates the deployment of HMI GUI Control, Display, Config components that realize several interfaces.
One simplification is not to reproduce the state logic in the presentation, instead an HMI component can reuse the controller logic by having canEvent(). The interface although simple, depends on methods in the control component of the form canEnable so that an HMI component can determine if an event/command can be done. For example, suppose there is a canEnable query method, should it return false, then dim the enable button (and vice versa). Logic is not created separately or repeated. The Machine Controller objects support tehse state query methods to simplify development. This reduces redundant effort that can lead to inconsistencies, and confusion.
The MVC controller “C” discussion will further explore the coupling of a control component with a view component for automated system development.
The MVC controller “C” is responsible for controlling the views presented to the user. In Figure 3, the control object is represented by the Client which changes views based upon the use of different MVC “V” methods (i.e., the different types of presentView methods - see above). However, the Client is not bound to use the mirror “V” methods when constructing presentation views. There exists a range of approaches that the MVC “C” Client can use when controlling the user presentation - from least to most customized.
In Figure 5, the Client is using the HMI mirrors to present the view. Exclusive use of the HMI mirrors presentation views could be considered the least customized option. The Client is bound to the view that the control vendor supplies. However, the benefit is that Client-builder has the least amount of work to do. In the least-customized, the following concepts apply.
At the other extreme, a more monolithic, all-powerful Client could ignore the HMI mirror presentation views altogether. This approach could be considered the most customized option. In this case, the monolithic Client uses the HMI mirrors for data manipulation purpose only and the Client presents its own view of the data. The Client can develop any view it wishes. However, the Client-builder has the greatest amount of work in doing so. In the most-customized, the following concepts apply.
Figure 5 illustrates the range of customization.
Figure 5 : HMI Ranges of Customization
Today, the “most customized” approach with its monolithic, all-encompassing, micro-management of the controller presentation is most prevalent. This monolithic approach is most common mostly out of default because few, if any, control components provide HMI views. It is hoped that OMAC API MVC “V” methods will help change this situation.
Describe.
Comments concerning this module are solicited on the following topics.
Submit Feedback