Top Community Contributors
Enterprise Architect User Group: London 2017
Written by DT_Sam
RepoDoc, a call for testing
Written by ArchimetesRead more...
- We are Profiling EA Users
Managing a student project with Enterprise Architect - Part 4
Written by doug rosenberg
- CIO Review's 20 Most Promising BPM Solution Providers 2017
- Sparx Systems Pro Cloud Server - Coming Soon
- SD Times - How UML makes a DevOps-driven digital transformation possible
Use C#, Java, for your VB Scripting
Written by Helmut Ortmann
Especially when concerning more deeply embedded systems with complex multicore SoCs, it is often not easy to prove functional safety. In this case, using a model-based development platform such as Enterprise Architect along with a code generator optimized for embedded applications and a model-based testing tool with hardware-level debugger, this problem is relatively easy to solve. This combination allows developers to design, test and debug their software on the same level of abstraction - also on the real target.
Model-based development is finding more and more followers, and the field of industrial and automotive embedded systems is no exception. This is hardly surprising, since especially in these challenging areas of technology it is in fact more important than ever to use mechanisms that help to ensure that the product complies with all requirements and safety criteria. A growing use of multicore architectures increases this pressure even further, since the complex interactions in the parallel execution of software also significantly complicate the detection of functional safety.
Basically, working with models to develop embedded applications has many advantages, such as:
continuity from requirements management to final C / C ++ - code
object- and component-oriented development without having to switch to C ++
less effort when switching to C ++ later on
In the case of already-running embedded projects, practical experience shows that the best course of action is to begin to develop parts of the functionality using the model-based approach. In this way, the fairly new model-based approach can be brought - step by step - into the company without having to discard existing code while overwhelming developers.
In general, it is important to always keep in mind the specific requirements of the embedded environment. These include, for example:
the limited performance of the hardware; the code must efficiently conserve resources
a software bug detected too late is an often costly affair (e.g. expensive auto recalls)
that the code must satisfy very specific standards (MISRA), and
it should integrate well with existing code.
Modeling with very specific requirements
The use of a model-based development platform such as Enterprise Architect from Sparx Systems demonstrably improves not only the development process of software and systems, but also communication between the people involved. The graphically-oriented representation in UML enables instant documentation of the software architecture and development process, and makes it easier for non-UML professionals to understand.
UML / SysML are very broadly-applicable languages, but were not specifically designed for creating embedded systems. In order to adapt the Enterprise Architect modeling platform (Figure 1) - now with over 350,000 licenses in operation worldwide - to the specific requirements of embedded engineering, LieberLieber software therefore combines two key functions in the "LieberLieber Embedded Engineer" product package: code generation (uml2code) and debugging UML (UML debugger). As part of the entire tool chain, this solution - aimed primarily at embedded software developers and software architects, but which can also be useful for testers and integration managers - enables code generation from UML structures, state machines and activity models and generates platform-independent C ++ - and MISRA-compliant C code from UML models.
Learning to use models
A characteristic valued by most customers is the potential coexistence of handwritten and generated code. However, it should be ensured that generated code is only altered by changes in the model or the generator. This ensures that model and code are identical at all times. Basically, the automatic code generation especially makes sense if the code generator is not a black box, but a living part of the project. The variety of template-based solutions for code generation can have a negative influence on acceptance by developers and thus also the will to adapt.
In practice, code generators are therefore much more successful when they themselves are programs and can thus adapt to the familiar tools. However, should the complexity of the templates become too great, maintainability and finding fault are far more difficult than, for example, in a code generator that was developed in C # and can debug normally with Visual Studio. A particularly great benefit from code generation can be achieved when parts of a project are generated from a model based on the state machines or activities as agreed upon among the respective departments.
Code generation produces high value
Thus, as has already been mentioned, model-based development has a particularly high value when implemented for automatic code generation and subsequent debugging. By eliminating complex configuration parameters and any frameworks, entry into model-based code generation is greatly facilitated by uml2code. Decisions at the model level can be transparently traced in the generated code – which is easy to read and well structured. Project-specific requirements for code generation are implemented directly in the supplied source code. As a result, the requirements are easy to understand. In addition, the generated code can be integrated without any problems into existing software projects, the advantages of the model-based and the traditional development can thus be combined virtually as desired. Moreover, since the code generator source code is included, there is no dependence on the solution suppliers.
In order to shift software development completely to Enterprise Architect, the following rules – necessary for embedded engineering – are also included in “LieberLieber Embedded Engineer for Enterprise Architect”:
Instead of dynamic memory management, which is a violation against the MISRA C rules, objects are created statically.
State Machines are instead implemented by a whole set of functions via short and effective case distinctions.
Debugging functionality includes the development cycle
The LieberLieber UML Debugger also offers users a graphical UML debugger, integrated into Enterprise Architect, that allows the testing and debugging of the software, modelled in UML or SysML, directly on the model level. The debugging of the model can be started directly with the code generated from the model and compiled with any compiler. The code generator and the debugger form a closed circuit and allow debugging at the implementation level - namely the UML model. Thus, a possible error even right at the source - the model - can be located and corrected.
Testing on the real target
Coupling with the Universal Debugging Engine (UDE) by PLS, a tool specialized in optimized target access and detailed architecture support, allows the execution and debugging of the models directly on the actual target hardware. This is possible thanks to the UDE object model, which is based on COM technology from Microsoft. COM allows programmatic use by a variety of programming languages, including the world of .NET such as C#. COM refers to the totality of all documented objects, methods, properties, and data types as an object model. This means that almost all functional aspects of the Universal Debug Engine are covered. The LieberLieber UML debugger uses the object model of the UDE for, among other things, a connection to the microcontroller and the programming of the application into the FLASH memory of the target. It is also able to set breakpoints. This is done directly in the model, for example, on a particular state of a state machine. Due to the integrated code generation, it is known what line in the generated C / C ++ code this corresponds to. This can be handed over to the debugger for the setting of breakpoints. Furthermore, the program execution can be started and stopped via the object model. It is even possible to read out the variable values and display them in the UML debugger (Figure 2).
The coupling of a modeling tool with a code generator optimized for embedded systems and a model-based testing tool with hardware-level debugger gives the designer the advantage to not only design software at the model level, but also test and debug it on the real target. This seamless integration between tools increases the acceptance of such development methods, reduces the occurrence of errors and represents a large gain in efficiency. This innovative approach is suitable for new as well as existing projects.