System Architecture Modeling for Electronic Systems

Using MathWorks System Composer and Simulink

Christopher B. Watkins Jerry Varghese Michael Knight
Gulfstream Aerospace Corporation Gulfstream Aerospace Corporation Gulfstream Aerospace Corporation
Savannah, GA, U.S. Savannah, GA, U.S. Savannah, GA, U.S.
[email protected] [email protected] [email protected]
Becky Petteys Jordan Ross
The MathWorks, Inc. The MathWorks, Inc.
Natick, Massachusetts, U.S. Natick, Massachusetts, U.S.
[email protected] [email protected]

Abstract—Electronic system architectures have traditionally

been documented as static block diagrams in tools such as
Microsoft® Visio® or through a richer modeling approach such as
Systems Modeling Language (SysML). These approaches did
not fully meet the modeling needs for the Gulfstream authors,
which led to an alternative approach.

This paper introduces the Electronic System Architecture

Modeling (eSAM) method, which leverages a new system
architecture modeling tool called System Composer™. eSAM
was created by the authors to define a standard method for
applying the generic System Composer modeling constructs to
build functional, physical, and logical architecture models of
electronic systems. The eSAM methods are applied to an example
avionics architecture to demonstrate capabilities needed for
system modeling, collaborative OEM-supplier workflows, data Figure 1: Simplified development process
management and ICD generation, systems integration activities,
generation of system architecture deliverables for the avionics
certification standards governed by SAE ARP4754A, and a are performed along the left-hand side and test and verification
Model-Based Design approach that connects a software function are performed along the right-hand side. Figure 1 shows a
to its system-level ICD. simplified view of the V-diagram and summarizes the left-hand
design activities.
System Composer is built on MATLAB® and Simulink® and
leverages the modeling, analysis, and simulation capabilities of When applying design tools to support this process, there
these well-established tools. System Composer adds additional are two gaps of interest. Gap #1 exists between the design
capabilities for modeling integration between systems, filtering specification and the implementation of the system. Design
large models into manageable views, capturing important system engineers must sufficiently describe the behavior and structure
and component properties, allocating between different of the system such that engineers can accurately implement the
descriptive architecture models, directly connecting system
architecture models to software functional models, and flowing
system. Graphical modeling tools, such as Simulink, allow
data down into specialized design tools. engineers to graphically represent and simulate their designs,
which allows them to validate that the behavior of the system is
This paper summarizes desirable features in system satisfactory. For software systems they can automatically
architecture modeling tools, introduces the features and concepts generate code for the algorithm that is used in the final
of System Composer and describes application of the eSAM production software. Using this Model-Based Design (MBD)
method. approach, the design engineers are able to work at a higher
level of abstraction in the graphical environment, and the
Keywords—system architecture, modeling, Model-Based
implementation engineers are able to elaborate the same
Design, MBD, MATLAB, Simulink, System Composer, eSAM
models when working the implementation details. These tools
help to bridge this gap between engineering disciplines by
I. INTRODUCTION eliminating unnecessary rework and encouraging effective
A traditional systems development workflow starts with communication in a common tool environment.
early concepts and requirements and flows down to the
The other significant gap, Gap #2, in the development
implementation in hardware and software. A common view of
workflow occurs earlier in the process, when moving from
this process is the V-diagram where the design and validation
early concepts to design. The tool requirements for each stage

978-1-7281-9825-5/20/$31.00
Authorized licensed use©2020
limited IEEE
to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
of the process are different and are performed by different functions should be allocated to physical components in the
personas. Early on, it is important to be able to express and physical model. The allocation serves to clarify which
capture abstract ideas, thoughts, and concepts. However, those functions a system designer is responsible for providing and
concepts are then slowly concretized into a design that can be gives the modeler the ability to assess if all their functions are
simulated for the expected behavior. Today this transition from implemented. This linkage also enables functional impact
early concepts to a concrete design specification is typically assessments for physical component failures, a key activity for
done in different tools, which introduces inefficiency and system safety assessments.
potential translation errors in the workflow.
B. Easily Understandable Graphical Depictions
System Composer [1], a tool from MathWorks, allows Highly integrated electronics systems, such as an Integrated
engineers to capture the early concepts and system architecture Modular Avionics (IMA) architecture [2], are complex and can
along with the design of the systems in a single tool. The be difficult to understand with merely a mental picture. Due to
aspects of the abstract system architecture work that can be this complexity, graphical diagrams can quickly become messy
directly applied and connected to detailed design work are the and difficult to understand with crossing lines routed all over.
initial focus of System Composer. There are two important A good modeling tool would be able to represent system
aspects of System Composer that enable it to effectively work connections with a single line and system allocations through
for both system engineers early in the development process and another means so that the graphical model remains clean and
design engineers who work in Simulink. First, it is easy and readable. It would also employ model nesting so that all details
intuitive for system engineers to begin their work of abstract aren’t shown in a large flat model.
modeling of architectures and functional decompositions.
Second, it is tightly coupled to the Simulink design C. Scalability for Large Models
environment. System Composer models begin as an early way Integrated system models can grow rapidly in size and
to capture concepts and mature into systems integration models become difficult to interact with. They do not fit on the
that describe the integration between subsystem models. For computer desktop, leaving the user to zoom in and out and pan
configurable software systems, the System Composer model continually to navigate the model. Likewise, it can become
can be interfaced with specialized design tools to directly difficult to print hard copies, especially when model
define the configurations, enjoying a Model-Based Design components of interest are spread across different areas of a
approach beyond what is achievable in Simulink alone. large model. A single view or screenshot cannot capture the
model effectively due to the sheer size and complexity. A
In this paper, we will summarize Gulfstream’s needs for method to create multiple views of the model with the elements
system architecture modeling, review the current state of of interest is necessary for understanding and building.
system architecture modeling, explain the capabilities of
System Composer, and show an example of how System D. Standardization of ICD Definition (Shared Language)
Composer can be used to model an avionics system
Large electronic system models, such as an aircraft system
architecture using the author’s eSAM method. model, involve a large number of subsystems, provided by
many different organizations (internal and external). A
II. GULFSTREAM NEEDS AND CAPABILITIES modeling tool should enable the system integrator to levy a
Electronic system modeling generally involves the standard method for system owners to define their IO. This
activities of modeling system components (i.e., hardware and saves the system integrator from converting IO from many
software), data inputs/outputs (IO), signal flows between different formats, which can be error-prone and time-
components, and signal flows between systems. The model consuming.
should include meta data to describe the properties of each
modeling element. E. Directly Connecting IO Model to Behavioral Model
An ideal solution would provide these capabilities: Ideally, the system architecture tool would integrate with
the system behavioral model (e.g., software model). The inputs
and outputs should be modeled as a single source for both the
A. Functional Allocation to Physical Architecture Models
behavior model and system architecture model. For example, if
Functional allocation was a simple mental task before the an input signal is added to the behavioral model, then the
dawn of highly integrated systems. It was obvious that the system architecture model should show the new input. This
communication function was provided by the radios. With notifies the system integrator to connect the input to the
highly integrated systems, it’s not clear which component producer of that signal.
should provide which function(s). The radio controls could be
allocated to a smart display, while a software defined radio is F. Requirements Traceability
allocated to a processing module, and the radio transmissions
are allocated to an antenna system. A modeling tool can help In the avionics development process, it is important to trace
by creating a functional model before physical implementation the system requirements to the models. Requirements should
is even conceived. These functional models should not be be traceable to both the behavioral model and the system
disconnected from the physical models since it is no longer architecture models. It is preferred that the requirements
obvious which functions a physical component provides. The

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
linking to graphical models be realized by graphical method failed to address a modeling need, or it didn’t satisfy the need
such as drag-and-drop. in a preferable way. In particular:
• Some lacked advanced modeling features or
G. Multi-User Concurrent Modeling
flexibility for model analyses.
Large models are managed by many subsystem modelers.
Efficient model development and management depends on the • Workflows did not sufficiently support large
ability for multiple users to concurrently work on their portions models distributed across many organizations.
of the model. • The underlying modeling methods weren’t
preferred for aircraft system architecture modeling
H. Collaborative Multi-Role Modeling (UML/SysML[4], Arcadia[5], AADL[6]). These
A modeling tool needs to address different stakeholder methods tended to be primarily suited for software
tasks. It needs to enable subsystem modelers to create their or embedded system modeling, and only
models and perform their local subsystem integration activities secondarily applied to system architecture
between their components. It also needs to enable the higher- modeling.
level system integrator to integrate the IO between subsystem
models. • Some methods didn’t support both early
conceptual models as well as mature design
models. That is, workflows required models to be
I. Signal Flow Analysis
specified at a detailed level before details were
When a system does not function as intended, the designer available during the conceptual stage.
typically resorts to analysis and/or lab investigations. Either
way, a signal flow analysis is usually required to highlight • Some graphical model depictions looked cluttered
where the intended function breaks down. An integrated and were difficult to navigate and read for large
system model should provide a good way to trace signals. models. They required too much panning and
zooming in/out.
J. Failure Propagation Analysis This led the authors to develop of a new modeling method.
Failure propagation is key design parameter for safety- The method was implemented using a new tool called System
critical systems, such as aircraft avionics systems. Once an Composer. The Gulfstream authors worked with MathWorks to
integrated system model is realized, the dependencies between share their use case prior to the System Composer product
components and system functions are inherently defined. A release in March 2019, and they continue to provide input.
good tool would enable the modeler to generate fault Future releases add functionality that help the authors realize
propagation reports so they can better understand impacts of their vision for system architecture modeling. This paper serves
part failures. If the components are allocated to functions, then to describe the new modeling method.
the failure propagation could be understood in the context of
affected functions. For example, it is important to know if the IV. MODELING IN SYSTEM COMPOSER
aircraft landing gear function could be potentially affected by a
single component failure, such as a hydraulic pump. Most The goals of System Composer are to make system
passengers would like to avoid a belly landing! modeling easy, flexible, and scalable; and to ease the transition
to the design environment. The features and constructs of
System Composer [7] reflect the prioritization of these goals.
K. Integration with Lower-Level Tools
Electronic systems are primarily software-driven and can A. Basic Constructs
be highly configurable. The lower-level component
configuration tools should exchange information with the A System Composer model consists of an architecture
system architecture model to directly drive the component diagram that shows all the architectural elements in the model.
configuration. This ensures the implementation remains synced The three main architectural elements are components, ports,
with the integration model and helps to minimize errors and connectors. A component can have multiple ports, which
between the model and implementation. Ideally, the system have a specified direction. Connectors are represented as lines
architecture model serves as the single source of truth that is from an output port to an input port. Components can have
common across all systems. This provides a path to integrate child components as many layers deep as desired. This drill-
lower-level component tools with a common integration model down philosophy supports scalability, by enabling the model to
to ensure all system developments remain aligned during the be managed in layers, rather than showing all model
design change cycles. components in one large flat model layer. A simple example
model showing two components with ports connected via a
connector is shown in Figure 2.
III. CURRENT STATE OF SYSTEM ARCHITECTURE
MODELING The data that flows out of one component via an output
port, through the connector, and into another component via an
The Gulfstream authors reviewed current system input port can have a specific structure or content. This
architecture modeling methods and found the methods did not structure or content can be specified through an interface. An
fully meet their needs and capabilities. The method either interface can start by simply being a named piece of data, but

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
as the model is elaborated, it can be refined to have elements B. Managing Complexity with Reuse
with specified data types and dimensions, or which themselves As the system is elaborated and detail is added, the model
can be interfaces, creating a nested structure of signals. When can become complex. To manage this complexity, it can be
an interface is applied to a port, the connected port also has the helpful to create a component that will be reused within the
same interface applied to it. If the ports are intended to have architecture. For example, a specific type of sensor may be
different interfaces, an adapter block may be added to define used throughout the system and always have the same
how one interface relates to another. An Adapter block is structure. In this case, the sensor architecture model can be
shown in Figure 2 between the OutPort of ComponentA saved as a separate model file and then referenced from the
and the InPort of ComponentB. system architecture model. The sensor model can use the same
In most realistic models, there will be many interfaces profile and data dictionary as the system model.
defined throughout the system. These interface objects can be Another consequence of increasing complexity is that the
stored as part of the model file, or in an external file called a diagram may become large and difficult to view and navigate.
data dictionary. A data dictionary can be used by many model There may be many domains represented in a single model –
files. mechanical, electrical, and software components. One way to
The architectural elements and interfaces can be extended simplify the diagram is to display only the parts of the model
through the use of stereotypes, a concept familiar to those who that are of interest to the individual viewing the model. This
know UML. For example, a hardware component can be construct is called a view architecture, which can be thought of
distinguished from a software component by applying the as a window into the model that enables only part of the model
hardware component stereotype to it, as shown on to be visualized.
ComponentA in Figure 2. This stereotype might include A view architecture can be constructed manually by
properties, such as weight, volume, or part number. explicitly selecting the set of components or automatically via
Stereotypes can be collected together and stored in a profile. A a query of the model structure. For example, we may wish to
profile is a separate artifact from the model that uses it. This see only the mechanical components in our architecture – all
independence allows the profile to be shared among many the components that have the “mechanical” stereotype applied
models. Profiles and stereotypes can be created and defined in to them. We can author these queries using a rich, MATLAB-
the profile editor. Properties can be set on a given element by based language or through a wizard-like GUI. Lastly, a
editing them in the property inspector. specialized filtered view, called a spotlight view, which shows
only the components connected to the currently selected
component, can automatically be created through a menu.

Canvas

Property Inspector

Interface Editor
Requirements Viewer

Figure 2: Simple System Composer model

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
C. Requirements Traceability F. Integration with Design Environment and Simulation
Textual requirements are an important part of the As part of the iterative process of elaborating the
development process. Architectural diagrams may be derived description and design of the system, Simulink is often used to
from textual requirements and contribute to the next level of start describing desired behaviors or even implementation.
requirements. Traceability between these layers is vital and is a These behavior and design models can be linked directly into
key feature of both System Composer and Simulink. This is as a System Composer model, giving the user quick access to the
simple as dragging and dropping the requirement from the work the design engineers are doing.
requirements viewer, as shown in Figure 2, to model
constructs. The ability to link between textual requirements and Additionally, if enough components have linked
models helps to establish a digital thread throughout the behaviors, the user can simulate the architecture model in
development process. Simulink. This enables additional forms of analysis and
validation as the design process continues.
D. Model Allocation
It is common to have multiple architecture diagrams that G. Scaling Up to Organizational Use
describe different lenses into the system. Often, a functional MATLAB and Simulink use file-based storage of models
architecture is described first, as a way to understand what and artifacts, which easily integrates into existing source
functionality must be included in the system and what control systems such as SVN [8] or Git [9]. All the files related
information those functions must exchange. After that, it may to a specific vehicle or program can be bundled together into a
be useful to describe a logical architecture that shows the project. These projects allow for setting up custom
logical components of the system such as the breakdown of an environments, integration with source control, packaging for
aircraft into a propulsion system, an airframe, etc. Finally, sharing, and dependency and impact analysis.
there are the physical components that make up the system.
These are the boxes, connectors, sensors, actuators, and Since System Composer is part of the MATLAB
physical parts that are assembled. Breaking a system model environment it benefits from a mature built-in scripting
down into these different architectures is a good way to language for automation and customization. A rich set of APIs
manage the complexity of large systems. for all the previously mentioned functionality enables common
tasks to be scripted and automated. These APIs also allow
These architectures are typically related to each other via access to any of the information stored in the models or
allocation. A particular function is allocated to a logical supporting artifacts, so data can be extracted and shared with
component or system, then that logical system is allocated to a other programs. Additionally, there is tabular format for
piece of hardware represented as a physical component in the importing and exporting existing models from and to other
physical architecture. This common system engineering internal tools and formats. This combination of an API-based
workflow is supported in System Composer Release 2020a. approach and a simple, tabular format gives the user flexibility
to decide which approach best meets their needs.
E. Model Analysis
Analyses based on stereotype property values can be V. ELECTRONIC SYSTEM ARCHITECTURE MODELING
initiated through the Analysis Viewer. The Analysis Viewer METHOD
guides the user through the creation of an analysis instance of The authors have created the Electronic System
their model, essentially a “sandbox” where the user can run Architecture Modeling (eSAM) method to support the
what-if scenarios without modifying the original model. The Gulfstream system architecture modeling needs. System
Analysis Viewer displays the results of the analysis in a tabular Composer is purposefully designed to support a wide variety of
format. modeling methodologies using the tool’s generic modeling
One example of a common type of analysis is a Size, constructs. eSAM provides a standard approach to model
Weight, and Power (SWaP) roll-up. In this analysis, the user electronic systems using these generic modeling constructs.
has defined some attribute such as weight for all the lowest- eSAM provides the following guidance:
level components in the model. The user wishes to add up all
these values to see what the total weight of the system is. The • How to model functions, physical components,
Analysis Viewer can help the user to select the property of communication ports and data parameters
interest, beginning at the lowest level of the hierarchy and
working up through each branch, adding up the weights of the • How to model functional and physical
child components at each level, until every component in the architectures
system has been visited and had its weight added to the total. • How to model subsystem integration
Many additional types of analysis can be scripted using the
model and analysis APIs and the range of available MATLAB
functions.

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
 The eSAM method is applied to an example system for B. Functional Architecture Models
purposes of describing the method. A simplified version of a A functional decomposition and subsequently functional
radar altimeter is used for this example. A radar altimeter is an flow models of the system can be created to establish
aircraft system used to measure the distance between the relationships between the various system functions and is
aircraft and the terrain directly below the sensor. System depicted in Figure 4. This allows the user to define and
Composer Release 2020a was used in this example. visualize the relationships between the system functions, using
A. Modeling Functions, Physical Components,
Communication Ports, and Data Parameters
Both functional and physical architectures are modeled
using a similar method. When modeling electronic systems, a
System Composer component can represent a function, a piece
of physical hardware, a hosted software application, or other
items, and are distinguished by utilizing and applying
stereotype properties. A function stereotype is created and
applied to a functional component and includes function-
related properties such as system and system owner. Likewise,
a software stereotype is created and applied to software
components and includes software-related properties such as
required memory. Finally, a hardware stereotype is created and Figure 3: Applying System Composer constructs to electronic system
applied to a hardware component and includes hardware- architecture models
related properties such as weight.
One or more ports can be applied to a component as either
an input or output port. Per the eSAM method, each port on a
function component represents a data inflow/outflow to another
function (only one port for functional exchanges should be
defined between any two functions). Each port on a hardware
component represents a physical data port such as Ethernet,
ARINC 429, or analog input. Each port on a software
component is a logical representation of the physical hardware
port that the data will flow through, such as a logical Ethernet
port. With the eSAM method, there is only one logical port on
the software component per physical port on the host hardware.
Connectors establish a relationship between two or more ports
by linking them with a graphical line. Interfaces are used to
represent the data which flows through the ports. Elements are
children of interfaces and used to represent the individual data
parameters within the dataflow and can be configured as
specific data types such as integers, enumerations, or a
grouping of data. While input ports can only have a single
connector applied, an Adapter block can be used to combine
multiple connectors into a single output (many-to-one).
Adapters are also used when identical data parameters
(elements) of different names need to be mapped between
different subsystems. For example, a subsystem may define
“airspeed” as an input, and the sourcing subsystem may
publish the data named as “CalibratedAirspeed”. An adapter
maps “airspeed” to “CalibratedAirspeed” so it is known as the
same data parameter in the model. These basic model
constructs are illustrated in Figure 3.
Recall that stereotypes are used to apply metadata to the
model constructs. The metadata can be extracted for use in
other downstream tools that may be part of the development
workflow. For example, Gulfstream uses the stereotypes to
store hardware/software component configuration data that is
used by downstream tools to configure the components directly Figure 4: Functional decomposition and flow models
from the system architecture model such as ARINC-664 End
System configuration).

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
simple graphical relationships. For avionics systems, this functional flow model, including the data exchanges between
artifact supports the ARP-4754a development process functions. The functional data exchanges are based on the
guidelines. physical data exchanges modeled in the physical model and
translated to the functional domain based on the allocation of
In this simplified example, the functional flow diagram is functions to physical components.
used to establish the relationship between the function to
measure the height above terrain and the functions to provide
crew indications and warning functions. These relationships C. Physical Subystem Architecture Model
between the functions are established using ports and In the eSAM workflow, a physical architecture model is
connectors. used to establish physical data exchanges between electronic
hardware and software components in a subsystem. Subsystem
In most system architecture modeling tools, the functional models can be created independently, in parallel, by different
flow model is defined separately from the physical model, and teams or organizations. In Figure 5, two sensors have been
therefore must be manually updated to remain synced with the inserted into a canvas to represent the radio altimeter
evolving physical model. Normally, the two models are not subsystem. Subsystem data parameters such as
completely synced until the end of the program in order to L164_RadioHeight1 and L164_RadioHeight2 can be
produce certification artifacts. This leaves much room for error individually defined as elements within an interface and
and minimizes the utility of the system architecture model assigned to ports on the subsystem components. Internal data
during development (because it does not accurately represent exchanges are defined within the subsystem component, but
implementation). any data parameters that need to be exchanged externally to the
A very powerful aspect of the eSAM method is the auto- subsystem are identified and linked to the boundary of the
generation of a functional flow model, which is easy to create subsystem, as shown in Figure 5. It is worth noting that System
at any point in the development cycle. The eSAM method Composer displays the relationship between internal and
utilizes a MATLAB script, written by the authors, to external ports without the need for graphically drawing lines,
automatically generate a functional flow model based on a which tended to clutter the view in other tools that were
functional decomposition model in System Composer and the evaluated. The purpose of the ports at the boundary of the
physical architecture model. The functional decomposition subsystem model is to clearly identify which dataflows and
model does not define any data flows between functions. The parameters the subsystem is expecting to receive from other
functions in a functional decomposition model are allocated to external sources, and which dataflows or parameters the
hardware/software components in the system physical model subsystem is expecting to produce that may be used by other
using the model-to-model allocation feature in System subsystems. With the subsystem inputs and outputs defined,
Composer. The MATLAB script auto draws the functions in a data parameters assigned, and metadata populated, the process

Figure 5: Radio altimeter subsystem

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
to create formal interface control documentation in a consistent corresponding ports on other subsystems in order to illustrate
format across all subsystems becomes possible and could be the exchange of data parameters. In this example, the Radio
automated using scripts or other third-party tools if desired. Altimeter reference model is publishing data parameters to the
Flight Deck Display reference model.
D. System Integration Model
It is common for subsystems to be developed by different
The next step in the eSAM workflow is to integrate the groups or even different companies. Thus, it may not always be
separate subsystem models together within a system integration
feasible or practical to coordinate the naming of data
model. The system integration model allows the user to map
parameters between subsystems. In our example, the Radio
and adapt data parameters between subsystem models using the
ports at the subsystem boundaries. Again, this concept Altimeter subsystem group may have named the parameter
eliminates the clutter of using lines to represent connections they are producing ‘RadioHeight2’ while the Display
from individual components within a subsystem to individual subsystem group may have named the parameter they were
components within another subsystem. expecting ‘RADALT2’. System Composer allows the system
integrator to conveniently address this parameter name
Subsystem models that have been inserted into a system discrepancy via the use of the adapter construct. An adapter is
integration model are referred to as reference models. used to map data parameters that are named differently to each
Reference models are representations of the subsystem models other without requiring the subsystem owner to rename the
within the larger integration model. This behavior within data parameters throughout their subsystem model(s). The
System Composer ensures that the parent subsystem model adapter entity is applied to a connector, and the adapter
always remains the sole definition of the subsystem across all properties dialog box, shown in Figure 6, facilitates the
reference model instances of the subsystem. While working mapping between one or more parameter names that are being
within the system integration model, if the user determines an exchanged between two subsystems.
additional port is required on the subsystem, it is a simple
matter of double-clicking on the subsystem reference model to
VI. OEM APPLICATION OF SYSTEM COMPOSER CORE
open it, add the new port, and then ascend back to the system
FUNTIONALITY
integration model. The new port will appear on each instance
of the subsystem reference model. It is worth noting that, while not a formal part of the eSAM
method, an OEM can leverage some of the core features of
In our example, Figure 6 shows the system integration System Composer to manage models across an aircraft
model in which two different subsystem models have been development program.
inserted as reference models. The external ports and interfaces
on each reference model can now be joined with the

Figure 6: System integration model with data parameter mapping mechanism for data routing

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
A. Software Model and Linking B. Multi-Organization Collaboration
System Composer and Simulink are part of the same Large models are developed by many stakeholders across
development environment and are tightly coupled, so it is easy many groups, organizations, or companies. Gulfstream expects
to create, access, and run Simulink models within System system suppliers to deliver a System Composer model of their
Composer, by embedding those Simulink models within the subsystem, which documents their system architecture and I/O.
components of the architecture model. The dataflows into or Changes need to be managed and controlled.
out of the component in the System Composer architecture Due to the file-base model format, subsystem models can
model are immediately synced with the inputs or outputs be easily exchanged between suppliers and Gulfstream. This
required to run the Simulink simulation model and vice-versa. allows the aircraft model to be worked across many
In the radio altimeter example, a simplified logic model organizations that are geographical distributed. A file-based
represented in Figure 7 has been created in Simulink to trigger configuration management tool, such as SVN or GIT, is used
to provide revision management for the model files.
Configuration management tools can be selected independently
by each subsystem supplier, and Gulfstream, according to their
own company standards.
Change control is managed by process. When suppliers
deliver updated subsystem model versions, the models are first
reviewed outside the master repository. The System Composer
difference report is leveraged to review changes between
model versions, allowing the OEM to determine if they will be
accepted. System integration impacts can be investigated
within the master aircraft model. If the updated subsystem
Figure 7: Embedded Simulink model
model is accepted, the files are simply copied into the master
repository. If these models were already included in the
systems integration model as reference models, then the
systems integration model will immediately reflect the updated
subsystem models without further action.

C. Model Views
Aircraft models are very large, and Gulfstream relies on the
architecture views feature to navigate and filter on the subset of
model information that is relevant for a given task. For
example, when troubleshooting a system in the lab, a user may
wish to create a view to understand the path for an end-to-end
data flow. A system integrator may wish to create a view for all
components provided by a single supplier, where supplier is
defined in the component’s stereotype property. In order to
identify all high-power components, a system owner may wish
to create a view that shows all components that consume more
Figure 8: Simulink model embedded within a System Composer than X amps, as defined by a component stereotype property.
component To evaluate impacts of a signal change, a view can be created
that includes the producer and all consumers of the given
an alert when three conditions are met. The Simulink
signal. The possibilities for views are very extensive and can
simulation model can be placed within a System Composer
be defined real-time by users interacting with the model.
software component and is displayed as illustrated in Figure 8.
Figure 9 provides an example of a realistic system integration
This allows the user to validate the logic or algorithm via
model, along with a model view of components that consume
simulation at the system architecture level, in the context of
greater than 5W of power.
multiple Simulink models integrated together.

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.
 It is the authors’ intention to publish future iterations of the
eSAM modeling method once it is further developed to meet
Gulfstream’s needs.

REFERENCES

[1] MathWorks, “System Composer”, website:

https://www.mathworks.com/products/system-composer.html, March
2020
[2] T. Gaska, C. Watkins, Y. Chen, “Integrated Modular Avionics-Past,
Present, and Future”, IEEE Aerospace and Electronic Systems
Magazine, Vol 30, Issue 9, pp. 12-23, September 2015.
[3] Microsoft, “Visio”, website: https://products.office.com/en-
us/visio/flowchart-software, March 2020.
[4] SysML.org, “SysML Open Source Project”, website: https://sysml.org/,
March 2020.
[5] Ecplise, “Arcadia Method at a Glance”, website:
https://www.eclipse.org/capella/arcadia.html, March 2020.
[6] Carnegie Mellon University, “Architecture Analysis and Design
Language”, website: https://www.sei.cmu.edu/research-capabilities/all-
work/display.cfm?customel_datapageid_4050=191439, March 2020
[7] MathWorks, “System Composer Documentation”, website:
https://www.mathworks.com/help/systemcomposer/index.html, March
2020.
[8] Subversion® (SVN), “About TortoiseSVN”, website:
https://tortoisesvn.net/, April 2020.
[9] Git™, “git – distributed-is-the-new-centralized”, website: https://git-
scm.com/about, April 2020.

Figure 9: Model view example of a system integration model and a

filtered view using the architecture view feature

VII. CONCLUSIONS AND NEXT STEPS

In the search for a system architecture modeling tool,
Gulfstream has selected MathWorks System Composer and has
developed the eSAM method in order to standardize how the
general modeling constructs are used to model avionics
systems. It is worth noting that the eSAM method is not limited
to the avionics domain and can be used for any electronics
system architecture.
The eSAM method is new and continues to be developed.
A specific area of continued research is how to model
subsystem allocations to an Integrated Modular Avionics
platform. That is, how a system integrator can independently
allocate software applications to a general processing platform,
and how system I/O can be allocated to a remote data
concentration (RDC) network.
Additionally, the authors are exploring methods for
deriving functional architectures from system implementations
to support analyses of functional dependencies and fault
propagation. This should serve to better link the
hardware/software implementation with the safety design at the
functional level: functional hazard analysis (FHA) and system
safety assessment (SSA).

Authorized licensed use limited to: DRDO-DEAL. Downloaded on November 20,2024 at 07:25:52 UTC from IEEE Xplore. Restrictions apply.