Logical Architecture
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:
- Functions directly deduced from functional requirements and from interface requirements. They express the expected services of a system to meet its System Requirements.
- 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.
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.
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.
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:
- 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 generated thereby; deduce the necessary Functions which use, transform, move, and generate the Input-Output Flows.
- Assign System Requirements to functional and behavioral elements:
- Characterize formally Functions expression and their attributes through assignment of performance, effectiveness, and constraints requirements.
- Characterize formally Input, Output, and control Flows expression and their attributes through assignment of interface, effectiveness, operational, and constraints requirements.
- Establish traceability between System Requirements and these functional and behavioral elements.
- Design candidate Logical Architectures; for each candidate:
- 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.
- Integrate these Scenarios of functions in order to get a Behavioral Architecture of the system (a complete picture of the dynamic behavior).
- Decompose previous defined logical elements as necessary to look towards implementation.
- Assign and incorporate temporal constraints to previous defined logical elements such as: 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.
- Perform functional Failure Modes and Effects Analysis, and update the Logical Architecture elements as necessary.
- Synthesize the selected Independent Logical Architecture
- 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.
- 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).
- Verify and validate the selected Logical Architecture, correct as necessary, and establish traceability between System Requirements and Logical Architecture elements.
- Feedback logical design and System Requirements (this activity is performed after the Physical Architecture Design Process):
- 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
This process may create several artifacts such as:
- System Design Document (describes the selected logical and physical architectures)
- System Design Justification Document (traceability matrices and design choices)
This process handles the ontology elements of Table 1.
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.
Proven practices with Logical Architecture Design are presented in Table 3.
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.
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 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