Thursday, September 10, 2015

Why use model-based HMI development?

Martin Riedl

Most of our new customers have been developing human machine interfaces (HMIs) for years and doing it the hard way: writing code from scratch. The idea of model-based HMI development is new to them. Before investing in the approach, they want to understand the benefits. So we thought we’d share some of the common scenarios we see and how EB GUIDE helps address them.

It’s clear in my head: Building HMIs from an idea

Some customers provide detailed specifications and wireframes for their HMIs. Others have an idea of what they want their HMIs to do but don’t have detailed specifications or designs. They may know the functionality they want to implement but not how they want to implement it. It may be that our customer received instructions to build an HMI with certain capabilities—without directions beyond that. Or they might be using agile methods of development, so they have clear scenarios and requirements, but they don’t have a specific design.

Writing code takes considerable time. Without detailed specifications and wireframes, you’re spending time building an HMI that you may have to throw away or substantially revise. Even building a prototype through code is time-consuming.

 

 

Coding is an expensive way to build consensus.

The alternative is to spend months creating specifications and designs and then gain approval—before you ever start programming. That kind of process nails down the specifics so you don’t waste programming time, but it delays the project and doesn’t allow for late-breaking design changes, sudden market shifts, or accommodating new technologies. If you do manage to accommodate those changes, they are probably very expensive.

Model-based development is ideal for this situation. With EB GUIDE 6, you can build a prototype of the HMI without a lot of coding. The client can see and use the prototype and can provide feedback early on.

Rather than trying to represent the design in specifications or diagrams, you can show an executable specification, such as a running simulation. EB GUIDE allows clients and stakeholders to view the product on a PC or to run it on a target device.

Model-based HMI development lets you quickly iterate on the design to come to agreement on a direction, UI standards, and look and feel. After the initial direction is agreed upon, you can continue to develop the product through EB GUIDE, adding features, responding to feedback, and testing and refining as you go. Model-based development is fast enough that you don’t need to invest in detailed specifications or diagrams—the model itself is the specification. And the cost of development is low enough to warrant designing as you build.

Grasping spaghetti: Managing variations and iterations of your HMI

Many of our clients build on their initial HMI code base to create different versions of the HMI. They may need to support different target models or devices, incorporate new technologies, fix bugs, or release updates to the HMI.

Managing variants can be challenging when all of your HMI development is done through coding. You may need to select, delete, or replace portions of the code for each version of the HMI. When you have to update a function or part of the core program, it can be difficult or even impossible to find and update the particular code in all the variants of the HMI.

And changing the look or feel of the HMI across all versions may be impossible when you work from code.

When you use model-based development through EB GUIDE, you can define a base model HMI and then specify inheritance from it. For example, you might use inheritances to support regional versions of the HMI or for specific models of a vehicle or device.

With model-based development, you select the controls and workflows to include in a new version and simply move them to a new branch in EB GUIDE. An update to the core model populates to all versions that inherit the updated components. This makes it much easier and faster to manage and update different versions of the same core HMI.

Change is inevitable: Adapting your HMI to support new technology

HMIs typically leverage a lot of systems, hardware, and tools. It’s a fast-moving industry, and the hardware and software used by HMIs are constantly changing. Nobody wants to be left behind. Being able to adopt the latest and greatest technology can make the difference in a highly competitive marketplace.

Model-based HMI development has the edge here. With EB GUIDE, the hardware and OS are abstracted from the HMI. You don’t have to worry about the details of the underlying target device as you build your HMI. Similarly, any components or supporting applications are separated and abstracted, so you can work on the model without writing code tied to a specific component—which may have to change when the component changes. Model-based HMIs enable fixed, stable interfaces.

For example, if you’re building a feature in your HMI panel to display a low fuel warning, the HMI connects to a hardware sensor in the fuel system. The sensor’s application provides data to the EB GUIDE data model. Once the sensor’s value is part of the data model, it can be used by different modules, displayed (as number or a needle), converted (from gallons to liters), or combined with other data. That means you can use the sensor data, but you can also combine it with other data from other sensors. For example, your HMI might combine time of day, status of driving lights, and data from a brightness sensor to determine when to switch from day driving to night driving.

Moreover, you aren’t limited to the notification methods provided by the sensor application. Since you receive the data independent from the delivery method, you can choose how to pass the information on to the user through your HMI: as a number, an icon, a blinking light, or a needle, among other options. The presentation layer is separated for you from the data layer.

Lastly, if the sensor is replaced with a new type of component, you don’t have to tear apart your HMI’s code to support it. The new sensor’s application simply passes the data to EB GUIDE. Since your HMI model already incorporates the data and makes appropriate use of it, you don’t have to make any changes to your model.

Those are just some of the common scenarios we see among our customers—and the reason they buy EB GUIDE.

You can try EB GUIDE for free by downloading our Community Edition