*banner
 

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.

Notice: This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright.

©2002-2018 Chess