Modeling Aerospace Systems Product Lines in SysML

Jess Padilla Gaeta

Krzysztof Czarnecki

jpadillagaeta@gsd.uwaterloo.ca

kczarnec@gsd.uwaterloo.ca

University of Waterloo

University of Waterloo

ABSTRACT

and agree on the scope and other important system properties; they are also means for analysis and automation. A
good model can become the cornerstone of a successful system. However, if modeling one system is challenging, modeling a family of them is even harder. Each family member
is dierent; models must specify accurately which parts are
shared, what can vary, and under which conditions. Further,
the notation used must be well understood by all stakeholders. Thus, relying on standards can be beneficial. SysML
[14] is particularly relevant in the avionics domain. It is
based on UML [13] and many existing tools already support
it; it can also be extended as necessary.
This paper reports on a collaborative eort between the
University of Waterloo and Pratt & Whitney Canada to develop engineering guidance on the use of SysML in the modeling of systems and software product-lines in the aerospace
domain.
The contributions of this work are as follows. First, it defines a method and a pattern catalog for modeling aerospace
systems product lines in SysML. Second, it reports on the
experience in applying the approach in the development of
an industrial systems-product line. The work shows that
SysML is rich enough to model systems variability out of
the box.

As the complexity of avionic systems increases, the aerospace

industry is turning to product-line engineering and modelbased development to better manage complexity and reduce
cost. This paper describes a method and a pattern catalog
for modeling avionics product lines in SysML, a standard
systems modeling language. The method is designed to satisfy aerospace systems and software development standards,
and the patterns provide guidance for expressing variability in SysML. The paper also reports on the experience in
applying the method and the patterns to model families of
propeller controllers and fuel controllers for turbo engines.

Categories and Subject Descriptors

J.7 [Computers in other systems]: Real time

Keywords
systems engineering, embedded software, product-line engineering, model-based engineering, variability modeling, UML,
SysML

1.

INTRODUCTION

Safety-critical embedded systems are becoming more and

more pervasive in modern society. Misoperation of such systems can have serious consequences, such as injury or loss
of life. Thus, companies must ensure that their products
are safe and reliable. In the avionics domain, these systems
have to be certified by national authorities; this process is
costly and time-consuming.
As avionics applications increase in size and complexity,
so are their development, testing, and certification costs.
Therefore, it is not surprising that companies are looking
for new approaches to deal with these challenges. Productlines engineering has been particularly attractive, as it can
reduce costs by reusing common assets across products [16].
Models are assets to improve complexity management.
They provide stakeholders with the means to communicate

2.

BACKGROUND

2.1

Avionic Systems

2.2

SysML

Avionics are the electronic sensors, actuators, computers, networks, and software on an aircraft. Important system qualities such as safety, reliability, and fuel-eciency
are becoming increasingly dependent on the correct operation of these systems [24]. Before such systems can be
used on an aircraft, their correct functioning and adherence to airworthiness requirements must be ensured. For
this purpose, systems and software must be approved by national certification authorities; this process can be lengthy
and time-consuming. Therefore, companies usually follow
standard development guidelines, such as ARP4754A [22],
ARP4761 [21], DO-254 [17], and DO-178C [20]. These standards do not focus only on the correct operation of the final
system but also on a rigorous process being followed during
the whole lifecycle. Thus, any new development approach
must ease the certification process and be compatible with
these standards; failure to do so could be risky and costly.

Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.

SPLC 2015, July 20 - 24, 2015, Nashville, TN, USA

c 2015 Copyright held by the owner/author(s). Publication rights licensed to ACM.

ISBN 978-1-4503-3613-0/15/07. . . $15.00

SysML is a general-purpose graphical modeling language

DOI: http://dx.doi.org/10.1145/2791060.2791104

293

for system engineering, derived from UML and supported

and maintained by the Object Management Group (OMG)
[14]. It allows the specification, analysis, design, verification, and validation of a broad range of complex systems,
which include hardware, software, information, processes,
personnel, and facilities.
Instead of focusing on documents, SysML supports the
so called Model-Based System Engineering (MBSE) [10] approach. It concentrates on defining a structured set of views
stored and managed in a repository, which make up the
model of the system. This organization allows designers to
manage complexity since each view provides an abstracted
representation of the system or part of it.
SysML is becoming an engaging option for modeling avionic
systems. It can be extended to support specialized notations, such as for timing and dependability, while being
vendor and methodology agnostic, and it should be flexible
enough to be adapted to any company needs. Since it is a
profile of UML, a wide variety of tools already support it.

3.

and the parts that can vary. Analogously, an variant model

describes the design of a single product or a subset of the
products of the family; it does so by configuring the family model by restriction and by creating parts exclusive to
the new variant. The variant model may still contain some
variability; for example, it may require so-called Parameter
Data Items (PDI) [20]. PDIs are parameter values that must
be provided at some point during the system lifecycle, such
as at code generation or system-start-up time.
Even though some aspects of the proposed method are
driven by the requirements stipulated in avionics standards,
the method or its parts are likely to be applicable to other
systems domains, such as automotive or railway systems or
medical devices.

4.1

PROPELLER EXAMPLE

We illustrate the method using a constant-speed controller

for a turboprop engine. The power produced by the engine is
used to drive the propeller, which will transform the rotatory
motion into thrust. [6] This type of control system ensures
that the propeller maintains an optimum speed to provide
the necessary thrust and to be fuel ecient. The controller
achieves it by modifying the pitch of the blades dynamically.
Its most relevant features include:
Reversing is an optional mode enabling the engine to
provide negative thrust and the aircraft to decelerate
when on ground.
Closed or Open Loop design may be used to control
the pitch of the propeller blades, relying on an angle
sensor or propeller speed, respectively.

Mandatory Requirement: Each variant must include it as is.

Optional Requirement: A variant may leave it out
or include it as is.

Synchrophasing allows the pilot to reduce the noise

and vibration produced by two engines by matching
their propeller speed and phase. This feature only
makes sense in multi-engine installations.

Variant-Specific Requirement: Each variant must

include it, but must customize it.

Anti-Ice feature prevents ice formation on the propeller; variants include fluid, electric, or hot-air-based.

Optional Variant-Specific Requirement: A variant may leave it out or include and customize it.

Although it is possible to have an entirely mechanical system controlling a turbo engine, we assume an electronic engine controller (EEC), as it is used on modern engines.

4.

Family Architectural Model

The family architectural model represents the parts of the

system that are common to all family members and the parts
that can vary from product to product. The first step in its
creation is to identify the common and variable features of
the family and to organize them in a feature model [11].
Features are customer-facing system characteristics, such as
those listed in Section 3. SysML has no dedicated feature
modeling notation; however, feature models can be represented as decompositions of blocks, each marked with the
stereotype Feature. Such representation inherits adequate
configuration semantics from UML class models.
The next step consists of specifying the expected functionality of the system as text requirements. This task is
particularly important in the avionics domain since systems
are verified via requirements-based testing. The method applies the following stereotypes to requirements in order to
classify their variability and provide guidance on when and
how to use each requirement:

Sample customizations are parameter values, installationspecific interfaces, and customer-specific functionality.
The following step is to model the structure and behavior
of the family architecture using SysML. The structural aspect covers system, software, and hardware blocks (components) and their connections (data flows). The behavioral
aspect covers the system dynamics: how inputs are processed to produce outputs, how messages are sent between
blocks, and how the states of the system evolve. These parts
of the model cover both the system architecture and the software architecture and use allocation relationships to allocate
features to blocks, behaviors to blocks, and blocks to blocks
(e.g., software components to hardware components) [8]. We
leverage existing SysML trace types for requirements (see
Table 1): deriveReqt traces software requirements to system requirements; refine traces variant-level requirements
to the family-level requirements they customize; and satisfy allocates requirements to features and components.

METHOD

We now summarize the proposed method to model systems with variability using SysML; a detailed description of
a previous version is available elsewhere [15]. The method
uses pervasive traceability through the system model, as
required by ARP4754A and DO-178C. According to DO331 [19], the model, in its most comprehensive form, can
cover system design, software requirements, and software design; system requirements must be provided in textual form,
but may be supplemented with diagrams in the model.
The core of the method relies on dividing the model into
two parts, a family model and variant models. The family
model describes the architecture common to all products in
the family; it highlights the parts that are common to them

294

Traceability
System Software

Relationship Keyword
deriveReqt

Family Variant

refine

Requirement Block
Requirement Test Block

satisfy
verify

Description
Links higher-level and lower-level requirements, such as system and
software requirements
Links a variant-level requirement with the family-level requirement
that the variant-level requirement customizes.
Allocates requirements to system, software, and hardware blocks.
Links a requirement with the tests that verify that the requirement
has been satisfied.

Table 1: SysML relationships to provide requirements traceability

The variant behavior and structure will vary depending
which features are instantiated. Variability in behavior and
structure is realized using SysML patterns described in Sections 5 and 6. The model uses constraint blocks to define
how the variability realized by these patterns should be resolved depending on feature instantiations.

4.2

act [Activity] CalculateBladePressure [Calculate Blade Pressure]

<<Dlternative>>
calculate_new_angle
test

>closed_loop 7UXH@

Variant Architectural Model

body
<<Rptional>>
current_beta : angle

A variant model defines the architecture of a single system variant; it describes which of the variable parts of the
family model are present and it introduces new parts unique
to that variant. SysML enables this kind of specialization
and extension via subclassing and redefinition: blocks can be
specialized and extended by creating subclasses and linking
them to new blocks via property redefinition. The top-level
block, representing the system, will have one subclass for
each variant; this top-level block will represent the context
of the new variant. Feature blocks are subclassed and their
properties redefined to represent feature selections; for example, an optional property can be redefined as a mandatory one. Blocks representing system, software, and hardware components are subclassed in a similar way. New requirements, behaviors, blocks and connectors are created as
needed and are linked to the model elements of the variant.
With this approach, all changes are restricted to the new
system variant, leaving the family model untouched.
Finally, the variant model must follow the conditions and
restrictions imposed by the constraint blocks at the family
architecture level. Designers can leverage this information in
two ways. One option is to use the constraints to verify consistency; any deviation from the expected structure must be
reported as a violation to fix. Alternatively, the constraints
can guide the necessary changes to the model, which could
be applied via automatic model transformations. While the
proposed method works with existing SysML tools, tool extensions for constraint checking and model transformation,
such as generating an initial set of subclasses for a variant
model, are important future work.

5.

{FeatureID = SystemConfiguration.Propeller.Feedback}

Get Delta

test

blade_pressure
>open_loop 7UXH@

req_beta : angle
body

Speed To Delta
<<Rptional>>
current_speed: frequency

Figure 1: Activity Diagram with Variability

sequence diagrams. Polymorphism is handled by structural
variability discussed in Section 6. Parts of behavior that
require customization are encapsulated as an action marked
with the customizationPoint stereotype; variants must redefine the action with their custom logic.
Variability in state diagrams can be represented by using
features in transition guards.

5.1

Activity Diagrams

Activity diagrams model flow of actions, such as in a use

case or an algorithm. Conditional execution can be represented using decision nodes or conditional nodes; the following pattern uses the less known conditional nodes.

Alternative Fragments via Conditional Node

Problem: How to represent optional or alternative fragments, with clear boundaries, in activity diagrams?
Solution: Use a conditional node (see Fig. 1). A conditional
node represents an exclusive choice among some number of
alternatives [13]; it contains one or more clauses, each with
a test and body section. The body of a clause will execute only if its corresponding test yields true; at most one
body section will execute within a conditional node. The
example models two alternative calculations of blade pressure, depending on whether the closed or open loop feature
is selected. A constraint block (not shown) connects the
feature model to the properties used in the tests (shown in
brackets). The entire conditional node is marked with alternative in order to distinguish runtime variability from
product-line variability; the stereotype is tagged with the
relevant feature to aid traceability. An optional fragment

BEHAVIORAL PATTERNS

This section focuses on representing variability in behavioral diagrams. Two major mechanisms support behavioral
variability: conditional execution and polymorphism. Conditional execution works best for small conditional fragments
or when the behavior needs to be shown in its calling context. Polymorphism allows encapsulating large behavioral
variations. Exposing content of variations in the calling context via conditional execution is particularly useful in early
lifecycle stages. Polymorphism can replace conditional execution in architectural design. The following subsections
focus on representing conditional execution in activity and

295

<<block>>
Propeller Mgr

sd [interaction] PropSpeedCtl [PropSpeedCtl]

values

Controller

Propeller Mgr

<<interval>> minBladeAngle : Real = 10.0 {max = 30.0, min = 0.0}

<<PDI>> defaultPropSpeed : Real

Remote Eng

proxy ports
<<proxy>> in_if : Mgr IN IF
<<proxy>> out_if : Mgr OUT IF

1. calculate prop speed

2. calculate blade angle

b
<<block>>
%ODGH3UHVVXUH&WO

<<Rptional>>

opt
d

proxy ports

{featureID: Config.Propeller.Synchrophasing}

<<proxy>> in_if : BP IN IF
<<proxy>> out_if : BP OUT IF

3. get re phase

0..1

<<block>>
Synchrophasing Mgr

<<block>>
<<FustomizationPoint>>
,FH3URWHFWLRQ0JU
proxy ports

<<proxy>> in_if : Ice Protection IN IF

<<proxy>> out_if : Ice Protection OUT IF

proxy ports
<<proxy>> in_if : Synchrophasing Mgr IN IF
<<proxy>> out_if : Synchrophasing Mgr OUT IF
<<proxy>> ORJ_if : SyncphVQJ Mgr /2* IF>@

FRPSOHWH
GLVMRLQW

<<block>>
BP Open Loop

4. calculate new phase

<<block>>
BP Closed Loop

proxy ports

proxy ports

<<proxy>> in_if : BP Open Loop IN IF {redefines %3IN IF}

<<proxy>> out_if : BP &OVG /p IN IF {redefines %3OUT IF}

5. calculate new speed

Figure 3: Family BDD with Variability

very complex; such a diagram should be split into separate
diagrams, e.g., each one for a subset of variants.
Origin: [28, p. 133].

Figure 2: Sequence Diagram with Variability

will typically need two clauses; one for the fragment and
one for pass-through flow. The UML specification does define a concrete syntax for conditional nodes; Fig. 1 uses the
concrete syntax of a specific SysML tool (MagicDraw). According to SysML, optional parameters can be marked by
[0..1] or the optional stereotype.
Consequences: In contrast to using decision nodes, the pattern clearly delineates each alternative fragment. It allows
comparing alternative behaviors at a glance; however, for
several large and complex alternative fragments, structural
variability using polymorphism and alternative components
may be preferred. Another consequence of this pattern is
inability to allocate the behaviors to blocks via swim lanes;
callout or matrix notation has to be used instead.
Origin: New use of an existing construct.

6.

STRUCTURAL PATTERNS

6.1

Variable Value Properties

This section describes patterns for realizing variability in

structural diagrams that specify system components and
their connectors. SysML has two main structural diagram
types: block-definition diagrams (BDDs) and internal block
diagrams (IBDs). BDDs are special type of class diagrams
that define block types and their relationships; IBDs are special type of composite structure diagrams that define connectors among elements in a block. The content of a block
can be specified using several IBDs.

Sequence diagrams model interactions between a system

and its environment or among system components.

A value property is a quantitative characteristic of a block

such as weight, speed, or minBladeAngle (Fig. 3) [8]. Its
value can be specified in the definition of its block; however,
the value may vary among the family members. The following three patterns address this type of variability. (For space
reasons, the first two patterns are not shown in Fig. 3.)

Optional and Alternative Combined Fragments

Variant-Specific Values via IBDs

5.2

Sequence Diagrams

Problem: How to specify variant-specific values for familydefined value properties?

Solution: Specify variant-specific values in variant-specific
IBDs. Variant models must subclass the top-level block,
and specify the new values via an IBD; SysML calls them
context-specific values since they are only valid within the
scope of the current variant. An alternative approach is for
the top-level block to define bound references connected to
the value properties of nested blocks; subclasses of the toplevel block can assign values to these references.
Consequences: A variant must specify unique values for all
required value properties; a tool can easily enforce this.
Origin: [8, Fig. 7.54].

Problem: How to represent optional or alternative fragments, with clear boundaries, in sequence diagrams?
Solution: Use opt or alt combined fragment [13], respectively. The first one specifies interactions that will execute
only if its guard evaluates to true (see Fig. 2). The second
one contains multiple alternative fragments, one of which
will execute depending on the guard returning true. To
control variability, guards refer to features; e.g., sync is an
attribute of Propeller Mgr, which may be bound to a feature using a constraint block. As in the previous pattern,
optional or alternative stereotype are used to indicate
product-line variability. If an actor or component lifeline
exists only within a fragment, it will not be included in the
variants that do not include the fragment.
Consequences: Optional and alternative combined fragments
have a clear visual representation. In some cases, a sequence
diagram containing many variable fragments may become

Variant-Specific Intervals via Redefinition

Problem: How to specify variant-specific value ranges for
family-defined value properties?

296

Optional Component via Multiplicity

Solution: Specify variant-specific value ranges in a subclass

via redefinition. Since SysML disallows using context-specific
values as interval bounds, the strategy from the previous
pattern cannot be used. The idea is for each variant to subclass the block, redefine the corresponding value property,
and specify the new interval.
Origin: [8, Fig. 7.49].

Problem: How to model an optional component?

Solution: Use multiplicity 0..1 (see Fig. 3c). In our example,
Synchrophasing Mgr is an optional component of Propeller
Mgr. A variant model would redefine the part property of
Propeller Mgr that holds a Synchrophasing Mgr instance
and specify multiplicity 1..1 to include the instance or 0..0
to exclude it. Optionality attaches to the composition end
rather than the block (Synchrophasing Mgr), since the block
could also be a mandatory part of another block.
Consequences: This pattern is the most straightforward solution; however, it requires the connectors attached to the
optional component to be optional too, which may require
further adaptations at the other side of the connectors.
Origin: Common use of multiplicity.

PDI Marking via Stereotype

Problem: How to represent Parameter Data Items (PDIs)?
Solution: Define PDIs as value properties in the family
model and mark them with the PDI stereotype, e.g., defaultPropSpeed in Fig. 3. An alternative solution is to model
PDIs of components as ports and connect them to a separate block that models a PDI File, which may be verified
separately from the code [20, p. 61].
Consequences: Tools can leverage this stereotype to produce
a report with all the values required by a particular variant.
Origin: Common use of stereotypes.

6.2

Optional Component via a Null Object

Problem: How to model an optional component?
Solution: Use two alternative components: one with the
optional functionality and another one being a null object.
This pattern uses the alternative components pattern: an
abstract block subclassed by the two alternatives. The first
one is used in variants where the optional functionality is
enabled. The second is an empty placeholder selected when
the functionality is disabled. Depending on the context, the
placeholder may need to pass inputs to outputs unchanged
or ignore inputs and return default values.
Consequences: The main advantage of this approach is that
no interface changes are necessary: all inputs and outputs
are the same regardless of the chosen block; however, the
placeholder adds some complexity to the model, and, if left
unoptimized, the resulting code may have unnecessary flows.
Origin: Derived from the null-object pattern [27].

Alternative Components

System variability often arises from alternative control

strategies, sensor and actuator technologies, and implementation mechanisms. Such dierences can be encapsulated
into alternative components.

Alternative Components via Subclassing

Problem: How to model alternative components?
Solution: Model alternative components as subclasses of an
abstract block (see Fig. 3a). The abstract block defines
a common interface for the alternatives. In our example,
Blade Pressure Ctl defines an interface consisting of an input proxy port in_if and an output proxy out_if port. If
the alternatives are anticipated, they can be provided as
part of the family modelBP Open Loop and BP Closed
Loop in our example. The linking between features and the
alternatives can be accomplished using a constraint block
(not shown). In general, variants can subclass the aggregate block (Propeller Manager) and replace the variable part
with one of the provided alternatives or a variant-specific
one. Since the generalization relationship in our example is
marked as complete, variants cannot add new alternatives;
marking it as incomplete would allow variants to add new
alternatives. The pattern uses the customizationPoint
stereotype to highlight abstract blocks that must or may be
subclassed by a variant (see Fig. 3b).
Consequences: Using this pattern allows variants to choose
from dierent components. If they do not change the abstract block interface, swapping components is completely
transparent; no other parts are touched. However, if the interface does change, other blocks that produce or consume
the changed flows might require adaptation via one of our
patterns. The property holding one of the alternatives may
be marked with the alternative stereotype to highlight
product-line variability. Our example refrains from it since,
in aircraft engine control domain, all components are normally configured statically.
Origin: Common use of subclassing, e.g., [8, Fig. 7.48].

6.3

6.4

Variable Ports

A port is a kind of property of a block that represents a

point of interaction for the block. Blocks are connected by
attaching connectors to ports. Thus, ports represent component interfaces. The following patterns focus on port variability. The first one enables optional ports; the other two
target ports with varying content. We assume that constraint blocks bind port variabilities to the feature model.

Optional Port via Multiplicity

Problem: How to model an optional port?
Solution: Use multiplicity 0..1 on the port (see the optional
logging port log_if in Fig. 3c). This pattern corresponds to
the optional component via multiplicity.
Consequences: An optional port may require the rest of the
model to react to the absence of the port; for example, the
optional port may be connected to another optional port
or to a mandatory port of an optional component. The
consistent configuration of both optional ends of a connector
can be enforced using a constraint block.
Origin: Common use of multiplicity.

Alternative Ports via Subclassing

Problem: How to model a port with variable content?
Solution: Type the port by an abstract block and model
alternative port realizations as subclasses of the block. This
pattern corresponds to the alternative component via subclassing. For example, a port may be configured to use al-

Optional Component

An optional component encapsulates optional functionality; a variant may or may not include it.

297

engine controller : Engine Controller

<<LQWHUIDFH%lock>>
AvionicsB'DWDB,)

<<full>>
engine_avionics_if : Engine_Avionics_IF

IORZSURSHUWLHV

<<proxy>>
avionics_data_port : Avionics_Data_IF

LQDPELHQWBWHPSHUDWXUH :&
RXWRLOBWHPSHUDWXUH&
LQFRQVROLGDWHGBZRZ%RROHDQ>@
LQQRVHBJHDUBZRZ%RROHDQ>@
LQOHIWBPDLQBJHDUBZRZ>@
LQULJKWBPDLQBJHDUBZRZ%RROHDQ>@

Avionics Bus

<<full>>
aiframe_avionics_if : Airframe_Avionics_IF

sw : Controller SW
<<proxy>>
: Avionics_Data_IF

Figure 5: IBD modeling the engine-to-airframe

avionics bus connection

Figure 4: Variable interface block for typing ports

within cables.

ternative communication protocols and each subclass may

encapsulate a dierent protocol. The variant model can use
redefinition to pick the desired alternative.
Consequences: The selection of an alternative for each of
two connected ports needs to be synchronized, for example,
using constraint blocks.
Origin: Common use of subclassing.

Alternative Connections via Subclasses

Problem: How to model alternative sets of connectors among
components?
Solution: Create an abstract block with properties holding components to be connected; define a subclass for each
alternative set of connectors; and model each set in a separate IBD, one per subclass. The family model can define
the subclasses; a variant selects the desired subclass using
redefinition, as in the alternative components pattern. Alternatively, the variant model can define its own subclass.
Fig. 5 shows an IBD modeling the connectors between the
engine control software and the airframe avionics. This IBD
shows a single-engine configuration; another variant model
could have an IBD defining a twin-engine configuration, with
two engine controllers connected to the airframe avionics.
Consequences: The first solution allows the family model to
provide alternative sets of connectors; the second solution
allows establishing custom connectors in the variant.
Origin: Common use of subclassing.

Port Variability via Properties

Problem: How to model a port with variable content?
Solution: Use a block with variable flow properties or variable nested ports as port type. Variability of the nested
properties can be achieved using multiplicities or subclassing. In essence, this pattern applies the previous two patterns to the properties of a port. For example, the interface
block in Fig. 4 has optional flow properties using multiplicities and it types the avionics_data_port in Fig. 5. On the
other hand, the Engine Avionics IF in Fig. 6 has parts providing data conversion services; their subclasses (not shown)
provide alternative implementations of these services. This
interface types the engine_avionics_if in Fig. 5.
Consequences: This pattern achieves content variability of
a port, just like the previous pattern. On the one hand, the
previous pattern allows subclasses to have dierent sets of
operations; such variability requires nested ports in the case
of variability via properties. On the other hand, variability
via properties scales well for ports with a large number of
optional flow properties, while subclassing works best for a
small number of alternative configurations only. As with the
previous patterns, constraints blocks can ensure consistent
configurations of connected ports.

6.5

airframe : Airframe

Optional Connector via Multiplicity

Problem: How to model an optional connector?
Solution: Type the connector by an association block, define
a connector property containing the connector, and use multiplicity 0..1 on this property. Similar to associations, connectors can have multiplicities at their ends; however, they
normally do not have a multiplicity to control the number of
links they represent. In order to provide such a multiplicity,
the connector must be typed by an association block; a container block can then have a connector property with multiplicity 0..1 typed by this association block. The presence
of the connector can be controlled by binding the connector
property to a parameter of an appropriate constraint block.
Consequences: In contrast to the previous pattern, this pattern allows a single IBD to represent a variable set of connectors.
Origin: New use of a connector property [8].

Variable Connectors

Connectors connect block properties, typically ports. There

are two types of variabilities in this context: variability in
how components are connected and variability in the data
that flows over these connectors. Complex systems often require components to exchange hundreds or even thousands
of values. Keeping the data flows well organized is a challenge, which is exacerbated in a product-line setting. The
first step to organizing the flows is to cluster the values into
groups. For example, all the input values required by a
given component can be grouped into a single block as its
flow properties. That block can then be used to type the
input port of the component. The port can be connected to
a port on another component, provided the port types are
compatible. The connector connecting such ports can be
thought as a cable that bundles multiple wires [23], where
each flow item represents a wire. The first two patterns address the variability of which components are connected; the
following two patterns focus on the variability of the wiring

Variable Cables via Mapping Policy

Problem: How to model a cable with variable content?
Solution: Use an untyped connector or a connector typed by
an association to connect two compatible ports with variable
content. The variable content of the connected ports can be
realized using the previous patterns: alternative ports via
subclassing or port variability via properties. For example,
the connector between controller software and the avionics_data_port in Fig. 5 transports the flow items defined
in Avionics_Data_IF (Fig. 4). SysML specifies port-type
compatibility only partially, such as when using conjugated

298

Content Type

<<block>>
Avionics Bus

Blocks
Interface Blocks
Flow Properties
Redefined Properties
Redefined Flows
Activity Diagrams

references

<<participant>> airframe_port : Airframe_Avionics_IF

<<participant>> engine_port : Engine_Avionics_IF

<<block>>
Engine_Avionics_IF

<<block>>
Airframe_Avionics_IF

proxy ports
avionics_bus_port: Avionics Msg
avionics_bus_port : Avionics Msg>@
avionics_data_port: Avionics_Data_IF

proxy ports
avionics_bus_port : Avionics Msg
DYLRQLFVBEXVBSRUW$YLRQLFV0VJ>@
avionics_data_port : Avionics_Data_IF

parts
input_processor : Bus Input Processor
data_unpacking : Bus Data Unpacking

<<proxy>>
avionics_data_port

<<proxy>>
avionics_EXV_port>@

<<proxy>>
avionics_EXV_port

Avionics Bus&K
Avionics Bus&K

<<participant>>
airframe_avionics_if : Airframe_Avionics_IF
<<proxy>>
avionics_EXV_port>@

CS2
Variants
12
8
0
36
13
2

that these ports are typed by the participant blocks from

Fig. 6, respectively. Therefore, the connector between these
two ports also specifies the connectors between their nested
ports, as shown in Fig. 7.
Consequences: The pattern allows specifying precise connections among the nested ports; thus, in contrast to the previous pattern, mapping is explicit. The pattern makes use of
advanced SysML constructs; however, it enables modeling
complex wiring scenarios with variability, such as modeling
signal routing options and avionics wiring for product lines.
Origin: New use of connectors typed by association blocks [8].

ibd [Block] Avionics Bus [Avionics Bus]

<<proxy>>
avionics_EXV_port

CS2
Family
60
101
309

14

Table 2: Model statistics

Figure 6: Association Block BDD

<<participant>>
engine_avionics_if : Engine_Avionics_IF

CS1
Family
72
83
27

11

<<proxy>>
avionics_data_port

Figure 7: Association Block IBD

ports (e.g., the port on the controller software sw is conjugated as indicated by the tilde in front of its type); however,
the language allows project-specific policies for mapping flow
properties. Such a policy needs to be enforced by a tool extension. Constraint blocks can be used to control variability
of connected ports to ensure their compatibility under the
chosen policy.
Consequences: This pattern works well for cases where an
automatic policy, such as matching flow properties by name,
type, and direction, exists.
Origin: Common use of connectors.

7.

METHOD DEVELOPMENT AND EVALUATION

7.1

Research Methodology

7.2

CS1: Propeller Controller Case Study

7.3

Feedback Session

The presented method was developed and evaluated through

two case studies and a feedback session with P&WC architects. The first case study (CS1) drove the method development; it involved a realistic example, but constructed for
the purpose of this research. We decided to construct the
example from public sources to allow sharing of the case
study with the research community. CS1 was followed by the
feedback session. The second case study (CS2) focussed on
evaluating the method on a real-world problem at the industry partner. The evaluation was exploratory and aimed at
generating lessons learned. The following subsections summarize these three activities and the lessons learned.

Variable Cables via Association Blocks

Problem: How to model a cable with variable content?
Solution: Use a connector typed by an association block
to connect ports that have (possibly variable) nested ports;
connect the nested ports within the IBD of the association
block using (possibly variable) nested connectors. Typing a
connector by an association block allows structures nested
in the connector, including nested connectors. Consider
the association block, Avionics Bus, in Fig. 6. It models
the association between two participants, Engine Avionics
IF and Airframe Avionics IF, each representing an interface. Engine Avionics IF is the interface between the engine avionics and the avionics bus. It has three nested
ports: avionics_data_port is the interface to the controller
software; avionics_bus_port1 and avionics_bus_port2 are
two redundant bus message ports; the back-up port, avionics_bus_port2, is optional. Airframe Avionics IF is the
interface between the airframe avionics and the avionics
bus; it has two corresponding nested message ports avionics_bus_port1 and avionics_bus_port2. The IBD of this
association block (Fig. 7) defines the connectors between
the nested message ports of the participants. Because the
back-up ports are optional, Avionics Bus Ch2 is optional,
too (alternative connectors among mandatory ports would
use the optional connector via multiplicity pattern instead).
Finally, the IBD of another block, shown in Fig. 5, uses the
association block as a type of the connector between two
ports: engine_avionics_if and airframe_avionics_if. Note

The first case study (CS1) involved modeling a product

line of propeller controllers, as briefly described in Section 3.
The objective of CS1 was to aid the method development.
We extracted the necessary domain knowledge from literature, in consultation with domain experts from our industry
partner. As a start, we used the V process, as mandated by
ARP4754A and DO-178C, and existing SysML guidance [8].
The split into a family model and variant models was to simplify management of customer-specific content within each
variant model. A variant model could still cover a subset of products via PDIs. We first developed the feature
model and the textual requirements; followed by structural
and behavioral models. We identified the variability patterns as they became relevant during the system modeling. Table 2 characterizes the size of the resulting family
model (the first two columns). The model is available at
http://gsd.uwaterloo.ca/SysML.
The feedback session was a two-hour meeting with two
architects from P&WC, followed by another two-hour meet-

299

ing a week later. We presented to them the method and the

patterns using the propeller controller example and recorded
the feedback. We summarize the most interesting findings.
Method. The division into family and variant models is
most suitable for reuse across programs. Aerospace systems
are developed as part of so-called programs, e.g., aircraft
programs or engine programs. A family model is suitable
for a common core architecture, to be reused across many
programs. Variants within a program are handled via PDIs.
Product-line variability should be distinguishable from other
variability types in the models. Representing variability using standard SysML constructs promotes the standard and
leverages exiting tools; however, product-line variability must
be visibly distinguishable from other variability types. Even
though our use of stereotypes helps, tool support may require sophisticated model analysis to determine each part
impacted by product-line variability.
Coloring is not acceptable for marking product-line variability in aerospace models. Coloring can visualize how features map to models [5] or code [7]. However, the architects
consider it unacceptable in practice, since some engineers are
color-blind and the models must be printable on a standard
black-and-white printer, e.g., for submission to certification
authorities. Further, SysML does not use color. For this
reason, we use stereotypes to mark product-line variability.
Alternative allocations of functional blocks to hardware
blocks require stereotypes. Allocations in SysML are dependencies, which lack instance semantics of associations. Thus,
cardinalities and constraints cannot be used on them.
Behavioral patterns. Side-by-side exposition of behavioral variabilities is particularly useful in requirements engineering. In early analysis, the ability to contrast alternative flows is most valuable. Thus, one needs to be able
to represent in-place optional and alternative fragments in
behavioral models. In contrast, in architectural and design
models, they prefer encapsulation and polymorphism.
Conditional nodes and combined fragments need marking
if used for product-line variability. These SysML constructs
show variable fragments in-place; however, they need to be
marked if used for product-line variability since they are also
used to represent scenario variations for a single product.
Structural patterns. PDI values are likely to be stored
outside the SysML models. Even though PDI values could be
specified in the variant models, they are likely to be stored
separately. These values originate from a wide range of
sources, and dierent stakeholders need to access them, including requirements, systems and software, and flight-test
engineers and sales and manufacturing personnel. Further,
using a SysML tool to store and export the actual PDI values would require qualifying it [18], even if modeling is used
mostly for analysis and documentation. Thus, the PDI values are most likely to be stored in a dedicated database.
Optional ports and parameters are preferably handled using default values. Optional ports and parameters can be
marked as such using 0..1; however, the architects prefer
treating them as mandatory and using default values if absent. This preference also applies to realizing the absence
of an optional component via a null object. Default values leave interfaces undisturbed and are often the simplest
solution; however, care is needed to avoid bloated interfaces.
Customization points require specification of what customizations are allowed or disallowed. This includes clarifying
which signals and operations can or must not be accessed.

300

Ideally, sample customizations are also given as guidance.

Variable cable pattern is useful to organize complex signal
flows and shield from external interface variabilities. Engine
controllers manage hundreds of signals; their hierarchical organization is very useful. The variable cable pattern with
full ports encapsulating data conversions is particularly useful to insulate the controller from airframe-avionics interface
variability (see Fig. 5).

7.4

CS2: FCU Controller Case Study

The objective was to test the method on a real-world problem from the industry partner. A Fuel-Control Unit (FCU)
is a part of the engine control system responsible for modulating the fuel flow into the combustor. The subject of
CS2 was to create a configurable and reusable system model
covering a wide range of FCUs used at P&WC; the controlsoftware aspect of the model will be eventually implemented
as a reusable software library. The first author performed
the work on the company premises under the supervision
of their engineers over a period of three months. The work
applied the method; however, the system requirements and
design alternatives were extracted from five existing engines,
representative of the wide range of engines made by P&WC,
including one turboprop, one turbofan, and three turboshaft
engines. We summarize the experience and findings.
Method. The family model has most of the content. It
covers significant variability, including alternative actuator
technologies (e.g., stepper motor vs. torque motor), sensor
configurations, and fault accommodation strategies. The
feature model has 20 common and 23 variable features; 20
requirements are mandatory, 20 requirements are optional,
and 9 requirements are optional variant-specific. Table 2
lists CS2 model statistics; the variants column considers the
union of all five variant models. We estimate the size of the
family model as somewhat larger than that of a dedicated
model for a single variant, but smaller than the size of two
dedicated models. Thus, there is a clear case for creating
and maintaing the family model.
Performing behavioral modeling first can help determine
the necessary structure. The initial attempt was to create
structural diagrams directly from requirements. Although,
the requirements came from actual engine specification documents that supposedly provided a complete understanding of the system, we found several points where matching
across the engines was unclear and requirements could be
interpreted dierently; even experts we worked with had
trouble resolving these points. We found that modeling the
behavior and applying the behavioral patterns helped us
solve this problem by providing a clear picture of the actual functionality, the necessary inputs and outputs, and
locations and scope of variability. With this information
creating structural diagrams became straightforward, as the
decomposition could be extracted almost directly from the
activity diagrams.
Tool supported consistency analysis is needed. CS2 had 13
constraint blocks containing constraints in natural language.
Only a subset of the necessary integrity constraints was captured. This part of the model is highly complex and very
dicult to model correctly and completely without tool support such as constraint satisfaction checking and constraint
debugging. Current commercial tools lack such a support.
Behavioral patterns. Conditional nodes were adequate
for CS2. CS2 had 40 diagrams, including 14 activity dia-

grams with a total of 6 conditional nodes, each with only two

alternatives. There was no nested variability, such as nesting variable fragments in other variable fragments. CS2 had
one sequence diagram, with an optional fragment, modeling
the interaction of the controller with its environment.
Structural patterns. CS2 used only PDIs for variable
values. Had CS2 covered test cases, it would have also likely
used interval refinement.
CS2 used alternative components via subclassing seven times.
Two of these cases were customizations.
CS2 used optional component twice; each with null objects.
The multiplicity approach could have been applied instead,
but at the cost of a more complex family model.
CS2 benefited significantly from the cable and variable port
patterns. Even for a simple system such as the FCU, structured ports and connectors were crucial to manage the signal
flow in the model. We used a hierarchy of interface blocks
to bundle individual flows; the hierarchy had 60 parent and
41 child interface blocks, with an average of 5 flow properties per parent. The components used mostly proxy ports
and connectors with implicit mapping; if needed variability was realized mainly via interface block subclassing and
redefinition. Ten ports and 13 flow properties used 0..1 to
indicate optionality. Without structured connectors, there
would have been at least 309 atomic flows. Also, interface blocks simplified interface updates, since cables crossed
boundaries of nested components. Cables via association
blocks were used to model the communication buses connecting the controller to the airframe avionics. A full port
with variable properties implemented an adaptor pattern to
insulate the controller form the variability of airframe avionics and bus technologies (similar to Fig. 5).

8.

THREATS TO VALIDITY

The main threat to external validity is that the two studied systems may not be representative of other avionic systems. The method was evaluated in the context of airplane engine control, a particular type of avionic system; it
is a relatively closed system, concerned mostly with modedependent continuous control, and extremely safety-critical
(the entire system is classified as DAL A). Further, the FCU
controller had flow-based behavior; other parts of engine
control are dierent; for example, governing additionally requires state machines to capture its complex modes and
transitions. There is a wide range of avionic systems on
an aircraft; some are similarly critical and involve modedependent continuous control, such as flight guidance; some
use more complex data, such as flight management and navigation systems; and some have lower criticality levels, such
as entertainment systems. More work is required to validate
the SysML patterns on a range of avionic systems.
A threat to construct validity of CS2 is that the method
was applied by a researcher. Even though he visited the
company for nine months during this research, the experience made by engineers employed by the company may
be have been significantly dierent. There is also a threat
of confirmation bias. The feedback session was limited to
two highly-experienced architects, but other engineers could
have had dierent opinions.
Finally, the work presented in this paper was evaluated
using a new family architecture model using existing products as variants. Other situations, such as when variability
is introduced incrementally, require additional studies.

301

9.

RELATED WORK

This section describes previous work focused on variability

modeling in UML and SysML.
The Common Variability Language (CVL) is designed for
the specification and resolution of variability [4]. Its main
strength is the ability to add variability modeling to existing MOF-based modeling languages; these include UML and
SysML. There are some similarities between CVL concepts
and our method. First, our family model corresponds to
the combination of the variability model and base model in
CVL. Second, our variant model corresponds to the combination of a resolution model and a resolved model. However, there are three major dierences. First, our method
takes advantage of existing SysML constructs; since CVL
is a generic language, it does not leverage them. CVL acts
at the level of abstract syntax, annotating model elements
with variation points that remove or leave model elements
depending on a feature configuration (similar to #ifdef directives). Our patterns exploit SysML semantics, which can
already express variability. Second, CVL allows adding variability to existing models; however, it might not be ecient
or possible to do so if the models have not been designed
with variability in mind. Our method provides patterns
for designing SysML models with variability. Finally, CVL
would create a resolved model that is normally detached
from the base model; our method defines resolved models as
subclasses of the base model. To get this eect one would
have to create a set of variant-level subclasses and annotate
them using CVL. The same three dierences apply when
comparing our method to other CVL like-approaches, including the approaches by Tessier et al. [25] and Trujillo
et al. [26] and model templates [5], which represent variation points as stereotypes that control model transformations such as element deletions or replacements.
Clau [3] makes some use of UML semantics to express
variability, such as modeling alternatives using inheritance
or templates in class diagrams. In addition, he annotates
classes with stereotypes representing CVL-style variation
points; this is in contrast to our patterns, which use multiplicites and constraints. Ziadi et al. [28] apply Claus
ideas to class diagrams and propose using combined fragments to express variability in sequence diagrams. Neither
Clau nor Ziadi et al. link variation points to feature models. Gomaa [9] also uses a mix of built-in UML constructs
and stereotypes, but also adds a feature model. Bayer et
al. [1] use specialization and redefinition to model variability in composite structures, similar to our approach. However, the paper does not cover more advanced structures
such as nested ports and connectors. Bhejati et al. [2] use
UML class models semantics to express variability of undersea oil exploration systems; this includes the use of multiplicities to control numbers of components, attributes to
express variability of physical properties, and associations
to model component linking (aka topological variability).
They use UML templates to capture configuration parameters, such as property multiplicities and types. Karban et
al. define variants via inheritance, as in our approach [12,
p. 109]. They structure variants using nested packages and
stereotypes, mimicking feature models [12, p. 111]. None of
the previous approaches covers variability of nested ports,
nested connectors, or behavioral diagrams.
In contrast to these previous works, our approach is to use
SysML constructs and semantics to express rich variability

(note that all of our patterns also apply to UML since they
use constructs that SysML inherits from UML). Although
Friedenthal et al. [8] give an excellent guidance for the use of
SysML in systems modeling, they do not give explicit guidance on modeling variability; for example, no example in
the book uses multiplicity 0..1 to express an optional component, port, or connector. Our pattern catalog focuses on
problems in modeling variability in SysML, alternative solutions to these problems, and their trade-os; we also report
on lessons learned from applying the method and catalog.

10.

[8] S. Friedenthal, A. Moore, and R. Steiner. A Practical

Guide to SysML: The Systems Modeling Language
(2nd edition). Elsevier, 2012.
[9] H. Gomaa. Designing Software Product Lines with
UML: From Use Cases to Pattern-Based Software
Architectures. Addison-Wesley, 2004.
[10] INCOSE. Model Based Systems Engineering, 2014.
[11] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak,
and A. S. Peterson. Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Technical report,
CMU/SEI-90-TR-21, SEI, 1990.
[12] R. Karban, T. Weilkiens, R. Hauber, M. Zamparelli,
R. Diekmann, and A. Hein. Cookbook for MBSE with
SysML, Part 2. SE2 Challenge Team, 2011.
[13] OMG. OMG Unified Modeling Language, 2013.
Version 2.5 (beta).
[14] OMG. Systems Modeling Language, 2013. Version 1.4
(beta).
[15] J. A. Padilla Gaeta. Modeling and Implementing
Variability in Aerospace Systems Product Lines.
Masters thesis, University of Waterloo, 10 2014.
[16] K. Pohl, G. Bckle, and F. Van Der Linden. Software
Product Line Engineering: Foundations, Principles
and Techniques. Springer, 2005.
[17] RTCA Inc. DO-254: Design Assurance Guidance for
Airborne Electronic Hardware, 2000.
[18] RTCA Inc. DO-330: Software Tool Qualification
Considerations, 2011.
[19] RTCA Inc. DO-331: Model-Based Development and
Verification Supplement to DO-178C and DO-278A,
2011.
[20] RTCA Inc. DO-178C: Software Considerations in
Airborne Systems and Equipment Certification, 2012.
[21] SAE. ARP4761: Guidelines and Methods for
Conducting the Safety Assessment Process on Civil
Airborne Systems and Equipment, 1996.
[22] SAE. ARP4754: Guidelines for Development of Civil
Aircraft and Systems, 2010.
[23] B. Selic. A short catalogue of abstraction patterns for
model-based software engineering. Int. J. Software
and Informatics, 5(1-2):313334, 2011.
[24] C. R. Spitzer and C. Spitzer. Digital Avionics
Handbook. CRC Press, 2000.
[25] P. Tessier, S. Grard, F. Terrier, and J. Geib. Using
variation propagation for model-driven management of
a system family. In SPLC, pages 222233, 2005.
[26] S. Trujillo, J. M. Garate, R. E. Lopez-Herrejon,
X. Mendialdua, A. Rosado, A. Egyed, C. W. Krueger,
and J. De Sosa. Coping with Variability in
Model-Based Systems Engineering: an Experience in
Green Energy. In MFA, pages 293304. 2010.
[27] B. Woolf. Null object. In Pattern Languages of
Program Design 3, pages 921926, 2007.
[28] T. Ziadi, L. Hlout, and J.-M. Jzquel. Towards a
UML Profile for Software Product Lines. In SPLE,
pages 129139. 2004.

CONCLUSION

This paper presented a method and pattern catalog for

modeling avionics systems product-lines. The method is derived from applicable aerospace systems and software engineering guidelines. The patterns build on previous work
in variability modeling and SysML modeling guidance; in
contrast to previous work, the patterns focus on expressing
variability using existing SysML semantics, while minimizing language extensions (such as through stereotypes). The
evaluation shows that SysML is rich enough to express realistic systems product-lines in the aircraft engine domain.
Practitioners can benefit from the method, the pattern catalog, and lessons learnt. The insights on limited tool support
for type and constraint consistency checking and debugging
are of interest to tool builders and researchers. In future
work, we plan to perform follow-up studies to analyze the
experience of engineers in applying the method and the pattern catalog to a wider set of systems. Other future work are
studies comparing this approach with CVL-style solutions.

Acknowledgment
This research was supported by Pratt & Whitney Canada.
The authors would like to thank Michael Darby, Kim George,
and Bran Selic for their valuable feedback.

11.

REFERENCES

[1] J. Bayer, S. Gerard, . Haugen, J. Mansell,

B. Mller-Pedersen, J. Oldevik, P. Tessier, J.-P.
Thibault, and T. Widen. Consolidated Product Line
Variability Modeling. In Software Product Lines, pages
195241. Springer, 2006.
[2] R. Behjati, T. Yue, L. Briand, and B. Selic. SimPL: A
product-line modeling methodology for families of
integrated control systems. Information and Software
Technology, 55(3):607 629, 2013.
[3] M. Clau. Generic Modeling Using UML Extensions
for Variability. In Workshop on Domain Specific
Visual Languages at OOPSLA, volume 2001, 2001.
[4] CVL Submission Team. Common Variability
Language, 2012. http://www.omgwiki.org/variability.
[5] K. Czarnecki and M. Antkiewicz. Mapping features to
models: A template approach based on superimposed
variants. In GPCE, pages 422437, 2005.
[6] Federal Aviation Administration. Pilots Handbook of
Aeronautical Knowledge. Skyhorse Pub. Inc., 2009.
[7] J. Feigenspan, C. Kstner, S. Apel, J. Liebig,
M. Schulze, R. Dachselt, M. Papendieck, T. Leich, and
G. Saake. Do background colors improve program
comprehension in the #ifdef hell? Empirical Software
Engineering, 18:699745, 2012.

302