Logical Architecture

6.1. Introduction, Definition and Purpose of Architectural Design

Introduction - Architectural design explores, defines, and formalizes the solutions that meet the System Requirements and selects the optimal solution, taking those requirements into account. Design is in fact the core of Systems Engineering.

ADD ACTION RELATED TO COMMENT 2160

Definition and Purpose - The main issues to be approached during the design of systems are:

• The functional modeling of the solution, as independent as possible from the implementation technologies, is an essential step toward working out an optimal physical solution. This functional model is established according to various aspects of transformations (functions and input/output flows) and considers the behavior of the system (states, transitions, and trigger events), otherwise known as the scenarios of the system operation (use cases).
• The projection or allocation of this functional model onto a physical architecture, dependent of the implementation technologies, including the definition of components (sub-systems and system elements) and physical connections (physical interfaces). The physical solution model satisfies the System Requirements.
• The confidence to have correctly designed the architecture and found the optimal option, given the complete set of System Requirements.

6.2. Principles about Architectural Design

6.2.1. Concept of Interface

The concept of interface is probably one of the most important to take into account when designing the architecture of the system-of-interest. From an etymology point of view, the term “interface” comes from the Latin words "inter" and "face" and means “to do something between things”. Therefore, the fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As the functions are performed by physical components (or sub-systems), the inputs/outputs of the functions are also carried by physical components, called physical links. Consequentially, the engineer must consider both the functional and physical aspects in the complete notion of interface. A detailed analysis of a complete interface shows that one needs to consider also the function “send,” located in one of the components, the function “receive,” located in the other one, and the function “carry,” performed by the physical link which supports the output/input flow – see Figure 7.

FIGURE 7

In the context of complex exchanges between some components, a protocol is seen as a physical interface or link which carries or supports the exchanges of data (functional interface). So the engineer must consider both the functional and physical aspects in the complete notion of interface.

6.2.2. Functional / Logical Architecture

6.2.2.1. Concept of Function

A function is an action that transforms inputs and generates outputs such as materials, energies, or information (or a combination of them). These inputs and outputs are the flow items exchanged between the functions. The general mathematic notation of a function is y = ƒ(x) and can be represented graphically – refer to section 3.3.6.3.5.

The design activities shall proceed from a functional framework, specifically in the case of the processes dealing with control-command, data processing, or services. In order to define the complete set of functions of the system, one must identify all the functions necessitated by the system and derived requirements as well as the corresponding inputs and outputs exchange driven by those functions. These two kinds of functions are:

1. The functions directly deduced from the functional requirements and from the interface requirements. They express the expected services of a system to meet the System Requirements.
2. The derived functions issued from the alternative solutions of physical architecture as the result of the design. They depend on technology choice to implement the functional architecture.

6.2.2.2. Functions hierarchy – Decomposition of Functions

At the highest level of a hierarchy, it is possible to represent a system as a unique main function (defined as the system's mission) just like a "black box." In order to understand in detail what the system does, this "head-of-hierarchy" is broken down into sub-functions grouped to form a sub-level of the hierarchy, and so on. The functions of the last level of a functional hierarchy can be called leaf-functions. Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which the physical solutions are known or possible to imagine.

6.2.2.3. Input/output and control Flows – Interfaces between Functions

The decomposition into functional hierarchy is an interesting way of understanding the system, but it represents an incomplete part of the functional architecture because it does not represent the exchanged flows of inputs and outputs. To get a more complete view, representations of the functional architecture should be able to model the various transformations operated by the system, using diagrams such as Functional Flow Block diagrams (FFBD) – refer to (Oliver, Kelliher, and Keegan 1997), or Activity Diagram of SysML (add reference).

In SE three types of input/output flows exchanged are considered: material, energy, and information.

6.2.2.4. Control Flow (Trigger)

The control flow is an element that activates a function as a condition of its execution. The state of this element (or the condition it represents) activates or deactivates the function (or elements thereof). A control flow can be a signal, an event such as position "on", an alarm or a trigger, a temperature variation, the push of a key on a keyboard, etc.

ADD ACTION RELATED TO COMMENT 1169

6.2.2.5. Concept of Dynamics

The preponderance of mathematics consists of continuous functions that are generally solved though differential equations. In SE, one considers also the set of functions that interact between themselves and with functions outside of the system. Since functions start and stop their execution depending on events, triggers, or durations, the discontinuous aspect of functions is a major consideration when designing the functional architecture.

Modeling using only functional hierarchy decomposition is insufficient to give a complete idea of what the system will do. A function is action, transformation, and dynamics, so it is necessary to consider the exchanges between the functions, as well as the reactions of the system in its context and operational environment, through control flows, scenarios, and behaviors of functions, states, or operational Modes.

Scenario of Functions - A scenario is a chain of functions performed as a sequence that synchronizes the functions between them, using their control flows to achieve a global transformation of inputs into outputs. A scenario of functions expresses the dynamic of an upper level function; inversely, a function can be expressed dynamically by a scenario of (sub) functions. The functional architecture is worked out with scenarios for each level of the functional hierarchy and for each level of the system hierarchy. The coherent combination of the scenarios is the global Functional Architecture of the system.

Operational State/Operational Mode – A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function as well as on its controls. Now, in a discussion of operational state or operational mode, the focus is on a scenario of states. A scenario of states is a chain of states performed as a sequence of transitions between the various states of the system. The transition from one state to another one is triggered by the arrival of a control flow (event, trigger). An action (function) can be generated within a transition between two states, following the arrival of an event or a trigger.

ADD ACTION RELATED TO COMMENT 1170

6.2.2.6. Functional Design Patterns

When designing scenarios or functional architectures, the designer has to recognize and to use known models to perform the expected transformations. Patterns are generic basic models, more or less sophisticated depending on the complexity of the treatment. A pattern can be represented with different notations. Functional design patterns can be classified into several categories, such as:

• Basic patterns linking functions: sequence, iteration, selection, concurrence, multiple exits, loop with exit, replication without monitoring, replication with monitoring.
• Complex patterns: monitor a treatment, exchange a message, Man Machine Interface, mutual exchanges, states-transition monitoring, real-time monitoring of processes, queue management, continuous monitoring with supervision.
• Failure detection, identification, recovery (FDIR) patterns: general FDIR pattern, passive redundancies, active redundancies, semi-active redundancies, continuation of treatment in degraded performance.
• Etc.

6.2.2.7. Temporal and Decision Hierarchy Concept

Not every function of a system is performed at the same frequency. It changes depending on the time and the ways functions are started and executed. One must therefore consider several classes of performance.

There are synchronous functions, that are executed cyclically, and asynchronous functions, that are executed when an event or trigger happens. The decision monitoring inside a system follows the same temporal classification because decisions are related to functions.

"Real-time" systems and command/control systems combine the cyclic operations (synchronous) and the factual aspects (asynchronous). The cyclic operations consist of sharing out the execution of the functions according to frequencies, which depend on the constraints of capture, or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:

• The disturbances on the high frequencies (bottom of the Figure 8) - the decisions are made at the level they occur or at the immediate upper level. The goal is to ensure the disturbances do not go up in the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations. The typical example related to the operations concerns breakdowns or failures.
• The changes happening on the low frequencies (top of the Figure 8) - the decisions of change are made at the upper levels. The goal is to transmit them towards the bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.

FIGURE 8

6.2.3. Physical Architecture

6.2.3.1. Composition of System into Systems and System Elements (End Products)

Refer to the Systems Engineering Fundamentals Knowledge Area (KA), section XXXX and section 3.3.2.1.

6.2.3.2. Allocation of Functional Elements to Physical Elements and Partitioning

A system physical architecture is a structure of the system-of-interest that identifies the components with their physical links. A component can be a system or a system element. Physical architecture and its elements exist in any kind of system, even in systems of services (human roles, infrastructures, procedures, protocols, etc.), organizations or enterprises (departments, sections, divisions, projects, procedures, protocols, etc.), or systems-intensive software (pieces of code, objects, databases, application protocols interface, etc.).

The components of the system perform the functions, and the links between components carry the input/output flows and control flows. Partitioning and allocation are activities to decompose, gather, or separate functions in order to be able to identify feasible components that could perform the functions of the system.

6.2.3.3. Criteria to Partition and Allocate Functions onto Components

Partitioning and allocation use criteria to find potential affinities between the functions. There are several criteria provided by the list of System Requirements. Some of the criteria include the periodicity of function, whether functions are subjected to similar effectiveness measures, whether they have commonalities in input, output, or control flows, whether similar transformations occur, whether functions occur in similar environments, the level of reuse of components, and/or project or enterprise constraints.

The partitioning of functions stops when the designer is able to identify one or several physical components that could perform the function or a set of functions. Either the component exists, is re-usable, or can be developed and technically implemented.

6.2.3.4. Designing Physical Candidate Architectures

The existence of several candidate arrangements of components that might potentially implement a function feed the list of candidate physical architectures that might be selected for the preferred physical architecture. All viable physical architectures should completely implement all required system functions. The preferred physical architecture represents the optimum design.

For a specific system level, the number of levels of decomposition of the functions might not exceed three or four because the sub-functions reside in the lower system levels. Even if the designer identifies more than ten leaf components to constitute the architecture of the current system level, he or she must synthesize the set into a single level of 7 + or – 2 higher level of components (sub-systems and/or system elements).

ADD ACTION RELATED TO COMMENT 407

Synthesis is done by grouping the leaf components to constitute a set of sub-systems. It must be done according to design criteria or principles such as reduction of the number of physical links, modularity, testability of components, maintainability, compatibility of technologies, usability, consumption of means or resources, emerging properties control (see section 3.3.6.2.4), etc.

ADD ACTION RELATED TO COMMENT 925

6.2.3.5. Evaluating and Selecting the Preferred Alternative

The goal of physical design activities is to achieve and provide the best possible set of components and the “best” architecture. The “best” means to define the solution that answers, at best, all the requirements, depending on the agreed limits or margins of each requirement. To do so, there is no other way than to produce several architectures, compare them, and select the most suitable one. Depending on the kind of system, certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global or detailed behavior of the candidate architectures of the system, regarding the System Requirements. Those analyses are gathered behind the terms “system analysis” (see section 3.3.7).

ADD ACTION RELATED TO COMMENT 1165, 2227

6.2.4. Emerging Properties

The notion of emerging property is used during the design of the system to highlight the necessary derived functions and internal physical or environmental constraints of the system. The corresponding “derived requirements” result from the studies of these emerging properties. They should be added to the System Requirements baseline when they impact the system-of-interest (SOI).

The (sub)-systems or system elements that compose the system-of-interest interact between themselves and can create desirable or undesirable phenomena called "emerging properties," such as interference or resonance. The definition of the system includes an analysis of the interactions between the (sub)-systems and/or the system elements in order to prevent the undesirable properties (negative behaviors) and reinforce the desirable ones (positive behaviors).

A property which emerges from a system can have various origins: from a single component (sub-system / system element), from several components, or from the interaction between several components.

The emerging properties of a system can be classified as in (Thome 1993):

• Local emerging property (in a single sub-system) - Example: the capacity of a container is the capacity of the system.
• Dispatched emerging property (in several sub-systems) - Examples: the weight of the system results from the sum of the weights of its sub-systems.
• Transitive emerging property (the property exists in several sub-systems and is modified by their interactions) - Example: the reliability of a system results from the reliability of each sub-system and the way they are organized.
• Non-transitive emerging property (the property does not exist in the sub-systems and results only from their interactions) - Example: electromechanical interferences, electromagnetism, static electricity, etc.
• Immerging property (inhibited property before going outside the system) - Examples: unbalance removed by the addition of a load; vibration deadened by a damper.

6.2.5. Systems of Systems Architecting

The characteristics of systems of systems (SoS) are provided in the Systems of Systems (SoS) KA, and are considered as requirements or constraints when designing their architecture.

---

6.3. Process Approach – Architectural Design

6.3.1. Purpose and Principle of the approach

The purpose of the Architectural Design Process is to synthesize a solution that satisfies the System Requirements (ISO/IEC 2008).

The architectural solution consists of both a functional or logical architecture (expressed as a set of functions, scenarios, and/or operational modes) and a physical architecture (expressed as a set of systems and system elements physically connected between them).

6.3.1.1. Transition from System Requirements to Physical Architecture

The aim of the approach is to progress from the system requirements baseline – representing the problem from a supplier/designer point of view, and as much as possible independent of technology - to an intermediate model of functional architecture - dependent on design decisions - then to allocate the elements of the functional architecture to the elements of potential physical architectures. The design decisions and the technological solutions are selected according to performance criteria and non-functional requirements such as the operational conditions and life cycle constraints (for example: environmental conditions or maintenance constraints) – see Figure 9.

FIGURE 9

6.3.1.2. Iterations between Functional and Physical Architectures Design

The design activities require spending several iterations from the functional design to the physical design and vice versa until both functional and physical architectures are exhaustive and consistent.

The first design activity is always the creation of a functional design that is based on the nominal scenarios. The goal is to get a first model that could achieve the mission of the system. The physical design then enables the engineer to determine the main components that will perform these functions and to organize them into a physical architecture.

A second functional design loop allows taking into account the allocations of the functions onto components and the derived functions coming from the physical solution choices, as well as supplementing the initial functional model by introducing other and/or altered modes, failure analyses, and every operational requirement not taken into account in the first loop. The derived functions must, in their turn, be allocated to components, and this, in turn, affects the physical design.

Obviously, other design loops must be considered to produce an exhaustive and consistent functional and physical solution. During design, technological choices conduct potentially to new functions, new input/output and control flows, and new physical links. These new elements can conduct to the creation of new System Requirements, called “derived requirements”, which become part of the requirements baseline.

ADD ACTION RELATED TO COMMENT 1641

6.3.1.3. Generic inputs and outputs of the design process

Because of the necessary iterative execution of the design, the inputs and outputs of the process evolve incrementally. The generic inputs include of course the system requirements, but also the generic design patterns that the designer identifies and uses to answer the requirements, the outcomes from the system analysis, and the feedback from the verification and validation.

The generic outputs are the selected functional and physical architectures of the system-of-interest (SOI), the (stakeholder) requirements of every component that comprises the physical architecture of the system-of-interest, the Interface Requirements between the components, and the rejected solutions elements.

ADD ACTION RELATED TO COMMENTs 441, 2228, 2229, 2230

6.3.2. Activities of the Process

ADD ACTION RELATED TO COMMENTs 562, 2491

Major activities and tasks performed during this process include:

1. Define the functional architecture of the system:
   1. Identify functions, input/output flows, operational modes, and operational scenarios from the system requirements by analyzing the functional, interface, and operational requirements;
   2. Define the necessary inputs and controls (energy, material, and data flows) to each function and the outputs generated thereby; deduce the necessary functions which use, transform, move, and generate the flows;
   3. Allocate performance, effectiveness, and constraints requirements to functions and to input, output, and control flows;
   4. Design candidate functional architectures using the previous defined elements to model scenarios of functions. Integrate the scenarios of functions in order to get a complete picture of the dynamic behavior of the system and allocate the temporal constraints. Decompose the functional elements as necessary to look towards implementation. Perform functional failure modes and effects analysis.
   5. Select the functional architecture by assessing the candidate functional architectures against criteria (related to requirements) and comparing them. Use system analysis to perform the assessments – see section 3.3.7.3.
   6. Synthesize the selected functional architecture, verifying its dynamic behavior. Identify the derived functional elements created for the necessity of design.
   7. Establish traceability between system requirements and functional architecture elements.
2. Define the physical architecture of the system. That is:
   1. Search for components able to perform the functions as well as Links to carry the input, output, and control flows; ensure the components exist or must be engineered. Use partitioning method to perform this allocation (when it is impossible to identify a component that performs a function, decompose the function till it is possible to identify implementable components).
   2. Design candidate physical architectures using the previously-defined elements to model networks of components and links. For each candidate, this requires the working out of a low-level physical architecture with the elementary components. Because these are generally too numerous (ten or more) they have to be grouped into higher-level components, often called sub-systems. It is then possible to work out a high-level physical architecture with these components (sub-systems).
   3. Select the most suitable physical architecture by assessing the candidate physical architectures against criteria (related to requirements) and comparing them. Use the system analysis process to perform the assessments – see section 3.3.7.3.
   4. Synthesize the selected physical architecture, verifying that it satisfies the system requirements and is realistic. Identify the derived physical elements and functional elements created for the necessity of design. Establish traceability between system requirements and physical architecture elements and allocation matrices between functional and physical elements.
3. Feedback the architectural design and the system requirements. That is:
   1. Model the “allocated functional architecture” onto components (sub-systems) if such a representation is possible.
   2. Define derived functional and physical elements induced by the selected functional and physical architectures. Define the corresponding derived requirements and allocate them on appropriate functional and physical architectures elements. Incorporate these derived requirements in the requirements baselines of the systems impacted.
4. Prepare the technical elements for the acquisition of each component of the system:
   1. Define the mission and objectives of the component from the functions performed by the component and the allocation of performance and effectiveness to the component, respectively.
   2. Define the stakeholder requirements for this component (the concerned stakeholder being the system-of-interest). Additional discussion on the development of the stakeholder requirements can be found in section 3.3.4.
   3. Establish traceability between the Components’ requirements and the design elements of the system-of-interest.

6.3.3. Artifacts and Ontology Elements

This process may create several artifacts such as:

1. System Design Document (describes the selected functional and physical architectures)
2. System Design Justification Document (traceability matrices and design choices)
3. Component Requirements Document (one for each component of the SOI)
4. Components Interface Requirements Document (interfaces between the components of the SOI)

Note: The interfaces between the Components of the system are normally described in the System Design Document and then can be grouped in the Components Interface Requirements Documents for interfaces management purpose.

This process handles the ontology elements of the Table 6 for System Functional Design and of the Table 7 for System Physical Design.

TABLE 6

Note: The element "Flow" is used for Input Flow, Output Flow, and Control Flow (trigger).

Note: The term Operational_Mode is equivalent to the term "state".

Note: The element Scenario is used for functional architecture, because as defined a Scenario includes flows of functions, flows of inputs-outputs, and flows of controls (triggers) arranged to model the transformations performed by the system and its behavior.

The main relationships between ontology elements of Functional Design are presented in Figure 10.

FIGURE 10

TABLE 7

Note: The element Component is used for System, or System Element.

Note: The element interface may include both functional aspects (Flow) and physical aspects (Link). It can be used for technical management purpose, for example to generate Interface Description Documents.

Note: The Component_Requirements become one part of the Stakeholder_Requirements applicable to the Component (System or System Element) of the lower layer of decomposition.

The main relationships between ontology elements of Physical Design are presented in Figure 11.

FIGURE 11

6.3.4. Checking and Correctness of Architectural Design

The main items to be checked during design concern functional and physical architectures.

Concerning functional design, check that:

• Every functional and interface requirement corresponds to one or several functions.
• The outputs of functions correspond to submitted inputs.
• Every function produces at least one output.
• Functions are triggered by control flows as needed.
• Functions are sequenced in the right order and synchronized.
• The execution duration of the functions is in the range of the effectiveness or performance requirements.
• All requested operational scenarios are taken into account.
• The simulation of the functional architecture is complete in every possible case and shows that the consummation of input flows and the production of output flows are correctly sized (when simulation of models is possible).

Concerning physical design, check that:

• Every component performs one or several functions of the functional architecture.
• Every function has been allocated to one component.
• Every input/output flow is carried by a physical link.
• The components of the context of the system-of-interest are linked to components of the system-of-interest with physical links.
• The functional architecture is correctly projected onto the physical architecture and the allocated functional architecture reflects this projection correctly.
• The physical architecture is implementable by mastered industrial technologies.

6.3.5. Methods and Modeling Techniques

Design uses modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models:

• Functional models such as the structured analysis design technique (SADT/IDEF0), system analysis & real time (SA-RT), enhanced functional flow block diagrams (eFFBD), function analysis system technique (FAST), etc.
• Semantic models such as entities-relationships diagram, class diagram, data flow diagram, etc.
• Dynamic models such as state-transition diagrams, state-charts, eFFBDs, activity diagram, Petri nets, etc.
• Temporal models such as to be added in SEBoK 0.5.
• Physical models such as physical block diagrams (PBD), etc.

ADD ACTION RELATED TO COMMENTS 3039, 1643, 3040

---

6.4. Application to Product systems, Service systems, Enterprise systems

TO BE WRITTEN

---

6.5. Practical Considerations about Architectural Design

Major pitfalls encountered with Architectural Design:

1. Inputs for design
   1. The major input for design activity is the set of system requirements, and sometimes they do not address the right level of design. The consequence is that the designer lets the requirements fall to the side and invents a solution with what he or she "understands" through the input.
2. Decomposition levels
   1. There is a common mistake with beginners in design that consists of decomposing the functions too deeply, or having too many functions and input/output flows in scenarios or in the functional architecture of the current system-block.
   2. The current system-block includes too many levels of decomposition; the right practice is that the physical architecture of a system-block is composed of one single level of sub systems and/or system elements.
3. Allocations of requirements and functions
   1. The developers perform a direct passage from system requirements to physical architecture without establishing a functional architecture; this is a common wrong practice mainly done when dealing with repeating systems and products because the functions are already known. The issue is that a function is always associated with input/output flows defined in a specific domain set. If the domain set changes, the performance of the function can become invalid.
   2. At a high level of abstraction of multidisciplinary systems, directly allocating the functions onto technologies of the lowest level of abstraction such as Hardware or Software does not reflect a system comprehension; the right practice is to consider criteria to cut out the architecture into sub-systems before reaching the technology level (last level of system).
4. Reuse of components
   1. In some projects, because of the usage of existing products or for industrial purposes, existing products or services are imposed very early as design constraints in the stakeholders’ requirements or in the system requirements, without paying sufficient attention to the new context of use of the system that will include them. It is better to work in the right direction from the beginning. Design the system first, taking account of other requirements, then see if any suitable commercial off-the-shelf (COTS) are available; do not impose a component from the beginning. The right re-use process consists of designing reusable components in every context of use– see Figure 12. FIGURE 12
5. Some architecting principles
   1. Restrict the number of interactions between the components, and consider modularity principle (maximum of consistency inside the component, minimum of links with outside) as the right way for architecting systems
   2. Focus on interfaces rather than on components is another key element of a successful design for abstract levels of systems
   3. Control the emergent properties of the interactions between the sub-systems or system elements: obtain the required synergistic properties, and control or avoid the undesirable behaviors (vibration, noise, instability, resonance, etc.).

---

6.6. Primary References related to Architectural Design

(ISO/IEC 2008)

(INCOSE 2010)

(Maier and Rechtin 2009)

(Rechtin 1999)

(Rechtin 1990)

(Faisandier 2011)

(Oliver, Kelliher, and Keegan 1997)

ADD ACTION RELATED TO COMMENT 1163

---

6.7. Additional References and Readings related to Architectural Design

ADD ACTION

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.

---

Article Discussion

[Go to discussion page]