Welcome to the system architecture modelling and analysis manual. This manual introduces
the basic concepts, several applications and our methods and tools for system
architecture modelling and analysis.
Engineering design concerns the process of creating solutions in the form of technical
systems for problems. The design space spanned by needs, requirements, and constraints.
These can be set by material, technological, economic, legal, environmental and human
An important step in the translation of needs, requirements and constraints into
technical solutions is the design of the system architecture. The architecture of a
system has a significant impact on a its performance, e.g., reliability, availability,
maintainability, and costs. Moreover, insight into the system’s architecture is required
to estimate the impact of (re)design decisions. That is, the designs of system
components are usually dependent on one another. As such, design choices with respect to
one component may affect the design of other components. Overlooked dependencies often
cause costly and lengthy design iterations.
As systems become increasingly complex the chance on overlooked dependencies increases
exponentially. Therefore, engineers need methods to structure, visualize, and analyze
needs, requirements, and constraints. This is exactly what Ratio Computer Aided Systems
Engineering aims to offer. Our methods and tools aim at supporting engineers to reduce
the chance on overlooked dependencies and enable them to develop better systems in less
time and at fewer costs.
In the literature on can find many models of the
engineering design process. The design-process figure is a schematic representation of
the design process which combines the V-model [FM91], spiral
model [Boe88] and design phases of Pahl and Beitz
Starting at the top left, the needs (N) at the highest decomposition level are
specified. Next, a concept (C) and an embodiment (E) are chosen for each component.
During detailed design (D) one aims to verify whether the needs can be fulfilled given
the concept and embodiment choices. If so, the first customer validation point is set to
check whether the solution satisfies the customer needs thus far.
Schematic representation of the engineering design process.¶
Subsequently, one can move to the next decomposition level at which needs are specified,
concepts and embodiments are chosen and verified for all (sub)-components. This process
continues until a sufficient level of detail is achieved to start the realization phase
(right side of the V). To ensure proper component integration it is essential to have a
proper understanding of the system architecture during all phases and at all
decomposition levels of the design process. Lack of understanding often leads to costly
and lengthy design iterations.
Systems engineering traditionally advocates the use of separate requirement, function,
and component trees, as shown in decomposition-trees. Creating dependencies between
these trees is done manually. This is a non-trivial, cumbersome and error prone task,
which relies heavily on the good-behavior of the modeller to obtain a proper model.
Moreover, the neat requirement and function hierarchies often do not exists in
real-life. That is, design decisions made during the project often yield new requirement
and new functions, which do not fit within the hierarchical structure.
Separate requirement, function, and component trees with dependencies between them, as advocated by traditional systems engineering practice.¶
Finally, the primary goal of the resulting network is to ensure traceability of
requirements to functions and physical components. Therefore, it does not represent the
Ratio methods and tools build upon the system architecture definition of Ulrich and
Eppinger [Ulr95]: “system architecture is the mapping of a system’s
functions to the physical components within the system, and to the dependencies between
In the literature, dependency structure matrix (DSM) methods are commonly used to model,
visualize and analyse system architectures in a large variety of industries. The book of
Eppinger and Browning [EB12] provides a wide variety of DSM
applications in industrie and academia alike. A DSM is a square \(N \times N\)
matrix in which a non-zero entry at position \((i, j)\) indicates that row
element:math:i depends on column element \(j\). A DSM can displays multiple
dependency types and strengths at once. Product DSMs are typically used to model
dependencies between components.
The two product DSMs on the left of the dsm_examples figure display four dependency
types between six components. One can highlight the system architecture by re-ordering
the matrix using a clustering algorithm. In this case, yielding an integrative (bus)
module and two independent modules. This provides opportunities to modularize a system.
Process DSMs, as shown on the right of the dsm_examples figure, are used to model
dependencies between functions or (design) parameters. The order of elements along the
diagonal of the DSM indicates the sequence in which each element is designed during the
process. Sequencing algorithms are used to reduce feedback loops (upper-diagonal marks)
which are a source of rework.
When systems grow in scale and complexity, it becomes challenging to obtain and maintain
an accurate and up-to-date model of the system architecture. Moreover, is is very
difficult to ensure the consistency of such a model with the system specifications which
are usually written in natural language. To overcome these challenges, Ratio has
developed the Elephant Specification Language (ESL) in cooperation with the Eindhoven
University of Technology. ESL is specifically developed to enable engineers to write
highly structured, multi-level, computer-readable system specifications from which
dependencies between requirements, functions, components, variables and combinations
thereof can be derived automatically.
In ESL the (functional) requirements are written following a fixed syntax (grammar)
within the system decomposition tree, yielding a single structured unambiguous system
specification. The ESL compiler performs consistency checks and derives a model of the
system architecture. This model can be used to optimize the design and the design
process of a system and serves as an interactive visualization of the system
In the Elephant Specification Language Manual and the Elephant Specification Language Reference ESL is explained in detail. This
manual shows how the resulting dependency network can be used to help structure and
coordinate your design process and enable you to improve your design. Moreover, it
guides you through the various proprietary Python Packages that have been specifically
created to process, visualize and analyze ESL specifications in particular and system
architecture models in general.
This chapter provides a brief overview of system architecture modelling and analysis
The main reason for creating a system architecture model is to gain better understanding
of the system such that one can organize and coordinate the design process more
effectively and efficiently. Thereby, improving system quality and reducing engineering
Section Dependency Structure Matrices already briefly explained how one can
modularize a system by analysing a product DSM with a clustering algorithm and how one
can schedule design activities by analysing a process DSM with a sequencing algorithm.
Furthermore, clustering and sequencing results can be used to determine how to organize
design teams or to determine which parts of a system or process can be outsourced.
Figure Dependency structure matrix types shows a generalized overview of DSM types.
In addition to product and process DSM, one can create organization DSM models,
multi-domain-matrix (MDM) models, and structure comparison DSM models.
Dependency structure matrix types.¶
An organization DSM shows for example the interactions between people within an
organization. In MDM model multiple DSM types are combined into a single figure. An
off-diagonal matrix in an MDM is named a domain-mapping-matrix (DMM) and relates
elements from one domain to elements in another domain. For example one can combine a
product DSM and process DSM into a single figure where the DMM relates components to
activities in the design process.
A structure comparison DSM can be used the compare system architectures of multiple
systems. An \(\Sigma\)-DSM emphasizes commonalities between system architectures
whereas a \(\Delta\)-DSM emphasizes differences.
A key performance indicator (KPI) is a variable that represents the quality of a system
in terms of a certain aspect, e.g., its reliability, availability or cost of ownership.
In design processes, resources are often too limited to perform (quantitative) KPI risk
analysis for the whole system. A projection dependency structure matrix (P-DSM) enables
one to quickly visually identify modules of components critical to various KPIs. The
critical modules are the focus area of subsequent (quantitative) KPI risk analysis.
Two projection DSMs indicating the areas of interest with respect to reliability and life-cycle-cost, respectively [WERV18b].¶
For example, the figure on the shows a regular DSM on which reliability (left) and
life-cycle-costs (right) impact estimates are projected. These estimates may be a simple
low impact (1), medium impact (3) or high impact (9) rating. The brighter the shade of
red, the greater the impact of that combination of components on the respective KPI. The
reliability P-DSM on the left shows that the combination of components c4, c1 and c3 has
the greatest impact on the reliability of the system. The life-cycle cost (LCC) P-DSM
shows that the combination of components c1, c3 and c5 has the greatest impact on (LCC).
The P-DSMs clearly show the area of interest regarding the respective KPI.
During any design process one has to make many design decisions, that may impact the
architecture and performance of the system. To visualize the effect of design choices on
the system architecture, one can use a comparison dependency structure matrix (C-DSM) as
depicted in figure below.
Schematic comparison DSM showing the differences between two alternative system architectures [Mee19].¶
The C-DSM displays two system architectures in a single Figure. The green and red shaded
areas contain the elements and dependencies of the two options. Grey elements (7-12) are
shared among both architectures. Pink elements (1-3) are only present in the First
option. Black elements (13-14) are only present in the second option. Yellow elements
(4-6) are present in both options but have different dependencies.
As such, the C-DSM provides a compact overview of the architectural differences between
two design alternatives. This overview serves as a ‘discussion figure’ during expert
meetings. That is, the system experts can discuss the benefits and down sides of each
design alternative by systematically following the figure. This enables them to focus on
details while maintaining an overall overview.
A major challenge in product family design is to select a realization strategy that
balances the external variety offered to the customer with the internal complexity of
managing the design, fabrication and maintenance of many different product variants
The figure below shows several realization strategies in relation to the input required
for the realization of a product using each strategy. A Engineer-to-Order strategy only
requires legislation and customer requirements as input. Subsequently, each product is
re-engineered. An Assembly-to-Order strategy requires standard products and customer
requirements as input. Subsequently the standard product that best fits the customer
requirements is assembled.
Several realization strategies.¶
Many companies chose a make-to-order or a configure-to-order strategy to offer the
customer variety and customization options while minimizing internal complexity. The
foundation of such a strategy is a basic product architecture which contains the common
core of all product family members. That is, the set of modules of components and their
(functional) dependencies that are present in all products. The common core may be
extended with optional modules. The basic product architecture should account for these
dependencies with optional modules as well to ensure proper and fast component
integration once a customer order has been received. Moreover, a basic product
architecture enables one to standardize common core and optional modules and the
dependencies between them and create a product family platform which further reduces
The design of a product family requires the creation of a basic product architecture
from which all product family members can be derived. By analyzing the similarity of
products within an existing product portfolio one can get an indication on which and how
many product variants have to be supported by the architecture.
The figure below shows a three step method to find groups of similar products within a
diverse product portfolio. Each group represents a variant which must be supported by
the basic product architecture.
The three steps of the product portfolio similarity analysis [WERV18b].¶
First, one has to build a binary characteristic mapping matrix M, relating
characteristics k:math:_i to products p:math:_i. Next, one can calculate a product
similarity matrix S, indicating how similar two product are based on the selected
characteristics. The third step comprises the pruning of S, joining it with M
and reordering the matrix with a cluster algorithm. The result provides groups of
similar products and shows which characteristics they possess. Here, the products in the
first group possess k:math:_1, k:math:_2 and possibly k:math:_3. Products in the
second group only possess k3.
A product portfolio commonality analysis reveals which modules of components belong to
the common core and which are optional within a group of products that form a product
family. The commonality analysis starts with building \(n\) binary dependency
structure matrices (DSM), one for each variant. Next, one can take the sum of the
\(n\) DSMs to obtain a \(\Sigma\)-DSM. The higher the value of a dependency
within the \(\Sigma\)-DSM, the more common that combination of components is with
the product family. Finally, by clustering the \(\Sigma\)-DSM, one can find modules
of components that are common and modules that are optional. For example, in the figure
below, five DSMs are summed into a \(\Sigma\)-DSM. Clustering reveals that
components c4, c1, c3 and c5 are present in almost all variants, while c2 and c6 are
optional. The common components and their dependencies shape the basic product
architecture for all variants.
Example \(\Sigma\)-DSM [WERV18b].¶
To make life a little bit easier we have created several Python Packages for handling,
visualizing and analysing ESL specifications in particular and graphs in general. You
Check out the Graph Handling Python Package Docs for detailed graph handling documentation.
Check out the Dashboard Python Package Docs for detailed graph visualization documentation.
Check out the Graph Analysis Python Package Docs for detailed graph analysis documentation.