PARTES: Performance Analysis of Real-Time Embedded Systems*

1
PARTES Performance Analysis of Real-Time
Embedded Systems
Benjamin Gorry Andrew Ireland Peter
King
PARTES 1. For formal
analysis approaches to be adopted by everyday
software engineers we must make them as
accessible as possible by linking them
to the source code level. 2. Testing has been
shown to be a fallible method of proving
correctness of real-time embedded systems
MTTA as a Measure of
Sensitivity Sensitivity analysis is defined in
1 as the study of how variation in the output
of a model (numerical or otherwise) can be
apportioned, qualitatively or quantitatively, to
different sources of variation, and of how the
given approach depends upon the information fed
into it. By changing the parameters of a
performance model we can view the effect the
changes have on the system we are analysing. We
can thus tell how sensitive'' a system is to
certain parameters. A sensitivity measure which
can be used is the MTTA (Mean Time To
Absorption). The MTTA provides a measure of when
an absorbing state will be reached. If an
absorbing state is reached a system timing
constraint has been violated. During sensitivity
analysis, the partial derivatives of any areas of
timing concern which have been identified via
annotations are evaluated. The absolute value of
a derivative indicates the magnitude of the
variation 2. If the value of the partial
derivative increases over time the parameter
becomes more likely to contribute to the system
reaching a state of absorption. However, if the
value of the partial derivative decreases over
time the parameter becomes less likely to
contribute to the system reaching a state of
absorption. By comparing partial derivatives,
with respect to the varying parameters, it is
possibly to identify those most likely to cause a
state of absorption to be reached over a period
of time 2. Since PARTES can focus on potential
areas of concern it can allow the engineer to
focus their testing efforts on the sections of
source code where potential problems may arise.
PARTES is a multi-perspective annotation-driven
approach which extracts functional and timing
information from source code. This information
is then used to develop 1. Promela models for
analysis with SPIN, and 2. CSPL models which
are subjected to sensitivity analysis via
SPNP. The results from analysis can be related
directly back to annotated sections of source
code. The analysis identifies any potentially
problematic timing areas within a system, aiming
to inform testing and reduce the amount of
resources required during testing. The PARTES
framework is illustrated as
FeaVer Test Harness
Promela Model
Extraction Of FeaVer Test Harness
FeaVer
SPIN
1
ANSI-C Code Annotations
4
2
Performance Test Harness
Extraction Of Performance Test Harness
Construct Performance Models
CSPL Models
SPNP
3
Timing Information
Timing Analysis
Real-Time Dining Philosophers As
an example of sensitivity analysis, the real-time
dining philosopher (for a problem of n
philosophers) is presented in Petri net form
below. A philosopher n must adhere to the
correctness constraint when a philosopher has
completed thinking he must have, from this point
in time, obtained access to both his fork and his
neighbours fork and completed eating within x
seconds.
Performance Model Development From
annotated source code a FeaVer test harness is
automatically extracted this is stage 1 of
PARTES. From this test harness a Promela model is
generated which is suitable for analysis using
SPIN.
Stage 2 of PARTES involves extracting
the structure of a performance model into a
performance test harness form. Annotations are
used to identify pertinent sections of source
code and points of timing importance. Using
annotations, a performance test harness is
automatically extracted. This represents program
source code components and areas of timing
importance. Stage 3 of PARTES, timing analysis,
involves executing the real-time source code on
the actual system hardware it is expected to
reside on. The annotations which have been
placed in the program source code to identify
areas of timing importance act as hooks. These
annotations are replaced by additional pieces of
source code to gather timing information for the
relevant sections of source code. The results
from stages 2 and 3 are combined in stage 4 to
produce performance models in CSPL form. Using
the CSPL models which have been developed,
sensitivity analysis is performed. During
analysis, if a potential problem area is
identified, this will indicate that further
investigation should be performed. This
investigation could take the form of traditional
real-time testing approaches.
Correctness Constraint
Startflow
!
Thinking
Neighbours Fork Free
Request Own Fork
Own Fork Free
Request Neighbours Fork
Neighbours Fork Busy
Eating
Own Fork Busy
Release Own Fork
Release Neighbours Fork
If a philosopher fails to complete these tasks
within x seconds he will have violated the
correctness constraint, causing the Petri net
above to reach a state of absorption (!).
Sensitivity analysis of PARTES-developed models
will identify if this problem may occur for a
philosopher n. This allows finite testing
resources to be focused on areas of concern in a
system which could contain a large number of
components (philosophers).
References 1
Andrea Saltelli, Karen Chan and E. Marian Scott.
Sensitivity Analysis. John Wiley Sons
Ltd, 2004. 2 Andrea Bondavalli, Ivan Mura and
Kishor S. Trivedi. Dependability
Modelling and Sensitivity Analysis of Scheduled
Maintenance Systems. In European
Dependable Computing Conference, pages 7-23, 1999.
Funded by an ICASE Studentship GR/PO1786 from
the EPSRC and QinetiQ.