Top Community Contributors
London User Group; Call for Speakers
Written by DT_Sam
Introducing RepoDoc, a document generator for Enterprise Architect
Written by Archimetes
Written by philchudley
SysML 1.4 reference card
Written by Guillaume
Enterprise Architect identified for Agile Development and DevOps: SD Times In-depth Feature
Written by sparxsystems
Enterprise Architect User Group: London 2017
Written by DT_Sam
Panorama 360 Insurance and Wealth Management Enterprise Business Framework is available on Amazon
Written by Pierre Gagne
We are Profiling EA Users
Written by sparxsystems
Automated FMU Generation from UML Models
IntroductionThe simulation of cyber-physical systems plays an increasingly important role in the development process of such systems. It enables the engineers to get a better understanding of the system in the early phases of the development. These complex systems are composed of different subsystems, each subsystem model is designed with its own specialized tool sets. Because of this heterogeneity the coordination and integration of these subsystem models becomes a challenge.
The Functional Mockup Interface (FMI) specification was developed by an industry consortium as a tool independent interface standard for integration and simulation of dynamic systems models. The models that conform to this standard are called Functional Mockup Units (FMU).
In this work we provide a method for automated FMU generation from UML models, making it possible to use model driven engineering techniques in the design and simulation of complex cyber-physical systems.
Functional Mockup InterfaceThe Functional Mockup Interface (FMI) specification is a standardized interface to be used in computer simulations for the creation of complex cyber-physical systems. The idea behind it being that if a real product is composed of many interconnected parts, it should be possible to create a virtual product which is itself assembled by combining a set of models. For example a car can be seen as a combination of many different subsystems, like engine, gearbox or thermal system. These subsystems can be modeled as Functional Mockup Units (FMU) which conform to the FMI standard.
The Functional Mockup Unit (FMU) represents a (runnable) model of a (sub)system and can be seen as the implementation of an Functional Mockup Interface (FMI). It is distributed as one ZIP file archive, with a ".fmu" file extension, containing:
- FMI model description file in XML format. It contains static information about the FMU instance. Most importantly the FMU variables and their attributes such as name, unit, default initial value etc. are stored in this file. A simulation tool importing the FMU will parse the model description file and initialize its environment accordingly.
- FMI application programming interface provided as a set of standardized C functions. C is used because of its portability and because it can be utilized in all embedded control systems. The C API can be provided either in source code and/or in binary form for one or several target machines, for example Windows dynamic link libraries (".dll") or Linux shared libraries (".so").
- Additional FMU data (tables, maps) in FMU specific file formats
The inclusion of the FMI model description file and the FMI API is mandatory according to the FMI standard.
ToolsEnterprise Architect is a visual modeling and design tool supporting various industry standards including UML. It is extensible via plugins written in C# or Visual Basic. The UML models from which we generate our FMU are defined with Enterprise Architect.
Embedded Engineer is a plugin for Enterprise Architect that features automated C/C++ code generation from UML models.
We further used the FMU SDK from QTronic for creating the FMI API. It also comes with a simple solver which we used to test our solution.
Running ExampleOur basic example to test our solution is called Inc. It is a simple FMU with an internal counter which is initialized at the beginning and it increments this counter by a specified step value, each time it gets triggered, until a final to value is reached or exceeded.
State MachineThe state machine contains just an initial pseudo state which initializes the state machine and a state called Step. The Step state has two transitions, one transition to itself, in case the counter is still lower then the to value, if this is the case, the inc() operation will be called and we are again in the Step state. If the value is equal or greater to the to value, it reaches the final state and no further process will be done.
Class diagramThe class diagram consists of two parts. The left part with the Inc class is project specific. It holds three attributes: counter, step and to. All attributes are of type int. The initial value for the counter is 0, for the step it's 5 and for the to value it's 50. The FSM classes on the right are the mandatory classes for the Embedded Engineer to be able to generate the state machine code.
Some specific implementation code also exists in various places. In the state machine you can see, that we have some guards on the transitions. These guards are actually code that will be used to generate the code for the state machine:
me->counter < me->to
me->counter >= me->to
The property me represents a pointer to an instance of the Inc class.
And finally the implementation of the inc() operation is also provided:
me->counter = me->counter + me->step;
Manual Code GenerationFirst we manually created our reference Inc FMU, the following steps where taken:
- UML models were defined in Enterprise Architect (class diagram and state machine diagram)
- C code was generated from the previously created models (with the Embedded Engineer plugin)
- The FMI model description xml file and the FMI API were created by hand
- The (compiled) FMI API was packaged together with the model description file into a FMU file. This was done with a batch script.
Automatic Code GenerationNow we want to automate the creation of the FMI model description file and the FMI API. For this purpose we wrote our own Enterprise Architect plugin. To be able to generate semantically correct FMI model description and FMI API artifacts, we attached additional information to the UML models. This was achived through the definition of various UML stereotypes for UML class attributes and methods. Since the FMI defines its own data types we also had to map the data types used in the UML models to the corresponding FMI data types. With these challenges addressed we were able to implement our FMU generation plugin.
Future WorkOur work comprises a fundamental prototype that is only a start and could be improved in various ways. The following list describes some issues that could be tackled.
- One limitation of the current implementation is that we are not able to provide initial values for the FMU. Consequently, to test different configurations of our FMU, we always have to set the default values in the UML models and regenerate the FMU for the simulator again. Hence, future work includes creating new stereo types for initialization of FMU settings/variables and testing these bindings.
- We used the FMU SDK simulator for this project. Other (more powerful) simulators should be tested too. Furthermore, co-simulation with other FMUs needs to be tested.
- In our project we restricted ourselves to just look at discrete functions by using the event system of the FMU. To continue the journey we also have to consider continuous functions.
- More complex examples should be considered to test the capabilities of the automatically generated code. By creating more complex examples the practical limitations of modeling a FMU with a class diagram and a finite state machine need to be discovered. Questions like "What can be implemented?" and "What can not be implemented?" need to be answered.
- The automated code generation process could be reduced to a one-click functionality to directly generate the ".fmu" file without any additional compilation and packaging step necessary.
Recently I have been reverse engineering a state transition (officially a state machine but I prefer the term state transition model) to understand the complex life-cycle of our application’s central object.
I had seen a demo on model simulation but the focus was more on a generated model from source rather than a hand fashioned UML model. This post is a walk through on the process and hopefully some takeaways from what I’ve learned.
Understanding complex systems
I came into a project that is well down the road to completion but sorely lacking in any concrete documentation which was becoming a pain point for everyone – and particularly for me – the new analyst tasked with helping out.
One of my first tasks was to document some ‘light’ form of a state model to get an idea of all of the possible scenarios and break down some of the complexity. I’ve iterated through several versions (or styles) of the state model trying to provide a simpler view of states and state transitions but the model was just very complicated and the diagrams were too busy. Understanding it myself was hard enough and trying to validate each of the scenarios was proving far too time-consuming.
States and multiple sub-states – too many paths!
My main problem was due to having states and multiple sub-states being dependent on single transitions. For example, we had something like this
OBJECT (super state life-cycle)
-- sub item1 (sub state life-cycle)
-- sub item2 (sub state life-cycle)
-- shipping item (sub state life-cycle)
-- other items (sub state life-cycle)
So for every transition, we could have movements of one or all of the sub-states, and depending on what states they were in, we could also have super-state changes.
I threw together a quick example of what things (sort of!) looked like in our world – its a horribly rushed example but gets across the point.
Model simulation and simulation variables!
So I got to the point where I’d modelled enough states and sub-states that it was very difficult to validate the accuracy – so I decided to use a bit of smarts and try out model simulation.
I setup my workspace to get the simulation controls ready. It looks somewhat like this.
With this setup we can kick off model simulations to run through transitions, select the required ‘trigger’ to choose paths and even save triggers to define pre-defined scenarios to run through. Note: I’ll post a separate article on how to do each step in more detail.
All of this is nothing new? Well that's get into some simulation variables to track what's going on at each point.
First of all, I’ve run through a created scenario manually (interpreted in EA language) by manually selecting the triggers as they come up. You can then save these as a trigger set and select to signal the triggers automatically – now we can fly through our models after defining our criteria.
The above shows a simulation in action as it goes through the path I defined manually and you can see the trigger sequence waiting to be fired to progress the simulation further.
What I end up at the end is a list of states / decisions / elements that I have passed through in the console log and a list of triggers that were fired.
For me this wasn’t all that useful – just a flat list of states and sub-states at a single level wasn't;t really enough – plus there was more detail I wanted to capture that would make these even more useful.
Enter simulation variables
I stumbled on simulation variables when trawling through some EA help file about getting my simulations to work and instantly through of a use (more on that soon).
Given I am reverse engineering a model and not trying to do and model-driven development, I feel I can use simulation in this way but I certainly appreciate this is a hack job and not their intended purpose (sorry everyone!).
I added an operation to each state called ‘updateVars’ and added a behaviour to each to assign simple variable.
Protip: To avoid cluttering up your diagram with all your updateVars on each state element – hide the operations from the diagram in the diagram properties. Un-tick the ‘Operations’ box under Show Compartments.
So now that I have added simulation variables to my model, I can see what the states and sub-states are at any given point in the model – either by pausing or setting simulation break points (another great feature!).
Writing to simulation console
Although simulation variables were interesting they didn't really offer me much over what I had before – just a different way of viewing the same state/substate information. What I really wanted was to be able to use this concept to show other important things that are going on at certain steps.
Another cool feature Sparx have included here is being about to output to the simulation console so you can supplement the standard list of element names with your own text.
So at certain steps, I have UI actions or account deductions, that I wanted to bring into my model and highlight to my stakeholders where and when these were actually occurring. Strictly nothing to do with a state machine but I'm not here to win UML medals – just provide my stakeholders something they can understand!
So on one of the updateVars actions I can add another line like this:
The magic words here are Trace() which allow you to output a string to the console log. What does it look like in the simulation console? I'm glad you asked – it looks something like this.
I ended up adding custom Trace() events for each state so I could better represent state /sub state movements and also record important events along the model.
Hopefully you followed along with me on this and I’ve had some interest regarding doing a screencast on the topic so please let me know in the comments if you’re interested and I’ll get one together.
This was an overview article to demonstrate the main features and I will come back and go through some of the steps I rushed through in more detail in the next post.
This paper introduces Enterprise Architect's simulation capabilities for State Machines by means of an example model.
State Machine simulation can help you to verify that the run-time behavior of your designed system conforms to specification. In this paper, we explore an example 'Digital Clock' system model and bring to life several aspects of Enterprise Architect's State Machine simulation support.