Introduction

An easy-to-use, intuitive GUI drives the sale of many popular products like in-dashboard navigation, infotainment systems and telecommunications products. The rich graphics found on popular GUI applications shows how important good software is, but more importantly reveals a critical weakness when developing a high quality GUI: meeting the host-to-target challenge.

Traditionally, building a high quality GUI is a laborious task where mistakes can be easily made because developers have to work on the host and the target to create the GUI and put it on the RTOS. What’s needed is a solution that incorporates GUI development into the embedded software process and:

• Keeps development in synch with GUI creation
• Solves RTOS integration issues by linking the code to the RTOS
• Enables developers to work in one design environment that helps ease issues

GUI development need not be a tedious task for embedded development teams. A new approach offers a solution that uses models to develop software with a special development capability that provides an easy solution to GUI challenges. The advantage to this approach is that your GUI development team is integrated in your overall embedded development process. Additionally, the design environment allows you to fully test the GUI, enabling you to test your GUI on Microsoft® Windows® and switch to the RTOS with no code changes. Finally, the new process solves the host-to-target challenge by enabling you to create the GUI on the host, fully test and simulate it, and then deploy it on the embedded target in one cohesive environment.

This article will outline how this approach works, including examples from actual applications. You’ll see how this new process offers developers:

• The freedom to switch RTOS with no rebuilding tasks
• A seamless RTOS integration for the smoothest process available
• An improved workflow between teams
• Better communications for improved development outcomes

The Challenges

With GUIs becoming more pervasive and sophisticated, the ability to develop a high quality GUI is more critical than ever before. One of the primary challenges is how to solve the host-to-target challenge. This challenge includes creating buttons and other types of GUI devices on the host and then having to redevelop them and get them working on the target. Typical applications that need GUIs are traditionally designed and implemented on a host system. These applications model and drive the behavior that is associated with a given interface. The problem comes when the application and GUI are ready to be moved onto a target system.

Global Positioning System 
The challenge is illustrated by the example of a consumer using their GPS to map to local restaurants, etc., in their vehicle. On a desktop, the mapping software is familiar and you can use your keyboard to get the needed information. In the vehicle, the GPS already knows your location, but it’s not desirable to require users to use a full keyboard to enter data — plus, you want turn-by-turn directions in real-time.  The first challenge is modeling this to a desktop, but it’s not as simple as taking a typical desktop mapping application and moving it to the vehicle due to the complexities explained above. Let’s assume that we have designed a GUI that works well for these purposes. The GUI now makes a request to the application to retrieve the data that the user has requested. The application passes this information to the GUI, which renders these images on the screen. This requires a tight interface between the GUI and the application, and gets tested on the host machine. Given all the work that has been done on the host machine, now you want to bring it down to the target. To be successful, you want to make sure everything runs exactly the same on the target as it does on the host (interactions, etc.).

From this GPS example, you can see that the GUI is very much a part of the application and is embedded into the software application itself. The user is entering in data, getting feedback (turn by turn directions), making the GUI interdependent on the application. No longer is the GUI a simple display device that you interact with occasionally, today’s GUIs are pervasive and powerful.  Current software applications are written using Model Driven Development™ (MDD™) concepts: GUI development needs to be integrated into the MDD process as well.

Model Driven Development has proven that you can take applications developed and tested on the host and have the application work on the target. Taking the GUI and moving it onto the target system is essentially a subset of this challenge.

MDD has brought a better understanding of your design to embedded, real-time and technical application developers. Also, MDD has brought a better understanding about testing on the host and then running the application on the RTOS. Building the GUI once and having it interact with the applications model itself is essential, allowing engineers and developers to build the GUI once and in only one place.

Why Model Driven Development?

MDD technology enables professionals to achieve unparalleled productivity gains over traditional document driven approaches by enabling users to specify the system design and architecture graphically, simulate and automatically validate the system as it is being built. This allows engineers and developers to ultimately produce a quality systems specification that is correct, non-ambiguous and completely satisfies original requirements.

MDD provides systems engineers and software developers with Unified Modeling Language™ (UML®)/Systems Modeling Language™ (SysML™) compliant products that can be extended for domain-specific modeling, providing a truly collaborative development environment that allows both large and small teams to communicate effectively and productively. Integrated requirements management and traceability features ensure that the design always meets the requirements. Design for Testability (DFT) capabilities reduce defects early in the process and always validate against the requirements. MDD accelerates development by generating full applications, not just code frames. These technologies, packaged in an easy-to-use format, make MDD the solution for the software and systems engineers.

Figure 1: MDD’s key enabling technologies

MDD lends itself to a design approach where the software can be constantly executed and validated on the host environment, then brought right down to the embedded target for target based testing. The MDD process allows users to develop high quality GUIs and embedded applications in less time.

With the advent of the new design environment afforded by the new Tilcon and Telelogic Rhapsody® integration, this problem is solved: the solution is provided by offering the only MDD products in each company’s respective environment.

Figure 2: Satellite beaming down data to a GPS illustrates how pervasive and powerful GUI applications have become to users

Synchronization
Another challenge that is very relevant but often overlooked is the synchronization of application development with GUI development. The processes in development are similar, but the separate requirements, development teams, and integration can make synchronization of these two elements a real challenge.

Below is a view of common processes for GUI and application development:

Ideally, the GUI development stays in synch with the logic application throughout the development processes, but this is often not the case. However, the tools that are chosen for development considerably impact the ease of Integration and Porting. MDD solves the host-to-target problem for the application by including MDD as part of the GUI development process, and having the process keep the GUI and the development process in synch. The best way to keep these solutions in synch is to have them stay as part of the same process, rather than two processes. If you add or drop a button from the GUI, you can instantly check that the button works with the application and still gives the GUI the correct data back.

A key advantage that UML development offers is that interfaces are explicit modeling elements: assuring that interfaces don’t vary much from the GUI and the application is a good way to make sure that the GUI builds correctly. The high level of interface exposure in the design itself assures that the GUI and the application interfaces are easily understood and can be rapidly checked to make sure that they communicate properly. Thus, synchronization issues between the GUI and the application are eased when you use an MDD approach.
 
There are several means of managing the application logic and GUI behavior into a unified approach. A very popular and effective solution is to design a system (Application flow + GUI behavior) within a UML model.

How it Works

Using UML models to design complex system logic makes the overall task more manageable and allows for system-wide verification of expected behavior.  Sophisticated UML tools aide in the Porting process from host-to-target by generating the model into clean source code that is then compiled into an executable for the target system.

Integration
Embedded devices with GUIs, whether created from scratch or through the latest COTS tools available on the market, have little value without a supporting backend application. A GUI is static without a behavioral logic response to user inputs. Likewise, an application for such devices has little effect without a supporting interface that is functional, intuitive, and aesthetically pleasing to use.

Integrating of the application and the GUI interface behavior possesses unique challenges that should not be underestimated. These challenges present themselves in all phases of design and development. An effective system behavior model can be thoroughly verified if it can communicate directly to its GUI counterpart. And, if a GUI can have its behavioral model reacting to user inputs during development, then the GUI can be simulated and tested for all expected conditions.

When applications and GUIs are developed independently, the level of synergy derived is not as great as if they were developed and integrated on an on-going basis. The flexibility of adding functional GUI blocks in a UML model throughout development goes a long way towards reducing integration pains.

Even for system applications developed separately from GUI applications, the correct tools allow for simplifying the integration process.

Below is an example embedded radio device that has application logic and GUI fully integrated via a UML model:

Figure 4: Shows a UML Statechart being driven by the buttons on the GUI and repopulated in the GUI data with (e.g. the map) with data as it reaches the appropriate states

By integrating GUI development into an embedded development environment, engineers are able to develop GUIs in a unified solution whose foundation exists inside the embedded system and code

GUI Verification
For an interface to be fully verified within the behavioral scope of its intended design, the development environment needs to be available and robust enough to simulate different input and output scenarios. A UML model, with its functional blocks and visually traceable communication flows, allows for full GUI verification.

Porting
Moving application software to a target system requires recompiling and rebuilding the source to meet the target’s environment. This exercise in itself typically adds to your project’s complexities. However, moving a GUI application from host-to-target is typically not a simple task. Graphics code is often native to the graphics library being used, and many environments have their own graphics library. This adds the complexity of having to re-write the graphics layer when moving from host-to-target.

Figure 5: Using the same graphics library, the host and target communicate with the same API calls, just like MDD environments operate

What MDD brings to the porting process is that you can quickly go from host-to- target, leveraging the standard API that the software developer calls and replacing it with the correct Operating System (OS).  Now there are no changes to the OS code to make it run on the OS.  Many users have worked with MDD to achieve this purpose, now what is happening is that this solution is available to GUI developers as well.

Particularly for embedded real-time devices, dealing with different graphics libraries and porting GUIs from host-to-target adds a level of complexity that affects the end product process: 

• Graphics layer porting and rewrite
• Development expertise
• Consistent GUI look and feel
• Performance between different embedded GUI environments
• Quality assurance and verification
• Time

With a good GUI design and a portability layer that treats Windows as one OS and the Real Time Operating System (RTOS) of your choice as another OS, a platform-independent MDD environment makes this work for GUIs too.

The technological challenges of porting graphics from host-to-target are separate from the business implications of added time, costs, and resources.

Solution

A solution is needed that allows an interface to be easily prototyped, developed, integrated, and ported across multiple RTOS and target platforms. Providing an encompassing solution via in-house GUI code often proves to be too time consuming and effort-driven to justify. The value of Commercial-Off-The-Shelf (COTS) GUI solutions becomes clear when considering all of the process factors that affect a project’s timeline. Leading-edge GUI COTS solutions eliminate the need to re-develop interfaces when porting between RTOS.

The \Rhapsody and Tilcon integration offers a powerful solution to the GUI host-to-target challenge. Rhapsody is the MDD solution of choice because it supports a seamless transition from host-to-target using an OS adaptor layer.  Tilcon is the GUI application development environment of choice because it allows you to build one GUI and have it work both on a host and on the target RTOS of your choice. The integration between these two solutions cracks the GUI host-to-target challenge, enabling you to develop powerful embedded GUI applications.

by Marty Bakal, Senior Application Engineer, Telelogic
and Ariel Bautista, Technical Account Manager, Tilcon Software Ltd.

November 27, 2007

Martin Bakal is a Senior Application Engineer with Telelogic Modeling Division. He has a BS in Electrical Engineering from Tufts University and has consulted on numerous embedded projects from the Lockheed Martin on the Joint Strike Fighter (JSF) project to working with various customers in the automotive industry.
 
Ariel Bautista is a “Technical Account Manager” with Tilcon Software Ltd. He graduated from the University of Ottawa with a BS in Computer Engineering and minor in Management. Ariel has considerable experience working with customers all over the world and carrying out product presentations and training.

[back to top]