EN 
DE Efficient embedded software through interactive statecharts
Authors: Dr. Klaus Birken, Axel Terfloth, itemis AG
Contribution – Embedded Software Engineering Congress 2015
State machines have proven their worth in many embedded software implementation projects. They allow for the graphical description of component behavior and the efficient generation of code in C or C++. The interaction of statecharts with their environment is described using concepts such as events and formal interfaces. The open-source project Franca allows the modeling of such interfaces, specifically their semantics (i.e., allowed sequences of events). In most projects, this information is only documented informally; with Franca, the allowed sequences are machine-readable and thus automatically verifiable. Tools for creating state machines can leverage this semantic information and provide interactive support to the developer, for example, by indicating expected or to-be-sent events, as well as unreachable states. This ensures compliance with all interface contracts and ultimately safeguards code quality.
Franca describes interfaces and their dynamics
In embedded development, interfaces between components or subsystems should not be designed and represented directly as C header files, but rather at a higher level of abstraction that is independent of the programming language. This is achieved through an interface description language or IDL (short for: Interface Definition Language) possible [1]. This reduces the syntax to precisely the vocabulary needed for the content-related definition of interfaces. Mapping to a programming language is typically done through code generation.
An Integrated Design Language (IDL) allows interfaces to be formally described independently of the target platform and language. This enables the same interfaces to be used for integration across subsystems, programming languages, controllers, and ECUs. Interfaces thus become a comprehensive tool for architects and developers. This is an open-source project. Franca [2] offers such an IDL and various tools for creating, editing, or generating program code from interfaces. Franca was initially developed within the GENIVI consortium [3] and is currently on its way to becoming an official project under the umbrella of the Eclipse Foundation. Various aspects of Franca have been presented at previous ESE conferences (e.g., [1], [4], [6]).
The typical language range of an IDL covers the static This includes parts of interfaces, i.e., data types, attributes, and function calls. This is initially sufficient for documenting the interfaces and also for code generation, since programming languages also only describe static parts of interfaces (C headers or C++ classes do not contain any specifications, e.g., for call orders).
The dynamic Today, the dynamic aspects of interfaces are usually only considered during implementation. These include allowed call sequences and their parameter values. Non-functional properties such as timing restrictions also belong to the dynamic aspects. Especially for more complex systems, it is advisable to define the dynamic aspects as part of the interface definition, since the interface designer has the most precise understanding of how their interface should be used [4]. By formally defining the dynamics, they can communicate this to subsequent implementers. This improves the quality of the resulting software system.
Franca supports precisely this description of the dynamic behavior of interfaces. To this end, Franca IDL offers the possibility of creating contracts (so-called...). contractsThe interfaces are specified in the form of protocol state machines. These are state machines located on the connection between the two communicating software parts (e.g., components) and react to communication events in both directions. For example, a state transition occurs if the client side calls a remote method. Another state transition is triggered when the server side sends the response message for this method. In each state of the protocol state machine, only events described by outgoing transitions are permitted. All other events would be protocol errors and thus violations of the agreement.
Franca allows state machines to be textually modeled as part of the IDL. A previous article demonstrated in detail how such behavior definitions can be used to validate trace data from a real embedded system [4]. This article now describes how such dynamic definitions can be implemented at the interface. during implementation can be used in an embedded system, provided that this implementation is carried out using a statechart modeling tool.
Creating embedded software using statecharts
State machines are an understandable formalism that has proven useful for specifying and implementing the reactive behavior of systems. There are several approaches to efficiently implementing state machines in programming languages such as C and C++. As with IDLs, describing state machines at a higher level of abstraction in the form of models has also proven effective. State machines are usually specified graphically as statecharts. These programming language-independent models can then be translated into C, C++, or code in other programming languages and integrated into the software. Since state machines describe the dynamic behavior of systems, tools for executing the state machines in the modeling environment, such as simulators, are particularly helpful during development.
The open-source project YAKINDU Statechart Tools (YSCT) [5] provides a tool environment for modeling, simulation and code generation for statecharts.
Statecharts with Franca interfaces – Integration of tools and models
Software components implemented using statecharts typically interact with other software components. This necessitates well-defined interfaces. Therefore, it makes sense to describe the interfaces of the software components using an IDL. Such an integration exists between Franca and YSCT. The statecharts offer the possibility to define ports that serve to connect suitable software components. For each port, it can be specified whether an interface defined in Franca is provided via it (provide) or used (requireThe events, methods, and data elements defined in the interface can then be used directly in the statechart. Depending on whether the statechart acts as a user or provider of an interface, appropriate elements are available.
Software components often have more than one interface and must also be interface-compliant with regard to their dynamic behavior. However, the complexity of the interfaces potentially multiplies during component implementation, so that validation and testing efforts can become very high without additional tools. The following example demonstrates how statechart-based implementation state machines can be automatically validated by using protocol state machines for the interfaces.
Example project: Robot arm control
As an example of the described integration of the open-source tools YSCT and Franca, a control software for a robot arm is used. The robot hardware is an AL5D kit from Lynxmotion with an SSC32 control board. Figure 1 (see PDF) shows the robot arm; this consists of five axes and a gripping unit.
For our example, we model the behavior at the application interface of the robot controller; this allows the control of the following functions:
- The gripper can grasp and release objects (operations). grave and release).
- The arm can move the gripper to a specific Cartesian position (operation). move).
The static elements of the interface are therefore the methods. move, grave and release. Each execution of one of these methods consists of two events: First, the client side of the interface calls the method; then, the server side sends a positive or negative response. In addition to this basic protocol definition, there are business-related restrictions on the permitted processes. For example, a release-Operation without prior grave-Operation not meaningful. All allowed sequences can be determined by the protocol state machine from Figure 2 (see PDF) define.
A protocol state machine as shown in Figure 2 (see PDFThe interface definition is formulated using Franca IDL. It's important to note that this only describes the semantics of the interface and not the actual implementation of the control component. This is created using a separate, much more detailed state machine with the Yakindu Statecharts tool.
Interactive feedback during statechart modeling
A previous ESE article demonstrated how recorded trace data can be automatically validated against one or more protocol state machines [4]. This improves the quality of the resulting product by allowing implementation errors to be specifically identified and corrected during testing. However, it is better to avoid errors during implementation itself. This is made possible by the integration of YSCT and Franca: The implementation state charts are continuously checked against the protocol state machines of the involved Franca interfaces during development. The developer is guided through this process by interactive feedback.
Figure 3 (see PDFFigure 2 shows, using a screenshot for the RobotArm example described above, what information is derived from the interface definitions and how this information is displayed to the user. The developer has just started building the state machine for the RobotArm control component. This component implements the RobotArm interface with the behavior shown in Figure 2 (see Figure 2). PDF)
The following information is derived from the interface definition:
- In the state Idle The operation will indeed be called move treated (see Transition) IdleàMoving), the treatment of the operation grave However, it is missing. This is indicated by a warning. This guides the developer to create another transition (and another state) to handle the issue. grave-to supplement the call.
- The condition Moving is through a move-Request reached. The response to the moveHowever, the operation is still pending; this is indicated by a piece of information („Proposed send…“). The developer is thus guided to the move-response to implement.
Further work on the state machine interactively generates additional warnings and information, which are then processed through further developer action. Ultimately, a state machine is created that no longer contains any warnings. This demonstrates that the protocol state machine's specifications have been met. For complex components with more than one interface, this positive effect is amplified because the developer can be guided even more effectively by the increased amount of information.
In the next step, for each warning or piece of information from the tool, suggestions are offered on how to directly resolve or implement the issue with a single mouse click (so-called...). QuickfixesThis allows the developer to automatically generate entire parts of the state machine and simultaneously resolve any existing warnings.
Advantages for embedded practice
Tools for modeling state machines and generating code are widely used in embedded projects. Building on this, this article demonstrates how the innovative consideration of interface semantics can guide developers to ensure that the behavior of their software components conforms to predefined interfaces. Developers are automatically alerted to potential errors as early as possible, thus reducing their workload. Implementation errors are detected and corrected early, thereby improving software quality. The costly correction of integration errors and errors in production is avoided as much as possible. Furthermore, the tool's automated suggestions, described above, simplify diagram editing for developers, accelerating their overall work.
In general, model-based interface definition is necessary and beneficial, especially for distributed applications. Franca IDL allows interfaces to be formally defined and then serves as a machine-readable "contract" for the participating parties and systems. Franca is available to everyone at [1] and can be downloaded and used directly, including documentation. Similarly, Yakindu Statecharts can be used for implementing embedded systems without license fees. The integration of both tools offers additional benefits for developers and architects.
References
[1] K. Birken: Interfaces fully under control – Model-based approaches with the open-source tool Franca. In: Conference Proceedings – Embedded Software Engineering Congress 2012, Sindelfingen, 2012.
[2] https://code.google.com/a/eclipselabs.org/p/franca/
[4] K. Birken: Dynamically describe interfaces with Franca. In: Conference Proceedings – Embedded Software Engineering Congress 2013, Sindelfingen, 2013.
[5] Yakindu Statechart Tools (https://statecharts.org)
[6] T. Szabo, K. Birken: Model-based in the Internet of Things. In: Conference Proceedings – Embedded Software Engineering Congress 2014, Sindelfingen, 2014.
Open Source – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Open Source / Embedded Software Engineering.
Training & coaching on the other topics in our portfolio can be found here. here.
Open Source – Expertise
Valuable expertise in the field of Open Source / Embedded Software Engineering is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
