State machine origami

State machines can be used to graphically describe the behavior of components and generate efficient code in C or C++. The interaction of statecharts with their environment is described using concepts such as events and formal interfaces.

Information: YAKINDU Statechart Tools Is Now itemis CREATE

Originally published in German on embedded software engineering on August 09th 2017 | Author / Editor: Dr. Klaus Birken and Axel Terfloth / Christine Kremser

Franca allows the modeling of such interfaces, especially their semantics, i.e., permitted sequences of events. In most projects, this information is only documented informally – with Franca, the permitted processes are machine-readable and can therefore be checked automatically. Tools for creating state machines can make use of this semantic information and support the developer interactively, e.g., by pointing out expected or to-be-sent events as well as unattainable states. This ensures compliance with all interface contracts and ultimately ensures the quality of the code.

Describing interfaces and their dynamics with Franca

In embedded development, interfaces between components or subsystems should not be designed and represented directly as C header files, but at a higher abstraction level, independent of the programming language. This is made possible by a description language for interfaces or IDL (short for Interface Definition Language)^[1]. This reduces the syntax to exactly the vocabulary needed for the definition of interfaces. The mapping to a programming language is typically done by code generation.

An IDL allows the formal description of interfaces to be independent of the target platform and language. This allows 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.

Franca^[2] offers such an IDL, plus various tools for creating, editing, and generating program code from interfaces. Franca was initially developed as part of the GENIVI consortium^[3] and is currently on its way to becoming an official project under the umbrella of the Eclipse Foundation. The different aspects of Franca were presented at past ESE conferences, e.g..^[1][4][6]

The typical language range of an IDL covers the static parts of interfaces, i.e., data types, attributes, and function calls. This is initially sufficient for the documentation of the interfaces and also for code generation, since only static parts of interfaces are described in programming languages (C headers or C++ classes do not contain any definitions of, e.g., call sequences).

Today, the dynamic parts of interfaces are usually only taken into account during implementation. These are permitted call sequences and their parameter values. Non-functional properties, such as timing restrictions, also belong to the dynamic parts.

Especially for more complex systems, it makes sense to define the dynamic components as part of the interface definition, because the interface designer has the most exact idea of how to use his interface^[4]. By formally defining the dynamics, the interface designer can communicate this to subsequent implementers. This increases the quality of the reulting software system.

Franca supports exactly this description of the dynamic behavior of interfaces. For this, Franca IDL offers the possibility to specify contracts of interfaces in the form of protocol state machines. These are state machines which are located at 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 when the client side calls a remote method. Another state transition is triggered when the server side sends the response message to this method. In each state of the protocol machine, only those events described by outgoing transitions are allowed. All other events would be protocol errors and thus violations of the contract.

With Franca, the state machines are textually modeled as part of the IDL. In a previous year's article, it was shown in detail how such behavior definitions can be used to validate trace data from a real embedded system in operation^[4]. This article now describes how such dynamic definitions can be used at the interface already during the implementation of an embedded system, if this implementation is done using a statechart modeling tool.

Creating embedded software using statecharts

State machines are an understandable formalism that has proven ideal for the specification and implementation of the reactive behavior of systems. There are a number of approaches to efficiently implement state machines in programming languages such as C and C++.

YAKINDU Statechart Tools (is now itemis CREATE)^[5] provides a tooling environment for modeling, simulation, and code generation of statecharts.

Statecharts with Franca interfaces – integration of tools and models

Software components that are implemented using statecharts usually interact with other software components. This requires well-defined interfaces, which suggests to describe the interfaces of the software components with an IDL.

Such an integration exists between Franca and YSCT. The statecharts offer the possibility to define ports for the connection of suitable software components. For each port, it can be specified whether an interface defined in Franca is to be provided or used.

The 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 as a provider of an interface, suitable 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 in the implementation of the components, so that the validation and test efforts can become very large without further aids.

The following example shows how you can automatically validate the implementation state machines using protocol state machines for the interfaces.

Example project: robot arm control

A control software for a robot arm serves as an example for the described integration of the open-source tools YSCT and Franca. The robot hardware is a Lynxmotion AL5D kit with an SSC32 control board. Figure 1 shows the robot arm, which consists of five axes and a gripper unit.

Figure 1: robot controller as an example for a embedded software system

For our example, we model the behavior at the application interface of the robot controller; this allows controlling the following functions:

• The gripper can hold and release objects (grab and release operations).
• The arm can move the gripper to a certain cartesian position (operation move).

Accordingly, the static elements of the interface are the methods move, grab, 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 elementary protocol definitions, there are technical restrictions on the permitted processes.

For example, a release operation without a previous grab operation does not make sense. In total, all permitted sequences can be defined by the protocol state machine from figure 2.

Figure 2: The protocol state machine is formulated as part of the interface definition.

A protocol state machine as shown in figure 2 is formulated as part of the interface definition, using Franca IDL. It is important that this only describes the semantics of the interface and not the actual implementation of the control component. The latter is created by another, much more detailed state machine with YAKINDU Statechart Tools (is now itemis CREATE).

Interactive feedback during statechart modeling

An earlier ESE contribution showed how recorded trace data can be automatically validated against one or more protocol state machines^[4]. This increases the quality of the resulting product by detecting and correcting errors in the implementation during testing.

However, it is better to avoid errors already during implementation. This is made possible by the integration of YSCT and Franca: During development, the implementation statecharts are constantly being checked against the protocol state machines of the Franca interfaces involved. The developer is guided by interactive feedback.

Figure 3 of the RobotArm example shows which information is derived from the interface definitions and how it is presented 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.

Figure 3: Interactive feedback in the statechart editor.

The following information is derived from the interface definition:

• In the idle state, the call of the move operation is handled (see transition IdleMoving), but the handling of the grab operation is missing. This is indicated by a warning. The developer is instructed to add another transition (and another state) to handle the grab call.
• The Moving state is reached by a move call. However, the response to the move operation is still outstanding, which is represented by a notification (“Proposed send…”). This instructs the developer to implement the move response.

Further work on the state machine will interactively generate further warnings and information, which will then be processed by more developer actions. At the end, a state machine is created that no longer causes any warnings.

This shows that the specifications of the protocol state machine are taken into account. In the case of complex components with more than one interface, the positive effect is reinforced because the developer can be guided even better by more information.

In the next step, additional suggestions are offered for each of the tool’s warnings or information items, so that the developer can quickly fix or implement the issue directly with a mouse click (so-called quick fixes). This way, the developer can have complete parts of the state machine generated automatically and at the same time resolve existing warnings.

Advantages for embedded practice

Tools for modeling state machines and code generation are used everywhere in embedded projects. In this article, it has been shown how the innovative consideration of interface semantics can guide developers to ensure that the behavior of the created software components conforms to given interfaces.

The developer is automatically notified about potential errors as early as possible and thus disburdened. Implementation errors are detected and corrected at an early stage, thus increasing the quality of the software and speeding up the development process. The expensive elimination of integration errors and errors in general.

The model-based definition of interfaces is necessary and useful, especially for distributed applications. With Franca IDL, interfaces can be formally defined and can then serve as a machine-readable “contract” for the parties and systems involved.

The integration of the Franca IDL and YAKINDU Statechart Tools (is now itemis CREATE) brings 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]http://code.google.com/a/eclipselabs.org/p/franca/

^[3]http://www.genivi.org

^[4] K. Birches: Describing Interfaces Dynamically with Franca. In: Conference Proceedings - Embedded Software Engineering Congress 2013, Sindelfingen, 2013.

^[5] YAKINDU Statechart Tools (is now itemis CREATE)

Information: YAKINDU Statechart Tools Is Now itemis CREATE

^[6] T. Szabo, K. Birken: Model-based on the Internet of Things. In: Conference Proceedings - Embedded Software Engineering Congress 2014, Sindelfingen, 2014.