Difference between revisions of "Physical Architecture"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(95 intermediate revisions by 9 users not shown)
Line 1: Line 1:
The purpose of physical architecture definition (or [[Design (glossary) |design]]) is to create a physical, concrete solution that accommodates the [[Logical Architecture (glossary)|logical architecture]] and satisfies and trades-off system requirements. Once a logical architecture is defined (see [[Architectural Design: Logical]]), concrete physical elements have to be identified that can support functional, behavioral, and temporal features as well as expected properties of the system deduced from non-functional system requirements (for example constraint of replacement of obsolescence, and/or continued product support).
+
----
 +
'''''Lead Authors:''''' ''Alan Faisandier, Rick Adcock''
 +
----
 +
Physical Architecture Model Development may be used as a task of the activity "Develop candidate architectures models and views," or a sub-process of the [[System Architecture Design Definition]] process. Its purpose is to elaborate models and views of a physical, concrete solution that accommodates the {{Term|Logical Architecture (glossary)|logical architecture}} model and satisfies and trades-off system requirements. Once a logical architecture model is defined (see [[Logical Architecture Model Development]]), concrete physical elements have to be identified that can support functional, behavioral, and temporal features as well as the expected properties of the system deduced from non-functional system requirements (e.g. constraint of replacement of obsolescence, and/or continued product support).
  
A [[Physical Architecture (glossary)|physical architecture]] is an arrangement of physical elements ([[System Element (glossary)|system elements]] and [[Physical Interface (glossary)|physical interfaces]]) which provides the designed solution for a [[Product (glossary)|product]], [[Service (glossary)|service]], or [[Enterprise (glossary)|enterprise]]. It is intended to satisfy logical architecture elements and system requirements (ISO/IEC 26702 2007). It is implementable through technological system elements. [[System Requirements|System requirements]] are allocated to both the [[Logical Architecture (glossary)|logical]] and physical architectures. The global system architecture is assessed with [[System Analysis|system analysis]] and when achieved becomes the basis for [[System Realization|system realization]].
+
A {{Term|Physical Architecture (glossary)|physical architecture}} model is an arrangement of physical elements, ({{Term|System Element (glossary)|system elements}} and {{Term|Physical Interface (glossary)|physical interfaces}}) that provides the solution for a {{Term|Product (glossary)|product}}, {{Term|Service (glossary)|service}}, or {{Term|Enterprise (glossary)|enterprise}}. It is intended to satisfy logical architecture elements and system requirements ISO/IEC/IEEE 26702 (ISO 2007). It is implementable through technological system elements. {{Term|System Requirement (glossary)|System requirements}} are allocated to both the logical and physical architectures. The resulting system architecture is assessed with {{Term|System Analysis (glossary)|system analysis}} and when completed becomes the basis for {{Term|System Realization (glossary)|system realization}}.
  
In many cases, particularly when multiple systems are to be designed to a common physical architecture, one of the drivers for the physical architecture may be interface standards. In fact these physical interfaces may well be one of the most important concerns for these systems.  It is quite possible that such interface standards are mandated at a high level in the System Requirements. On the other hand it is equally possible for standards to be derived at the Physical Architecture Design phase and these can be critical enablers for desirable engineering outcomes such as families of systems, technology insertion, interoperability and “open systems”. For example today’s video, hi-fi and computer systems have all benefitted from adoption of interface standards.  Other examples exist in most fields of engineering from nuts and bolts, plumbing, electrical installations, rail gauges, IT systems and software to modular defence and space systems.
+
In some cases, particularly when multiple systems are to be defined to a common physical architecture model, one of the drivers for the physical architecture model may be interface standards; these physical interfaces may well be one of the most important concerns for these systems.  It is quite possible that such interface standards are mandated at a high level in the system requirements. On the other hand, it is equally possible for standards to be derived during physical architecture model development and these can be critical enablers for desirable engineering outcomes, such as: families of systems, technology insertion, interoperability and “open systems”. For example, today’s video, hi-fi, and computer systems have all benefited from adoption of interface standards.  Other examples exist in most fields of engineering from nuts and bolts, plumbing, electrical installations, rail gauges, TCP/IP, IT systems and software to modular defense and space systems.
 +
 
 +
Note: The term ''Physical Architecture'' is a contraction of the expression ''Physical View of the System Architecture''.
  
 
==Concepts and Principles==
 
==Concepts and Principles==
  
===System Element, Physical Interface, and Physical Architecture===
+
===System Element, Physical Interface, and Physical Architecture Model===
A system element is a discrete part of a system that can be implemented to fulfill design properties. A system element can be hardware, software, data, humans, processes (e.g., processes that provide a service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, and minerals), or any combination of these (ISO/IEC/IEEE 15288 2008). A [[Physical Interface (glossary)|physical interface]] binds two system elements together; this is similar to a link or a connector. Table 1 provides some examples of system elements and physical interfaces.
+
A system element is a discrete part of a system that can be implemented to fulfill design properties. A system element can be hardware, software, data, humans, processes (e.g., processes that provide a service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, and minerals), or any combination of these ISO/IEC/IEEE 15288 (ISO 2015). A {{Term|Physical Interface (glossary)|physical interface}} binds two system elements together; this is similar to a link or a connector. Table 1 provides some examples of system elements and physical interfaces.
  
 
{|
 
{|
Line 19: Line 24:
 
|'''System Element'''
 
|'''System Element'''
 
|
 
|
*Hardware Parts (mechanics, electronics, electrical, plastic, chemical, etc.)
+
* Hardware Parts (mechanics, electronics, electrical, plastic, chemical, etc.)
*Operator Roles
+
* Operator Roles
*Software Pieces
+
* Software Pieces
 
|
 
|
*Processes, data bases, procedures, etc.
+
* Processes, Data Bases, Procedures, etc.
*Operator Roles
+
* Operator Roles
*Software Applications
+
* Software Applications
 
|
 
|
*Corporate, direction, division, department, project, technical team, leader, etc.
+
* Corporate, Direction, Division, Department, Project, Technical Team, Leader, etc.
*IT Components
+
* IT Components
 
|-
 
|-
 
|'''Physical Interface'''
 
|'''Physical Interface'''
|Hardware parts, protocols, procedures, etc.
+
|* Hardware Parts, Protocols, Procedures, etc.
|Protocols, documents, etc.
+
|* Protocols, Documents, etc.
|Protocols, procedures, documents, etc.
+
|* Protocols, Procedures, Documents, etc.
 
|}
 
|}
  
A complex system composed of thousands of physical and/or intangible parts may be structured in several layers of [[System (glossary)|systems]] and [[System Element (glossary)|system elements]]. The number of elements in the decomposition of one system is limited to only a few, in order to facilitate the ease of mastering the system; a common guideline is ''five plus or minus two'' elements (see illustration in Figure 1).  
+
A complex system composed of thousands of physical and/or intangible parts may be structured in several layers of {{Term|System (glossary)|systems}} and {{Term|System Element (glossary)|system elements}}. The number of elements in a level of the structure of one system is limited to only a few, in order to facilitate managing the system definition; a common guideline is ''five plus or minus two'' elements (see illustration in Figure 1).  
  
 
[[File:SEBoKv075_KA-SystDef_Limited_nb_in_decomposition.png|500px|thumb|center|'''Figure 1. Layers of Systems and System Elements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
[[File:SEBoKv075_KA-SystDef_Limited_nb_in_decomposition.png|500px|thumb|center|'''Figure 1. Layers of Systems and System Elements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
A physical architecture is built from systems, system elements, and all necessary physical interfaces between these elements, as well as from external elements (neighboring or enabling systems and/or system elements in the considered layer and concerned elements in the context of the global system-of-interest) - see illustration in Figure 2.
+
A physical architecture model is built from systems, system elements, and all necessary physical interfaces between these elements, as well as from external elements (neighboring or enabling systems and/or system elements in the considered layer and concerned elements in the context of the global system-of-interest) - see illustration in Figure 2.
  
[[File:SEBoKv075_KA-SystDef_Encapsulation.png|600px|thumb|center|'''Figure 2. Physical Architecture Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
+
[[File:SEBoKv075_KA-SystDef_Encapsulation.png|600px|thumb|center|'''Figure 2. Physical Architecture Model Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
 
===Design Property===
 
===Design Property===
A [[Design Property (glossary)|design property]] is a property that is obtained during system architecture and design through the assignment of non-functional requirements, estimates, analyses, calculations, simulations of a specific aspect, or through the definition of an existing element associated with a system element, a physical interface, and/or a physical architecture. If the designed element complies with a requirement, the design property will relate to (or may equal) the requirement. Otherwise, one has to identify any discrepancy that could modify the requirement, the design, or identify a deviation.
+
A {{Term|Design Property (glossary)|design property}} is a property that is obtained during system architecture and created through the assignment of non-functional requirements, estimates, analyses, calculations, simulations of a specific aspect, or through the definition of an existing element associated with a system element, a physical interface, and/or a physical architecture. If the defined element complies with a requirement, the design property will relate to (or may equal) the requirement. Otherwise, one has to identify any discrepancy that could modify the requirement or design property and detect any deviations.
 
 
Stakeholders have concerns that correspond to expected behavior within operational, environmental, or physical constraints as well as to more general life cycle constraints. [[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] express these concerns as expected abilities from the system (e.g., usability, interoperability, security, expandability, environment suitability, etc.). Architects and/or designers identify these abilities from requirements and deduce corresponding quantitative or qualitative design properties to equip their physical architecture (e.g., reliability, availability, maintainability, modularity, robustness, operability, climatic environment resistance, dimensions limits, etc.).  (For more discussion on how some of these properties may be included in architecture and design, please see the article [[Systems Engineering and Specialty Engineering]] in the [[Related Disciplines]] knowledge area (KA).
 
 
 
===Emergent Properties===
 
The overarching physical architecture of a system may have design properties that emerge from the arrangement and interaction between technological system elements, but which may not be properties of any individual element. [[Emergence (glossary)|Emergence]] is the principle which states that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts.
 
 
 
Technological system elements interact among themselves and can create desirable or undesirable phenomena called [[Emergent Property (glossary)|emergent properties]], such as inhibition, interference, resonance, or reinforcement of any property. The definition of the system includes an analysis of interactions between technological system elements in order to prevent undesirable properties and reinforce desirable ones.
 
 
 
Physical architecture design will include identification of likely emergent properties and the inclusion of functions, components or arrangements in the logical or physical architectures to avoid, mitigate or keep them within acceptable limits.  This may be achieved through the knowledge and experienced of the Systems Engineer or through the application of [[Pattern (glossary)|System Patterns]].  However, it is generally not possible to predict and remove all Emergent Properties.  Fully dealing with the consequences of emergence can only be done via iteration between System Definition, Realization and Use, see [[Emergence]]
 
 
 
A property which emerges from a system can have various origins, from a single system element to several ones, or from the  interactions among several elements (Thome, B. 1993). (For more information, see Table 2, as well as the white paper by Dereck Hitchins (2008), available at http://www.hitchins.net/EmergenceEtc.pdf.).
 
 
 
{|
 
|+'''Table 2. Properties and Emergent Properties.''' (SEBoK Original)
 
!Broad Categories of Properties
 
!Description and examples
 
|-
 
|'''Local property'''
 
|The property is located in a single system element – e.g. the capacity of a container is the capacity of the system.
 
|-
 
|'''Accumulative System property'''
 
|The property is located in several system elements, and is obtained by simple summation of elemental properties – e.g. the weight of the system results from the sum of the weights of its system elements.
 
|-
 
 
 
 
 
 
|'''Emergent property modified by architecture and/or interactions.'''
 
|The property exists in several system elements and is modified by their interactions – e.g. the reliability/safety of a system results from the reliability/safety of each system element and the way they are organized. Architectural steps are often critical to meeting System Requirements.
 
|-
 
|'''Emergent property created by interactions'''
 
|The property does not exist in system elements and results only from their interactions – e.g. electromechanical interfaces, electromagnetism, static electricity, etc.
 
|-
 
|'''Controlled emergent property'''
 
|Property controlled or inhibited before going outside the system – e.g.: unbalance removed by the addition of a load; vibration deadened by a damper.
 
|}
 
  
The notion of emergent property is used during architecture and design to highlight necessary derived functions and internal physical or environmental constraints. Corresponding ''derived requirements'' should be added to the system requirements baseline when they impact the [[System-of-Interest (glossary)|system-of-interest]] (SoI).  
+
Stakeholders have concerns that correspond to the expected behavior of a system within operational, environmental, and/or physical constraints as well as to more general life cycle constraints. {{Term|Stakeholder Needs and Requirements (glossary)|Stakeholder needs and requirements}} and {{Term|System Requirement (glossary)|system requirements}} express these concerns as expected capabilities from the system (e.g., usability, interoperability, security, expandability, environment suitability, etc.). Architects and/or designers identify these capabilities from requirements and deduce corresponding quantitative or qualitative design properties to properly equip their physical architecture model (e.g., reliability, availability, maintainability, modularity, robustness, operability, climatic environment resistance, dimensions limits, etc.).  For further discussion on how some of these properties may be included in architecture and design, please see the article [[Systems Engineering and Quality Attributes]] in the [[Related Disciplines]] Part.
 
 
Emergent properties are often linked to the notion of [[Complexity (glossary)|complexity]]. This is the case with complex adaptive systems (CAS), systems where the individual elements act independently but jointly behave according to common constraints and goals (Flood and Carson 1993). Examples of CAS include the global macroeconomic network within a country or group of countries, stock market, complex web of cross border holding companies, manufacturing businesses, geopolitical organizations, etc. (Holland, J. 1999 and 2006).
 
  
 
===Allocation of Logical Elements to Physical Elements and Partitioning===
 
===Allocation of Logical Elements to Physical Elements and Partitioning===
Defining a candidate physical architecture for a system consists of first identifying system elements that can perform functions of the logical architecture as well as identifying the interfaces capable of carrying out input-output flows and control flows. When identifying potential elements, a systems engineer needs to allocate design properties within the logical architecture; these properties are deduced from [[System Requirements|system requirements]]. Partitioning and allocation are activities to decompose, gather, or separate functions in order to facilitate the identification of feasible system elements that support these functions. Either they exist and can be reused or re-purposed, or they can be developed and technically implemented.
+
Developing a candidate physical architecture model for a system consists of first identifying the system elements that can perform functions of the logical architecture model as well as identifying the interfaces capable of carrying out the input-output flows and control flows. When identifying potential elements, a systems engineer needs to allocate design properties within the logical architecture; these properties are deduced from the [[System Requirements|system requirements]]. Partitioning and allocation are activities to decompose, gather, or separate functions in order to facilitate the identification of feasible system elements that support these functions. Either they exist and can be reused or re-purposed, or they can be developed and technically implemented.
  
Partitioning and allocation use criteria to find potential affinities between functions. Systems engineers use system requirements and/or design properties as criteria to assess and select physical candidate system elements and partitions of functions, such as similar transformations within the same technology, similar levels of efficiency, exchange of the same type of input-output flows (information, energy, and materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environment resistance level, and other enterprise constraints.
+
Partitioning and allocation use criteria to find potential affinities between functions. Systems engineers use system requirements and/or design properties as criteria to assess and select candidate system elements and partitions of functions, such as similar transformations within the same technology, similar levels of efficiency, exchange of the same type of input-output flows (information, energy, and materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environment resistance level, and other enterprise constraints.
  
A concurrent engineering approach is necessary when several different sets of technologies, knowledge, and skills are necessary to work out a candidate physical architecture. This is particularly true during the partition and allocation of functions to various system elements, in which the systems engineer must account for compatibility issues and emergent properties.
+
A concurrent engineering approach is necessary when several different sets of technologies, knowledge, and skills are necessary to establish a candidate physical architecture model. This is particularly true during the partition and allocation of functions to various system elements, in which the systems engineer must account for compatibility issues and {{Term|Emergent Property (glossary)|emergent properties}}. (See SEBoK Part 2: [[Synthesizing Possible Solutions]] for a discussion of possible approaches.)
  
===Developing Physical Candidate Architectures===
+
===Developing Candidate Physical Architecture Models===
The goal of physical architecture and design activities is to provide the best possible physical architecture made of suitable systems, technological system elements, and physical interfaces (i.e., the architecture that answers, at best, all system requirements, depending on agreed limits or margins of each requirement). The best possible way to do this is to produce several candidate physical architecture models, assess and compare them, and then select the most suitable one.
+
The goal of physical architecture model development activities is to provide the best possible physical architecture model made of suitable systems, technological system elements, and physical interfaces (i.e., the architecture that answers, at best, all system requirements, depending on agreed limits or margins of each requirement). The best way to do this is to produce several candidate physical architecture models, assess and compare them, and then select the most suitable one.
  
A candidate physical architecture is worked out according to affinity criteria in order to build a set of (sub) systems and system elements (i.e., separate, gather, connect, and disconnect the network of system elements and their physical interfaces).  These criteria are the same as those used for partitioning and allocating functions to system elements. The physical architecture definition may be focused in different ways, concentrating on
+
A candidate physical architecture model is elaborated according to affinity criteria in order to build a set of system elements (i.e., separate, gather, connect, and disconnect the network of system elements and their physical interfaces).  These criteria are the same as those used for partitioning and allocating functions to system elements. The physical architecture model development may be focused in different ways, for example, it may address:
  
* reduction in the number of physical interfaces,
+
* Reduction in the number of physical interfaces
* system elements that can be tested separately,
+
* System elements that can be tested separately
* modular (i.e., have low interdependence),
+
* Compatible technology
* maintainable, replaceable system elements,
+
* Measures of the proximity of elements in space
* compatible technology,
+
* Ease of handling (weight, volume, and transportation facilities)  
* measures of the proximity of elements in space,
+
* Optimization of resources shared between elements
* accounts of handling (weight, volume, and transportation facilities), or
+
*  Modularity (i.e. elements have low interdependence)
* optimization of resources shared between elements.
+
*  Resilience (i.e. elements which are highly reliable, maintainable or replaceable)
  
 
===Evaluating and Selecting the Preferred Candidate===
 
===Evaluating and Selecting the Preferred Candidate===
Viable physical architectures enable all required functions or capabilities specified in the logical architecture to be realised. Architecture and design activity includes optimization to obtain a balance among design properties, costs, risks, etc. Generally, the physical architecture of a system is determined more strongly by non-functional requirements (e.g., performance, safety, security, environmental conditions, constraints, etc.) than by functions. There may be many (physical) ways to achieve functions but fewer ways of satisfying non-functional requirements. The preferred physical architecture represents selection of physical components, their physical relationships and interfaces. Typically this physical architecture will still leave further systems engineering to be undertaken to achieve a fully optimized system design after any remaining trade-offs are made and algorithms and parameters of the system are finalised.
+
Viable physical architecture models enable all required functions or capabilities specified in the logical architecture model to be realized. Architecture and design activity includes evaluation to obtain a balance among design properties, costs, risks, etc. Generally, the physical architecture model of a system is determined more strongly by non-functional requirements (e.g., performance, safety, security, environmental conditions, constraints, etc.) than by functions. There may be many (physical) ways to establish functions but fewer ways of satisfying non-functional requirements. The preferred physical architecture model represents the selection of system elements, their physical relationships, and interfaces. Typically, this physical architecture will still leave further systems engineering to be undertaken to achieve a fully optimized system after any remaining trade-offs are made and algorithms and parameters of the system are finalized.
 +
Certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global behavior and structure of the candidate architectures in regard to system requirements; this is often broadly referred to as [[System Analysis|system analysis]]. Other analyses and assessments require knowledge and skills from the different involved technologies and specialties (mechanics, electronics, software, thermodynamics, electro-magnetic compatibility, safety, security etc.). They are performed through corresponding specialist analysis of the system.
  
Certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global behavior and structure of the candidate architectures regarding system requirements; this is often broadly referred to as [[System Analysis|system analysis]]. Other analyses and assessments require knowledge and skills from the different involved technologies and specialities (mechanics, electronics, software, thermodynamics, electro-magnetic compatibility, safety, security etc.). They are performed through corresponding specialist analysis of the physical architecture or system.
+
===Legacy Systems and Systems of Systems===
 +
Few systems come into existence or operate without interacting with others in a {{Term|System Context (glossary)|system context}}. These interactions may be with other operational systems, or maintenance and support systems, which in turn may be legacy (already in use) or future legacy (under development and likely to operate with the system of interest in the future).  
  
===Legacy Systems and Systems of Systems===
+
The best chosen approach will be dependent on the strength of interactions between the {{Term|System-of-Interest (glossary)}} (SoI) and its wider context. While these interactions are small, they may be accounted for by defining a set of static external interface requirements (for example, technical standards) with which the system must comply, by including these as constraints in the system requirements and ensuring compliance through design assurance. 
Few systems come into existence or operate without interacting with others in a [[System Context (glossary)]]. These interactions may be with other operational systems, or maintenance and support systems, which in turn may be legacy (already in use) or future legacy (under development and likely to operate with the system of interest some time in the future).  
+
 
 +
Where the interactions are more intense (for example, where continuous information is to be exchanged with other systems), these will have to be recognized as part of a {{Term|System of Systems (SoS) (glossary)|system of systems}} context and will instead be considered as part of an {{Term|Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering}} approach.  
  
The approach to be taken will depend on the strength of interactions between the [[System-of-Interest (glossary)]] (SoI) and its wider context. Where these are small, they may be catered for by defining a set of static external interfaces (for example technical standards) with which the system must comply, including these as constraints in the System Requirements, and ensuring compliance through design assurance.
+
Another important consideration may be the sharing of technology or system elements between the SoI and other systems, often as part of a family of systems (many examples occur in automotive and aerospace industries) or the re-use of system elements from existing legacy. Here a degree of top-down or middle-out design work will be necessary to ensure the system of interest embodies the required system elements, while conforming as far as possible to the stakeholder and system requirements, with any compromises being understood and managed.  
  
Where the interactions are more intense, for example where continuous information is to be exchanged with other systems, these will have to be recognized as part of a [[System of Systems (SoS) (glossary)|system of systems]] context and considered as part of an [[Enterprise Systems Engineering (ESE) (glossary)]] approach. The relevant SoS relationships, interfaces and constraints should be included in concept definition, with the results embedded in the stakeholder and system requirements and handled through interface agreements and across-project communication during development.
+
If a System-of-Interest is intended to be used in one or more {{Term|Service System (glossary)|service systems}} or {{Term|System of Systems (SoS) (glossary)|system of systems}} configurations, this will affect its physical architecture model.  One of the features of these SoS is the late binding of component systems in use. Such component systems must be architected with open or configurable interfaces, must have clearly defined functions packaged in such a way as to be relevant to the SoS using them, and must include some method by which they can be identified and included in the SoS when needed.
  
Another important consideration may be the sharing of technology or system elements between the SoI and other systems, often as part of a family of systems (many examples occur in automotive and aerospace industries) or re-using system elements from existing legacy. Here a degree of top-down or middle-out design work will be necessary to ensure the system of interest embodies the required system elements while conforming as far as possible to the user and system requirements, with any compromises understood and managed.   
+
Both service systems and SoS will be defined by a high-level physical architecture model, which will be utilized to define the relevant SoS relationships, interfaces, and constraints that should be included in [[System Concept Definition]].  The results will be embedded in the stakeholder and system requirements and handled through interface agreements and across-project communication during development, realization, and use.   
  
Please see SEBoK Part 4 [[Applications of Systems Engineering]] for more information on special considerations for architecting SoS.
+
See SEBoK Part 4: [[Applications of Systems Engineering]] for more information on special considerations for architecting SoS.
  
 
==Process Approach==
 
==Process Approach==
 
===Purpose===
 
===Purpose===
The purpose of the physical architecture definition (design) process is to define, select, and synthesize a system physical architecture which can support the logical architecture. A physical architecture will have specific properties designed to address stakeholder or environmental issues and satisfy system requirements.
+
The purpose of the Physical Architecture Model Development is to define, select, and synthesize a system physical architecture model which can support the logical architecture model. A physical architecture model will have specific properties to address stakeholder concerns or environmental issues and to satisfy system requirements.
  
Because of the evolution of the [[System Context (glossary)|context of use]] or technological possibilities, the physical architecture which is composed of [[System Element (glossary) |system elements]] is supposed to change along the life cycle of the system in order for it to continue to perform its mission within the limits of its required effectiveness. Depending on whether or not evolution impacts [[Logical Architecture (glossary)|logical architecture]] elements, allocations to system elements may change. A physical architecture is equipped with specific [[Design Property (glossary)|design properties (glossary)]] to continuously challenge the evolution.
+
Because of the evolution of the {{Term|System Context (glossary)|context of use}} or technological possibilities, the physical architecture which is composed of {{Term|System Element (glossary)|system elements}} is supposed to evolve along the life cycle of the system in order for it to continue to perform its mission within the limits of its required effectiveness. Depending on whether or not evolution impacts {{Term|Logical Architecture (glossary)|logical architecture}}  model elements, allocations to system elements may change. A physical architecture model is equipped with specific {{Term|Design Property (glossary)|design properties}} to continuously challenge the evolution.
  
'''Generic inputs''' include the selected logical architecture, system requirements, generic patterns and properties that designers identify and utilize to answer requirements, outcomes from system analysis, and feedback from system verification and system validation.
+
'''Generic inputs''' include the selected logical architecture model, system requirements, generic patterns and properties that architects identify and utilize to answer requirements, outcomes from system analysis, and feedback from system verification and system validation.
  
'''Generic outputs''' are the selected physical architecture, allocation matrix of functional elements to physical elements, traceability matrix with system requirements, stakeholder requirements of each system and system element composing the physical architecture, and rejected solutions.
+
'''Generic outputs''' are the selected physical architecture model, allocation matrix of functional elements to physical elements, traceability matrix with system requirements, stakeholder requirements of each system and system element composing the physical architecture model, and rejected solutions.
  
 
===Activities of the Process===
 
===Activities of the Process===
 
Major activities and tasks to be performed during this process include the following:
 
Major activities and tasks to be performed during this process include the following:
  
*Partition and allocate functional elements to system elements:
+
* Partition and allocate functional elements to system elements:
**Search for system elements or technologies able to perform functions and physical interfaces to carry input-output and control flows. Ensure system elements exist or can be engineered. Assess each potential system element using criteria deduced from design properties (themselves deduced from non-functional system requirements).
+
** Search for system elements or technologies able to perform functions and physical interfaces to carry input-output and control flows. Ensure system elements exist or can be engineered. Assess each potential system element using criteria deduced from design properties (themselves deduced from non-functional system requirements).
**Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria and allocate partitioned sets to system elements (using the same criteria).
+
** Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria and allocate partitioned sets to system elements (using the same criteria).
**When it is impossible to identify a system element that corresponds to a partitioned functional set, decompose the function until the identification of implementable system elements is possible.
+
** When it is impossible to identify a system element that corresponds to a partitioned functional set, decompose the function until the identification of implementable system elements is possible.
**Check the compatibility of technologies and the compatibility of interfaces between selected system elements.
+
** Check the compatibility of technologies and the compatibility of interfaces between selected system elements.
*Model candidate physical architectures; for each candidate
+
* Constitute candidate physical architecture models.
**Because partitioned sets of functions can be numerous, there are generally too many system elements. For defining controllable architectures, system elements have to be grouped into higher-level system elements known as (sub) systems.
+
** Because partitioned sets of functions can be numerous, there are generally too many system elements. For defining controllable architectures, system elements have to be grouped into higher-level system elements known as system element groups, often called sub-systems in industry.
**Constitute several different sets of (sub) systems corresponding to different combinations of elementary system elements. One set of (sub) systems plus one or several non-decomposable system elements form a candidate physical architecture of the considered system.
+
** Constitute several different system element groups corresponding to different combinations of elementary system elements. One set of system element groups plus one or several non-decomposable system elements forms a candidate physical architecture model of the considered system.
**Represent (using patterns) the physical architecture of each (sub) system connecting its system elements with physical Interfaces that carry input-output flows and triggers. Add physical interfaces as needed; in particular, add interfaces with external elements to the (sub) system.
+
** Represent (using patterns) the physical architecture model of each system element group connecting its system elements with physical interfaces that carry input-output flows and triggers. Add physical interfaces as needed; in particular, add interfaces with external elements to the system element group.
**Represent the synthesized physical architecture of the considered system built from (sub) systems, non-decomposable system, and physical interfaces inherited from the physical architecture of (sub) systems.
+
** Represent the synthesized physical architecture of the considered system built from system element groups, non-decomposable systems, and physical interfaces inherited from the physical architecture model of system element groups.
**Equip the physical architecture with design properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.
+
** Enhance the physical architecture model with design properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.
**If possible, use executable architecture prototypes (e.g., hardware-software (HW-SW)-in-the-loop prototypes) for identifying potential deficiencies and correct the architecture as needed.
+
** If possible, use executable architecture prototypes (e.g., hardware-software (HW-SW)-in-the-loop prototypes) for identifying potential deficiencies and correct the architecture as needed.
*Assess physical architecture candidates and select the most suitable one:
+
* Assess physical architecture model candidates and select the most suitable one:
**Constitute a decision model based on criteria deduced from non-functional requirements (effectiveness, environmental conditions, safety, human factors, cost, risks, etc.) and design properties (modularity, communication commonality, maintainability, etc.).
+
** Use the system analysis process to perform assessments (see the [[System Analysis]] topic).
**Assess physical architecture candidates against the given criteria. Select the most suitable one by comparing scores and rationales to determine which candidate best matches the criteria. Use the system analysis process to perform assessments (see the [[System Analysis]] Topic).
+
** Use the Decision Management process to support the trades and selection of the preferred alternative (see the [[Decision Management]] topic).
*Synthesize the selected physical architecture:
+
* Synthesize the selected physical architecture model:
**Formalize physical elements and properties. Verify that system requirements are satisfied and that the solution is realistic.  
+
** Formalize physical elements and properties. Verify that system requirements are satisfied and that the solution is realistic.  
**Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding system requirements.
+
** Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding system requirements.
**Establish traceability between system requirements and physical elements as well as allocate matrices between functional and physical elements.
+
** Establish traceability between system requirements and physical elements as well as allocate matrices between functional and physical elements.
*Prepare for the acquisition of each system or non-decomposable system element:
 
**Define the system or system element’s mission and objectives from allocated functions and effectiveness.
 
**Define the stakeholder requirements (the concerned stakeholder being the current studied system). Additional information about development of stakeholder requirements can be found in the [[Stakeholders Requirements]] topic.
 
**Establish traceability between these stakeholder requirements and elements of the studied system (in particular design properties). This allows traceability of requirements between two layers of systems.
 
  
===Artifacts and Ontology Elements===
+
===Artifacts, Methods and Modeling Techniques===
This process may create several artifacts, such as
+
Physical architecture descriptions use modeling techniques to create and represent physical architectures. Some common physical models include structural blocks, mass, layout and other models. Modeling techniques may be:
  
*system design documents (describe selected logical and physical architectures),
+
* Physical block diagrams (PBD)
*system design justification documents (traceability matrices and design choices), and
+
* SysML block definition diagrams (BDD)
*system element stakeholder requirements documents (one for each system or system element).
+
* Internal block diagrams (IBD) (OMG 2010)
 +
*  Executable architecture prototyping
 +
*  Etc.
  
This process utilizes the ontology elements discussed in Table 3.
+
Depending on the type of domain for which it is to be used (defense, enterprise, etc.), {{Term|Architecture Framework (glossary)|architecture frameworks}} may provide descriptions that can help to trade-off candidate architectures. Please see section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]].
 
 
{|
 
|+'''Table 3. Ontology Elements Handled within Physical Architecture Design.''' (SEBoK Original)
 
!Element
 
!Definition
 
----
 
Attributes (example)
 
|-
 
|'''System Element'''
 
|A physical element (user or operator role, hardware, software) that composes a system (used for system-of-interest, system, system element). A system element may be seen in its turn as a system (i.e. sub-system) and be engineered in a system block or lower level.
 
----
 
Identifier; name; description; purpose; mission; objectives; generic type (context, system-of-interest, system, system element); specific type (product, component, service, enterprise, operator role, operational note, etc.)
 
|-
 
|'''Physical Interface'''
 
|A physical interface is a system element that binds two system elements.
 
----
 
Identifier; name; description
 
|-
 
|'''Port'''
 
|The part of a system element that allows the binding of one system element to another with a physical interface.
 
----
 
Identifier; name; description
 
|-
 
|'''Design Property'''
 
|A design property is associated with a system element, a physical interface, and a physical architecture. It is a characteristic obtained during design through allocation of requirements, or estimate, analysis, study, calculation, simulation, etc. If the designed element complies with a requirement, the design property should equal the requirement. Otherwise one has to identify the difference or non-conformance and establish which treatment could conclude to modify the requirement, or the design, or identify a deviation.
 
----
 
Identifier; name; description; type (effectiveness, availability, reliability, maintainability, weight, capacity, etc.); value; unit; etc.
 
|-
 
|'''Physical Architecture'''
 
|An arrangement of physical system elements which provides the design solution for a consumer product or life-cycle process that is intended to satisfy the requirements of the functional architecture and the requirement baseline. (ISO/IEC 2007)
 
----
 
Identifier; name; description
 
|-
 
|'''Interface'''
 
|An interface generally includes a functional interface and a physical interface. A functional interface is constituted of an input flow or an output flow. A physical interface is a physical link and/or port between two system elements so that they can work together.
 
----
 
Identifier; name; description
 
|-
 
|'''System Element Requirement'''
 
|A requirement applicable to the system element that is defined during the design of the system that contains it. Its nature is similar to a stakeholder requirement; the stakeholder is the system that contains it. It is elaborated from the system physical and functional architecture elements and from the system requirements of the system.
 
----
 
Identifier; name; description; origin (owner of the system element requirement = the system); type/classification (identical to stakeholder types); history records (date, author, identification, and contents of the modification, type of modification, reason for the modification); comment
 
|-
 
|'''Rationale'''
 
|An argument that provides the justification for the selection of an engineering element.
 
----
 
Identifier; name; description (rationale, 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 engineer). A risk is the combination of vulnerability and a danger or a threat.
 
----
 
Identifier; name; description; status
 
|}
 
 
 
Note: The element "interface" may include both functional and physical aspects. It can be used for technical management purposes.
 
 
 
===Methods and Modeling Techniques===
 
Modeling techniques are used to create and represent physical architectures. Some common models include
 
 
 
* physical block diagrams (PBD),
 
* SysML block definition diagrams (BDD),
 
* internal block diagrams (IBD) (OMG 2010), and
 
* executable architecture prototyping.
 
 
 
Depending on the type of domain (defense, enterprise, etc.), architecture frameworks such as DoDAF (DoD 2010), TOGAF (The Open Group 2011), the Zachman framework (Zachman 2008), etc., provide descriptions that can help to trade-off candidate architectures - see section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]].
 
  
 
==Practical Considerations==
 
==Practical Considerations==
Key pitfalls and good practices related to physical architecture definition are described in the next two sections.
+
Key pitfalls and good practices related to physical architecture development are described in the next two sections.
  
 
===Pitfalls===
 
===Pitfalls===
Some of the key pitfalls encountered in planning and performing physical architecture definition are provided in Table 4.
+
Some of the key pitfalls encountered in performing physical architecture model development are provided in Table 3.
  
 
{|
 
{|
|+'''Table 4. Pitfalls with Physical Architecture Design.''' (SEBoK Original)
+
|+'''Table 3. Pitfalls with Physical Architecture Development.''' (SEBoK Original)
 
!Pitfall
 
!Pitfall
 
!Description
 
!Description
 
|-
 
|-
|Too many levels in a single system block
+
|Too Many Levels in a Single System Block
|The current system block includes too many levels of decomposition. The right practice is that the physical architecture of a system block is composed of one single level of systems and/or system elements.
+
|The current system block includes too many levels of decomposition. The right practice is that the physical architecture model of a system block is composed of one single level of systems and/or system elements.
|-
 
|No functional architecture
 
|The developers perform a direct passage from system requirements to physical architecture without establishing a logical architecture; this is a common wrong practice mainly done when dealing with repeating systems and products because the functions are already known. The issue is that a function is always associated with input-output flows defined in a specific domain set. If the domain set changes, the performance of the function can become invalid.
 
 
|-
 
|-
|Direct allocation on technologies
+
|No Logical Architecture Model
|At a high level of abstraction of multidisciplinary systems, directly allocating the functions onto technologies of the lowest level of abstraction, such as hardware or software, does not reflect a system comprehension. The right practice is to consider criteria to decompose the architecture into the appropriate number of levels, alternating logical and physical before reaching the technology level (last level of system).
+
|The developers perform a direct passage from system requirements to a physical architecture model without establishing a logical architecture model; this is a common wrong practice that mainly takes place when dealing with repeating systems and products because the functions are already known. The issue is that a function is always associated with input-output flows defined in a specific domain set. If the domain set changes, the performance of the function can become invalid.
 
|-
 
|-
|Reuse of system elements
+
|Direct Allocation on Technologies
|In some projects, because of the usage of existing products or for industrial purposes, existing products or services are imposed very early as design constraints in the stakeholder requirements or in the system requirements, without paying sufficient attention to the new context of use of the system that will include them. It is better to work in the right direction from the beginning. Design the system first, taking note of other requirements, and then see if any suitable commercial off-the-shelf (COTS) are available. Do not impose a system element from the beginning. The right re-use process consists of designing reusable system elements in every context of use.
+
|At a high level of abstraction of multidisciplinary systems, directly allocating the functions onto technologies of the lowest level of abstraction, such as hardware or software, does not reflect a system comprehension. The right practice is to consider criteria to decompose the architecture into the appropriate number of levels, alternating logical and physical before reaching the technology level ( the last level of the system).
 
|}
 
|}
  
 
===Proven Practices===
 
===Proven Practices===
Some proven practices gathered from the references are provided in Table 5.
+
 
 +
Some proven practices gathered from the references are provided in Table 4.
  
 
{|
 
{|
|+'''Table 5. Proven Practices with Physical Architecture Design.''' (SEBoK Original)
+
|+'''Table 4. Proven Practices with Physical Architecture Development.''' (SEBoK Original)
 
!Practice
 
!Practice
 
!Description
 
!Description
 
|-
 
|-
 
|Modularity
 
|Modularity
|Restrict the number of interactions between the system elements and consider modularity principle (maximum of consistency inside the system element, minimum of physical interfaces with outside) as the right way for architecting systems.
+
|Restrict the number of interactions between the system elements and consider the modularity principle (maximum of consistency inside the system element, minimum of physical interfaces with outside) as the right way for architecting systems.
|-
 
|Focus on interfaces
 
|Focusing on interfaces rather than on system elements is another key element of a successful design for abstract levels of systems.
 
 
|-
 
|-
|Emerging properties
+
|Focus on Interfaces
|Control the emergent properties of the interactions between the systems or system elements: obtain the required synergistic properties and control or avoid the undesirable behaviors (vibration, noise, instability, resonance, etc.).
+
|Focusing on interfaces rather than on system elements is another key element of a successful architecture and design for abstract levels of systems.
 
|}
 
|}
  
 
==References==
 
==References==
 
===Works Cited===
 
===Works Cited===
Checkland, P. B. 1999. ''Systems Thinking, Systems Practice''. Chichester, UK: John Wiley & Sons Ltd.
+
ISO/IEC. 2007. ''Systems Engineering – Application and Management of The Systems Engineering Process.'' Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007.
 
 
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.
 
 
 
Flood, R.L., and E.R. Carson. 1993. ''Dealing with complexity: An Introduction to the Theory and Application of Systems Science'', 2nd ed. New York, NY, USA: Plenum Press
 
 
 
Hitchins, D. 2008. "Emergence, Hierarchy, Complexity, Architecture: How do they all fit together? A guide for seekers after enlightenment." Self-published white paper. Accessed 4 September 2012. Available at: http://www.hitchins.net/EmergenceEtc.pdf.
 
 
 
Holland, J.H. 1999. ''Emergence: from chaos to order''. Reading, Mass: Perseus Books. ISBN 0-7382-0142-1.
 
 
 
Holland, J.H. 2006. "Studying Complex Adaptive Systems." Journal of Systems Science and Complexity 19 (1): 1-8. http://hdl.handle.net/2027.42/41486
 
 
 
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.
 
 
 
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.
 
  
The Open Group. 2011. TOGAF, version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
+
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation (ISO) /International Electrotechnical Commissions (IEC)/ Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015.
  
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering''. New York, NY, USA: Wiley.
+
OMG. 2010. ''OMG Systems Modeling Language Specification'', version 1.2, July 2010. Available at: http://www.omg.org/technology/documents/spec_catalog.htm.
  
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
+
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
  
 
===Primary References===
 
===Primary References===
ANSI/IEEE. 2000. ''[[IEEE 1471|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.
+
ANSI/IEEE. 2000. ''[[IEEE 1471|Recommended Practice for Architectural Description for Software-Intensive Systems]]''. New York, NY, USA: 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.
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
 
   
 
   
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|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. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation (ISO)/International Electrotechnical Commissions (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015.
 +
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|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]].
  
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|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]].
+
===Additional References===
  
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]].'' 3rd ed. Boca Raton, FL, USA: CRC Press.
+
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]],'' 3rd ed. Boca Raton, FL, USA: CRC Press.
  
===Additional References===
+
Holland, J.H. 2006. "Studying Complex Adaptive Systems." ''Journal of Systems Science and Complexity.'' vol. 19, no. 1 pp. 1-8. Available at: http://hdl.handle.net/2027.42/41486.
  
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com
+
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering.'' New York, NY, USA: Wiley.
  
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering''. New York, NY, USA: Wiley.
+
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
  
 +
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture.  Accessed August 29, 2012.  Available at: http://www.zachman.com/about-the-zachman-framework.
 
----
 
----
  
<center>[[Architectural Design: Logical|< Previous Article]]  |  [[System Definition|Parent Article]]  |  [[System Analysis|Next Article >]]</center>
+
<center>[[Logical Architecture Model Development|< Previous Article]]  |  [[Systems Engineering and Management|Parent Article]]  |  [[System Detailed Design Definition|Next Article >]]</center>
 +
 
 +
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
  
[[Category:Part 1]][[Category:Topic]]
+
[[Category: Part 3]][[Category:Topic]]
 
[[Category:System Definition]]
 
[[Category:System Definition]]
{{DISQUS}}
 

Latest revision as of 23:19, 2 May 2024


Lead Authors: Alan Faisandier, Rick Adcock


Physical Architecture Model Development may be used as a task of the activity "Develop candidate architectures models and views," or a sub-process of the System Architecture Design Definition process. Its purpose is to elaborate models and views of a physical, concrete solution that accommodates the logical architecturelogical architecture model and satisfies and trades-off system requirements. Once a logical architecture model is defined (see Logical Architecture Model Development), concrete physical elements have to be identified that can support functional, behavioral, and temporal features as well as the expected properties of the system deduced from non-functional system requirements (e.g. constraint of replacement of obsolescence, and/or continued product support).

A physical architecturephysical architecture model is an arrangement of physical elements, (system elementssystem elements and physical interfacesphysical interfaces) that provides the solution for a productproduct, serviceservice, or enterpriseenterprise. It is intended to satisfy logical architecture elements and system requirements ISO/IEC/IEEE 26702 (ISO 2007). It is implementable through technological system elements. System requirementsSystem requirements are allocated to both the logical and physical architectures. The resulting system architecture is assessed with system analysissystem analysis and when completed becomes the basis for system realizationsystem realization.

In some cases, particularly when multiple systems are to be defined to a common physical architecture model, one of the drivers for the physical architecture model may be interface standards; these physical interfaces may well be one of the most important concerns for these systems. It is quite possible that such interface standards are mandated at a high level in the system requirements. On the other hand, it is equally possible for standards to be derived during physical architecture model development and these can be critical enablers for desirable engineering outcomes, such as: families of systems, technology insertion, interoperability and “open systems”. For example, today’s video, hi-fi, and computer systems have all benefited from adoption of interface standards. Other examples exist in most fields of engineering from nuts and bolts, plumbing, electrical installations, rail gauges, TCP/IP, IT systems and software to modular defense and space systems.

Note: The term Physical Architecture is a contraction of the expression Physical View of the System Architecture.

Concepts and Principles

System Element, Physical Interface, and Physical Architecture Model

A system element is a discrete part of a system that can be implemented to fulfill design properties. A system element can be hardware, software, data, humans, processes (e.g., processes that provide a service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, and minerals), or any combination of these ISO/IEC/IEEE 15288 (ISO 2015). A physical interfacephysical interface binds two system elements together; this is similar to a link or a connector. Table 1 provides some examples of system elements and physical interfaces.

Table 1. Types of System Elements and Physical Interfaces. (SEBoK Original)
Element Product System Service System Enterprise System
System Element
  • Hardware Parts (mechanics, electronics, electrical, plastic, chemical, etc.)
  • Operator Roles
  • Software Pieces
  • Processes, Data Bases, Procedures, etc.
  • Operator Roles
  • Software Applications
  • Corporate, Direction, Division, Department, Project, Technical Team, Leader, etc.
  • IT Components
Physical Interface * Hardware Parts, Protocols, Procedures, etc. * Protocols, Documents, etc. * Protocols, Procedures, Documents, etc.

A complex system composed of thousands of physical and/or intangible parts may be structured in several layers of systemssystems and system elementssystem elements. The number of elements in a level of the structure of one system is limited to only a few, in order to facilitate managing the system definition; a common guideline is five plus or minus two elements (see illustration in Figure 1).

Figure 1. Layers of Systems and System Elements (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

A physical architecture model is built from systems, system elements, and all necessary physical interfaces between these elements, as well as from external elements (neighboring or enabling systems and/or system elements in the considered layer and concerned elements in the context of the global system-of-interest) - see illustration in Figure 2.

Figure 2. Physical Architecture Model Representation (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

Design Property

A design propertydesign property is a property that is obtained during system architecture and created through the assignment of non-functional requirements, estimates, analyses, calculations, simulations of a specific aspect, or through the definition of an existing element associated with a system element, a physical interface, and/or a physical architecture. If the defined element complies with a requirement, the design property will relate to (or may equal) the requirement. Otherwise, one has to identify any discrepancy that could modify the requirement or design property and detect any deviations.

Stakeholders have concerns that correspond to the expected behavior of a system within operational, environmental, and/or physical constraints as well as to more general life cycle constraints. Stakeholder needs and requirementsStakeholder needs and requirements and system requirementssystem requirements express these concerns as expected capabilities from the system (e.g., usability, interoperability, security, expandability, environment suitability, etc.). Architects and/or designers identify these capabilities from requirements and deduce corresponding quantitative or qualitative design properties to properly equip their physical architecture model (e.g., reliability, availability, maintainability, modularity, robustness, operability, climatic environment resistance, dimensions limits, etc.). For further discussion on how some of these properties may be included in architecture and design, please see the article Systems Engineering and Quality Attributes in the Related Disciplines Part.

Allocation of Logical Elements to Physical Elements and Partitioning

Developing a candidate physical architecture model for a system consists of first identifying the system elements that can perform functions of the logical architecture model as well as identifying the interfaces capable of carrying out the input-output flows and control flows. When identifying potential elements, a systems engineer needs to allocate design properties within the logical architecture; these properties are deduced from the system requirements. Partitioning and allocation are activities to decompose, gather, or separate functions in order to facilitate the identification of feasible system elements that support these functions. Either they exist and can be reused or re-purposed, or they can be developed and technically implemented.

Partitioning and allocation use criteria to find potential affinities between functions. Systems engineers use system requirements and/or design properties as criteria to assess and select candidate system elements and partitions of functions, such as similar transformations within the same technology, similar levels of efficiency, exchange of the same type of input-output flows (information, energy, and materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environment resistance level, and other enterprise constraints.

A concurrent engineering approach is necessary when several different sets of technologies, knowledge, and skills are necessary to establish a candidate physical architecture model. This is particularly true during the partition and allocation of functions to various system elements, in which the systems engineer must account for compatibility issues and emergent propertiesemergent properties. (See SEBoK Part 2: Synthesizing Possible Solutions for a discussion of possible approaches.)

Developing Candidate Physical Architecture Models

The goal of physical architecture model development activities is to provide the best possible physical architecture model made of suitable systems, technological system elements, and physical interfaces (i.e., the architecture that answers, at best, all system requirements, depending on agreed limits or margins of each requirement). The best way to do this is to produce several candidate physical architecture models, assess and compare them, and then select the most suitable one.

A candidate physical architecture model is elaborated according to affinity criteria in order to build a set of system elements (i.e., separate, gather, connect, and disconnect the network of system elements and their physical interfaces). These criteria are the same as those used for partitioning and allocating functions to system elements. The physical architecture model development may be focused in different ways, for example, it may address:

  • Reduction in the number of physical interfaces
  • System elements that can be tested separately
  • Compatible technology
  • Measures of the proximity of elements in space
  • Ease of handling (weight, volume, and transportation facilities)
  • Optimization of resources shared between elements
  • Modularity (i.e. elements have low interdependence)
  • Resilience (i.e. elements which are highly reliable, maintainable or replaceable)

Evaluating and Selecting the Preferred Candidate

Viable physical architecture models enable all required functions or capabilities specified in the logical architecture model to be realized. Architecture and design activity includes evaluation to obtain a balance among design properties, costs, risks, etc. Generally, the physical architecture model of a system is determined more strongly by non-functional requirements (e.g., performance, safety, security, environmental conditions, constraints, etc.) than by functions. There may be many (physical) ways to establish functions but fewer ways of satisfying non-functional requirements. The preferred physical architecture model represents the selection of system elements, their physical relationships, and interfaces. Typically, this physical architecture will still leave further systems engineering to be undertaken to achieve a fully optimized system after any remaining trade-offs are made and algorithms and parameters of the system are finalized. Certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global behavior and structure of the candidate architectures in regard to system requirements; this is often broadly referred to as system analysis. Other analyses and assessments require knowledge and skills from the different involved technologies and specialties (mechanics, electronics, software, thermodynamics, electro-magnetic compatibility, safety, security etc.). They are performed through corresponding specialist analysis of the system.

Legacy Systems and Systems of Systems

Few systems come into existence or operate without interacting with others in a system contextsystem context. These interactions may be with other operational systems, or maintenance and support systems, which in turn may be legacy (already in use) or future legacy (under development and likely to operate with the system of interest in the future).

The best chosen approach will be dependent on the strength of interactions between the system-of-interestsystem-of-interest (SoI) and its wider context. While these interactions are small, they may be accounted for by defining a set of static external interface requirements (for example, technical standards) with which the system must comply, by including these as constraints in the system requirements and ensuring compliance through design assurance.

Where the interactions are more intense (for example, where continuous information is to be exchanged with other systems), these will have to be recognized as part of a system of systemssystem of systems context and will instead be considered as part of an enterprise systems engineeringenterprise systems engineering approach.

Another important consideration may be the sharing of technology or system elements between the SoI and other systems, often as part of a family of systems (many examples occur in automotive and aerospace industries) or the re-use of system elements from existing legacy. Here a degree of top-down or middle-out design work will be necessary to ensure the system of interest embodies the required system elements, while conforming as far as possible to the stakeholder and system requirements, with any compromises being understood and managed.

If a System-of-Interest is intended to be used in one or more service systemsservice systems or system of systemssystem of systems configurations, this will affect its physical architecture model. One of the features of these SoS is the late binding of component systems in use. Such component systems must be architected with open or configurable interfaces, must have clearly defined functions packaged in such a way as to be relevant to the SoS using them, and must include some method by which they can be identified and included in the SoS when needed.

Both service systems and SoS will be defined by a high-level physical architecture model, which will be utilized to define the relevant SoS relationships, interfaces, and constraints that should be included in System Concept Definition. The results will be embedded in the stakeholder and system requirements and handled through interface agreements and across-project communication during development, realization, and use.

See SEBoK Part 4: Applications of Systems Engineering for more information on special considerations for architecting SoS.

Process Approach

Purpose

The purpose of the Physical Architecture Model Development is to define, select, and synthesize a system physical architecture model which can support the logical architecture model. A physical architecture model will have specific properties to address stakeholder concerns or environmental issues and to satisfy system requirements.

Because of the evolution of the context of usecontext of use or technological possibilities, the physical architecture which is composed of system elementssystem elements is supposed to evolve along the life cycle of the system in order for it to continue to perform its mission within the limits of its required effectiveness. Depending on whether or not evolution impacts logical architecturelogical architecture model elements, allocations to system elements may change. A physical architecture model is equipped with specific design propertiesdesign properties to continuously challenge the evolution.

Generic inputs include the selected logical architecture model, system requirements, generic patterns and properties that architects identify and utilize to answer requirements, outcomes from system analysis, and feedback from system verification and system validation.

Generic outputs are the selected physical architecture model, allocation matrix of functional elements to physical elements, traceability matrix with system requirements, stakeholder requirements of each system and system element composing the physical architecture model, and rejected solutions.

Activities of the Process

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

  • Partition and allocate functional elements to system elements:
    • Search for system elements or technologies able to perform functions and physical interfaces to carry input-output and control flows. Ensure system elements exist or can be engineered. Assess each potential system element using criteria deduced from design properties (themselves deduced from non-functional system requirements).
    • Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria and allocate partitioned sets to system elements (using the same criteria).
    • When it is impossible to identify a system element that corresponds to a partitioned functional set, decompose the function until the identification of implementable system elements is possible.
    • Check the compatibility of technologies and the compatibility of interfaces between selected system elements.
  • Constitute candidate physical architecture models.
    • Because partitioned sets of functions can be numerous, there are generally too many system elements. For defining controllable architectures, system elements have to be grouped into higher-level system elements known as system element groups, often called sub-systems in industry.
    • Constitute several different system element groups corresponding to different combinations of elementary system elements. One set of system element groups plus one or several non-decomposable system elements forms a candidate physical architecture model of the considered system.
    • Represent (using patterns) the physical architecture model of each system element group connecting its system elements with physical interfaces that carry input-output flows and triggers. Add physical interfaces as needed; in particular, add interfaces with external elements to the system element group.
    • Represent the synthesized physical architecture of the considered system built from system element groups, non-decomposable systems, and physical interfaces inherited from the physical architecture model of system element groups.
    • Enhance the physical architecture model with design properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.
    • If possible, use executable architecture prototypes (e.g., hardware-software (HW-SW)-in-the-loop prototypes) for identifying potential deficiencies and correct the architecture as needed.
  • Assess physical architecture model candidates and select the most suitable one:
    • Use the system analysis process to perform assessments (see the System Analysis topic).
    • Use the Decision Management process to support the trades and selection of the preferred alternative (see the Decision Management topic).
  • Synthesize the selected physical architecture model:
    • Formalize physical elements and properties. Verify that system requirements are satisfied and that the solution is realistic.
    • Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding system requirements.
    • Establish traceability between system requirements and physical elements as well as allocate matrices between functional and physical elements.

Artifacts, Methods and Modeling Techniques

Physical architecture descriptions use modeling techniques to create and represent physical architectures. Some common physical models include structural blocks, mass, layout and other models. Modeling techniques may be:

  • Physical block diagrams (PBD)
  • SysML block definition diagrams (BDD)
  • Internal block diagrams (IBD) (OMG 2010)
  • Executable architecture prototyping
  • Etc.

Depending on the type of domain for which it is to be used (defense, enterprise, etc.), architecture frameworksarchitecture frameworks may provide descriptions that can help to trade-off candidate architectures. Please see section 'Enterprise Architecture Frameworks & Methodologies' in Enterprise Systems Engineering Key Concepts.

Practical Considerations

Key pitfalls and good practices related to physical architecture development are described in the next two sections.

Pitfalls

Some of the key pitfalls encountered in performing physical architecture model development are provided in Table 3.

Table 3. Pitfalls with Physical Architecture Development. (SEBoK Original)
Pitfall Description
Too Many Levels in a Single System Block The current system block includes too many levels of decomposition. The right practice is that the physical architecture model of a system block is composed of one single level of systems and/or system elements.
No Logical Architecture Model The developers perform a direct passage from system requirements to a physical architecture model without establishing a logical architecture model; this is a common wrong practice that mainly takes place when dealing with repeating systems and products because the functions are already known. The issue is that a function is always associated with input-output flows defined in a specific domain set. If the domain set changes, the performance of the function can become invalid.
Direct Allocation on Technologies At a high level of abstraction of multidisciplinary systems, directly allocating the functions onto technologies of the lowest level of abstraction, such as hardware or software, does not reflect a system comprehension. The right practice is to consider criteria to decompose the architecture into the appropriate number of levels, alternating logical and physical before reaching the technology level ( the last level of the system).

Proven Practices

Some proven practices gathered from the references are provided in Table 4.

Table 4. Proven Practices with Physical Architecture Development. (SEBoK Original)
Practice Description
Modularity Restrict the number of interactions between the system elements and consider the modularity principle (maximum of consistency inside the system element, minimum of physical interfaces with outside) as the right way for architecting systems.
Focus on Interfaces Focusing on interfaces rather than on system elements is another key element of a successful architecture and design for abstract levels of systems.

References

Works Cited

ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation (ISO) /International Electrotechnical Commissions (IEC)/ Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015.

OMG. 2010. OMG Systems Modeling Language Specification, version 1.2, July 2010. Available at: http://www.omg.org/technology/documents/spec_catalog.htm.

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

Primary References

ANSI/IEEE. 2000. Recommended Practice for Architectural Description for Software-Intensive Systems. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.

INCOSE. 2015. Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation (ISO)/International Electrotechnical Commissions (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015. 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.

Additional References

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

Holland, J.H. 2006. "Studying Complex Adaptive Systems." Journal of Systems Science and Complexity. vol. 19, no. 1 pp. 1-8. Available at: http://hdl.handle.net/2027.42/41486.

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

The Open Group. 2011. TOGAF, version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.

Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024