# A formal process of hierarchical functional requirements development for
Set-Based Design

Minghui Sun  Coordinated Systems Lab
Department of Mechanical Engineering
Iowa State University
Ames, IA 50011
Email<EMAIL_ADDRESS>Zhaoyang Chen  Coordinated Systems Lab
Department of Mechanical Engineering
Iowa State University
Ames, IA 50011
Email<EMAIL_ADDRESS>Georgios Bakirtzis  Autonomous Systems Group
Oden Institute for Computational Engineering & Sciences
The University of Texas at Austin
Austin, TX 78712
Email<EMAIL_ADDRESS>Hassan Jafarzadeh  Advanced Control Methods
Research and Advanced Engineering
Ford Motor Company
Dearborn, MI 48126
Email<EMAIL_ADDRESS>Cody Fleming  Coordinated Systems Lab
Department of Mechanical Engineering
Iowa State University
Ames, IA 50011
Email<EMAIL_ADDRESS>
###### Abstract

The design of complex systems is typically uncertain and ambiguous at early
stages. Set-Based Design is a promising approach to complex systems design as
it supports alternative exploration and gradual uncertainty reduction. When
designing a complex system, functional requirements decomposition is a common
and effective approach to progress the design incrementally. However, the
current literature on Set-Based Design lacks formal guidance in functional
requirements decomposition. To bridge the gap, we propose a formal process to
hierarchically decompose the functional requirements for Set-Based Design. A
four-step formal process is proposed to systematically define, reason, and
narrow the sets, and eventually decompose the functional requirement into the
sub-requirements. Such a process can be used by the individual suppliers
working in parallel at multiple levels of abstraction and guarantee that the
resulting system will eventually satisfy the top-level functional
requirements. An example of designing a cruise control system is applied to
demonstrate the feasibility of the proposed process.

##  1 Introduction

Modern complex systems are usually developed in the OEM-supplier mode. The OEM
(or a higher-level supplier) decomposes the top-level functional requirements
into lower-level ones and assigns them to the lower-level suppliers that work
in parallel. Getting the functional requirements decomposition correct is
crucial for the success of product development.

One of the challenges of functional requirements decomposition is that the
design of complex systems is typically uncertain and ambiguous at early stages
[1]. Set-Based Design (SBD) [2] is particularly suitable to tackle this
challenge as it provides great support in robust design alternative
development, uncertainty reduction and resolution [3], and supplier/subsystem
autonomy and optimality [4]. In SBD, the overall system design problem is
typically decomposed into multiple distinct disciplines, each utilizing their
own sets of possibilities [5]. Teams of engineers develop a set of design
alternatives in parallel at different levels of abstraction and narrow the
prospective set of alternatives based on additional information until a final
solution is converged [6].

Our ultimate goal is to automate functional requirements decomposition for SBD
because manually decomposing functional requirements is time-consuming and
error-prone. This paper, _as our first step towards this goal_ , aims to
formalize the functional requirement decomposition process in the context of
SBD. Although function decomposition may not be nominally related to SBD, it
clearly features set-based reasoning [4].

This paper addresses the following objectives.

  * •

Objective 1: Creating methods, leveraging SBD, to formally decompose the
functional requirements.

  * •

Objective 2: Provide formal guarantees that the resulting component designs
are composable, and the system as a whole will satisfy the top-level
functional requirements.

Objective 2 is a constraint on Objective 1, and therefore is addressed first
in Section 4. We then ensure that this constraint from Objective 2 is
considered when reasoning about Objective 1 in Section 5. Achieving these
objectives would allow design teams to work at different levels of abstraction
in parallel and asynchronously, providing a path towards more seamless
integration for OEMs.

For Objective 1: There is little attention in the SBD literature to a general
formal process of functional requirements decomposition for complex systems.
Shallcross et al. pointed out that “there is limited SBD research contributing
to requirements development” [7] and SBD methodologies applied to complex
systems are mostly qualitative [3]. Ghosh and Seering [4] posited that SBD had
not been formally defined, despite many authors having studied its process
inspired by the example of Toyota. Therefore, in response to Objective 1, we
propose a four-step formal process by applying set-based reasoning to
systematically define, reason, and narrow the sets, and eventually decompose
the functional requirement into the sub-requirements. Dullen et al. [8] and
Specking et al. [5] observed that “there has been limited (formal) guidance on
how to define, reason, and narrow sets while improving the level of
abstraction of the design”, which is precisely the proposed process aims to
improve.

Furthermore, the proposed process makes two additional contributions to the
SBD literature. First, most SBD approaches formulate the functional
requirements as the ranges of the elements in the performance spaces. Such a
formulation applies to many mechanical components at lower levels. However,
for systems at higher levels, the function is usually defined as a
transformation between the inputs and outputs. Accordingly, the functional
requirements have to be defined as a mapping between the ranges of the inputs
and the outputs. Our process focuses on the latter formulation as we focus on
the requirements development of complex systems. Therefore, the proposed
process solves a different problem than most current SBD approaches and is a
complement to the current SBD literature.

Second, according to Eckert et al. [9], there are two ways to address
uncertainties: “buffer” as “the portion of parameter values that compensates
for uncertainties”, and “excess” as “the value over, and above, any allowances
for uncertainties.” The current SBD literature does not make explicit
distinctions between buffer and excess when addressing the uncertainties and
hence lacks specificity in their robustness claims. In our process, buffer and
excess are addressed with a clear distinction in their respective steps, where
buffer is practiced to reduce the controllable uncertainties, and excess is
practiced to accommodate the possibility of an under-estimated initial
characterization of the uncertainty.

For Objective 2: SBD claims autonomy of teams of designers is an advantage of
SBD [10], but very little SBD work provides a priori proof of this property.
In fact, one cannot rigorously justify such a claim without an explicit
underlying formalism. Based on the formalism defined in this paper, we can
prove that when the functional requirements are decomposed in a specific way
(i.e., composable and refinement), individual design teams can work
independently, and the resulting system as a whole will satisfy the top-level
functional requirements.

In summary, we propose in this paper a formal process to hierarchically
decompose the functional requirements in the context of SBD. Individual design
teams can use the proposed process to decompose the functional requirements
independently and eventually achieve a system that satisfies the top-level
functional requirements. We demonstrate the feasibility of the proposed
process with an example of designing a cruise control system based on existing
computational tools.

##  2 Background

###  2.1 Qualitative SBD approaches

There are qualitative procedural models concerning requirements development in
the literature. Enhanced function-means modelling (EF-M), a method for
function modeling [11] was used in combined with SBD to manage platform-based
product family design [12]. Functional decomposition and solutions were
generated according to EF-M. At each level of abstraction, there is a mapping
from FR to DS, and a mapping from DS to the FR to be assigned to the next
level [13]. The two mappings are conceptually aligned with the approach
proposed in this paper.

A “wayfaring” model was introduced for set-based requirement generation as a
map to discover critical functionalities and create dynamic requirements in
[14]. It was found that prototyping critical functionalities could guide the
design process from the initial concept idea to arrive at a final product with
low tooling and production costs. A novel set-based approach (MBRMA) was
developed to filter out weak or costly solutions over time and assess system
engineers when adopting trade-off analysis [15]. Although a mathematical
formalism containing the requirements, subsystems, activities, and components
was defined in this paper, this article did not provide specific guidance on
how to decompose the requirements. Another framework based on a set-based
engineering approach allows for building re-usable and adaptable engineering
methods [16]. The proposed “virtual methods” can be used to create and
validate the early phase design requirements, and make sure the introduction
of novel technologies to increase the engine subsystem performance can be
realized without compromising the requirements on risk and cost. More
frameworks exist, such as CONGA [17], DMIV [18], MBSS [19], RR-LeanPD model
[20], and a combination of V-model and SBCE [21].

One weakness of the qualitative approaches is the ambiguity about the concrete
activities needed to accomplish the requirements development process, which
makes it challenging for them to be repeated by the general industry
practitioners. Therefore, a formal process is needed to provide precise
instructions on decomposing the functional requirements and assigning them to
the lower level of abstraction in a transparent and repeatable way.

###  2.2 Quantitative SBD approaches

There are many quantitative techniques for design space exploration in SBD. We
focus on the quantitative approaches that have a discernible feature of
hierarchical decomposition to make a meaningful comparison to the approach of
this paper.

SBD has been applied to the design of a downhole module to demonstrate whether
their method previously developed in a laboratory setting had the same
potential when practiced in the actual industry setting [22]. The downhole
module was decomposed into a chassis subsystem and a bumper subsystem. The
system-level team assigned the design “target” to the subsystem based on a
downhole assembly impact model. Mathews et al. applied a set-based approach
for a multilevel design problem of negative stiffness metamaterials based on
Bayesian Network Classifier [23]. The design process progressed in a top-down
fashion from the macro-level to the meso-level to eventually the micro-level,
which was a typical hierarchical design approach. Both [22, 23] have
distinctive features of “hierarchical decomposition”, but they “walk down” the
hierarchy by treating the design space of the higher-level abstraction as the
requirements for the lower-level design, which is different from our problem
formulation.

Jansson et al. [24] combined Set-Based Design with axiomatic design to manage
and evaluate the performance of multiple design alternatives against the
established functional requirements. This work considered the mapping from the
design space of the higher level of abstraction to the functional requirements
for the lower level, but did not show how specifically the functional
requirements for the lower level of abstraction are derived. A set-based
approach to collaborative design was proposed in [25]. The overall system was
decomposed into distributed collaborative subsystems, where each design team
built a Bayesian network of his/her local design space and shared their
Bayesian network to identify compatibilities and conflicts to improve the
efficiency of local design space search. However, the design problem was
formulated to optimize an objective function at the top level rather than
decomposing the given requirements into the lower level.

A Serious Game was proposed in [26] to illustrate how the customer
requirements of an airplane design can be decomposed into the design
parameters of the body, tail, wing, and cockpit by applying the principle of
SBD. Although the game was only for educational purposes, it showed a clear
process of deriving the ranges of the design parameters at the lower level
from the ranges of the higher-level design parameters. [27] presented an
Interval-based Constraint Satisfaction Method for decentralized, collaborative
multifunctional design. A set of interval-based design variables were
identified and then reduced systematically to satisfy the design requirements.
SBD was also used by [28, 29] to inform system requirements and evaluate
design options by identifying the number of potential feasible designs in the
tradespace for each requirement or combination of requirements. The case study
was conducted on the design of a UAV to demonstrate how to assess whether the
relaxation of the requirements will create better options. The results
demonstrated that SBD provides a comprehensive tradespace exploration and
valuable insights into requirement development.

In summary, the functional requirements in these approaches are ranges of the
variables in the performance space rather than a mapping between ranges of the
design space and the performance space as defined in our process. Such a
difference has a significant implication in the requirements decomposition
process. The decomposition in other approaches is fulfilling a mapping from
one set of the ranges (of the performance space) to another set of ranges (of
the design space), while the decomposition in our process is accomplishing a
mapping from one mapping (between the ranges of the design space and the
performance space of the higher level function) to a set of mappings (between
the ranges of the design space and the performance space of the sub-
functions).

###  2.3 Design uncertainty

SBD is known for its robustness to design uncertainty [30, 31, 32]. In an
introduction about the application of SBD by the U.S. Naval Sea Systems
Command, [33] pointed out that SBD was particularly fit for design problems
where there were many conflicting requirements and a high level of uncertainty
in requirements. This observation was corroborated by [34], “SBD allows
designers to develop a set of concepts, so changes in the design requirements
are easier to adjust to.” In an approach that incorporated Bayesian network
classifiers for mapping design spaces at each level, “design flexibility” was
defined as the size of the subspace that produced satisfactory designs, and
“performance flexibility” was defined as the size of the feasible performance
space relative to the size of the desired performance space [10]. In [35], a
Set-Based Design methodology was proposed to obtain scalable optimal solutions
that can satisfy changing requirements through remanufacturing. The
methodology was demonstrated on a structural aeroengine component
remanufactured by direct energy deposition of a stiffener to meet higher
loading requirements.

There is another line of work that combines SBD with platform-based design
based on Function-Means modeling techniques to preserve design bandwidth, a
system’s flexibility that allows its use in different products [36]. A dynamic
platform modeling approach based on SBD and a function modeling technique were
presented in [37] to represent product production variety streams inherent in
a production operation model. Following the SBD processes, inferior
alternatives were put aside until new information became available and a new
set of alternatives could be reconfigured, which eventually reduced the risk
of late and costly modifications that propagated from design to production.
Modeling platform concepts in early phases and eliminating undesired regions
of the design space was described in [13]. Change was considered in both the
requirements space and the design space. By applying set-based concurrent
engineering, sets of design solutions were created to cover the bandwidth of
each functional requirement. More work on this topic can be found in [38, 39].

Furthermore, [40] conducted a design experiment on how delaying decisions
using SBD could cause higher adaptability to requirements changes later in the
design process. As a result, the variable and parameter ranges were open
enough to accommodate the changes in the requirements. A method called
Dynamically Constrained Set-Based-Design efficiently provides a dynamic map
for the feasible design space under varying requirements based on parametric
constraint sensitivity analysis and convex hull techniques [41]. The
methodology ultimately allowed for identifying a robust feasible design space
and a flexible family of solutions. A hybrid agent approach was applied for
set-based conceptual ship design [42]. It was found that the process was
robust to intermediate design errors. After the errors were corrected, the
sets were still wide enough that the process could move forward and reach a
converged solution without major rework. More work can be found in [43, 44].

According to [45], “excess” is “the quantity of surplus in a system once the
necessities of the system are met”. Later, [9] defines “excess” as “the value
over, and above, any allowances for uncertainties”, and “buffer” as “the
portion of parameter values that compensates for uncertainties.” Robustness
achieved by addressing these two concepts has different meanings. Current SBD
literature lacks an explicit distinction between buffer and excess when
addressing the uncertainties, hence lacking specificity in their robustness
claims.

##  3 Preliminaries

###  3.1 Notation

We introduce the notation that is used throughout this paper. For a function
$f_{i}$, we make the following definitions. For function $f$, the same
concepts can be applied without “$(i)$”.

  * •

$a(i)=(a_{1}(i),a_{2}(i),...,a_{j}(i),...,a_{n}(i))^{\top}$ is a column vector
associated with function $f_{i}$, where $j=1,2,...,n$.

  * •

$R_{a_{j}(i)}$ is the range of $a_{j}(i)$, i.e., $a_{j}(i)\in R_{a_{j}(i)}$.

  * •

$\\{a(i)\\}$ is a set representation of $a(i)$, i.e.,
$\\{a(i)\\}=\\{a_{1}(i),a_{2}(i),...,a_{n}(i)\\}$.

  * •

$R_{a(i)}=(R_{a_{1}(i)},R_{a_{2}(i)},...,R_{a_{n}(i)})^{\top}$ is a column
vector of the ranges of $a(i)$, i.e., $a(i)\in R_{a(i)}$.

  * •

$\\{R_{a(i)}\\}$ is a set representation of $R_{a(i)}$, i.e.,
$\\{R_{a(i)}\\}=\\{R_{a_{1}(i)},R_{a_{2}(i)},...,R_{a_{n}(i)}\\}$.

Furthermore, we define the following set operations, where $a$ and $b$ are two
column vectors.

  * •

$\\{a\\}\sqcup\\{b\\}$ returns the union of the identifiers (instead of the
values) of all the elements in $\\{a\\}$ and $\\{b\\}$. The identical variable
between $\\{a\\}$ and $\\{b\\}$ are merged into one element. By “identical”,
we mean the elements that have the same physical meaning, the same data
source, and hence the same value _at all time_.

  * •

$\\{a\\}\sqcap\\{b\\}$ returns the identifier of the identical variable(s)
between $\\{a\\}$ and $\\{b\\}$.

  * •

$\\{a\\}\sqsubseteq\\{b\\}$ returns $true$ if the identifiers (instead of the
values) of all the variables in $\\{a\\}$ are included in $\\{b\\}$.

  * •

$\\{R_{a}\\}\Cup\\{R_{b}\\}$ returns the set of the ranges of
$\\{a\\}\sqcup\\{b\\}$. Because the identical elements between $\\{a\\}$ and
$\\{b\\}$ are subject to the ranges in both $\\{R_{a}\\}$ and $\\{R_{b}\\}$,
the resulting ranges for the identical elements are the intersections ($\cap$)
of the respective ranges in $\\{R_{a}\\}$ and $\\{R_{b}\\}$.

  * •

$a_{j}|\\{R_{b}\\}$ identifies the element in $\\{b\\}$ that is identical to
$a_{j}$ and returns its range in $\\{R_{b}\\}$.

  * •

$\mathcal{TR}(\\{R_{a}\\})$ transforms the set $\\{R_{a}\\}$ into the column
vector $R_{a}$, i.e., $\mathcal{TR}(\\{R_{a}\\})=R_{a}$.

###  3.2 The functional requirements

First, functional requirements have different meanings in different contexts.
In this paper, we abstract the function of a system in Eq. (1) as an input-
output transformation that describes the overall behavior of a system [46,
47].

$(x,u,c)\xrightarrow[]{f}y$ (1)

  * •

$f$ represents the transformation between $(x,u,c)$ and $y$.

  * •

$x$ represents the input variables that the system takes from the environment
or other systems.

  * •

$y$ represents the output variables that the system gives in response to the
inputs.

  * •

$u$ represents the uncertain design parameters that are out of the designer’s
control, such as the weather for an airplane.

  * •

$c$ represents the uncertain design parameters that are under the designer’s
control, such as the weight of an airplane.

Second, mathematically, a system must satisfy Eq. (2), where
$(R^{*}_{x},R^{*}_{u},R^{*}_{c},R^{*}_{y})$ constitute the functional
requirements of the system.

$\forall x\in R^{*}_{x},\forall u\in R^{*}_{u},\exists c\in
R^{*}_{c}:(x,u,c)\xrightarrow[]{f}y\in R^{*}_{y}$ (2)

  * •

$\forall R^{*}_{x}$ implies the system must be able to process all the values
from the input set.

  * •

$\forall R^{*}_{u}$ is because $u$ is out of the designer’s control. The
system must be able to process all the possible $u$.

  * •

$\exists R^{*}_{c}$ is because $c$ is under the designer’s control. The
designer only needs to find one $c$ within $R^{*}_{c}$ to satisfy the
functional requirements.

  * •

$R^{*}_{y}$ is the co-domain of $f$. All the possible output values must be
bounded within $R^{*}_{y}$.

However, not any random $(R^{*}_{x},R^{*}_{u},R^{*}_{c},R^{*}_{y})$ can be the
requirements of $f$. $(R^{*}_{x},R^{*}_{u},R^{*}_{c})$ and $R^{*}_{y}$ must
satisfy Eq. (3), which implies that the functional requirements of a system
are actually a constrained mapping between $(R^{*}_{x},R^{*}_{u},R^{*}_{c})$
and $R^{*}_{y}$.

$(R^{*}_{x},R^{*}_{c},R^{*}_{u})\longrightarrow R^{*}_{y}\text{ s.t.
Eq.\leavevmode\nobreak\ (\ref{eq:requirements1})}$ (3)

Similarly, the requirements of $f_{i}$ can be represented in Eq. (4), where
$f_{i}$ is the sub-function of $f$ ($i=1,2,...,n$).

$(R^{*}_{x(i)},R^{*}_{c(i)},R^{*}_{u(i)})\longrightarrow R^{*}_{y(i)}\text{
s.t. Eq.\leavevmode\nobreak\ (\ref{eq:requirements1})}$ (4)

Therefore, the functional requirements decomposition problem is to decompose
the top-level requirements in Eq. (3) into a set of sub-requirements in Eq.
(4) at the lower level, repeat the same process independently at each level of
abstraction and eventually lead to a system that satisfies the top-level
requirements in Eq. (3).

###  3.3 Refinement and composability

Refinement defines a relationship between two sets of functional requirements
(FR). $FR^{\prime}$ refining $FR$ implies the reduction of the uncertainties
from $FR$ to $FR^{\prime}$, which can always be reflected in the mapping
between the input and output variables. As shown in Fig. 1(a), $FR^{\prime}$
refines $FR$ if the relationship in Eq. (5) is satisfied, where the meanings
of $x_{i}|\\{R^{*}_{x^{\prime}}\\}$ and $y_{i}|\\{R^{*}_{y^{\prime}}\\}$ are
defined in Section 3.1.

$\begin{cases}\\{x\\}\sqsubseteq\\{x^{\prime}\\}\bigwedge\forall
x_{i}\in\\{x\\}:R^{*}_{x_{i}}\subseteq x_{i}|\\{R^{*}_{x^{\prime}}\\}\\\
\\{y\\}\sqsubseteq\\{y^{\prime}\\}\bigwedge\forall
y_{i}\in\\{y\\}:y_{i}|\\{R^{*}_{y^{\prime}}\\}\subseteq
R^{*}_{y_{i}}\end{cases}$ (5)

Intuitively, Eq. (5) means (1) $FR^{\prime}$ defines all the input/output
variables of $FR$, and (2) $FR^{\prime}$ allows the system to take a larger
range of $x$ but will generate a smaller range of $y$ than $FR$.

Figure 1: Graphical illustration of _refinement_. The green circles are the
ranges defined in $FR$, and the brown circles are the ranges defined in
$FR^{\prime}$.

Figure 2: Graphical illustration of _composability_. The green circles are the
ranges defined in $FR_{j}$, and the brown circles are the ranges defined in
$FR_{k}$.

Note that a system satisfying the functional requirements is a special case of
_refinement_. As implies by Eq. (2), the system can take all the values in
$R^{*}_{x}$ and provide the output values that are bounded within $R^{*}_{y}$,
which satisfies the relationship of _refinement_ in Eq. (5).

Composability defines the interface between functional requirements.
Therefore, only the input and output variables are concerned. Two sets of
functional requirements (denoted as $FR_{j}$ and $FR_{k}$ in Fig. 2(a)) are
composable if the relationship in Eq. (6) below is satisfied.

$\begin{cases}\\{z\\}=\\{y(j)\\}\sqcap\\{x(k)\\}\neq\emptyset\\\ \forall
z_{i}\in\\{z\\}:z_{i}|\\{R^{*}_{y(j)}\\}\subseteq
z_{i}|\\{R^{*}_{x(k)}\\}\end{cases}$ (6)

Intuitively, _composability_ means two things: (1) the output of $FR_{j}$ and
the input of $FR_{k}$ share at least one common variable (denoted as
$\\{z\\}$), and (2) $FR_{k}$ can take in more values of $z$ than $FR_{j}$ can
output (Fig. 2(b)).

Second, based on the definition above, we have the following properties.
Property 1 and 2 can be proved by directly applying the definitions of
_refinement_ and _composability_ , so we do not provide additional proof. The
proof of Property 3 can be found in the Appendix.

###### Property 1

If $FR^{\prime}$ refines $FR$, and $FR^{\prime\prime}$ refines $FR^{\prime}$,
then $FR^{\prime\prime}$ refines $FR$.

###### Property 2

If a set of functional requirements $\\{FR_{1},FR_{2},..,FR_{n}\\}$ are
composable, then their refinements
$\\{FR^{\prime}_{1},FR^{\prime}_{2},..,FR^{\prime}_{n}\\}$ are also
composable.

###### Property 3

Consider a set of composable functional requirements
$\\{FR_{1},FR_{2},...,FR_{n}\\}$. If $FR^{\prime}_{i}$ refines $FR_{i}$
(i=1,2,…,n), then the composite of
$\\{FR^{\prime}_{1},FR^{\prime}_{2},..,FR^{\prime}_{n}\\}$ refines the
composite of $\\{FR_{1},FR_{2},...,FR_{n}\\}$.

Because a system satisfying the functional requirements is a special case of
_refinement_ , Property 4, 5 and 6 can be derived similar to Property 1, 2 and
3. Therefore, we do not provide additional proof for them.

###### Property 4

If $FR^{\prime}$ refines $FR$, and a system $S$ satisfies $FR^{\prime}$, then
$S$ satisfies $FR$.

###### Property 5

If a set of functional requirements $\\{FR_{1},FR_{2},..,FR_{n}\\}$ are
composable, and a set of systems $\\{S_{1},S_{2},...,S_{n}\\}$ satisfy the
functional requirements respectively, then $\\{S_{1},S_{2},...,S_{n}\\}$ are
also composable.

###### Property 6

Consider a set of composable functional requirements
$\\{FR_{1},FR_{2},...,FR_{n}\\}$ and their composite $FR$. If $S_{i}$
satisfies $FR_{i}$ (i=1,2,…,n), then the composite of
$\\{S_{1},S_{2},..,S_{n}\\}$ satisfies the composite of
$\\{FR_{1},FR_{2},...,FR_{n}\\}$.

##  4 The hierarchical independent decomposition of functional requirements

Figure 3: A two-level example system to describe the hierarchical functional
requirements decomposition process.

We address Objective 2 introduced in Section 1. Without loss of generality, we
depict a simple system in Fig. 3 to describe the hierarchical functional
requirements decomposition process. First, given the top-level functional
requirements $FR$, the OEM decomposes $FR$ into $\\{FR_{1}^{1},FR_{2}^{1}\\}$,
and assign them to the Level-1 suppliers. The Level-1 suppliers then decompose
$FR_{1}^{1}$ and $FR_{2}^{1}$ independently into
$\\{FR_{1,1}^{2},FR_{1,2}^{2}\\}$ and $\\{FR_{2,1}^{2},FR_{2,2}^{2}\\}$, and
assign them to Level-2 suppliers. The Level-2 suppliers implement the
functional requirements independently into individual systems
$S_{1,1}^{2},S_{1,2}^{2},S_{2,1}^{2}$ and $S_{2,2}^{2}$ that satisfy the
respective functional requirements.

Now, we prove if at each level of abstraction, (1) the sub-requirements are
_composable_ , and (2) when composed together the sub-requirements _refine_
the higher-level functional requirements, then
$S_{1,1}^{2},S_{1,2}^{2},S_{2,1}^{2}$ and $S_{2,2}^{2}$ are composable and
together satisfy $FR$.

_Proof._ First, by definition, $\\{FR_{1}^{1},FR_{2}^{1}\\}$ are compsoable
and refine $FR$; $\\{FR_{1,1}^{2},FR_{1,2}^{2}\\}$ are composable and refine
$FR_{1}^{1}$; $\\{FR_{1,1}^{2},FR_{1,2}^{2}\\}$ are composable and refine
$FR_{2}^{1}$; $S_{1,1}^{2},S_{1,2}^{2},S_{2,1}^{2}$ and $S_{2,2}^{2}$ satisfy
$FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2}$ and $FR_{1,2}^{2}$ respectively.

Second, $\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$ are
composable according to Property 2. Then, the composite of
$\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$ refines the
composite of $\\{FR_{1}^{1},FR_{2}^{1}\\}$ according to Property 3. Because
$\\{FR_{1}^{1},FR_{2}^{1}\\}$ refine $FR$, then the composite of
$\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$ refine $FR$
according to Property 1.

Third, because $\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$ are
composable, and $S_{1,1}^{2},S_{1,2}^{2},S_{2,1}^{2}$ and $S_{2,2}^{2}$
satisfy $FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2}$ and $FR_{1,2}^{2}$
respectively, then $\\{S_{1,1}^{2},S_{1,2}^{2},S_{2,1}^{2},S_{2,2}^{2}\\}$ are
composable according to Property 5, and the composite of
$\\{S_{1,1}^{2},S_{1,2}^{2},S_{2,1}^{2},S_{2,2}^{2}\\}$ satisfies the
composite of $\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$
according to Property 6. We have established that the composite of
$\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$ refines $FR$.
Then, according to Property 4, the composite of
$\\{FR_{1,1}^{2},FR_{1,2}^{2},FR_{1,1}^{2},FR_{1,2}^{2}\\}$ satisfies $FR$. In
other words, the resulting system satisfies the top-level functional
requirements.

Therefore, for the design teams at different levels of abstraction can work in
parallel and obtain a system that satisfies the top-level functional
requirements, the sub-requirements at each level of abstraction must be
_composable_ , and _refine_ the higher-level functional requirements as a
whole.

##  5 Set-based approach to requirements decomposition at each level of
abstraction

In this section, we apply the set-based approach to functional requirements
decomposition (Objective 1) to achieve the sub-requirements required by
Objective 2.

###  5.1 An overall description

Given the higher level functional requirements:

  1. 1.

Define and analyze the functional architecture (Section 5.2).

  2. 2.

Explore the sub-functions for initial feasible spaces (Section 5.3).

  3. 3.

Narrow the initial feasible spaces for the feasible design space and
performance space (Section 5.4).

  4. 4.

Determine the sub-requirements that are _composable_ , and when composed
together, can _refine_ the higher-level functional requirements (Section 5.5).

After that, the team for each sub-function will improve the level of detail by
independently decomposing the sub-functions into the lower levels iteratively
until a final solution can be chosen.

###  5.2 Define and analyze the functional architecture

A functional architecture is comprised a set of connected sub-functions
($f_{1},f_{2},...,f_{n}$), and represents a set of potential design solutions
of the higher-level requirements. In SBD, there can be multiple alternative
functional architectures. However, we focus on one given functional
architecture in this paper because different functional architectures can be
analyzed in the same way.

To analyze a functional architecture, we extract the following two pieces of
information: (1) which variable/parameter is shared with which function/sub-
functions, and (2) the constitution of the design space and the performance
space. They will be used to narrow the feasible spaces later.

First, we aggregate $x(i),y(i),c(i)$ and $u(i)$ of the sub-functions into
$\\{x^{\prime}\\},\\{y^{\prime}\\},\\{c^{\prime}\\}$ and $\\{u^{\prime}\\}$
without considering the functional architecture. As defined in Section 3.1,
the $\sqcup$ operation merges the identical variables/parameters in multiple
sub-functions into one variable/parameter in the new set.

$\begin{cases}\\{x^{\prime}\\}=\\{x(1)\\}\sqcup\\{x(2)\\},...,\sqcup\\{x(n)\\}\\\
\\{y^{\prime}\\}=\\{y(1)\\}\sqcup\\{y(2)\\},...,\sqcup\\{y(n)\\}\\\
\\{c^{\prime}\\}=\\{c(1)\\}\sqcup\\{c(2)\\},...,\sqcup\\{c(n)\\}\\\
\\{u^{\prime}\\}=\\{u(1)\\}\sqcup\\{u(2)\\},...,\sqcup\\{u(n)\\}\end{cases}$
(7)

Second, for the system to implement the higher-level functional requirements,
all the elements defined in the higher-level function $f$ (i.e.,
$\\{x\\},\\{y\\},\\{c\\}$ and $\\{u\\}$) must also be defined in the
functional architecture, i.e., Eq. (8).

$\\{x\\}\sqsubseteq\\{x^{\prime}\\}\bigwedge\\{c\\}\sqsubseteq\\{c^{\prime}\\}\bigwedge\\{u\\}\sqsubseteq\\{u^{\prime}\\}\bigwedge\\{y\\}\sqsubseteq\\{y^{\prime}\\}$
(8)

Third, we examine where the variables and the parameters are defined. The
elements of $\\{c^{\prime}\\}$ and $\\{u^{\prime}\\}$ may or may not be
defined in $\\{c\\}$ and $\\{u\\}$. We define the elements of
$\\{c^{\prime}\\}$ and $\\{u^{\prime}\\}$ that are not defined in $\\{c\\}$
and $\\{u\\}$ as $\\{\widetilde{c}\\}$ and $\\{\widetilde{u}\\}$, and thus
have Eq. (9) below.

$\begin{cases}\\{c^{\prime}\\}=\\{\widetilde{c}\\}\sqcup\\{c\\}\\\
\\{u^{\prime}\\}=\\{\widetilde{u}\\}\sqcup\\{u\\}\end{cases}$ (9)

Figure 4: $\\{x^{\prime}\\}$ and $\\{y^{\prime}\\}$ can be divided into six
groups to reason about the design space and the performance space. The ranges
of each group will be calculated differently in Section 5.4.

For $\\{x^{\prime}\\}$ and $\\{y^{\prime}\\}$, we use Fig. 4 to reason about
where the elements can be possibly defined, where $\\{x^{\prime}\\}$ and
$\\{y^{\prime}\\}$ are the two outer ovals that include $\\{x\\}$ and
$\\{y\\}$. As shown in the middle of Fig. 4, there are four possible different
ways of where $\\{x^{\prime}\\}$ and $\\{y^{\prime}\\}$ can be defined.
$\\{x^{\prime}\\}$ and $\\{y^{\prime}\\}$ overlap because the sub-functions
are connected, i.e., one’s input is other’s output; $\\{x^{\prime}\\}$ and
$\\{y\\}$ overlap if there are feedback loops that feeds some elements of
$\\{y\\}$ into the sub-functions. $\\{x\\}$ does not overlap with
$\\{y^{\prime}\\}$ or $\\{y\\}$ because $\\{x\\}$ are the input variables of
the higher-level functional requirements, hence can only come from the
external environment rather than being controlled by the system itself. As a
result, we identify six different areas (the bottom of Fig. 4) depending on
the overlapping between $\\{x^{\prime}\\},\\{y^{\prime}\\},\\{x^{\prime}\\}$
and $\\{y\\}$.

The variables in Area 1, 2, 3 and 4 are therefore denoted as
$\\{y^{\prime(1)}\\},\\{y^{\prime(2)}\\},\\{y^{\prime(3)}\\}$ and
$\\{y^{\prime(4)}\\}$ in Eq. (10).

$\begin{cases}\\{y^{\prime(1)}\\}=\\{y^{\prime}\\}\sqcap\neg\\{y\\}\sqcap\neg\\{x^{\prime}\\}\\\
\\{y^{\prime(2)}\\}=\\{y^{\prime}\\}\sqcap\\{x^{\prime}\\}\sqcap\neg\\{y\\}\\\
\\{y^{\prime(3)}\\}=\\{y\\}\sqcap\\{x^{\prime}\\}\\\
\\{y^{\prime(4)}\\}=\\{y\\}\sqcap\neg\\{x^{\prime}\\}\end{cases}$ (10)

Area 5 is $\\{x\\}$. Area 6, denoted as $\\{\widetilde{x}\\}$, can then be
represented in Eq. (11).

$\\{\widetilde{x}\\}=\\{x^{\prime}\\}\sqcap\neg\\{y^{\prime}\\}\sqcap\neg\\{x\\}$
(11)

Therefore, we can classify all the elements of a functional architecture into
the exclusive groups below based on where the elements are defined.

  * •

$\\{x\\}$ is defined in $\\{x\\}$ and $\\{x^{\prime}\\}$;
$\\{\widetilde{x}\\}$ is only defined within $\\{x^{\prime}\\}$.

  * •

$\\{c\\}$ is defined in $\\{c\\}$ and $\\{c^{\prime}\\}$;
$\\{\widetilde{c}\\}$ is only defined within $\\{c^{\prime}\\}$.

  * •

$\\{u\\}$ is defined in $\\{u\\}$ and $\\{u^{\prime}\\}$;
$\\{\widetilde{u}\\}$ is only defined within $\\{u^{\prime}\\}$.

  * •

$\\{y^{\prime(1)}\\}$ is only defined in $\\{y^{\prime}\\}$;
$\\{y^{\prime(2)}\\}$ is defined in $\\{x^{\prime}\\}$ and $\\{y^{\prime}\\}$;
$\\{y^{\prime(3)}\\}$ is defined in $\\{x^{\prime}\\},\\{y\\}$ and
$\\{y^{\prime}\\}$; $\\{y^{\prime(4)}\\}$ is defined in $\\{y\\}$ and
$\\{y^{\prime}\\}$.

Finally, because the design space is the set of the independent
variables/parameters of a system and the performance space is the set of the
dependent variables [48, 49], the design space of a given functional
architecture are comprised of
$(\\{x\\},\\{c\\},\\{u\\},\\{\widetilde{x}\\},\\{\widetilde{c}\\},\\{\widetilde{u}\\})$
and the performance space are comprised of
$(\\{y^{\prime(1)}\\},\\{y^{\prime(2)}\\},\\{y^{\prime(3)}\\},\\{y^{\prime(4)}\\})$.

###  5.3 Explore the initial feasible spaces

The initial feasible spaces of each sub-function is characterized in Eq. (12)
after exploring the feasible implementations. The specific initial spaces can
only be determined case by case.

$\displaystyle\forall x(i)\in R_{x(i)}$ $\displaystyle,\forall u(i)\in
R_{u(i)},\exists c(i)\in R_{c(i)}:$ (12) $\displaystyle
f_{i}(x(i),u(i),c(i))\in R_{y(i)}$

Note that Eq. (12) is different from Eq. (4). The ranges (without $*$) in Eq.
(12) represent the feasible spaces of the sub-functions while the ranges in
Eq. (4) represent the desired spaces (i.e., requirements).

###  5.4 Narrow the feasible spaces

In this section, we derive the feasible design space and performance space of
the system by narrowing from the initial feasible spaces.

First, we aggregate the ranges of the sub-functions
$\\{R_{x(i)}\\},\\{R_{c(i)}\\},\\{R_{u(i)}\\}$ and $\\{R_{y(i)}\\}$
($i=1,2,...,n$) into
$\\{R_{x^{\prime}}\\},\\{R_{c^{\prime}}\\},\\{R_{u^{\prime}}\\}$ and
$\\{R_{y^{\prime}}\\}$, where
$\\{x^{\prime}\\},\\{u^{\prime}\\},\\{c^{\prime}\\}$ and $\\{y^{\prime}\\}$
are defined in Eq. (7). Refer to Section 3.1 for the definition of $\Cup$.

$\begin{cases}\\{R_{x^{\prime}}\\}=\\{R_{x(1)}\\}\Cup\\{R_{x(2)}\\},...,\Cup\\{R_{x(n)}\\}\\\
\\{R_{y^{\prime}}\\}=\\{R_{y(1)}\\}\Cup\\{R_{y(2)}\\},...,\Cup\\{R_{y(n)}\\}\\\
\\{R_{c^{\prime}}\\}=\\{R_{c(1)}\\}\Cup\\{R_{c(2)}\\},...,\Cup\\{R_{c(n)}\\}\\\
\\{R_{u^{\prime}}\\}=\\{R_{u(1)}\\}\Cup\\{R_{u(2)}\\},...,\Cup\\{R_{u(n)}\\}\end{cases}$
(13)

Second, we calculate the ranges of
$\\{\widetilde{x}\\},\\{x\\},\\{\widetilde{c}\\},\\{c\\},\\{\widetilde{u}\\},\\{u\\},\\{y^{\prime(1)}\\},\\{y^{\prime(2)}\\},\\{y^{\prime(3)}\\}$
and $\\{y^{\prime(4)}\\}$ based on where they are defined. For example, we
have established in Section 5.2 that the elements in $\\{x\\}$ are defined in
both $\\{x\\}$ and $\\{x^{\prime}\\}$. Therefore, the range of each element in
$\\{x\\}$ will be the intersection of the corresponding ranges in $R^{*}_{x}$
and $\\{R_{x^{\prime}}\\}$ i.e., the first item in Eq. (14). Refer to Section
3.1 for the definition of operation of $x_{i}|\\{R_{x^{\prime}}\\}$. The
ranges of
$\\{c\\},\\{u\\},\\{\widetilde{x}\\},\\{\widetilde{c}\\},\\{\widetilde{u}\\},\\{y^{\prime(1)}\\},$
$\\{y^{\prime(2)}\\},\\{y^{\prime(3)}\\}$ and $\\{y^{\prime(4)}\\}$ can be
calculated in the same way in the rest of Eq. (14).

$\begin{cases}\\{R_{x}\\}=\\{R_{x_{i}}|\forall
x_{i}\in\\{x\\}:R_{x_{i}}=R^{*}_{x_{i}}\cap x_{i}|\\{R_{x^{\prime}}\\}\\}\\\
\\{R_{u}\\}=\\{R_{u_{i}}|\forall u_{i}\in\\{u\\}:R_{u_{i}}=R^{*}_{u_{i}}\cap
u_{i}|\\{R_{u^{\prime}}\\}\\}\\\ \\{R_{c}\\}=\\{R_{c_{i}}|\forall
c_{i}\in\\{c\\}:R_{c_{i}}=R^{*}_{c_{i}}\cap c_{i}|\\{R_{c^{\prime}}\\}\\}\\\
\\{R_{\widetilde{x}}\\}=\\{R_{x_{i}}|\forall
x_{i}\in\\{\widetilde{x}\\}:R_{x_{i}}=x_{i}|\\{R_{x^{\prime}}\\}\\}\\\
\\{R_{\widetilde{c}}\\}=\\{R_{c_{i}}|\forall
c_{i}\in\\{\widetilde{c}\\}:R_{c_{i}}=c_{i}|\\{R_{c^{\prime}}\\}\\}\\\
\\{R_{\widetilde{u}}\\}=\\{R_{u_{i}}|\forall
u_{i}\in\\{\widetilde{u}\\}:R_{u_{i}}=u_{i}|\\{R_{u^{\prime}}\\}\\}\\\
\\{R_{y^{\prime(1)}}\\}=\\{R_{y_{i}}|\forall
y_{i}\in\\{y^{\prime(1)}\\}:R_{y_{i}}=y_{i}|\\{R_{y^{\prime}}\\}\\}\\\
\begin{aligned} \\{R_{y^{\prime(2)}}\\}&=\\{R_{y_{i}}|\forall
y_{i}\in\\{y^{\prime(2)}\\}:\\\ R_{y_{i}}&=y_{i}|\\{R_{x^{\prime}}\\}\cap
y_{i}|\\{R_{y^{\prime}}\\}\\}\end{aligned}\\\ \begin{aligned}
\\{R_{y^{\prime(3)}}\\}&=\\{R_{y_{i}}|\forall y_{i}\in\\{y^{\prime(3)}\\}:\\\
R_{y_{i}}&=y_{i}|\\{R_{x^{\prime}}\\}\cap y_{i}|\\{R_{y^{\prime}}\\}\cap
y_{i}|\\{R^{*}_{y}\\}\\}\end{aligned}\\\ \begin{aligned}
\\{R_{y^{\prime(4)}}\\}&=\\{R_{y_{i}}|\forall y_{i}\in\\{y^{\prime(4)}\\}:\\\
R_{y_{i}}&=y_{i}|\\{R_{y^{\prime}}\\}\cap
y_{i}|\\{R^{*}_{y}\\}\\}\end{aligned}\end{cases}$ (14)

In addition, each range in
$\\{R_{x}\\},\\{R_{u}\\},\\{R_{c}\\},\\{R_{\widetilde{x}}\\}$,
$\\{R_{\widetilde{c}}\\},\\{R_{\widetilde{u}}\\},\\{R_{y^{\prime(1)}}\\},\\{R_{y^{\prime(2)}}\\},\\{R_{y^{\prime(3)}}\\}$
and $\\{R_{y^{\prime(4)}}\\}$ cannot be $\emptyset$ because $\emptyset$
implies internal conflicts between the initial ranges, unless the
corresponding group of elements are not defined. Furthermore, for
$\\{R_{x}\\}$ and $\\{R_{u}\\}$, the conditions are stricter. Recall $\forall$
is associated with $\\{R^{*}_{x}\\}$ and $\\{R^{*}_{u}\\}$ in Eq. (2). The
system must operate under all the values defined in $\\{R^{*}_{x}\\}$ and
$\\{R^{*}_{u}\\}$. For this reason, the ranges of $\\{x\\}$ and $\\{u\\}$
defined in $\\{R_{x^{\prime}}\\}$ and $\\{R_{u^{\prime}}\\}$ must include
$\\{R^{*}_{x}\\}$ and $\\{R^{*}_{u}\\}$ respective. As a result, we can update
$\\{R_{x}\\}$ and $\\{R_{u}\\}$ in Eq. (15) based on Eq. (14).

$\\{R_{x}\\}=\\{R^{*}_{x}\\}\bigwedge\\{R_{u}\\}=\\{R^{*}_{u}\\}$ (15)

Now, let
$R^{1}_{D}=\\{R_{x}\\}\Cup\\{R_{\widetilde{x}}\\}\Cup\\{R_{c}\\}\Cup\\{R_{\widetilde{c}}\\}\Cup\\{R_{u}\\}\Cup\\{R_{\widetilde{u}}\\}$
and
$R^{1}_{P}=\\{R_{y^{\prime(1)}}\\}\Cup\\{R_{y^{\prime(2)}}\\}\Cup\\{R_{y^{\prime(3)}}\\}\Cup\\{R_{y^{\prime(4)}}\\}$.
The feasible design space and performance space can be easily represented in
Eq. (16). Refer to Section 3.1 for the definition of operation
$\mathcal{TR}()$.

$\displaystyle FDS^{1}=\mathcal{TR}(R^{1}_{D})\bigwedge
FPS^{1}=\mathcal{TR}(R^{1}_{P})$ (16)

Third, $FDS^{1}$ and $FPS^{1}$ are coupled through the sub-functions, and thus
can be further narrowed by exploiting the coupling. Let
$f^{\prime}=f_{1}\wedge f_{2}...\wedge f_{n}$. $f^{\prime}$ can be
characterized in Eq. (17).

$(x,\widetilde{x},c,\widetilde{c},u,\widetilde{u})\xrightarrow[]{f^{\prime}}y^{\prime}$
(17)

where $(x,\widetilde{x},c,\widetilde{c},u,\widetilde{u})\in FDS^{1}$ and
$y^{\prime}\in FPS^{1}$.

Based on Eq. (17), we can narrow $R_{c}$ and $R_{\widetilde{c}}$ to
$R^{\downarrow}_{c}$ and $R^{\downarrow}_{\widetilde{c}}$ so that Eq. (18) is
satisfied, which is in fact a Quantified Constraint Satisfaction Problem [50].

$\displaystyle\text{For }\forall x\in R_{x}$
$\displaystyle,\forall\widetilde{x}\in R_{\widetilde{x}},\forall u\in
R_{u},\forall\widetilde{u}\in R_{\widetilde{u}},\forall c\in
R^{\downarrow}_{c},$ (18) $\displaystyle\text{and }\forall\widetilde{c}\in
R^{\downarrow}_{\widetilde{c}}$ $\displaystyle:$
$\displaystyle(x,\widetilde{x},c,\widetilde{c},u,\widetilde{u})\xrightarrow[]{f^{\prime}}y^{\prime}\in
FPS^{1}$

Let
$R^{2}_{D}=\\{R_{x}\\}\Cup\\{R_{\widetilde{x}}\\}\Cup\\{R_{u}\\}\Cup\\{R_{\widetilde{u}}\\}\Cup\\{R^{\downarrow}_{c}\\}\Cup\\{R^{\downarrow}_{\widetilde{c}}\\}$,
then the new feasible design space can be represented as
$FDS^{2}=\mathcal{TR}(R^{2}_{D})$.

The reason that only $R_{c}$ and $R_{\widetilde{c}}$ are narrowed is because
other ranges in Eq. (17) are all associated with $\forall$, meaning the system
must operate under all values in the ranges. Hence ranges associated with
$\forall$ cannot be narrowed. Furthermore, the reason that the ranges of the
controllable parameters $R^{\downarrow}_{c}$ and
$R^{\downarrow}_{\widetilde{c}}$ in Eq. (18) are associated with $\forall$ is
that $R^{\downarrow}_{c}$ and $R^{\downarrow}_{\widetilde{c}}$ will be further
narrowed independently by subsystems at the lower levels of abstraction until
single values can be determined for the elements in $\\{c\\}$ and
$\\{\widetilde{c}\\}$. “$\forall$” makes sure whatever values chosen for $c$
and $\widetilde{c}$ at the lower levels, Eq. (18) will always be satisfied.

After Eq. (18), because the feasible design space is narrowed from $FDS^{1}$
to $FDS^{2}$, $FPS^{1}$ can be narrowed into a new feasible performance space
$FPS^{2}$ based on the new $FDS^{2}$, such that Eq. (19) holds.

$\displaystyle\forall(x,\widetilde{x},c,$
$\displaystyle\widetilde{c},u,\widetilde{u})^{\top}\in FDS^{2}:$ (19)
$\displaystyle(x,\widetilde{x},c,\widetilde{c},u,\widetilde{u})\xrightarrow[]{f^{\prime}}y^{\prime}\in
FPS^{2}$

Reachability analysis [51] can be applied to calculate $FPS^{2}$ as an over-
approximation so that all the points in $FDS^{2}$ will be mapped within the
$FPS^{2}$. Let the resulting reachable sets for $y^{\prime(h)}$ be
$\\{R_{y^{\prime(h)}}^{\downarrow}\\}$ and
$R_{P}^{2}=\\{R_{y^{\prime(1)}}^{\downarrow}\\}\Cup\\{R_{y^{\prime(2)}}^{\downarrow}\\}\Cup\\{R_{y^{\prime(3)}}^{\downarrow}\\}\Cup\\{R_{y^{\prime(4)}}^{\downarrow}\\}$.
The new feasible performance space can be represented as
$FPS^{2}=\mathcal{TR}(R^{2}_{P})$.

Finally, the feasible design space and performance space of the system are
narrowed to $FDS^{2}$ and $FPS^{2}$.

###  5.5 Determine the sub-requirements

#### Uncertainty expansion.

Ideally, the ranges in the sub-requirements should be as narrow as possible to
reduce the uncertainty to the most extent. The ranges in $FDS^{2}$ and
$FPS^{2}$ are the narrowest ranges that can be calculated at the current level
of abstraction. However, it is always possible that the initial
characterizations of the uncertainties (i.e., $R_{u^{\prime}}$ and
$R_{c^{\prime}}$) are under-estimated, which will inevitably lead to an
expansion of $FPS^{2}$ at a later time.

Naturally, to accommodate the possible unexpected expansion, the desired
ranges of $y^{\prime}$ in the sub-requirements must also expand from
$FPS^{2}$. We denote the desired ranges of $y^{\prime}$ in the sub-
requirements as $FPS^{*}$. As shown in Fig. 5, to maximize the capacity of the
sub-requirements to accommodate the possible expansion, $FPS^{*}$ must be
expanded as close to $FPS^{1}$ as possible. Note that $FPS^{*}$ cannot expand
beyond $FPS^{1}$ to avoid infeasibility.

Figure 5: The boundaries of $FPS^{*}$.

However, $y^{\prime}$ may also be the input variables of some sub-functions.
Expanding the ranges of $y^{\prime}$ will inevitably lead to the expansion of
the input ranges of some sub-functions, which will in turn makes the system
more difficult or expensive to implement. Therefore, there is an inherent
tension between accommodating excessive uncertainty and the level of
difficulty in implementing the system. This tension dictates that the boundary
of $FPS^{*}$ in Fig. 5 cannot be too close either to $FPS^{1}$ or to
$FPS^{2}$.

#### Trade-off study.

A trade-off needs to be made to decide the distance of $FPS^{*}$ from
$FPS^{1}$ and $FPS^{2}$. This problem highly resembles the barrier function in
optimization. Therefore, we construct an optimization problem based on barrier
function to conduct the trade-off study.

First, we construct the boundaries of the ranges in $FPS^{*}$. For $y_{j}(i)$
(i.e., the $j$th variable of $y(i)$), let the corresponding range defined in
$FPS^{*}$ be $R^{*}_{y_{j}(i)}=[y_{j}^{l*}(i),y_{j}^{u*}(i)]$. As explained
before, the ranges in $FPS^{*}$ must be bounded by the ranges in $FPS^{1}$ and
$FPS^{2}$. Therefore, the range of $y_{j}(i)$ in $FPS^{*}$ is subject to Eq.
(20).

$\begin{cases}y_{j}^{u2}(i)\leq y_{j}^{u*}(i)\leq y_{j}^{u1}(i)\\\
y_{j}^{l1}(i)\leq y_{j}^{l*}(i)\leq y_{j}^{l2}(i)\end{cases}$ (20)

  * •

$y_{j}^{u1}(i)$ and $y_{j}^{l1}(i)$ are the upper and lower bound of the range
of $y_{j}(i)$ in $FPS^{1}$.

  * •

$y_{j}^{u2}(i)$ and $y_{j}^{l2}(i)$ are the upper and lower bound of the range
of $y_{j}(i)$ in $FPS^{2}$.

Second, we explain the barrier functions in Eq. (21). $y_{j}(i)$ is the output
of $f_{i}$. If $R^{*}_{y_{j}(i)}$ is too close to $FPS^{2}$, then $h_{j}(i)$
goes to infinity. If $y_{j}(i)$ is the input of $f_{k}$ and $R^{*}_{y_{j}(i)}$
is too close to $FPS^{1}$, then $h_{j}^{k}(i)$ goes to infinity; otherwise,
$h_{j}^{k}(i)=0$.

$\begin{cases}\begin{aligned}
h_{j}(i)=-a_{j}(i)(&\ln|y_{j}^{u*}(i)-y_{j}^{u2}(i)|\\\
+&\ln|y_{j}^{l*}(i)-y_{j}^{l2}(i)|)\end{aligned}\\\ \begin{aligned}
h_{j}^{k}(i)=-a_{j}^{k}(i)(&\ln|y_{j}^{u*}(i)-y_{j}^{u1}(i)|\\\
+&\ln|y_{j}^{l*}(i)-y_{j}^{l1}(i)|)\end{aligned}\\\ \end{cases}$ (21)

The coefficients $a_{j}(i)$ and $a_{j}^{k}(i)$ represent the designers’
preference of the ability to tolerate uncertainty expansion of $f_{i}$ and the
level of difficulty to implement $f_{k}$. Specific values of $a_{j}(i)$ and
$a_{j}^{k}(i)$ can only be determined case by case.

$\text{min}\left(\sum_{i=1}^{n}\sum_{j=1}^{S(i)}h_{j}(i)+\sum_{i=1}^{n}\sum_{j=1}^{S(i)}\sum_{k=1}^{n}h_{j}^{k}(i)\right)$
(22)

Third, the objective function is Eq. (22) where $S(i)$ is the number of the
variables in $y(i)$. The optimization problem is to decide $y_{j}^{u*}(i)$ and
$y_{j}^{l*}(i)$ to minimize Eq. (22), subject to the constraints in Eq. (4)
and Eq. (20). As a result, $FPS^{*}$ can be assembled using the resulting
$y_{j}^{u*}(i)$ and $y_{j}^{l*}(i)$ where $i=1,2,...n$.

#### The sub-requirements.

In general, the sub-requirements must satisfy the following three conditions:

  1. 1.

Must be within the initial feasible spaces of the sub-functions.

  2. 2.

Must include all the possible values that the elements of the system will
encounter.

  3. 3.

Must be composable and refine the higher-level functional requirements as a
whole.

We intend to assign the ranges in $FDS^{2}$ and $FPS^{*}$ directly to the sub-
functions as the sub-requirements. Now, we explain the ranges satisfy all the
three conditions above.

First, $FDS^{1}$ and $FPS^{1}$ are both narrowed from the initial feasible
spaces of the sub-functions (see Eq. (14)), and $FDS^{2}$ and $FPS^{*}$ are
narrowed from $FDS^{1}$ and $FPS^{1}$. Therefore, ranges in $FDS^{2}$ and
$FPS^{*}$ satisfy the first condition.

Second, $FDS^{2}$ does not narrow the ranges of
$\\{x\\},\\{\widetilde{x}\\},\\{u\\}$ and $\\{\widetilde{u}\\}$, elements that
are associated with $\forall$, thus all the values of the independent
variables that the system must accept are included within $FDS^{2}$. Moreover,
we have established in Eq. (19) that all the possible values of $y^{\prime}$
are included within $FPS^{2}$. Because $FPS^{*}$ include $FPS^{2}$, thus all
the possible values of $y^{\prime}$ are also included within $FPS^{*}$.
Therefore, ranges in $FDS^{2}$ and $FPS^{*}$ satisfy the second condition.

Third, the ranges of all the elements are only defined once in $FDS^{2}$ and
$FPS^{*}$. If they are assigned to the sub-functions, the identical element
will only be assigned the same range. Therefore, the sub-requirements will be
composable. In addition, the ranges of $\\{x\\}$ in $FDS^{2}$ are the same as
the ranges in the higher-level functional requirements (see Eq. (15)) and the
ranges of $y$ are narrowed from the ranges in the higher-level functional
requirements (see Eq. (14)). Therefore, the sub-requirements as a whole will
also refine the higher-level functional requirement, and the third condition
is satisfied.

In conclusion, $R^{*}_{x(i)},R^{*}_{c(i)}$ and $R^{*}_{u(i)}$ can be directly
obtained from $FDS^{2}$, and $R^{*}_{y(i)}$ can be directly obtained from
$FPS^{*}$. Together, $R^{*}_{x(i)},R^{*}_{c(i)},R^{*}_{u(i)}$ and
$R^{*}_{y(i)}$ are the sub-requirements of $f_{i}$ ($i=1,2,...,n$) decomposed
from the $R^{*}_{x},R^{*}_{c},R^{*}_{u}$ and $R^{*}_{y}$ of $f$.

##  6 Case study

We design a cruise control system to demonstrate the feasibility of the four-
step formal process proposed in Section 5.

The top-level functional requirements are given as below: for any initial
speed $v_{0}\in[22.0,30.0]$ $\mathrm{m}\text{/}\mathrm{s}$ and reference speed
between $v_{r}\in[34,36]$ $\mathrm{m}\text{/}\mathrm{s}$, the real speed shall
be bounded by $v(t)\in[20,40]$ at all time (we simulated $100$ seconds in this
paper) and converge to $v(t)\in[33,37]$ $\mathrm{m}\text{/}\mathrm{s}$ after
$20$ seconds.

$(v_{0},v_{r})\xrightarrow[]{f}v(t)$

where $R_{x}^{*}$ is
$(v_{0},v_{r})^{\top}\in([23.0,30.0],[34,36])^{\top}$\mathrm{m}\text{/}\mathrm{s}$$
and $R^{*}_{y}$ is
$\begin{cases}v(t)\in[20,40]$\mathrm{m}\text{/}\mathrm{s}$\text{ for
}t\in[0,100]s\\\ v(t)\in[33,37]$\mathrm{m}\text{/}\mathrm{s}$\text{ for
}t\in[20,100]s\end{cases}$

#### Step 1: Define and analyze the functional architecture.

We adopt the functional architecture of a cruise control design from Aström
and Murray [52] (Fig. 6) with each sub-function defined as below.
$\begin{cases}f_{1}:v(t)=\int_{0}^{t}\dot{v}dt+v_{0}\\\
f_{2}:\dot{v}(t)=(F(t)-Fr-Fa(t))/m\\\ f_{3}:Fr=mgC_{r}\\\
f_{4}:F(t)=\alpha*u(t)T(t)\\\ f_{5}:Fa(t)=\frac{1}{2}\rho C_{d}Av(t)^{2}\\\
f_{6}:\omega(t)=\alpha*v(t)\\\
f_{7}:T(t)=T_{m}(1-\beta(\omega(t)/\omega_{m}-1)^{2})\\\
f_{8}:u(t)=p(v_{r}-v(t))+i\int_{0}^{t}(v_{r}-v(t))dt\end{cases}$

Figure 6: The functional architecture for the top-level functional
requirements.

A detailed explanation of each sub-function can be found in the Supplemental
Material. For this step, the input/output variables can be found in Fig. 6;
the uncontrollable uncertain parameter is the weight of the car ($m$); the
controllable uncertain parameter is the maximum engine speed ($\omega_{m}$).
Other parameters are constant. Note that the constant parameters can also be
defined as uncertain parameters and addressed in the same way as $m$ and
$\omega_{m}$. However, we intentionally limit the number of the uncertain
parameters to simplify the presentation.

Next, we classify the variables and the parameters based on where they are
defined, yielding the following exclusive groups. For example, according to
the characterizations in Section 5.2, $\\{y^{\prime(3)}\\}$ are the output
variables that are defined in the output of the top-level function, the input
of the sub-functions and the output of the sub-functions. In this example, the
only variable we can find is $v(t)$.

  * •

$\\{x\\}=\\{v_{r},v_{0}\\}$.

  * •

$\\{\widetilde{c}\\}=\\{\omega_{m}\\}$.

  * •

$\\{\widetilde{u}\\}=\\{m\\}$.

  * •

$\\{y^{\prime(2)}\\}=\\{\dot{v}(t),Fr(t),F(t),Fa(t),T(t),u(t),\omega(t)\\}$.

  * •

$\\{y^{\prime(3)}\\}=v(t)$.

As a result, the design space of the cruise control system is
$\\{v_{r},v_{0},m,\omega_{m}\\}$ and the performance space is
$\\{\dot{v}(t),Fr(t),F(t),Fa(t),T(t),u(t),\omega(t),v(t)\\}$.

#### Step 2: Explore the initial feasible spaces.

The initial feasible spaces are provided by the design teamsm responsible for
the sub-functions. The specific ranges can be found in the Supplemental
Material.

#### Step 3: Narrow the feasible spaces.

First, we compute $FDS^{1}$ and $FDS^{1}$ by taking intersections of the
ranges of the elements defined in multiple places. For example, $m$ is defined
in $f_{2}$ and $f_{3}$, hence $R_{m}$ is the intersection of the corresponding
ranges defined in $f_{2}$ and $f_{3}$. $v_{0}$ is defined in both top-level
function and $f_{1}$, hence $R_{v_{0}}$ is the intersection of the
corresponding ranges defined in $f_{1}$ and top-level function.

As a result, the ranges in $FDS^{1}$ can be computed as below:

$\begin{aligned}
R_{v_{r}}&=[23.0,30.0]$\mathrm{m}\text{/}\mathrm{s}$,R_{v_{0}}=[34,36]$\mathrm{m}\text{/}\mathrm{s}$\\\
R_{\omega_{m}}&=[350,480]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$,R_{m}=[990,1100]$\mathrm{k}\mathrm{g}$\end{aligned}$

The ranges in $FPS^{1}$ can be computed as below:

$\begin{aligned}
R_{\dot{v}(t)}&=[-1.5,3]$\mathrm{m}\mathrm{/}\mathrm{s}^{2}$,\;R_{Fr(t)}=[70,120]$\mathrm{N}$,\\\
R_{F(t)}&=[-250,3500]$\mathrm{N}$,R_{Fa(t)}=[0,1000]$\mathrm{N}$,\\\
R_{T(t)}&=[0,250]$\mathrm{N}\mathrm{m}$,\qquad R_{u(t)}=[-0.5,2],\\\
R_{\omega(t)}&=[0,450]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$,\quad\;R_{v(t)}=[20,40]$\mathrm{m}\text{/}\mathrm{s}$\end{aligned}$

Second, let $f^{\prime}=f_{1}\wedge f_{2}...\wedge f_{8}$. $FDS^{1}$ and
$FPS^{1}$ can be further narrowed into $FDS^{2}$ and $FPS^{2}$ using
$f^{\prime}$. To achieve $FDS^{2}$, the range of the controllable parameter
$\omega_{m}$ must be narrowed into $R_{\omega_{m}}^{\downarrow}$ based on Eq.
(18) such that,

For $\forall v_{r}\in R_{{v}_{r}},\forall v_{0}\in R_{{v}_{0}},\forall m\in
R_{m},\forall\omega_{m}\in R_{\omega_{m}}^{\downarrow}$:
$(v_{r},v_{0},\omega_{m},m)\xrightarrow[]{f^{\prime}}y^{\prime}\in FPS^{1}$

where $y^{\prime}=(v(t),\dot{v}(t),v(t),Fr(t),F(t),Fa(t),T(t),u(t),$
$\omega(t))^{\top}$. In this example, we apply reachability analysis to help
find $R_{\omega_{m}}^{\downarrow}$. We estimate an over-approximation of
$R_{\omega_{m}}^{\downarrow}$, feed it into a reachability solver (i.e., CORA
[53] in this example), and adjust the bounds of the over-approximation until
the reachable sets of all the output variables are bounded with $FPS^{1}$. As
a result, we obtain the ranges in $FDS^{2}$ as below,

$\begin{aligned}
R_{v_{r}}&=[23.0,30.0]$\mathrm{m}\text{/}\mathrm{s}$,R_{v_{0}}=[34,36]$\mathrm{m}\text{/}\mathrm{s}$\\\
R_{\omega_{m}}^{\downarrow}&=[365,450]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$,R_{m}=[990,1100]$\mathrm{k}\mathrm{g}$\end{aligned}$

After that, $FPS^{1}$ can be narrowed into $FPS^{2}$ by calculating the
reachable sets according to Eq. (19). We choose CORA as the tool because it
can compute the over-approximation of the feasible performance space. The
result shows the range of $v(t)$ converges gradually from $R_{v_{0}}$ to
$R_{v_{r}}$, meaning the reference speed is achieved by the cruise control
system (see the Supplemental Material for the plots). Eventually, we obtain
the ranges of $FPS^{2}$:

$\begin{aligned}
R_{\dot{v}(t)}^{\downarrow}&=[-0.63,2.89]$\mathrm{m}\mathrm{/}\mathrm{s}^{2}$,\;R_{Fr(t)}^{\downarrow}=[88.20,107.80]$\mathrm{N}$,\\\
R_{F(t)}^{\downarrow}&=[-9.33,2997.78]$\mathrm{N}$,R_{Fa(t)}^{\downarrow}=[240.88,655.25]$\mathrm{N}$,\\\
R_{T(t)}^{\downarrow}&=[179.94,200.00]$\mathrm{N}\mathrm{m}$,\,R_{u(t)}^{\downarrow}=[0,1.51],\\\
R_{\omega(t)}^{\downarrow}&=[219.66,362.30]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$,\\\
R_{v(t)}^{\downarrow}&=[21.97,36.23]$\mathrm{m}\text{/}\mathrm{s}$\text{ for
}[0,100]s\\\
R_{v(t)}^{\downarrow}&=[33.65,36.19]$\mathrm{m}\text{/}\mathrm{s}$\text{ for
}[20,100]s\\\ \end{aligned}$

All the ranges in $FPS^{2}$ are subsets of their counterparts in $FPS^{1}$. In
other words, $FPS^{2}$ is successfully narrowed from $FPS^{1}$.

#### Step 4: Determine the sub-requirements.

We compute $R^{*}_{y(i)}=[y^{l*}(i),y^{u*}(i)]$ for $y(i)$ ($i=1,2,...,8$) by
formulating the optimization problem in Eq. (22) subject to the constraints in
Eq. (4) and Eq. (20). Note that there is no subscript $j$ associated with the
output variable $y(i)$, because each $f_{i}$ in this example only has one
variable at its output side.

First, the constraints described in Eq. (20) can be directly obtained from
$FDS^{1},FPS^{1},FDS^{2}$ and $FPS^{2}$ calculated in the previous step.

Second, Eq. (4) needs to be satisfied for each individual sub-function, which
yields the constraints in Eq. (23). Note that $f_{1}$ and $f_{8}$ are not
included in the constraints. $f_{1}$ and $f_{8}$ alone are not enough to
decide the ranges of the output variables because the operation $\int$ makes
the ranges of the output variables correlated with the time $t$. Their ranges
can only be determined after the rest of the system is determined. In this
example, $f_{1}$ and $f_{8}$ belong to the PID controller. These modules are
designed after other parts of the car (e.g., engine and tyres) are defined,
and hence are not part of the constraints in Eq. (23).

$\begin{cases}y^{l*}(6)\leq f_{6}(y^{l*}(1))\\\ y^{u*}(6)\geq
f_{6}(y^{u*}(1))\\\ y^{l*}(7)\leq f_{7}(y^{l*}(6),\overline{\omega_{m}})\\\
y^{u*}(7)\geq f_{7}(y^{u*}(6),\underline{\omega_{m}})\\\ y^{l*}(5)\leq
f_{5}(y^{l*}(1))\\\ y^{u*}(5)\geq f_{5}(y^{u*}(1))\\\ y^{l*}(4)\leq
f_{4}(y^{l*}(7),y^{l*}(8))\\\ y^{u*}(4)\geq f_{4}(y^{u*}(7),y^{u*}(8))\\\
y^{l*}(2)\leq f_{2}(y^{l*}(4),y^{u*}(3),y^{u*}(5),\overline{m})\\\
y^{u*}(2)\geq f_{2}(y^{u*}(4),y^{l*}(3),y^{l*}(5),\underline{m})\end{cases}$
(23)

Third, based on Eq. (21) and Eq. (22), we define the objective function below:

$\text{min}(\sum_{i=1}^{8}h(i)+\sum_{i=1}^{8}\sum_{k=1}^{8}h^{k}(i))$ (24)

where the coefficients are defined as
$a(1)=0.9,a(2)=0.6,a(3)=0.5,a(4)=0.3,a(5)=0.4,a(6)=0.5,a(7)=0.1,a(8)=0.9,a^{5}(1)=0.5,a^{6}(1)=0.1,a^{8}(1)=0.8,a^{1}(2)=0.6,a^{2}(3)=0.4,a^{2}(4)=0.8,a^{2}(5)=0.7,a^{7}(6)=0.6,a^{4}(7)=0.9,a^{4}(8)=0.9$.

Finally, the optimization problem is to decide $y^{u*}(i)$ and $y^{l*}(i)$
($i=1,2...,8$) by minimizing Eq. (24). As a result, $y^{u*}(i)$ and
$y^{l*}(i)$ ($i=1,2...8$) are calculated. Together with $FDS^{2}$ computed in
the previous step, the ranges of each sub-function can be summarized in
Table.1. Accordingly, the sub-requirements of $f_{i}$ are the mapping between
$(R^{*}_{x(i)},R^{*}_{c(i)},R^{*}_{u(i)})$ and $R^{*}_{y(i)}$ in Table.1.
Eventually, the four-step process can be repeated to further decompose the
sub-requirements independently to the lower levels until a final solution is
selected. The resulting system as a whole is guaranteed to satisfy the top-
level functional requirements.

Table 1: The requirements of the sub-functions.

$f$ | $R_{x(i)}^{*},R_{c(i)}^{*},R_{u(i)}^{*}$ | $R_{y(i)}^{*}$
---|---|---
$f_{1}$ |  $v_{0}\in[34,36]$\mathrm{m}\text{/}\mathrm{s}$$ $\dot{v}(t)\in[-1.1,3]$\mathrm{m}\mathrm{/}\mathrm{s}^{2}$$ | $v(t)\in[21.8,38.4]$\mathrm{m}\text{/}\mathrm{s}$$
$f_{2}$ |  $Fr(t)\in[88.2,107.8]$\mathrm{N}$$ $F(t)\in[-159.1,3024.0]$\mathrm{N}$$ $Fa(t)\in[237.6,827.6]$\mathrm{N}$$ $m\in[990,1100]$\mathrm{k}\mathrm{g}$$ | $\dot{v}(t)\in[-1.1,3]$\mathrm{m}\mathrm{/}\mathrm{s}^{2}$$
$f_{3}$ | $m\in[990,1100]$\mathrm{k}\mathrm{g}$$ | $Fr(t)\in[88.2,107.8]$\mathrm{N}$$
$f_{4}$ |  $T(t)\in[150,200.1]$\mathrm{N}\mathrm{m}$$ $u(t)\in[-0.1,1.511]$ | $F(t)\in[-159.1,3024.0]$\mathrm{N}$$
$f_{5}$ | $v(t)\in[21.8,38.4]$\mathrm{m}\text{/}\mathrm{s}$$ | $Fa(t)\in[237.6,827.6]$\mathrm{N}$$
$f_{6}$ | $v(t)\in[21.8,38.4]$\mathrm{m}\text{/}\mathrm{s}$$ | $\omega(t)\in[109.8,406.1]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$$
$f_{7}$ |  $\omega(t)\in[109.8,406.1]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$$ $\omega_{m}\in[365,450]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$$ | $T(t)\in[150,200.1]$\mathrm{N}\mathrm{m}$$
$f_{8}$ |  $v_{r}\in[23.0,30.0]$\mathrm{m}\text{/}\mathrm{s}$$ $v(t)\in[21.8,38.4]$\mathrm{m}\text{/}\mathrm{s}$$ | $u(t)\in[-0.1,1.511]$

##  7 Conclusion

###  7.1 Summary

SBD has excellent potential in assisting functional requirements decomposition
for complex systems, especially under the OEM-supplier development mode. This
paper formalizes the functional requirements decomposition process for SBD. We
first proved that as long as the sub-requirements are composable and refine
the higher-level functional requirements, the design teams at multiple levels
can decompose their functional requirements independently, and the final
system will still satisfy the top-level functional requirements. After that,
we proposed a set-based formal process for the design teams at each level of
abstraction to decompose the functional requirements independently so that the
sub-requirements are composable and refine the higher-level functional
requirements. Finally, a case study on designing a cruise control system was
conducted to demonstrate the feasibility of the proposed set-based process.

###  7.2 Discussion

#### Toyota’s set-based approach.

In one of the seminal works of SBD, Ward et al. [54] explained Toyota’s
qualitative SBD process in five steps. Later, Specking et al. [5] observed
that many SBD literature shared the similar characteristics with Toyota’s
process. We compare our process with Toyota’s approach below.

  1. 1.

The team defines a set of solutions at the system level.

  2. 2.

It defines sets of possible solutions for various subsystems.

  3. 3.

It explores these possible subsystems in parallel to characterize a possible
set of solutions.

  4. 4.

It gradually narrows the set of solutions, converging slowly toward a single
solution. In particular, the team determines the appropriate specifications to
impose on the subsystems.

  5. 5.

Once the team established the single solution for any part of the design, it
does not change it unless absolutely necessary.

The first step above is the same as Step 1 in our process, where the
“solution” in our case is the functional architecture. The second step and
third step above correspond to Step 2 of our process, which are essentially
defining the feasible implementation of the subsystems individually. The
fourth step above corresponds to Step 3 and 4 in our process. However, our
formal process provides more details without ambiguity. With the underlying
formalism defined in the process, we are able to explain how to narrow the
sets, determine the specifications on the subsystems, and gradually converge
to a single solution using hierarchy. The fifth step above is related to the
uncertainty expansion addressed in our process. Specifically, Toyota applies
“rigorous effort to avoid changes that _expand_ , rather than contract, the
space of possible designs” [54]. We believe expansion sometimes is unavoidable
due to epistemic uncertainties. Step 4 of our process for “uncertainty
expansion” is motivated for this reason and designed to address this possible
impacts of the unexpected uncertainty expansions.

#### Scalability.

One possible question about the proposed process relates to scalability. The
hierarchical nature of our process makes it scalable for complex systems, as
the complexity can always be reduced through hierarchical abstraction, i.e.,
an iterative “divide-and-conquer” approach at multiple levels of abstraction
that still provides mathematical guarantees that the composed system meets its
requirements. However, at one specific level of abstraction, the scalability
of our process is subject to the effectiveness of the computational techniques
used in the process. Specifically, Step 3 requires computational tools to
compute $FDS^{2}$ and $FPS^{2}$. Too many sub-functions or uncertain
parameters may make the computation challenging. This suggests that creating
appropriate abstractions and architectures is vital to the approach, as it is
in any complex system design.

#### Future work.

Our approach is only applicable to the systems that can be abstracted as
input-output transformations (e.g., dynamic systems), while general SBD does
not assume any formalism of the system. This is a limitation of the paper. The
applicability of other formalisms within the framework should be investigated
in the future.

## References

  * [1] Schrader, S., Riggs, W. M., and Smith, R. P., 1993,  “Choice over uncertainty and ambiguity in technical problem solving,”  Journal of Engineering and Technology Management, 10(1-2), pp. 73–99.
  * [2] Ward, A. C., 1989,  A theory of quantitative inference for artifact sets applied to a mechanical design compiler  Tech. rep., MASSACHUSETTS INST OF TECH CAMBRIDGE ARTIFICIAL INTELLIGENCE LAB.
  * [3] Shallcross, N. J., 2021,  “Quantitative set-based design for complex system development,”  PhD thesis, University of Arkansas.
  * [4] Ghosh, S., and Seering, W., 2014,  “Set-based thinking in the engineering design community and beyond,”  In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Vol. 46407, American Society of Mechanical Engineers, p. V007T07A040.
  * [5] Specking, E. A., Whitcomb, C., Parnell, G. S., Goerger, S. R., Pohl, E., and Kundeti, N. S. A., 2018,  “Literature review: exploring the role of set-based design in trade-off analytics,”  Naval Engineers Journal, 130(2), pp. 51–62.
  * [6] Sobek II, D. K., Ward, A. C., and Liker, J. K., 1999,  “Toyota’s principles of set-based concurrent engineering,”  MIT Sloan Management Review, 40(2), p. 67.
  * [7] Shallcross, N., Parnell, G. S., Pohl, E., and Specking, E., 2020,  “Set-based design: The state-of-practice and research opportunities,”  Systems Engineering, 23(5), pp. 557–578.
  * [8] Dullen, S., Verma, D., Blackburn, M., and Whitcomb, C., 2021,  “Survey on set-based design (sbd) quantitative methods,”  Systems Engineering, 24(5), pp. 269–292.
  * [9] Eckert, C., Isaksson, O., and Earl, C., 2019,  “Design margins: a hidden issue in industry,”  Design Science, 5.
  * [10] Matthews, J., Klatt, T., Seepersad, C. C., Haberman, M., and Shahan, D., 2014,  “Bayesian network classifiers and design flexibility metrics for set-based, multiscale design with materials design applications,”  In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Vol. 46322, American Society of Mechanical Engineers, p. V02BT03A008.
  * [11] Müller, J. R., Isaksson, O., Landahl, J., Raja, V., Panarotto, M., Levandowski, C., and Raudberget, D., 2019,  “Enhanced function-means modeling supporting design space exploration,”  AI EDAM, 33(4), pp. 502–516.
  * [12] Raudberget, D. S., Michaelis, M. T., and Johannesson, H., 2014,  “Combining set-based concurrent engineering and function—means modelling to manage platform-based product family design,”  In 2014 IEEE International Conference on Industrial Engineering and Engineering Management, IEEE, pp. 399–403.
  * [13] Levandowski, C., Raudberget, D., and Johannesson, H., 2014,  “Set-based concurrent engineering for early phases in platform development,”  In Moving Integrated Product Development to Service Clouds in the Global Economy. IOS Press, pp. 564–576.
  * [14] Kriesi, C., Blindheim, J., Bjelland, Ø., and Steinert, M., 2016,  “Creating dynamic requirements through iteratively prototyping critical functionalities,”  Procedia CIRP, 50, pp. 790–795.
  * [15] Borchani, M. F., Hammadi, M., Ben Yahia, N., and Choley, J.-Y., 2019,  “Integrating model-based system engineering with set-based concurrent engineering principles for reliability and manufacturability analysis of mechatronic products,”  Concurrent Engineering, 27(1), pp. 80–94.
  * [16] Vallhagen, J., Isaksson, O., Söderberg, R., and Wärmefjord, K., 2013,  “A framework for producibility and design for manufacturing requirements in a system engineering context,”  Procedia CIRP, 11, pp. 145–150.
  * [17] Al-Ashaab, A., Golob, M. M., Noriega, M. P., Torriani, M. F., Alvarez, M. P., Beltran, M. A., Busachi, M. A., Ex-Ignotis, M. L., Rigatti, M. C., Sharma, M. S., et al., 2013,  “Capturing the industrial requirements of set-based design for conga framework,”  Advances in Manufacturing Technology XXVII, p. 3.
  * [18] Ammar, R., Hammadi, M., Choley, J.-Y., Barkallah, M., Louat, J., and Haddar, M., 2017,  “Architectural design of complex systems using set-based concurrent engineering,”  In 2017 IEEE International Systems Engineering Symposium (ISSE), IEEE, pp. 1–7.
  * [19] Yvars, P.-A., and Zimmer, L., 2022,  “Towards a correct by construction design of complex systems: The mbss approach,”  Procedia CIRP, 109, pp. 269–274.
  * [20] Al-Ashaab, A., Golob, M., Attia, U. M., Khan, M., Parsons, J., Andino, A., Perez, A., Guzman, P., Onecha, A., Kesavamoorthy, S., et al., 2013,  “The transformation of product development process into lean environment using set-based concurrent engineering: A case study from an aerospace industry,”  Concurrent Engineering, 21(4), pp. 268–285.
  * [21] Al-Ashaab, A., Howell, S., Usowicz, K., Hernando Anta, P., and Gorka, A., 2009,  “Set-based concurrent engineering model for automotive electronic/software systems development,”  In Proceedings of the 19th CIRP Design Conference–Competitive Design, Cranfield University Press.
  * [22] Madhavan, K., Shahan, D., Seepersad, C. C., Hlavinka, D. A., and Benson, W., 2008,  “An industrial trial of a set-based approach to collaborative design,”  In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Vol. 43253, pp. 737–747.
  * [23] Matthews, J., Klatt, T., Morris, C., Seepersad, C. C., Haberman, M., and Shahan, D., 2016,  “Hierarchical design of negative stiffness metamaterials using a bayesian network classifier,”  Journal of Mechanical Design, 138(4).
  * [24] Jansson, G., Schade, J., and Olofsson, T., 2013,  “Requirements management for the design of energy efficient buildings,”  Journal of Information Technology in Construction (ITcon), 18, pp. 321–337.
  * [25] Shahan, D., and Seepersad, C. C., 2009,  “Bayesian networks for set-based collaborative design,”  In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Vol. 49026, pp. 303–313.
  * [26] Kerga, E., Rossi, M., Taisch, M., and Terzi, S., 2014,  “A serious game for introducing set-based concurrent engineering in industrial practices,”  Concurrent Engineering, 22(4), pp. 333–346.
  * [27] Panchal, J. H., Gero Fernández, M., Paredis, C. J., Allen, J. K., and Mistree, F., 2007,  “An interval-based constraint satisfaction (ibcs) method for decentralized, collaborative multifunctional design,”  Concurrent Engineering, 15(3), pp. 309–323.
  * [28] Parnell, G. S., Specking, E., Goerger, S., Cilli, M., and Pohl, E., 2019,  “Using set-based design to inform system requirements and evaluate design decisions,”  In INCOSE International Symposium, Vol. 29, Wiley Online Library, pp. 371–383.
  * [29] Specking, E., Shallcross, N., Parnell, G. S., and Pohl, E., 2021,  “Quantitative set-based design to inform design teams,”  Applied Sciences, 11(3), p. 1239.
  * [30] Costa, R., and Sobek, D. K., 2003,  “Iteration in engineering design: inherent and unavoidable or product of choices made?,”  In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Vol. 37017, pp. 669–674.
  * [31] Terwiesch, C., Loch, C. H., and Meyer, A. D., 2002,  “Exchanging preliminary information in concurrent engineering: Alternative coordination strategies,”  Organization Science, 13(4), pp. 402–419.
  * [32] Bogus, S. M., Molenaar, K. R., and Diekmann, J. E., 2006,  “Strategies for overlapping dependent design activities,”  Construction Management and Economics, 24(8), pp. 829–837.
  * [33] Parker, M., Garner, M., Arcano, J., and Doerry, N., 2017,  “Set-based requirements, technology, and design development for ssn (x),”  Warship 2017: Submarines & UUVs, 14-15 June 2017.
  * [34] Trueworthy, A. M., DuPont, B. L., Maurer, B. D., and Cavagnaro, R. J., 2019,  “A set-based design approach for the design of high-performance wave energy converters,”  In Proceedings of the 13th European Tidal and Wave Energy Conference, Naples, Italy, pp. 1–6.
  * [35] Al Handawi, K., Andersson, P., Panarotto, M., Isaksson, O., and Kokkolaras, M., 2021,  “Scalable set-based design optimization and remanufacturing for meeting changing requirements,”  Journal of Mechanical Design, 143(2).
  * [36] Müller, J., Siiskonen, M., and Malmqvist, J., 2020,  “Lessons learned from the application of enhanced function-means modelling,”  In Proceedings of the Design Society: DESIGN Conference, Vol. 1, Cambridge University Press, pp. 1325–1334.
  * [37] Landahl, J., Jiao, R. J., Madrid, J., Söderberg, R., and Johannesson, H., 2021,  “Dynamic platform modeling for concurrent product-production reconfiguration,”  Concurrent Engineering, 29(2), pp. 102–123.
  * [38] Levandowski, C., Müller, J. R., and Isaksson, O., 2016,  “Modularization in concept development using functional modeling.,”  In ISPE TE, pp. 117–126.
  * [39] Levandowski, C., Forslund, A., Johannesson, H., et al., 2013,  “Using plm and trade-off curves to support set-based convergence of product platforms,”  In DS 75-4: Proceedings of the 19th International Conference on Engineering Design (ICED13), Design for Harmonies, Vol. 4: Product, Service and Systems Design, Seoul, Korea, 19-22.08. 2013, pp. 199–208.
  * [40] McKenney, T. A., Kemink, L. F., and Singer, D. J., 2011,  “Adapting to changes in design requirements using set-based design,”  Naval Engineers Journal, 123(3), pp. 67–77.
  * [41] Kizer, J. R., and Mavris, D. N., 2014,  “Set-based design space exploration enabled by dynamic constraint analysis,”  In Proceedings of the 29th Congress of the International Council of the Aeronautical Sciences, ICAS.
  * [42] Parsons, M. G., and Singer, D. J., 1999,  “A hybrid agent approach for set-based conceptual ship design,”.
  * [43] Ross, J. E., 2017,  “Determining feasibility resilience: Set based design iteration evaluation through permutation stability analysis,”  PhD thesis, The University of Southern Mississippi.
  * [44] Rapp, S., Chinnam, R., Doerry, N., Murat, A., and Witus, G., 2018,  “Product development resilience through set-based design,”  Systems Engineering, 21(5), pp. 490–500.
  * [45] Tackett, M. W., Mattson, C. A., and Ferguson, S. M., 2014,  “A model for quantifying system evolvability based on excess and capacity,”  Journal of Mechanical Design, 136(5), p. 051002.
  * [46] LARSON, B. J., and MATTSON, C. A., 2012,  “Design space exploration for quantifying a system model’s feasible domain,”  Journal of mechanical design, 134(4).
  * [47] Buede, D. M., 1997,  “Integrating requirements development and decision analysis,”  In 1997 IEEE International Conference on Systems, Man, and Cybernetics. Computational Cybernetics and Simulation, Vol. 2, IEEE, pp. 1574–1579.
  * [48] Wood, K. L., and Antonsson, E. K., 1989,  “Computations with imprecise parameters in engineering design: background and theory,”.
  * [49] Nahm, Y.-E., and Ishikawa, H., 2006,  “Novel space-based design methodology for preliminary engineering design,”  The International Journal of Advanced Manufacturing Technology, 28(11), pp. 1056–1070.
  * [50] Qureshi, A. J., Dantan, J.-Y., Bruyere, J., and Bigot, R., 2014,  “Set-based design of mechanical systems with design robustness integrated,”  International Journal of Product Development, 19(1/2/3), pp. 64–89.
  * [51] Geretti, L., Sandretto, J. A. D., Althoff, M., Benet, L., Chapoutot, A., Collins, P., Duggirala, P. S., Forets, M., Kim, E., Linares, U., et al., 2021,  “Arch-comp21 category report: Continuous and hybrid systems with nonlinear dynamics.,”  In ARCH@ ADHS, pp. 32–54.
  * [52] Aström, K. J., and Murray, R. M., 2010,  Feedback systems: an introduction for scientists and engineers Princeton university press.
  * [53] Althoff, M., and Kochdumper, N., 2016,  “Cora 2016 manual,”  TU Munich, 85748.
  * [54] Ward, A., Liker, J. K., Cristiano, J. J., Sobek, D. K., et al., 1995,  “The second toyota paradox: How delaying decisions can make better cars faster,”  Sloan management review, 36, pp. 43–43.

## Appendix A

_Proof of Property 3._ Let $FR$ be the composite of
$\\{FR_{1},FR_{2},..,FR_{n}\\}$. Replace one $FR_{i}$ with $FR^{\prime}_{i}$
($i=1,2...n$). According to Property 2,
$\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$ are composable, meaning
$FR_{i}$ can be replaced with $FR^{\prime}_{i}$ without causing changes to
other functional requirements.

Therefore, if the input of $FR_{i}$ is the input of $FR$, then the composite
of $\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$ will have a larger
input space. If the output of $FR_{i}$ is the output of $FR$, then the
composite of $\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$ will have a
smaller input space. Otherwise, the composite of
$\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$ will have the same input
space and output space as $FR$. As a result, we can conclude the composite of
$\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$ will always refine $FR$.

Next, replace another element in
$\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$ with its refinement. We
will obtain a refinement of
$\\{FR_{1},FR_{2},..,FR^{\prime}_{i},...,FR_{n}\\}$. Repeat the process until
all the functional requirements are replaced with the respective refinement.
Eventually, we will obtain
$\\{FR^{\prime}_{1},FR^{\prime}_{2},..,FR^{\prime}_{n}\\}$ that refines $FR$.

## Supplemental Material

##  Appendix A Further details of the sub-functions from the case study

$\mathbf{f_{1}}$ is a mathematical definition of the speed, and hence will be
allocated to no subsystem. $\dot{v}(t)$ has to be bounded to avoid violent
acceleration/deceleration by the cruise control; $v(t)$ is bounded to
constrain the fastest speed that the cruise control can be engaged due to
safety concerns.

  * •

$f_{1}$: $v(t)=\int_{0}^{t}\dot{v}dt+v_{0}$.

  * •

$x(1)=(v_{0},\dot{v})^{\top}$ and,
$R_{x(1)}=([0,40]$\mathrm{m}\text{/}\mathrm{s}$,[-1.5,3]$\mathrm{m}\mathrm{/}\mathrm{s}^{2}$)^{\top}$.

  * •

$y(1)=v(t)$ and $R_{y(1)}=[0,50]$\mathrm{m}\text{/}\mathrm{s}$$.

$\mathbf{f_{2}}$ combines all the forces and yields the acceleration of the
car as a whole, where $F(t)$ is the driving force, $Fa(t)$ is the aerodynamic
drag, and $Fr$ is the tyre friction. The weight of the car $m$ is defined as
an uncontrollable parameter.

  * •

$f_{2}$: $\dot{v}(t)=(F(t)-Fr-Fa(t))/m$.

  * •

$x(2)=(F(t),Fr,Fa(t))^{\top}$ and,
$R_{x(2)}=([-250,3500]$\mathrm{N}$,[60,130]$\mathrm{N}$,[0,1000]$\mathrm{N}$)^{\top}$.

  * •

$y(2)=\dot{v}(t)$ and $R_{y(2)}=[-2,4]$\mathrm{m}\mathrm{/}\mathrm{s}^{2}$$;

  * •

$u(2)=m$ and $R_{u(2)}=[990,1100]$\mathrm{k}\mathrm{g}$$.

$\mathbf{f_{3}}$ represent the rolling friction of the tyre. No input is
defined for this function. $C_{r}$ is the rolling friction coefficient.

  * •

$f_{3}$: $Fr=mgC_{r}$.

  * •

$y(3)=Fr$ and $R_{y(3)}=[70,120]$\mathrm{N}$$.

  * •

$u(3)=m$ and $R_{u(3)}=[990,1100]$\mathrm{k}\mathrm{g}$$.

$\mathbf{f_{4}}$ represents the ability of the drivetrain to convert the
torque to the driving force, where $\alpha$ is the gear ratio, $u(t)$ is the
control input from the cruise controller (not the uncontrollable uncertain
parameters defined in this paper), $T(t)$ is the torque.

  * •

$f_{4}$: $F(t)=\alpha*u(t)T(t)$.

  * •

$x(4)=(u(t),T(t))^{\top}$ and,
$R_{x(4)}=([-0.5,2],[0,250]$\mathrm{N}\cdot\mathrm{m}$)^{\top}$.

  * •

$y(4)=F(t)$ and $R_{y(4)}=[-1250,5000]$\mathrm{N}$$.

$\mathbf{f_{5}}$ represents the aerodynamic drag, where $\rho$ is the air
density, $C_{d}$ is the shape-dependent aerodynamic drag coefficient and $A$
is the frontal area of the car.

  * •

$f_{5}$: $Fa(t)=\frac{1}{2}\rho C_{d}Av(t)^{2}$;

  * •

$x(5)=v(t)$ and $R_{x(5)}=[0,60]$\mathrm{m}\text{/}\mathrm{s}$$.

  * •

$y(5)=Fa(t)$ and $R_{y(5)}=[0,2000]$\mathrm{N}$$.

$\mathbf{f_{6}}$ represents the ability of the drivetrain to convert from the
car speed $v(t)$ to the engine speed $\omega(t)$.

  * •

$f_{6}$: $\omega(t)=\alpha*v(t)$;

  * •

$x(6)=v(t)$ and $R_{x(6)}=[0,55]$\mathrm{m}\text{/}\mathrm{s}$$.

  * •

$y(6)=\omega(t)$ and
$R_{y(6)}=[0,560]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$$.

$\mathbf{f_{7}}$ represents the correlation between the torque, the engine
speed $\omega(t)$, the maximum torque $T_{m}$ and the maximum engine speed
$\omega_{m}$. $\omega_{m}$ is the controllable uncertain design parameter that
starts with a rough estimation but will eventually be determined by the
designers.

  * •

$f_{7}$: $T(t)=T_{m}(1-\beta(\omega(t)/\omega_{m}-1)^{2})$.

  * •

$x(7)=\omega(t)$ and
$R_{x(7)}=[0,450]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$$.

  * •

$y(7)=T(t)$ and $R_{y(7)}=[0,250]$$\mathrm{N}\mathrm{M}$.

  * •

$c(7)=\omega_{m}$ and
$R_{c(7)}=[350,480]$\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{/}\mathrm{s}$$.

$\mathbf{f_{8}}$ is the cruise controller, in this case based on PID control.
$p$ and $i$ are the proportional and integral parameters for the PID
controller.

  * •

$f_{8}$: $u(t)=p(v_{r}-v(t))+i\int_{0}^{t}(v_{r}-v(t))dt$.

  * •

$x(8)=(v_{r},v(t))^{\top}$ and,
$R_{x(8)}=([0,60]$\mathrm{m}\text{/}\mathrm{s}$,[0,60]$\mathrm{m}\text{/}\mathrm{s}$)^{\top}$.

  * •

$y(8)=u(t)$ and $R_{y(8)}=[-0.5,4]$.

The coefficients mentioned above are
$\alpha=10,g=9.8,C_{r}=0.01,C_{d}=0.32,\rho=1.3,A=2.4,\beta=0.4,T_{m}=200,p=0.1,i=0.5$.

##  Appendix B Additional results of the case study

We mentioned in the case study that after applying CORA for the reachability
analysis, the result shows the range of $v(t)$ converges gradually from
$R_{v_{0}}$ to $R_{v_{r}}$ during the simulated time, meaning the reference
speed is achieved by the cruise control system. Here are the plots of the
converging trend from CORA.

Fig. 1 is a continuous plot of the reachable set of $(v(t),u(t))^{\top}$ for
$t\in[0,100]$ seconds. The blue line at the left bottom corner is the initial
condition of $(v(0),u(0))^{\top}$. It converges to the right and becomes
stable at the darker red area as the time approaches to $t=100$.

Figure 1: Continuous evolution of the reachable sets of $(v(t),u(t))^{\top}$:
given a set of known dynamics (Table 1), all the possible values of
$(v(t),u(t))^{\top}$ during $t\in[0,100]$ are properly bounded within the red
shape.

Fig. 2 shows the convergence of $(v(t),u(t))^{\top}$ through time. In the
beginning, it is bounded by the large blue area during $[1,2]s$; it then
gradually migrates to the right and is bounded in the smaller green area for
$[10,11]s$; during $[20,100]s$, it is bounded in the smallest magenta area.
This discrete change in different sections of time coincides the narrowing and
converging trend in Fig. 1.

Figure 2: Discrete sampling of the continuous evolution of the reachable sets
(Figure 1) at different time intervals. Instead of only showing the trend of
the convergence, it compares the reachable sets of $(v(t),u(t))^{\top}$ at
different time intervals. Compared with the blue area during $[1,2]$ seconds
and the green area during $[10,11]$ seconds, the magenta area of the last $80$
seconds is much smaller.