Predictability by Construction

1SwMonSource
2
03 1
4
5 0 PIOC

0 TCTR 1 2

0 TVTR 1 0

MMXU 2

1

Up

Predictability by Construction

Building high-stakes systems
from certified software components

CarnegieMellon
Software Engineering Institute





Predictability by Construction

3

Predictable Assembly of
High-Stakes Software

7

The Value of Objective Confidence

11

Predictability by
Construction: Where Plug
Implies Play

15

Getting Started with
Predictable Assembly

19

Achieving Value
from Day One

23

Competitive Edge for Early Adopters

25

Selected Technical Details

This is the vision that
motivates a new research
initiative at the Software
Engineering Institute:
Predictable Assembly from
Certifiable Components
(PACC).

Imagine the year i
company’s bottom
and its unrivaled q
new and innovativ
applications from
Timing estimates
required tolerance
Critical safety and
and you have obta
components devel
These capabilities
increasingly comp

is 2009. You stake your reputation and your
m line on the innovative features of your software
quality. Your company quickly assembles
ve software-intensive systems for high-stakes

certified, trusted software components.
made at design time are routinely within
e with 99.99% confidence—or better.
d security properties are formally verified,
ained firm control over the quality of software
loped by suppliers from around the world.
give you a potent differentiator in your
petitive industry.

3

Predictable Ass
Components (PA
Technology of P

In the zone: Well-formed Engineering predictabilit
predictable assembly: The vision for 2009 implies n
before built satisfies analytic than engineering predictabili
assumptions Software Engineering Institu
forefront of research in the u
Out of the zone: predictably satisfy the quality
testable but not systems. The PACC vision ta
predictable ity to the extreme ranges of r
dence, and incorporates arch
Analytic theory: Analysis model: the basic units of software co
sound and reliable view of a well-
tools to reason about formed assembly The PACC vision represents
assembly behavior in analytic theory current practice. Today, pred
system-by-system basis in a w
Component assemblies are “in the zone” if their rigorous testing. This notion
runtime behavior is analytically predictable. Each the premise that if we observ
assembly (system assembled from components) in we can predict future behavio
the zone has a corresponding model in that zone’s of testing are well known. Af
analytic theory. Using sound analytic theories to and then watch for the parts
understand assembly behavior early in the approach is to develop analyt
development process has many advantages when behavior of entire classes of s
compared to conventional testing techniques. emphasis is on confirming th
confirmed, we can be sure th
4 assumptions of the theory wi
predictable in that theory.

sembly from Certifiable
ACC): The Science and
Predictable Assembly

ty—beyond testing Zones of predictability
nothing more—or less— PACC divides the world into systems whose behaviors are
ity. The Carnegie Mellon® predictable by analytic means and those whose are not.
ute (SEI) has been on the Analytically predictable systems are said to lie within the
use of software architecture to set, or zone, of predictable assemblies (systems assembled
y requirements of software from components).
akes architectural predictabil-
rigor and objective confi- The behavior of assemblies that are in the zone can be
hitecture design directly into determined at design time with objective confidence.
onstruction. Assemblies that lie outside the zone are not analytically
predictable. Their behavior can only be observed after
a fundamental advance on they are built.
dictability is achieved on a
way that typically involves Assemblies may be predictable using any number of
n of predictability relies on analytic theories (for example, timing, security, safety,
ve enough past executions, fault tolerance, and power consumption) and may
or. However, the limitations therefore lie within any number of zones of predictability.
fter all, we don’t build bridges
The PACC approach is to ensure that we build only
that collapse! A far better systems that lie within the required zones of predictabil-
tic theories that predict the ity. Our focus is on critical qualities that are likely to be
systems. In this approach, the of significant business value, such as performance, safety,
he validity of theories. Once and security.
hat all systems satisfying the
ill have behavior that is

Predictable assembly 2. Predictability by constructio
Engineering predictability is more than just a good idea. those systems that have predi
It is achievable today. The SEI’s PACC Initiative has to predict the behavior of any
made significant progress to this end by establishing technology ensures that the a
two axioms: theories are established—and
during system construction.
1. Objective confidence. Predictions must be trustworthy.
Objective confidence, through rigorous empirical and In PACC, analytic theories p
formal validation, is the acid test PACC applies to predicting critical system beh
predictions. This distinguishes PACC from other impose design constraints—t
model-based and generative approaches to software constraints are “in the zone”
development. new class of component tech
construction—these constrai
The predicted behaviors of all assemblies have associated • We know our systems are pre
measures of confidence. This confidence is the bankable component technology guara
outcome of predictable assembly—leading to shorter stay in their required zones.
development cycles, decreased development and testing • We know which properties o
costs, and higher quality systems. and must be trusted since the
required by the analytic theo

Predictable Assembly = Objective Confidence + Predictability

on. Our aim is to build only “With predictability by
ictable behavior, rather than
y systems we build. PACC construction Siemens can
assumptions of analytic
d enforced—as invariants maintain high-quality

provide the means for standards in our embedded
haviors. Analytic theories
the systems that satisfy these software while simultaneously
of this theory. PACC uses a
hnology to enforce—by using a growing worldwide
ints.
edictable because the source of software
antees that assemblies always
component developers.”
of components are important
ey are the same properties Matthew Bass
ories. SEI Resident Affiliate
Siemens Corporate Research, Inc.

y by Construction 5

6



“There is a wide gulf between
claiming predictability and
trusting the predictions.
Trust requires objective
evidence. Objective evidence
mandates systematic rigor
in engineering analysis and
measurement. Empirical and
formal validation are part of
the fiber of PACC to provide
objective evidence, instill
objective confidence, and
engender trust.”

Linda Northrop

Linda Northrop has over 35 years of experience in the software
development field as a practitioner, researcher, manager,
consultant, and educator. She is currently director of the
Product Line Systems Program at the SEI where she leads the
work in software architecture, software product lines,
and predictable component engineering. Under her leadership,
the SEI has developed software architecture and product line
methods that are used worldwide, a series of five highly
acclaimed books, and Software Architecture and Software
Product Line curricula that include a total of 11 courses and
6 certificate programs. Linda is a recipient of the Carnegie
Science Award of Excellence for Information Technology and
the New York State Chancellor’s Award for Excellence in
Teaching. She is coauthor of Software Product Lines: Practices
and Patterns and chaired both the first and second international
Software Product Line Conferences (SPLC1 and SPLC2).
In addition, she is the current Object-Oriented Programming,
Systems, Languages, and Applications (OOPSLA) Steering
Committee Chair and was the OOPSLA 2001 Conference Chair.

A standard label for The Value of Ob
latency theories
A standard measure for
statistical inference

Population parameter:
8 out of 10 assemblies will
exhibit predicted behavior.

Trusted predictions

Upper bound: Making predictions is easy; m
Actual latency will differ consistently and quantitative
<1% from predicted latency. difficult. For one thing, it req
precisely what we mean by “g
requires that we provide obje
“goodness.” Despite the diffic
worth our while:
• Without objective evidence,
should not, trust a prediction
prediction has little, if any, va
• With quantifiable trust, signi
made to designs, families of d
processes.

Confidence parameter: PACC already assigns a statis
We have >99% confidence analytic theories, such as the
that the upper bound is will come when the form and
correct. be industry standards.

Objective confidence in predictions comes Sample: Objective confidence puts bo
from reliable, quantifiable evidence. The Important but not exhaustive This is as good as money in t
predictions of an analytic theory are validated detail of how the label can uncertainty is the root of all r
against sample assemblies representative of be interpreted mitigate risk. For performanc
those in the zone of that theory. The SEI is mitigation might be overly co
charting the future of engineering confidence useful and distinctive feature
for software systems. cycles with extra testing and
Objective confidence will allo

bjective Confidence

making predictions that are risk mitigation; conversely, it will help you avoid the need
ely good is much more to carry unnecessary risk.
quires that we understand
good.” For another, it Combining objective confidence with state-of-the-art
ective evidence of analytic theories will allow us to continuously reduce
culties, the effort is well uncertainty. In this way, PACC aims to effectively eliminate
whole classes of design risk from your software systems.
engineers cannot, and The result will be better quality software, better resource
n. Without this trust, a allocation, and less liability.
alue.
ificant optimizations can be More concretely, quantification begs optimization. For
designs, and engineering example, perhaps a 1% upper bound is not acceptable,
or the population parameter needs to be 99 out of 100 or
stical confidence label to 999 out of 1,000 assemblies. PACC provides a repeatable
label shown at left. The day process for systematically improving engineering predict-
d content of these labels will ability for specific critical system qualities. This engineering
predictability will be a core asset in maintaining your
competitive position in the marketplace.

ounds on uncertainty. Most concretely, objective confidence will lead to substan- 7
the bank. Why? Because tial reductions in testing effort. For example, assuming that
risk, and there is a cost to a 1% difference between predicted and actual latency is
ce-critical systems, one acceptable, testing might be limited to determine that an
onservative designs that lack assembly lies within the “8 out of 10” population. Once
es or longer development that is established, only spot checks of latency might be
quality assurance effort. required—a substantial savings in time and effort over
ow you to avoid unnecessary conventional development approaches.

Safety interface Trusted components
Security interface PACC establishes a rich foun
Performance interface components, one that goes b
ness to encompass other “as b
Analytic interfaces components must possess. An
which qualities are needed to
Conventional
interface All analytic theories make ass
assumptions dictate what we
Software component trust—about components. Fo
theory might require that we
Today’s components typically expose minimal non-blocking execution time
information—often only a conventional, syntactic operations, while a safety the
interface and a brief API description. Trusted possess a state machine for ea
components must provide more insight into their In these examples, analytic th
inner workings. Analytic theories require additional into some aspect of the behav
quality-specific properties such as task execution of components.
time to make predictions. These quality-specific
properties are exposed as analytic interfaces These new visibilities make u
of components. of a component. Different an
general, require different ana
8 interface defines a distinct, an
the component.

ndation for trusted To have objective confidence in the predictions of
beyond functional correct- analytic theories, we must also have objective confidence
built” qualities that in the parameters to these theories—components’
nalytic theories tell us analytic interfaces. PACC therefore establishes an
o support predictability. objective, measurable, and predictive foundation for
component trust and certification.
sumptions. Some of these
need to know—and By making analytic interfaces first-class elements of
For example, a performance component technology, we extend the benefits that
e know the maximum components bring to quick integration to reliable
e for all component predictability.
eory might require that we
ach component operation.
heories require visibility
vior or implementation

up the analytic interface
nalytic theories will, in
alytic interfaces; each such
nalysis-specific view of

Today’s Component Technology: Only a First Ste

Why component technology is a good first step Why component technolo
Component-based development is not a new idea. For all of its promise, today’s
Components are implementations of software function- falls short of what is needed f
ality. The boundaries of components are not set by tolerance on runtime behavio
technical considerations alone, but also by economic component technology, little
considerations, chief among which are the potential to nents beyond their plug inter
apply the component in multiple markets and the need behavior is, by design, hidden
to implement nontrivial capabilities so the component today’s component technolog
has substantial value. high-stakes software systems.

The logic of these considerations leads to components When design tolerance is ext
that are inherently complex. This complexity is developers mitigate risk by pl
packaged for consumption in what is known as software conservative designs and buil
components. Whether components are developed and rework. Development tim
in-house or by third-party suppliers, the inner workings and computing resources are
of components are intentionally hidden by this packag-
ing. Today, this packaging is a major part of the value of But it doesn’t have to be this w
component technology. Current component technology corporate partners are develop
also packages another form of complexity by providing the promise of component-ba
standards that enable components to fit together— systems with tight design tole
providing “plug” compatibility. reliability. To do this, we mus
of software components by ad
development of performance-
is to guarantee that componen
that they also “play”—securely
system developers intend.

ep

ogy is not enough “We need a new paradigm for software
s component technology engineering that moves engineering
for systems with tight analysis to the forefront. As opposed
or. In today’s software to building software line by line,
e is known about compo- we need a system of fabrication from
rfaces—critical component reusable components (not unlike
n. This opaqueness makes how we leaped forward in the
gy a risky proposition for electronics industry years ago), and
. that results in zero defects being
introduced into the software during
tremely tight, system its design and development. There is
laying it safe. They employ already very interesting and important
ld in long cycles for testing work going on in this regard, known
me is long, costs are high, as Predictable Assembly from
e not fully exploited. Certifiable Components (PACC).”

way. The SEI and its Congressional Testimony of Former Congressman Dave McCurdy,
ping technology to bring March 19, 2002, The Current and Future Ability of the U.S. Industrial
ased development to software Base to Effectively and Affordably Meet Our National Security Requirements
erance for timing, safety, and
st go beyond today’s concept
dding what is needed for the
-critical systems. Our aim
nts do more than just “plug”:
y, reliably, and exactly as

9

10



“A component technology
is nothing more than a
way of packaging design
constraints. If we also include
design constraints that
lead to predictable behavior,
then we have, in effect,
packaged predictability.
This is the motivation for
prediction-enabled
component technology.”

Kurt Wallnau

Kurt Wallnau is a senior member of the technical staff at the
SEI. He has 20 years of experience in software engineering
research as a defense contractor and with the SEI.
A recurring theme in this research has been the use of
software components. Kurt’s most recent research focuses on
formalizing the connections between software architecture
and software component technology with the goals of making
software architecture more concrete, software components
more abstract, and systems composed from components more
predictable at runtime. Kurt is currently the technical lead of
the SEI PACC Initiative; previously he led the design and
engineering work in the SEI COTS-Based Systems Initiative.
Kurt’s earliest research was in application-specific languages,
program generation techniques, and the use of knowledge
representation techniques for semiautomated assembly of
systems from components. He is coauthor of Building Systems
from Commercial Components and numerous papers and
articles on component-based software engineering.

Predictability b
Where Plug Imp

Stimulus Software Standard Reactive Response A higher order componen
interface component connector behavior interface The SEI and its research part
only generation, or higher order, c
By “higher order,” we mean
Standard component Component runtime Hardware/OS that is parameterized by anal
runtime interface environment these parameters with specifi
performance and security for
Predictability cannot be achieved with an arbitrary prediction-enabled compone
component technology. To support predictability, Prediction enabling means th
a component technology must exhibit the minimal, ideal the component technology w
design pattern shown above. In this ideal pattern, all construction—to be in the z
interactions among components are exposed and use critical system properties.
standard connection mechanisms. Additionally, resource
management and coordination policies are defined and To support predictability, we
enforced by a standard component runtime environment. found in today’s component
This ideal pattern is a crucial first step toward others. We need more visibil
predictability by construction. of components and their run
more control over the design
the component technology. C
freedom for programmers to
software architectures and fe
features that have marginal u

by Construction:
plies Play

nt technology A strict foundation
tners are developing a next A PECT requires a strict and well-defined component
component technology. technology at its core.
a component technology
lytic theories. Filling in The component technology we use is a result of close
fic analysis theories, for examination of the best features and patterns found in
r example, results in a today’s component technologies. Our design pattern
ent technology (PECT). (shown at left) differs from those patterns in its combina-
hat systems built using tion of features and the strictness with which it is
will be guaranteed—by enforced. It includes only the features needed to support
zone of predictability for predictability by construction.

e need more of some things There are many ways to implement this design pattern.
technologies and less of The important point is the strict enforcement of the
lity into the behavior design pattern, not its particular implementation.
ntime environment and In any case, the implementation need not be packed with
n constraints imposed by features. Indeed, for systems with tight bounds on
Conversely, we need less runtime behavior, less is more.
o invent new and untested
ewer complex technical The SEI has developed the Pin component technology
utility. as an exemplar of this pattern. Pin is a small-footprint,
real-time component technology that has been designed
to also be simple to program, extend, and rehost.

11

Component Analytic
technology constraints

Reasoning The real breakthrough: re
frameworks The real breakthrough in our
component technology but r
Analytic theory component technology with
Model representations
Evaluation function Reasoning frameworks make
theories accessible to system
developers rather than just to
performance, or safety. In eff
works treat this expertise as a
in its own right. Reasoning fr
and package for use, the engi
required to construct systems
runtime requirements with sp

Interpretation

A prediction-enabled component technology (PECT) moves
a step beyond the ideal component technology pattern by
introducing reasoning frameworks. Reasoning frameworks
package state-of-the-art analytic theories and enable
nonexperts to predict critical runtime qualities such as
performance, safety, and security.

12

easoning frameworks The elements of a reasoning framework are
r research, however, is not an analytic theory, based on a solid foundation such as
rather the extension of queuing theory, rate monotonic scheduling theory,
reasoning frameworks. finite-state automata, or temporal logic

e state-of-the-art analytic analytic constraints that mirror the enforceable design and
integrators and component implementation assumptions of the analytic theory
o experts in security,
fect, the reasoning frame- an interpretation that checks assemblies for well-
a new kind of component formedness in the reasoning framework and generates
rameworks encapsulate, analysis models
ineering competence
s that satisfy critical model representations in the theory, defining behavioral
pecified design tolerance. “views” or “semantics” of assemblies of components,
for example, in terms of time

a computable evaluation function, which, when given an
analysis model, constructs a prediction of assembly
behavior that can be objectively (observably) validated

Although there is quite a bit of computer science in the The discipline of constructin
structure and implementation of reasoning frameworks, generates unique value in and
the core idea is simple and straightforward. Every engineering competence on w
prediction is based on assumptions about the subject of depends and by making this
the prediction (the assembly). Reasoning frameworks asset in its own right.
ensure that assumptions are established as invariants in
assemblies, much as type checkers in modern program- Of course, few systems only h
ming languages establish representation invariants in or safety requirements. To de
computer programs. requirements, multiple reason
applied. Each reasoning fram
The illustration at right shows how the idea works defines a projection of the sy
using the PACC technology developed at the SEI. theory. In any well-construct
The reasoning framework called “λ*” packages a variant of predictability for multiple
of rate monotonic scheduling theory that has been will overlap significantly, ensu
specialized to a range of characteristic assemblies for predictable with respect to m
some application area. The λ* interpretation checks
whether component assemblies satisfy the assumptions
of this specialized theory (formalized as analytic
constraints). If they do, the interpretation generates a
corresponding analysis model and applies the evaluator
to “solve” the model.

Component
assembly

ng reasoning frameworks λ* interpretation λ* analytic
d of itself by codifying the YES constraints
which your organization satisfied?
competence a first-class
NO
have performance, security, Generate λ*
eal with multiple quality analysis model
ning frameworks must be only for well-formed
mework’s interpretation assemblies
ystem with respect to that λ* model of
ted PECT, the zones the assembly
reasoning frameworks
uring that systems are
multiple qualities.

Each component assembly that satisfies a reasoning
framework’s analytic constraints is in that reasoning
framework’s zone of predictability. For such an assembly,
the reasoning framework’s interpretation can be used to
automatically generate an analysis model that describes
a view of the assembly in terms that are relevant to
the reasoning framework. The reasoning framework
uses this analysis model to predict the runtime behavior
of the assembly.

13

14



“Utmost reliability of the
software in our products and
systems is crucial for ABB.
The safety of an electric
grid or the operation of a
whole factory may depend
on that. We follow with
deep interest the PACC
approach and welcome further
initiatives to improve software
engineering.”

Markus Bayegan

Chief Technology Officer
Group R&D and Technology
ABB Asea Brown Boveri Ltd

Dr. Markus Bayegan began his career in 1973 as a system engineer
with Integrated System Development in Oslo, Norway. Within a
couple of years, he moved to the Center for Industrial Research,
also in Norway, where he worked as a research scientist for
two years and later as R&D manager. His work has focused on
computer-aided design, databases, and microelectronics. During
this time, he was also a visiting research scientist at Stanford
University in the U.S. In 1981, he took the position of senior vice
president of R&D at the EB Corporation, a telecom company,
which today is part of Ericsson. Since 1985, he has held the position
of professor of electronics manufacturing at the Norwegian
Institute of Technology. For 10 years, he held dual positions
of president of ABB Corporate Research Norway and senior vice
president for ABB Asea Brown Boveri Ltd. Since January 1998,
he has worked in the Group R&D and Technology division in two
capacities: as senior corporate officer, and since January 2001,
as chief technology officer. Dr. Bayegan is the coauthor of several
books on microelectronics and information technology.

Getting Started

Strong Design Constraints High Confidence

Incrementally Target Theory Co-refinement: a method
Relax refinement of predictable
The SEI has developed the co
Interpretation trading off restrictiveness of d
design tolerance, and analysis
Target Zone Incrementally has proven to be an effective
Weak Design Constraints Tighten design competence needed to
Low Confidence construction. It identifies the
implementation constraints n
The co-refinement process is a systematic process for prediction accuracy for your
developing reasoning frameworks. The process begins your organization will obtain
with a base step: a reasoning framework that is as runtime qualities of your syst
constrained as necessary to be thoroughly understood. that make up your systems.
The “zone” of this base step may be a small subset
of the target zone and fail to deliver the required The co-refinement process st
confidence. The process proceeds by incrementally of assemblies for which devel
relaxing design constraints and improving confidence predictions with confidence a
(co-refinement), while preserving the ability to apply the tolerances. The idea is to star
reasoning framework’s analytic theory. It does so by thoroughly understood and f
ensuring that a valid interpretation exists at each step. tation to a reasoning framewo
The process continues until the reasoning framework
can be applied to the target systems and produce Co-refinement proceeds thro
predictions with the target level of confidence. relaxations of design restrictio
increases the size of the zone
also preserves interpretability
and predictability evolve han

with Predictable Assembly

for systematic The process stops when the set of predictable assemblies
e assembly is large enough to contain the target zone; that is, when
o-refinement process for it describes the set of applications of interest to your
design constraints, required business. The resulting design restrictions are sufficiently
s tractability. Co-refinement tight to enable the reasoning framework to predict
tool for capturing the qualities with the required confidence and tolerance, and
o deliver predictability by sufficiently loose to permit the exploration of various
e weakest design and system designs and product variants that are relevant to
needed to achieve required your application domain.
systems. With this process,
n real control of the critical But the process need not stop there. The exceptional
tems and the components focus on objective confidence introduced by PACC will
enable your organization to systematically improve its
tarts with the largest set engineering competence over time by tightening
lopers can make design confidence bounds or relaxing design constraints and by
and that meet required introducing new reasoning frameworks. Engineering
rt with a base case that is predictability is not an end state—it is a mind-set.
for which a sound interpre-
ork can be constructed.

ough a series of controlled
ons. Each relaxation
of predictability. Each step
y so that design constraints
nd in hand (or co-evolve).

15

A basic but complete PECT that Getting Started
includes performance and model
checking reasoning frameworks Building your PECT
that can be used to predict A prediction-enabled compo
the behavior of time- and safety- is an expression of your organ
critical embedded systems. competence. Since this comp
The Starter Kit was designed to distinction in the marketplac
jump-start the PECT development the shelf. Instead, to be effect
process, allowing extensions targeted to the class of system
to other reasoning frameworks the critical behaviors that you
or product domains. and the distinctive way you b

Starter Kit Starter Kit
Developing a PECT may see
Your PECT but the SEI has been workin
the process with the Starter K
A specialization of the Starter Kit but complete PECT that can
for a particular product domain, and safety-critical embedded
set of qualities, or product line. you can construct your own
The SEI works with partner
organizations to develop these The elements of the Starter K
embodiments of an organization’s of the art, but move well bey
engineering competence. in the Starter Kit.

16

with PECT

onent technology, or PECT, Today’s Starter Kit provides
nization’s engineering
petence is your competitive the Pin component technology, a small-footprint, real-time
ce, don’t expect to buy it off component technology that includes the minimal features
tive, a PECT must be needed to support predictability. Pin operates on Windows
ms your organization builds, CE and Windows 2K platforms and can be readily rehosted
ur systems must exhibit, to “bare” devices.
build these systems.
a family of performance reasoning frameworks (λ*) for
predicting average- and worst-case latencies in a variety of
design settings (e.g., periodic and stochastic event arrivals)

em like a daunting task, a model checking reasoning framework (ComFoRT) for
ng on a way to jump-start verifying safety and liveness conditions of components and
Kit. The Starter Kit is a basic assemblies (e.g., ensuring that communication protocols
n be used “as is” for time- route information correctly)
d systems. From this basis,
an instrumentation and observation infrastructure for
business-specific PECT. observing runtime behaviors of assemblies and for
performing statistical analysis on the differences between
observed and predicted behavior

Kit are in themselves state a construction and composition language (CCL) and
yond that when combined compilation tools that perform static checking of design
constraints against CCL specifications and generate
analysis models and component implementations (code)
for well-formed specifications

Today’s Starter Kit is a basic but complete PECT that
can be used “as is” for time- and safety-critical
embedded systems. The elements of the Starter Kit
can also be used to jump-start the development of
new PECTs, through the addition of new reasoning
frameworks or the extension or replacement of
existing elements.

��������
�������������

��������������

�����������������
��������������
�����������������������

��������������� ������������� ������������� �����
���������������
�������������

��������� �����

��������������
�������������������

�������������� ��������������������������������
�������������� ���������������
�����������
�������������� ���������������
����������
������������������������� 17
��������������

�����������������������
������������������

�����������������
�������������
�������������������������������

�����������
�������������������

18



“The SEI works closely with
organizations to provide
support throughout the
development life cycle.
We strive to create mission
success and competitive
advantage through our
training programs, technical
service offerings, and
advanced research initiatives.
We look forward to
leveraging the potential of
PACC with organizations
looking to win the future.”

Achieving Value

The SEI excels at bringing state-of-the-art software The process of specifying mo
methods and technology to bear on industrial-strength cant value to collaborators. Sy
problems. The SEI’s PACC Initiative has pioneered a problems can often be genera
method for technical collaboration that focuses predict- a class of systems—and the so
able assembly directly on those system qualities for is therefore applicable to that
which predictability is paramount. This method problem is not simple, but it
produces objective proofs of feasibility for PACC that step in achieving engineering
are situated in your critical business area, while at the co-refinement, the social proc
same time transitioning to your organization the capabil- model problems can be as im
ity to scale these proofs to industrial use. results of these processes.

The method is centered on the collaborative specifica- Each model problem initiates
tion and solution of model problems. A model problem each step of the co-refinemen
specifies a base design pattern and one or more opera- solution to some class of syste
tional scenarios, with each scenario distinguishing step produces solutions that b
system stimuli from system responses. Prediction is of systems represented by the
expressed in terms of response measures and confidence of this process is not limited t
bounds—both establish the norms for objective it creates; the process also imp
confidence. A model problem reduces a predictability standing to its participants ab
problem to its essence; its solution is clearly applicable to under development and abou
the system it models. design freedom and predictab
organization will be accruing

e from Day One

odel problems is of signifi- Benefits for SEI research partners

ystem-specific analysis SEI research partners actively participate in a research

alized in model problems to activity and receive numerous benefits:

olution to those problems • Early access to research results provide the partner with the

t class. Defining a model opportunity to adopt cutting edge technologies well before

is a critical first their competitors can.

g predictability. As with • We tailor our research agendas around the applications

cesses involved in specifying and model problems provided by research partners. Doing

mportant as the technical so often provides direct and tangible benefits to the

partner in the application area.

• In the case of PECTs, partners will help us set the

s a co-refinement process, standards for a new class of component technologies.

nt process yields a prediction

ems, and each successive

better approximate the class

e model problem. The value

to the technical by-products

parts a depth of under-

bout the class of systems

ut the tradeoff between

bility. At each step, your

g value.

19

ABB collaboration • The λABA reasoning framewo

ABB Ltd., a leader in power and automation technolo- predicting average latency in

gies that enable utility and industry customers to lers. λABA supports very gener

improve performance while lowering the environmental interacting both synchronou

impact, became an SEI research partner in 2001. This • The general method and sup

collaboration has produced significant results for both validating the objective quali

ABB and the SEI. were developed and applied t

foundational for PACC and

The initial application of predictable assembly was in the resident affiliate his PhD.

electric power grid domain. The question was whether

operator stations and primary equipment controllers ABB and the SEI later applie

could be assembled such that average latency could be tion automation research to

predicted for primary control functions such as closing a robot control. Controllers in

high-speed breaker and for interactions between human functions and manage a large

operators and primary controllers. It was also important only some of which are hard

that the resulting assemblies satisfy the IEC-61850 This domain presented sever

functional standard for substation automation systems. team. Again, the results were

The ABB Corporate Research Center provided funding • An assortment of safety prop

and a full-time resident affiliate to explore this question. interprocess communication

verified using model checkin

The results were promising: this nontrivial subsystem (ex

• A PECT for soft real-time operator stations and a PECT states) provided results of gre

for hard real-time primary equipment controllers were software engineers. In one ca

built using the SEI Pin component technology. These a rare anomaly (only recently

controllers were integrated using proprietary ABB had eluded detection for 7 ye

messaging software and conformed to the IEC-61850

standard.

20

Photos: ABB

ork was developed for • The λABA reasoning framework was extended to handle

n primary equipment control- events with aperiodic arrivals and introduced novel

ral topologies of components queuing-theory extensions to classical rate monotonic

usly and asynchronously. analysis (RMA). The extended reasoning framework allows

pporting automation for third-party extensions to be plugged into a new generation

ity of performance theories of open robot controllers in a way that guarantees bounded

to λABA. The results were invasiveness of the plug-in component on hard real-time

also earned the ABB control operations and allows accurate prediction of

average-case latency of plug-in operations.

ed the results of the substa- The four years of collaboration between the SEI and ABB
the domain of industrial have been of tremendous value to both parties. ABB
n this domain perform many benefits from working with the SEI on PACC because it
e variety of concurrent tasks, will be among the first to reap the benefits of predictable
d real-time and safety critical. assembly. PACC solutions to challenging ABB problems
ral challenges to the research are directly applicable to the class of systems built by ABB.
e promising:
perties of the controller’s The SEI also benefits from working with industrial collabo-
n mechanism were formally rators such as ABB. The PACC solutions to ABB problems
ng. Verifying properties of can be applied to a vastly large class of analogous problems
xceeding 101932 discrete found throughout the commercial and defense segments of
eat interest to the controller the software industry. Collaboration is the surest way for
ase, the model checker found the SEI to achieve its mission of large-scale technology
y discovered by ABB) that transition to improve the state of the art, and the state of
ears. the practice, of software engineering.

The SEI Seeks I

Collaboration opportunities The following kinds of collab
During 2002-2004, the SEI developed PECT and (and are not mutually exclusi
applied it, and its associated methods, in increasingly 1. trial use of PACC to produ
demanding industry settings. The result is state-of-the- technology demonstrations, p
art technology—the Starter Kit. return on investment (ROI)
2. refinement of Starter Kit r
The SEI seeks innovative research collaborators to development of new reasonin
apply PACC technology to industry systems that will opportunities exist in the are
benefit the most from predictability by construction— reliability, and timely behavio
systems that exhibit three or more of the following 3. applying PACC technolog
characteristics: embedded, mobile, distributed, safety resulting in an industry- or c
critical, time critical, and security critical. Kit that combines the functio
line with design restriction fo
Representative application areas include industrial 4. developing technology for
robotics, automotive, aerospace, power generation and certification of software comp
transmission, medical diagnostics, and command and frameworks, including self-ce
control. Qualified collaborators will have significant model-code conformance, an
control over the design and implementation of these prediction labels
systems, although major portions of them may be 5. advanced research in autom
developed by third parties. including design transformat
performance within the pred
runtime behaviors and tradeo
different zones

Are your systems embedded, mobile, distributed, safety criti