Logical Architecture

The purpose of Logical Architecture Definition (or design) is to work out the functionality and behavior of the in-service system.

The 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. Other additional views are suggested in Architectural Frameworks; depending on the domain refer to DoDAF, TOGAF, etc.

Concepts and Principles

Functional Architecture / View

A functional architecture is a set of functions and their sub-functions that defines the 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, and/or information. These inputs and outputs are the flow items exchanged between functions. The general mathematic notation of a function is y = ƒ(x,t), where y and x may be vectors, t for time, 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 its derived requirements, as well as the corresponding inputs and outputs of those functions. There are, in general, two kinds of functions :

• Some functions are directly deduced from functional requirements and from interface requirements. They express the expected services of a system necessary to meet its system requirements.
• Other functions are derived and issued from the alternative solutions of physical architecture as the result of the architecture and design activities. They depend in particular on technology choice to implement the Logical Architecture elements.

Functions hierarchy/decomposition of functions – At the highest level of a hierarchy (Figure 1), it is possible to represent a system as a unique, central function (defined as the system's mission) similar to a "black box" (F0 in plan A-0). In order to understand, in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). 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 static functional hierarchy does not represent well how the flows of inputs and outputs are exchanged.

Figure 1. Decomposition of Functions (Faisandier 2012). Permission granted by Sinergy'Com.

Behavioral Architecture / View

A behavioral architecture is an arrangement of functions and their sub-functions, as well as interfaces (inputs and outputs), that defines the execution sequencing, conditions for control or data-flow, and its performance level to satisfy the System Requirements. 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 or an event, such as something moved to the “on” position, an alarm, 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 - see illustration on Figure 2 and Figure 3 below. A scenario of functions expresses the dynamic of an upper level function. A Behavioral Architecture model is developed 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 diagrams, developed with SysML (OMG. 2010), are suitable to represent scenarios of functions and Behavioral Architecture models.

Figure 2. Illustration of a Scenario (eFFBD) (Figure Developed for SEBoK)

Figure 3. Illustration of a scenario (Activity Diagram) (Figure Developed for SEBoK)

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 (see Figure 2). The transition from one mode to another 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 4. Scenario of Operational Modes (Faisandier 2012) Reprinted with permission of © Alain Faisandier.

Behavioral patterns - When defining scenarios or behavioral architectures, architects may recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models, more or less sophisticated depending on the complexity of the treatment. A pattern can be represented with different notations. Behavioral patterns could be classified into several categories, such as the following examples:

• basic patterns or constructs linking functions, such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, replication, etc.;
• complex patterns, such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, continuous monitoring with supervision, etc.; and
• failure detection, identification, and recovery (FDIR) patterns, such as passive redundancies, active redundancies, semi-active redundancies, treatments with reduced performance, etc.

Temporal Architecture / View

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

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

Temporal and decisional hierarchy concept – Not every Function of a system is performed at the same frequency. The frequency changes depending on the 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 cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing 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 either the level they occur or one level above. The goal is to ensure that 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 5. Temporal and Decision Hierarchy Levels (Faisandier 2012) Reprinted with permission of © Alain Faisandier

Process Approach

Purpose

The purpose of the Logical Architecture Definition (design) Process is to define, select, and synthesize a system’s Logical Architecture to enable it to satisfy and trade-off with the concerned System Requirements, as well as enable it to operate all operational scenarios of the complete system life.

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

Generic outputs are the selected independent Logical Architecture of the system, including at least views and models; such as functional, behavioral, and temporal views; a traceability matrix between Logical Architecture elements and System Requirements; and the rejected solutions’ elements.

Activities of the Process

Major activities and tasks performed during this process include the following:

• Identify and analyze functional and behavioral elements:
  • identify functions, input-output flows, operational modes, transition of modes, and operational scenarios from System Requirements by analyzing the functional, interface, and operational requirements:
    • define necessary inputs and controls (energy, material, and data flows) to each function and outputs that result, deduce the necessary Functions which use, transform, move, and generate the Input-Output Flows.
• Assign System Requirements to functional and behavioral elements:
  • formally characterize functions expression and their attributes through the assignment of performance, effectiveness, and constraints requirements; study in particular temporal aspects from requirements to assign duration, response time, frequency to functions;
  • formally characterize input, output, and control Flows expression and their attributes through assignment of interface, effectiveness, operational, temporal and constraints requirements; and
  • establish traceability between System Requirements and these functional and behavioral elements.
• Define candidate Logical Architectures. For each candidate:
  • analyze operational modes as stated in the System Requirements (if any) and/or use previously defined elements to model sequences of operational modes and the transition of Modes. Eventually decompose modes into sub-modes, then establish for each operational mode one or several scenarios of functions recognizing and/or using relevant generic behavioral generic patterns;
  • integrate these Scenarios of functions in order to get a Behavioral Architecture model of the system (a complete picture of the dynamic behavior);
  • decompose previously defined logical elements as necessary to look towards implementation;
  • assign and incorporate temporal constraints to previously defined logical elements, such as the period of time, duration, frequency, response-time, timeout, stop conditions, etc.;
  • 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 model;
  • perform functional failure modes and effects analysis, and update the logical architecture elements as necessary;
  • execute the models with simulators (when possible) and tune these models to obtain expected characteristics.
• Synthesize the selected independent Logical Architecture:
  • select the Logical Architecture by assessing the candidate Logical Architectures against assessment criteria (related to System Requirements) and compare them, use the System Analysis Process to perform assessments (see the System Analysis Topic). This selected Logical Architecture is called “Independent Logical Architecture” because, as much as possible, it is independent of implementation decisions;
  • identify and define derived logical architecture elements created for the necessity of design and corresponding derived System Requirements, and assign these requirements to the appropriate system (current studied system or external systems); and
  • verify and validate the selected Logical Architecture models (using executable models as possible), make corrections as necessary, and establish traceability between System Requirements and logical architecture elements.
• Feedback Logical Architecture definition and System Requirements (this activity is performed after the Physical Architecture Definition (design) Process):
  • model the “Allocated Logical Architecture” to systems and System Elements, if such a representation is possible, and add any functional, behavioral, and temporal elements as needed to synchronize functions and treatments; and
  • 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

• System Design Documents (describe the selected Logical and Physical Architectures) and
• System Design Justification Documents (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. (SEBoK Original)

Element	Definition Attributes (examples)
Function	A task, action, or activity performed to achieve a desired outcome. A function uses input flows and generates output flows. Identifier; name description; duration (execution time).
I/O Flow	An input or an output or a trigger of a function (used for input-output flow, control flow). An I/O flow can be made of material and/or energy and/or information. Identifier; nage; description; type (input, output, trigger); initial quantity; quantity consumed or produced; preconditions; priority; precision; accuracy; concurrency
Operational Mode	An operational situation/configuration of a system characterized by its active functions (synonym of state). Inside an operational mode the system can perform specific operational scenarios, and so activate the corresponding functions. Identifier; name description
Scenario	A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service. Identifier; name; description
Rationale	Argument that provides the justification for the selection of an engineering element. Identifier; name; description (rational reasons for relevance of the element)
Risk	An event having a probability of occurrence and a gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat. Identifie; name; description; status

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 the transition of modes can be used alternatively, depending on the used modeling techniques.

Methods and Modeling Techniques

Logical Architecture descriptions use modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models (some are executable 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 diagrams, class diagrams, data flow diagrams, etc.; and
• dynamic models such as state-transition diagrams, state-charts, eFFBDs, state machine diagrams (SysML), activity diagrams (SysML) (OMG. 2010), petri nets, etc.

Depending on the type of domain (Defense, Enterprise), Architecture Frameworks such as DoDAF, TOGAF, Zachman, etc. provide descriptions that can help to represent additional aspects/views of architectures - see section 'Enterprise Architecture Frameworks & Methodologies' in Enterprise Systems Engineering Key Concepts. See also practical means for using general templates in [1]

Practical Considerations

Major pitfalls encountered with Logical architecture design are presented in Table 2.

Table 2. Pitfalls with Logical Architecture Design. (SEBoK Original)

Pitfall	Description
Inputs for design	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.
Decomposition too deep	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 int he functional architecture of the current system block.
Not considering inputs and outputs together with functions	A current mistake is to consider only the actions supported by functions and decomposing them, but forgetting the inputs and the outputs, or considering them too late. Inputs and outputs are integrated parts of a function.
Considering static decomposition of functions only	Static function decomposition is the smallest functional design task and answers the question, "How is this done?" The purpose of the status decomposition is to facilitate the management or navigation through the list of functions. The static decomposition should be established only when scenarios have been created and the logical design almost finished.
Mixing governance, management, and operation	Governance (strategic monitoring), management (tactical monitoring), and basic operations are often mixed in complex systems. Functional design should deal with behavioral design and with temporal design.

Proven practices with logical architecture Design are presented in Table 3.

Table 3. Proven Practices with Logical Architecture Design. (SEBoK Original)

Practice	Description
Constitute scenarios of functions	Before constituting a decomposition tree of functions, model the behavior of the system establishing scenarios of functions; decompose functions as scenarios of sub-functions.
Analysis and synthesis cycles	When facing a system that seems to contain a lot of functions, try to synthesize functions into higher abstraction levels of functions with the help of criteria. Do not perform analysis only, but small cycles of analysis (decomposition) and synthesis. The technique of using scenarios includes this design practice.
Alternate functional and behavioral views	A function (action verb; e.g. "to move") and its state of execution/operational mode (e.g. "moving") are two similar and complimentary views. Use this to consider a behavioral view of the system that transits from one operational mode to another.
Order to create a scenario of functions	When creating a scenario of functions, it is more efficient from a mouthed viewpoint to first establish the (control) flow of functions, then to add input and output flows, and finally to add triggers or signals for synchronization.

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).

www.iso-architecture.org/42010/templates

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. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com

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 > 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