Formal Semantics and Analysis of Behavioral AADL Models in ... - IfI

Formal Semantics and Analysis of Behavioral
AADL Models in Real-Time Maude
Peter Csaba Ölveczky1 , Artur Boronat 2 , José Meseguer 3 , and Edgar Pek 3
1 University of Oslo
2 University of Leicester
3 University of Illinois at Urbana-Champaign
Abstract. AADL is a standard for modeling embedded systems that is
widely used in avionics and other safety-critical applications. However,
the AADL standard lacks at present a formal semantics, and this severely
limits both unambiguous communication among model developers, and
the development of simulators and formal analysis tools. In this work we
present a formal real-time rewriting logic semantics for a behavioral subset
of AADL which includes the essential aspects of its behavior annex.
Our semantics is directly executable in Real-Time Maude and provides
an AADL simulator and LTL model checking tool called AADL2Maude.
AADL2Maude is integrated with OSATE, so that OSATE’s code generation
facility is used to automatically transform AADL models into
their corresponding Real-Time Maude specifications. Such transformed
models can then be executed and model checked by Real-Time Maude.
We present our semantics, and two case studies in which safety-critical
properties are verified in AADL2Maude.
1 Introduction
AADL [15] is both a modeling language for real-time embedded systems and an
international standard widely used in industry. It has good features to model the
real-time aspects of embedded systems and to represent both the software and
hardware architectures of the components making up such systems. It does however
lack at present a formal semantics. This lack is particularly important for
real-time embedded systems, because many of them —in areas such as avionics,
motor vehicles, and medical systems— are safety-critical systems, whose failures
may cause great damage to persons and/or valuable assets. Indeed such systems
are often required to pass stringent processes of certification to provide sufficiently
strong evidence about their safety. Furthermore, AADL models are not
executable, which limits not just the possibility of formal analysis of their safety
and liveness properties, but even the possibility of simulating them.
It seems clear that overcoming these limitations of AADL is highly desirable,
but requires in an essential way the use of formal methods, because in the absence
of a precise mathematical semantics any pretense of achieving formal verification
is meaningless. Furthermore, these formal methods should be supported by tools
that are integrated into the AADL tool chain. A further, highly desirable goal

2
is to have a formal semantics of AADL that can be used to automatically generate
formal executable specifications of AADL models, since the first and most
basic way of analyzing AADL models should be the capacity to simulate such
models; and since such formal executable specifications can then also be used
for automatic verification of safety and liveness properties by model checking.
There isn’t of course a single choice of a formal framework in which to first
define a formal semantics for AADL and then support both simulation and
formal analysis of AADL models. What we have is a spectrum of choices, each
with its specific advantages and its possible limitations. This technical report
describes our experience in defining a formal semantics for a substantial subset
of AADL in the Real-Time Maude formal specification language [14]; and in
directly using such a formal semantics to simulate and formally analyze AADL
models. We have found the rewriting logic formal framework supported by Real-
Time Maude particularly well suited for this task for the following reasons:
– Real-time formalism. All real-time aspects of AADL can be directly and
naturally formally modeled by means of real-time rewrite theories.
– Support for nested objects. AADL models are structured in nested hierarchies
of components. Much would be lost in translation if such structure were not
preserved. Real-Time Maude’s support for object classes with a “Russian
dolls” nested structure (see [10]) provides an essentially isomorphic formal
counterpart for an AADL model. This is important to achieve a small representational
distance between an AADL model and its corresponding formal
specification, and to be able to map back simulation and formal analysis
results from the formal specification to the original model for diagnostic
purposes.
– Wide range of formal analysis capabilities. By automating the AADL formal
semantics with the AADL2Maude tool, one can automatically generate
formal executable specifications of AADL models in Real-Time Maude for
simulation, reachability analysis, and LTL model checking purposes.
One potential limitation of the Real-Time Maude framework is that, because of
its flexibility to represent many communication models, object architectures, and
unbounded algebraic data structures, in general its specifications fall outside the
automata-theoretic decidable fragments for real-time model checking. However,
because of the routine use of nested object hierarchies and of different data
structures in AADL itself, plus the need for formal properties involving such
structures, we doubt that AADL models can be faithfully modeled in automatabased
formalisms, although it may be possible to model abstractions of such
models for restricted subsets of AADL. Furthermore, the lack of decidability
for general Real-Time Maude models is substantially compensated for by the
decidability of time-bounded LTL properties for a wide class of models, including
a large class of object-oriented systems, under mild checkable conditions [13].
Our Contribution. Our main contributions are: (i) a formal semantics for a
substantial subset of AADL, including the most essential aspects of AADL’s
behavior annex; (ii) the AADL2Maude tool, automating the generation of Real-

Time Maude specifications for AADL models in OSATE based on such a semantics
and supporting simulation, reachability and LTL model checking analyses;
and (iii) two case studies, one on safe interoperation of medical devices and one
on the safety of avionics systems, demonstrating the usefulness of this semantics
and tools in concrete examples. This work should be seen in the context of other
recent approaches to the formal analysis of AADL models [2, 7, 1, 18, 17], which
are further discussed in Section 5. To the best of our knowledge, our approach
is the only one to date to provide an intuitive semantics, preserving the components’
hierarchical structure, and also simulation and LTL model checking
capabilities for AADL behavioral models in its behavior annex, as opposed to
approaches that specify AADL model behavior in formalisms external to AADL.
The paper is organized as follows. Section 2 gives a brief introduction to
AADL and Real-Time Maude. Section 3 presents the Real-Time Maude semantics
of a behavioral subset of AADL, and shows how AADL models can be
formally analyzed in AADL2Maude. Section 4 reports on the verification of the
avionics active standby example. Section 5 discusses related work on formalizing
fragments of AADL, and Section 6 gives some concluding remarks.
Acknowledgments. Xiaokang Qiu contributed to an earlier version of this
technical report, and also to earlier prototype versions of the AADL semantics
and the verification of the avionics case study. This work reported here is part of
a Rockwell-Collins sponsored joint project with Prof. Lui Sha and his students
at UIUC and reseachers at Rockwell-Collins. We have benefitted very much
form Prof. Sha’s comments and suggestions during many project meetings, and
also from the help and suggestions of other members of the joint working group,
particularly from Joe Hendrix (who made some initial contributions to the AADL
to Maude translation ideas), Tanya Crenshaw, who was an early user of Real-
Time Maude for analysis of embedded systems, Mu Sun who pioneered the static
analysis of AADL models in Maude using MOMENT2, and Abdullah Al-Nayeem
and Min-Young Nam, who have helped us greatly with AADL expertise and with
concrete AADL examples as those mentioned in this report. We are also very
grateful to Steve Miller and Darren Cofer from Rockwell-Collins for many helpful
suggestions on this work along our regular project meetings.
2 Preliminaries on AADL and Real-Time Maude
2.1 AADL
The SEA Architecture Analysis & Design Language (AADL) [15, 16] is an industrial
standard used in avionics, aerospace, automotive, and robotics communities
to describe a performance-critical embedded real-time system as an assembly of
software components mapped onto an execution platform.
An AADL model describes a system as a hierarchy of hardware and software
components. A component is defined by its name, its interface consisting
of input and output ports, its subcomponents and their interaction, and other
type-specific properties. System components are the top-level components, and
3

4
can consist of other system components as well as of hardware and software
components. Hardware components include: processor components that schedule
and execute threads; memory components; device components representing
devices like sensors and actuators that interface with the environment; and bus
components that interconnect processors, memory, and devices. Software components
include: thread components modeling the application software to be
executed; process components defining protected memory that can be accessed
by its thread subcomponents; and data components representing data types. In
AADL, thread behavior is typically described using AADL’s behavior annex [5],
which models programs as transition systems with local state variables.
An AADL model specifies how the different components interact and are
integrated to form a complete system. The AADL standard also describes the
runtime mechanisms for handling message and event passing, synchronized access
to shared resources, thread scheduling when several threads run on the same
processor, and dynamic reconfiguration that are specified by mode transitions.
AADL has a MOF meta-model, and the OSATE modeling environment provides
a set of plug-ins for front-end processing of AADL models on top of the
Eclipse platform.
2.2 Rewriting Logic, Maude, and Real-Time Maude
Rewriting Logic and Maude. A Maude [4] module specifies a rewrite theory
of the form (Σ, E ∪A, R), where (Σ, E ∪A) is a theory in membership equational
logic [8], with Σ a signature, E a set of conditional equations and memberships,
and A a set of equational axioms such as associativity, commutativity,
and identity, so that equational deduction is performed modulo the axioms A.
The theory (Σ, E ∪ A) specifies the system’s state space as an algebraic data
type. R is a collection of labeled conditional rewrite rules specifying the system’s
local transitions, each of which has the form
[l] : t −→ t ′ if
n
m
ui −→ vi ∧ wj = w ′ j,
i=1
where l is a label. Intuitively, such a rule specifies a one-step transition from
a substitution instance of t to the corresponding substitution instance of t ′ ,
provided the condition holds. The rules are implicitly universally quantified by
the variables appearing in the Σ-terms t, t ′ , ui, vi, wj, and w ′ j . The rules are
applied modulo the equations E ∪ A. 4
We briefly summarize the syntax of Maude. Operators are introduced with
the op keyword. They can have user-definable syntax, with underbars ‘_’ marking
the argument positions, and are declared with the sorts of their arguments
and the sort of their result. Some operators can have equational attributes, such
as assoc, comm, and id, stating, for example, that the operator is associative
4 Operationally, a term is reduced to its E-normal form modulo A before any rewrite
rule in R is applied in Maude.
j=1

and commutative and has a certain identity element. Such attributes are then
used by the Maude engine to match terms modulo the declared axioms. There
are three kinds of logical statements, namely, equations—introduced with the
keywords eq, or, for conditional equations, ceq—memberships—declaring that
a term has a certain sort and introduced with the keywords mb and cmb—and
rewrite rules—introduced with the keywords rl and crl. The mathematical variables
in such statements are declared with the keywords var and vars. An equation
f(t1, . . . , tn) = t with the owise (for “otherwise”) attribute can be applied
to a subterm f(. . .) only if no other equation with left-hand side f(u1, . . . , un)
can be applied. 5
In object-oriented Maude modules one can declare classes and subclasses. A
class declaration
class C | att1 : s1, ... , attn : sn .
declares an object class C with attributes att1 to attn of sorts s1 to sn. An object
of class C in a given state is represented as a term
< O : C | att1 : val1, ..., attn : valn >
where O is the object’s name, and where val1 to valn are the current values
of the attributes att1 to attn. In an object-oriented system, the state, which
is usually called a configuration, is a term of the built-in sort Configuration.
It has typically the structure of a multiset made up of objects and messages.
Multiset union for configurations is denoted by a juxtaposition operator (empty
syntax) that is declared associative and commutative and having the none multiset
as its identity element, so that order and parentheses do not matter, and so
that rewriting is multiset rewriting supported directly in Maude. The dynamic
behavior of concurrent object systems is axiomatized by specifying each of its
concurrent transition patterns by a rewrite rule. For example, the rule
rl [l] : < O : C | a1 : 0, a2 : y, a3 : w, a4 : z > =>
< O : C | a1 : T, a2 : y, a3 : y + w, a4 : z >
defines a parameterized family of transitions (one for each substitution instance)
which can be applied whenever the attribute a1 of an object O of class C has
the value 0, with the effect of altering the attributes a1 and a3 of the object.
“Irrelevant” attributes (such as a4, and the right-hand side occurrence of a2)
need not be mentioned in a rule.
A subclass inherits all the attributes and rules of its superclasses.
Object-Oriented Specification in Real-Time Maude. Real-Time Maude [14]
is a high-performance tool that extends Maude to support the formal specification
and analysis of object-based real-time systems. A Real-Time Maude
timed module specifies a real-time rewrite theory [12], that is, a rewrite theory
R = (Σ, E ∪ A, R), such that:
5 A specification with owise equations can be transformed to an equivalent system
without such equations [4].
5

6
1. (Σ, E ∪ A) contains a specification of a sort Time which defines the time
domain (which may be discrete or dense). Although a timed module is
parametric on the time domain, Real-Time Maude provides some predefined
modules specifying useful time domains. For example, the modules
NAT-TIME-DOMAIN-WITH-INF and POSRAT-TIME-DOMAIN-WITH-INF define the
time domain to be, respectively, the natural numbers and the nonnegative
rational numbers.
2. The rules in R are decomposed into:
– “ordinary” rewrite rules that model instantaneous change, and
– tick (rewrite) rules that model the elapse of time in a system. Such tick
rules have the form
crl [l] : {t} => {t ′ } in time u if cond .
where t and t ′ are terms of sort Configuration, { } is a built-in constructor
of a new sort GlobalSystem, and where u is a term of sort Time
denoting the duration of the rewrite.
The initial state of a real-time system so specified must be reducible to a
ground term {t0} using the equations in the specification. The form of the tick
rules then ensures uniform time elapse in all parts of a system.
Formal Analysis in Real-Time Maude. Timed modules are executable under
reasonable assumptions, and Real-Time Maude provides a spectrum of formal
analysis capabilities.
Real-Time Maude’s timed “fair” rewrite command simulates one behavior
of the system up to a certain duration. It is written with syntax
(tfrew t in time * pattern such that cond in time

for b a term of sort Bool, which defines the state proposition prop to hold in
all states {t} where {t} |= prop evaluates to true. A temporal logic formula
is constructed by state propositions and temporal logic operators such as True,
False, ~ (negation), /\, \/, -> (implication), [] (“always”), (“eventually”),
O (“next”), and U (“until”). The model checking command has syntax
(mc t |=u formula .)
for t the initial state and formula the temporal logic formula.
3 Real-Time Maude Semantics for a Behavioral Subset of
AADL
This section presents the Real-Time Maude semantics for a behavioral subset of
AADL. Section 3.1 presents the chosen subset of AADL, Section 3.2 presents its
Real-Time Maude semantics, and Section 3.3 explains how AADL models can
be formally analyzed in Real-Time Maude.
3.1 Overview of a Behavioral Subset of AADL
This section gives an overview of the subset of AADL for which we have defined
a rewriting logic semantics.
Components. In AADL, a system is modeled as a collection of software and
hardware components. Since we have focused on the software parts of AADL,
the following description only deals with the software components and features.
A component is given by its type and its implementation. A component type
specifies the component’s interface in terms of features and properties. In the
software portion, features are just input and output ports. Properties support
specialized modeling and analysis capabilities that can be defined in AADL
annexes. A component implementation specifies the internal structure of the
component in terms of a set of subcomponents, a set of connections linking the
ports of the subcomponents, and modes that represent operational states of
components (see below).
System components are the top level software components. A process component
contains a set of thread components that together define the dynamic
behavior of the process.
Port Connections. Port connections link ports to enable the exchange of data
and events among components. Ports are directional. An out port represents
output provided by the sender, and an in port represents input needed by the
receiver. A port is either a data port, an event port, or an event data port. Each
port is accessible through its buffer. Buffers of event ports and event data ports
support queueing of, respectively, “events” and message data, while buffers of
data ports only keep the latest data. In addition, each thread port is associated
7

8
to an internal buffer, which is accessible by the thread. The dequeue protocol
attribute determines how many elements in the port buffer are transferred to
the thread’s internal buffer when a thread is dispatched.
A level-up connection links an outgoing port in a subcomponent to an outgoing
port in the containing component. A level-down connection links an incoming
port of a component to an incoming port in one of its subcomponents. A samelevel
connection connects an outgoing port of a component to incoming ports
of another component at the same level in the containment hierarchy. AADL
supports 1-to-n connectivity for event and event data ports at the same level.
Modes. Modes represent the operational states of components. A component
can have mode-specific property values, subcomponents, and connections. Mode
transitions are triggered by events. In the following example, a simplified blood
pressure monitor process has two modes, fast and slow. The fast and slow
modes have their own implementations, sending out the requestbp signal every
100, respectively 1000, milliseconds. An incoming event through the port
modechange results in mode switch between slow mode and fast mode.
process bpProc
features
modeChange: in event port;
requestbp: out event port;
end bpProc;
process implementation bpProc.i
subcomponents
slowTh: thread mcTh.slow in modes (slow);
fastTh: thread mcTh.fast in modes (fast);
connections
event port slowTh.requestbp -> requestbp in modes (slow);
event port fastTh.requestbp -> requestbp in modes (fast);
modes
slow: initial mode ;
fast: mode ;
slow -[modeChange]-> fast;
fast -[modeChange]-> slow;
end bpProc.i;
thread mcTh
features
requestbp: out event port;
end mcTh;
thread implementation mcTh.slow
properties
Period => 1000 Ms;
annex Behavior_specification {**
states

send : initial state;
transitions
send -[]-> send {requestbp!};
**};
end mcTh.slow;
thread implementation mcTh.fast
properties
Period => 100 Ms;
annex Behavior_specification {**
states
send : initial state;
transitions
send -[]-> send {requestbp!};
**};
end mcTh.fast;
(We do not support at the moment some other features of modes, such as,
e.g., the “applies to” construct, where the properties of a subcomponent are
directly modified as a result of a mode change in one of its supercomponents.)
Dispatch Protocols. The dispatch protocol property of a thread determines
when the thread is executed. A periodic thread is activated at time intervals of
the specified period T ; an aperiodic thread is activated when an event arrives at
a port of the thread; a sporadic thread is activated when an event arrives and
the interval between two dispatches is at least T ; and a background thread is
(re-)activated upon the completion of execution.
Behavioral Annex. The dynamic behavior of a thread is defined in AADL
using AADL’s behavioral annex [5]. Given a finite set of states (or locations),
and a set of state variables, the dynamic behavior of a thread is defined by a set
of guarded state transitions of the form
s -[guard]-> s ′ {actions}
where s and s ′ are states, and where the guard is a boolean condition on the
values of the state variables and/or the presence of events or data in the thread’s
input ports. The actions that are performed when a transition is applied may
update the state variables, generate new output events and/or data, and/or
suspend the thread for a given amount of time. Actions are built from basic
actions using a small set of control structures allowing sequencing, conditionals,
and finite loops.
When a thread is activated, an enabled transition is nondeterministically
selected and applied; if the resulting state s ′ is not a complete state, another
transition is applied, and so on, until a complete state is reached (or the thread
is suspended).
9

10
Value Constraints. In embedded applications, such as the active standby
system discussed in Section 4, the environment interacting with sensors and
actuators can be modeled as a special “environment” component that nondeterministically
generates events.
Typically, the data/events from the environment are interdependent, so that
not all possible combinations of values are legal inputs from the environment.
Using the fact that we can define new properties in AADL, Abdullah Al-Nayeem
has extended AADL with a property feature to express such constraints on a set
of values. For example, in the avionics example in Section 4, the environment
sends five boolean-valued signals in each period. One of these reports whether
or not side 1 has failed; another signal reports whether side 2 has failed. It is
assumed that both sides cannot fail at the same time. Hence, the input from
the environment in each round is a five-tuple (b1, b2, . . . , b5) satisfying the value
constraint (b1 ∨ b2). See Section 4 for more details.
An AADL Example. As a small example of an AADL specification within
our targeted subset of AADL, consider a system consisting of a controller, a
ventilator machine that assists a patient’s breathing during surgery, and an Xray
device. Whenever a button is pushed to take an X-ray, and the ventilator
machine has not paused sometime in the past 10 minutes, the ventilator machine
should pause for two seconds, starting one second after the button is pushed,
and the X-ray should be taken after two seconds. To execute the system, we also
add a test activator that pushes the button every second.
The following AADL model was developed by Min-Young Nam.
The entire system Wholesys is a closed system that does not have any features
(i.e., ports) to the outside world. Hence, its type (interface) is empty:
system Wholesys
end Wholesys;
The implementation of the entire system describes the architecture of the system,
with four subcomponents and the connections linking these subcomponents:
system implementation Wholesys.imp
subcomponents
TestActivator: system TA.impl;
XRayMachine: system XM.impl;
VentilatorMachine: system VM.impl;
Controller: system Controller.impl;
connections
C01: event data port Controller.xmContrOutput ->
XrayMachine.controllerInput;
C02: event data port Controller.vmContrOutput ->
VentilatorMachine.controllerInput;
C03: event data port VentilatorMachine.feedback -> Controller.feedback;
C04: event data port TestActivator.pressEvent ->
Controller.commandInput;
end Wholesys.imp;

The test activator TestActivator, whose job it is to generate an event every
second, is an instance of a system of type TA, having as interface the output port
pressEvent:
system TA
features
pressEvent: out event data port Behavior::integer;
end TA;
Its implementation consists of a single process taPr, which is an instance of
taProcess.impl:
system implementation TA.impl
subcomponents
taPr: process taProcess.impl;
connections
C90: event data port taPr.pressEvent -> pressEvent;
end TA.impl;
A taProcess.impl itself consists of a single thread taTh:
process taProcess
features
pressEvent: out event data port Behavior::integer;
end taProcess;
process implementation taProcess.impl
subcomponents
taTh: thread taThread.impl;
connections
C91: event data port taTh.pressEvent -> pressEvent;
end taProcess.impl;
The thread taTh is dispatched periodically, with a period of one second.
When the thread is dispatched, the single transition is applied once (since the
resulting state s0 is a complete state), and the action performed is to output
the value 1 through the output port pressEvent:
thread taThread
features
pressEvent: out event data port Behavior::integer;
properties
Dispatch_Protocol => periodic;
Period => 1 sec;
end taThread;
thread implementation taThread.impl
annex behavior_specification {**
states
s0: initial complete state;
11

12
transitions
s0 -[ ]-> s0 { pressEvent!(1); };
**};
end taThread.impl;
The other components are defined in a similar way. The following presents
the implementation of the X-ray machine thread, which shows a transition system
with state variables, and where each transition guard contains a test on
the existence of events/data in the input ports, and on the value of the data
received (inMessage). Since the Dispatch_Protocol is aperiodic, this thread
is activated upon receiving input:
thread xmThread
features
contrInput: in event data port Behavior::integer;
timeoutInput: in event port;
timeoutReq: out event data port Behavior::integer;
properties
Dispatch_Protocol => aperiodic;
end xmThread;
thread implementation xmThread.impl
annex behavior_specification {**
states
idle: initial complete state;
xray, pendingXray: complete state;
state variables
xrayDone: Behavior::boolean;
pendingTimeout: Behavior::integer;
xrayDuration: Behavior::integer;
inMessage: Behavior::integer;
initial
xrayDone := false;
pendingTimeout := 2;
xrayDuration := 1;
transitions
idle -[contrInput?(inMessage) when inMessage = 1]-> pendingXray
{timeoutReq!(pendingTimeout);};
pendingXray -[timeoutInput?]-> xray {timeoutReq!(xrayDuration);};
xray -[timeoutInput?]-> idle {xrayDone:=true;};
**};
end xmThread.impl;
3.2 Real-Time Maude Semantics of AADL
AADL is a modeling notation whose standard is described informally in English
without a precise semantics. Unavoidably this means that there are various
ambiguities in the standard, including its behavioral annex. However, formal

specification and analysis are meaningless without a precise semantics. This section
outlines the rewriting logic semantics for the behavioral subset of AADL
presented in Section 3.1. We show first how an AADL model can be represented
in Real-Time Maude, and then define the dynamics of AADL for models that
use the behavioral annex.
Representing AADL Models in Real-Time Maude
Components. The semantics of a component-based language such as AADL can
naturally be defined in an object-oriented style, where each instance of a component
is modeled as an object. The hierarchical structure of AADL components
is reflected in the nested (“Russian dolls”) structure of objects, in which an attribute
of an object/component contains the subcomponents of the object as a
multiset of objects.
Any AADL component instance is represented as an object instance of a
subclass of the following class Component, which contains the attributes common
to all kinds of components (systems, processes, threads, etc.):
class Component | features : Configuration,
subcomponents : Configuration,
connections : ConnectionSet,
properties : Properties,
modes : ModeTransitionSystem,
inModes : ModeNameSet .
The attribute features denotes the features of a component (i.e., its ports), represented
as a multiset of Port objects (see below). The subcomponents attribute
denotes the multiset of subcomponents of the object. The connections attribute
denotes the set of port connections of the objects (see below). The properties
attribute denotes the properties of the component, which in our case are the
dispatch protocol and the value constraints for thread components. The modes
attribute contains the object’s mode transition system. Finally, the inModes
attribute gives the set of modes (of the immediate containing component) in
which the component is available (if the component is not a mode-specific subcomponent
of the containing component, then this attribute has the special value
allModes).
For our chosen subset of AADL, the classes System and Process, denoting
system and process components, do not have any other attributes than those
they inherit from Component:
class System . subclass System < Component .
class Process . subclass Process < Component .
The Thread class is the following subclass of Component:
class Thread | behavior : ThreadBehavior,
status : ThreadStatus,
13

14
subclass Thread < Component .
threadType : ThreadName,
implementationType : ImplName,
deactivated : Bool .
The behavior attribute denotes the locations and the state variables and their
values of the transition system associated with the thread. To avoid carrying
around the (sometimes quite large) set of transitions associated with the
thread, the transitions themselves are defined as the value of the expression
transitions(threadT ype,implName). To access its transitions, a thread object
must therefore contain its threadName and implName. The status indicates
the current status of the thread (active, completed, suspended, etc.). The attribute
deactivated indicates whether the thread is deactivated as a result of
a mode transition somewhere in the component hierarchy.
Ports. Any port is an object instance of a subclass of the following class Port,
whose only attribute denotes the list of messages (events or data) currently in
the port’s buffer:
class Port | buffer : MsgList .
Several subclasses of Port define outgoing and incoming ports, as well as
event ports and event data ports. The subclass InThreadPort also contains an
internalBuffer and a fresh flag (which indicates whether there are new messages
in the thread’s internal buffer that have not yet been treated). In addition,
the dequeueProtocol is defined in the InEventThreadPort. It determines how
many items are dequeued from the buffer when a thread dispatches:
class InPort . class OutPort .
subclass InPort OutPort < Port .
...
class InThreadPort | internalBuffer : MsgList, fresh : Bool .
subclass InThreadPort < InPort .
class InEventThreadPort | dequeueProtocol : DequeuePolicy .
subclass InEventThreadPort < InThreadPort InEventPort .
sort DequeuePolicy .
ops allItems oneItem : -> DequeuePolicy [ctor] .
Connections. The following sorts define, respectively, port names, single port
connections, and sets of such connections:
sort PortName . subsort PortId < PortName .
op _._ : ComponentId PortId -> PortName [ctor] .
sort Connection .

op _-->_ : PortName PortName -> Connection [ctor] .
sort ConnectionSet . subsort Connection < ConnectionSet .
op none : -> Connection [ctor] .
op _;_ : ConnectionSet ConnectionSet -> ConnectionSet [ctor assoc comm id: none] .
An (immediate) level-up connection is therefore modeled as a term C.P --> P ′ ,
where C is the identifier of the subcomponent in which the source port with
identifier P resides. The destination port is the port with name P ′ in the “current”
component. Likewise, immediate same-level and level-down connections
are terms of the forms, respectively, P1 --> P2 and P --> C.P ′ . We have not yet
defined the semantics of delayed connections.
Connections can be mode-specific; such connections are defined as terms of
the form P --> P ′ in modes (mk . . . ml):
op _-->_in‘modes_ : PortName PortName ModeNameSet -> Connection [ctor] .
Representing Thread Behavior. As mentioned above, to save space in the term
representation of an AADL component by not carrying around the transition
rules, which do not change, of a thread in its state, we divide the representation
of the transition system associated with a thread into two parts:
1. The locations and the current values of the local variables of the transition
system are represented in the behavior attribute of the corresponding thread
objects as a term
states
current: s complete: s1 . . . sk others: sk+1 . . . sn
state variables
var1 |-> val1 . . . varm |-> valuem
2. The transitions of any thread of “thread type” threadT ype and implementation
impl are represented by a term
transitions
s -[guard]-> s ′ {actions} ;
. . .
s ′′ -[guard ′ ]-> s ′ {actions ′ }
that is declared to be equal to the term transitions(threadT ype,impl).
The constructor for the first part of transition systems is declared
sort ThreadBehavior .
op states_state‘variables_ : LocationDeclSet Valuation -> ThreadBehavior [ctor] .
sorts Location LocationSet .
subsort Location < LocationSet .
op emptyLocationSet : -> LocationSet [ctor] .
15

16
op __ : LocationSet LocationSet -> LocationSet
[ctor assoc comm id: emptyLocationSet] .
sorts LocationDecl LocationDeclSet .
subsort LocationDecl < LocationDeclSet .
op current:_ : Location -> LocationDecl [ctor] .
op initial:_ : Location -> LocationDecl .
ops complete:_ other:_ : LocationSet -> LocationDecl [ctor] .
op noLocDecl : -> LocationDeclSet [ctor] .
op __ : LocationDeclSet LocationDeclSet -> LocationDeclSet
[ctor assoc comm id: noLocDecl] .
We have also defined some additional “syntactic sugar” functions (e.g., allowing
the definition of initial states, for skipping the declaration of the store when
no state variables are declared, etc.) that reduce to terms of the above form.
The set of transitions, locations, and variable mappings have the structure of a
multiset, using a binary multiset union operator that is declared to be associative
and commutative.
For example, the set of transitions is defined as follows:
sort Transition .
op _-‘[_‘]->_‘{_‘} : Location TransGuard Location StatementList
-> Transition [ctor] .
sort TransitionSet .
subsort Transition < TransitionSet .
op emptyTransitionSet : -> TransitionSet [ctor] .
op _;_ : TransitionSet TransitionSet -> TransitionSet
[ctor assoc comm id: emptyTransitionSet] .
As already mentioned, the transition table is given by the function transitions
having the memo attribute, which means that the transitions for each thread implemented
are memorized:
op transitions : ThreadName ImplName -> TransitionSet [memo] .
Translating an AADL Model into a Real-Time Maude Module. We now show how
an AADL model can be represented as a Real-Time Maude module. One of the
main goals of our semantics is to make the “representational distance” between
the AADL specification and the corresponding Real-Time Maude module as
small as possible, so that we can automatically translate an AADL model to a
very similar-looking Real-Time Maude module.
Consider a type declaration of a component (System, Process, or Thread):
system typeNname
[features: ports]
[properties: properties]
end typeName;

This declaration binds the name to a set of ports and properties. We can therefore
consider system as a function that, given a name, returns the interface of
that name:
op system : SystemName ~> FeaturesAndProperties .
A component implementation, such as
system implementation typeName.implName
...
end typeName.implName;
defines an object/component template, which is instantiated to a concrete instance
of the component in AADL declarations of the form
instanceName: system typeName.implName
and
instanceName: system typeName.implName in modes (mode names)
Therefore, in our Real-Time Maude semantics, the above component implementation
declaration translates to an equation
var INSTANCE-NAME : Oid . var MNS : ModeNameSet .
eq INSTANCE-NAME system typeName . implName in modes MNS =
< INSTANCE-NAME : System | features : features(system(typeName)),
properties : properties(system(typeName)),
inModes : MNS,
subcomponents : ...,
connections : ...,
... >
In addition, the equation
eq SI:SystemId system SN:SystemName . IN:ImplName =
SI:SystemId system SN:SystemName . IN:ImplName in modes allModes .
allows us to declare component instances that are not mode-dependent.
A concrete component instance, declared in AADL as
instanceName: system typeName.implName
is therefore translated directly into the Real-Time Maude term
instanceName system typeName . implName
which equals the desired object
17

18
< instanceName : System | features : features(system(typeName)),
properties : properties(system(typeName)),
inModes : allModes,
subcomponents : ...,
connections : ...,
... >
Likewise, for mode-specific system components, the term
instanceName system typeName . implName in modes (mode names)
equals the object
< instanceName : System | features : features(system(typeName)),
properties : properties(system(typeName)),
inModes : mode names,
subcomponents : ...,
connections : ...,
... >
This scheme applies in exactly the same way to the other kinds of components
(Process and Thread), so that the AADL model and its Real-Time Maude
representation are textually fairly similar, as shown in the following example.
Example 1. Consider the AADL model of the X-ray/ventilator machine system
in Section 3.1. The declaration of the type of the entire system
system Wholesys
end Wholesys;
is translated into the Real-Time Maude equation
eq system(Wholesys) = features none properties noProperty .
The AADL implementation definition
system implementation Wholesys.imp
subcomponents
Test_Activator: system TA.impl;
XRayMachine: system XM.impl;
VentilatorMachine: system VM.impl;
Controller: system Controller.impl;
connections
C01: event data port Controller.xmContrOutput ->
XrayMachine.controllerInput;
C02: event data port Controller.vmContrOutput ->
VentilatorMachine.controllerInput;
C03: event data port VentilatorMachine.feedback -> Controller.feedback;
C04: event data port TestActivator.pressEvent ->
Controller.commandInput;
end Wholesys.imp;

is translated into the Real-Time Maude equation
eq INSTANCE-NAME system Wholesys . imp in modes MNS =
< INSTANCE-NAME : System | modes : noModes, inModes : MNS,
features : features(system(Wholesys)),
subcomponents : (TestActivator system TA . impl)
(XRayMachine system XM . impl)
(VentilatorMachine system VM . impl)
(Controller system Controller . impl),
connections :
(Controller . xmContrOutput --> XRayMachine . controllerInput) ;
(Controller . vmContrOutput --> VentilatorMachine . controllerInput) ;
(VentilatorMachine . feedback --> Controller . feedback) ;
(TestActivator . pressEvent --> Controller . commandInput),
properties : properties(system(Wholesys)) > .
Likewise, the AADL model of the test activator process
system TA
features
press_event: out event data port Behavior::integer;
end TA;
system implementation TA.impl
subcomponents
taPr: process taProcess.impl;
connections
C90: event data port taPr.pressEvent -> pressEvent;
end TA.impl;
is translated line by line into the Real-Time Maude equations
eq system(TA) = features (pressEvent out event data port) .
eq INSTANCE-NAME system TA . impl in modes MNS =
< INSTANCE-NAME : System | modes : noModes, inModes : MNS,
features : features(system(TA)),
subcomponents : (taPr process taProcess . impl),
connections : (taPr . pressEvent --> pressEvent),
properties : properties(system(TA)) > .
where pressEvent out event data port equals a port object accordining the
following definition:
op _out‘event‘data‘port : PortId -> Object .
eq P:PortId out event data port = < P:PortId : OutEventDataPort | buffer : nil > .
In the same style, we can define the translation of the test activator thread
implementation. In AADL, this thread is defined as follows:
19

20
thread taThread
features
press_event: out event data port Behavior::integer;
properties
Dispatch_Protocol => periodic;
Period => 1 sec;
end taThread;
thread implementation taThread.impl
annex behavior_specification {**
states
s0: initial complete state;
transitions
s0 -[ ]-> s0 { pressEvent!(1); };
**};
end taThread.impl;
The corresponding Real-Time Maude equations are again very similar:
eq thread(taThread) = features (pressEvent out event data thread port)
properties periodic-dispatch(1) .
eq INSTANCE-NAMEthread taThread . impl in modes MNS =
< INSTANCE-NAME : Thread | modes : noModes, inModes : MNS,
features : features(thread(taThread)),
threadType : taThread,
implementationType : impl,
subcomponents : none,
connections : none,
properties : properties(thread(taThread)),
behavior : state variables noVariables
states initial: s0 complete: s0 > .
eq transitions(taThread, impl) =
(s0 -[]-> s0 {(pressEvent ! (1))}) .
It is worth noticing that the deactivated attribute was not defined in the
above equations, since it is impossible to see from only the definition of the thread
type and implementation whether or not a thread is initially deactivated. This
is due to the fact that deactivation may follow from mode-specific components
much higher in the containment hierarchy. A function initializeThreads is
therefore applied to fully define the initial state by defining the initial deactivated
value for each thread object.
Dynamics. This section formalizes the operational semantics of AADL in Real-
Time Maude. Unavoidably, since AADL does not have a precise semantics, our
semantic definitions are a formal semantics for AADL and involve an interpretation
of what the informal and sometimes ambiguous descriptions in the standard
mean. The dynamics is defined by equations and rewrite rules specifying:

– “message” transportation,
– mode switches,
– thread dispatch,
– thread execution,
– nondeterministically assigning values to a set of variables, given a value
constraint, and
– timed behavior.
Message Passing. In the spirit of the “traditional” Maude model for message
transmission — where message transmission from source to destination is abstractly
modeled by the state having a multiset structure — we use equations to
model the transmission of messages from source port to destination port along
a series of connections.
To transmit a list ML of messages (that is, events and/or data), an out port
puts transfer(ML) into its buffer. The following equation models the transmission
of a message list along a level-up connection C1 . P1 --> P from the out
port P1 of the subcomponent C1 to the out port P of the supercomponent C. As
a result of applying the equation, the port P now has the value transfer(ML),
and the subcomponent’s port buffer is empty:
op transfer : MsgList -> MsgList [ctor] .
vars C C1 C2 : ComponentId . vars P P1 P2 : PortId .
vars PORTS PORTS2 OTHER-COMPONENTS : Configuration .
vars ML ML’ : MsgList . var CONXS : ConnectionSet .
eq < C : Component |
features : < P : OutPort | buffer : nil > PORTS,
subcomponents :
< C1 : Component |
features : < P1 : OutPort | buffer : transfer(ML) > PORTS2 >
OTHER-COMPONENTS,
connections : (C1 . P1 --> P) ; CONXS >
=
< C : Component |
features : < P : OutPort | buffer : transfer(ML) > PORTS,
subcomponents :
< C1 : Component | features : < P1 : OutPort | buffer : nil > PORTS2 >
OTHER-COMPONENTS > .
The following equation models the transmission of a message list following a
same-level connection between the two subcomponents C1 and C2:
eq < C : Component |
subcomponents :
< C1 : Component |
features : < P1 : OutPort | buffer : transfer(ML) > PORTS >
< C2 : Component |
features : < P2 : InPort | buffer : nil > PORTS2 >
21

22
OTHER-COMPONENTS,
connections : (C1 . P1 --> C2 . P2) ; CONXS >
=
< C : Component |
subcomponents :
< C1 : Component |
features : < P1 : OutPort | buffer : nil > PORTS >
< C2 : Component |
features : < P2 : InPort | buffer : transfer(ML) > PORTS2 >
OTHER-COMPONENTS > .
This is a somewhat simplified version of the equations we actually use, since we
also allow 1-to-n same-level connections as well as mode-specific connections.
Finally, the following equation models the transmission of a list of messages
along a level-down connection. It is similar to a level-up connection, the only
difference being that the destination may already have some buffer contents;
therefore, the list to be transferred is just appended to the buffer of the destination
port:
eq < C : Component |
features :
< P : InPort | buffer : transfer(ML) > PORTS,
subcomponents :
< C1 : Component | features : < P1 : InPort | buffer : ML’ > PORTS2 >
OTHER-COMPONENTS,
connections : (P --> C1 . P1) ; CONXS >
=
< C : Component |
features : < P : InPort | buffer : nil > PORTS,
subcomponents :
< C1 : Component | features : < P1 : InPort | buffer : ML’ :: transfer(ML) >
PORTS2 >
OTHER-COMPONENTS > .
Thread Status and Mode Switches. The execution status of a thread can be any
of the following:
Active: The thread is ready to execute a state transition.
Completed: The thread has completed its execution in this dispatch and waits
for its next dispatch.
Sleeping: The thread is suspended, and will resume execution after a given
amount of time.
Inactive: The thread is not part of the “active” mode of the system.
A mode switch has the effect of deactivating and activating threads to respond
to dispatches. A thread becomes inactive as the result of a mode change
if it is not part of the new mode. An inactive thread cannot be dispatched for
execution. An inactive thread can be activated as the result of a mode change,
in which case the thread enters the completed status, from where it can respond

to future dispatches. When a thread in the completed status receives a dispatch
request, the thread enters the active status to perform the computation. Upon
successful completion of the computation, the thread returns to the completed
status. Once an active thread executes a delay action, it enters the sleeping status,
suspends for a period of time, and becomes active after that time period.
Mode switch is modeled by the following rewrite rule:
rl [modeSwitch] :
< C : Component |
features :
(< P : InEventPort | buffer : transfer(ML) :: ML’ > PORTS),
modes : current: MN1
transitions: (MN1 -[P , PIS]-> MN2 ) ; MTSET,
subcomponents : SUBCOMPONENTS >
=>
< C : Component |
features : (< P : InEventPort | buffer : nil > PORTS),
modes : current: MN2 transitions: (MN1 -[P , PIS]-> MN2) ; MTSET,
subcomponents : modeSwitch(SUBCOMPONENTS, MN1, MN2) > .
where the modeSwitch operation propagates the mode switch request to the
subcomponents (by setting deactivated to true for the other threads to be
suspended; and vice versa for the threads that should be activated).
Thread Dispatch and Execution. Under a periodic dispatch protocol, a thread
in completed status is dispatched when the “dispatch timer,” i.e., the second
parameter T’ in the term periodic-dispatch(T,T’), is 0. As a result, the
thread is dispatched, that is, its status is set to active, the “timer” is reset to
the length T of a period, and the input ports are “dispatched” as well:
crl [periodic-dispatch] :
< O : Thread | properties : periodic-dispatch(T, 0 ) ; TP,
status : completed,
features : PORTS >
=>
< O : Thread | properties : periodic-dispatch(T, T) ; TP,
status : active ,
features : dispatchInputPorts(PORTS) >
if not environmentThread(TP) .
Likewise, when the dispatch protocol is aperiodic, and new events have arrived
in some of the thread’s input ports (that is, some of the messages in the
port buffer have the wrapper transfer), and the thread is in completed status,
then the thread is activated: 6
6 In our AADL subset, we assume that any arriving event may dispatch an aperiodic
thread.
23

24
rl [aperiodic-incoming-message] :
< O : Thread | properties : aperiodic-dispatch PROPS,
features :
(< P : InEventThreadPort | buffer : ML :: transfer(ML’) >
PORTS),
status : completed >
=>
< O : Thread | features :
dispatchInputPorts(
< P : InEventThreadPort | buffer : ML :: ML’ > PORTS),
status : active > .
The next rule specifies the execution of an active thread. If the thread is
in state L1, and there is some transition from L1 whose guard evaluates to
true, then the transition is executed. The resulting status is sleeping(...)
if some of the actions in the statement list SL are delay statements, the thread
is completed or suspended if the resulting state L2 is a complete state, and
remains active otherwise:
crl [execute-transition] :
< O : Thread | status : active ,
deactivated : false,
features : PORTS,
behavior : states (current: L1 ) LDS state variables VAL,
threadType : TN, implementationType : IMPL >
=>
< O : Thread | status : NEW-STATUS,
features : (if NEW-STATUS == completed
then transferData(NEW-PORTS)
else NEW-PORTS fi),
behavior : states (current: L2 ) LDS
state variables NEW-VALUATION >
if not environmentThread(TP)
/\ ((L1 -[ GUARD ]-> L2 {SL}) ; TRANSITIONS) := transitions(TN, IMPL)
/\ evalGuard(GUARD, dispatchInputPorts(PORTS), VAL)
/\ transResult(NEW-PORTS, NEW-VALUATION, SLEEP-TIME) :=
executeTransition(L1 -[ GUARD ]-> L2 SL, dispatchInputPorts(PORTS), VAL)
/\ SLEEP := SLEEP-TIME > 0
/\ NEW-STATUS := if SLEEP then sleeping(SLEEP-TIME)
else (if completeState(L2,LDS) then
completed else active fi) fi .
The function executeTransition executes a given transition in a state with a
given set PORTS of ports and assignment VAL of the state variables. Its definition
is straight-forward. The function returns a triple transResult(p, σ, t), where p
is the state of the ports after the execution, σ is the resulting values of the state
variables, and t is the sum of the delays in the transition actions. The transitions
are modeled as a multiset of single transitions; therefore, any of the enabled
transitions can be nondeterministically selected in the matching condition

((L1 -[ GUARD ]-> L2 {SL}) ; TRANSITIONS) := transitions(TN, IMPL)
in the above rule.
The following rule models the behavior of a sleeping thread when the remaining
sleeping time is 0. The thread becomes active, completed, or suspended
depending on whether or not its current state is a complete state and, if so,
whether it should deactivate itself as a result of an earlier mode switch:
rl [finish-sleep] :
< O : Thread | status : sleeping(0) ,
deactivated : B,
behavior : states current: L LDS state variables VAL >
=>
< O : Thread | status : (if not completeState(L, LDS) then active else
(if B then inactive else completed fi) fi) > .
Value Constraints. Consider again an “environment” thread which is supposed
to nondeterministically generate n boolean values b1, . . . , bn, satisfying a constraint
ϕ(b1, . . . , bn), for its n boolean state variables.
A straight-forward solution is to initialize each bi to some “uninitialized”
value, and then have two rules which assign an uninitialized boolean variable
the values true and false, respectively. However, since the number of Boolean
vectors is exponential on the number of Boolean variables, this can quickly become
too inefficient, since it will generate too many assignments which do not
satisfy ϕ. We instead take advantage of Maude SAT solving features to easily
define a function
op allAssignments : Valuation BoolExpression -> ValuationSet [memo] .
to generate the set of all possible variable assignments satisfying ϕ, and then
have a rule that can nondeterministically select any of these assignments.
In our model, the sort Valuation defines a variable map. Sets of such variable
maps can then be defined using an associative and commutative set union
operator _;;_:
subsort Valuation < ValuationSet .
op emptyVS : -> ValuationSet [ctor] .
op _;;_ : ValuationSet ValuationSet -> ValuationSet
[ctor assoc comm id: emptyVS] .
eq VAL ;; VAL = VAL .
Now, whenever an environment thread is dispatched, the environment should
reset its (Boolean) variables nondeterministically so that the input constraint is
satisfied. In the following rule
vars VAL NEW-ASSIGNMENT : Valuation .
var VS : ValuationSet .
crl [env-periodic-dispatch] :
25

26
< O : Thread | properties : periodic-dispatch(T, 0 ) ; IsEnvironment(true) ;
InputConstraints(ϕ) ; TP,
status : completed ,
features : PORTS,
behavior : states LDS state variables VAL >
=>
< O : Thread | properties : periodic-dispatch(T, T ) ;
IsEnvironment(true) ; InputConstraints(ϕ) ; TP,
status : active ,
features : dispatchInputPorts(PORTS),
behavior : states LDS
state variables NEW-ASSIGNMENT >
if NEW-ASSIGNMENT ;; VS := allAssignments(initializeToFalse(VAL), ϕ) .
the variable NEW-ASSIGNMENT can match any of the maps defined by allAssignments(...,ϕ).
The point is that such an assignment should be done each time a thread is dispatched,
that is, each time the thread goes from completed to active.
We have implemented this technique, and it has given us improved performance
in the avionics case study reported in Section 4. For further efficiency:
– The set of all legal assigments is not stored in the states; instead the function
allAssignments is called each time a new variable assignment is selected.
– The frequently called function allAssignments is declared to have the attribute
memo, so that the results of its computations are memorized by Maude
(see [4]). Therefore, after the first computation of allAssignments(V,ϕ)
each subsequent “computation” of allAssignments(V,ϕ) takes time O(1).
Time Behavior. Following the specification techniques proposed in [14], we
model time elapse in the system by a single tick rule
vars T T’ T’’ : Time . vars SYSTEM C C’ PORTS : Configuration .
var S : SystemId . var THR : ThreadId .
var P : PortId . var PROPS : Properties .
var TS : ThreadStatus . vars ML ML’ ML’’ : MsgList .
crl {SYSTEM} => {delta(SYSTEM, T)} in time T if T Configuration [frozen (1)] .
op mte : Configuration -> TimeInf [frozen (1)] .
and distribute over the elements in a (sub)configuration:

eq delta(none, T) = none .
ceq delta(C C’, T) = delta(C, T) delta(C’, T) if C =/= none and C’ =/= none .
eq mte(none) = INF .
ceq mte(C C’) = min(mte(C), mte(C’)) if C =/= none and C’ =/= none .
The important time behaviors that must be taken into account when defining
these functions are:
– Periodic threads must dispatch at the given time.
– Threads in sleep status must exit this status when their sleep time expires.
– Time must not elapse when there are “untreated” messages in the system,
since an aperiodic thread is dispatched when it receives a message. This
ensures that signals are treated instantaneously.
– Time cannot advance when a thread is in active state, as the thread should
execute a transition when it is active.
– Deactivated threads should not impact time behavior.
Time elapse therefore only affects the timer t in the periodic-dispatch(T,t)
property of a thread, and the timer t ′ in the sleeping(t ′ ) status of a thread,
both of which are reduced according to the elapsed time. The function delta
does not affect a System component, except by propagating to the subcomponents:
eq delta(< S : System | features : PORTS, subcomponents : C >, T) =
< S : System | features : PORTS, subcomponents : delta(C, T) > .
delta is defined in the same way for Process objects. For Thread objects, the
delta function must decrease the possible “timers” as described below, taking
into account the possibility that some of these “timers” are mode-specific
properties:
eq delta(< THR : Thread | deactivated : false, subcomponents : C,
status : TS, modes : MTS, properties : TP >, T)
=
< THR : Thread | subcomponents : delta(C, T),
status : delta(TS, T),
properties : delta(TP, MTS, T) > .
op delta : ThreadStatus Time -> ThreadStatus .
eq delta(sleeping(T), T’) = sleeping(T monus T’) .
eq delta(TS, T’) = TS [owise] .
op delta : Properties ModeTransitionSystem Time -> Properties .
eq delta((periodic-dispatch(T, T’) ; TP), MTS, T’’) =
periodic-dispatch(T, T’ monus T’’ ) ; TP .
eq delta(((periodic-dispatch(T, T’) in modes (MN MNS)) ; TP),
current: MN transitions: MODETRANSES, T’’) =
(periodic-dispatch(T, T’ monus T’’) in modes (MN MNS)) ; TP .
27

28
eq delta((sporadic-dispatch(T, T’) ; TP), MTS, T’’) =
sporadic-dispatch(T, T’ monus T’’) ; TP .
eq delta(((sporadic-dispatch(T, T’) in modes (MN MNS)) ; TP),
current: MN transitions: MODETRANSES, T’’) =
(sporadic-dispatch(T, T’ monus T’’) in modes (MN MNS)) ; TP .
eq delta(TP, MTS, T) = TP [owise] .
As for the function mte, it does not affect System or Process objects, but
must ensure that mte is 0 when an “untreated” message list, that is, one of the
form transfer(ml), is present in some port buffer; in addition, it must ensure
that time cannot advance beyond the time at which a sleeping thread should
wake up, or beyond the time at which a periodic thread should dispatch. In
addition, time cannot advance when a thread is active:
eq mte(< S : System | features : PORTS, subcomponents : C >) =
min(mte(PORTS), mte(C)) .
eq mte(< THR : Thread | deactivated : B, features : PORTS, subcomponents : C,
status : TS, properties : TP, modes : MTS >)
=
if B then INF else min(mte(PORTS), mte(C), mte(TS), mte(TP, MTS)) fi .
eq mte(< P : Port | buffer : ML :: transfer(ML’) :: ML’’ >) = 0 .
eq mte(< P : Port | buffer : ML >) = INF [owise] .
op mte : ThreadStatus -> TimeInf .
eq mte(active) = 0 .
eq mte(completed) = INF .
eq mte(sleeping(T)) = T .
eq mte(inactive) = INF .
op mte : Properties ModeTransitionSystem -> TimeInf .
eq mte(periodic-dispatch(T, T’) ; TP, MTS) = T’ .
eq mte((periodic-dispatch(T, T’) in modes (MN MNS)) ; TP,
current: MN transitions: MODETRANSES) = T’ .
eq mte(TP, MTS) = INF [owise] .
3.3 Formal Analysis of AADL Models in Real-Time Maude
This section illustrates how the Real-Time Maude module corresponding to an
AADL model can be formally analyzed. In particular, we present some helpful
functions allowing the user to define desired properties without having to
understand the details of the Real-Time Maude representation of an AADL
component.
Defining Initial States. An AADL system definition declares a template for
the component. An initial state is an instance of such a template. For example,

in our medical example, assuming that MAIN is a constant of sort SystemId of
System object names, a typical initial state is
initializeThreads({MAIN system Wholesys . impl})
A first form of formal analysis consists of simulating one of the many possible
system behaviors up to a given duration using timed rewriting: 7
Maude> (tfrew initializeThreads({MAIN system Wholesys . impl}) in time < 20 .)
Reachability Analysis. Real-Time Maude’s tsearch, respectively utsearch,
command can be used to analyze whether or not a state matching a given pattern
and satisfying a given condition pattern can be reached from a given initial state
within a given time interval, respectively without any time limit.
Defining the appropriate state pattern in general requires understanding the
Real-Time Maude representation of the AADL component being analyzed. To
avoid requiring the user of our tool to know this Real-Time Maude representation,
our tool defines some useful functions. The term
value of v in component fullComponentName in globalComponent
returns the value of the state variable v in the thread identified by the full
component name fullComponentName in the system in state globalComponent.
The full component name is defined as a ->-separated path of component names,
from the outermost to the innermost. Likewise, the term
location of component fullComponentName in globalComponent
gives the current location/state in the transition system in the given thread. We
have also defined useful functions for extracting the contents of port buffers, as
well as the content of a thread’s internal port buffer, by way of two functions
getBuffer and getInternalBuffer.
Example 2. In our medical devices example, the thread MAIN -> XRayMachine
-> xmPr -> xmTh denotes the full component name of the xmTh thread component,
and the term
location of component (MAIN -> XRayMachine -> xmPr -> xmTh)
in (MAIN system Wholesys . impl)
equals the current location (or “state”) in the thread xmTh in the (initial) state
(MAIN system Wholesys . impl).
The system of medical devices described in Section 3.1 is supposed to achieve
that the ventilator machine is pausing when an X-ray is being taken, so that the
7 Since the targeted fragment of AADL is time-deterministic, our tool has predefined
the time sampling strategy to be the maximal strategy that advances time as much
as possible in each application of the tick rule (see [14] for details).
29

30
X-ray is not blurred. The following Real-Time Maude time-bounded search command
analyzes this property by checking whether an undesired state, namely
one where the X-ray device thread xmTh is in state xray while the ventilator
thread vmTh is not in state paused, can be reached from the initial state
{MAIN system Wholesys . impl} in less than 4 time units:
Maude> (tsearch
initializeThreads({MAIN system Wholesys . impl}) =>* {C:Configuration}
such that
((location of component (MAIN -> XRayMachine -> xmPr -> xmTh)
in C:Configuration) == xray
and
(location of component
(MAIN -> VentilatorMachine -> vmPr -> vmTh)
in C:Configuration) =/= paused)
in time < 4 .)
LTL Model Checking. As already mentioned in Section 2.2, Real-Time Maude
is equipped with an explicit-state linear termporal logic (LTL) model checker
that analyzes whether all behaviors (possibly up to a given duration) from the
initial state satisfy an LTL formula. Again, we have pre-defined useful atomic
propositions, such as getBuffer(full port name), getInternalBuffer(full port
name), and full thread name @ location. The latter holds when the thread is in
state location and is defined as follows:
op _@_ : EComponentId Location -> Prop [ctor] .
var SYSTEM : Configuration . var ECI : EComponentId . var L : Location .
eq SYSTEM |= (ECI @ L) = ((location of component ECI in SYSTEM) == L) .
Example 3. We can use the LTL model checker to analyze two desired properties
of our medical system:
1. The ventilation machine must be pausing when an X-ray is being taken.
2. Since the button is pushed at time 0, an X-ray should be taken within three
seconds of the start of the system.
The first property, which has already been subjected to reachability analysis,
can be model checked by the following untimed model checking command:
Maude> (mc initializeThreads({MAIN system Wholesys . impl}) |=u
[] (((MAIN -> XRayMachine -> xmPr -> xmTh) @ xray)
->
((MAIN -> VentilatorMachine -> vmPr -> vmTh) @ paused)) .)
The second requirement amounts to checking the time-bounded liveness property
that the xmTh thread will always reach its xray state within 3 time units:
Maude> (mc initializeThreads({MAIN system Wholesys . impl}) |=t
((MAIN -> XRayMachine -> xmPr -> xmTh) @ xray) in time

Surprisingly, this latter model checking command returned a counterexample
demonstrating that the expected property does not hold for all behaviors from
the initial state. Analyzing the counterexample revealed a previously unknown
faulty behavior, where, due to some subtle timer issues, the X-ray machine thinks
that it has already taken an X-ray even though it is only waiting to take an X-ray.
3.4 The AADL2Maude Tool
The above semantics of AADL has been automated in the AADL2Maude tool.
AADL2Maude is an OSATE plug-in that uses OSATE’s code generation facility
to automatically generate Real-Time Maude specifications from AADL models.
The executable, formal semantics of AADL models has been integrated into
the OSATE environment, enabling techniques for verifying critical properties
over AADL specifications. An AADL specification is usually defined in OSATE
in either textual or graphical format. The abstract syntax of AADL and of
its Behavioral Annex are defined as MOF metamodels. OSATE parses AADL
specifications and obtains AADL models, which conform to the metamodels
above, that represent their abstract syntax trees.
Our tool adds a model compiler to OSATE as a plugin that, given an AADL
specification, automatically generates a formal, executable, Real-Time Maude
model corresponding exactly to its rewrting logic semantics. This is obtained by
means of the function mapping the model MAADL to a real-time rewrite theory
MAADL. The function has been implemented using OSATE’s traversal
mechanisms mapping each object in an AADL model to an element of a Real-
Time Maude theory as explained in Section 3.2. Our approach allows an AADL
modeler to work with AADL models as mathematical entities within the OSATE
environment itself, thus enhancing the application of the analysis techniques supported
in Real-Time Maude.
4 An Active Standby System Example
In order to further illustrate how AADL design can benefit from Maude-based
formal analysis using the AADL2Maude tool chain, we give an overview of the
verification of another example, an Active Standby system for deciding which
of two computer systems is active in an aircraft. This model is an AADL variant
developed by Abdullah Al-Nayeem of a similar active standby specification
by Steve Miller and Darren Cofer from Rockwell-Collins. This example and its
properties is also discussed in [11].
4.1 The Active Standby System
The Active Standby system is a simplified example of a fault-tolerant Avionics
system. In integrated modular avionics (IMA), a cabinet is a chassis with a power
supply, internal bus, and general purpose computing, I/O, and memory cards.
Aircraft applications are implemented using the resources in the cabinets. There
31

32
are always two or more cabinets that are physically separated on the aircraft so
that physical damage (e.g., an explosion) doesn’t take out the computer system.
The Active Standby system considers the case of two cabinets and focuses on
the logic of deciding which side is active. While one side is active, the other side
remains passive. The two sides receive inputs through communication channels.
Each side could fail, but it is assumed that both sides cannot fail at the same
time. A failed side can recover after failure. In case one side fails, the nonfailed
side should be the active side. In addition, the user/pilot can toggle the
active status of these sides. Each side is dependent on other system components.
In this example, the full functionality of each side is dependent on these two
sides’ perception of the availability of these system components. Only a fully
functional/available side should be active, while the other side is alive but not
fully functional. Each side monitors the status of other side and acts upon the
monitored result.
Important properties that the Active Standby system should satisfy include:
R1: Both sides should agree on which side is active (provided neither side has
failed, the availability of a side has not changed, and the pilot has not made
a manual selection).
R2: A side that is not fully available should not be the active side if the other
side is fully available (again, provided neither side has failed, the availability
of a side has not changed, and the pilot has not made a manual selection).
R3: The pilot can always change the active side (except if a side is failed or the
availability of a side has changed).
R4: If a side is failed the other side should become active.
R5: The active side should not change unless the availability of a side changes,
the failed status of a side changes, or manual selection is selected by the
pilot.
4.2 AADL Model of the Active Standby System
As already mentioned, the Active Standby system has been modeled in AADL
by Abdullah Al-Nayeem. The architecture of the system is shown in Figure 1.
The top-level system specification consists of three AADL system components:
Side1, Side2, and Environment. Side1 and Side2 encapsulate the behaviors of
the two sides. The Environment component can be considered as an abstract
representation of other non-specified components that interact with Side1 and
Side2. The behavior of each component is defined by a periodic thread.
The AADL design of the Active Standby system is globally synchronous;
i.e., all threads inside Side1, Side2, and Environment have the same period and
dispatch at the same time. These three components are wrapped in a system
component ActiveStandbySystem.
Each time the thread inside Environment dispatches, it sends 5 boolean values,
one through each of its out ports shown in Figure 1. These values are
nondeterministically generated, with the constraints that two sides cannot fail

side1Failed
Side1
side1FullyAvail
Environment
manualSelection
side1ActiveSide
mon1Side1FullyAvail
mon1Side2FullyAvail
side2ActiveSide
mon2Side1FullyAvail
mon2Side2FullyAvail
side2FullyAvail
Side2
Fig. 1. Architecture of the Active Standby system in AADL
side2Failed
at the same time, and that the failed side cannot be fully available. These assumptions
are specified in AADL as a value constraint property in the thread
inside Environment:
PalsProperties::ValueConstraints =>
"not s1F and s2F and not s2FA or not s2F and
s1F and not s1FA or not s1F and not s2F";
4.3 Applying the PALS Philosophy to the Active Standby AADL
Model
The above-described AADL model of the active standby system is not really
synchronous. It is instead an asynchronous model. This is due to semantics
of AADL models, since in an AADL model consisting of several threads, each
individual thread can perform transitions on its own, leading to an asynchronous
and highly concurrent behavior, and therefore to a big state space explosion.
Therefore, in a sense the AADL model of the active standby system is halfway
between the intended synchronous system and the AADL model resulting from
applying the PALS pattern, which is even more complex and of course also
asynchronus.
In our own experiments model checking the above, really asynchronous model,
we run into a performance barrier both in time and space. It was possible to perform
bounded model checking analyses of the model for modest depth bounds,
33

34
but full model checking analysis was unfeasible. As a sanity check, we also specified
directly in Real-Time Maude a, still asynchronous, version of the active
standby system. We were able to fully verify all the safety requirements of this
Real-Time Maude model in less than a minute. The difference with the performance
barriers for the similar AADL version of the model was that, in addition
to the asynchrony shared by both models, the AADL model (and therefore also
its Real-Time Maude translation) was considerably more complex, with the size
of a single AADL model state occupying about six printed pages. In reality,
each component is not just a single object, but a relatively large collection of
concurrent objects; since each of its gates is itself a nontrivial object containing
a buffer and additional state information.
All this means that we were really analyzing the wrong model to begin with,
because we were not taking advantage of the PALS methodology [11, 9]. Specifically,
as explained in detail in [9], the PALS transformation applies to any
ensemble E of state machines connected by a wiring diagram so that: (i) the
single state machine obtained as the synchronous composition of E, and (ii) the
asynchronous system obtained by applying to E the PALS transformation (for
given parameters of clock skew, local transition times, and maximum network
delay) are in fact bisimilar. In particular, both system saisfy the same temporal
logic properties [9], but is of course much easier to model check the synchronous
composition, while it is typically unfeasible to model check the corresponding
PALS-transformed system. This means that the right AADL model to analyze
for a given ensemble E is not its natural asynchronous version, where each machine
in E can perform transitions on its own, but instead the AADL model of
its synchronous composition.
For the active standby example, what this means is that we should specify the
AADL model corresponding to such a synchronous composition. This is exactly
what we did, allowing us to model check all the desired safety properties in a
few minutes as explained in what follows.
4.4 Formal Analysis of the Synchronous AADL Model
Taking the synchronous model of the Active Standby system in AADL as input,
the AADL2Maude tool chain automatically generates the corresponding Real-
Time Maude specification, a timed object-oriented module ACTIVE-STANDBY--
SYSTEM. Then the safety requirements for the Active Standby system are specified
and model checked in the MODEL-CHECK-ACTIVE-STANDBY module, which
also defines the initial state init:
(tomod MODEL-CHECK-ACTIVE-STANDBY is
including AADL-MODEL-CHECKER .
including ACTIVE-STANDBY-SYSTEM .
op init : -> GlobalSystem .
eq init = initializeThreads{MAIN system ActiveStandbySystem . impl} .
......
endtom)

We use temporal logic formulae to encode requirements R1 to R5. Due to the
globally synchronous design of Active Standby, we restrict our attention to the
stable state in each period. A state is stable if it is at the moment of dispatch.
The notion of a stable state is defined as an atomic proposition stable.
We likewise define the exact meaning of specialized words like active, failed,
and changed as atomic propositions. For example, the atomic proposition side1-
FullyAvailNow holds if and only if in the thread of Side1, the received message
stored in the internal buffer of the in port side1FullyAvail has value true:
var CONF : Configuration . var B : Bool .
ceq {CONF} |= side1FullyAvailNow = B
if B := boolFromPort(
MAIN -> sidesOneTwo -> sideProcess ->
sideThread -> side1FullyAvail, Conf ) .
ceq {CONF} |= side2FullyAvailNow = B
if B := boolFromPort(
MAIN -> sidesOneTwo -> sideProcess ->
SideThread -> side2FullyAvail, Conf ) .
We combine atomic propositions into more complex LTL formulae, such as
NoChangeAssumption, which defines the conditions under which both R1 and
R2 must hold:
op NoChangeAssumption : -> Prop .
eq NoChangeAssumption =
(Side1FullyAvailNow /\ Side2FullyAvailNow /\ NoChangeInAvailability /\
NoManualSelectionPressed /\ NeitherSideFailed /\ NeitherSideFailedNow) .
A more precise definition of requirement R1 is that, in a stable state where
no assumptions are changed, both sides must agree on active side either in the
current state or in the next stable state. This requirement can be formalized as
the following temporal logic formula R1:
op R1 : -> Formula .
eq R1 = [] ((NoChangeAssumption /\ Stable)
-> (AgreeOnActiveSide
\/ O ((~ Stable) U (Stable /\ AgreeOnActiveSide)))
Since the AADL2Maude tool chain automatically generates a Real-Time
Maude translation of an AADL model, we could inject formal analysis into
the AADL design process of Active Standby. Indeed, the synchronous Active
Standby system satisfies all five requirements, as shown by the following model
checking command, which took about six minutes to execute:
(mc init |=u (R1 /\ R2 /\ R3 /\ R4 /\ R5) .)
35

36
rewrites: 277333182 in 373655ms cpu (375661ms real) (742216 rewrites/second)
Result Bool :
true
This of course means that the AADL model for the PALS-transformed version
of this synchronous model of the active standby system will also satisfy the same
safety requirements, even though it is unfeasible to verify this fact directly by
model checking on the much more complex PALS-transformed version.
5 Related Work
The applications of formal methods to analyze AADL models can be divided
into two classes: analyzing schedulability of an architectural subset of AADL
where thread behavior is only characterized by dispatch protocol and execution
time [17, 6], and analyzing behaviors in behavioral subsets of AADL similar to
the one chosen in our work.
For analyzing behaviors of AADL models, the work reported in [2] is the
closest to ours. As similar subset of AADL is translated into an extension of
Petri nets. Their model checker selt can then be used to analyze abstractions
of AADL models, including their LTL properties. However, the paper does not
explain their semantics. The paper [7] also covers a similar subset of AADL,
except that thread behavior is not given by the behavioral annex, but is instead
given as a program in the synchronous language Lustre. In [1], the authors translate
a behavioral subset, minus mode switches, to IF, where they can analyze
safety properties of the system. The behaviors are, however, not expressed using
AADL’s behavioral annex, but their own behavioral language. In [18], a smaller
subset (periodic threads, no modes) is translated to timed abstract state machines,
and model checking in the timed automaton tool Uppaal is suggested
to verify timing properties.
6 Conclusions
AADL’s current lacks of a formal semantics and of executability are two severe
limitations, particularly for certifiable safety-critical embedded systems. In this
work we solve these two problems for a substantial subset of AADL by providing
a formal rewriting semantics of it in Real-Time Maude, and by deriving
from this semantics a tool, AADL2Maude, that connects the OSATE AADL tool
with Real-Time Maude and supports simulation, reachability, and LTL model
checking analyses of AADL models in this subset. Furthermore, we have illustrated
the use of AADL2Maude with two case studies, one of safe medical device
interoperation, and another on safety of an avionics system.
Our experience is quite encouraging, but much work remains ahead. Increasingly
larger AADL subsets should be given a formal rewriting logic semantics to
achieve the goal of giving a formal semantics to the entire AADL standard and

having simulation and formal analysis tools for AADL based on such a semantics.
Also, further experimentation to extend and perfect our approach should
be carried out. We also plan to extend the facilities described in this paper to
make it easy for users to specify formal properties of AADL models into an
AADL “formal property annex,” so that such properties can be expressed solely
in terms of the given AADL model.
References
1. Abdoul, T., Champeau, J., Dhaussy, P., Pillain, P.Y., Roger, J.C.: AADL execution
semantics transformation for formal verification. In: ICECCS’08. IEEE (2008)
2. Berthomieu, B., Bodeveix, J.P., Chaudet, C., Dal-Zilio, S., Filali, M., Vernadat,
F.: Formal verification of AADL specifications in the Topcased environment. In:
Ada-Europe’09. LNCS, vol. 5570. Springer (2009)
3. Clavel, M., Durán, F., Eker, S., Lincoln, P., Martí-Oliet, N., Meseguer, J., Talcott,
C.: Maude Manual (Version 2.3) (January 2007), http://maude.cs.uiuc.edu
4. Clavel, M., Durán, F., Eker, S., Lincoln, P., Mart-Oliet, N., Meseguer, J., Talcott,
C.: All About Maude - A High-Performance Logical Framework, LNCS, vol. 4350.
Springer (2007)
5. França, R., Bodeveix, J.P., Filali, M., Rolland, J.F., Chemouil, D., Thomas, D.:
The AADL behaviour annex - experiments and roadmap. In: ICECCS. IEEE (2007)
6. Gui, S., Luo, L., Li, Y., Wang, L.: Formal schedulability analysis and simulation
for AADL. In: ICESS’08. IEEE (2008)
7. Jahier, E., Halbwachs, N., Raymond, P., Nicollin, X., Lesens, D.: Virtual execution
of AADL models via a translation into synchronous programs. In: Proc.
EMSOFT’07. ACM (2007)
8. Meseguer, J.: Membership algebra as a logical framework for equational specification.
In: Parisi-Presicce, F. (ed.) Proc. WADT’97. LNCS, vol. 1376, pp. 18–61.
Springer (1998)
9. Meseguer, J., Ölveczky, P.C.: Formalization and correctness of the PALS pattern
for asynchronous real-time systems. Tech. rep., CS Dept. University of
Illinois at Urbana-Champaign (2009), cS Tech. Rep. 2009-11-12. Available at
https://www.ideals.illinois.edu/handle/2142/10762
10. Meseguer, J., Talcott, C.: Semantic models for distributed object reflection. In:
Proceedings of ECOOP’02, Málaga, Spain, June 2002. pp. 1–36. Springer LNCS
2374 (2002)
11. Miller, S., Cofer, D., Sha, L., Meseguer, J., Al-Nayeem, A.: Implementing logical
synchrony in integrated modular avionics. In: Proc. 28th Digital Avionics Systems
Conference. IEEE (2009)
12. Ölveczky, P.C., Meseguer, J.: Specification of real-time and hybrid systems in
rewriting logic. Theoretical Computer Science 285, 359–405 (2002)
13. Ölveczky, P.C., Meseguer, J.: Abstraction and completeness for Real-Time Maude.
Electronic Notes in Theoretical Computer Science 176(4), 5–27 (2007)
14. Ölveczky, P.C., Meseguer, J.: Semantics and pragmatics of Real-Time Maude.
Higher-Order and Symbolic Computation 20(1-2), 161–196 (2007)
15. SAE AADL Team: AADL homepage (2009), http://www.aadl.info/
16. SEA: Architecture Analysis & Design Language (AADL). AS5506A, Version 2.0,
SAE Aerospace (2009), http://www.sae.org/technical/standards/AS5506A
37

38
17. Sokolsky, O., Lee, I., Clarke, D.: Schedulability analysis of AADL models. In: Proc.
IPDPS’06. IEEE (2006)
18. Yang, Z., Hu, K., Ma, D., Pi, L.: Towards a formal semantics for the AADL behavior
annex. In: Proc. DATE’09. IEEE (2009)