Tracing of the event flow in state-based designs - Embedded.com

Tracing of the event flow in state-based designs

Tracing is useful both during development and after the software is released. Here is an explanation of the different parts required for realizing a tracing function and how to implement tracing of state-based designs with minimal effort .

Finite state machines (FSMs) are a well-established tool for the design of embedded systems. Using state machines offers many benefits throughout the whole development process.1 In an FSM-based software architecture the application is designed as individual state machines. Such a system design can be realized with or without an operating system.

In systems with real-time operating systems (RTOSes), the individual state machines typically run in its own task. Tasks are generally constructed as while () loops, and the task body realizes the state machine. After an event is received, the task becomes ready and reads the event, for example, from a message queue. The event is then processed from the state machine and eventually a state change happens. The task then waits for the next event. The code in Listing 1 shows this principle.


Click on image to enlarge.

In a non-RTOS design (foreground/background system design), the difference is that in the background a main loop executes the different state machines one after the other. The state machines return immediately if an eventually available event was processed. One of the advantages of this design is that the issues of task switching and resource-sharing between RTOS tasks is not relevant, as Listing 2 demonstrates.

Click on image to enlarge.

In both designs, the individual state machine can be coded by hand, such as in C. But this is an error-prone task especially for hierarchical designs. In practice, a code generator can fully transform UML state diagrams into source code. This saves a lot of time especially if the model is not complete from the beginning and transitions or entry/do/exit code are to be added later. Additionally, a code generator can perform design checks on the model level before generating the source code.

Testing state-based designs
After the design and coding phase, the behavior of a state machine must be tested. It's recommended that you go through every state transition at least once. Based on the state diagram, a tool can suggest test routes through the state chart ensuring 100% transition coverage.

Debugging an application that is based on generated code from a state diagram is a bit different from debugging handwritten state-machine code. Why? Because you can assume that the generated code is correct. You don't have to worry about all the nitty gritty details of the realization of a state machine, such as handling history, handling hierarchical designs, placement of entry/exit. If the machine does not do what it should do, then most probably the model is not correct. To track down the problem—especially in deeply embedded real-time systems—typically means to add a tracing mechanism that allows you to see which events do fire. Here a code generator can support you again by automatically generate trace code that provides you with information useful for debugging or testing.

The trace data can be used both during the development process and after the software is released either online or in a post mortem. The main advantage of dynamic analysis is that it can run in real-life production conditions. In practice, the information collection does disturb the system execution, but the disturbance may remain extremely small, possibly negligible, in many cases.

The Tracing Book on Wikipedia provides a good overview on the different parts needed to realize a tracing function.2 Based on a small mobile robot, these different parts are exemplary realized and discussed in the following section of the article. Figure 1 shows the hardware setup of the demo system. To log trace messages while the robot is cruising, the connection to the monitoring PC was realized as wireless link.


Click on image to enlarge.

Data providers are the basic mechanisms to access the needed data, for example by adding instructions to trace the execution of some program section. In state-based systems, an important information to trace are the events causing a state transition. A state-machine tool can automatically create the needed trace code. The code in Listing 3 shows trace code that was automatically inserted (lines 6, 9, 23) in the generated cruising algorithm's state machine. Each event is uniquely identified with an unsigned integer so the overhead is minimized. In other words, no strings needs to be copied.

Click on image to enlarge.

The event information must then be written to a trace buffer or sent through the network (for example, a serial link) to a PC; this second aspect is called data collection and transfer. Once the data is available on the PC, it can be either stored in a disk file (for later analysis) or sent through a stream (pipe, socket) to an analysis tool. Data collection and transfer is typically a very system-dependent process because it depends on the available hardware resources (for example, memory to store trace data) and communication links to a PC (such as RS232, CAN, and wireless). Within the trace function, the trace data can be buffered for later download or directly sent out as shown in Listing 4 . On the PC, it's now already possible to watch the event flow in a terminal window.

Click on image to enlarge.

On the PC side, it's useful to have a dedicated event-reception software to decouple the data analysis and visualization tool from the used communication link.

For the mobile robot, a basic event forwarder was used that simply receives trace data from the serial port where the wireless receiver was connected to and forwards it to a UDP port. The data-visualization software always listens to a UDP port and is as wanted independent from the communication link. Larger embedded systems with an own Ethernet link might sent the UDP packets directly to the analysis software.

Based on the trace data, a data analysis tool can measure or identify a number of interesting properties or metrics, for example the number of processed events or the frequency a certain event occurs with.

The final component is the data visualization. It can be used to replay the traced events or display the device state graphically. Figure 2 shows the data-visualization window of SinelaboreRT.3 It displays the robot's state as a state-machine graph generated with the help of the DOT tool.4 This allows to do a visualization of the state-machine independently of the used UML modeling tool. The presently active states are shown in red. Transitions that can be taken are shown in blue (others in grey). The bottom window displays the source code that was executed as a reaction to a state change on the target. It's also possible to interactively send events to the machine (left window) for example, to enter a specific start state. With this final component, the tool chain for implementing tracing is complete now.


Click on image to enlarge.

Go with the tracing flow
In this article, I've shown how useful it is to implement tracing in an embedded system. Tracing is useful both during the development process and after the software is released either online or for a post mortem analysis. A code generator can automatically generate the required trace statements, which saves a lot of work. So the effort for the developer can be reduced to the job of coding the trace function. In a state-based design, tracing of the event flow enables embedded systems developers to follow the system internals with minimal overhead.

Peter Mueller has been an embedded systems developer for nearly 15 years, involved in projects in the area of public transportation, instrumentation, and process automation. During this time, he was involved in several initiatives to improve the embedded software quality. Peter Mueller created and sells SinelaboreRT, a code generator. He can be reached at .

Endnotes:
1. Mueller, Peter. “State charts can provide you with software quality insurance.” Embedded.com, August 19, 2009, www.embedded.com/219400531.
2. Tracing Book. http://lttng.org/tracingwiki/index.php/TracingBook
3. Mueller, Peter. SinelaboreRT. SinelaboreRT generates code from UML state charts. www.sinelabore.com.
4. Graphviz—Graph Visualization Software. www.graphviz.org/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.