MODEL-BASED INTEGRATION OF REUSABLE
COMPONENT-BASED AVIONICS SYSTEMS1
David Sharp, Wendy Roll
{david.sharp, wendy.c.roll}@boeing.com
The Boeing Company
P.O. Box 516
St. Louis, MO 63166, USA
Abstract:
A flight-tested product line open system software architecture developed under the Boeing Bold
Stroke initiative has been previously described and presented. This architecture enables a
reusable component-based development process for avionics systems to achieve product goals
of improved affordability, quality, and system timeliness.
For large-scale systems, one very challenging portion of this process is the integration of
common and project specific software components into systems that respect cross-cutting
embedded system requirements such as hard and soft real-time deadlines, fault tolerance, and
distribution. Significant advances in current approaches would result from an integrated
approach to explicit modeling of functional behaviors and coupled physical embedded system
properties, analysis of these models to ensure that they meet requirements prior to coding, and
automated component configuration code generation. Such capabilities and their integration are
well beyond that of current tools and methods. This presentation describes some of the
challenges, requirements, and end-state visions of this approach for avionics systems as being
developed within the DARPA Model-Based Integration of Embedded Software (MoBIES) and
Program Composition for Embedded Software (PCES) programs, including descriptions of
capabilities that have been developed to date and the results of initial experimental evaluations.
1 Introduction
In 1995, an initiative was launched at Boeing
(then McDonnell Douglas) to assess the potential
for reuse of operational flight program (OFP)
software across multiple fighter aircraft platforms,
and to define and demonstrate a supporting system
architecture based upon open commercial hardware,
software, standards and practices [1]. The following
year, this became a key element of the Bold Stroke
Open System Architecture avionics affordability
initiative which applied these techniques to the
broader tactical aircraft mission processing domain.
Key aspects of the component-based logical
architecture developed therein have been previously
described [2]. For large-scale systems, one very
difficult portion of the resulting development
process is the integration of common and product
specific software components into systems while
respecting embedded system requirements such as
hard and soft real-time deadlines, fault tolerance,
and distribution. Automating this task through
modeling component compositions, analyzing their
embedded system properties, and automatically
synthesizing integration and configuration code,
would enable significant advances over current
approaches. An integrated approach of explicit
modeling of functional behaviors and coupled
1
This work was sponsored by the DARPA Information Exploitation Office Model-Based Integration of Embedded Software program
under contract F33615-00-C-1704 administered by the Air Force Research Laboratory, Wright-Patterson Air Force Base.
1
physical embedded system properties, analysis of
these models to ensure that they meet requirements
prior to coding, and automated component
architecture views to the specific case of embedded
system component integration [3].
integration and configuration code generation is
well beyond the capabilities of current tools and
methods. These development steps are the focus of
this effort, highlighted in Figure 1 within the
context of a full reusable component-based
development process.
Scalability of these approaches
is a key concern. The avionics systems targeted by
this approach include millions of lines of source
code and thousands of components. The size of
these systems greatly benefits from automated
development aids. Wherever possible, these
modeling activities should be possible both
manually and via input from configuration
automation tools, including monitors of actual
execution of partial and complete system
configurations.
A key challenge of multiple view modeling for
real-time embedded systems arises
from the cross-cutting nature of the
different views. For example,
Analyze
changing
the
allocation
of
Reusable
Component
components to processes and
Model
Components
Models
Model
processors affects scheduling and
fault tolerance aspects. The use of
Configure
Build
Test
Build
Test
multiple views for analysis and
automated composition requires their
Focus Area
integration to provide a coherent
Figure 1: General Model-Based Component Integration
view of the entire system and
Approach
highlight effects of changes in other
views.
This paper describes some of the challenges,
requirements, and end-state visions of these modelbased approaches to developing avionics software
systems. The next three sections address the three
key technology areas of multiple view modeling,
model analysis and system configuration. The
conclusion includes a brief description of
experiments associated with exercising and
measuring these capabilities.
2 Multiple View Modeling
The first of the three key enabling technologies
for component-based product line development of
avionics systems is the explicit modeling of
integrated components and systems, focusing on
those aspects that affect their non-functional
properties. The models are then leveraged to
support analysis and automated configuration of
avionics systems that satisfy real-time embedded
system requirements. Making these modeling
technologies usable by established production
programs requires that they be incorporated into
existing development practices. Accordingly, this
section discusses how such modeling technologies
should be reflected in existing development views.
This applies the common approach of multiple
Due to space constraints, a key subset of
defined views associated with these efforts are
included, and are grouped together into those
associated with the Process and Deployment
architecture views.
2.1 Process View
Execution control and timing are a critical
concern of large real-time embedded systems and in
practice are often handled empirically. This has lead
to substantial rework, cost, and system development
delays in many important cases. Improving this
current practice is one of the major motivations for
moving to the explicit modeling and model-based
analysis of such properties. The Process View is
used to identify the processes and threads executing
in a system and to identify which components are
executing in each thread.
In the envisioned
development approach, it will also be used to
identify dependencies between threads, between
components, and between threads and components
2
in order to facilitate the desired analysis. This
subsection will examine the modeling needs for
various subviews within the overall Process View.

2.1.1 Execution Dependency
Subview
Control flow in avionics systems has a
significant impact on, and is impacted by, nonfunctional properties and requirements. An activity
may be executed in response to new data, at some
periodic rate, or in response to a request by a
component. The goal of this view is to be able to
model the execution dependencies of specific
components on specific triggers, or events, as well
as the dependencies between components that
generate and respond to such triggers.
In some cases, the periodic arrival of data
triggers execution of components that receive the
data. These components in turn trigger other
components, and represent roots of acyclic
execution dependency graphs. Other such graphs
may be initiated via time triggers. Within these
graphs, subgraphs often exhibit modal behavior and
are conditionally active based on the state of the
system. Modeling these graphs in a way practical
for large systems is a key modeling challenge.
Such modeling is ideally performed without
reference to a particular hardware configuration.
Hardware specifics are used to refine models using
the Deployment View.
Capturing this information for analysis will
require models that allow the developer to:



Specify trigger types. Trigger types
could be as simple as names or
enumerations that convey the semantics
of the trigger. Trigger types could be
used to provide filtered views or
highlighted relationships within a view.
Specify semantic categories of trigger
types. Possible categories of trigger types
are clock driven triggers, notification
triggers, enabling triggers, root triggers,
and terminal triggers with the capability
to define additional domain specific
categories of trigger types.
Specify trigger types generated and
responded to by components. Specify
components that respond to Boolean


combinations of triggers in addition to
the occurrence of individual triggers.
Specify execution dependency graphs.
This includes the specification both of
the roots of these graphs, typically
triggers related to time-based interrupts,
and the arcs within the graphs
representing execution dependencies
between component instances. Following
Deployment View modeling, some of the
execution dependencies may result in
distributed computation.
Specify execution rates for the timebased roots of execution dependency
graphs.
Model system modes and define their
relationships. System modes may be
always active or conditionally active, and
describe those triggers that are supplied
under different conditions, including
those associated with fault management
modes. System modes may be active
simultaneously or be mutually exclusive.
2.1.2 Thread Subview
The baseline Bold Stroke architecture typically
contains four types of threads. There is a single
thread that handles external bus specific input and
output. There is a set of threads that handle
network processing, one for each rate of processing
typically resulting from remote Object Request
Broker requests. There is another set of threads that
handle trigger dispatching and processing, again
one for each rate in rate monotonic scheduling
manner. Finally, while threads are typically within
the middleware framework as in the cases above to
allow flexible composition of application
components with threads, there are rare cases of
product specific components that have their own
threads. These four thread types are representative
of most derivative avionics systems, although the
balance between the thread types may vary
significantly from system to system.
Although a significant amount of research is
being applied to more dynamic and adaptive
embedded system scheduling, most such systems
currently in operational use are statically scheduled.
Typically, all threads are created during the
initialization and configuration phase of the system.
Each thread has a unique static priority.
3
Components have known rates at which they need
to produce outputs, and are assigned to threads with
related priorities.
Models for the thread subview need to allow
the user to:



Specify the threads in the system.
Specify the intended rates of execution,
which imply deadlines for associated
processing.
Identify the priority assigned to each
thread.
2.2 Deployment View
The primary focus of the deployment view is
allocation of application components to processors
and processes.
2.2.1 Component Quality of
Service Subview
Components may have various Quality of
Service (QoS) attributes that aid in determining
how they will be executed, in particular, in which
thread the components will execute. Such
components
are
considered
independently
schedulable. Other components may not have their
own QoS attributes. Such components are passive
and their execution is purely a function of their
invocation by some schedulable component.
A component may have multiple QoS
attributes. These attributes are used to schedule the
activity of the given component, e.g. determine in
which thread a component will run and the order in
which the component is activated within a given
thread. QoS attributes can include:



Rates of execution – A range of
acceptable rates may be specified or the
component may specify that its activity
must execute at a specific rate. It is the
rate of execution that implicitly defines
the component’s execution deadline.
Importance – The relative importance of
one component as compared to other
components that have the same rate of
execution. This affects the ordering of
execution within a thread.
Execution Time - The amount of
processing time that may be used by a
component. This is usually the worst
case execution time. This may include
the execution time of other (passive)
components, utilities, and services that
this component invokes.
These QoS attributes may remain fixed over
the life of a component, or they may change as the
state of the system changes.
Similarly, a
component may exist throughout the life of the
system but be designed to be available to respond to
triggers during some system states and be dormant
and not available during other system states.
Any component quality of service model
should allow the user to specify the QoS properties
associated with components, including their
evolution as the system changes state, and the
resulting assignment of components to threads.
2.2.2 Process Subview
The first, and relatively simple, step of
software allocation is defining the hardware and
software processing resources that will be available
for component allocation.
Process subview models should allow the user
to:



Define the set of processors and
processes available for processing within
the system.
Define the topology of the available
resources and the network
communication resources available for
their interaction.
Define the allocation of threads to
processes.
2.2.3 Component Allocation
Subview
Allocation of components to hardware
resources in distributed systems is influenced by a
number of concerns including resource utilization,
timing requirements, and unique hardware
capabilities.
Component allocation models should allow the
user to:

Identify a group of components that must
be allocated to the same processor. This
may be done to conserve bandwidth by
ensuring that high volume transfers of
4


data are performed locally, or for other
reasons. Especially in real-time systems,
performance concerns require that
components with close communication
coupling remain collocated.
Allocate a component or group of
components to a particular processor.
Automate or aid activities associated
with mapping logical system views to the
physical deployment of components. For
example, in a CORBA [5] based system,
automated creation of appropriate
CORBA stubs and skeletons when
communicating components are placed
on different processors.
2.3 View Integration
The development process defined here makes
use of a number of views and subviews in a number
of different contexts. Individual views also evolve
throughout the process. This presents several
challenges related to the management of these
multiple views.
Integration of multiple views covers a number
of different issues. The first issue is ensuring and/or
checking consistency between views. If there are
two views or subviews that are intended to be views
of the same system, do they in fact represent the
same system? If two views of a system are
consistent, and one is modified, does the other view
need to be modified to maintain consistency, and if
so how? Many of these questions and related ones
require developing mappings between the metamodels for each view. In a team-oriented
development process, a key question related to
consistency is how to manage concurrent access to
multiple views of a system. For example, if one
agent acquires write access to one view, should
other agents be prohibited from acquiring write
access or even read access to other views? Other
issues related to integrating multiple views include
configuration management of views, identifying
views relevant for particular analysis approaches,
and performing analyses that span multiple views.
3 Model-Based Analysis
The second of the three key enabling
technologies for component-based product line
development of avionics systems is the modelbased analysis of components and systems, in
particular for their non-functional properties. The
preceding section identified a number of models
appropriate for capturing non-functional aspects of
avionics systems. For brevity, this section describes
one of several types of analysis that could be
performed on such models, and that would
contribute
significantly
to
the
effective
development of avionics by supplementing existing
techniques with explicit analysis to reduce the risk
of costly rework.
3.1 Execution Dependencies
Even though they are at the heart of system
behavior, automated analysis tools for exploring the
impact of execution dependencies are currently
lacking. One type of analysis that would be very
valuable
would
be
checking
execution
dependencies for consistencies, in particular,
automatically checking the consistency of the
execution dependency subgraphs within different
system modes. Other types of execution
dependency analysis include identifying trigger
type mismatches between components generating
and responding to triggers, and the analysis of rates
associated with generating and responding
components, and dependency subgraphs.
4 Model-Based
Configuration
The third of the three key enabling
technologies for component-based product line
development of avionics systems is model-based
automated creation of configuration data and code.
Manual creation of configuration data and code
associated with all modeling views is a tedious and
error prone task in current systems. Although our
current approach includes some automation, it relies
on the component integrators manually populating a
configuration spreadsheet, and too much of the
configuration code is created manually. The
realization of the modeling and analysis
technologies called for in the preceding sections
will make available explicitly in the various models
of the views exactly the information needed to
populate the configuration spreadsheet and the
configuration code. This provides an excellent
5
opportunity for additional
automated generation of
much of this software.
Automated generation
of configuration data and
code associated with the
areas of 1) component
allocation and instantiation;
2) execution dependencies;
3) fault management modes;
and 4) threading allocation
and scheduling should be
realizable. Meta-generator
technology
could
be
exploited to support creation
of specific code generators
corresponding to specific
models.
5 Conclusion
View-Based Models
Input
Translation
Application
Component
Library
Reusable
Reusable
Components
Components
Parse
Parse Rose
Rose
Inter-View
Translation
Model
Editor
Model
Model
Importer
Importer
Fault
Fault
Tolerance
Tolerance
Event
Event
Dependencies
Dependencies
Logical
Logical
Fault
Fault Mgmt
Mgmt
Threading
Threading
Filter/Translate
Filter/Translate
To
To XML
XML
Analysis
Analysis
Translation
Event
Event
Dependency
Dependency
Invocation
Invocation
Dependency
Dependency
Component
Component
Thread
Thread Map.
Map.
Analysis
Interchange
Format
Timing
Timing
Generation
OEP
Configuration
Configure
Configure
Process
Process
Component
Component
Allocation
Allocation
Physical
Physical
Fault
Fault Mgmt
Mgmt
Build
Build
Configuration
Translation
Test
Test
Instrumentation
Figure 2: Model-Based Avionics System Component Integration
Process Summary
In this paper a vision
for model-based integration
of
component-based
avionics systems has been presented and
advancements in three key technology areas that are
needed to make that vision a reality have been
identified. Figure 2 summarizes this vision and the
relationships between the technology areas and
challenges.
We are involved in several activities that work
toward making this vision a reality. Our role on
these programs is to define real-world technical
challenges to provide a context for research,
provide an Open Experimental Platform (OEP)
including a reusable CORBA-based middleware
framework and application components for
integrated experimentation, collaborate with
technology developers to define an open tool
integration framework that fits our proposed modeldriven development process, and define and execute
a set of experiments to evaluate research products.
In the summer of 2002 we experimented with
creating systems up to ~50 component instances
using these tools and techniques, and were able to
roughly double the aggregate productivity of
component integrators. We have recently created
systems of up to ~400 components using a refined
set of tools, including most of the development
steps described herein, and expect the benefits of
the approach to prove even more valuable for these
larger systems.
References
[1] Winter, Don C., “Modular, Reusable Flight
Software For Production Aircraft”, 15th AIAA/IEEE
Digital Avionics Systems Conference Proceedings,
p. 401-406, 1996.
[2] Sharp, David C., “Reducing Avionics Software
Cost Through Component Based Product Line
Development”, Software Technology Conference,
1998.
[3] Kruchten, Phillipe, “Architectural Blueprints—
The ‘4+1’ View Model of Software Architecture”,
IEEE Software, November 1995, pp. 42-50.
[4] Hofmeister, Christine; Nord, Robert; Soni,
Dilip, Applied Software Architecture, AddisonWesley, 2000.
[5] Object Management Group, Inc., The Common
Object Request Broker Architecture and
Specification; Revision 2.0, Framingham, MA,
Object Management Group, http://www.omg.com.
6