APES-LESS: Access Point Event Simulation of Legacy Embedded Software Systems

Modeling Legacy C Code

The implementation of a functional software model (with concurrency and timing properties) on a sequential execution platform may exhibit behaviors unaccounted for in the model, due to influences of platform-specific parameters. In particular, dataflow and timing properties of the model may be violated in the implementation as a result of the interplay of execution times and preemptive scheduling. In the embedded systems industry, the established way to validate properties of an implementation is extensive testing, which is done either by simulating the application mapped on a detailed model of the platform (usually using an instruction set simulator) or by using a hardware-in-the loop setup. Both processes are expensive and brittle. Small changes in the assumptions or the setup can result in big changes in the results.

This project, funded by CHESS partner Toyota, is developing an approach for fast simulation of software models mapped to platform abstractions. In particular, the project focuses on legacy automotive control software in C, running on an OSEK-compliant operating system. We refer to a line of source code containing an I/O access (with respect to the owner task) as an access point. In a run of the software, an “access point event” (APE) occurs whenever the code of an access point starts executing. The simulation framework being developed is based on three ingredients: (1) The ability to catch all APEs during an execution, (2) The ability to stop and then resume the execution of a task at any access point, and (3) The ability to determine the (platform-specific) execution time of the portion of code between any two consecutive access points of the same task. We achieve (1) by instrumenting the application code, i.e., inserting a callback to the simulation engine before every access point. Feature (2) is obtained by executing each application task in a separate (Java) thread, which can be paused and then resumed as necessary in the callback function. Objective (3) can be achieved by leveraging existent methods for estimation of execution times.

The simulation engine employs the discrete-event domain in Ptolemy II to process the APEs generated by the application tasks, with timestamps given by the execution times determined at (3) and reported to the engine as parameters of the instrumentation callbacks. Task management operations are provided by a partial OSEK implementation in Ptolemy II.

Above: Model of program with three interrupt service routines and three scheduled tasks. Below: APES-LESS researchers Patricia Derler (Visiting Student Researcher from the University of Salzburg) and Stefan Resmerita (CHESS Postdoc).


©2002-2018 Chess