Logical Architecture

Architectural design explores, defines, and formalizes the solutions that meet the System Requirements and selects the optimal solution, taking those requirements into account.

Definition and Purpose of Architectural Design

The architectural design of a system is the creation of a solution based on principles and concepts logically related and consistent to each other. The solution possesses properties and characteristics satisfying as much as possible the problem expressed by a set of System Requirements. It is implementable.

The properties and characteristics can be classified and modeled during the design activities in views such as functional, temporal, behavioral, performance, operational, environmental, and structural - see Fundamentals of System Definition topic, System Architecture and System Design sections. Use of a design properties oriented classification (see [[System Requirements}] facilitates these views.

Considerations include:

Functional, behavioral, temporal views - The functional description, independent from the implementation technologies, is essential. A temporal and decision monitoring model supplements well the functional and behavioral models to organize the in service management of the system in order to achieve permanently its mission and purpose .

Performance, operational, environmental, structural views - The projection or allocation of functional, behavioral, temporal models onto a physical architecture , dependent of the implementation technologies, includes the definition of systems and system elements and physical connections (physical interfaces ) that own together design properties such as:
- structural properties (simplicity, modularity, adaptability, scalability, reusability, portability, commonality, expandability, etc.),
- effectiveness/performance levels, accuracy, etc.,
- operational characteristics (usability, availability, maintainability, reliability, testability, robustness, interoperability, integrity, generality, trainingetc.),
- environmental characteristics (heatproof, shockproof, electrical resistance, radiation resistance, etc.).

Confidence in the solution - The confidence having correctly designed the architecture and found the optimal option, given the complete set of System Requirements. This essential aspect is related to the assessment of the properties and characteristics of the system that are performed during design; refer to System Analysis topic.

The various architectural models should cover the properties listed above. Multiple models are used to represent all properties. A today issue is the consistency of all models that represent the global solution.

Principles governing Architectural Design

This section provides a short explanation of the general mechanism of intellectual creation and then focus on known concepts and/or patterns by system designers or architects such as interface, function, input-output-control flow, dynamics, temporal and decision hierarchy, allocation and partitioning, emerging properties, etc.

The intellectual creation works with more or less short "analysis – synthesis" cycles. We analyze objects, ideas, their relationships, and then we try to express or represent synthesis more or less successfully. Figure 1 summarizes this mechanism.:

Figure 1. Intellectual creation principles and mechanism (Faisandier, 2011)

Concept of Interface

The concept of interface is critical when designing the architecture of the system of interest (soi) . The fundamental aspect of an interface is functional, and is defined as inputs and outputs of functions. The engineer must consider both the functional and physical aspects of interfaces.

In the context of complex exchanges between some System Elements (in particular in IT systems), a protocol is seen as a Physical Interface which carries or supports the exchanges of data (functional interface).

Functional / Logical Architecture

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,t) and can be represented graphically – refer to section Methods and Modeling Techniques.

Functions hierarchy – Decomposition of Functions

At the highest level of a hierarchy, a system may be represented 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 sub-levels 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.

Input/Output and Control Flows – Interfaces between Functions

The decomposition into functional hierarchy is an incomplete view of the Functional Architecture because it does not represent the exchanged flows of inputs and outputs. To get a more complete view, diagrams such as Functional Flow Block diagrams (FFBD)(Oliver, Kelliher, and Keegan. 1997), or Activity Diagram of SysML (OMG. 2010) are used.

In systems engineering, three types of Input/Output Flows exchanged are considered: material, energy, and information.

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.

Note: in SysML (OMG. 2010) all interactions are initiated by signals; there five kinds of signals: creation event, destruction event, asynchronous message, synchronous message, duration constraints.

Concept of Dynamics

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 can be considered as 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 and on its controls. Now, in a discussion of Operational Mode, the focus is on a scenario of modes. A scenario of modes is a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode 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 modes, following the arrival of an event or a trigger.

Functional Design Patterns

Patterns are generic basic models, more or less sophisticated, that can be used as templates depending on the complexity. A pattern can be represented with different notations. Examples of functional design patterns include:

Basic patterns linking functions: sequence, iteration, selection, concurrence, multiple exits, loop with exit, replication without monitoring, replication with monitoring, etc.
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, etc.
Failure detection, identification, recovery (FDIR) patterns: general FDIR pattern, passive redundancies, active redundancies, semi-active redundancies, continuation of treatment in degraded performance, etc.

Temporal and Decision Hierarchy Concept

Not every Function of a system is performed at the same frequency. 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.

Figure 3. Temporal and Decision Hierarchy Levels (Faisandier, 2011)

Physical Architecture

Allocation of Functional Elements to Physical Elements and Partitioning

A complex system is structured in layers of systems and System Elements.

A system physical architecture is a structure that identifies the System Elements with their Physical Interfaces. 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 System Elements of the system perform the Functions, and the Physical Interfaces between system elements 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 System Elements that could perform the Functions of the system.

Criteria to Partition and Allocate Functions onto System Elements

Partitioning and allocation use criteria(provided by the list of system requirements) to find potential affinities between the functions. 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 system elements, and/or project or enterprise constraints.

The partitioning of functions stops when the designer is able to identify one or more system elements that could perform the function or a set of functions. Either the system element exists (re-usable), is re-purposed, or can be developed and technically implemented.

Designing Physical Candidate Architectures

These are arrangements of system elements that might potentially implement a function. Viable physical architectures implement all required system functions. The preferred physical architecture represents the optimum design. Simpler is better.

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. They allow the designer to master the handled elements, their interfaces, their interrelationships and to navigate in the architecture for impact analysis, or flow analysis for example.

Synthesis is done by grouping the leaf system elements 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 interfaces, modularity, testability of system elements, maintainability, compatibility of technologies, usability, consumption of means or resources, emerging properties control (see section further), etc.

Evaluating and Selecting the Preferred Alternative

The goal of physical design activities is to provide the "best" possible set of system elements and the “best” architecture. The value system for a design provides the basis for discrimination.

Design activity includes optimization to obtain a balance among Design Properties, cost, risks, etc. Generally, it is found that the architecture of a system is determined more strongly by non-functional requirements (performance, safety, security, environmental conditions, constraints, etc.) than by functions. There may be many ways to achieve functions but fewer ways to satisfying non-functional requirements.

Emergent Properties

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

The emergent properties of a system can be classified as in (Thome, B. 1993) - see Table 1.

Table 1 - Classification of emergent properties

Process Approach – Architectural Design

The architectural solution consists (as a minimum) of both a Functional / 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) associated to a set of Design Properties.

Transition from System Requirements to Physical Architecture

Design progresses from a 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 - and then allocates the elements of the Functional Architecture to the elements of potential Physical Architectures. 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, maintenance constraints, realization constraints, etc.) – see Figure 4.

Figure 4. Progressive Approach for Designing (Faisandier, 2011)

Iterations between Functional and Physical Architectures Design

The design activities require 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 loop should be the creation of a functional design 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 system elements that will perform these functions and to organize them into a physical architecture.

A second functional design loop considers the allocations of the Functions onto System Elements 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 system elements, and this, in turn, affects the physical design.

Eventually, other design loops produce an exhaustive and consistent functional and physical solution. During design, technological choices lead potentially to new functions, new input/output and control flows, and new physical interfaces. These new elements can conduct to the creation of new system requirements, called “derived requirements”, which become part of the requirements baseline.

Generic inputs and outputs of the design process

Because of the necessarily iterative execution of the design, the inputs and outputs of the process evolve incrementally. The generic inputs include the system requirements, the initial generic design patterns, the outcomes from the System Analysis, and the feedback from the System Verification and Validation.

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

Activities of the Process

Major activities and tasks performed during this process include:

Define the functional architecture of the system:
1. Identify Functions, Input/Output Flows, Operational Modes, Transition of 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 Input/Output Flows.
3. Allocate performance, effectiveness, and constraints requirements to Functions and to Input, Output, and control Flows.
4. Design candidate Functional Architectures using the previously defined elements to model Scenarios of functions and/or model sequences of Operational Modes and Transition of Modes. 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 and update the Functional Architecture as necessary.
5. Select the Functional Architecture by assessing the candidate Functional Architectures against assessment criteria (related to design properties and to requirements) and comparing them. Use System Analysis Process to perform the assessments – see System Analysis topic.
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.
Define the Physical Architecture of the system. That is:
1. Search for System Elements able to perform the Functions as well as Physical interfaces to carry the Input, Output, and control Flows; ensure the System Elements exist or must be engineered. Use partitioning method to perform this allocation (when it is impossible to identify a System Element that performs a Function, decompose the function till it is possible to identify implementable System Elements).
2. Design candidate Physical Architectures using the previously-defined elements to model networks of System Elements and Physical Interfaces. For each candidate, this requires the working out of a low-level Physical Architecture with the elementary System Elements. Because these are generally too numerous (ten or more) they have to be grouped into higher-level System Elements, also called systems. It is then possible to work out a high-level Physical Architecture with these systems and System Elements.
3. Select the most suitable Physical Architecture by assessing the candidate Physical Architectures against Assessment Criteria (related to non functional requirements) and comparing them. Use the System Analysis Process to perform the assessments – see System Analysis topic.
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.
Feedback the architectural design and the system requirements. That is:
1. Model the “allocated functional architecture” onto systems and system elements 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.
Prepare the technical elements for the acquisition of each system or system element:
1. Define the mission and objectives of the system or System Element from the Functions allocated to the system or System Element and the allocation of performance and effectiveness to the system or System Element, respectively.
2. Define the Stakeholder Requirements for this system or System Element (the concerned stakeholder being the System of Interest). Additional discussion on the development of the stakeholder requirements can be found in Mission Analysis and Stakeholders Requirements topic.
3. Establish traceability between the Stakeholder Requirements of the system or System Element and the design elements of the System of Interest. This allows the traceability of requirements between two layers of systems.

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 system element performs one or several functions of the functional architecture.
Every function has been allocated to one system element.
Every input/output flow is carried by a physical interface.
The components of the context of the System of Interest are linked to system elements of the System of Interest with physical interfaces.
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.

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, state machine diagrams (SysML), activity diagram (SysML) (OMG. 2010), Petri nets, etc.
Physical models such as physical block diagrams (PBD), SysML blocks (OMG. 2010), etc.

Practical Considerations about Architectural Design

Major pitfalls encountered with Architectural Design are presented in Table 5:

Table 5. Pitfalls with architectural design of systems

Proven practices with architectural design of systems are presented in Table 6:

Table 6. Proven practices with architectural design of system

Figure 7 - Requirements Traceability between the system-blocks. (Faisandier, 2011)

References

Citations

Alexander, Christopher; Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel. 1977. A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press.

Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY: McGraw-Hill.

OMG. 2010. OMG Systems Modeling Language – specification - version 1.2 – July 2010 - http://www.omg.org/technology/documents/spec_catalog.htm

Thome, B. 1993. Systems engineering, principles & practice of computer-based systems engineering. New York, NY: Wiley.

ISO/IEC. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).

Dereck Hitchins - http://www.hitchins.net/EmergenceEtc.pdf

Primary References

ANSI/IEEE. 2000. IEEE Recommended Practice for Architectural Description for Software-Intensive Systems. Institute of Electrical and Electronics Engineers, ANSI/IEEE Std 1471:2000.

INCOSE. 2010. INCOSE Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

ISO/IEC. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE FDIS 42010:2011 (E).

Maier, M., and E. Rechtin. 2009. The Art of Systems Architecting. 3rd ed. Boca Raton, FL, USA: CRC Press.

Additional References