A Formal Approach for Incremental Modeling and Verification of
Real-Time Distributed Systems1
Yi Deng, JiaCun Wang, and Rakesh Sinha
School of Computer Science
Florida International University
Miami, FL 33199
e-mail: {deng,wangji,sinha)@cs.fiu.edu
Abstraction
An incremental approach for modeling and verification of real-time distributed systems design is
presented. We first present a Real-time Architectural Specification (RAS) model. RAS combines
Time Petri nets (TPN) and Real-Time Computational Tree Logic (RTCTL) to form an integrated
system model to systematically achieve high assurance in design and to improve scalability in
modeling and analysis. Based on RAS, we further present a method to verify timing properties of
a system design. This verification method helps to conquer the complexity of analysis in two
dimensions. Horizontally at each level of design, incremental verification is achieved by
introducing TPN reduction rules that ensure the composition-ability of analysis results on
individual system components. Vertically across design levels, incremental verification is
achieved by systematically decomposing and propagating higher-level constraints to lower-level
designs so that we can safely plug a component or subsystem design into a high-level architecture
without having to re-verify the entire model. A naval command and control (C2) system is used
throughout the paper to demonstrate the concept and usability of our approach.
Keywords: Distributed systems, real-time systems, time Petri nets, real-time computational tree
logic, incremental verification.
1. Introduction
We present an integrated approach for incremental modeling and verification of real-time
distributed systems. The approach expands and integrates existing formal methods, more
specifically TPN [5] and RTCTL [10], in a way that scales better and also helps to achieve high
assurance in design than each formalism used alone.
1
This work was supported by the National Science Foundation under Grant No. CCR_9308473, by Air Force Office of Scientific
Research under Grant No. F49620-96-1-0221, and by NASA under Grand No. NAGW-4080. The views and conclusions contained
herein are those of the authors and should not be interpreted as necessarily representing the official polices or endorsements either
expressed or implied by the above named Agencies.
1
This paper focuses on timing and control in architectural design. Timing and control are
among the most critical aspects of system design. Architectural design – the engineering of a
system into components and their interactions – is a key step of system development critical to
reliability and extensibility of the system. A rigorous approach of modeling and analysis at
architecture level will significantly raise our confidence on the system.
We first present a Real-time Architectural Specification (RAS) model. RAS is built on top of
TPN and RTCTL. The former is a well-known operational formalism for modeling control but is
cumbersome for specifying rules and constraints. The latter is a popular descriptive model best
suited for describing rules and constraints but not control and composition of systems. By
integrating them into a coherent architectural model, RAS offers two desirable features:
First, it establishes a formal basis to systematically maintain a correlation between
requirements and design and to verify or validate the conformance of design to the requirements.
This is a key step towards high-assurance in design. In RAS, a distributed system is modeled as a
multileveled composition of subsystems (using extended TPN) together with the specification of
real-time constraints (using RTCTL) that each of the components and their composition must
satisfy at every design level. The refinement of system architecture in RAS goes hand-in-hand
with decomposition of the constraints, which in turn serve as the basis for analysis and further
refinement. This property helps to enforce that, at any design level, every design decision can be
traced to and meets the time-critical system requirements.
Second, RAS offers better scalability in modeling and analysis: Components interact with
environment only via their communication interface (called ports). Moreover, the constraint
specification deals with only the ports, with internal states of the components encapsulated. This
structural property ensures that, horizontally at each design level, an architectural model can be
constructed and verified compositionally, and vertically across design levels, lower level
(interface and constraint conforming) design can be specified and analyzed incrementally and
safely plugged into their parent level architecture without the need of re-verifying the entire
model.
Based on RAS, we further present a method to verify timing properties of system design that
materializes the above advantages. The verification method manages complexity of analysis in
two dimensions: At each design level, we introduce component-level net reduction rules, which
allow us to reduce arbitrarily complex net structure associated with a verified component into one
of predefined small patterns of constant size, which in turn is used in the verification of other
components. Consequently, system-wide properties are verified by composing the results of
2
analysis on individual components, and thus, the complexity of analysis is proportional to the size
and number of components, rather than the size of the entire model. Across different design
levels, incremental verification is achieved by systematically decomposing and propagating highlevel constraints to lower-level designs in such a way that a verified subsystem architecture can
be safely plugged into its parent-level architecture without having to re-verify the entire model.
Throughout the paper, a naval command and control (C2) system, a typical complex real-time
distributed system, is used to demonstrate our modeling approach and verification technique.
Neither the use of dual languages nor introducing modular structure in formal modeling is a
new idea. None of the previous results, however, combines the complementary features of
operational and descriptive modeling in such a way as in RAS to form an integrated approach of
modeling and analysis. In [13], for example, TRIO logic is coupled with TPN for modeling realtime systems. TRIO++ [13] further extends the notation of TRIO to explore the use of objectoriented concepts and constructs in modeling. The objective here, however, is to axiomatize TPN
so that logical deduction can be used to prove certain properties of real-time systems. Unlike
RAS, TRIO’s coupling with TPN doesn’t address relationship between requirement and design or
deal with issue of incremental modeling and verification. Many efforts in Petri nets community
have been proposed to introduce modular and/or object-based structure into the net
representation. Examples of these efforts include PROTOB [2], OBJSA Nets [4], POT/POP [11],
Cooperative Object Nets [3], OPNets [12], and CmTPN [7]. A common objective of these models
is to improve scalability in modeling and analysis. Among them, only CmTPN has a well-defined
real-time semantics, and supports reachability-based compositional verification. Each of these
studies has more or less helped us to formulate the component-based modular structure of RAS
model.
The rest of the paper is organized as follows: In Section 2, we present an informal overview
of the RAS model. In Section 3, we first describe a naval command and control system and then
illustrate the use of RAS to incrementally construct a design model for this system. In Section 4,
we discuss incremental verification of RAS models -- both at a given design level and across
different design levels, with the former discussed in detail. Section 5 concludes the paper.
Appendix contains a formal description of the RAS model.
2. Overview of RAS Model
An RAS architectural model consists of three basic elements: component specifications
(henceforth referred to as specifications), connections, and architectural constraints (constraints).
3
The specifications describe the real-time behavior and communication interface of the
components or subsystems; the connections specify how the components interact with each other;
and the constraints define real-time system requirements imposed on the components and
connections. All connections are defined using only communication interfaces. In this way, the
architecture can be viewed as a template for system composition, that is, a specific design (or subarchitecture) of a component can be “plugged-into” the place of the corresponding specification
to form an instantiated, recursively defined multi-level architectural model.
The framework of RAS is illustrated at a more detailed level in Figure 1. In the RAS
architectural model, a component (e.g., C) specification is described as a time Petri net (TPN).
The specification has two parts: (1) communication ports (denoted graphically by half circles),
including input ports (e.g., PORT5) and output ports (e.g., PORT6), and (2) a net that describes
the time-dependent, operational behavior of C, that is, it defines the semantics associated with the
ports. The communication between C and its environment is solely through the ports. Such an
interface specification not only promotes information hiding, but more importantly, allows any
sub-architecture that conforms to the component specification to be “plugged into” the place of
the specification to form a multi-leveled, and more detailed system architecture.
C1: For request issued from
A.PORT1, reply must be received at
A.PORT2 within 20 time units.
C2: A flow initiated from B.PORT4
must reach A.PORT7 in 20 – 30
time units.
POR
A
PORT POR T1
T2
7
POR
T6
POR
C
PORB
T3
POR
T4
POR
T5
E
F
T6
C
POR
T5
G
Figure 1 Framework of the RAS model
The components (either specification or sub-architecture) form the building blocks of RAS
architecture, but the main focus in RAS is on the composition of components. A connection
represents a channel of interaction between two components. A connection, modeled by timed
4
transitions connecting the components’ communication ports, defines the direction of message
flow and delay in the channel. A connection may be uni-directional or bi-directional. For
instance, the connection between component A and B describes a request-reply relationship and
is bi-directional, whereas the connection from C to A is uni-directional. The basic communication
model supported by the RAS is asynchronous message (token) passing; that is, the sending
component does not suspend itself if there is a concurrent activity available.
In addition to serving as a component’s communication interface, RAS communication ports
also provide the linkage between the operational design (components and connections) and the
descriptive architectural constraints. Each port represents an atomic proposition, which is
satisfied by an arriving token (an incoming message at the port). These ports constitute the
alphabet (atomic propositions) of the RTCTL formulae that define the constraints. That is, the
architectural constraints are specified without using any internal information (or state) of the
components, which gives us the flexibility to experiment with different component designs under
the same architecture.
Four types of architectural constraints are defined in the RAS: (1) component constraints on a
component define the required, externally observable real-time properties of the component; (2)
connection constraints describe time-dependent properties required on a connection; (3) crossconnection constraints define the required time-critical synchronization among multiconnections; and (4) environmental constraints specify the assumptions made about the
environment of the system or components for the system to function properly.
Examples of connection constraints and cross-connection constraints are shown in Figure 1,
respectively. Formally, connection constraint C1 is described as: Port1 AF20PORT2, and
cross-connection constraint C2 as: PORT4A(G20PORT7  F30PORT7).
These constraints play an important role in system design and are an integral part of an
architectural specification. First, they provide guidance for and help to enhance traceability in
architecture refinement. For instance, any specification or sub-architecture for component B must
satisfy constraints C1. Second, they provide the basis for architecture validation and verification.
Third, the environmental assumptions explicitly define what behavior a component (and the
system) can expect from its environment, and thus eliminates the need to consider those
disallowed events and states in the design. This effectively reduces the state space of a system
architecture, which, in turn, reduces the complexity of design and analysis.
5
3. A Motivating Example
In this section, we first introduce a practical design example—the hierarchical design of a generic
naval Command and Control (C2) system and then use the example to demonstrate our modeling
principle and incremental verification techniques.
A C2 system is a typical real-time distributed system representing complex integration of
multi-techniques and multi-hardware. Delays in execution of any of its functions may degrade the
kill probability, result in inefficient use of battle space, cause too many weapons to be assigned
against the same target, and perhaps allow many targets to leak through a particular defense zone
[1].
A naval command and control battle group (BG) is an example of a C2 system. It consists of
at least one carrier along with several escorting platforms (ships, submarines, and aircraft). The
carriers and their platforms contain a wide variety of sensors and weapon systems, which allow
BG to carry out defensive and offensive missions as prescribed by a controlling authority. The
threat to BG is multi-warfare in character consisting of enemy submarines, surface ships, and
aircrafts. As a consequence, the defense of BG involves anti-submarine warfare (ASW), antisurface warfare (ASUW), and anti-air warfare (AAW). The enemy platforms must be detected
using information from organic BG sensors; they must also be identified, tracked, and engaged
before they launch their offensive weapons against the BG assets.
C2 Center
AAW Center
Air
Radar
ASUW Center
AAW
Fire Unit
ASW Center
ASUW
Fire Unit
Surface
Radar
: intelligence flow
Sonar
Tracking
ASW
Fire Unit
: control flow
Nomenclature: ASUW: Anti-Surface Warfare
ASW: Anti-Submarine Warfare
AAW: Anti-Aircraft Warfare
C2: Command and Control
Figure 2 A generic naval command and control system.
Usually a naval BG operates under a distributed C2 doctrine, the so-called Composite
Warfare Commander (CWC) doctrine which reflects the complexities of naval warfare and
survivability. The sensor admiral in charge of BG under the CWC doctrine can delegate
6
command and control authority and responsibility to three senior warfare commanders: the ASW
commander, the ASUW commander, and the AAW commander who are specialists in their
respective warfare areas. The CWC assigns control of specific platforms (submarines, ships,
aircraft, etc.) to each subordinate warfare commander, a resource-allocation problem, so that each
commander can define the BG assets from the specific threat in his assigned domain.
Due to space limitation, we only consider the ASUW subsystems. (The study of the entire
system with three types of warfare involved is included in [9].) Figure 3(a) shows ASUW
system’s structure. It has three components: (1) C2 Center, which reflects the function of
compositional warfare organization; (2) ASUW Center, which reflects the function of ASUW
organization; and (3) ASUW Fire Unit, which reflects the function of fire unit. The third
component, ASUW Fire Unit, can be further refined into two low level components, Fire Control
and Damage Assessment, as shown in Figure 3(b). Table I, II and III show the meanings of ports
and transitions in Figure 3(a) and (b).
TABEL I LEGENDS OF PORTS IN FIGURE 3(a).
PORT
DESRIPTION
TYPE
ASUC.SI
ASUW center ready to send intelligence to C2 center
output
ASUC.RM
ASUW center received command from C2 center
input
ASUC.SM
ASUW center ready to send command to ASUW fire unit
output
ASUF.R
ASUW fire unit received command from ASUW center
input
ASUF.S
ASUW fire unit ready to send damage assessment results to ASUW center
output
C2C.R
C2 center received messages from centers
input
C2C.S
C2 center ready to send commands to centers
output
C2.SUR
A message from surface radar arrived
input
C2.FSU
ASUW center received damage assessment results
input
C2.ASU
A combat command from ASUW fire unit is sent
output
TABEL II LEGENDS OF TRANSITIONS IN FIGURE 3(a).
TRANSITION
DESCRIPTION
FIRING INTERVAL
T1
ASUW center sends intelligence to C2 center
[1, 1]
T2
C2 center sends command to ASUW center
[1, 1]
T3
ASUW center sends command to ASUW fire unit
[1, 1]
T4
ASUW fire unit sends damage assessment results to ASUW center
[1, 1]
7
C2 CENTER
(C2C)
C2C.S
C2C.R
T2
T1
ASUC.RM
ASUC.SI
ASUF.R
ASUW
CENTER
(ASUC)
C2.SUR
FIRE
CONTROL
(FC)
C2.ASU
FC.SM
C2.FSU
ASUC.SM
T20
T3
T4
ASUF.R
DA.RM1
DA.RM3
ASUF.S
ASUW
FIRE UNIT
(ASUF)
ASUF.S
C2.ASU
Figure 3 (a) Structure of the ASUW system.
DAMAGE
ASSESSMENT
(DA)
(b) Refinement of ASUW Fire Unit.
TABEL III LEGENDS OF PORTS AND TRANSITIONS IN FIGURE 3(b).
PORT
DESCRIPTION
TYPE
FC.SM
Ready to send command for collecting firing results
output
DA.RM1,2,3
Waiting for damage assessment
input
TRANSITION
T20
DESCRIPTION
FIRING INTERVAL
ASUW fire unit sends command of collecting firing results
[1, 2]
The first concern of the designer and the user of a C2 system should be the reaction time of
the system. Consequently, we add a cross-connection constraint
C2.SUR AF40C2.ASU,
which states that a fire command must be issued within 40 time units of receiving an enemy
intelligence message. Since a C2 system is a closed-loop system, a constraint reflecting the time
limitation for the feedback of damage assessment results should be included. Thus we have the
component constraint:
C2.SUR AF45C2.FSU,
Moreover, because the bottleneck for information processing is usually located in component C2
Center the component is always asked to respond as soon as possible. This is captured by the
connection constraint:
ASUC.SI AF18ASUC.RM,
8
We also have an environmental constraint about the inter-arrival time of radar data:
C2.SUR AG50C2.SUR,
which states that the time interval between two successive radar messages entering the system is
at least 50 units. Figure 4, 5, and 6 show the internal TPN representation of the three components.
(The description of nodes of TPN models is given in [9].)
We need to verify whether the formal operational model is consistent with the first three
constraints. It is clear that constructing the reachability graph of the entire TPN model is not a
practical idea because of the state explosion problem. The next section presents an incremental
verification technique that takes advantages of the structural features of RAS to verify the design
against the above timing constraints. Our method works by breaking the task of verifying a
complex design into verification of several simpler TPNs.
ASUC.SI
p1
t2
p3
t5
t4
t1
t6
t7
C2.SUR
ASUC.SM
C2C.S
C2C.R
p2
p6
p4
t3
Static firing time intervals:
t5: [2, 3], t6: [1, 2], t7: [ 4, 6].
Static firing time intervals:
t1: [1, 2], t2: [3, 5], t3: [3, 5], t4: [5, 6].
Figure 4. The internal representation of C2 Center.
ASUF.R
p5
ASUC.RM
t8
p8
Figure 5. The internal representation of ASUW Center.
t9
C2.ASU
ASUF.S
t10
p9
Static firing time intervals:
t8: [4, 6], t9: [1, 2], t10: [5, 7]
Figure 6. The internal representation for ASUW Fire Unit.
4. An Incremental Verification Method for Timing Analysis
The goal of verification is to ensure that the behavior of the model is what was intended. In a
hierarchical design, verification not only applies to component-connections in each given design
level, but also to models between any two different design levels. The former verifies whether the
9
operational model is consistent with the specifications or constraints, while the latter verifies
whether the specifications of lower level are consistent with those of higher level.
In this section, we present an incremental technique for timing verification of RAS design
models. Our method works by verifying designs independently at each level – starting from the
very top level. Within a given level, we analyze one component at a time. The analysis consists of
verifying all constraints related to this component and then reducing it to a simpler TPN of
constant size, which, in turn, is used to verify subsequent components. We need to address
several issues:
(1) As design gets refined across levels, how can we ensure that sub-architecture can be safely
plugged into the high-level architecture without having to re-verify the entire model? This is
addressed in Section 4.3.
(2) How can we reduce a component into a simpler TPN while still preserving its externally
observable time-critical properties? We give a set of component-level reduction rules in
Section 4.1.
(3) Within a given level, we can’t verify a component until all other components it depends on
have already been verified. So we need to choose the right order in which components are
verified. In section 4.1, we outline a method for choosing the right order in which
components can be verified incrementally.
We first present the incremental verification algorithm for a given level of design.
4.1 Incremental Verification at a Given Design Level
The following definitions are needed for the description of our verification algorithm.
Definition 1 A pair of input port PORT_in and output port PORT_out in a given component are
said to form a port pair if there exists a directed path between them.
Definition 2 A port pair <PORT_in, PORT_out> is a calling pair if a reply token from the
environment is expected at PORT_in whenever a token is sent to some other component from
PORT_out.
Definition 3 A port pair <PORT_in, PORT_out> is a passing pair if a token is expected to be
sent to the environment from PORT_out whenever a token from some other component is
received at PORT_in,.
10
From the three definitions, we know that a port pair is either a calling pair or a passing pair.
In Figure 5, <ASUC.SI, ASUC.RM> and <ASUC.SM, C2.FSU> are calling pairs, whereas
<C2.SUR, ASUC.SI> is a passing pair.
The basic idea of the algorithm is to close passing pairs by connecting them with timed
transitions, thereby replacing each component by a very simple net of constant size that preserves
all external observable time-critical properties of the component being replaced. In Figure 7, we
introduce five component-level reduction rules to support such closure. The reduction rules
introduced here work at a much coarse level than the reduction rules given in [14], which work at
individual transition level. Consequently, we need fewer applications of our rules to reduce the
size of the model being analyzed. In these rules, the static firing time interval SIM_(A, B) of
transition T_(A, B) is the time delay interval of the message transfer between PORTA being
marked and PORTB being marked, and SIM_((A, B), C) of T_((A, B), C) is the time delay
interval of the message transfer between both PORTA and PORTB being marked and PORTC
being marked, and so on. In our reduction rules, we make the same assumption as Sloan and Buy
[14]:
Assumption 1. The underlying (untimed) net corresponding to the TPN of a RAS model is safe.
This assumption implies that, for a given passing pair in a component, a token can be received
from the input port only after the previous input token has exited from the output port. As
indicated in [14], this assumption holds for many systems.
Of course, we need to make sure that these reduction rules preserve timing properties of nets.
Let L(N) be the set of all firing schedules of TPN N. For any set of transitions U, let L(N)|U be the
set of all schedules of N where transitions not from U have been deleted from each of schedules.
Definition 4 [14] Let NR be the result of applying some reduction rule to a time Petri net N, and
let U be any set of transitions of N which are left completely unmodified by this transformation.
Then we say that a reduction rule is equivalence preserving if L(N)|U=L(NR)|U.
Theorem Reduction rules 1 - 5 are equivalence preserving. (A proof is included in [9].)
11
PORTA
PORTA
PORTA
PORTB
PORTA
T_(A,B)
PORTC
PORTC
PORTB
PORTB
T_((A,B),C)
PORTB
( PORTA and PORTB have same post-set)
Figure 7(a) Illustration for Rule 1.
Figure 7(b) Illustration for Rule 2.
PORTA’
T_(A, B)
PORTB
PORTB
PORTA
competitive
PORTB
concurrent
PORTC
PORTA
PORTC
PORTC
PORTC
PORTA’’
T_(A, C)
T_(A,C)
( Each of PORTB and PORTC will receive
a token for every token arriving at PORTA.)
(The token arriving in PORTA will either reach PORTB or PORTC)
Figure 7(c) Illustration of Rule 3.
Figure 7(d) Illustration for Rule 4.
PORTA
PORTA
T_(A,B)
PORTB
PORTA
PORTC
PORTC
T_((A,B), (C,D))
PORTB
PORTD
PORTB
PORTD
(PORTA and PORTB have same post-set.
PORTC and PORTD have same pre-set.)
Figure 7(e) Illustration for Rule 5.
Because of dependencies among components we need to be careful in choosing the order in
which components are considered. E.g., if a component has a calling pair, it needs to interact with
other components. We say that component A depends on component B, denoted by AB, if after
A sends a token from the output port of its calling pair, it can not receive a token at the input port
if we remove B away from the system. If AB then B has to be analyzed before A. If AB and
BC, then C has to be analyzed before B, which, in turn, has to be analyzed before A. We can
build a dependency graph such that there is a directed edge from component A to component B
iff A depends on B. If this dependency graph contains a cycle, then we can’t pick an order, so we
assume that
Assumption 2 The dependency graph does not contain a cycle.
In which case we can (linearly) order the component (e.g., by performing a topological sort
[8]) in such a way that all dependency edges go from a component higher in this order to a
component lower in the order. In other words, the first component does not depend on any other
components so it can be verified and reduced to a simple TPN. The second component depends
only on the first one, which has already been reduced, and so on. Suppose that there are m
12
components, which are linked together by inter-related connection structures to form the system
or subsystem. Now we can describe our incremental verification method as follows:
Initialization
(1) List calling pairs, and passing pairs for each component;
(2) For each port pair, list the reduction rule that can be applied to this pair; and
(3) Build the dependency graph on components and perform a topological sort. If the sorted
order is CP1, CP2, , CPm, then we know that  i>j, CPjCPi is not possible.
Procedure for incremental verification
for CP1 to CPm
verify connection constraints;
if violation found
quit the algorithm, report the violation of constraints and redesign the system or
subsystem;
endif
verify all cross-connection constraints;
if violation found
quit the algorithm, report the violation of constraints and redesign the system or
subsystem;
endif
calculate time delay interval of the message transfer between each passing pair of the
component;
verify component constraints;
if violation found
quit the algorithm, report the violation of constraints and redesign the system or
subsystem;
endif
if all constrains of the first three types are verified
the algorithm returns successfully;
else
close passing pairs by applying reduction rules 1-5;
endif
endfor
4.2 Verification of the C2 System
We now illustrate the incremental verification on the C2 system given in section 3. It is easy to
see that the second constraint (C2.SURAF45C2.FSU) and the environmental constraint
(C2.SUR AG50C2.SUR) ensure that the C2 system satisfies assumption 1. Therefore, our
verification method is applicable to this system. (Due to the space limitation, we skip some steps
that are not crucial for understanding the algorithm.) The C2 system consists of three
components: C2 Center, ASUW Center and ASUW Fire Unit. There are two dependency edges:
ASUW CenterC2 Center, and ASUW CenterASUW Fire Unit, so we can order the three
components as C2 Center, ASUW Fire Unit, and ASUW Center. Applying reduction rule 1 to
13
component C2 Center results in Figure 8(a), and applying reduction rule 4 to component ASUW
Fire Unit results in Figure 8(b). Applying simple reachability analysis [5,6], we conclude
SIM_(C2C.R, C2C.S)=[9, 13],
SIM_(ASUF.R, C2.AS)=[5, 8], and
SIM_(ASUF.R, ASSF.S)=[10, 15].
This gives
SIM_(ASUF.SI, ASSU.RM)=[11, 15].
So the constraint ASUC.SIAF18ASUC.RM is verified. Next, we consider component ASUW
Center. Figure 8(c) shows its interaction with the other two components, which have been
simplified. Based on Figure 8(c), we obtain
SIM_(C2.SUR, C2.ASU)=[24, 35], and
SIM_(C2.SUR, C2.FSU)=[30, 43].
Based on these values, we have verified C2.SURAF40C2.ASU and C2.SURAF45C2.FSU.
Therefore, all three constraints have been verified.
T_(C2C.R, C2C.S)
T_(C2C.R, C2C.S)
C2C.R
C2C.S
C2C.R
C2C.S
T2
T1
(a)
ASUC.SI
ASUC.RM
ASUU.R’
T_(ASUU.R, C2.ASU)
C2.FSU
ASUF.R’
t5
C2.SAU
p5
t6
p7
t7
ASUC.SM
T_(ASUU.R, ASUU.S)
C2.SUR
T23
T_(ASUF.R, C2.ASU)
T23
ASUU.R’’
T_(ASUF.R, ASUF.S)
ASUF.S
p6
ASUF.R’’
ASUF.S
C2.FSU
(b)
T23
6
(c)
Figure 8 (a) Reduction of component C2 Center.
(b) Reduction of component ASUW Fire Unit.
(c) The simple but equivalent model of the system.
4.3 Constraints Decomposition and Incremental Verification across Design Levels
In the last subsection we showed that we could use the compositional algorithm to verify the
design at any given level. In this section, we briefly describe an incremental technique that
ensures that, after each refinement step, we can safely plug the sub-architecture into its parentlevel architecture without having to re-verify the entire model. For more details, refer to [9]. This
technique consists of three basic elements: 1) We automatically derive constraints for the lowerlevel design that is consistent with the higher-level constraints. 2) The lower-level design is
14
verified using the technique discussed in the last section. 3) the sub-architecture is plugged into
the parent-level architecture to form a more detailed architectural model.
In fact, when we refine an RAS component into a sub-architecture, the RAS model mandates
that it inherit all the ports from the high-level component to ensure interface consistency. During
the verification of the high-level design, we compute time delays for certain port-pairs.
Correctness of the high-level design is contingent on the values of these time delays. So for the
lower level design, we add these delays as constraints that must be satisfied. As long as these
constraints are satisfied, we can ensure that the low-level designs is consistent with the high-level
design.
Let’s take the analysis of the C2 system as an example.
In the last subsection, we finished the verification of its
high-level design. Figure 7 shows the internal representation
p11
t12
p14
p12
t13
p15
p13
t14
p16
t11
ASUU.R
t15
C2.AS
of low-level design for ASUW Fire Unit. From this figure
we know ports ASUF.R, C2.AS, and ASUF.S are inherited
ASUU.SM
from Figure 6, the high-level design model for ASUW Fire
T20
ASUU.RM1
Unit (The legends of nodes in Figure 9 is included in [9]).
During the high-level verification, we concluded that
SIM_(ASUF.R,
C2.AS)=[5,
8],
and
SIM_(ASUF.R,
ASSU.S)=[10, 15], which enabled us to prove the
t19
ASUU.S
p17
t16
p18
t17
p19
ASUU.RM3
ASUU.RM2
t18
constraints for the high-level design. Hence, for the lowlevel model we have the following two constraints:
Figure 9. Refinement of Figure 6.
(1) ASUF.RA(G5 C2.AS  F8 C2.AS), and
(2) ASUF.RA(G10AASU.S  F15 AASU.S).
Then we can use the compositional verification algorithm from the previous subsection to verify
the design in Figure 7 as long as the static firing time interval for each transition is given.
5. CONCLUSION
We have presented an RAS-based incremental approach for architectural modeling and
verification of real-time distributed systems. The contribution of this paper is twofold: First, it
provides a systematic way to link real-time system constraints to the process of formal modeling
and analysis to ensure that the constraints are met at any given design level. Second, our approach
is scalable in both modeling and analysis. We have presented an incremental verification
technique for timing analysis based on constraint propagation and component-level Petri net
15
reduction. This technique significantly reduces the complexity of analysis by supporting both
horizontal and vertical composition-ability. These two features together ensure that a complex
system model can be built, changed and verified progressively both at a given design level and
across different design levels.
A restriction of our verification method is that, as in [14], it assumes that the underlying
(untimed) Petri net is safe. We are exploring alternative analysis techniques that may allow us to
remove this restriction. A potential solution to this problem is to use compositional model
checking.
Reference:
[1] M. Athans. Command and control (C2) theory: A challenge to control science.
IEEE
Transactions on Automatic Control, AC-32 (4):286-293, 1987.
[2] M. Baldasssri, G. Bruno. Protob: An object methodology for developing discrete event
dynamic system. High-level Petri Nets: Theory and Application, 1991.
[3] R. Bastide, C. Blanc, P. palanque. Cooperative objects: A concurrent Petri-net based,
objected-oriented language. Procedings of the IEEE International Conference on System,
Man and Cybernetics, 3:286-291, 1993.
[4] E. Battiston, F. Cindio, G. Mauri. Objsa nets: A class of high-level nets having objects as
domains. Advances in Petri Nets, LNCS 340, 1988.
[5] B. Berthomieu, M. Menasche. An enumerative approach for analyzing time Petri nets.
Procedings of IFIP Congress, Sept. 1983.
[6] B. Berthomieu, M. Diaz. Modeling and verification of time dependent systems using time
Petri nets. IEEE Transactions on Software Engineering, 17(3), 1991.
[7] G. Bucci, E. Member. Compositional validation of time-critical systems using communicating
time Petri nets. IEEE Transactions on Software Engineering, 21(12): 969-992, 1995.
[8] T. Cormen, C. Leiserson, R. Rivest. Introduction to algorithms. The MIT Press, 1994.
[9] Y. Deng, J. Wang, R. Sinha. Compositional and incremental verification of real-time systems
based on the RAS model. Technical Report, School of Computer Science, Florida
International University, 1997.
[10] E.A. Emerson, A.K. Mok, A. P. Sistla, J. Srinivasian. Quantitative temporal reasoning. 1989.
[11] J. Engelfriet, G. Leih, G. Rozenberg. Net-based description of parallel object-based system,
or pots and pops. Foundations of object-oriented languages, LNCS, 489, 1990.
16
[12] Y. Lee, S. Park. Opnets: An object-oriented high-level Petri net model for real-time systems.
Journal of Systems & Software, SE-13(3):69-86, 1993.
[13] D. Mandrioli, A. Morzenti, M. Pezze, P. Pietro S. and S. Silva. A Petri net and logic
approach to the specification and verification of real time systems. Formal Methods for Real
time Computing, Ed: C. Heitmeyer and D. Mandrioli, John Wiley & Sons Ltd, 1996.
[14] R. Sloan, U. Buy. Reduction rules for time Petri nets. Acta Informatica. 33:687-706, 1996.
Appendix: Formal Description of RAS Model
The basic building block of an RAS model is called Atomic RAS Architecture (ARA), which
corresponds to the concept of component specification discussed earlier. Formally, an ARA is
defined as a tripe:
ARA=(TPN, PORT, AC), where
(1) TPN=(P, T, B, F, M0, SIM) is a time Petri net.
(2) PORTTPN.P is a special class of places used to represent the communication ports of
the component. Furthermore, PORT = PORT.INPORT.OUT, and PORT.INPORT.OUT = ,
where PORT.IN and PORT.OUT are called the set of input-ports and output ports, respectively.
(3) AC is a RTCTL formula used to describe component and environment constraints for the
component. In particular, AC.AlphabetPORT, where AC.Alphabet denotes the alphabet of AC.
An ARA describes a system component from the perspective of its externally observable and
operational behavior (by TPN), its ports of interaction with its environment (by PORT), the
constraints it needs to satisfy, and the assumptions about its environment (by AC).
Based on the definition of ARA, we recursively define the architecture of any real-time system
(called an RAS architecture, and denoted by RA) as a composition of component specifications
(ARAs) or sub-architectures linked together by inter-related connection structures. Formally, an
RAS architecture RA is defined as follows:
(1) An ARA is an RAS architecture (RA).
(2) If RA1, RA2, …, RAk are a set of RAS architectures, then RA=(SAS, PORT, CON, AC)
is an RAS Architecture, where
(a) SAS= ki=1RAi are called the sub-architectures of RA;
(b) PORTki=1RAi.PORT are the ports of RA;
17
(c) CON=(P, T, B, F, M0, [SIM, Pty]) is a TPN used to describe the connections between the
sub-architectures RAi, i=1,…,k, that satisfies the following rules:
i. P is a set of places. In particular, (ki=1RAi.PORT-RA.PORT)P. This set of ports is called
the internal ports of RA, which are used solely for connections between the system components,
and not accessible from outside of the system;
ii. T is a set of transitions describing real-time behavior of the connections;
iii. B=TPN is the backward incidence function of the TPN. In particular,
(pki=1RAi.PORT.IN, and tT), B(t, p)=0. That is, an input port can only accept incoming
communication, but cannot generate outgoing communication;
iv. F=TPN is the forward incidence function of the TPN. In particular,
(pki=1RAi.PORT.OUT, and tT), F(t, p)=0. That is, an output port can only generate
outgoing communication, but cannot accept incoming communication; and
v. pki=1RAi.-RA.PORT, ( tT), such that B(t, p)>0, or F(t, p)>0. That is, all internal
ports of an architecture must be connected to at least one connection.
vi. M0 is the initial marking of the TPN used to describe the initial state of the system.
vii. [SIM, Pty] are the time intervals and priorities associated with the transitions,
respectively. In particular, SIM=TN(N) and Pty=TN. The defualt time interval for a
tT is (0, ), and the default priority is 0 (lowest priority).
(d) AC is an RTCTL formula used to describe the architecture constraints of RA, with its
alphabet being the ports of the components. That is, AC.Alphabetki=1RAi.PORT.
AC=CCCICEC, where C is the component constraints used to describe the required
synchronization between connections, and EC is the environmental constraints used to describe
the assumptions about the environment of the system and components.
18