In Proceedings of the Automotive Software Workshop on Future Generation Software Architectures in the Automotive

Domain, San Diego, CA, Jan. 10-12, 2004.

Two-tiered Architectural Design for Automotive Control Systems:

An Experience Report

Kevin Steppe, Greg Bylenok, David Garlan, Bradley Schmerl,

Kanat Abirov, Nataliya Shevchenko
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA 15221
{ksteppe,gbylenok,garlan,schmerl,kanatknt,san}@cs.cmu.edu

chosen to support distributed interaction between compo-

nents, and component libraries can be used to select im-
Abstract plementations for the abstract components.
An attractive approach to architecture-based design is While attractive in principle, a two-tiered approach to
to structure the development process into two tiers. The model-based development raises a number of interesting
top tier represents the abstract design (or architecture) of issues that have yet to be fully understood. What kinds of
a system in terms of abstract components. The bottom tier notations are best used to represent the two levels? What
refines that design by making specific implementation kinds of architectural features should be modeled at each
decisions, such as platform, middleware, and component level? What parts of the refinement process can be auto-
implementations. While attractive in principle, there has mated? How well does the approach scale to realistic sys-
been relatively little industrial-based experience to shed tems? To what extent does the application domain influ-
light on problems and solutions involved in such an ap- ence the process and artifacts?
proach. In this paper we describe our experience in de- In this paper we offer insight into these issues by de-
veloping tools to introduce a two-tiered model-based ap- scribing our experience of developing a tool to support
proach to the design of Ford Motor Company’s automo- two-tiered design methods for automotive control systems
tive control systems, highlighting the principle chal- at Ford Motor Company. Currently, Ford has detailed
lenges, and evaluating the effectiveness of our solutions component specifications in the form of Simulink [9]
for them. models. However, they are currently only able to perform
Keywords: Model-driven architecture, architecture- component level analyses. Composition of the Simulink
based design, architecture design tools, software devel- models is currently performed manually, and even con-
opment environments. structing small subsystems can take a matter of weeks;
composing an entire automotive software system is infea-
1. Introduction sible with this approach. Our goal was to provide auto-
mated assistance that introduces a two-tiered modeling
Over the past decade industry has become increasingly process and dovetails well with Ford’s current practices.
aware of the value of architectural models and architec- In particular, Ford engineers desire to initially design
ture-based design. Architectural models define a system their systems at a high level of abstraction in terms of
at a high level of abstraction – typically in terms of a sys- abstract entities such as controllers, sensors, and schedul-
tem’s interacting components – where major design trade- ers. These components could then be associated with spe-
offs can be analyzed before committing to a particular cific component implementations and their Simulink
implementation. Architecture-based design typically starts models, and used to automatically produce a more de-
with an abstract architecture and then refines that model tailed composition on which detailed design analysis
to the point where the system can be directly imple- could take place.
mented. As we will illustrate, architecture description lan-
For many classes of system it is helpful to structure the guages and their associated tools can play a central role in
process of architecture-based design into two phases. In supporting two-tiered architectural design. However,
the first phase system architects design a system in terms there were a number of difficult technical hurdles that we
of abstract capability, postponing implementation deci- had to surmount – hurdles that we suspect will be charac-
sions, such as execution platforms, communications infra- teristic of many other domains in which this kind of sup-
structure, and component implementations. In the second port is required. Section 2 discusses some related work. In
phase implementation commitments are made in a struc- Section 3 we discuss the approach we used, give an over-
tured and systematic way. For example, abstract compo- view of our tool (called Synergy), and present an example
nents can be assigned to platforms, middleware can be
problem to provide context. Section 4 & 5 discuss the terms. We then briefly introduce an architectural tool,
notational and technical issues encountered and the solu- AcmeStudio, which is a typical software architecture en-
tions we used. We conclude with a review of the imple- vironment. Following this, we show how Synergy, an
mentation status and evaluation of results. augmentation of AcmeStudio, supports the scenario.

2. Related Work 3.1. The Problem

The use of two-tiered approaches to software devel- Ford Motor Company, like many in the automotive in-
opment extends back to early specification languages, dustry, build software systems for all their car models.
such as Larch [6], which advocated the separation of The software used in these systems is life critical, where
abstract capability from implementation details. More the failure can cause loss of human life. To address this,
recently the Object Manage Group has been promoting Ford develops Simulink models of their componentry so
model-based design using a two-tiered approach that they that they can conduct rigorous analyses of these compo-
refer to as “Model-Driven Architecture.” (MDA) [10]. nents to help ensure reliability. These models are a de-
MDA is motivated by similar concerns to ours, but tailed specification indicating all component interfaces in
attempts to advance the state of understanding about how addition to properties supporting simulation. Component
to carry out such an approach in the context of real models are reused and iteratively changed across projects.
systems, complementing existing development methods, Despite having the ability to analyze individual com-
and leveraging special features of a product domain (in ponents, producing assemblies of these components to be
our case automotive control systems). analyzed is problematic and does not scale. Currently,
Within the area of architectural design, many people these compositions, if they are built at all, are constructed
have advocated the importance of multi-view approaches manually. Because components typically have dozens of
[3][8]. A two-tiered architectural method can be viewed interfaces each, manually connecting them is tedious and
as a specialization of such approaches, focusing on two error prone. One of Ford’s main needs is to determine
specific architectural views: an abstract and a concrete whether all input ports in a model are connected. If any
view. The specialization allows one to consider general input port has not been connected the final system will
questions of multi-view consistency, and requirements for not work. However, for a typical six component subsys-
multi-view tools in a more limited, but tractable, context. tem, Ford engineers report that construction takes ap-
There has been considerable recent interest in model- proximately two weeks. The handful of large (50 compo-
based approaches to embedded control systems, such as nent) vehicle control subsystems developed have taken
automotive and avionic. For example, the DARPA- six months to produce.
sponsored MoBIES Project specifically focuses on this Factor in that there are multiple choices for each com-
area, and has developed a number of techniques, nota- ponent (e.g., it is possible to use one of several wind
tions, and tools [2]. Our work fits within that general shield wiper servos), and the combinatorial explosion of
category of research, but explores the specific conse- possible combinations quickly makes manual construc-
quences of using architecture description languages as the tion absolutely infeasible.
carriers of embedded systems designs. However, this problem presents an ideal opportunity
The ISIS group at Vanderbilt has been working with for automated tool support. Typically, engineers think of
Ford on a similar project [7]. They have so far focused constructing their software in terms of abstract system
primarily on handling constraint satisfaction within a architectures. Detailed compositions, called assemblies,
large design space through BDD trees. Their solution are only necessary when performing detailed analysis.
uses a single abstract view and presents the acceptable Thus, we introduced a two-tiered modeling approach that
solutions to the given constraints. The single view model, reflected this, and allowed assemblies and composed
however, prevents the user from fine-tuning or validating Simulink models to be automatically generated.
the selections.
3.2. Overview of Approach
3. Two-tiered Architectural Design Thinking about a software system in terms of its com-
ponents and interactions can be represented with software
In this section we describe a motivating example that
architectures [1][11][14]. A software architecture repre-
is typical of the work of a Ford engineer designing an
sents a system in such a way, and is amenable to auto-
automotive software system. We cover the architectural
matic analysis. To model an architecture in a specific do-
styles for background. We describe in general terms a
main, it is common to use an architectural style [4]. An
scenario of what engineers need to do, and then continue
architectural style is a vocabulary of the possible types of
with how to think about this example in architectural
components, connectors, and interfaces that can be used
in a particular domain, in addition to rules governing the
correct composition of these elements. RootT
To address the problem described above, we intro-
duced two levels of architecture representation to be used
by Ford: the high-level System Architecture and the low- BaseT ExternalT
level Assemblies. These levels of abstraction are repre-
sented by two related architectural styles, which will be
discussed in Section 3.3. In this section, we discuss a SchedulerT IODriverT DigitalDeviceT
typical scenario for which Ford engineers desire tool sup-
port. ControllerT PlantT SensorT
An engineer starts designing the software for a car by
creating a high level architecture of the system. At this
Figure 1. The Component Types of the Sys-
level, the engineer is only concerned with the high-level tem Architectural Style.
vocabulary of Servos, Managers, etc, rather than particu-
lar implementations or specializations of these. For ex-
ample, at this level the engineer may only be concerned Architecture style to create abstract architectural models.
with putting together a system architecture for the cruise These models are then translated by the tool into architec-
control aspect of the car, and not be concerned about the tural models in the Ford-AssemblyR style.
low level details such as particular connections, timing To design these styles, we analyzed documents, Mat-
requirements, or memory footprint of particular lab models, and papers provided by Ford researchers. We
implementations of a cruise control manager for a then created Acme families based on these artifacts by
particular car model. At this level, the engineer is defining element types and creating rules. The high-level
concerned with whether the system is well-formed and vocabularies of these styles consist of component types,
consistent, and also which subsystems of the car interact their expected forms of interaction in the form of connec-
with other subsystems. Because the system architecture is tor and interface types, and a set of constraints (heuristics
abstract, it can be reused in other products, both within and invariants) on how components should be assembled
Ford or its subsidiary companies. into abstract or low-level systems.
After creating the system architecture, the engineer The Ford System Architectural style consists of the
associates the abstract components with component mod- following elements:
els that are stored in a repository and which may be re- - Ten component types organized as depicted in
lated to particular products within the automotive lines. Figure 0. The component type RootT defines a
They are reused for new abstract architectures. property allowing a component characterization
In order to manage the complexity of the architecture, to be assigned to a component. At this level, the
the engineer may divide the architecture into sub-systems components in the architectural style merely in-
and compose them in a hierarchical fashion. In such cases teract with other components via input and out-
the user must associate the deepest components of an ab- put ports. These ports are defined in BaseT. Ex-
stract component with component characterizations. ternalT represents the point of interaction be-
After associating abstract components with characteri- tween the subsystem being defined and other
zations of those components, the engineer needs to pro- systems. For example, if the cruise control sub-
duce an assembly from this abstract design. This assem- system must interact with the brake subsystem, it
bly is based upon platform-specific information provided does so through this component.
by the component characterizations, and involves choos- - One connector type, called CSignalT that all
ing among multiple alternatives for components. components at this level must interact through.
The final step of the process is translating assemblies - Associated port and role types for input and out-
into Matlab/Simulink models of the entire subsystem. The put, representing interaction points between
assemblies can then be imported into Matlab, and pre- components and connectors.
existing analyses and simulations of the system can be Figure 0 illustrates the abstract architecture of our ex-
conducted. ample cruise control system. At this level, the architec-
tural style is not particularly rich. Ford engineers are only
3.3. Architectural styles concerned about the interconnections between compo-
nents at this level. Rules specify that all ports must be
Although each tier of our approach is closely related, attached to roles, and that BaseT’s contain a single ab-
we developed two architectural styles to allow modeling stract input and output port.
at each level in Acme [5]. When working at the system At the Assembly level, engineers are concerned with
architecture level, Ford engineers use the Ford-System detailed knowledge of the connections between compo-
nents. Thus, while the component types at this level are
the same as at the abstract architectural level they may
have any number of input and output ports showing de-
tailed communication. Additionally there are two new
connector types:
- ManSignalT, indicating a signal connection
added by the user at the assembly level rather
than automatically generated from the system ar-
chitecture.
- Bus, representing a specific publish-subscribe or
shared data bus connection.
Because architectures in this style are generated from Figure 2. The System Architecture of the
the higher design, this style does not have any new rules Design.
on its connections. Similar rules to the high level are In this experience we extended AcmeStudio so that it
maintained in case engineers manipulate the model at this supports the two architectural styles that were developed
level. for Ford, the ability to read Ford’s Simulink component
Generation of the Assembly level from the System Ar- models, and generation of assemblies from high level
chitecture level involves elaborating connections between system architectures. This tool is called Synergy. In this
components in detail. All the possible ports on a compo- section we give an example of using Synergy to support
nent are enumerated. Then all legal connections for those the scenario described above. In later sections, we discuss
ports to other components are made. This detail is pro- the issues that we needed to resolve in order to make this
vided through the component characterizations and the tool useful to Ford engineers.
connections made at the system architecture level.
3.4.1 Creating the abstract design
3.4. Overview of Synergy To illustrate the use of Synergy, and to give an impres-
sion of its capabilities, we follow the design of a simple
A typical architectural development environment pro- and generic cruise control system. The demo system dis-
vides support for producing architectural models, and cussed further in the paper is rather simple.
conducting architectural analysis to determine properties The system represents a cruise control system that con-
of the model, such as performance, quality, and correct- sists of the following components:
ness. - “ExternalIO”. This ExternalT component provides a
Many architectural design tools are written to work bridge between this system and other outside sys-
with a particular architectural style, and making them tems. This component sends parameters to “Sched-
work with other or customized architectural styles is dif- uler” and “Manager” components such as scheduling
ficult. More recently, architectural tools have been devel- periods and cruise settings respectively.
oped that allow users to customize the environment based - “Scheduler”. This SchedulerT component manages
on particular architectural styles. Among these include usage of hardware resources of the system and sched-
Unicon [15], Mae [12], and AcmeStudio [13]. ules all the components.
We used AcmeStudio as a basis for this project. - “Manager”. This ControllerT component is responsi-
AcmeStudio is a style-neutral architecture development ble for controlling the Servo component.
environment that can use any style written in Acme and - “Servo”. The ActuatorT component manipulates
tailor the environment for that style. It provides access to physical devices. The physical devices are not in-
the element types in the style, style-specific depictions of cluded in this example, but can be modeled with
elements in the architectural diagram, and support for PlantT components.
analysis of rules. Quite recently, AcmeStudio has been - “Monitor” is a SensorT type which reads data about
retargeted to the Eclipse platform, which enables exten- the hardware from the servo and sends results to the
sion through the notion of plugins. AcmeStudio takes manager.
advantage of this feature to allow style-specific analysis The user creates an abstract architecture of the demo sys-
to be integrated and used by designers. These extensions tem without any platform specific details (see Figure 0).
allow customization of the user interface, specialized At this abstract level a component of the architecture is
views of the architecture, and access to extra analyses. represented with two ports (input and output). These in-
This meant that it was possible to reuse a large body of put and output ports are interfaces to other components of
code, and concentrate only on the areas specific to Ford. the design. Connectors are represented as buses that con-
nect interfaces of the architecture’s components.
 stract level. These buses are refined as end-to-end
connectors, each having only two roles connecting
two neighboring components.
At this time legal connections are defined by a match
of input port name and output port name. The buses cre-
ated in the system architecture are first represented as
hashtables. The name of output ports connected to the
high level bus is added to the table. Then, for every input
port connected to the bus, the corresponding output port
is found in the table and a point-to-point connector is
added to the assembly. Subsystems are handled recur-
sively, built from the bottom up. Though no data have
been collected, this solution should scale linearly with the
total number of ports in the system – an important feature
as a large system could contain thousands of ports.
For example, onsider the bus in between the ‘Sched-
uler’ and ‘Monitor’ in Figure 2. That bus becomes a
hashtable of all the output ports from the scheduler com-
ponent. The Manager, Monitor, and Servo components all
Figure 3. The user links Acme components to
Matlab/Simulink models. have input ports attached to the bus and thus may search
that hashtable for connections. For the ‘Monitor’, the port
After creating the abstract architecture Ford engineers named ‘trig_etc_monitor_fast’ will match with the output
must either associate each component to existing Simu- port of the same name on the ‘Scheduler’ component as
link models or refine the component as a subsystem. shown in Figure 4.
Synergy allows the user to browse and select a Simulink Such detailed representations of components and con-
model to associate with a component in the project, as nectors empower the user with the ability to conduct com-
depicted in Figure 0. In this version of Synergy, there is plex analyses using heuristics and constraints of Acme
currently no check that the right kind of Simulink model architecture description language and/or custom-
is assigned to a component. For example, a scheduler developed analyses that could be plugged into Synergy.
model could be assigned to an Actuator component. An We added two analyses that demonstrate this plug-in
error of this sort only becomes apparent in later stages of feature. The first takes a numerical property (CPU usage
the design. in our case) and sums across all components, checking if
Design choices between alternative Simulink models the final total is less than the system wide constraint
or subsystems can be specified through AcmeStudio’s specified by the user. The second gives a suggested
support for multiple representations. For each possible scheduling order, by creating a dependency graph using
choice, a new representation of a component is created, Apache’s Commons project graph code. Cycles are iden-
with subcomponents. A component characterization rep- tified and reported, then a possible ordering suggested.
resenting the particular alternative is then assigned to
subcomponents. 3.4.3 Generating Simulink Models
Ford’s primary model analysis tool is Mat-
3.4.2 Creating the assemblies
lab/Simulink. Thus it was vital that Synergy produce
After the user creates the abstract architecture and as- Simulink models from the designs. As noted above, all
sociates its components with component characteriza- the atomic components are linked to Simulink models.
tions, Synergy allows the user to generate low-level archi- Additionally, all the ports in the assembly view map di-
tecture alternatives or “Assemblies”. The low-level archi- rectly to ports in the Simulink model. Using those map-
tecture elaborates details of the abstract architecture and pings Synergy generates a model using the Simulink
they are described as follows: scripting language. An example of the Simulink model
- The set of input and output ports are completely generated by Synergy is presented in Figure 4. Once run
enumerated. These sets are detailed refinements of through Simulink the model can be re-imported into Syn-
the abstract input and output ports shown in System ergy as a single component, allowing for iterative devel-
Architecture. opment of ever larger models.
- Connectors of the design at the assembly level are
detailed representations of the buses used at the ab-
 Figure 4.The Assembly for the Design.

Summarizing this example – we have given Ford ar- sitions, the abstract level needed to be easily created by
chitectural styles tailored to their domain modeling prob- the user. We also wanted the ability to do some analysis
lems. AcmeStudio provides an effective tool for develop- at the abstract level before generating detailed assemblies.
ing abstract architectures of vehicle control systems. The The detailed level had to support the many ports and con-
Synergy extension to AcmeStudio automatically gener- nections present in the system as well as the properties to
ates a more detailed view of the ‘assembly’. The user is be analyzed. In our case we used the Acme ADL for both
then able to review, analyze, and modify the details of the levels. To better represent the features of the two levels,
design. Finally the entire assembly can be converted to we used different architectural families for the two levels.
Simulink for further analyses. The family provides and requires the attributes and design
restrictions appropriate to that level. While it would be
possible to use different languages for each level, using
4. Representation of component architec- the same one as in our case means that engineers don’t
tures have to learn to two different tools. And since both views
and manipulations are architectural, it made sense to use
the same language.
Although in the example above, the use of Synergy
seems straightforward (because it was designed that way),
we had to deal with a number of representational issues. 4.2. Hierarchy
Other architectural approaches to multilevel design are
Ford’s vehicle control models are likely to include one
likely to encounter similar issues.
hundred different components. Managing that scale re-
quires breaking the system into modules and subsystems
4.1. Styles of multiple representations
via architectural hierarchy. In fact, Ford engineers gener-
ally work with only five or six components at a time, con-
The most obvious issue in multilevel design is how to
structing large systems from these subsystems. Addition-
represent each level. We needed two design levels, the
ally, hierarchy provides a mechanism for re-using assem-
more abstract System Architecture, and the detailed As-
blies. Thus large architectures can be built in a bottom-up
sembly. As our intent was to simplify component compo-
 Figure 5. The Simulink Model generated by Synergy

approach from previously built assemblies. In our case to using hierarchy and building progressively larger archi-
hierarchical design was supported through Acme repre- tectures. The question becomes how that interface is de-
sentations. In representations, the abstract component is a termined. Options include explicit specification by the
place-holder for the underlying sub-structure, a scheme designer, automatic generation from the available ports of
which matched our intended use of hierarchy. the system, or leaving unbound ports. Explicit specifica-
The interface to the subsystem must be clear for the tion enables the system to check for completeness, but
engineer to make use of the subsystem. At the system requires a lot of extra work for complicated interfaces.
architecture level a single input and output port is suffi- Automatic generation is easier on the user, but could
cient, however the details must be identified somewhere. mask incompleteness by generating additional inputs.
This interface must also be mapped to ports within the Leaving unbound ports allows the user to review the in-
sub-structure. In some cases the mapping from external complete system to pick needed inputs, but prevents full
port or ports to internal structure will have higher than 1:1 analysis. One of Ford’s main needs is to determine
cardinality – for example an internal source ‘A’ may sup- whether all input ports in a model are connected. If any
ply data to two components outside the subsystem. In input port has not been connected the final system will
these cases a mechanism for one to many mapping is not work. Thus we chose to have the interfaces be ex-
needed which can distinguish the different possible mean- plicit. Having explicit interfaces allows us to check and
ings applicable to the domain. One to many mappings verify the completeness of the system, both for inputs and
could be fan-in, fan-out, a priority arrangement, a rotation expected outputs.
of usage, or some other meaning depending on the do- However, within hand built sub-systems, we generated
main. Some method is required to indicate this choice in the interface from unsatisfied input (or required) ports,
the model (so that it can be used in analysis, for example). and any output ports used by the rest of the system. We
Unfortunately, no mechanism currently exists in Acme to did not allow the user to specify or restrict which compo-
make this possible, and so handling different kinds of one nents (or ports) within a sub-system would map to its
to many mappings was not supported. interface. For the highest level of the System Architecture
the user must specify the interface through the use of spe-
4.3. External interfaces cial components representing external systems. This is not
an especially intuitive mechanism. A more intuitive
Any design will need to interface with other systems, model would make a single choice between generated and
requiring that the system representation includes facilities specified interfaces. However, the method does allow for
for identifying that interface. The interface is also crucial a designer to maintain control of the interface to be ex-
posed to other systems, while making modularization well as properties added by the user directly to the archi-
within the system easy. tecture description. The second set of properties is pulled
from the Simulink models – either analyzed through
4.4. Expression of alternatives Simulink directly or added to the architectural description
automatically. The component linking mentioned above
For Ford, exploration of design alternatives is an im- enables Ford to take full advantage of Simulink’s power
portant feature. With a large collection of components on assemblies generated by Synergy. Lastly, our tool uses
there are often multiple choices which fulfill the required its own component characterization file. Properties added
interface yet still have different properties. Ford often to the characterization can be analyzed through an analy-
uses a single architecture across several car makes and sis plug-in framework in Synergy.
models, the differences coming in the choice of compo-
nents to fill in that architecture. The abstract component We presented a number of questions at the beginning
representation must be able to express these alternatives. of the section. The solutions we chose to these issues
Since the number of alternatives grows exponentially, the heavily influenced the development of Synergy. Similar
scalability of constraint checking across the possibilities but separate styles make automatic conversion easy, while
may be heavily dependant on representation. Even after supporting the difference in detail. We used AcmeStu-
constraint checking, a single system architecture can gen- dio’s built in representations to support hierarchy and
erate a large number of assemblies. Each of these will thus enable generation of large modules in an understand-
need to be stored and presented in some navigable man- able fashion. The external interface for a design is speci-
ner. The user may also wish to review how constraint fied by the user through use of a special component. In-
checks eliminated certain alternatives, requiring the soft- ternally, Synergy automatically generates the interface
ware to present easily searched reports on the fate of all between hierarchical levels. Design space is also sup-
choices. ported by Acme representations, considering them to be
Vanderbilt used a special alternative component type mutually exclusive alternatives. Linking to existing mod-
to indicate choices. We used Acme’s allowance for mul- els is provided by Acme properties and a convenient
tiple representations to express choice points. Each rep- browser dialog. Lastly, an analysis plug-in framework is
resentation for a component represents a potential choice. part of both Synergy and AcmeStudio. We felt that our
This mechanism is fairly heavy for a choice between two architectural representation is rich enough to support
components. However, it does allow for choice points many more analyses than we could develop. Thus we
between entire subsystems – which may contain their own built Synergy to make it simple for the customer to add
choice points. more without having to address representational issues.

4.5. Component linking 5. Tooling Issues

When the design must link to an existing set of com- Usable multilevel design software requires more than
ponents or models, the architecture description needs to just appropriate representation solutions. The user needs
support that link. Component linking is especially impor- to be able to construct architectures easily, view them,
tant when the architecture must integrate with external and analyze them – often using other software. In par-
tools as discussed in 4.6. We used a property on each ticular the developer must provide tool support for
component to indicate which model to link to the archi- graphical editing, layout of generated views, and integra-
tectural component. Every component to be used is tion with other analysis tools. Lastly, as there are multiple
placed within the project directory making selection via a views representing the same design, consistency checking
browser easy. Unfortunately we did not find a way to is also important.
prevent erroneous linkages – such as mechanical models
with software models. Using a property rather than nam- 5.1. Visualization & usability
ing, allows the user to construct the architecture using a
naming scheme appropriate for that design while linking Software architectures can be described using an archi-
to models named with a different scheme. tectural description language, but a textual description
may be difficult for users to read and understand. It is
4.6. Analysis support more natural to deal with the architecture graphically,
where relationships between components can be made
Additionally various properties are needed to support clear. Since we had adopted the Acme architectural de-
analysis of the system. We supported analysis on three scription language, we could utilize the AcmeStudio de-
different kinds of properties. The first kind is checked by sign tool to provide a graphical visualization of the
AcmeStudio and includes architectural constraints, as model. AcmeStudio also provides a way for users to
compose models visually. To create a new model, users Translating the models between Simulink and Acme was
simply drag-and-drop new components from a palette of fairly straightforward.
pre-defined types. Beginning users will likely stick to the Once settling on the Acme ADL, the team was able to
graphical user interface, however, advanced users may make advantageous use of the existing Acme toolset.
still edit the underlying Acme architectural description Foremost among these was AcmeStudio, a tool for com-
directly. posing and analyzing Acme models. AcmeStudio is itself
built upon the Eclipse open-source development envi-
5.2. Layout Tools ronment. Eclipse provides a ready-made framework for
integrating individual development tools under a common
Rather than generating source-code from a model, our user interface. The cornerstone of this framework is a
modeling tool generates one model from another. Once well-developed plug-in mechanism for expanding a tool's
generated, the user must be able to visually inspect the capabilities. The Eclipse framework allowed the team to
new model. The newly generated model contains signifi- deliver the core functionality in one plug-in, saving ad-
cantly more detail than the source model, and care must vanced forms of analysis for a later plug-in. Several more
be taken to keep the model readable. Components should plug-ins supporting additional data formats and analyses
be laid out intelligently so that connections between com- will expand the tool's usefulness and reach.
ponents remain clear. Clarity remains a challenge within
these highly detailed models, where each component may 5.4. Consistency Issues
involve twenty to thirty individual connections.
The right layout algorithm can help reduce the visual With multiple models involved in the development
complexity of the generated diagram. Existing graph lay- process, consistency between models becomes an impor-
out algorithms generally try to optimize a particular aes- tant issue. The tool gives the developer free-reign to
thetic quality of the diagram, for example, minimizing the tinker with the design at both the high and low levels of
number of connection bends and overlaps. Choosing an abstraction, so keeping everything synchronized remains
algorithm is generally a tradeoff between these different a challenge. Changes to the system architecture or indi-
aesthetics, as well as running time and development ef- vidual component models must be carried forward into
fort. In the end, the team settled for a heuristic-based ap- the generated assemblies. Today, this is accomplished
proach. The layout algorithm used here takes the original automatically by regenerating the assemblies. Reverse
system architecture as a starting point, adjusting the posi- engineering is not supported, because developers are ex-
tions of components to meet a minimum acceptable level pected to make at most minor targeted changes to the as-
of readability. This helps promote some correspondence semblies.
between the system architecture and generated assembly.
It provides the user some influence over the generated We used AcmeStudio to provide graphical editing of
layout, but it relies on the user to place components intel- architectures as well as the previously mentioned repre-
ligently within the system architecture. sentational facilities. Automatic layout will always be
difficult for larger, more complicated systems. To sim-
5.3. Integration with analysis tools plify the problem we took advantage of the user con-
structed system architecture as a starting point. Integra-
The tool fills a small but critical niche in the model- tion with other tools was a major requirement from Ford,
based development cycle, so it should not be considered a which led us to select Eclipse and AcmeStudio as a base
stand-alone tool. Rather, it must work in cooperation with for plug-in development. Ford is focused on the architec-
the other tools at the modeler's disposal. Foremost among ture and pushing for automatic generation, thus Synergy
these is the Mathwork's Simulink modeling and analysis maintains consistency in a feed-forward mechanism, re-
package. Simulink provides the individual component generating the detailed model when requested.
models that serve as building blocks within our tool.
Simulink also provides advanced analysis capabilities for 6. Implementation status
verifying completed assemblies. Our tool must therefore
be able to translate models to and from Simulink. Synergy has been built and delivered to Ford. Synergy
Unlike in the object-oriented world, the embedded sys- is best considered a prototype at an alpha or beta devel-
tems community has yet to adopt a standard format for opment status. Ford is currently evaluating the tool, and
exchanging models between tools. In the meantime, tool has expressed interest in further development.
developers must choose from one of several candidate Synergy was created by five students in the Master of
formats. Acme's roots as a generic description language Software Engineering program at Carnegie Mellon Uni-
makes it a suitable candidate for model interchange. versity. Our experience report comes from one calendar
year of work as part of the masters program. Synergy is
an augmentation of AcmeStudio and uses AcmeLib, both for them. The more challenging issues will be difficult to
developed by the ABLE group at Carnegie Mellon. As of solve if they are not considered upfront.
writing, Synergy contains about 160 source files using
Eclipse, AcmeStudio and AcmeLib. To support Ford’s Acknowledgements
interest in further development, another group of masters
students will be working on Synergy over the next year. The authors wish to acknowledge funding from Ford
Areas for future work include: Motor Company for this work. In particular, we thank
- Improving support for hierarchy through interface Ken Butts and William Milam for providing feedback on
specification or restriction. our work.
- Development of more architectural design rules and
heuristics.
References
- Improved component layout generation.
- Integration with Ford’s enterprise wide repository of [1] Bass, L., Clements, P., and Kazman, R. Software Architec-
components, possibly including automated search. ture in Practice. Addison-Wesley, 1999.
[2] Bay, J.B. Model-Based Integration of Embedded Software.
http://dtsn.darpa.mil/ixo/programdetail.asp?progid=38.
7. Evaluation [3] Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J.,
Little, R., Nord, R., and Stafford, J. Document Software Ar-
chtiectures: Views and Beyond. Addison-Wesley, 2002.
While Ford has had considerable success in simulating
[4] Garlan, D., Allen, R.J., and Ockerbloom, J. Exploiting
individual software components, the complexity of build- Style in Architectural Design. Proc. SIGSOFT '94 Symposium
ing assemblies of components has prevented larger scale on the Foundations of Software Engineering, New Orleans, LA,
model development. We took a two-tiered approach to 1994.
solving the problem. The user is able to work with [5] Garlan, D., Monroe, R.T., and Wile, D. Acme: Architec-
enough abstraction to design a large system. Synergy tural Description of Component-Based Systems. Foundations of
then automates the time consuming process of connecting Component-Based Systems. Leavens, G.T., and Sitaraman, M.
the components and checking constraints across alterna- (eds). Cambridge University Press, 2000 pp. 47-68.
tives. As discussed earlier, Synergy also handles issues [6] Guttag, J.V., and Horning, J.J. (Eds) Larch: Languages and
Tools for Formal Specification. Springer-Verlag, 1993.
such as component linking, consistency, and hierarchy.
[7] Karsai, G, Sztipanovits, J., Ledeczi, A., and Bapty, T.
The initial reaction from Ford has been very positive. Model-Integrated Development of Embedded Software. Pro-
In a demo we were able to build a system in twenty min- ceedings of the IEEE 91(1):145-164, 2003.
utes that would have previously taken two weeks. They [8] Kruchten, P.B. The 4+1 View Model of Architecture. IEEE
estimate that large systems which took six months previ- Software, 2(6):42-50, 1995.
ously, would now take about two weeks. [9] The Mathworks. Simulink 5.1.
The Synergy project illustrates a number of lessons. http://www.mathworks.com/products/simulink.
There are several notational and tool support issues which [10] Object Management Group. MDA: The Architecture of
any similar endeavor will encounter. To be useful the tool Choice for a Changing World. http://www.omg.org/mda.
must support graphical construction of architectures and [11] Perry, D.E., and Wolf, A.L. Foundations for the Study of
Software Architecture. ACM SIGSOFT Software Engineering
layout of any generated diagrams. If editing is allowed at
Notes, 17(4):40-52, 1992.
all levels, consistency becomes a particularly difficult [12] Roshandel R., van der Hoek A., Mikic-Rakic M., Medvi-
problem. The notation of the solution must contain repre- dovic N., Mae - A System Model and Environment for Manag-
sentations for hierarchy or else the designs will be too ing Architectural Evolution, Submitted to ACM Transactions on
complex to be understood. A means of specifying the Software Engineering and Methodology (In review), 2002.
system’s interface is needed as well as a way of linking to [13] Schmerl, B., and Garlan, D. Exploiting Architectural De-
existing component characterizations. For domains where sign Knowledge to Support Self-repairing Systems. Proc. 14th
a large number of components exist, expression of design International Conference on Software Engineering and Knowl-
choices and constraint satisfaction are particularly impor- edge Engineering, July, 2002.
[14] Shaw, M., and Garlan, D. Software Architectures: Perspec-
tant issues. An extensible analysis framework will greatly
tives on an Emerging Discipline. Prentice Hall, 1996.
enhance the system’s value. For example, Ford and Volvo [15] Shaw, M., DeLine, R., Klein, D.V., Ross, T.L., Young,
have similar design and architecture needs. However, the D.M., Zelesnik, G. Abstractions for Software Architectures and
components and analyses they use are different. Synergy Tools to Support Them. IEEE Transactions on Software Engi-
allows both companies to capitalize on the same tool by neering, 21(4):314-335, 1995.
adding analyses specific to their needs rather than build-
ing separate tools.
Not all of these issues are challenging, but a successful
project must have considered and decided upon a solution