Thursday, October 29, 2015

How does EB GUIDE run your model on a device?

Martin Riedl

EB GUIDE’s model-based developmentYou probably already know that EB GUIDE’s model-based development lets you create user interfaces for devices. But you may be wondering how EB GUIDE runs your model on a target device and how your interface uses data and events from the device or other, third-party devices such as sensors. Read on to learn how.

EB GUIDE Studio: Build the model on the desktop

Let’s say you’re using EB GUIDE to build the interface for a vehicle’s dashboard system. We’ll focus on the portion of the UI that displays the gas gauge. You use EB GUIDE Studio, the WYSIWYG modeler, to develop the HMI at your desktop. Your HMI:

  1. Defines a value which the gas gauge sensor will write, indicating the quantity of gas in the tanks.
  2. When that value changes, the HMI will be notified.
  3. Runs script you write to perform a calculation to determine the number of bar segments to display, based on the gas value.
  4. Uses the bar graph widget to display the correct number of bar segments in the gauge by setting the input value of the widget to the calculated value.

EB GUIDE GTF: Run the model on your target device

When you’re ready to run your model on a target device, for test or production purposes, you first install the EB GUIDE Graphics Target Framework (GTF) onto the target device with its operating system. The GTF is the runtime framework that translates your HMI model.

When you’re ready to run your model on the target device, you use EB GUIDE to export the model and then copy the files it generates onto the target device.

(EB GUIDE supports a wide variety of devices and OS’s commonly used in different industries.)

EB GUIDE SDK and device APIs

But what about getting data to and from sensors, like the gas tank sensor? EB GUIDE provides an SDK and APIs which device manufacturers can use to enable communication between an application and the Graphics Target Framework.

One set of API functions communicates with the data pool, which is where data such as the value from the gas tank sensor, is stored. The other communicates with the event system, which allows the application and the HMI to communicate asynchronously.

(If the third-party application you’re using needs to support EB GUIDE’s Graphics Target Framework, contact us.)

The applications and the HMI are decoupled and run independently. Let’s walk through our example and see how the calls would work.

  1. The system launches and the application and the HMI start.
  2. The third-party application determines the current fuel state and writes the data to the correct datapool value using one of the API functions that are part of the EB GUIDE SDK. For example, DP_WRITE_VALUE(dp_Value_Fuellevel, currentValue).
  3. The HMI performs a calculation to determine the correct number of bar segments.
  4. The display is updated automatically once the HMI writes the Writes the new value that is associated with the bar graph widget.
  5. Note that the application continues to check and update values in the datapool as they change. The HMI is notified whenever one of the values change and performs its calculations and updates the datapool.

For more details about the operation of the GTF and other components of EB GUIDE, see the EB GUIDE System Integration diagram .

And if you haven’t tried EB GUIDE yet, don’t forget you can download the EB GUIDE Community Edition free!