Difference between revisions of "Logical Architecture"

From SEBoK
Jump to navigation Jump to search
Line 1: Line 1:
−
Architectural design explores, defines, and formalizes solutions that meet the system requirements and selects the optimal solution while taking system requirements into account.  
+
The notion of system is a practical mean to create, design or re-design Products, Services or Enterprises. A today complex system is mainly characterized by its dynamic aspects, its [[Behavior (glossary)|behavior]] facing external elements or reacting to events from its context of use. [[Operational Scenario (glossary)|Operational Scenarios]] are basic elements to express or describe the behavior of the system, and Scenarios are composed in particular of actions or functions.
  
−
==Definition and Purpose of Architectural Design==
+
====Definition and purpose====
  
−
The architectural design of a system creates a solution based on principles and concepts logically related and consistent to each other that possess properties and characteristics that satisfy a problem. It is implementable within a predefined set of system requirements.
+
The purpose of Logical Architecture Design is to work out functionality and behavior of the in-service system.
  
−
The properties and characteristics are classified and modeled while activities are designed that take into account views such as functional, temporal, behavioral, performance, operational, environmental, and structural. See the [[Fundamentals of System Definition]] section for more information. A design-properties-oriented classification (see [[System Requirements]]) facilitates these views.
+
A [[Logical Architecture (glossary)]] of a system is composed of a set of related technical concepts and principles that support the logical operation of the system. It is described with views corresponding to viewpoints; and as a minimum includes a [[Functional Architecture (glossary) | Functional Architecture]] / view, a [[Behavioral Architecture (glossary)]] / view and a [[Temporal Architecture (glossary)]] / view.
  
−
Considerations include:
+
==Concepts and Principles==
  
−
*'''Functional, behavioral, and temporal views''' – The functional description (independent from the implementation technologies) is essential.  A temporal and decision monitoring model  supplements the functional and behavioral models to organize the in-service management of the system in order to achieve its [[Mission (glossary)|mission (glossary)]] and [[Purpose (glossary)| purpose (glossary)]] permanently.
+
===Functional Architecture / view===
  
−
*'''Performance, operational, environmental, and structural views''' – The projection or allocation of functional, behavioral, and temporal models onto a [[Physical Architecture (glossary)| physical architecture (glossary)]] (dependent on the implementation technologies) includes the definition of systems, [[System Element (glossary)|system elements (glossary)]], and physical connections ([[Physical Interface (glossary)|physical interfaces (glossary)]]) that together own [[Design Property (glossary)|design properties (glossary)]], such as:
+
'''Definition''' - A Functional Architecture is a set of functions and their sub-functions that defines transformations performed by the system to achieve its mission.
−
**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, training, etc.); and
 
−
**environmental characteristics (heatproof, shockproof, electrical resistance, radiation resistance, etc.).
 
  
−
*'''Confidence in the solution''' – The confidence obtained by correctly designing the architecture and finding the optimal solution given the complete set of system requirements is an essential aspect related to the assessment of the properties and characteristics of the system that are performed during design (refer to [[System Analysis]] topic for more information).
+
'''Concept of Function and Input-output Flow''' - 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 functions. The general mathematic notation of a function is y = ƒ(x,t) and can be represented graphically.
  
−
Various architectural models should cover the properties  listed above; multiple models can be used to represent all properties. An issue in today's society concerns the consistency between all models attempting to represent the global solution.
+
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:
  
−
==Principles Governing Architectural Design==
+
#Functions directly deduced from functional requirements and from interface requirements. They express the expected services of a system to meet its [[System Requirement (glossary) | System Requirements]].
 +
#Derived functions issued from the alternative solutions of [[Physical Architecture (glossary)]] as the result of the design. They depend on technology choice to implement the Logical Architecture elements.
  
−
Architectural design relies on known concepts and/or patterns such as interface, function, input-output-control flow, dynamics, temporal and decision hierarchy, allocation and partitioning, emerging properties, etc.
+
'''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. 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 physical solutions are known, feasible or possible to imagine. But a Functional hierarchy does not represent exchanged flows of inputs and outputs.
  
−
The principles are well described in ''The Engineering Design of Systems: Models and Methods'' (Buede, 2009) and ''The Art of Systems Architecting'' (Maier and Rechtin, 2009).
 
  
−
==Process Approach – Architectural Design==
+
[[File:SEBoKv075_KA-SystDef_Decomposition_of_Functions.png|400px|thumb|center|Figure 1. Decomposition of Functions (Faisandier 2012) Reprinted with permission of © Alain Faisandier.]]
  
−
As a minimum, the architectural solution consists of both a functional/logical architecture (expressed as a set of functions, scenarios, and/or operational models) and a physical architecture  (expressed as a set of systems with system elements physically connected between them) associated to a set of design properties.
+
===Behavioral Architecture / view===
  
−
====Transition from System Requirements to Physical Architecture====
+
'''Definition''' - A Behavioral Architecture is an arrangement of functions and their sub-functions, and interfaces (inputs, outputs) which defines the execution sequencing, conditions for control or data-flow and its performance level to satisfy the System Requirements (adapted from ISO/IEC 26702). A behavioral architecture can be described as a set of inter-related scenarios of functions and/or of operational modes.
  
−
As Figure 1 illustrates, design progresses from a system requirements baseline (representing the problem from a supplier/designer point of view while remaining as independent of technology as possible) 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 (e.g., environmental conditions, maintenance constraints, realization constraints, etc.).  
+
'''Concept of control (trigger)''' - A 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.
  
−
[[File:SEBoKv05_KA-SystDef_Progressive_Approach_for_Designing.png|thumb|500px|center|Figure 1. Progressive Approach for Designing (Faisandier 2011) Reprinted with permission of © Alain Faisandier.]]
+
'''Concept of 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. A Behavioral Architecture is worked out with Scenarios for each level of the functional hierarchy and for each level of the system hierarchy.
  
−
====Iterations Between Functional and Physical Architectures Design====
+
Modeling techniques using diagrams such as Functional Flow Block diagrams (FFBD) (Oliver, Kelliher, and Keegan. 1997) or Activity Diagram of SysML (OMG. 2010) are suitable to represent Scenarios of functions and Behavioral Architectures.
  
−
Design activities require iterations looping from functional to physical design and vice versa until both the functional and physical architectures are exhaustive and consistent.
+
'''Concept of 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. This view is called 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.
  
−
The first design loop creates a functional design based on the nominal scenarios. The goal is to actualize the first model that could potentially 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 functions onto system elements and the derived functions coming from physical solution choices. This loop also supplements the initial functional model by introducing other altered models, failed analyses, and every operational requirement not performed in the first loop. The derived functions must, in their turn, be allocated to system elements and this, in turn, affects the physical design.
+
[[File:SEBoKv075_KA-SystDef_Scenario_of_Operational_Modes.png|400px|thumb|center|Figure 2. Scenario of Operational Modes (Faisandier 2012) Reprinted with permission of © Alain Faisandier.]]
  
−
Eventually, other design loops produce an exhaustive and consistent functional and physical solution. During design, technological choices potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements conduct the creation of new system requirements called “derived requirements” that become part of the requirements baseline.
+
'''Behavioral design patterns''' - When designing Scenarios or Behavioral Architectures, architects may recognize and can use known models to perform the expected transformations and behaviors. Patterns are generic basic models, more or less sophisticated depending of the complexity of the treatment. A pattern can be represented with different notations. Behavioral design patterns could be classified into several categories, such as examples:
  
−
====Generic Inputs and Outputs of the Design Process====
+
* Basic patterns or constructs linking functions: sequence, iteration, selection, concurrence, multiple exits, loop with exit, replication, etc.
 +
* Complex patterns: monitor a treatment, exchange a message, Man Machine Interface, modes monitoring, real-time monitoring of processes, queue management, continuous monitoring with supervision, etc.
 +
* Failure detection, identification, recovery (FDIR) patterns: passive redundancies, active redundancies, semi-active redundancies, treatment with reduced performance, etc.
  
−
The inputs and outputs of the design process evolve incrementally because of the necessity of iterative execution in the process. The generic inputs include the system requirements, initial generic design patterns, outcome from the [[System Analysis]], and feedback from the [[System Verification]] and [[System Validation]].
+
===Temporal Architecture / view===
 +
 +
'''Definition''' - A Temporal Architecture is a temporal classification of the functions of a system according to their frequency level of execution. Temporal Architecture includes definition of synchronous and asynchronous aspects of functions.
  
−
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 elements from rejected solutions.
+
The decision monitoring inside a system follows the same temporal classification because decisions are related to monitoring of functions.
 +
 
 +
'''Temporal and decisional hierarchy concept''' – Not every Function of a system is performed at the same frequency. It changes depending on time and 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.
 +
 
 +
In particular, "Real-time" systems and "Command-control" systems combine cyclic operations (synchronous) and factual aspects (asynchronous). Cyclic operations consist of sharing out the execution of functions according to frequencies, which depend on constraints of capture, or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:
 +
 
 +
* Disturbances on high frequencies (bottom of Figure 3) - decisions are made at the level they occur or at the immediate upper level. The goal is to ensure disturbances do not go up in 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 operations concerns breakdowns or failures.
 +
* Changes happening on low frequencies (top of Figure 3) - decisions of change are made at the upper levels. The goal is to transmit them towards bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.
 +
 
 +
[[File:SEBoKv05 KA-SystDef Temporal and decision hierarchy levels.png|400px|thumb|center|Figure. Temporal and Decision Hierarchy Levels (Faisandier 2012) Reprinted with permission of © Alain Faisandier]]
 +
 
 +
==Process Approach==
 +
 
 +
===Purpose===
 +
 
 +
The purpose of the Logical Architecture Design Process is to define, select and synthesize a system logical architecture able to satisfy and trade-off the concerned System Requirements, and able to operate all operational scenarios of the complete system life.
 +
 
 +
Because of the necessarily iterative execution of the design, inputs and outputs of the process evolve incrementally. Generic inputs include System Requirements, generic design patterns that designers identify and use to answer requirements, outcomes from System Analysis process, and feedback from System Verification and Validation processes.
 +
 
 +
Generic outputs are the selected Independent Logical Architecture of the system including at minimum views and models such as functional, behavioral and temporal views, traceability matrix between logical architecture elements and System Requirements, the rejected solutions elements.
  
 
===Activities of the Process===
 
===Activities of the Process===
Line 57: Line 75:
 
Major activities and tasks performed during this process include:
 
Major activities and tasks performed during this process include:
  
−
#'''Define the functional architecture''' of the system, that is:
+
# Identify and analyze functional and behavioral elements:  
−
##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.
+
## Identify [[Function (glossary) | Functions]], [[Input-Output Flow (glossary) | Input-Output Flows]], [[Operational Mode (glossary) | Operational Modes]], [[Transition of Modes (glossary) | Transition of Modes]], and [[Operational Scenario (glossary) | Operational Scenarios]] from System Requirements by analyzing the functional, interface, and operational requirements.
−
##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.
+
## Define necessary inputs and controls (energy, material, and data flows) to each Function and outputs generated thereby; deduce the necessary Functions which use, transform, move, and generate the Input-Output Flows.
−
##Allocate performance, effectiveness, and constraints requirements to functions and to input, output, and control flows.
+
# Assign System Requirements to functional and behavioral elements:
−
##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.
+
## Characterize formally Functions expression and their attributes through assignment of performance, effectiveness, and constraints requirements.
−
##Select the functional architecture by assessing the candidate functional architectures against [[Assessment Criterion (glossary)| assessment criterion (glossary)]], as related to design properties and to requirements, and compare them. Use a system analysis process to perform the assessments (see [[System Analysis]] topic).
+
## Characterize formally Input, Output, and control Flows expression and their attributes through assignment of interface, effectiveness, operational, and constraints requirements.
−
##Synthesize the selected functional architecture and verify its dynamic behavior. Identify the derived functional elements created for the necessity of design.
+
## Establish traceability between System Requirements and these functional and behavioral elements.
−
##Establish traceability between system requirements and functional architecture elements.
+
#Design candidate Logical Architectures; for each candidate:
−
#'''Define the physical architecture''' of the system, that is:
+
##Analyze Operational Modes as stated in System Requirements (if any), and/or use previously defined elements to model sequences of Operational Modes and Transition of Modes. Decompose eventually Modes in sub modes. Then establish for each Operational Mode one or several Scenarios of functions recognizing and/or using relevant generic behavioral generic patterns.
−
##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 until it is possible).
+
##Integrate these Scenarios of functions in order to get a Behavioral Architecture of the system (a complete picture of the dynamic behavior).
−
##Design potential physical architectures using the previously-defined elements to model networks of system elements and physical interfaces. For each potential 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.
+
##Decompose previous defined logical elements as necessary to look towards implementation.  
−
##Select the most suitable physical architecture by assessing the candidate physical architectures against assessment criteria (related to non-functional requirements) and compare them. Use the system analysis process to perform the assessments (see the [[System Analysis]] topic).
+
##Assign and incorporate temporal constraints to previous defined logical elements such as: period of time, duration, frequency, response-time, timeout, stop conditions, etc.
−
##Synthesize the selected physical architecture; verify 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.
+
##Define several levels of execution frequency for Functions that correspond to levels of decision in order to monitor system operations. Prioritize processing on this time basis, and share out Functions among those execution frequency levels to get a Temporal Architecture.
−
#'''Feedback the architectural design and the system requirements''', that is:  
+
##Perform functional Failure Modes and Effects Analysis, and update the Logical Architecture elements as necessary.
−
##Model the “allocated functional architecture” onto systems and system elements if such a representation is possible.
+
#Synthesize the selected Independent Logical Architecture
−
##Define the derived functional and physical elements induced by the selected functional and physical architectures. Define the corresponding derived requirements and allocate them on the appropriate functional and physical architectures elements. Incorporate these derived requirements in the requirements baselines of the systems impacted.
+
##Select the Logical Architecture by assessing the candidate Logical Architectures against Assessment Criteria (related to Design Properties and to System Requirements) and comparing them. Use the System Analysis Process to perform assessments – see [[System Analysis]] topic. This selected Logical Architecture is called “Independent Logical Architecture”, because it is as much as possible independent of implementation decisions.
−
#'''Prepare the technical elements for the acquisition of each system or system element''', that is:
+
##Identify and define derived logical architecture elements created for the necessity of design, and corresponding derived System Requirements. Assign these requirements to the appropriate system (current studied system or external systems).
−
##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.
+
##Verify and validate the selected Logical Architecture, correct as necessary, and establish traceability between System Requirements and Logical Architecture elements.
−
##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 the [[Mission Analysis]] and [[Stakeholder Needs and Requirements]] topics.)
+
#Feedback logical design and System Requirements (this activity is performed after the Physical Architecture Design Process):
−
##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.
+
##Model the “Allocated Logical Architecture” to systems and System Elements if such a representation is possible. Add any functional, behavioral and temporal elements as needed to synchronize Functions and treatments.
 +
##Define or consolidate derived logical and physical elements induced by the selected logical and physical architectures. Define corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements in requirements baselines of impacted systems.
 +
 
 +
===Artifacts and Ontology Elements===
  
−
===Checking and Correctness of Architectural Design===
+
This process may create several artifacts such as:
  
−
The main items to be checked during design concern functional and physical architectures.
+
#System Design Document (describes the selected logical and physical architectures)
 +
#System Design Justification Document (traceability matrices and design choices)
  
−
Concerning functional design, check that:
+
This process handles the ontology elements of Table 1.
−
*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:
+
[[File:SEBoKv05 KA-SystDef ontology elements Functional Design.png|600px|thumb|center|Table 1. Main ontology elements as handled within Logical Architecture Design (Figure Developed for BKCASE)]]
−
*Every system element performs one or several functions of the functional architecture.
+
 
−
*Every function has been allocated to one system element.
+
Note: The element Scenario is used for Logical Architecture, because as defined a Scenario includes a large set of functional, behavioral and temporal elements. Sequences of Operational Modes and Transition of Modes can be used alternatively depending of the used modeling techniques.
−
*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 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===
 
===Methods and Modeling Techniques===
  
−
Design uses modeling techniques that are grouped under various types of models. Several methods have been developed to support the following types of models:
+
Logical Architecture 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, system analysis and real time, enhanced functional flow block diagrams (eFFBD), function analysis system technique, 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, activity diagrams (OMG 2010), Petri nets, etc.
 
−
*Physical models, such as physical block diagrams, [[Acronyms|SysML]] blocks (OMG 2010), etc.
 
−
 
 
−
==Practical Considerations about Architectural Design==
 
  
−
Major pitfalls encountered with architectural design are presented in Table 1.
+
* 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.
  
−
<center>'''Table 1. Pitfalls with architectural design of systems (Figure Developed for BKCASE)'''</center>
+
==Practical Considerations==
−
[[File:SEBoKv05_KA-SystDef_Pitfalls_architectural_design.png|700px|center]]
 
  
−
Proven practices with architectural design of systems are presented in Table 2.
+
Major pitfalls encountered with Logical Architecture Design are presented in Table 2.
  
−
<center>'''Table 2. Proven practices with architectural design of system (Figure Developed for BKCASE)'''</center>
+
[[File:SEBoKv075_KA-SystDef_Pitfalls_Logical_Design.png|600px|thumb|center|Table 2. Pitfalls with Logical Architecture Design (Figure Developed for BKCASE)]]
−
[[File:SEBoKv05_KA-SystDef_practices_architectural_design.png|thumb|700px|center]]
 
  
−
[[File:SEBoKv05_KA-SystDef_Requirements_Traceability_between_system-blocks.png|thumb|500px|center|Figure 2. Requirements Traceability between the system-blocks (Faisandier 2011)Reprinted with permission of © Alain Faisandier.]]
+
Proven practices with Logical Architecture Design are presented in Table 3.
  
−
Note: Figure 2: Traceability graph referenced in Table 2, Proven Practices, above.
+
[[File:SEBoKv075_KA-SystDef_Practices_Logical_Design.png|600px|thumb|center|Table 3. Proven Practices with Logical Architecture Design (Figure Developed for BKCASE)]]
  
 
==References==  
 
==References==  

Revision as of 14:59, 28 February 2012

The notion of system is a practical mean to create, design or re-design Products, Services or Enterprises. A today complex system is mainly characterized by its dynamic aspects, its behavior facing external elements or reacting to events from its context of use. Operational Scenarios are basic elements to express or describe the behavior of the system, and Scenarios are composed in particular of actions or functions.

Definition and purpose

The purpose of Logical Architecture Design is to work out functionality and behavior of the in-service system.

A logical architecture of a system is composed of a set of related technical concepts and principles that support the logical operation of the system. It is described with views corresponding to viewpoints; and as a minimum includes a Functional Architecture / view, a behavioral architecture / view and a temporal architecture / view.

Concepts and Principles

Functional Architecture / view

Definition - A Functional Architecture is a set of functions and their sub-functions that defines transformations performed by the system to achieve its mission.

Concept of Function and Input-output Flow - 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 functions. The general mathematic notation of a function is y = ƒ(x,t) and can be represented graphically.

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. Functions directly deduced from functional requirements and from interface requirements. They express the expected services of a system to meet its System Requirements.
  2. Derived functions issued from the alternative solutions of physical architecture as the result of the design. They depend on technology choice to implement the Logical Architecture elements.

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. 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 physical solutions are known, feasible or possible to imagine. But a Functional hierarchy does not represent exchanged flows of inputs and outputs.


File:SEBoKv075 KA-SystDef Decomposition of Functions.png
Figure 1. Decomposition of Functions (Faisandier 2012) Reprinted with permission of © Alain Faisandier.

Behavioral Architecture / view

Definition - A Behavioral Architecture is an arrangement of functions and their sub-functions, and interfaces (inputs, outputs) which defines the execution sequencing, conditions for control or data-flow and its performance level to satisfy the System Requirements (adapted from ISO/IEC 26702). A behavioral architecture can be described as a set of inter-related scenarios of functions and/or of operational modes.

Concept of control (trigger) - A 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.

Concept of 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. A Behavioral Architecture is worked out with Scenarios for each level of the functional hierarchy and for each level of the system hierarchy.

Modeling techniques using diagrams such as Functional Flow Block diagrams (FFBD) (Oliver, Kelliher, and Keegan. 1997) or Activity Diagram of SysML (OMG. 2010) are suitable to represent Scenarios of functions and Behavioral Architectures.

Concept of 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. This view is called 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.


Figure 2. Scenario of Operational Modes (Faisandier 2012) Reprinted with permission of © Alain Faisandier.

Behavioral design patterns - When designing Scenarios or Behavioral Architectures, architects may recognize and can use known models to perform the expected transformations and behaviors. Patterns are generic basic models, more or less sophisticated depending of the complexity of the treatment. A pattern can be represented with different notations. Behavioral design patterns could be classified into several categories, such as examples:

  • Basic patterns or constructs linking functions: sequence, iteration, selection, concurrence, multiple exits, loop with exit, replication, etc.
  • Complex patterns: monitor a treatment, exchange a message, Man Machine Interface, modes monitoring, real-time monitoring of processes, queue management, continuous monitoring with supervision, etc.
  • Failure detection, identification, recovery (FDIR) patterns: passive redundancies, active redundancies, semi-active redundancies, treatment with reduced performance, etc.

Temporal Architecture / view

Definition - A Temporal Architecture is a temporal classification of the functions of a system according to their frequency level of execution. Temporal Architecture includes definition of synchronous and asynchronous aspects of functions.

The decision monitoring inside a system follows the same temporal classification because decisions are related to monitoring of functions.

Temporal and decisional hierarchy concept – Not every Function of a system is performed at the same frequency. It changes depending on time and 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.

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

  • Disturbances on high frequencies (bottom of Figure 3) - decisions are made at the level they occur or at the immediate upper level. The goal is to ensure disturbances do not go up in 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 operations concerns breakdowns or failures.
  • Changes happening on low frequencies (top of Figure 3) - decisions of change are made at the upper levels. The goal is to transmit them towards bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.
Figure. Temporal and Decision Hierarchy Levels (Faisandier 2012) Reprinted with permission of © Alain Faisandier

Process Approach

Purpose

The purpose of the Logical Architecture Design Process is to define, select and synthesize a system logical architecture able to satisfy and trade-off the concerned System Requirements, and able to operate all operational scenarios of the complete system life.

Because of the necessarily iterative execution of the design, inputs and outputs of the process evolve incrementally. Generic inputs include System Requirements, generic design patterns that designers identify and use to answer requirements, outcomes from System Analysis process, and feedback from System Verification and Validation processes.

Generic outputs are the selected Independent Logical Architecture of the system including at minimum views and models such as functional, behavioral and temporal views, traceability matrix between logical architecture elements and System Requirements, the rejected solutions elements.

Activities of the Process

Major activities and tasks performed during this process include:

  1. Identify and analyze functional and behavioral elements:
    1. Identify Functions, Input-Output Flows, Operational Modes, Transition of Modes, and Operational Scenarios from System Requirements by analyzing the functional, interface, and operational requirements.
    2. Define necessary inputs and controls (energy, material, and data flows) to each Function and outputs generated thereby; deduce the necessary Functions which use, transform, move, and generate the Input-Output Flows.
  2. Assign System Requirements to functional and behavioral elements:
    1. Characterize formally Functions expression and their attributes through assignment of performance, effectiveness, and constraints requirements.
    2. Characterize formally Input, Output, and control Flows expression and their attributes through assignment of interface, effectiveness, operational, and constraints requirements.
    3. Establish traceability between System Requirements and these functional and behavioral elements.
  3. Design candidate Logical Architectures; for each candidate:
    1. Analyze Operational Modes as stated in System Requirements (if any), and/or use previously defined elements to model sequences of Operational Modes and Transition of Modes. Decompose eventually Modes in sub modes. Then establish for each Operational Mode one or several Scenarios of functions recognizing and/or using relevant generic behavioral generic patterns.
    2. Integrate these Scenarios of functions in order to get a Behavioral Architecture of the system (a complete picture of the dynamic behavior).
    3. Decompose previous defined logical elements as necessary to look towards implementation.
    4. Assign and incorporate temporal constraints to previous defined logical elements such as: period of time, duration, frequency, response-time, timeout, stop conditions, etc.
    5. Define several levels of execution frequency for Functions that correspond to levels of decision in order to monitor system operations. Prioritize processing on this time basis, and share out Functions among those execution frequency levels to get a Temporal Architecture.
    6. Perform functional Failure Modes and Effects Analysis, and update the Logical Architecture elements as necessary.
  4. Synthesize the selected Independent Logical Architecture
    1. Select the Logical Architecture by assessing the candidate Logical Architectures against Assessment Criteria (related to Design Properties and to System Requirements) and comparing them. Use the System Analysis Process to perform assessments – see System Analysis topic. This selected Logical Architecture is called “Independent Logical Architecture”, because it is as much as possible independent of implementation decisions.
    2. Identify and define derived logical architecture elements created for the necessity of design, and corresponding derived System Requirements. Assign these requirements to the appropriate system (current studied system or external systems).
    3. Verify and validate the selected Logical Architecture, correct as necessary, and establish traceability between System Requirements and Logical Architecture elements.
  5. Feedback logical design and System Requirements (this activity is performed after the Physical Architecture Design Process):
    1. Model the “Allocated Logical Architecture” to systems and System Elements if such a representation is possible. Add any functional, behavioral and temporal elements as needed to synchronize Functions and treatments.
    2. Define or consolidate derived logical and physical elements induced by the selected logical and physical architectures. Define corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements in requirements baselines of impacted systems.

Artifacts and Ontology Elements

This process may create several artifacts such as:

  1. System Design Document (describes the selected logical and physical architectures)
  2. System Design Justification Document (traceability matrices and design choices)

This process handles the ontology elements of Table 1.

Table 1. Main ontology elements as handled within Logical Architecture Design (Figure Developed for BKCASE)

Note: The element Scenario is used for Logical Architecture, because as defined a Scenario includes a large set of functional, behavioral and temporal elements. Sequences of Operational Modes and Transition of Modes can be used alternatively depending of the used modeling techniques.

Methods and Modeling Techniques

Logical Architecture 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.

Practical Considerations

Major pitfalls encountered with Logical Architecture Design are presented in Table 2.

Table 2. Pitfalls with Logical Architecture Design (Figure Developed for BKCASE)

Proven practices with Logical Architecture Design are presented in Table 3.

Table 3. Proven Practices with Logical Architecture Design (Figure Developed for BKCASE)

References

Works Cited

Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. 1977. A Pattern Language: Towns, Buildings, Construction. New York, NY, USA: Oxford University Press.

Buede, D.M. 2009. The engineering design of systems: Models and methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Boston, MA, USA: Addison-Wesley.

Maier, M., and E. Rechtin. 2009. The art of systems architecting. 3rd ed. Boca Raton, FL, USA: CRC Press.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY, USA: 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, USA: Wiley.

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

Primary References

ANSI/IEEE. 2000. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.

INCOSE. 2011. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

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

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

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

Additional References

Faisandier, A. 2011 (unpublished). Engineering and Architecting Multidisciplinary Systems.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.

Thome, B. 1993. Systems Engineering, Principles & Practice of Computer-Based Systems Engineering. New York, NY, USA: Wiley.

<- Previous Article | Parent Article | Next Article ->


Comments from 0.5 Wiki

<html> <iframe src="http://bkcasewiki.org/index.php?title=Talk:Architectural_Design&printable=yes" width=825 height=200 frameborder=1 scrolling=auto> </iframe> </html>


SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Logical_Architecture&oldid=31112"