Citation
Stefan Resmerita. "The APES-LESS project: Access Point Event Simulation of Legacy Embedded Software Systems". Talk or presentation, 17, February, 2009.

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

• APES_CHESS_FEB_17_09.ppt · application/vnd.ms-powerpoint · 601 kbytes

• HTML

  Stefan Resmerita. <a
  href="http://chess.eecs.berkeley.edu/pubs/532.html"
  ><i>The APES-LESS project: Access Point Event
  Simulation of Legacy Embedded Software
  Systems</i></a>, Talk or presentation,  17,
  February, 2009.

• Plain text

  Stefan Resmerita. "The APES-LESS project: Access Point
  Event Simulation of Legacy Embedded Software Systems".
  Talk or presentation,  17, February, 2009.

• BibTeX

  @presentation{Resmerita09_APESLESSProjectAccessPointEventSimulationOfLegacyEmbedded,
      author = {Stefan Resmerita},
      title = {The APES-LESS project: Access Point Event
                Simulation of Legacy Embedded Software Systems},
      day = {17},
      month = {February},
      year = {2009},
      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/532.html}
  }
  

Posted by Hiren Patel on 20 Feb 2009.
Groups: chess
For additional information, see the Publications FAQ or contact webmaster at chess eecs berkeley edu.