Predictability by Construction

Innovative Collaborators

borations are sought As part of their relationship with the SEI, research
ive): partners provide the following:
uce scaled-up advanced • model problems or sample applications that can be
proofs of feasibility, and used as test cases or focal points for our research
data • funding, which is used to support research activities
reasoning frameworks and agreed to in advance with the partner and for which
ng frameworks. Near-term the partner will receive direct and indirect benefits
eas of security, safety and • optionally, personnel. The partner organization
or. may choose to have its own staff actively participate in
gy to software product lines, research activities.
corporate-standard Starter
onal variants of a product
or predictability
r automated, high-assurance
ponents and reasoning
ertifying components,
nd standard component and

mated design assistance,
tions to optimize
dictability zone for specific
offs among behaviors in

ical, time critical, and/or security critical? 21

22



“There are several opposing
‘forces’ at work in creating
a PECT. For example,
practitioners advocate enlarging
the construction framework
while reasoning framework
developers advocate constraining
it to ensure interpretability
and solvability. Co-refinement
can be thought of as a
managed, incremental
negotiation between these
opposing forces.”

Mark Klein

Mark Klein is a senior member of the technical staff at the
SEI. He has over 20 years of experience in research on
various facets of software engineering, dependable real-time
systems, and numerical methods. Mark’s most recent
work focuses on the analysis of software architectures,
architecture tradeoff analysis, attribute-driven architectural
design, and scheduling theory. Mark’s work in real-time
systems involved the development of rate monotonic analysis
(RMA), the extension of the theoretical basis for RMA, and
RMA’s application to realistic systems. Mark’s earliest work
involved research in high-order finite element methods for
solving fluid flow equations arising in oil reservoir simulation.
He is the co-author of A Practitioner’s Handbook for
Real-Time Analysis: Guide to Rate Monotonic Analysis for
Real-Time Systems and Evaluating Software Architecture:
Methods and Case Studies.

Competitive Edg

Our objectives apply to your business The PACC pedigree
The mission of the SEI is to advance the practice of The PACC work is the newes
software engineering. cal agenda of the SEI Produc
PACC builds on more establi
The SEI aims to research in software architectu
• accelerate the introduction and widespread use of high- lines. Both areas of research h
in following the SEI model o
payoff software engineering practices and technology widespread transition. Both a
by identifying, evaluating, and maturing promising or afforded early collaborators u
underused technology and practices business advantages. PACC w
• maintain a long-term competency in software engineer- advantages.
ing and technology transition
• enable industry and government organizations to make Software architecture technol
measured improvements in their software engineering area of the SEI since 1990. T
practices by working with them directly applied methods and techniq
• foster the adoption and sustained use of standards of use effective architecture-cent
excellence for software engineering practice development. The SEI Archit
Method® (ATAM®) is now an
Effective technology transition is paramount to achiev- software architecture evaluati
ing our mission. Each research agenda we undertake is “Views and Beyond” docume
pursued with the practitioner in mind. software architecture has give
create relevant and useful doc
Our research collaborators become early adopters of architectures. The SEI has pu
technology and methods that we are dedicated to SEI software architecture tech
transitioning into widespread practice. Our collaborators more than 50,000 copies to d
are in a unique position to influence the direction and the corporate technical training c
packaging of that technology. They ultimately become computer science department
community leaders in using high-payoff practices and instruction. Individuals from
technology that give them a competitive edge. have taken software architectu
in 2004.

ge for Early Adopters

st arm of the broader techni- The SEI is also a leader in software product lines. The SEI
ct Line Systems Program. provides the seminal product line reference model, the
ished but complementary SEI Framework for Software Product Line Practice SM, as well
ure and software product as proven product line methods and patterns that have been
have exemplary track records successfully used to achieve tenfold time-to-market decreases
of applied research and and cost decreases of 50 percent.
areas of research have
unique technical and Robert Bosch, the world’s second leading supplier of
will provide these same automotive technology, was an early collaborator with the
SEI on software architecture and software product lines.
logy has been a key research This relationship has been fruitful for both the SEI and
The SEI has developed and Bosch. SEI ATAM training was made available to the public
ques so that practitioners can in 2003. By this time, Bosch had already trained evaluators
and was using the ATAM routinely to surface architectural
tric practices in software risks early in the development life cycle. Likewise, Bosch has
tecture Tradeoff Analysis already experienced substantial advantages in piloting the
n internationally used Framework for Software Product Line Practice, such as one-
ion method. The SEI third savings in memory resource consumption and higher
entation approach for reuse potential than with their former reuse approach.
en practitioners a way to
cumentation for software The National Reconnaissance Office, another early SEI
ublished four books on product line collaborator, had already achieved a 50-percent
hnology that have sold reduction in its cost and schedule with its pioneer product
date and are used by major line effort before the SEI began to transition SEI product
centers and university line practices to the broader community.
ts for software architecture
m more than 160 companies PACC is representative of the most forward-leaning work at
ure courses at the SEI the SEI. We are looking for technology innovators to help us
develop the potential of predictable assembly.
23

24



Selected Techn

26

Overview of a Model Check
Reasoning Framework

28

Overview of a Performance
Reasoning Framework

30

Validating and Labeling
the Objective Confidence of
a Reasoning Framework

32

Overview of the Pin
Component Technology

34

Selected Publications

nical Details

king
e
f

25

Overview of a M

Sagar Chaki, James Ivers,
Natasha Sharygina, Kurt W

1. Introduction We address these issues by incor
Model checking is a powerful error detection technology that model checking research into a
has been successfully applied in the hardware industry. Model ComFoRT that allows nonexper
checking works by checking a model of a system against model checking for component-
behavioral claims (requirements) that should be true of the
model. Examples include claims that an actuator cannot move 2. State-of-the-Art Research
while the system is in a safe mode and that messages are never Model checking’s scaling issues
delivered to the wrong recipient. exhaustive analysis. The size of t
for a concurrent system is expon
Model checking goes far beyond conventional testing states and concurrent units; this
procedures in terms of coverage because it uses an algorithmic space explosion problem.
approach to exhaustively check every possible path through a
model of a system. All combinations of every thread interleav- Consequently, most model chec
ing, every point at which events could be received, and every reducing the number of states th
parameter value that an event or invocation could have is performing searches more efficie
examined.
The two principle approaches to
Moreover, while conventional testing only indicates whether a explosion are
system passes or fails a test, model checking provides feedback 1. abstraction: constructing sma
to help solve the problem. Whenever a claim does not hold, a
counterexample is reported detailing the execution path leading a claim is guaranteed to hold
to the problem. This information can be used to understand or also holds for the abstract mo
localize the cause(s) of the problem or to generate specific test 2. compositional reasoning: par
cases to reproduce the problem. a number of smaller models t
independently and proving sy
While model checking is used extensively in the hardware on the model checking result
industry, to date, successful applications to software have been
limited to small examples. Two obstacles to wider use are Our model checking reasoning
scalability and the degree of expertise needed to successfully research from both approaches,
apply model checking. real software systems. A brief ov
algorithms used is provided belo

26

Model Checking Reasoning Framework

Wallnau

rporating state-of-the-art 2.1 Automated Predicate Abstraction
reasoning framework called Predicate abstraction is used to systematically generate a
rts to gain the benefits of smaller, abstract model from the original, complete model.
-based software. It maps concrete data types to abstract data types through
predicates over the concrete data. For example, reducing a
h 32-bit integer to 3 predicates: i < 0, i == 0, and i > 0.
arise from its strength—
the complete state space The automated abstraction techniques used in ComFoRT
nential in the number of make use of the predicates found within the original model
s is known as the state (e.g., loop and branch conditions) to determine the set of
predicates to be applied.

cking research is focused on Model checking such abstract models is considerably easier and
hat must be searched or is a safe operation because the abstract model preserves the
ently. complete model’s behavior. Each abstraction is proven to be a
conservative abstraction (using automated decision proce-
o dealing with state space dures), meaning that if a claim holds for the abstract model, it
must also hold for the complete model.
aller abstract models such that
for the concrete model if it 2.2 Compositional CEGAR Framework
odel However, if a claim does not hold for the abstract model, that
rtitioning a model into does not necessarily mean that it does not hold for the
that can be checked complete system. Consequently, each counterexample must be
ystem correctness based checked to determine whether it is spurious (a result of the
ts for the submodels abstraction), and if so, model checking must be repeated with a
less abstract model.
framework draws on current
combining them to address
verview of some of the specific
ow.

Complete Predicate Abstract Model ϕ true 2.3 State/Event-Based Formalism
model Abstraction model Checking In model checking, behavioral c
using temporal logics over state
Claim ϕ ϕ values or the current state) or co
(e.g., event arrival or function in
Counterexample to one form or the other is usua
software in which both concepts
Predicate Spurious Spurious? ϕ false often related.
Refinement Counterexample Counterexample
For example, to check whether a
Figure 1: CEGAR Framework actions when a sensor reports (an
a threshold (state), both concept
We use predicate abstraction in conjunction with a
counterexample-guided abstraction refinement (CEGAR) ComFoRT uses a state/event-bas
framework, shown in Figure 1, to discharge spurious claims to be naturally expressed
counterexamples. In the CEGAR framework, abstract A labeled Kripke structure (LKS
models are constructed and refined as needed, until model An LKS is a directed graph in w
checking is completed. atomic propositions and transiti
A state/event derivative of linear
Specifically, for a complete model C consisting of concur- express claims over the LKS.
rent units C1 … Cn, the algorithms that check whether a
claim ϕ holds for C use the following iterative process: Experiments have shown that th
1. abstract. Create a conservative abstract simplifies writing claims, but sho
efficiency. Without a state/event
model M = M1 || … || Mn. like our example, users have to a
2. verify. Check if a claim ϕ holds for M. If so, report additional information to captur
expressible in a state- or event-b
success and exit. Otherwise, let CE be a counterexample the state space explosion problem
that indicates where ϕ fails in M.
3. refine. Check if CE is a valid counterexample with respect 3. Packaged as a Reasoning
to C. If CE corresponds to a real behavior, report the Successful application of model
counterexample showing why ϕ does not hold • learning the specialized language
for C. If CE is spurious, refine M using CE to obtain a checker, many of which are bett
more precise abstract model and repeat from Step 1. description
• simplifying the model by hand t
Two important benefits of this approach include the in clever or unrealistic ways
following: • finding the right combination o
1. By starting with a small abstraction and incrementally successful model checking for a

adding details, state space explosion is delayed as
long as possible.
2. Steps 1 and 3 are both performed compositionally
(i.e., one concurrent unit at a time). Only Step 2
requires the construction of a composed state space,
and this composition always involves only the current
abstract models.

claims are typically expressed Much of this work can be automated and hidden from users,
information (e.g., variable particularly when incorporated in a reasoning framework
ommunication information and restricted to a particular problem domain (embedded
nvocation). But limiting claims controllers).
ally a bad fit for concurrent
s are significant and Figure 2 shows how the ComFoRT reasoning framework
is applied. Each step is described below.

a controller takes the right 1. Model 2. Interpretation
n event) a value that exceeds assemblies
ts are needed. and claims CCL Analysis
specification model
sed formalism that allows such
and efficiently verified. 5. Revise 3. Model
S) is used to represent models. model checking
which states are labeled with
ions are labeled with events. CCL Counter-
r temporal logic is used to counter- example
example

4. Reverse
interpretation

Figure 2: Applying the ComFoRT Reasoning Framework

his formalism not only 1. Users design their components and assemblies in a design
ows significant gains in language (e.g., CCL) and specify the claims to be checked.
t formalism, to check a claim
annotate their models with 2. The interpretation generates an analysis model from
re the concepts that are not the assembly.
based formalism, exacerbating
m. 3. Model checking is applied, determining whether each claim
holds. When a claim does not hold, a counterexample
g Framework is generated.
checking often involves
es used by a particular model 4. Reverse interpretation is applied to any counterexamples
ter suited to hardware to express them in terms of the assembly, rather than the
analysis model.
to improve tractability, often
5. Users examine any counterexamples and determine how to
of algorithms to permit modify their designs to solve any problems. Any modifica-
particular model and claim tions are then checked by returning to Step 2.

Steps 2-4 are fully automated, restricting the user’s attention to
where it belongs—designing the assembly, specifying the
behavioral claims that should hold, and deciding how to solve
any problems that are detected.

27

Overview of a P

Scott Hissam, Mark Klein,
Paulo Merson, Gabriel More

1. Introduction (or aperiodically—the terms are

Performance, or specifically timing behavior, is important to as periodically. This work entail
all systems. For some systems, meeting hard deadlines is theory for predicting the averag
critical. For other systems, missing deadlines occasionally in the context of a collection of
might be fine, but only if you can guarantee that the miss rate This new theory also imposes an
will not exceed a specified threshold. In many cases, average in particular, assemblies must m
latency is the performance measure of merit. Our ultimate goal sporadic servers.

is to have reasoning frameworks for each of these performance The sporadic server scheduling
measures. events with hard deadlines from

This overview provides a high-level summary of a reasoning stochastic events that also requir
framework that is suitable for predicting the average latency in The hallmark of a sporadic serve
control systems comprising a mix of periodic and aperiodic “virtual processor” within which
events. This reasoning framework is motivated by systems that processed and analyzed. For the
must handle aperiodic events without sacrificing the hard real- below, the two key parameters o
time deadlines of periodic processes. execution budget and replenishm
the execution time needed to ha

2. Background equal to the sporadic server’s exe

We began with a performance reasoning framework called 3. Empirical Analysis
λABA. λ is short for latency, and ABA is short for Average case, Our performance reasoning fram
with Blocking and allowing for Asynchrony. analysis via simulation with theo

λABA is built on a body of work known as Generalized Rate early simulations revealed an int
Monotonic Analysis (RMA), which offers the ability to latency as we varied some key pa

predict worst-case latency to ensure that hard deadlines are We simulated and analyzed a ve
met. λABA extends RMA to predict average latency. λABA us insight into a much more gen
was constrained to a set of component assemblies, the interpre- studied a single aperiodic stream
tation of which reduces to sequences of tasks (units of times governed by an exponenti
concurrency) initiated periodically using both synchronous services. This is known as an M
(e.g., call/return) and asynchronous (e.g., message passing)

communication. Recently, we relaxed the analytic constraints

on assemblies to also include those tasks initiated stochastically
28

Performance Reasoning Framework

eno

e used synonymously) as well The aperiodic events were processed under the control of a
ls developing a new analytic sporadic server. The assembly also had a single periodic stream of
ge latency of aperiodic events events. The sporadic server executed at the highest priority and
real-time periodic events. allowed the aperiodic events to execute whenever it had an available
nalytic constraints— budget. Aperiodic events also exploited any available idle time left
manage aperiodic events with over from the periodics, that is, background time.

algorithm protects periodic We examined how the average aperiodic latency (E[W])
m bursts of high-priority varied as a function of a period of the periodic task (Tp) and
the utilization of the periodic task (Up). The results are shown
re high-priority processing. in Figure 1.
er is that it provides a periodic
h aperiodic events can be E[W], Varying Tp and Up for Ta = 200
e analytic theory described 70
of a sporadic server are its
ment period. We assume that 60
andle an aperiodic event is
ecution budget. 50

mework combines empirical 40
oretical results. Some of our
teresting pattern of average E[W] 30
arameters.
20
ery simple situation that gave
neral class of problems. We 10
m of events with interarrival
ial distribution and constant 0 1
M/D/1 queuing problem. 0 0.5
Tp=10,000
Up Tp=100,000

Tp=10 Tp=1,000
Tp=250 Tp=500

Figure 1: Average Aperiodic Latency

Each curve represents a suite of simulations for which the periodic
task’s period was held constant and periodic utilization, Up, varied
from 0 to .95. The lowest curve had a periodic period, Tp, of 10
ms, and the highest curve had a periodic period of 100,000 ms.

Note that This more general formula is
• The curve for the smallest periodic period, Tp = 10, looks like a
4.3 Special Case of Continuous Ba
standard queuing curve; it became the target of our queuing Our next challenge was to unde
analysis. these two extremes. We chose to
• Curves for the smallest and largest periodic periods are bounds calling the continuous backgrou
for the other curves. server has exhausted its budget,
• All the curves nearly meet at the lowest and highest levels of execute is in background. For a
periodic utilization. smaller the period, the more con
available. An infinitesimal perio
4. Queuing Theoretic Analysis background.
The question was, “can we coerce” this problem into a standard
queuing theoretic framework? The key queuing result that we
draw on is the following formula:

The first term of the equation is the mean queuing time, which This has given us a great deal of
we will denote by E[Q]. E[S] is the mean aperiodic execution theoretic structure of this proble
time, and ρ is the mean service time divided by the mean processing is equivalent to being
aperiodic interarrival time. Therefore, the equation basically For example, when Up = .5, back
says that the mean latency is the mean queuing time plus the continuous case is equivalent to
mean service time: E[W] = E[Q] + E[S]. the speed of a full processor. If S
the aperiodic, the effective execu
4.1 Special Case of No Periodics background is Sa / (1-Up).
When the periodic utilization equals zero, it is as if there are no
periodics. In this case, the above formula is directly applicable. This equivalence to a degraded
interesting and illuminating spe
4.2 Special Case of No Background is the result that, from a queuin
When the periodic utilization is at its highest level, there is no effective execution whether the
background available for the aperiodic events to exploit. In this background or at a high priority
case, all aperiodic processing must be performed within the This means Sq in the previous fo
budget of the sporadic server. To aperiodic events in the queue, This observation allows us to an
it appears as if each event’s service time is equal to the sporadic in the continuous background c
server’s replenishment period. However, once an item starts
executing, it only takes its actual execution time to complete. The benefit of the sporadic serv
E[Ss]. Calculating this term requ
This dichotomy between the queuing and executing perspec- analysis. The key insight for calc
tives leads us to our first refinement of the standard queuing an aperiodic event is executed w
formula. To reflect this dichotomy in the queuing formula, we sometimes in the background an
denote the service time from the queuing perspective as Sq and of both.
from the server perspective as Ss.
To account for how much of eac
we needed to derive the probabi

ackground “time to next replenishment,” which determines how often each type
erstand the “curves” between contributes to E[Ss]. It turns out that the time to replenishment is
o study what we have been almost uniformly distributed over the interval [0, Tss], where Tss is
und case. When the sporadic the replenishment period. Given the density function for time to
replenish, Tr, the formula below can be used to calculate E[Ss].
the only way for aperiodics to
given periodic utilization, the The first term handles when an aperiodic event is executed within
ntinuously background is the sporadic server; the second term handles the remaining cases.
od results in a continuous Figure 2 compares our analytic prediction with simulation results for
time to replenishment.

0.150

f insight into the queuing Probability Density 0.010
em. In this case, background
g processed in a slower processor. 0.005
kground processing in the
o executing in a CPU that is half
Sa denotes the execution time of
ution when executing in

0.000

processor is what makes this an 0 20 40 60 80 100
ecial case. Even more interesting Time to Replenishment
ng perspective, Sa / (1-Up) is the
aperiodic executes in the Figure 2: Analytic Predictions Versus Simulation Results
y (within the sporadic server).
ormula is equal to Sa / (1-Up). Qualitatively, the prediction appears to be quite good. The shaded
nalytically predict queuing time bars are the predictions, and the 3-D bars are the simulation results.
case.
5. Where Are We Going?
ver comes from its impact on While our theoretical analysis is for a very special case, the combina-
uires a much more detailed tion of theoretical and empirical analysis gives us the capability of
culating E[Ss] is that sometimes analyzing a broad class of assemblies. Our ongoing work involves
within the sporadic server, generalizing the types of aperiodic streams we can analyze and
nd sometimes a combination exploiting a very recent development in queuing theory known as
real-time queuing theory (RTQT). RTQT offers the ability to
ch type of processing occurs, predict the probability of missing deadlines, which, in turn, allows
ility density function for the for reasoning about deadlines in a stochastic setting. Our current
capability augmented with the aforementioned enhancements will
allow us to develop PECTs for an extremely broad spectrum of
assemblies and a broad set of performance requirements.

29

Validating and L
Objective Confid

Gabriel Moreno, Paulo Merson
Scott Hissam, Kurt Wallnau

1. Empirical Validation functions over a range of values.
We establish objective and quantified confidence in the quality theories is likewise statistically d
of a reasoning framework’s analytic theory through empirical descriptors as statistical labels.
validation. Validation does not yield a simple pass/fail result,
however. Instead, it produces statistical evidence that can be 2.1 Component Labels
used to assess the likelihood that predicted assembly behavior Empirical theories may depend
will correspond to observed assembly behavior. Our goal is components. Two forms of statis
to establish a uniform set of statistical models and labels components: property estimator
for describing objective confidence in reasoning framework
predictions. 2.1.1 Estimator Labels
Ideally, the goal would be to kno
This overview describes the empirical validation approach used execution time (for some operat
on the λ* reasoning frameworks. Section 2 gives an overview true value is just a theoretical va
of statistical labels for components and reasoning frameworks. would result from an infinite num
Section 3 describes an automated validation process that uses measurand carried out under repe
constrained random sample (assembly) generation. systematic error. Obviously, it is n
We must therefore use a statistic
2. Statistical Labels
Analytic theories (of reasoning frameworks) that predict For example, we can take sample
quantifiable phenomena, such as time, space, and power, are their average –x as the estimator o
called empirical theories. Validating such theories requires with this estimator is expressed a
controlled observation and measurement. that the true value of μ will fall w
with some specified confidence.
Even the most accurate measurement instrumentation will coverage factor. Typically, we com
introduce error that must be accounted for. Empirical theories interval (i.e., k = 2).
may also abstract details, for example low-level caching
mechanisms, that introduce marginal but observable (appar- A confidence interval of compon
ent) nondeterministic behavior. For these reasons, the results of fundamental measure for λ* the
component and assembly measurements are described not as
discrete values, but in a statistical form, as probability density

30

Labeling the
dence of a Reasoning Framework

n,

. The effectiveness of empirical 2.1.2 Interval Labels
described. We refer to such Other kinds of component intervals are useful. A tolerance
interval for component execution time contains a specified
on empirical properties of proportion ρ of all executions of a component. For instance, a
stical labels are used for tolerance interval with ρ = 0.95 might state that 95% of a
rs and property intervals. component’s traces will have execution time X ± 17 ms, where
±17 ms is the computed tolerance interval.
ow the true value of component
tion of a component). However, Also useful is the confidence interval on the probability of
alue defined as the mean (μ) that satisfying a specified property requirement. In this case, we
mber of measurements of the same specify the execution time interval and use it to compute the
eatable conditions, assuming no probability that any trace will fall within this interval. For
not possible to obtain true value. example, we might specify the interval X ± 20 ms and use it to
cal estimator of true value. calculate a ρ = 0.64 probability that a given component trace
will fall within this interval.
e observations of X and use
of μ. The uncertainty associated 2.2 Analytic Theory Labels
Two forms of statistical labels are used for empirical theories:
as the standard deviation s such inferential and descriptive.
within some interval (–x ± k•s)
2.2.1 Inferential Labels
The factor k is known as the For empirical theories, we are usually interested in the
mpute the 0.95 confidence magnitude of relative error (MRE) between predicted and
observed values. For latency, we use MRE = |λ – λ′| / λ′,
nent execution time is a where λ is the predicted assembly latency and λ′ is the
eories. measured latency.

We use confidence and tolerance intervals to characterize how For λABA, we used Spearman ran
effective an analytic theory is likely to be for future predictions. distribution-free linear correlatio
We use one-tail intervals (or bounds) rather than two-tail means that the theory accounts
intervals, since we are generally only interested in knowing how the actual latency.
frequently predictions are worse than the mean MRE for
some sample. 3. Constrained Random Sam

Analogues to the confidence/tolerance intervals used for To construct a label for a proper
component properties are also used for analytic theories. require a representative set of ass
A confidence interval describes the probability that the MRE precise definition of this set? An
for a particular prediction will lie within a specified MRE from this set?
interval. Table 1 shows the tolerance interval for the
λABA member of λ*. The representative set of assemb
T is defined as the set of assembl
Part of Interval Description ΧT ∪ ΧC, with analytic constrai
Ν = 156 sample size constructive constraints ΧC imp
γ = 0.9929 confidence C. In practice, we are interested
ρ = 0.80 proportion subsets of SR:
• SL ⊆ SR of limit assemblies
• SA ⊆ SL of application assemblie

UB = 0.01 upper bound We might discover SL by subject
testing. Implementation details
Table 1: Statistical Label for λABA theory might have negligible im
encountered. For example, conte
The interpretation of the λABA label is that 80% of latency have negligible impact on predic
predictions have less than 1% MRE, and the interval is of tasks approaches the scheduli
constructed in a way that gives 99% confidence in this upper made explicit as constraints ΧL,
bound. to satisfy ΧL ∪ ΧT ∪ ΧC by con

2.2.2 Descriptive Labels We are likely to be interested in
Linear correlation is a descriptive statistic that describes the tive of the applications for which
strength of correlation between two data sets—for λ*, predicted example, the controllers in an in
and observed assembly latency. Linear analysis yields the subset of SL, and this subset may
coefficient of determination R2, 0 ≤ R2 ≤ 1, where 0 represents controllers found in electric grid
no relation and 1 represents a perfect linear relation. In a perfect use judgment sampling to define
prediction model, predicted and observed latency would be ΧA; SA satisfies ΧA ∪ ΧL ∪ ΧT ∪
identical; therefore, the goal for the model builder is a linear used for validation only; they ar
relation.

nk correlation, which is a For λABA, domain experts in substation automation defined ΧA
on. The resulting R2 = 0.998 to include the maximum number of event sources, compo-
for 99.8% of the variability in nents, and connections per component; the minimum and
maximum load factors; the minimum and maximum periods;
mpling the ratio of synchronous to asynchronous interactions; and an
rty theory such as λABA, we indication of whether harmonic periods are allowed.
semblies. But what is the
nd how do we choose a sample We use a library of components for synthetic execution from
which we automatically generate a sample S′A ⊂ SA. A suite of
blies SR of analytic theory tools controls how this sample is selected and generated. The
lies that satisfies the constraints tool suite and its associated measurement infrastructure are
ints ΧT imposed by T and described in publicly available SEI reports.
posed by component technology
in discovering one of two

es

ting a theory to destructive
that have been abstracted by a
mpact until certain extremes are
ext-switching overhead may
ctions until the execution time
ing quantum. These limits are
and assemblies SL will be made
nstruction.

only SA ⊂ SL that is representa-
h the theory will be used. For
ndustrial robot may be a small
y be different from the
d substation automation. We
e these additional constraints
∪ ΧC. The constraints ΧA are
re not enforced constructively.

31

Overview of the

Daniel Plakosh, Scott Hissa
James Ivers, Kurt Wallnau

1. Introduction 2. The Pin Component Mode
At the heart of every prediction-enabled component technol- A component model defines the
ogy (PECT) lies a kernel component technology. This kernel their assemblies, and the coordin
must be designed expressly to support predictability. In interact. The Pin component m
practice, this means strictly enforced patterns of component following goals in mind:
interaction and strictly defined runtime services and resource • simple programming model. Th
management policies. components and assemblies is k
generation and conformance ch
A key element of the Starter Kit is Pin, a canonical, kernel, • strict encapsulation. Implicit an
and adaptable component technology: mortal enemy of predictability.
• canonical: Pin is a minimal component technology for these interactions can be introdu
predictable assembly. Removing any feature will reduce its • pure composition. A declarative
effectiveness for embedded, safe, secure, time-critical systems composition allows alternative c
or make reliable prediction difficult or impractical. specified and enforced in a trans
• kernel: The Pin runtime environment provides real-time
services for concurrency, scheduling, and inter-component 2.1 Simple Programming Model
communication. It can execute as the highest priority task in Pin provides a standard compon
Windows CE/2K and can be rehosted easily to “bare” of the complexity typically assoc
hardware. development. Among other thin
• adaptable: Pin has plug-in interfaces for alternative inter- interaction of components with
component communication protocols and scheduling unique functionality of a compo
disciplines. Figure 1) is a plug-in to the core
to messages delivered on the cor
These characteristics combine with the minimal nature of introspection mechanism is also
Pin to enable a variety of application-specific customizations of to allow components and their c
Pin. We briefly describe the Pin component model in Section 2 Section 3) a limited form of run
and its runtime environment in Section 3.

32

e Pin Component Technology

am,

el Pin Component Component Ops
e structure of components and call . . . Generated
nation policies they use to
model was designed with the

he programmer’s view of Component Core call . . .
kept simple to facilitate code Standard Library
hecking.
nd hidden interactions are the Inter-component Standard component interface
Pin reduces the chances that communication plug-in Directory service plug-in
uced.
e style of component Figure 1: Module View of a Pin Component
coordination policies to be
sparent and uniform way. Each interface depicted in Figure 1 is standard, and the imple-
mentation of Ops is sufficiently stereotypical that automated
nent core that handles much code generation from design specifications is straightforward.
ciated with component In fact, code generation is the usual and preferred way we
ngs, the core manages the develop Pin components, although, on occasion, we combine
h their environment. The code generation and manual development. The code generator
onent (“Component Ops” in is designed with a mixed style of development in mind.
e that is invoked in response
re’s external interface. A basic 2.2 Strict Encapsulation
o provided (not shown) Pin imposes strict forms of encapsulation on component
controllers (discussed in developers. Components may only interact with their environ-
ntime configurability. ments through their Pin interface. As a first approximation
(but only that), the Pin interface comprises a set of inbound
(stimulus) and outbound (response) communication channels.
There are no hidden runtime communication paths; all
interactions of a component with the external world are
expressed as Pin interactions.

Stimulus Pin Component Ops Response “glue” code. The form of declara
(Sink) pins shared data (Source) pins sometimes referred to as connect
Threaded nents are said to be connected. In
reaction Reaction R1 Synchronous components is enabled when the
Non- private data Asynchronous nent is connected to the sink pin
threaded state machine Connectors may impose topolog
reaction pin conformance constraints.
Reaction R2
private data The value of pure composition i
state machine tion, although that has its advan
“glue” code may sometimes be n
Figure 2: A Closer Look at Component Ops encapsulated as a Pin componen
ment step in comparison with n
Internally (see Figure 2), a component is structured as one or
more reactions, each of which might or might not have its own Instead, the value of pure compo
thread of execution. The term reaction reflects the rule that Pin completely exposes the runt
components may not initiate activity on their own: they can components and those interactio
only respond (or react) to environment-provided stimuli. and the runtime environment. A
Reactions accept stimuli from one or more sink pins; each sink hidden from reasoning framewo
pin serves exactly one reaction. Reactions produce responses interaction as a first-class elemen
on zero or more source pins; each source pin serves at least one provides analytic leverage. For ex
reaction. Reactions may share component-scope data and can formalization of interaction poli
have their own reaction-scope data. Components may not reasoning frameworks. Alternati
share data (again, there are no communications beyond those can impose their own coordinati
expressed as interactions on pins). priority queuing semantics whic
implemented and enforced. The
2.3 Pure Composition tion all serve the end goal of pre
An intuition about pure composition in Pin may be obtained
from Figure 3, taken from an application of Pin to an electric 1SwMonSource
grid substation controller problem. The innermost boxes 2
depict Pin components, while the outermost box depicts an CLOCK 03
assembly of components. Note that Pin imposes coordination 4
and encapsulation schemes but does not impose a functional 5
decomposition scheme. For example, the components depicted
in Figure 3 conform to the Pin component model and also to 0
the functional (domain) model defined by the IEC-61850
standard for substation automation systems. 0 TCTR 1

Only components that have been composed may interact with 0 TVTR 1 0
one another. We say that composition is pure (or strict) if it 1
can be achieved declaratively and without recourse to custom
Figure 3: A Portion of a Pin IEC-6185

ative mechanism used in Pin is 3. The Pin Runtime Environment
tors, and composed compo- A component runtime environment provides an implementa-
nteraction among Pin tion of interaction mechanisms and other aspects of the
e source pin of one compo- component model. The Pin runtime has two main elements:
n of some other component. 1. The component runtime implements the Pin
gical constraints and pin-to-
component model.
is not iconic system integra- 2. The kernel runtime implements elements of a
ntages. Even with Pin, custom
needed, but it will be small-footprint real-time operating system (OS).
nt; this is an extra develop-
non-pure composition. The component runtime provides a container for deployed
assemblies: each deployed assembly executes in its own
osition lies in predictability: container called its controller. The controller is responsible for
time interactions among managing the life cycle of components in an assembly and for
ons between the components managing interactions with components in other, possibly
As a result, no interactions are distributed, assemblies. The controller provides support for
orks. Moreover, exposing error reporting and handling, and provides a primitive but
nt in system specification customizable (through code generation) fault model. Lastly, the
xample, it permits greater controller provides support for dynamic loading and unloading
icies that can be exploited by of components, although the current generation of Starter Kit
ively, reasoning frameworks reasoning frameworks assumes static topologies.
ion policies—for example,
ch can then be uniformly The kernel runtime provides the necessary primitives of a
ese aspects of pure composi- real-time OS for embedded applications. Unlike general OS
edictability by construction. kernels, the Pin kernel is tailor-made for component-based
development. The kernel runtime supports real-time timers,
threads, and synchronization; it also supports real-time message
queues that have been specifically adapted to closely mirror the
dynamic semantics of UML statecharts. As a result, the gap
between component-level behavior specifications and their
realization in the runtime environment is drastically reduced,
making analysis and code generation much simpler than would
otherwise be the case.

1

PIOC
2

MMXU 2

50 Switch Assembly

33

Selected Public

Starting points Hissam, S.; Moreno, G.; Stafford, J.;
Hissam, Scott; Hudak, John; Ivers, James; Klein, Mark; Larsson, Predictable Assembly,” 108-124. Pro
Magnus; Moreno, Gabriel; Northrop, Linda; Plakosh, Daniel; Stafford, IFIP/ACM Working Conference on Co
Judith; Wallnau, Kurt; & Wood, William. Predictable Assembly of (in Lecture Notes in Computer Scien
Substation Automation Systems: An Experiment Report, Second Edition Germany, June 20-21, 2002. Berlin,
(CMU/SEI-2002-TR-031, ADA418441). Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University, 2002. Moreno, G.; Hissam, S.; & Wallnau
www.sei.cmu.edu/publications/documents/02.reports/02tr031.html Empirical Component Properties an
Predictions: Toward Standard Labeli
Hissam, S.; Klein, M.; Lehoczky, J.; Merson, P.; Moreno, G.; 5th ICSE Workshop on Component-Ba
& Wallnau, K. Performance Property Theories for Predictable Assembly Orlando, Florida, May 19-20, 2002.
from Certifiable Components (PACC) (CMU/SEI-2004-TR-017). www.sei.cmu.edu/pacc/CBSE5/Moren
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, 2004. To be published. Stafford, J. & Hissam, S. The Softwa
Workshop on Predictable Assembly: La
Ivers, James & Sharygina, Natasha. Overview of ComFoRT: A Model Predictability (CMU/SEI-2003-TN-
Checking Reasoning Framework (CMU/SEI-2004-TN-018). Pittsburgh, Software Engineering Institute, Carn
PA: Software Engineering Institute, Carnegie Mellon University, 2004. www.sei.cmu.edu/publications/docum
www.sei.cmu.edu/publications/documents/04.reports/04tn018.html

Wallnau, K. Volume III: A Technology for Predictable Assembly from Stafford, J. & Wallnau, K. “Is Third
Certifiable Components (CMU/SEI-2003-TR-009, ADA413574). 13-17. Proceedings of the 4th ICSE W
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon Software Engineering. Toronto, Cana
University, 2003. Los Alamitos, CA: IEEE Computer
www.sei.cmu.edu/publications/documents/03.reports/03tr009.html
Wallnau, K. & Ivers, J. Snapshot of C
General material Assembly (CMU/SEI-2003-TN-025,
Bachmann, F.; Bass, L.; Buhman, C.; Comella-Dorda, S.; Long, F.; Software Engineering Institute, Carn
Robert, J.; Seacord, R.; & Wallnau, K. Volume II: Technical www.sei.cmu.edu/publications/docum
Concepts of Component-Based Software Engineering, Second Edition
(CMU/SEI-2000-TR-008, ADA379930). Pittsburgh, PA: Model checking reasoning framew
Software Engineering Institute, Carnegie Mellon University, 2000. Chaki, S.; Clarke, E.; Groce, A.; Ou
www.sei.cmu.edu/publications/documents/00.reports/00tr008.html & Yorav, K. “Efficient Verification of
C Programs.” To be published in the
Hissam, S. & Ivers, J. PECT Infrastructure: A Rough Sketch in System Design.
(CMU/SEI-2002-TN-033, ADA413548). Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University, 2002.
www.sei.cmu.edu/publications/documents/02.reports/02tn033.html

34

cations

; & Wallnau, K. “Packaging Chaki, S.; Clarke, E.; Ouaknine, J.; & Sharygina, N. “Automated,
oceedings of the First International Compositional and Iterative Deadlock Detection,” 201-210.
omponent Deployment (CD 2002) Proceedings of Formal Methods and Models for Codesign
nce [LNCS] volume 2370). Berlin, (MEMOCODE ’04). San Diego, CA, June 23-25, 2004. Madison,
, Germany: Springer-Verlag, 2002. WI: Omnipress, 2004.

u, K. “Statistical Models for Chaki, S.; Clarke, E.; Ouaknine, J.; Sharygina, N.; & Sinha, N.
nd Assembly-Level Property “State/Event-Based Software Model Checking,” 128-147. Integrated
ing.” Proceedings of the Formal Methods 4th International Conference (IFM 2004) (in Lecture
ased Software Engineering. Notes in Computer Science [LNCS] volume 2999). Canterbury, UK,
. April 4-7, 2004. New York, NY: Springer-Verlag, 2004.
no-cbse5-final.pdf
Clarke, E.; Grumberg, O.; & Peled, D. Model Checking.
are Engineering Institute’s Second Cambridge, MA: MIT Press, 1999.
andscape of Compositional
-029, ADA418396). Pittsburgh, PA: Ivers, J. & Wallnau, K. “Preserving Real Concurrency,” 15-22.
negie Mellon University, 2003. Correctness of Model-Based Software Composition (CMC) Proceedings,
ments/03.reports/03tn029.html done in association with the 17th European Conference on
Object-Oriented Programming (in Lecture Notes in Computer Science
Party Certification Necessary?” [LNCS] volume 2743). Darmstadt, Germany, July 21-25, 2003.
Workshop on Component-Based New York, NY: Springer-Verlag, 2003.
ada, May 14-15, 2001. www.ubka.uni-karlsruhe.de/v v v/ira/2003/13/13.pdf

Society, 2001. Performance reasoning framework material
Doytchinov, B.; Lehoczky, J.; & Shreve, S. “Real-Time Queues in
CCL: A Language for Predictable Heavy Traffic with Earliest-Deadline-First Queue Discipline.”
, ADA418453). Pittsburgh, PA: Annals of Applied Probability 11, 2 (2001): 332-378.
negie Mellon University, 2003.
ments/03.reports/03tn025.html Klein, M.; Ralya, T.; Pollak, B.; Obenza, R.; & Gonzalez Harbour, M.
A Practitioner’s Handbook for Real-Time Analysis. Boston, MA: Kluwer
work material Academic Publishers, 1993.
uaknine, J.; Strichman, D.;
f Sequential and Concurrent Kleinrock, Leonard. Queuing Systems, Volume 1: Theory.
e journal Formal Methods New York, NY: John Wiley and Sons, 1975.

Sprunt, B. Scheduling Sporadic and Aperiodic Events in a Hard Real-
Time System (CMU/SEI-89-TR-011, ADA211344). Pittsburgh, PA.
Software Engineering Institute, Carnegie Mellon University, 1989.
www.sei.cmu.edu/publications/documents/89.reports/89.tr.011.html

For more information about PACC, go to The Software Engineering Institute (
www.sei.cmu.edu/pacc/pacc_init.html operated by Carnegie Mellon Univer
the Department of Defense. As such,
For more information about becoming a following conditions apply:
PACC research partner, please contact
Copyrights
Linda Northrop Carnegie Mellon University SEI-auth
Director, Product Line Systems Program documents are sponsored by the U.S
Software Engineering Institute Department of Defense under Contra
4500 Fifth Avenue F19628-00-C-0003. Carnegie Mellon
Pittsburgh, PA 15213 retains a non-exclusive, royalty-free
to publish or reproduce these docum
Phone: 412-268-7638 allow others to do so, for U.S. gover
Fax: 412-268-5758 purposes only pursuant to the copyr
Email: [email protected] license under the contract clause at
7013.
For more information about the
Software Engineering Institute, please contact Disclaimer of Endorsement
References in this publication to spe
Customer Relations commercial products, processes, or
Software Engineering Institute by trade name, trademark, manufact
4500 Fifth Avenue otherwise, do not necessarily consti
Pittsburgh, PA 15213 imply their endorsement, recommen
or favoring by Carnegie Mellon Univ
Phone: 412-268-5800 the U.S. government.The ideas and
Fax: 412-268-5758 of authors expressed in any reports
Email: [email protected] material should not be construed as
Web: www.sei.cmu.edu Carnegie Mellon University or Depa
of Defense position and shall not be
for advertising or product-endorsem
purposes. Information contained in t
document is published in the interes
scientific and technical information e

No Warranty
Any material furnished by Carnegie
University and the Software Enginee
Institute is furnished on an “as-is” b
Carnegie Mellon University makes n
warranties of any kind, either expres
or implied, as to any matter includin
but not limited to, warranty of fitnes
purpose or merchantability, exclusiv
results obtained from use of the mat
Carnegie Mellon University does no
any warranty of any kind with respec
freedom from patent, trademark, or
infringement.

(SEI) is Trademarks and Service Marks
rsity for Carnegie Mellon Software Engineering
, the Institute (stylized), Carnegie Mellon Software
Engineering Institute (and design), and the
hored stylized hexagon are trademarks of Carnegie
S. Mellon University.
act
University ® ArchitectureTradeoff Analysis Method, ATAM,
license and Carnegie Mellon are registered in the
ments, or U.S. Patent and Trademark Office by Carnegie
rnment Mellon University.
right
252.227- SM Framework for Software Product Line
Practice is a service mark of Carnegie Mellon
University.

ecific The Software Engineering Institute (SEI)
services is a federally funded research and
turer, or development center sponsored by the
itute or U.S. Department of Defense and operated
ndation, by Carnegie Mellon University.
versity or
findings Copyright 2004 by Carnegie Mellon
or other University.

s an official
artment
e used
ment

this
st of
exchange.

Mellon
ering
basis.
no
ssed
ng,
ss for
vity, or
terial.
ot make
ct to
copyright

Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213-3890
Phone: 412-268-5800
Fax: 412-268-5758
www.sei.cmu.edu

Other Offices
Washington, DC Area
NRECA Building, Suite 902
4301 Wilson Boulevard
Arlington, VA 22203

SEI-Europe
An der Welle 4
60322 Frankfurt
Germany

U.S. Army Aviation
and Missile Command
AMSAM-BA Bldg 6263
Redstone Arsenal, AL 35898