The APES-LESS project: Access Point Event Simulation of Legacy Embedded Software Systems
Stefan Resmerita, Patricia Derler

Citation
Stefan Resmerita, Patricia Derler. "The APES-LESS project: Access Point Event Simulation of Legacy Embedded Software Systems". Talk or presentation, 16, April, 2009; Presented at the 8th Biennial Ptolemy Miniconference.

Abstract
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 mode of validating 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 in terms of the time, as well as the involved human and logistic resources. We present in this work an approach for fast simulation of software models mapped to platform abstractions. In particular, we focus on legacy automotive control software in C, running on an OSEK 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 proposed simulation framework is based on three main 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.

Electronic downloads

(No downloads are available for this publication.)

Citation formats

• HTML

  Stefan Resmerita, Patricia Derler. <a
  href="http://chess.eecs.berkeley.edu/pubs/554.html"
  ><i>The APES-LESS project: Access Point Event
  Simulation of Legacy Embedded Software
  Systems</i></a>, Talk or presentation,  16,
  April, 2009; Presented at the 8th Biennial Ptolemy
  Miniconference.

• Plain text

  Stefan Resmerita, Patricia Derler. "The APES-LESS
  project: Access Point Event Simulation of Legacy Embedded
  Software Systems". Talk or presentation,  16, April,
  2009; Presented at the 8th Biennial Ptolemy Miniconference.

• BibTeX

  @presentation{ResmeritaDerler09_APESLESSProjectAccessPointEventSimulationOfLegacyEmbedded,
      author = {Stefan Resmerita and Patricia Derler},
      title = {The APES-LESS project: Access Point Event
                Simulation of Legacy Embedded Software Systems},
      day = {16},
      month = {April},
      year = {2009},
      note = {Presented at the 8th Biennial Ptolemy
                Miniconference},
      abstract = {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 mode of validating
                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 in terms of
                the time, as well as the involved human and
                logistic resources. We present in this work an
                approach for fast simulation of software models
                mapped to platform abstractions. In particular, we
                focus on legacy automotive control software in C,
                running on an OSEK 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 proposed simulation
                framework is based on three main 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. },
      URL = {http://chess.eecs.berkeley.edu/pubs/554.html}
  }
  

Posted by Christopher Brooks on 17 Apr 2009.
Groups: ptolemy
For additional information, see the Publications FAQ or contact webmaster at chess eecs berkeley edu.