Putting preemptive Time Petri Nets to work in a V-Model SW life cycle

Document Sample
Putting preemptive Time Petri Nets to work in a V-Model SW life cycle Powered By Docstoc
					          Putting preemptive Time Petri Nets to work
                  in a V-Model SW life cycle
                                       Laura Carnevali, Lorenzo Ridi, Enrico Vicario
                                                                                  a
                                 Dipartimento Sistemi e Informatica - Universit` di Firenze
                                   {laura.carnevali, lorenzo.ridi, enrico.vicario}@unifi.it



   Abstract— Preemptive Time Petri Nets (pTPNs) support mod-          supports mathematical modeling and simulation of complex
eling and analysis of concurrent timed SW components running          control systems through block diagrams, which can then
under fixed priority preemptive scheduling. The model is sup-          be translated into C-code for various Real-Time Operating
ported by a well established theory based on symbolic state-space
analysis through Difference Bounds Matrix (DBM) zones, with           Systems (RTOSs), emphasizing performance and signal-flow
specific contributions on compositional modularization, trace          over correctness, and hiding the effects of concurrency and re-
analysis, and efficient over-approximation and clean-up in the         source usage. Charon [7] specifies interacting systems through
management of suspension deriving from preemptive behavior.           modular hybrid state machines, which capture architectural
   In this paper, we devise and implement a framework that            and behavioral aspects and enable formal validation [6]; code
brings the theory to application. To this end, we cast the theory
into an organic tailoring of design, coding, and testing activities   generation experiences are mainly focused on the preserva-
within a V-Model SW life cycle in respect of the principles           tion of properties that might be jeopardized in the mapping
of regulatory standards applied to the construction of safety-        of continuous/concurrent behavior of the model onto a dis-
critical SW components. To implement the toolchain subtended          crete/preemptive target platform [61]. The Giotto Language
by the overall approach into a Model Driven Development               [68] introduces an intermediate layer of abstraction between
(MDD) framework, we complement the theory of state-space-
analysis with methods and techniques supporting semi-formal           the mathematical model and the corresponding generated
specification and automated compilation into pTPN models and           code, defining an embedded software model which takes into
real-time code, measurement-based Execution Time estimation,          account timing and concurrency constraints while neglecting
test-case selection and execution, coverage evaluation.               functionality concerns and platform-dependent choices such as
  Index Terms— Real-time systems, safety-critical SW compo-           scheduling or preemption policies [32]; the actual execution
nents, SW life cycle, V-Model, preemptive Time Petri Nets, sym-       of the generated SW components on a target platform relies
bolic state-space analysis, Model Driven Development, automated       on the use of a Virtual Machine that accounts for scheduling,
model transformation, automated code generation, Execution            preemption, and resource allocation policies.
Time estimation, real-time testing, test-case selection and exe-
cution, coverage analysis.                                               In [41], an on-line controller based on the structure of a
                                                                      discrete time state-space keeps the execution of the system
                                                                      within a range of correct behavior. A similar approach in
                       I. I NTRODUCTION                               continuous time is reported in [18]. In both cases, exhaustive
   In the development of safety-critical SW, formal methods           enumeration of the state-space becomes a precondition for the
may provide a crucial help both in design and in verifica-             implementation stage, and on-line control puts an overhead on
tion activities. This is explicitly encouraged in certification        timing resources. Moreover, the resulting code is closer to the
standards [60], [13], [56] with specific reference to SW with          perspective of the analysis than to usual patterns of real-time
complex behavior deriving from concurrency, synchronization,          programming. In the Uppaal tool [23], the formal nucleus of
and distributed processing, provided that proposed methods are        Timed Automata is exploited to support state-space analysis of
smoothly integrated within a defined and documented SW life            non-preemptive models, test-case selection and execution [8],
cycle [12]. In this context, the adoption of formal methods           [43], and synthesis of a controller that drives the system along
may serve to attain various degrees of rigor, ranging from non        selected behaviors in the state-space [19]. Extension to systems
ambiguous specification to support for manual verification and          running under preemptive scheduling is addressed by Timed
even to automated verification [60]. The integration of formal         Automata with Tasks (TATs) [17] through the composition of
methods along multiple activities of the SW life cycle is also        asynchronous task releases with the analysis technique of [38],
typical in Model Driven Development (MDD), where Domain               under the assumption that the model does not include both
Specific Modeling Languages (DSMLs) enable the formaliza-              nondeterministic Execution Times and dependencies among
tion of system requirements and design, and transformation            release and completion times of tasks [22].
engines support the development of generators of concrete ar-            Preemptive Time Petri Nets (pTPNs) [26], [25] extend
tifacts including code, documentation, complementary models,          Time Petri Nets (TPNs) with resources, representing sus-
and tests [29], [16].                                                 pension in the advancement of clocks. This realizes the so-
   The concepts of the MDD have been practiced in various             called Preemptive ReSume execution policy (PRs) [51] and
tools [67], [7], [68] with different goals in the aspects of model    enables convenient modeling of the usual patterns of real-
formalization, implementation, and verification. Simulink [67]         time concurrency [28], with an expressivity that compares with
                                                                                                                                                                         2



StopWatch Automata [20], Petri Nets with hyper-arcs [55], and       In Sect. VI, we expand concepts reported in [45], [46] adding:
Scheduling-TPNs [50]. The analysis technique of [26] enumer-        an explicit model of failures and defects addressed by the
ates an over-approximation of the state-space that maintains        proposed approach (Sect.V-A); a comprehensive discussion
the efficient encoding of Difference Bounds Matrix (DBM)             about the application of pTPNs to test-case selection, coverage
zones and supports exact identification of feasible timings          analysis, and evaluation of executed tests (Sects.V-B and V-
of selected behaviors through a clean-up algorithm, enabling        C); experimental results on the application of the test-case
efficient verification of reachability properties under timing        execution approach of [47] to the running case study (Sect.V-
constraints and real-time deadlines. The over-approximation is      E). Conclusions are finally drawn in Sect.VI.
applied also in [50], where the state class graph is translated
into a bisimilar Linear Hybrid Automaton [6] with a reduced               II. M APPING P TPN THEORY AND TOOLS ONTO                                              A
number of clocks and analyzed through the HyTech model                               V-M ODEL SW LIFE CYCLE
checker [31]. In [69], symbolic analysis of TPNs with inhibitor
                                                                       Fig.1 reports a scheme of the System Development (SD)
arcs is extended with temporal parameters, supporting design
                                                                    Submodel of the V-Model framework [12]. We illustrate
decisions through the automated derivation of min-max values
                                                                    the process referring to the specific tailoring applied to the
of parameters.
                                                                    development of a real-time controller for an electro-optical
                                                                    system at the FinMeccanica site of Galileo Avionica in Flo-
   In this paper, we propose a comprehensive methodology
                                                                    rence. To avoid disclosure of classified details, concepts are
that brings the theory of pTPNs to concrete application. To
                                                                    transposed into a case of equivalent complexity that addresses
this end, we consolidate and extend preliminary results on
                                                                    an Intelligent Visual Surveillance System (IVSS) performing
code-generation and real-time testing reported in [44], [45],
                                                                    real-time 3D tracking of people moving within a target area.
[46], [47], so as to devise an organic tailoring of the V-
Model SW life cycle [12] following the principles of standards                 SD1                                                        SD9
                                                                       System Requirements                                             Transition             System Level
for safety critical SW [60], [13], [56] and the experience                    Analysis                                                to Utilization

gained in a pilot project of industrial development. To this end,          User Requirements

state-space analysis of [26], [25] is integrated within a full-                                                                     SD8
                                                                                  SD2                                                                   System Level
fledged MDD approach supporting: modeling of real-time SW                     System Design
                                                                                                                                  System
                                                                                                                                Integration

through a semi-formal specification and automated translation
                                                                           System Architecture
into a corresponding pTPN; generation of real-time code
                                                                                    SD3
preserving sequencing and timing properties of the model;                    SW/HW Requirements                                                  Unit Level
                                                                                   Analysis
Execution Time profiling; test-case selection and execution,                                                                SD7-SW
                                                                                                                            SW
oracle verdict, and coverage evaluation. With reference to the                Technical Requirements
                                                                                                                        Integration


framework of [14], this can be regarded as a hybrid approach                           SD4-SW
                                                                                Preliminary Software                                       SW Component Level
combining model-to-model and model-to-text transformations.                            Design


   The paper is organized as follows. In Sect.II, we present                       Software Architecture


the concept of the proposed tailoring, we introduce a running                              SD5-SW
                                                                                     Detailed Software
case study reflecting our industrial experimentation, and we                                Design

define the conceptual model of a task-set extending [44],                                 Software Design
                                                                                                                                SW Module Level


[45], [46], [47] so as to encompass the patterns of real-time                                                  SD6-SW
                                                                                                  SW   Implementation
concurrency encountered in that industrial practice. In Sect.III,
we describe the modeling of task-sets through pTPNs (Sect.III-
A); we illustrate application of the theory reported in [26],       Fig. 1. A scheme of the V-Model life cycle: activities covered by the proposed
                                                                    approach are highlighted in grey.
[25] with reference to the running case study (Sects.III-B and
III-C); and, we show how pTPNs can be derived from a semi-
formal specification based on timelines with semaphores and             System-level User Requirements are determined in SD1
messages, extending [44], [45], [46] with a detailed description    (System Requirements Analysis) and mapped to the Units of
of the translation process, and with an example of application      a System Architecture in SD2 (System Design). SD3 (Soft-
on the running case study (Sects.III-D and III-E). In Sect.IV,      ware/Hardware Requirements Analysis) allocates Technical
we consolidate and extend preliminarily results reported in         Requirements to CSCIs (Computer Software Configuration
[44], [45], [46] about the implementation of pTPN models,           Items) and HCIs (Hardware Configuration Items) that com-
adding new contribution on: generation of code that complies        prise each Unit. In the specific case of study, User Require-
with regulatory standards for safety-critical SW and encom-         ments define parameters of the vision system, such as the
passes message passing communication to include a pattern           frame rate (i.e., 25 frames per second), the image size (i.e.,
frequently encountered in the industrial practice (Sects.IV-        160 x 120 pixels), the compression format (i.e., JPEG), the
A and IV-B); a measurement-based approach to Execution              operating temperature (i.e., from 0◦ C to 40◦ C), the camera
Time estimation, which was systematically applied to the            mass (i.e., up to 1.5 Kg). In SD2, these requirements are
verification of time-frame requirements of low-level modules         allocated to 3 Units, shown in the diagram of Fig.2: a Control
(Sects.IV-C and IV-D); and, an experimental assessment for          Unit (CU), a Pan-Tilt-Zoom (PTZ) Camera, and a Video
the evaluation of the accuracy of measurements (Sect.IV-E).         Processing Unit (VPU). The CU sends images acquired by
                                                                                 3



the PTZ Camera to the VPU, receives the elaborated images
back, and consequently sets values for parameters of image
acquisition (e.g., the levels of pan, tilt, and zoom) and image
processing (e.g., the window size of non-linear filters), sending
them to the PTZ Camera and the VPU, respectively. In SD3,




Fig. 2. Case study: SD2. UML (Unified Modeling Language) component
diagram of the System Architecture in the MARTE (Modeling and Analysis
of Real-Time and Embedded systems) profile [54]: the ProcessingResource
stereotype models an active, protected, executing-type resource allocated
to the execution of schedulable resources; the DeviceResource stereotype
specializes the concept of processing resource to represent an external device
that may be manipulated/invoked by the platform through specific services,
with internal behavior not relevant for the model under consideration; a
CommunicationMedia represents a mean to transport information from one
location to another.


CSCIs and HCIs are specified through more detailed UML-
MARTE component diagrams. As an example, Fig.3 shows
the diagram for the VPU, which is made by 3 CSCIs (i.e.,
Images Acquisition (IA), Basic Features Extraction (BFE), and
Multiple Target Tracking (MTT)) and 4 HCIs (i.e., 3 boards
running the RTAI (Real-Time Application Interface) operating
system [15] and a battery): each CSCI is implemented as a
different real-time task-set and allocated to a different board.
                                                                                  4




Fig. 3. Case study: SD3. UML component diagram of the VPU in the
MARTE profile: the rtUnit stereotype models a real-time application that
owns one or more schedulable resources; a SchedulableResource is an active
resource that performs actions using the processing capacity brought from a
processing resource managed by a scheduler; a Hw Card symbolizes a printed
circuit board typically made by chips and electrical devices; the allocate
stereotype identifies an allocation relation between elements of the application
model and of the execution platform, represented through the stereotypes
ApplicationAllocationEnd and ExecutionPlatformAllocationEnd, respectively;
a Hw PowerSupply is a hardware component supplying the hardware platform
with power; the Hw Bus stereotype represents a particular wired channel with
specific functional properties.
                                                                                                                                     5



  Our proposed methodology comes into play with SD4-                 and Time Requirements, not shown in Fig.1) is supported by
SW (Preliminary Software Design) and SD5-SW (Detailed                pTPN theory and the Oris Tool through state-space analysis,
Software Design), where each CSCI is mapped on a set of              which drive two nested cycles of feedback on design choice
concurrent and interacting tasks according to the following          of temporal parameters until the structure of the dynamic
model derived from the practice of real-time systems [28],           architecture of each task-set proves to be adequate to meet
[36] and described by the UML diagram of Fig.4:                      sequencing and timeliness requirements. Referring again to the
  • A task releases jobs in a recurrent manner with periodic,        RTCA/DO-178B standard [60], state-space analysis verifies
     sporadic, or jittering policy, depending on whether the         the design with the level of rigor of full coverage, which
     release time is deterministic, bounded by a minimum but         is recommended there with explicit reference to the case of
     not a maximum value, or constrained between a minimum           concurrent and timed behavior. When state-explosion prevents
     and a maximum value, respectively.                              complete enumeration and analysis, the rigor degree of the
  • A job is internally structured as a sequence of chunks,          approach downgrades to the level of a method that supports
     each characterized by a non-deterministic Execution Time        manual verification, but it is in any case able to verify a
     constrained between a minimum and a maximum value.              significant part of the state-space, by far beyond the limits
     Chunks representing a computation are also associated           that could be attained through code inspection and testing.
     with an entry-point function for the attachment of func-           SD6-SW (Software Implementation) automatically derives
     tional behavior to the corresponding low-level module.          the implementation of the dynamic architecture of each CSCI
  • Chunks belonging to jobs of different tasks may have             from its semi-formal specification through the Oris Tool [27],
     dependencies (e.g., semaphore synchronization, message          [44]. The structure of the code closely follows readable pat-
     passing communication through a mailbox) and they may           terns of preemptive real-time programming and relies on con-
     require resources (e.g., one or more processors), in which      ventional RTOS primitives. Again, this meets the RTCA/DO-
     case they are associated with a priority level and run          178B [60] recommendation that the introduction of formal
     under static priority preemptive scheduling. Wait and           methods does not change the essential nature of development
     signal semaphore operations are constrained to occur at         processes and, moreover, avoids legacy constraints on tools
     the beginning and at the end of chunks, respectively,           for automated generation, which also has relevance for in-
     but a semaphore may be held across multiple subsequent          dustrial acceptance. SD6-SW also includes implementation of
     chunks of the same task. Receipt and dispatch mailbox           functional code of low-level modules attached to the entry-
     operations are constrained to occur at the beginning and        points. The sub-activity SD6.3-SW (Self Assessment of the
     at the end of chunks, respectively.                             Software Module, not shown in Fig.1) performs unit-testing of
                                                                     low-level modules and it is supported by pTPN theory in the
                                                                     verification of timing requirements through a measurement-
                                                                     based approach to Execution Time profiling.
                                                                        SD7-SW (Software Integration) verifies the integration of
                                                                     low-level modules within each CSCI (SW Component Level
                                                                     in Fig.1) and then the integration of CSCIs within each
                                                                     Unit (Unit Level in Fig.1). The theory of pTPNs impacts
                                                                     on the verification of the integration at the SW Component
                                                                     Level supporting test-case selection, test-case execution, oracle
                                                                     verdict, and coverage evaluation.
                                                                        Out of the scope of impact of the methodology proposed
Fig. 4.   UML class diagram of the conceptual model of a task-set.
                                                                     here, SD8 (System Integration) composes units and performs
                                                                     self-assessment of the system, while SD9 (Transition To
In SD4-SW, the Software Architecture of each CSCI is speci-          Utilization) operates the transition that leads to install the
fied as a task-set with assigned functional low-level modules,        completed system at the intended application site and to put
prescribed release times and deadlines. Minimum inter-release        it into operation.
times and deadlines are directly prescribed by Technical
Requirements, while task periods are design choices. The             III. S PECIFICATION    AND ARCHITECTURAL VERIFICATION
Software Design is completed in SD5-SW with the allocation                             OF REAL - TIME TASK - SETS
of resources and time requirements to SW modules through the            In SD4-SW and SD5-SW, the representation of the dynamic
specification of target processors, task priorities, and allowed      architecture of a CSCI through pTPN models enables schedu-
time-frames of computation chunks. In the usual practice,            lability analysis and sequencing verification through symbolic
the latter design choice is initially based on analogy with          analysis. We recall here the salient aspects of state-space
previous realizations and may require iterations along the           analysis of pTPNs [26], [25] and report on its application in
development process. In the proposed methodology, in both the        the case of study.
stages of SD4-SW and SD5-SW, task-sets are modeled through
a semi-formal specification and automatically translated into          PTPNs [25], [26] extend Petri Nets with the timing se-
pTPN models through the Oris Tool [27], [44]. According              mantics of TPNs [58], [10], [18] and with an additional
to this, the sub-activity SD5.2-SW (Analysis of Resources            mechanism of resource assignment, that makes the progress
                                                                                                                                          6



of timed transitions dependent on the availability of a set            which raises the priority of any locking chunk to the highest
of preemptable resources. As in Petri Nets [65], the model             priority of any chunk that ever uses that lock (i.e., its priority
is a bipartite graph where nodes are places and transitions,           ceiling). Although the protocol does not require the use of
accounting for conditions and events, respectively: a transition       semaphores on single-core systems, we assume semaphore
is enabled iff all its input places contain at least one token; an     synchronization in compliance with the general case of multi-
enabled transition may fire and in this case a token is removed         core systems, which are in fact encompassed in modeling and
from each of its input places and a token is added to each             analysis of the proposed approach. Binary semaphores are
of its output places. As in TPNs [58], [10], each transition is        modeled as places initially marked with 1 token. For instance,
associated with a static firing interval made of an earliest and a      place mux1 models a binary semaphore synchronizing the
latest firing time, and each enabled transition is associated with      first chunk of T sk3 , the first chunk of T sk4 , and the second
a clock evaluating the time elapsed since it was newly enabled:        chunk of T sk5 : wait operations are modeled by the immediate
a transition cannot fire before its clock has reached the static        transitions (i.e., with firing interval equal to [0, 0]) t31 , t42 ,
earliest firing time, neither it can let time pass without firing        and t53 ; signal operations are represented by transitions t32 ,
when its clock has reached the static latest firing time. In            t43 , and t54 , which also account for the completion of the
addition, each transition may request a set of preemptable             three synchronized chunks. According to the priority ceiling
resources, each request being associated with a priority level:        emulation protocol, priorities of tasks T sk4 and T sk5 are
an enabled transition is progressing and advances its clock            raised in the sections where they hold a resource. Priority boost
if no other enabled transition requires any of its resources           operations are modeled in explicit manner by the immediate
with a higher priority level; otherwise, it is suspended and           transitions t41 , t45 , and t52 , which precede semaphore wait
maintains the value of its clock. The expressivity of the              operations. Conversely, the corresponding deboost operations
model compares with StopWatch Automata [20], Petri Nets                are allocated to transitions t43 , t47 , and t54 , which also account
with hyper-arcs [55], and Scheduling-TPNs [50], providing              for the completion of computation chunks. In fact, preemption
a convenient setting for the representation of the patterns of         by a different task within the priority ceiling can occur at the
concurrency and inter-task communication described in the              boost operation but not at deboost, and thus the model does
task-set model of Sect.II.                                             not need to distinguish chunk completion and priority deboost.
                                                                          Mailboxes are modeled by empty places. For instance,
A. Case study: SD4-SW and SD5-SW (formal specification)                 place mbx represents a mailbox used in message passing
   The task-set of the BFE CSCI is made by 5 tasks: T sk1              communication between the first chunk of T sk2 (sender)
performs noise reduction through a median filter; T sk2 ma-             and the unique chunk of T sk1 (receiver): message dispatch
nipulates parameters employed by the noise reduction algo-             operations are modeled by transition t21 , which also accounts
rithm; T sk3 and T sk4 accomplish edge and corner detection,           for the completion of the first chunk of T sk2 ; message receipt
respectively; T sk5 manipulates parameters employed by edge            operations are modeled by the immediate transition t11 .
and corner detection algorithms. In particular, T sk2 sends
values for parameters of the noise reduction algorithm to
T sk1 ; T sk3 , T sk4 , and T sk5 are synchronized in order to
access a shared memory, where T sk3 and T sk4 read values
for parameters of edge and corner detection algorithms written
by T sk5 ; T sk3 and T sk4 are also synchronized in order
to write in a second shared memory the results of edge
and corner detection algorithms, respectively. Fig.5 reports
the pTPN model of the dynamic architecture of the BFE
CSCI: T sk1 , T sk2 , T sk3 and T sk4 are periodic tasks, with
period equal to 40, 40, 80, and 100 time units, respectively;
T sk5 is a sporadic task with minimum inter-release time
equal to 120 time units. Transitions t10 , t20 , t30 , t40 , and t50
model recurrent job releases of T sk1 , T sk2 , T sk3 , T sk4 , and
T sk5 , respectively: they have neither input places nor resource
requests, so as to fire repeatedly with inter-firing times falling
within their respective firing intervals. Job chunks are modeled
by transitions with static firing intervals corresponding to the
min-max range of Execution Time, associated with resource
requests and static priorities (low priority numbers run first).
For instance, transition t12 represents the completion of the
unique chunk of each job of T sk1 , which requires resource
cpu with priority 1 for an Execution Time ranging between 5
and 10 time units.
   In general, we assume that the access to shared resources
is regulated by the priority ceiling emulation protocol [49],
                                                                         7




Fig. 5. Case study: SD4-SW and SD5-SW. The pTPN model of the dynamic
architecture of the BFE CSCI, made by 5 tasks synchronized by 2 binary
semaphores and 1 mailbox.
                                                                                                                                      8



B. Architectural verification through state-space enumeration         model execute along a symbolic run.
of the pTPN model
   In state-space analysis, the state of a pTPN is a pair s =        C. Case study: SD5.2-SW
 M, τ , where M is a marking and τ is a vector of times to              The Oris Tool [27] supports enumeration of the SCG, selec-
fire for enabled transitions. Since τ takes values in a dense         tion of symbolic runs attaining specific sequencing and timing
domain, the state-space of a pTPN is covered using state-            conditions, and tight evaluation of their range of timings. For
classes, each comprised of a pair S = M, D , where M is              the pTPN model of the dynamic architecture of the BFE CSCI,
a marking and D is a firing domain encoded as the space of            the state-space includes 433 reachable markings, covered by
solutions for the set of constraints limiting the times to fire       51079 state-classes. For each task, the analysis of the SCG
of enabled transitions. A reachability relation is established       identifies the paths between release and completion of each
among classes [18], [26]: a class S c is reachable from class        job and the corresponding execution sequences. Specifically,
                                               t0
S p through transition t0 , and we write S p → S c , if and only     tasks T sk1 , T sk2 , T sk3 , T sk4 , and T sk5 have 15295, 10967,
if S c contains all and only the states that are reachable from      21170, 491703, and 156574 symbolic runs, and 497, 113, 935,
some state collected in S p through some feasible firing of t0        25377, and 14044 symbolic execution sequences, respectively.
                                     t0
(i.e., sc ∈ S c ⇔ ∃ sp ∈ S p | sp → sc ). This relation defines       The analysis provides a Worst Case Completion Time (WCCT)
a graph of reachability among classes called state-class-graph       of 12, 14, 30, 58, and 60 time units for T sk1 , T sk2 , T sk3 ,
(SCG) [18], [26].                                                    T sk4 , and T sk5 , respectively, thus verifying that all deadlines
   The reachability relation among classes preserves the EA          are met with minimum laxity of 28, 26, 50, 42, and 60 time
                                                                t0   units, respectively.
condition [70] among states (i.e., ∀ sc ∈ S c , ∃ sp ∈ S p | sp →
sc ) and guarantees that states reached through the same firing          As an example, Fig.6 reports the results of trace analysis on
sequence but with different times are collected in the same          a symbolic run of T sk4 that was selected through state-space
class [10], [11], [18]. A path in the SCG thus assumes the           analysis as a case in which T sk4 may attain its WCCT of
meaning of symbolic run, representing the dense variety of           58 time units. After the initial job release (i.e., the firing of
runs that fire a given set of transitions in a given qualitative      transition t40 , not shown in the schema of Fig.6), task T sk4 is
order with a dense variety of timings between subsequent             suspended until time +30: first, it undergoes preemption by the
firings. A symbolic run is then identified by a sequence of            releases of tasks T sk1 , T sk2 , and T sk3 ; then, it is overtaken
transitions starting from a state-class in the SCG, and it is        by the first chunk of T sk2 , by the unique chunk of T sk1 , and
associated with a completion interval, calculated over the set       by the second chunk of T sk2 ; next, it undergoes preemption
of completion times of the dense variety of runs it represents.      by the second chunk of T sk5 and by the three chunks of
Note that the same sequence of firings may be firable from             T sk3 . Finally, after the completion of its first chunk, T sk4 is
different starting classes. According to this, we call symbolic      overtaken again by the releases of tasks T sk1 and T sk2 , by
execution sequence the finite set of symbolic runs with the           the first chunk of T sk2 , by the unique chunk of T sk1 , and
same sequence of firing but with different starting classes.          by the second chunk of T sk2 . Note that T sk5 is the lowest
   If the model does not include preemptive behavior, i.e.,          priority task, but its priority is raised to the level of T sk3
if it can be represented as a TPN, firing domains can be              before the acquisition of the binary semaphore mux1 .
encoded as DBM zones, which enable efficient derivation and              Trace analysis detects mutual dependencies among transi-
encoding of successor classes in time O(N 2 ) with respect to        tion firing times along the sequence (e.g., transition t44 can fire
the number N of enabled transitions [18], [26]. Moreover, the        in [+47, +56] and transition t47 can fire in [+48, +58], but the
set of timings for the transitions fired along a symbolic run can     assumption that transition t44 fires at time +56 restricts t47 to
also be encoded as a DBM zone, thus providing an effective           fire in [+57, +58]). This may serve to identify the timings that
and compact profile for the range of timings that let the model       let the system run along that sequence and the specific values
run along a given firing sequence [18].                               that yield the WCCT. In so doing, anomalies are detected as
                                                                     the cases where the WCCT along the run requires that some
   When the model includes preemptive behavior, derivation
                                                                     previous firing occurs before its latest feasible value.
of the successor class breaks the structure of DBM zone
and takes the form of a linear convex polyhedron, resulting
in exponential complexity for the derivation of classes and,
more importantly, for their encoding [25], [26], [55], [9]. To
avoid the complexity, [26] replaces classes with their tightest
enclosing DBM zone, thus yielding an over-approximation of
the SCG. For any selected path in the over-approximated SCG,
the exact set of constraints limiting the set of feasible timings
can be recovered, thus supporting clean-up of false behaviors
and derivation of exact tightening durational bounds along
selected critical runs. In particular, the algorithm provides a
tight bound on the maximum time that can be spent along any
symbolic run and provides an encoding of the linear convex
polyhedron enclosing all and only the timings that let the
                                                                                                                                                           9


                                                                                 S9521                                             S12607
                              S5795              S8120                           S9687                                                  S13028
                              S6092                   S8406                           S9873        S10969                                    S13454
                              S6591                        S8711                     S10121        S11322                                    S13907
                                   S7198                   S9030                     S10396             S11729                               S14344
                                   S7741                        S9313                     S10670        S12164                                    S14739
                                0 1 2          10 12 14 16 18                  26 28 30 32           404142           464748         52 54 56 58

         Tsk1: job release t10

         Tsk2: job release t20

         Tsk3: job release t30

Tsk2: 1st chunk completion t21

    Tsk1: message receipt   t11

Tsk1: 1st chunk completion t12

Tsk2: 2nd chunk completion t22

Tsk5: 2nd chunk completion t54

    Tsk3: mux1 acquisition t31

Tsk3: 1st chunk completion t32

Tsk3: 2nd chunk completion t33

    Tsk3: mux2 acquisition t34

Tsk3: 3rd chunk completion t35

       Tsk4: priority boost t41

    Tsk4: mux1 acquisition t42

Tsk4: 1st chunk completion t43

Tsk4: 2nd chunk completion t44

       Tsk4: priority boost t45

    Tsk4: mux2 acquisition t46

Tsk4: 3rd chunk completion t47




                                           progressing transition           suspended transition      firing variability interval      firing time




Fig. 6. Case study: SD5.2-SW. A schema illustrating the range of feasible
                                            t10           t20         t30
timings for the symbolic run ρ = S5605 −→ S5795 −→ S6092 −→ S6591
 t21          t11          t12         t22           t54          t31        t32
−→ S7198 −→ S7741 −→ S8120 −→ S8406 −→ S8711 −→ S9030 −→
         t33          t34          t35           t41            t42          t43
S9313 −→ S9521 −→ S9687 −→ S9873 −→ S10121 −→ S10396 −→
          t20          t10          t21            t11           t12         t22
S10670 −→ S10969 −→ S11322 −→ S11729 −→ S12164 −→ S12607 −→
          t44          t45           t46           t47
S13028 −→ S13454 −→ S13907 −→ S14344 −→ S14739 in the state-space
of the pTPN model of the dynamic architecture of the BFE CSCI. The run
starts with the release of a job of T sk4 (t40 entering S5605 , not shown)
and terminates with its completion (t47 ). Time advances along the horizontal
axis. Transition firings are represented by arrows and positioned at their latest
feasible time, while striped rectangles indicate their allowed range of variation
(e.g., t12 fires twice along the sequence: first within [+10, +12] and then
within [+46, +52]; the two firings are displayed at time +12 and +52,
respectively). Transitions enabling-periods are marked through grey or white
rectangles depending on whether the transition is progressing or suspended,
respectively (e.g., t22 fires twice along the sequence and in both cases is
suspended until the firing of t12 ). Classes entered at transition firings are
listed over the schema (e.g., t12 enters S8120 ); in case of simultaneous firings,
classes are listed from the top in their order (e.g., t10 enters S5795 , which is
left at the firing of t20 to enter S6092 ).
                                                                                                                                                                                10


                                                                                                                      [min, max]
D. Timeline specifications and derivation of pTPNs
                                                                                                   C1 [bcet1 , wcet1 ]                 C2 [bcet2 , wcet2 ]
   In SD4-SW and SD5-SW, the dynamic architecture of a                       (a)                      {cpu} : prio1                      {cpu} : prio2
CSCI is modeled through a semi-formal specification based                               T sk              f1()                                f2()
on the concept of timeline schemas and it is automati-
cally translated into a corresponding pTPN model. Timeline                                                                                                    deadline
schemas restrict the expressivity of pTPNs in a manner that
                                                                                                                     [bcet1 , wcet1 ]                [bcet2 , wcet2 ]
gives explicit representation to the structural concepts of task,                      [min, max]                    {cpu} : prio1                   {cpu} : prio2
job, chunk, hyperperiod, completion-time deadline, and entry-                (b)
point. This enables a direct formalization of the task-set at a
higher level of abstraction which smooths the complexities of                              T sk             C1 in           C1               C2 in           C2
pTPN domain, provides modeling convenience, and facilitates                  Fig. 8. The timeline schema for a task with two chunks (a) and the equivalent
industrial acceptance.                                                       pTPN model (b).
   1) Tasks and jobs: A task is specified by a name T sk and
a release interval [min, max] (see Fig.7a); in the equivalent
pTPN model (see Fig.7b), it is accounted by a transition with                transition is added, while priority deboost is collapsed with
neither input places nor resource requests. A task can also                  the completion of the chunk that releases the semaphore.
be associated with a deadline, which has no counterpart in                                                                [min, max]
the equivalent pTPN model, being part of the descriptional                                 mutex.wait C1 [bcet1 , wcet1 ] mutex.signal          C2 [bcet2 , wcet2 ]
requirements rather than of the operational specification of the                     T sk
                                                                                                          {cpu} : prio1
                                                                                                             f1()
                                                                                                                                                  {cpu} : prio2
                                                                                                                                                      f2()
task-set design. When not specified, the deadline is implicitly               (a)                                                                                  deadline
assumed to be coincident with the minimum inter-release time.
                                                                                                  [0, 0]            [0, 0]                 [bcet1 , wcet1 ]       [bcet2 , wcet2 ]
                                                                                   [min, max] {cpu} : prio1 {cpu} : prio(mutex)         {cpu} : prio(mutex)       {cpu} : prio2

                        [min, max]                 [min, max]
                                                                             (b)      T sk boostin boost waitin       C1 wait    C1 in          C1            C2 in     C2



           T sk                                          T sk                                                                    mutex
                                     deadline
                                                                             Fig. 9. The timeline schema for a task with a semaphore synchronization
                     (a)                              (b)                    (a) and the equivalent pTPN model (b).

Fig. 7. The timeline schema for a task (a) and the transition modeling its      4) Message passing communication through mailboxes:
job releases in the equivalent pTPN model (b).                               Mailbox operations are specified by decorating chunks with a
                                                                             (non-atomic) sequence of mailbox operations, each referred to
   2) Chunks: A chunk is specified by a name C, an execution                  a mailbox name (see Fig.10a). In the equivalent pTPN model
interval [bcet, wcet], a set of resource requests specifying the             (see Fig.10b): each mailbox is translated into a place with no
processors to which the chunk is statically allocated, and the               tokens; a send operation is collapsed with the completion of
level of priority of its scheduling (see Fig.8a). The set of                 the chunk that dispatches the message; a receive operation is
resource requests is empty in case the chunk accounts for a                  accounted by an immediate transition preconditioned by the
waiting state rather than for a computation. In the equivalent               mailbox place.
pTPN model (see Fig.8b), each chunk C is translated into a
transition with an input place Cin . The sequence of chunks                  E. Case study: SD4-SW and SD5-SW (semi-formal specifica-
that form a task is represented by chaining input places of                  tion)
individual chunks with the initial task release transition. Entry-              Fig.11 shows the timeline schema of the dynamic archi-
point functions associated with computation chunks have no                   tecture of the BFE CSCI: entry-point f11 performs noise
counterpart in the pTPN model, but serve in the later stages of              reduction; entry-points f21 and f22 manipulate parameters
coding and testing to attach functional behavior to low-level                of the noise reduction algorithm; entry-points f31 and f41
modules.                                                                     acquire values for parameters of the edge and corner detection
   3) Semaphore synchronization and priority ceiling:                        algorithms, respectively, from a memory shared with task
Semaphore operations are specified by decorating chunks with                  T sk5 ; entry-points f32 and f42 perform edge and corner
circles annotated with a (non-atomic) sequence of semaphore                  detection, respectively, and entry-points f33 and f43 write
operations, each referred to a semaphore name (see Fig.9a).                  the corresponding results on a second shared memory; entry-
In the equivalent pTPN model (see Fig.9b): each semaphore                    point f51 manipulates parameters of the edge and corner
is translated into a place initially marked with 1 token; a                  detection algorithms, and entry-point f52 writes them on the
wait operation is accounted by an immediate transition pre-                  memory shared with tasks T sk3 and T sk4 .
conditioned by the semaphore place; a signal operation is
collapsed with the completion of the chunk that releases                          IV. C ODING AND E XECUTION T IME P ROFILING
the semaphore. Note that the translation process incorporates                  In SD6-SW, the model of the dynamic architecture of
the priority ceiling emulation protocol, and thus a boost                    each CSCI is implemented into code that assumes the fol-
                                                                                                                                        11



                                                                           produced by the engine in the automated translation of timeline
                                                                           schemas into real-time code running on RTAI version 3.6
                                                                           [15]. Translation towards VxWorks 5.5 and 6.2 [71] was also
                                                                           experimented.
(a)
                                                                           A. Implementation of the dynamic architecture of a CSCI on
                                                                           RTAI
                                                                              Fig.12 describes the architecture of the implementation.
                                                                           Salient aspects of the code implementing the dynamic archi-
                                                                           tecture of the BFE CSCI of Fig.3 are reported in and Figs.13
                                                                           and 14 (times expressed in ms).


(b)




Fig. 10. The timeline schema for two tasks synchronized on a mailbox (a)
and the equivalent pTPN model (b).




Fig. 11. Case study: SD4-SW and SD5-SW. The timeline schema of the
dynamic architecture of the BFE CSCI.



lowing responsibilities: release task jobs according to their
policies; invoke semaphore, mailbox, and priority handling
operations; enforce sequenced invocation of entry-points. The
implementation is derived from the timeline model, either
automatically or through manual programming guided by the
model structure. As a salient trait, in both approaches the
resulting code has a readable structure, which follows natural
and readable patterns of concurrent programming and closely
mirrors the structure of the corresponding pTPN model. This
enables a measurement-based approach to Execution Time
profiling [59]. In [44], we described the SW architecture of
an MDD engine supporting agile transformation of models
in the Oris Tool. We report here on the structure of the code
                                                                                 12




Fig. 12.     UML class diagram for the implementation structure of the
dynamic architecture of a CSCI on RTAI in the MARTE profile: the stereotype
SwResource represents a software structural entity provided to the user by the
execution support; SwMutualExclusionResource, MessageComResource, and
SharedDataComResource are subtypes of SwResource describing a resource
commonly used to synchronize access to shared variables, a communication
resource used to exchange messages, and a specific resource used to share
the same area of memory among concurrent resources, respectively; the
stereotyope SwConcurrentResource specializes SwResource to represent an
entity that provides a routine with an executing context; the stereotype
SwSchedulableResource specializes SwConcurrentResource to describe a re-
source that executes concurrently with other resources under the supervision
of a scheduler, modeled by the stereotype Scheduler; the stereotype EntryPoint
represents a routine executed in the context of a SwConcurrentResource; the
stereotype BehavioralFeature represents the routine to be executed.
                                                                                                                                                                                         13


#define MILLISEC 1000000                                                                       [100, 100]
#define ASYNCH_SHM_SIZE 10000
SEM mux1, mux2, asynch_mux5;                                                        mux1.w    C41 [1, 2] mux1.s             C42 [5, 10]        mux2.w   C43 [1, 2]      mux2.s
MBX mbx;
long long* asynch_shared_memory;                                                              {cpu} : 4                     {cpu} : 4                     {cpu} : 4
                                                                            T sk4               f41()                         f42()                         f43()
int init_module(void)
{                                                                                                                                                                                  100
    RT_TASK tsk1, tsk2, tsk3, tsk4, tsk5, asynch_tsk5;                                                            static void tsk4_job(int i) {
    long long start1, start2, start3, start4, start5, time;                                                          while(1) {
                                                                                                                         rt_change_prio(rt_whoami(),3);
    rt_typed_sem_init(&mux1, 1, BIN_SEM);
    rt_typed_sem_init(&mux2, 1, BIN_SEM);
    rt_typed_sem_init(&asynch_mux5, 0, BIN_SEM);                                                                             rt_sem_wait(&mux1);
    rt_typed_mbx_init(&mbx, 1024, PRIO_Q);
    asynch_shared_memory = (long long*) rtai_kmalloc(nam2num(ASYNCH_SHM),                                                    f41();
                                      ASYNCH_SHM_SIZE*sizeof(long long));                                                    rt_sem_signal(&mux1);
                                                                                                                             rt_change_prio(rt_whoami(),4);
    rt_task_init(&tsk1, (void*)tsk1_job, 0, 10000, 1, 0, 0);
    rt_task_init(&tsk2, (void*)tsk2_job, 0, 10000, 2, 0, 0);                                                                 f42();
    rt_task_init(&tsk3, (void*)tsk3_job, 0, 10000, 3, 0, 0);
    rt_task_init(&tsk4, (void*)tsk4_job, 0, 10000, 4, 0, 0);
                                                                                                                             rt_change_prio(rt_whoami(),3);
    rt_task_init(&tsk5, (void*)tsk5_job, 0, 10000, 5, 0, 0);
    rt_task_init(&asynch_tsk5, (void*)asynch_tsk5_job, 0, 2000, 0, 0, 0);
                                                                                                                             rt_sem_wait(&mux2);
    rt_set_periodic_mode();
    start_rt_timer(nano2count(500000));                                                                                      f43();
    time = rt_get_cpu_time_ns();                                                                                             rt_sem_signal(&mux2);
                                                                                                                             rt_change_prio(rt_whoami(),4);
    start1   =   nano2count(time   +   1000*MILLISEC   +   40*MILLISEC);
    start2   =   nano2count(time   +   1000*MILLISEC   +   40*MILLISEC);                                                     rt_task_wait_period();
    start3   =   nano2count(time   +   1000*MILLISEC   +   80*MILLISEC);
                                                                                                                      }
    start4   =   nano2count(time   +   1000*MILLISEC   +   100*MILLISEC);
    start5   =   nano2count(time   +   1000*MILLISEC   +   120*MILLISEC);                                         }

    rt_task_make_periodic(&tsk1, start1, nano2count(40*MILLISEC);
    rt_task_make_periodic(&tsk2, start2, nano2count(40*MILLISEC);
    rt_task_make_periodic(&tsk3, start3, nano2count(80*MILLISEC);
    rt_task_make_periodic(&tsk4, start4, nano2count(100*MILLISEC);
    rt_task_make_periodic(&asynch_tsk5, start5, nano2count(120*MILLISEC);                               [0, 0]                    [0, 0]                     [1, 2]
    rt_task_resume(&tsk5);                                                   [100, 100]               {cpu} : 4                 {cpu} : 3                  {cpu} : 3
    return 1;                                                               T sk4
}
                                                                                t40          p41           t41        p42               t42      p43            t43          p44

Fig. 13.   Case study: SD6-SW. The entry-point of the kernel module                                                                                    mux1
implementing the dynamic architecture of the BFE CSCI.                                                                                                                    [1, 2]
                                                                                            [5, 10]                 [0, 0]                      [0, 0]
                                                                                          {cpu} : 4               {cpu} : 4                   {cpu} : 3                 {cpu} : 3

   1) Implementation of a task-set: The task-set is imple-
                                                                                             t44          p45         t45          p46           t46          p47            t47
mented as a kernel module, loaded into the kernel space
through the entry-point init_module (class Load Module                                                                                                                mux2
in Fig.12) and unloaded at the end of the execution through
the exit-point cleanup_module (class Unload Module                          Fig. 14. Case study: SD6-SW. A fragment of the code implementing the
in Fig.12). The entry-point init_module allocates data                      dynamic architecture of the BFE CSCI, illustrating the correspondence of
                                                                            components of the timeline schema, the code, and the underlying pTPN model
structures that are used in the task-set and the exit-point                 with reference to the implementation of job executions for the periodic task
cleanup_module deletes them (in Fig.13, these include                       T sk4 .
two binary semaphores mux1 and mux2 and a mailbox mbx,
which are explicitly represented in the timeline model of
Fig.11, a binary semaphore named asynch_mux5 and a                          rtai kfree.
shared memory named ASYNCH_SHM, which are instrumental                         Before activating any real-time task, the entry-point
to the implementation of the sporadic task T sk5 ).                         init module starts the timer in periodic mode
   Binary semaphores are implemented as RTAI binary                         with a period of 500 µs through the RTAI primitives
semaphores (class Binary Semaphore in Fig.12), created and                  rt set periodic mode and start rt timer. The
deleted through the primitives rt typed sem init and                        exit-point cleanup module stops the timer through the
rt sem delete, respectively. RTAI binary semaphores re-                     RTAI primitive stop rt timer.
quire explicit priority handling operations to implement the                   2) Implementation of each individual task: For each task
priority ceiling emulation protocol [49]. Actually, RTAI re-                T skx in the timeline model, the entry-point init module
source semaphores natively implement priority inheritance and               creates a real-time task tskx (class Task in Fig.12) through
they could be encompassed in the model by extending the                     the RTAI primitive rt task init, which associates a real-
semantics of pTPNs with marking-dependent priorities with-                  time task with an entry-point function, a priority level, and
out significantly impacting on state-space analysis techniques               a stack. The exit-point cleanup module deletes the real-
[25]; however, the construct was not used to facilitate porta-              time tasks through the RTAI primitive rt task delete. In
bility across different RTOSs. Mailboxes are implemented                    Fig.13, the entry-point function associated with a real-time
as RTAI Mailboxes (class Mailbox in Fig.12), created and                    task tskx is named tskx job and it is responsible for the
deleted through the primitives rt typed mbx init and                        execution of task jobs (class Job in Fig.12).
rt mbx delete, respectively. Shared memory spaces (class                       For each periodic task of the specification (e.g., tasks T sk1 ,
Shared Memory in Fig.12) are created through the RTAI                       T sk2 , T sk3 , and T sk4 in the timeline model of Fig.11),
primitive rtai kmalloc, which allocates in the kernel space                 init_module also defines a start time and a period, through
a chunk of memory to be shared among kernel modules and                     the RTAI primitive rt task make periodic (class Peri-
Linux tasks; they are freed by means of the RTAI primitive                  odic Task in Fig.12). The primitive does not make the real-time
                                                                                                                                   14



task actually recurrent and periodic, but only guarantees that      this yields an executable code that implements the architecture
an invocation of the RTAI primitive rt task wait period             before the construction of any of its functional capabilities.
will suspend the task until the start-time of the next pe-          As usual in UP development, this provides a baseline for
riod. To make the task recurrent, an explicit loop control          incremental integration and testing of low-level modules. In
structure is programmed in the function tskx job that               particular, in SD6.3-SW, this supports separate Execution Time
performs job executions, and each repetition of the loop is         measurement and unit-testing of low-level modules embed-
completed with an invocation of rt task wait period.                ded within their expected operation environment, providing a
The loop body of tskx job implements a single job by                number of relevant advantages: the scaffolding effort needed
performing: invocation of entry-point functions that execute        to support unit testing of each module is largely reduced;
chunk computations (in Fig.14, tsk4 job invokes the entry-          Execution-Time measurement accounts for pipeline and cache
points f41, f42, and f43); wait and signal semaphore                damage induced by the execution in preemptive interrupted
operations (through the RTAI primitives rt sem wait and             mode; unit testing is carried out under the general setting of
rt sem signal, respectively); priority boost and deboost            the specification model rather than under a specific integration
operations according to the priority ceiling emulation protocol     scenario where each module implements only a subset of
(through the RTAI primitive rt change prio, which is                behaviors accepted by the specification. In so doing, the effects
passed the pointer to the current real-time task returned by        of changes in individual modules are confined, thus reducing
the RTAI primitive rt whoami); mailbox send and receive             the complexity in the subsequent activity of integration testing.
operations (by means of the RTAI primitives rt mbx send
and rt mbx receive).
                                                                    C. Execution Time Profiling
   Jittering and sporadic tasks of the specification (e.g., the
sporadic task T sk5 in the timeline model of Fig.11) account           The specification of the task-set allocated to a CSCI includes
for asynchronous jobs that must be scheduled on reaction to         temporal parameters playing different roles that subtend differ-
external stimuli, whose timing is not under control of the task-    ent hurdles in the development process: task periods are design
set but only subject to an expected restriction on the mini-        choices that can be easily enforced in the implementation;
mum and maximum time that can elapse between subsequent             minimum inter-release times and deadlines are derived from
occurrences (class Sporadic Task in Fig.12). In the dynamic         high-level requirements and do not have a direct counterpart in
architecture, they are thus implemented as jobs scheduled on        the implementation; whereas, chunk Execution Times account
reaction to the arrival of a signal. Synchronization is performed   for the time spent by entry-points of the specification and thus
by the way of a semaphore (binary semaphore tsk5 mux in             comprise requirements for low-level SW components, which
Fig.13) which is supposed to receive a signal on each release.      are not easy at all to predict and control.
   Possibly reentrant job releases (which occur whenever the           In the early stages of development, Execution Times are
completion time of a job exceeds the time between subsequent        determined through a tentative approach which mainly re-
releases) are encompassed by the semantics of pTPNs, but they       lies on analogy with previous realizations of comparable
are not supported by the proposed implementation architecture.      functionalities on comparable platforms. As the development
They could be included by employing a separate task for each        process advances and chunk entry-points become available,
job release: the body loop of tskx_job would spawn a real-          actual Best Case Execution Times (BCETs) and Worst Case
time task at each repetition, using a mechanism of multiple         Execution Times (WCETs) must be evaluated to verify the
buffering to associate each real-time task with a different         satisfaction of allocated bounds or to relax/tighten the initial
task handler. This would keep the Execution Time of each            estimates. In general, this can be done either through a static
loop in tskx_job short, thus avoiding the case in which             or through a measurement-based method [59]. Static tools
the invocation of rt_task_make_periodic comes after                 (e.g., Heptane [3], aiT [5], Bound-T [53]) provide lower and
the end of the task release period; however, it would break         upper bounds for Execution Times by combining control-
the recommendation of main regulatory standards (e.g., the          flow analysis of code structure to a model of the hardware
Ravenscar profile [2]) that rule out dynamic task creation.          architecture; measurement-based tools (e.g., RapiTime [24],
Yet, this implementation pattern can be useful in the early         MTime [34], Symta/P [66], [39]) derive estimates through
implementation stage to detect reentrant job releases, until        the conjoint use of analysis of the code architecture and
verification guarantees that all jobs are completed within the       measurements of the Execution Time of sections of code by
end of their task period.                                           means of partial/full hardware tracing support or simulation.
                                                                       In our proposed methodology, precise estimates on Exe-
                                                                    cution Times appear to be more relevant than safe bounds,
B. Executable Architecture of a CSCI                                since inaccurate valuations may jeopardize test-case execution
   The code produced in the implementation of the dynamic           and coverage analysis, and, moreover, verification is in any
architecture of a CSCI concretely realizes the concept of           case supported by the evidence of testing. We thus assume a
Executable Architecture of Unified Process (UP) [57]. To this        measurement-based method which is implemented in a simple
end, chunk computations attached to the entry-points and job        yet effective manner by developing on the formal basis of
releases of asynchronous tasks can be replaced through calls        pTPNs, providing: estimates for BCETs and WCETs; the
to busy-sleep and wait functions providing a scaffolding im-        distribution of observed Execution Times; and, a measure
plementation conforming with expected timing requirements:          of coverage of the state-space. In particular, the approach
                                                                                                                                              15


                                                                          1.6%
is independent of the complexity of the code and of the
corresponding pTPN model. As a salient trait, unlike RapiTime             1.4%

and MTime tools, our method carries out measurements by                   1.2%
letting chunks run in the Executable Architecture of the task-
set, thus accounting for possible dataflow dependencies as well                1%

as for cache and pipeline damages due to the execution in                 0.8%
interrupted mode within a concurrent preemptive context.
   The proposed approach is efficiently implemented through                0.6%

automated code instrumentation that produces a time-stamped               0.4%
log for each event corresponding to each transition in the
pTPN. By construction, these are: job releases, chunk com-                0.2%

pletions, semaphore wait operations, priority boost operations,               0%
and mailbox receive operations. The initial state of an execu-                     5         6        7           8           9          10
                                                                                                           ms
tion is easily identified, either through the implementation of
a reset function, or though a technique of state identification         Fig. 15. Case study: SD6.3-SW. Histogram of observed Execution Times
                                                                       for a data-dependent implementation of entry-point f32 of the BFE CSCI.
[62]; the sequence of time-stamped logs supports reconstruc-
tion of the sequence of states visited during the execution,
enabling evaluation of the sojourn time in each state; in turn,        4.5%

each state also determines which transitions are newly enabled          4%
or persistent and which are progressing or suspended. The
                                                                       3.5%
Execution Time of a chunk is thus evaluated as the time during
which the transition representing the chunk completion has              3%
been progressing since it was newly enabled, which is derived
                                                                       2.5%
off-line as the sum of sojourn times in the visited states where
the transition is progressing:                                          2%

                           Ki,n −1                                     1.5%
              ET (tn ) =
                   i                 ci,k · (τk+1 − τk )        (1)
                                                                        1%
                            k=n

where: tn is the instance of transition ti newly enabled in the
         i
                                                                       0.5%

n-th state visited by the trace; ci,k is either 1 or 0 whether ti is    0%
progressing or suspended in the k-th state visited by the trace;              5          6            7
                                                                                                            ms
                                                                                                                   8              9           10

Ki,n is the index (in the trace) of the state reached through
the firing of tn ; τk is the time of entrance into the k-th state
                i                                                      Fig. 16. Case study: SD6.3-SW. Histogram of observed Execution Times
visited by the trace, i.e., the k-th time-stamp in the log.            for a data-independent implementation of entry-point f32 of the BFE CSCI.
   The responsibility of logging time-stamped events is con-
veniently allocated to the implementation of the dynamic
architecture, supporting reuse and avoiding perturbation of
chunk entry-points. To this end, the implementation archi-             entry-point f32 in Fig.11): the first histogram of observed
tecture is extended to support the observation of the actual           Execution Times has a wider spectrum with various peaks
release time of jobs, using a separate real-time task for each         within [7.771, 8.620] ms, due to a set of input-data depen-
job and assigning highest priority to recurrent real-time tasks        dent alternatives in the implementation of the entry-point;
that release them. Logs are written on an RTAI FIFO queue              whereas, the second histogram has a narrower spectrum within
and transferred on a file by a low-priority task running in the         [7.279, 7.371] ms, thus evidencing a substantial independence
user space, since file operations are not available in the kernel       from input-data. Both implementations accomplish the time-
space and would in any case take time beyond the acceptable            frame requirement of [5, 10] ms.
limits.
                                                                       E. Assessment of the accuracy of measurements
D. Case study: SD6.3-SW                                                   An experimental assessment was carried out to evaluate
   As mentioned throughout Sect.IV-A, the application of the           the perturbation induced by time-stamped logging and the
proposed programming method to the implementation of the               accuracy of measurements. While our proposed methodology
running case study is illustrated in Figs.13 and 14.                   is platform-independent, reported results were obtained on an
   The proposed approach to Execution Time profiling was                Intel Core 2 Quad Q6600 desktop processor.
implemented in the Oris Tool [27] and systematically applied              As a preliminary step, we developed a function
to unit-testing of low-level modules in the development of             busy_sleep that uses the cpu for a controlled Execution
the running case study. Figs.15 and 16 show experimental               Time. Actually, RTAI [15] natively provides the function
results obtained on two different implementations of the               rt_busy_sleep, but this tends to jam the operating
edge detection module of the BFE CSCI (corresponding to                system clock when applied for timings over few hundreds of
                                                                                                                                                   16


         1.1e+08
                                                                                     FIFO queue. Experiments were repeated for several values of
           1e+08
                                                                                     the nominal Execution Time. Fig.18 plots the histogram of
           9e+07
                                                                                     the nominal Execution Time minus the difference between
           8e+07
                                                                                     subsequent logged time-stamps for an Execution Time of
           7e+07
                                                                                     25 ms, reporting also the min-max delay measured with
           6e+07
                                                                                     respect to the nominal value, its mean value and standard
    ns




           5e+07
           4e+07
                                                                                     deviation. Note that the error sums up various factors: the
           3e+07
                                                                                     (variable) overhead due to the acquisition of a time measure
           2e+07
                                                                                     through rt_get_time_ns; the overhead for the log onto
           1e+07
                                                                                     the RTAI FIFO queue; the finite accuracy of busy_sleep
                  0                                                                  in controlling the applied Execution Time.
                      0      5e+06       1e+07    1.5e+07      2e+07     2.5e+07
                                                                                        Observed results show that 99.4% of cases fall
                                             cycles
                                                                                     within [214, 1120] ns, with recurrent error peaks within
Fig. 17. Observed Execution Times of the function busy sleep and their               [3174, 3710] ns occurring in 0.6% of the cases. These peaks
linear approximation.                                                                turn out to have negligible impact on our application context
                                                                                     where the precision of temporal parameters is in the order
   10000
                                                                                     of various hundreds of µs. In any case, this appears to
                 1   = 594 ns σ1 = 119 ns             2   = 3280 ns σ2 = 93 ns       be related to the RTOS implementation rather than to the
                214 ns       1120 ns                         3174 ns    3710 ns      structure of our implementation: according to experimental
     1000                                                                            results obtained by the RTAI development team, error peaks
                                                                                     are interpreted as timing uncertainties due to processor and
                                                                                     bus effects, which are reported to cause jitters on the order of
         100                                                                         1 µs to a few tens of µs on general purpose CPUs running a
                                                                                     hard RTOS [48], [21].

          10                                                                                    V. U NIT AND I NTEGRATION T ESTING
                                                                                        In SD7-SW, conformance of the implementation to design
                                                                                     specification is assured through a combined use of static code
           1
            0         500    1000      1500   2000   2500    3000      3500   4000   inspection and dynamic functional testing: static inspection
                                               ns                                    is used to ascertain that inter-process communication (IPC)
                                                                                     primitives are not invoked within the code of chunk entry-
Fig. 18. Error due to finite accuracy and perturbation in the application of
a controlled Execution Time of 25 ms.
                                                                                     points; under this assumption, conformance is verified through
                                                                                     the exercise of the implementation and the observation of the
                                                                                     times of execution of the events represented in the pTPN
                                                                                     abstraction of the task-set.
microseconds and, concretely, it only controls the Completion
Time (CT). In fact, rt_busy_sleep embeds a while loop
                                                                                     A. Failure and defect model
that exits when the current time overtakes the time at which
the loop was entered plus the specified duration, causing the                            According to [35], we define failures as deviations of a
actual Execution Time to be lower than that duration if a task                       component or system from its expected delivery, service, or
is suspended while executing the loop.                                               result. In the abstraction of the proposed model, these can be:
   A busy_sleep fitting our needs was thus implemented                                   • un-sequenced execution: a run breaking sequencing re-

as a simple deterministic loop, with the usual expedients that                             quirements (e.g., a priority inversion);
avoid compiler optimizations. It was experimentally tuned                               • time-frame violation: a temporal parameter assuming a

on the specific HW platform, assuming that its actual dura-                                 value out of its nominal interval (e.g., untimely job
tion is a linear function with a constant start-up time plus                               release, a computation chunk breaking its expected Exe-
a duration proportional to the number of cycles. Timings                                   cution Time interval);
were measured using the RTAI primitive rt_get_time_ns,                                  • deadline miss: a job breaking its end-to-end timing re-

whose overhead was made negligible through the repetition                                  quirement.
of multiple calls of busy_sleep between subsequent time                                 Still according to [35], defects are defined as flaws in a
measurements. Fig.17 plots the results of the experimentation,                       component or system that can cause failures in performing
showing that a linear approximation effectively fits the relation                     the required function. In the proposed programming model,
between the number of cycles of the deterministic loop and                           these can consist of:
its duration.                                                                           • task programming defect: flaw in concurrency control
   We then experimented to evaluate accuracy and confidence                                 and task interactions due to semaphore operation not
of logged time-stamps. To this end, we repeatedly applied a                                properly combined with priority handling, wrong priority
constant Execution Time through the function busy_sleep,                                   assignment, flawed usage of any IPC mechanism, un-
logging the completion time of each execution on an RTAI                                   sequenced invocation of entry-points;
                                                                                                                                  17



  •  cycle stealing: detraction of computational resources due     is a kind of all-edges with complexity proportional to the
     to tasks intentionally not represented in the specification    number of reachable markings multiplied by the maximum
     as considered not critical for real-time behavior, unex-      number of events occurring within a marking, which in turn is
     pected overheads of the Executable Architecture or the        limited by the number of tasks in the set. As for All-Markings,
     RTOS.                                                         selection is performed on the SCG: for each edge between any
Defects in the sequential code of entry-points are not con-        two markings m1 and m2 , select any class S1 with marking
sidered here as they are more conveniently addressed through       m1 that accepts an event leading to a class S2 with marking
consolidated control-flow and data-flow strategies [63], [64] at     m2 , and include in the test-suite any path starting from a
the level of unit-testing [60].                                    controllable starting point and covering the edge.
                                                                      3) All-Classes and All-Class-Edges: All-Markings and All-
                                                                   Marking-Edges can be refined into All-Classes and All-Class-
B. Test-case selection                                             Edges, requiring coverage of all reachable state-classes and all
   Certification standards explicitly prescribe structural cov-     edges between reachable state-classes, respectively, and adding
erage criteria on the control-flow graph of the code such           the capability to partially account for the difference among
as all-statements and all-decisions, with modified condition        paths whenever this results in different timing restrictions.
decision coverage (MCDC) [37], and more demanding criteria         However, they also largely increase the actual complexity of
can be applied to improve coverage beyond the contractual          coverage (e.g., in the state-space of the task-set of Fig.5, 433
certification needs [63]. While effectively exerting control        markings are refined into 51079 classes).
structures and data-flow dependencies, these criteria provide          4) All-Symbolic-Runs: All-Symbolic-Runs covers every
a limited coverage of the variety of behaviors that may            path in the SCG that starts with a job release and terminates
result from the concurrent and interrupted execution of the        with its completion or deadline miss. This includes All-Class-
dynamic architecture of a task-set. The SCG provides an            Edges and thus also All-Marking-Edges, adding the capability
effective abstraction to account for this variety, that can be     to cover all the possible concurrency states and transitions
interpreted in different perspectives: if the code generator has   within the context of the same job execution, which could
been previously qualified as correct, then the SCG reflects          be relevant to account for possible implicit data-flow and
the actual implementation of the dynamic architecture of the       timeliness dependencies among chunks of the same job.
task-set and can be used to evaluate a structural measure of          If deadlines of synchronous and asynchronous jobs are not
coverage and to drive architectural testing of entry-points and    higher than task periods and minimum inter-release times,
asynchronous task releases; whereas, if the code generator         respectively, task releases and completions are directly rep-
is not qualified or if the code is manually written, then the       resented by specific transitions, while deadline misses are
SCG provides a functional abstraction for test-case selection      identified with tasks releases occurring when a task-job is still
in the verification of conformance of the implementation [33],      pending. The test-suite thus includes every path that starts from
[30] composed by the dynamic architecture along with entry-        any task release and terminates either with the task completion
points and asynchronous task releases. In both perspective,        or with a new release (which indicates a deadline miss). If a
test-cases can be selected as symbolic runs satisfying a specific   deadline is anticipated with respect to the period or minimum
test purpose determined through a model checking technique         inter-release time, deadline misses are not directly represented
[4] or as part of a test suite defined through various criteria     on the SCG, but they can be made observable by extending
to automate test-case selection and/or coverage analysis [8].      the pTPN model with watch transitions as proposed in [11].
We illustrate here the application of few relevant criteria to        The resulting number of test-cases is guaranteed to be
the SCG abstraction, highlighting the trade-off between the        finite under the reasonable assumption that all tasks have a
subtended complexity and the attained type of coverage.            finite deadline and that all tasks require a non-null minimum
   1) All-Markings: All-Markings is satisfied when each             Execution Time. In fact, if the number of paths would be
reachable marking has been visited by at least one test-case.      infinite, there should be a marking m that can be visited an
This covers all the acceptable states of concurrency, i.e., all    infinite number of times between a release and the comple-
the possible combinations of chunks that are concurrently          tion/deadline of some task T . Since the time between release
ready/running/blocked. The criterion is a kind of all-nodes        and completion/deadline is bounded, the Infimum of the time
with complexity proportional to the number of reachable            spent between two subsequent visits of m should be equal to 0.
markings. It is efficiently resolved on the SCG of the pTPN         However, every sequence between two subsequent visits of m
model: for each reachable marking m, select any class Sm           must include an event that advances the state of a task T = T
with marking m and include in the test-suite any path from a       and thus changes the marking in a place pT belonging to T ;
controllable starting point to S.                                  to bring back the marking of pT to its value in m, T must
   2) All-Marking-Edges: All-Marking-Edges is satisfied             complete its execution, restart a new release and execute all
when each edge between any two reachable markings has been         the steps prior to m, which requires a time not lower than the
traversed by at least one test-case. This includes All-Markings    minimum Execution Time of the task which is supposed to be
and guarantees to observe the transitions between subsequent       strictly higher than 0.
states of concurrency (e.g., the events of preemption following       5) All-Symbolic-Executions: All-Symbolic-Executions cov-
to asynchronous releases, chunk completions, semaphore and         ers any feasible events sequence that starts with the release of
mailbox operations, and priority boost/deboost). The criterion     a job and terminates with its completion or deadline-miss. This
                                                                                                                                    18



reduces the complexity of All-Symbolic-Runs by avoiding to           from an initial state s0 =< M0 , F I0 >, the algorithm checks
include multiple runs having the same sequence of events             the feasibility of the first time-stamped event t1 , τ1 by
but different starting class, answering the same rational that       verifying whether t1 can be fired at time τ1 from state s0
suggests to prefer All-Markings and All-Marking-Edges to             and computes the subsequent state s1 ; at the n-th step, the
All-Classes and All-Class-Edges, respectively.                       algorithm checks whether tn can be fired at time τn − τn−1
                                                                     from state sn−1 and computes the resulting state sn . The
                                                                     oracle emits: a failure verdict as soon as any time-stamped
C. Oracle verdict
                                                                     event tn , τn is not accepted by the simulator; a pass verdict
   Time-stamped logs can be analyzed by different oracles            when the run terminates; an inconclusive verdict when the
evaluating conformance of the implementation to the speci-           trace diverges from the test-case sequence with an event that is
fication with different levels of abstraction, each implying a        accepted by the simulator. In so doing, the decision algorithm
different run-time overhead for logging and a different off-line     verifies off-line whether the sequence of time-stamped events
complexity for the decision.                                         produced by an implementation is a subset of the dynamic
   1) End-to-end Oracle: The oracle verifies that end-to-end          behavior that the semantics of the specification model may
task deadlines are met. This requires time-stamped logging           accept, thus distinguishing from the technique reported in [4],
of job releases and completions, and it is implemented in            where an automaton is employed online during the testing
a straightforward manner by comparing the time elapsed               process to collect auxiliary information for coverage evalua-
between release and completion of any job against the deadline       tion, and also from the approach proposed in [9], where an
of its task (without explicit reference to the structure of the      observer is used to evaluate quantitative properties through
pTPN).                                                               state-space enumeration of the specification model augmented
   2) Sequencing Oracle: The oracle verifies that the qual-           with additional places and transitions.
itative ordering of events conforms with design specification            4) Failure detection: All the failures detected by the Se-
(i.e., that there exists at least one timing that makes the logged   quencing Oracle are also detected by the Timing Oracle,
sequence feasible for the specification). This requires logging       while the vice-versa is of course not true: any un-sequenced
of all the events corresponding to a transition in the pTPN          execution is detected by the Sequencing Oracle (and thus by
model (i.e., job releases; chunk completions; semaphore wait,        the Timing Oracle); any time-frame violation is detected by the
priority boost, and mailbox receive operations), avoiding the        Timing Oracle, but not by the Sequencing Oracle unless timing
invocation of a time-measuring primitive of the RTOS (e.g.,          causes the execution to diverge from the expected sequencing.
rt_get_time_ns on RTAI [15]) to associate each logged                Failure detection capability of the End-to-end Oracle is not
event with a time-stamp.                                             comparable with that of the Sequencing Oracle and the Timing
   The decision algorithm consists in verifying whether the          Oracle, since an execution may break the expected sequencing
logged sequence is a symbolic execution sequence in the SCG          and/or an internal timeframe and satisfy its deadline, and vice-
of the pTPN model (i.e., whether the SCG contains a path that        versa. However, if state-space analysis of the specification
follows the sequence of logged events). If the SCG is not finite,     model has verified the absence of symbolic runs breaking any
or if it does not fit in the available memory, then conformance       task deadline, then all the failures observed by the End-to-end
can be tested by reconstructing the fragment of the state-space      Oracle are also observed by the Sequencing Oracle (and thus
composed by the classes visited by the logged sequence. To           by the Timing Oracle).
this end, we assume that the logged sequence begins with                Coverage metrics can be obtained by mapping on the SCG
the start-up of the task-set. This identifies the initial marking,    the sequence of events reproduced by the Timing Oracle or
guarantees that all enabled transitions are newly enabled, and       by the Sequencing Oracle, providing a measure of confidence
thus identifies a reachable state-class that contains the initial     in the absence of residual defects regardless of the number of
state of the logged sequence. Since a state-class is derived         identified failures. The sequence of events reproduced by the
in time O(N 2 ) with respect to the number N of enabled              End-to-end Oracle cannot be mapped on the SCG because the
transitions [18], [26], the entire fragment is computed in time      oracle does not observe all actions.
O(N 2 · L), where L is the length of the logged sequence.
   3) Timing Oracle: The oracle verifies the timed trace in-
clusion relation of [4] (i.e., it verifies that the logged sequence   D. Test-case execution
is a feasible execution for the specification), requiring a time-        Test-case execution determines timed inputs that force the
stamped log for each event corresponding to a transition in          Implementation Under Test (IUT) to execute selected test-
the pTPN model. To guarantee identification of the initial            cases. In [4], [42], test-cases are deterministically timed event
state, we assume that the logged sequence starts from a              sequences, executed under the assumption that all events can
state with a known marking where all enabled transitions are         be observed and that all inputs can be controlled so as to
newly enabled. This can be the initial state reached through a       assume a deterministic value and time. However, periodic
reset function, or any intermediate controllable state reached       and asynchronous release times can be effectively controlled
through an ad-hoc function where no computation is ongoing           through conventional RTOS primitives; whereas, computation
and all times to the next job releases are known.                    times are often impractical to handle. Moreover, timers may
   The decision algorithm does not require state-space analysis      take values within a subset of their nominal range of vari-
and relies on a simulation of the specification model: starting       ation due to the determinization of the implementation with
                                                                                                                                    19



respect to the specification [47], which causes legal behaviors      T sk1 ) releasing the sporadic task T sk5 according to a uniform
of the specification model to be unfeasible in the IUT [1]           distribution within [120, Nmax/106 ] ms, being Nmax the
due to various practical factors: i) assumptions taken in the       maximum representable integer value. Coverage evaluation
specification model cannot exactly correspond to the actual          evidenced that the test-case ρ was never covered. Since ρ
implementation (e.g., synchronous releases may suffer of some       comprises the execution of a job of T sk5 , a second experiment
jitter, semaphore and priority handling operations require a        was performed by activating jobs of T sk5 according to a
non-null Execution Time); ii) temporal parameters of the            uniform distribution within [120, 1000] ms. However, also in
specification are usually associated with a nondeterministic         this case, ρ was never covered.
range of variation, to make the model robust with respect to           In guided testing, the IUT was repeatedly started from
possible variations of the IUT; iii) in a re-engineering process,   a controllable class, releasing T sk5 within [0, 10] ms and
temporal parameters are associated with intervals which over-       starting T sk1 , T sk2 , T sk3 , and T sk4 at the same time within
approximate those of the actual implementation, to circumvent       [4, 11] ms. One thousand executions were performed, which
the difficulty in obtaining precise estimates of Execution           correspond to an overall Execution Time of a little more
Times and release times; iv) specification usually neglects          than 1 minute, and ρ was executed 207 times, evidencing
dependencies among Execution Times of computation chunks,           the effectiveness of the approach with respect to randomized
which are difficult to quantify and definitely unreliable as an       testing.
assumption for schedulability; v) the RTOS may contribute to
the partial determinization of the implementation (e.g., RTAI
                                                                                          VI. C ONCLUSIONS
[15] turns out to assign a fixed order to the releases of periodic
tasks with the same priority at times multiple of their hyper-         In this paper, we drew a comprehensive methodology that
period, insensitively to the order in which tasks are initially     integrates the theory of pTPNs into a tailoring of the V-
started).                                                           Model SW life cycle [12], engineering the steps of design,
    Assumptions on deterministic behavior and observability of      implementation and testing, in compliance with our industrial
the IUT are relaxed in [52], which introduces a timed version       experience and with the principles of process standards for
of the input output conformance relation of [40] and proposes       safety-critical SW [60], [13], [56]. To effectively bring the
a framework for black-box conformance testing of real-time          theory to application, the overall toolchain is implemented in
systems specified as nondeterministic and partially-observable       the Oris Tool [27] according to an MDD approach, supporting
timed automata. The construction of the tester is described         automated derivation of pTPN models from a semi-formal
as a general algorithm, but it is not instantiated with respect     specification, automated compilation of models into real-time
to specific coverage strategies or testing purposes. In [42], the    code running on RTAI [15], measurement-based Execution
timed input output conformance is relativized to explicitly take    Time evaluation, test-case selection and execution, and cov-
environment assumptions into account and an on-the-fly test-         erage evaluation.
ing algorithm is defined to support online test-case generation,        As a salient trait, the proposed methodology has a smooth
test-case execution, and conformance verdict assignment. The        impact on the development life cycle, as explicitly recom-
approach is based on randomized testing and does not provide        mended by the RTCA/DO-178B standard [60]. In fact, the
any coverage evaluation on the variety of timed behaviors. As       main difficulty that the approach brings along is the need of a
a relevant trait, the specification automaton adopted in [52],       specification of the dynamic architecture through pTPNs. This
[42] does not encompass preemptive behavior.                        is largely eased by the use of the semi-formal specification
    The formal approach to test-case execution proposed in          of timelines and by their automated translation into pTPN
[47] nicely exploits state-space enumeration and trace analysis     models and real-time code. Without any additional effort
of a pTPN model of the specification to identify timing              on the part of the developer, the pTPN model provides a
restrictions that can attain path execution. As a characterizing    formal abstraction that supports verification of the dynamic
trait, the technique distinguishes between controllable and         architecture, Execution Time profiling of entry-points, unit and
non-controllable timers, identifying state-classes that can be      integration testing.
selected as starting points for the IUT. The approach was              Explosion of the timed state-space of the pTPN model
integrated in the MDD framework presented in this paper and         may impair exhaustive verification of SW design, but it does
systematically applied to the development of the running case       not prevent the overall development approach: on the one
study.                                                              hand, partial enumeration of the state-space still enables the
                                                                    verification of a significant part of possible behaviors, reaching
                                                                    the level of rigor that can be attained through simulation;
E. Case study: SD7-SW                                               on the other hand, conformance of the implementation with
  We report here experimental results on the application of         respect to the specification is in any case achieved through
the test-case execution approach of [47] to testing of the          testing requested for certification purposes.
implementation of the BFE CSCI, comparing randomized and               The code of the implementation follows in straightfor-
guided testing in the execution of a symbolic run ρ of T sk4        ward manner the structure of the pTPN model. Since each
that may attain its WCCT of 58 ms.                                  component of the pTPN specification accepts a context-free
  In randomized testing, the IUT was run for 1 hour (which          translation, the code can be generated automatically by struc-
corresponds to 90000 releases of the shortest-period task           tural induction, thus providing a full fledged Model Driven
                                                                                                                                                       20



Development method. At the same time, and perhaps more                       [17] E. Fersman and P. Pettersson and W. Yi. Timed Automata with
importantly, the implementation code has a readable structure,                    Asynchronous Processes: Schedulability and Decidability. LNCS, 2280,
                                                                                  2002.
which follows common patterns of concurrent programming,                     [18] E. Vicario. Static Analysis and Dynamic Steering of Time Dependent
leaving the developer full insight and control over the final                      Systems Using Time Petri Nets. IEEE Trans. on SW Eng., 27(1):728–
code and even allowing manual programming guided by the                           748, August 2001.
                                                                             [19] F. Cassez and A. David and E. Fleury and K. G. Larsen and D. Lime.
model structure. This is a crucial point to support industrial                    Efficient On-the-fly Algorithms for the Analysis of Timed Games. In
acceptance and avoids legacy constraints on tools that support                    Proc. Int. Conf. on Concurrency Theory, pages 66–80. Springer-Verlag,
editing and translation of timeline schemas and pTPN mod-                         2005.
els. A clean and readable code structure also prevents erro-                 [20] F. Cassez and K. G. Larsen. The Impressive Power of Stopwatches,
                                                                                  volume 1877. LNCS, August, 2000.
neous understanding of the semantics of pTPNs and timeline                   [21] F. M. Proctor and W. P. Shackleford. Real-time operating system timing
schemas, which in industrial practice may be less understood                      jitter and its impact on motor control. In Peter E. Orban (Ed.), editor,
and trusted than conventional programming languages and                           Proc. of SPIE, Sensors and Controls for Intelligent Manufacturing II,
                                                                                  volume 4563, pages 10–16, Dec. 2001.
operating system primitives.                                                 [22] E. Fersman, P. Krcal, P. Pettersson, and W. Yi. Task automata: Schedula-
                                                                                  bility, decidability and undecidability. Inf. Comput., 205(8):1149–1172,
                                                                                  2007.
                      ACKNOWLEDGEMENTS
                                                                             [23] G. Behrmann and A. David and K. G. Larsen. A Tutorial on U PPAAL.
   This work was supported by the SW-Intiative of the FinMec-                     In 4th Int. School on Formal Methods for the Design of Computer,
                                                                                  Communication, and Software Systems, number 3185 in LNCS, pages
canica Group. We kindly thank Paolo Viliani and Simonetta                         200–236. Springer–Verlag, Sept. 2004.
Orsi of Galileo Avionica for their help in bridging the gap                  [24] G. Bernat and R. I. Davis and N. Merriam and J. Tuffen and A. Gardner
between theory and practice. We also thank Giacomo Bucci                          and M. Bennett and D. Armstrong. Identifying Opportunities for Worst-
for advise and Irene Bicchierai and Dario D’Amico for help                        case Execution Time Reduction in an Avionics System. Ada User
                                                                                  Journal, 28(3):189–194, Sept. 2007.
in the experimentation stage.                                                [25] G. Bucci and A. Fedeli and L. Sassoli and E. Vicario. Modeling Flexible
                                                                                  Real Time Systems with Preemptive Time Petri Nets. In Proc. of the
                                                                                  15th Euromicro Conf. on Real-Time Systems (ECRTS03), July 2003.
                            R EFERENCES                                      [26] G. Bucci and A. Fedeli and L. Sassoli and E. Vicario. Timed State
 [1] A. Bertolino and M. Marr´ . Automatic Generation of Path Covers Based
                              e                                                   Space Analysis of Real Time Preemptive Systems. IEEE Trans. on SW
     on the Control Flow Analysis of Computer Programs. IEEE Trans. on            Eng., 30(2):97–111, Feb. 2004.
     SW Eng., 20(12):885–899, 1994.                                          [27] G. Bucci and L. Carnevali and L. Ridi and E. Vicario. Oris: a Tool
 [2] A. Burns and B. Dobbing and T. Vardanega. Guide on the use of                for Modeling, Verification and Evaluation of Real-Time Systems. Int.
     the ADA Ravenscar profile in high integrity systems. ADA Letters,             Journal of SW Tools for Technology Transfer, 12(5):391 – 403, 2010.
     XXIV(2):1–74, 2004.                                                     [28] G. Buttazzo. Hard Real-Time Computing Systems. Springer, 2005.
 [3] A. Colin and I. Puaut. A modular and retargetable framework for tree-   [29] G. Karsai and J. Sztipanovits and A. Ledeczi and T. Bapty. Model-
     based WCET analysis. In Proc. of the 13th Euromicro Conference on            Integrated Development of Embedded Software. Proc. of the IEEE,
     Real-Time Systems, pages 37–44, Delft, The Netherlands, June 2001.           91:145–164, Jan. 2003.
 [4] A. Hessel and K. Larsen and B. Nielsen and P. Pettersson and A.         [30] H. Muccini and A. Bertolino and P. Inverardi. Using Software Architec-
     Skou. Time-optimal realtime test case generation using UPPAAL. Int.          ture for Code Testing. IEEE Trans. on SW Eng., 30(3):160–171, 2004.
     Workshop on Formal Approaches to Testing of SW (FATES03), 2003.         [31] T. A. Henzinger, P.-H. Ho, and H. Wong-toi. HyTech: A model checker
 [5] AbsInt Angewandte Informatik GmbH. aiT Worst-Case Execution Time             for hybrid systems. SW Tools for Technology Transfer, 1:460–463, 1997.
     Analyzers. www.absint.com/ait.                                          [32] Henzinger, T.A. and Kirsch, C.M. and Sanvido, M.A.A. and Pree, W.
 [6] R. Alur, C. Courcoubetis, N. Halbwachs, T. A. Henzinger, P.-H. Ho,           From control models to real-time code using Giotto. Control Sys.
     X. Nicollin, A. Olivero, J. Sifakis, and S. Yovine. The Algorithmic          Magazine, IEEE, 23(1):50–64, Feb. 2003.
     Analysis of Hybrid Systems. Theor. Comp. Science, 138:3–34, 1995.       [33] I. Stuermer and M. Conrad and H. Doerr and P. Pepper. Systematic
 [7] R. Alur, I. Lee, and O. Sokolsky. Compositional refinement for                Testing of Model-Based Code Generators. IEEE Trans. on SW Eng.,
     hierarchical hybrid systems. In Hybrid Systems: Computation and              33(9):622–634, Sept. 2007.
     Control, LNCS 2034, pages 33–48. Springer–Verlag, 2001.                 [34] I. Wenzel and R. Kirner and B. Rieder and P. Puschner. Measurement-
 [8] Anders Hessel and Paul Pettersson. A Global Algorithm for Model-             Based Timing Analysis. In Int. Symposium on Leveraging Applications
     Based Test Suite Generation. Electronic Notes in Theoretical Computer        of Formal Methods, Verification and Validation, October 2008.
     Science, 190(2):47–59, 2007.
                                                                             [35] International Software Testing Qualifications Board. Standard glossary
 [9] B. Berthomieu and D. Lime and O. H. Roux and F. Vernadat. Reach-
                                                                                  of terms used in Software Testing - v2.0, 2007.
     ability Problems and Abstract State Spaces for Time Petri Nets with
     Stopwatches. LAAS Report 04483, 2004.                                   [36] J. A. Stankovic and M. Spuri and K. Ramamritham and G. C. But-
                                                                                  tazzo. Deadline Scheduling for Real-Time Systems: EDF and Related
[10] B. Berthomieu and M. Diaz. Modeling and Verification of Time
                                                                                  Algorithms. Kluwer Academic Publishers, Norwell, MA, USA, 1998.
     Dependent Systems Using Time Petri Nets. IEEE Trans. on SW Eng.,
     17(3):259–273, March 1991.                                              [37] J. J. Chilenski and S. P. Miller. Applicability of modified condition/de-
[11] B. Berthomieu and M. Menasche. An enumerative Approach for                   cision coverage to software testing. Software Engineering Journal,
     Analyzing Time Petri Nets. In R. E. A. Mason, editor, Information            29(5):193–200, 1994.
     Processing: Proceedings of the IFIP Congress 1983, volume 9, pages      [38] J. McManis and P. Varaiya. Suspension Automata: A Decidable Class
     41–46. Elsevier Science, 1983.                                               of Hybrid Automata. In Proc. of the 6th Int. Conf. on Computer Aided
[12] BWB - Federal Office for Military Technology and Procurement of               Verification, June 1994.
     Germany. V-Model 97, Lifecycle Process Model-Developing Standard        [39] J. Staschulat and R. Ernst and A. Schulze and F. Wolf. Context Sensitive
     for IT Systems of the Federal Republic of Germany. General Directive         Performance Analysis of Automotive Applications. In Designer’s Forum
     No. 250, June 1997.                                                          at Design, Automation and Test in Europe (DATE), March 2005.
[13] CENELEC. EN 50128 - Railway applications: SW for railway control        [40] J. Tretmans. Test Generation with Inputs, Outputs, and Quiescence. In
     and protection systems, 1997.                                                Int. Workshop on Tools and Alg. for the Construction and Analysis of
[14] K. Czarnecki and S. Helsen. Feature-based survey of model transfor-          Sys., volume 1055 of LNCS, pages 127–146. Springer–Verlag, 1996.
     mation approaches. IBM Systems Journal, 45:621–645, July 2006.          [41] K. Altisen and G. Goessler and J. Sifakis. Scheduler Modeling Based
[15] Dept. of Aerospace Engineering - Polytechnic of Milan. RTAI: Real            on the Controller Synthesis Paradigm. Real Time Sys., 23:55–84, 2002.
     Time Application Interface for Linux. https://www.rtai.org.             [42] K. Larsen and M. Mikucionis and B. Nielsen. Online testing of real-time
[16] Douglas C. Schmidt. Model–Driven Engineering. IEEE Computer, pages           systems using uppaal: Status and future work. Perspectives of Model-
     1–2, February 2006.                                                          Based Testing, 2005.
                                                                                                                                                           21



[43] Kim G. Larsen and Marius Mikucionis and Brian Nielsen and Arne              [70] W. Penczek and A. Polrola. Specification and Model Checking of
     Skou. Testing Real-time Embedded Software using UPPAAL-TRON -                    Temporal Properties in Time Petri Nets and Timed Automata. In Proc.
     An Industrial Case Study. In The 5th ACM Int. Conf. on Embedded                  Int. Conf. on Application and Theory of Petri Nets (ICATPN), Bologna,
     SW, September 2005.                                                              Italy, June 2004.
[44] L. Carnevali and D. D’Amico and L. Ridi and E. Vicario. Automatic           [71] Wind River. VxWorks. www.windriver.com/products/vxworks.
     Code Generation from Real-Time Systems Specifications. In Proc. of the
     IEEE/IFIP Int. Symp. on Rapid System Prototyping (RSP), June 2009.
[45] L. Carnevali and L. Grassi and E. Vicario. A Tailored V-Model
     Exploiting the Theory of Preemptive Time Petri Nets. In Proc. of the
     Ada-Europe Int. Conf. on Reliable SW Tech., pages 87–100. Springer-
     Verlag, 2008.
[46] L. Carnevali and L. Sassoli and E. Vicario. Casting preemptive Time
     Petri Nets in the development Life Cycle of Real-Time software. In
     Proc. of the Euromicro Conference on Real-Time Systems, July 2007.
[47] L. Carnevali and L. Sassoli and E. Vicario. Sensitization of symbolic
     runs in real-time testing using the ORIS tool. In Proc. of the IEEE Conf.                            Laura Carnevali received the Bachelor Degree in
     on Emerging Technologies and Factory Automation (ETFA), Sept. 2007.                                  Informatics Engineering, the Doctoral Degree in In-
[48] L. Dozio and P. Mantegazza. General-purpose processors for active                                    formatics Engineering, and the Ph.D. in Informatics,
     vibro-acoustic control: Discussion and experiences. Control Engineering                              Multimedia, and Telecommunications Engineering
     Practice, 15(2):163–176, February 2007.                                                              from the University of Florence in 2004, 2006,
[49] L. Sha and R. Rajkumar and J. P. Lehoczky. Priority Inheritance                                      and 2010, respectively. She is a post-doc fellow at
     Protocols: An Approach to Real-Time Synchronization. IEEE Trans.                                     the Department of Systems and Informatics of the
     Comput., 39(9):1175–1185, 1990.                                                                      University of Florence. Her research is focused on
[50] D. Lime and O. H. Roux. Formal verification of real-time systems with                                 correctness verification and performance evaluation
     preemptive scheduling. Real-Time Syst., 41(2):118–151, 2009.                                         of real-time systems, with specific interest on inte-
[51] M. Ajmone Marsan and G. Balbo and A. Bobbio and G. Chiola and                                        gration of formal methods in the development life
     G. Conte and A. Cumani. The Effect of Execution Policies on the             cycle of real-time software and stochastic characterization of timed models.
     Semantics and Analysis of Stochastic Petri Nets. IEEE Trans. on SW
     Eng., 15(17):832–846, 1989.
[52] M. Krichen and S. Tripakis. Black-Box Conformance Testing for Real–
     Time Systems. Int. SPIN Workshop on Model Checking of SW, 2004.
                        a
[53] N. Holsti and T. L˚ ngbacka and S. Saarinen. BoundT Reference Manual.
     Tidorum Ltd, 2009. www.tidorum.fi/bound-t.
[54] Object Management Group. UML Profile for MARTE: Modeling and
     Analysis of Real-Time Embedded systems v1.0, 2009.
[55] Olivier H. Roux and Didier Lime. Time Petri nets with inhibitor
     hyperarcs: formal semantics and state-space computation. 25th Int. Conf.                             Lorenzo Ridi was born in Firenze in 1983. He
     on Theory and Application of Petri Nets, 3099:371–390, 2004.                                         received the bachelor degree in Informatics Engi-
[56] P. Jordan. IEC 62304 International Standard Edition 1.0 Medical device                               neering in 2006 and the master degree in Informat-
     software - Software life cycle processes. Software for Medical Devices,                              ics Engineering in 2008. He is now a student in
     2006. The Institution of Engineering and Technology Seminar on, 2006.                                the Ph.D. program in Informatics, Multimedia and
[57] P. Kruchten. The Rational Unified Process: an introduction. Addison–                                  Telecommunications Engineering at the University
     Wesley, 2003.                                                                                        of Florence. His research activity mainly focuses on
[58] P. Merlin and D.J. Farber. Recoverability of Communication Protocols.                                formal techniques for the specification, the qualita-
     IEEE Trans. on Comm., 24(9):1036–1043, 1976.                                                         tive verification and the quantitative validation of
[59] R. Wilhelm and J. Engblom and A. Ermedahl and N. Holsti and S.                                       stochastic time-dependent systems, and their inte-
     Thesing and D. Whalley and G. Bernat and C. Ferdinand and R.                                         gration in the development lifecycle of real-time
     Heckmann and T. Mitra and F. Mueller and I. Puaut and P. Puschner           software. He is a member of the Software Technologies Laboratory (STLab)
     and J. Statshulat and P.Stenstroem. Priority Inheritance Protocols: The     of the University of Florence.
     Worst Case Execution-Time problem: Overview of methods and survey
     of tools. ACM Trans. Emb. Comp. Sys., 7(3):1–53, 2008.
[60] Radio Technical Commission for Aeronautics. DO-178B, Software
     Considerations in Airborne Systems and Equipment Certification, 1992.
[61] Rajeev Alur and Franjo Ivancic and Jesung Kim and Insup Lee and
     Oleg Sokolsky. Generating embedded software from hierarchical hybrid
     models. In Languages, Compilers, and Tools for Embedded Systems
     (LCTES03). ACM, pages 171–182. ACM Press, 2003.
[62] S. Fujiwara and G.V. Bochmann and F. Khendek and M. Amalou and A.
     Ghedamsi. Test Selection Based on Finite-State Models. IEEE Trans.
     on SW Eng., 17(2):591–603, 1991.                                                                     Enrico Vicario is a Full Professor of Computer
                                                                                                          Science at the School of Engineering of the Uni-
[63] S. Rapps and E.J.Weyuker. Selecting Software Test Data Using Data
                                                                                                          versity of Florence, where he received the Doctoral
     Flow Information. IEEE Trans. SW Eng., 11(8), 1985.
                                                                                                          Degree in Electronics Engineering and the Ph.D.
[64] S.C. Ntafos. A comparison of some structural testing strategies. IEEE                                in Informatics and Telecommunications Engineer-
     Trans. on SW Eng., 14(6):868–874, 1988.                                                              ing, in 1990 and 1994, respectively. His research
[65] T. Murata. Petri Nets: Properties, Analysis and Applications. Proc. of                               is presently focused on formal methods for model
     the IEEE, 77:541–580, April 1989.                                                                    driven development, correctness verification of real-
                            a
[66] Technische Universit¨ t Braunschweig.       Symta/P.      www.ida.ing.tu-                            time systems, and quantitative evaluation of concur-
     bs.de/forschung/projekte/symtap.                                                                     rent non-Markovian models.
[67] The Mathworks. Simulink. www.mathworks.com/products/simulink.
[68] Thomas A. Henzinger and Benjamin Horowitz and Christoph M. Kirsch.
     Giotto: A time-triggered language for embedded programming. In Proc.
     of the IEEE, pages 84–99. IEEE, 2003.
[69] L.-M. Traonouez, D. Lime, and O. H. Roux. Parametric model-checking
     of stopwatch petri nets. Journal of Universal Computer Science,
     15(17):3273–3304, Dec. 2009.

				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:18
posted:11/4/2011
language:English
pages:21