Table of Contents

• 3.1. Define Functional Architecture
• 3.2. Allocate Requirements to Functions and Flows
• 3.c. Functional Chains

Introduction

One of the easiest way to start the description of the system is to describe its functional architecture. The functional architecture aims to “describe what the system must do” [Dickerson & Mavris 2010]. According to the IEEE standard 1220 - 2005, a functional architecture is an "arrangement of functions and their subfunctions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow, and the performance requirements to satisfy the requirements baseline.” [IEEE 1220 - 2005, 3.1.15] The functional architecture shows the hierarchical decomposition of system function and flows. A function “is a task, action, or activity that must be performed in order to achieve a desired outcome.” [Clifton & Ericson 2011] We will define later in more detail what a function in SEA precisely is.

The definition of the functional architecture is an integral part of well-known systems engineering frameworks, often under the notions of "functional analysis" [NASA, 2007, 4.3.2.2] and "functional decomposition" [Estefan, 2007]. For example, the INCOSE Systems Engineering Handbook introduces the functional architecture in the context of the Function-Based Systems Engineering (FBSE) Method [Walden et al., 2015, Section 9.3]. Common representations used for describing a functional architecture are function trees which show the hierarchical structure of functions in a system, function structures for representing flows between functions [Otto & Wood, 2001], Function Flow Block Diagrams (FFBDs) for representing sequences and their relationships, and N² matrices for identifying interactions and interfaces between functions.  The DoDAF standard provides several diagrams that capture the functional architecture of a system such as the SV-4 view "System Functionality Description" [DoD, 2010].

Fig. 10 shows the role of the functional architecture in a generic systems engineering framework [Boutin, 2017]. The function breakdown structure that represents the decomposition of the system function(s) is shown along with the flows between the functions. Requirements are allocated to functions and functions are allocated to system components. arKItect SEA enables to model these aspects of a functional architecture. In the following, each of these aspects along with its concepts are presented.

Figure 10: The functional architecture and its relationship with other SEA systems engineering data [Boutin, 2017]

Functions and flows are designated to meet requirements, as shown in Figure 11. The numbers in the yellow circle are the corresponding SEA views. The system requirements “Wi-Fi connection” is allocated to the function “Capture the WiFi signal” and the requirement “Wired connection” is allocated to the function “Capture the cabled internet signal”. The allocation is represented by the “allocated to” relationship.

Figure 11: Allocation of requirements to functions and flows

The table below shows the coverage of common systems engineering functional architecture artifacts by arKItect SEA.

Main tasks of the functional architecture step

• Define the functional architecture: Functions & flows;
• Allocate requirements to functions & flows.

Definition: Functions and flows

In SEA, in order to qualify as a function, an object needs to satisfy the following two conditions:

• It begins with a verb, since it is an action;
• It transforms flows (It has input and output flows).

Figure 12 shows an example for a function. It begins with a verb, as it begins with “to heat”. It transforms flows, as it has “cold water” as an input and “hot water” as an output. Note that functions are solution-neutral descriptions of what the system does. Hence, words that are related to specific solutions and technologies should be avoided. In practice, it is often the case that the choice of specific functions already limits the solutions that can be found. For example, the function “heat water” already presupposes that there is no external source of hot water and the system needs to create hot water itself.

Figure 12: Example for a function

In SEA, two types of flows are distinguished:

• Physical flow: represents material or energy exchanges;
• Data flow: represents data exchanges such as control, command, regulation, etc.

Figure 13 shows the “heat water” function from Figure 10 with a data flow “command”. The “cold water” and “hot water” flows are physical flows.

Figure 13: Function "heat water" with physical flows and a data flow

At this point we have introduced the notions of functional architecture, function, and flows. Next, we will introduce the steps for developing the functional architecture. 

Furthermore, functions are organized in hierarchies. In other words, a function can have sub-functions or i.e. lower-level functions. Figure 14 an example for a hierarchy of functions for the LapTop system. Note the two input flows “internet WiFi connection” and “internet cabled connection”. The output flow is “internet data” and “internet settings”.

Figure 14: LapTop functions and input / output flows

Objective of functional architecture step

In this step, the objective is to define functions and flows of the studied system, and to allocate requirements to them. Using the LapTop example, we will here define the main functions of the system and all Functional and Physical exchanges inside the system and with the environment. Defining functions is linked with requirements refinement. Indeed, functions are designed to cover requirements. To keep traceability, we will allocate requirements upon functions. It will allow users to check the requirements coverage.

We, firstly, define the:
- Functions,
- Sub-Functions,
- Physical Flows,
- Functional / Data Flows,
and then, we allocate Requirements to Functions.

In our example, the final results of defining the External and Internal Functional Architectures are respectively shown in figures 1 and 2:

Figure 1. External Functional view

Figure 2. Internal Functional view

In the next sections, we'll explain the sub-views of the view 3, which allow to define the Functional Architecture. In each section, there are two parts that explain how to define Functional Architecture in two manners:

1. in a graphical view, called Internal Block Diagram (IBD, below the toolbar, see figure 3),
2. in a tabular view (available through Project Tools icon in the toolbar, see figure 4).

Figure 3. Internal Block Diagram tab

Figure 4. Project Tools icon to access Tabular Views

References