Physical Architecture

Once a logical architecture is defined, concrete physical elements have to be identified that could support functional, behavioral and temporal features, as well as expected properties of the system deduced from non-functional System Requirements.

Because of evolution of the context of use, or technological possibilities, the Physical Architecture made of System Elements, is supposed to change along the life cycle of the system in order it continues to perform its mission within limits of its required effectiveness. Whether evolutions impact Logical Architecture elements, allocations to System Elements could change. A Physical Architecture is equipped with specific Design Properties to challenge continuously the evolution.

Definition and purpose

The purpose of Physical Architecture Design is to create a physical concrete solution that performs the Logical Architecture, and that satisfies and trade-offs System Requirements.

A Physical Architecture is an arrangement of physical elements (System Elements, Physical Interfaces) which provides the design solution for a product, service, enterprise intended to satisfy Logical Architecture elements and System Requirements (adapted from ISO/IEC 26702). It is implementable through technologies.

Concepts and Principles

Concepts of System Element, Physical Interface, and Physical Architecture

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 for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, minerals), or any combination (adapted from ISO/IEC 15288:2008).

A Physical Interface is a System Element that binds physically two System Elements. Equivalent terms may be Link, or Connector.

Table 1 provides some examples of System Elements and Physical Interfaces.

TABLE 1 TABLE 1 - Examples of System Elements and Physical Interfaces

A complex system composed of thousands of physical and/or intangible parts is structured in several layers of systems and System Elements. To be mastered easily the number of elements in decomposition of one system is limited to a few ones; generally 5+ or - 2 elements.

FIGURE 1 FIGURE 1 - Layers of systems and System Elements

Every system in each layer of the decomposition is structured as a Physical Architecture.

A Physical Architecture is built from systems, System Elements and all necessary Physical Interfaces between these elements and with external elements (neighbor systems and/or System Elements in the considered layer; concerned elements of the context of the global System of Interest).

FIGURE 2 FIGURE 2 - Physical Architecture representation

Concept of Design Property

A Design Property is associated to a System Element, a Physical Interface, a Physical Architecture. It is a property obtained during design, through assignment of non-functional requirements, or estimate, analysis, calculation, simulation of a specific aspect, or obtained by definition in the case of an existing element.

If the designed element complies with a requirement, the Design Property should equal the requirement. Otherwise one has to identify discrepancy which treatment could conclude to modify the requirement, or the design, or identify a deviation.

Stakeholders have concerns that correspond to expected behavior facing operational, environmental, physical constraints, and more generally life cycle constraints. Stakeholders Requirements and System Requirements express these concerns as expected abilities from the system (example: usability, interoperability, security, expandability, environment suitability, etc.).

Designers are able to identify these abilities from requirements and to deduce corresponding quantitative or qualitative Design Properties to equip their Physical Architecture (example: reliability, availability, maintainability, modularity, robustness, operability, climatic environment resistance, dimensions limits, etc.)

A system Physical Architecture owns Design Properties that each of its elements may have partially or not, but that the arrangement of them owns.

Emergent Properties

Emergence is the principle that whole entities exhibit properties, which are meaningful only when attributed to the whole, not to its parts. Every model of a human activity system exhibits properties as a whole entity which derive from its component activities and their structure, but cannot be reduced to them (Checkland 1999).

System Elements interact between themselves and can create desirable or undesirable phenomena called "emergent properties," such as inhibition, interference, resonance, or reinforcement of any property. Definition of the system includes an analysis of interactions between System Elements in order to prevent undesirable properties and reinforce desirable ones.

A property which emerges from a system can have various origins: from a single System Element, from several ones, or from interaction between several ones (Thome, B. 1993) – see Table 2, also article from Dereck Hitchins at http://www.hitchins.net/EmergenceEtc.pdf

TABLE 2 TABLE 2 - Emergent properties

The notion of emergent property is used during design to highlight necessary derived functions and internal physical or environmental constraints. Corresponding “derived requirements” should be added to System Requirements baseline when they impact the System of Interest.

Allocation of Logical Elements to Physical Elements and Partitioning

Designing a candidate Physical Architecture of a system consists first to identify System Elements capable to perform Functions of the Logical Architecture, and to identify Physical Interfaces capable to carry Input-output Flows and control flows. These elements have also to take account Design Properties deduced from System Requirements.

Partitioning and allocation are activities to decompose, gather, or separate Functions in order to be able to identify feasible System Elements that support these Functions. Either they exist (re-usable), are re-purposed, or can be developed and technically implemented.

Partitioning and allocation use criteria to find potential affinities between functions. Designers use directly System Requirements and/or Design Properties as criteria to assess and select physical candidate System Elements and partitions of Functions; examples: similar transformations within same technology, similar level of efficiency, exchange of same type of Input-output Flows (information, energy, materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environment resistance level, etc., other enterprise constraints.

Designing Physical Candidate Architectures

The goal of Physical Design activities is to provide the “best” possible Physical Architecture made of suitable 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). There is no other way than producing several candidate Physical Architectures, assessing and comparing them, then selecting the most suitable one.

A candidate Physical Architecture is worked out according to affinity criteria, in order to build up a set of sub-systems and System Elements (i.e., separate, gather, connect, disconnect the network of System Elements and their Physical interfaces).

These criteria are the same as those used for partitioning and allocation of Functions to System Elements. To summarize, orientations can be:

• • Reduction of the number of Physical Interfaces
  • System Elements that can be tested separately
  • Modularity, i.e. low interdependence
  • Maintainability, replace-ability of System Elements
  • Compatible technology
  • Proximity of elements in space
  • Handling (weight, volume, transportation facilities)
  • Optimization of resources shared between elements
  • Etc.

Evaluating and selecting the preferred candidate

All viable Physical Architectures implement all required Functions after trade-offs are made. The preferred Physical Architecture represents the optimum design.

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

Certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global behavior of the candidate architectures, regarding System Requirements. Those analyses are gathered behind the terms “System Analysis” (see System Analysis topic).

Systems of Systems

Considering a set of existing Systems of Interest that have their own existence in their own context of use, one issue is to know if it is possible to constitute a System of Interest that includes those as System Elements. The higher level system has a mission, a purpose, a context of use, objectives and architectural elements. Engineering of such systems includes generally both reverse engineering and top down approach. It is the case when upgrading facilities in the frame of a company using information technology keeping legacy systems.

The architecture activity combines a top-down approach, but also a bottom-up approach induced by the necessity to integrate existing or legacy systems on which no or very few modifications can be applied. Additional tasks consist to identify capabilities and interfaces of these existing systems. The architecture activity has to answer two questions:

• how to fulfill requirements of the new System of Interest,
• how to manage with legacy systems.

Process Approach

Purpose

The purpose of the Physical Architecture Design Process is to define, select and synthesize a system Physical Architecture able to perform the Logical Architecture, equipped with specific Design Properties to challenge continuously stakeholder or environmental concerns, and able to satisfy and trade-off concerned System Requirements.

Generic inputs include the selected Logical Architecture, System Requirements, generic design patterns and properties that designers identify and use to answer requirements, outcomes from System Analysis, and feedback from Verification and 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, rejected solutions.

Activities of the Process

Major activities and tasks performed during this process include:

1. Partition and allocate functional elements to System Elements:
   1. Search for System Elements or technologies able to perform Functions, and Physical Interfaces to carry input-output, 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).
   2. Partition functional elements (Functions, Scenarios, input-outputs, triggers) using criteria, and allocate partitioned sets to System Elements (same criteria as previously).
   3. When it is impossible to identify a System Element that corresponds to a partitioned functional set, decompose the Function till being able to identify implementable System Elements.
   4. Check compatibility of technologies and with interfaces between selected System Elements.
2. Model and design candidate Physical Architectures; for each candidate:
   1. Because partitioned sets of Functions can be numerous, there are generally too many System Elements. For designing controllable architectures, System Elements have to be grouped into higher-level System Elements, so called sub-systems.
   2. Constitute several different sets of sub-systems corresponding to different combinations of elementary System Elements. One set of sub-systems plus one or several not decomposable System Elements form a candidate Physical Architecture of the considered system.
   3. Represent (using design 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 with external elements to the sub-system.
   4. Represent then the synthesized Physical Architecture of the considered system built from sub-systems, System Elements and Physical Interfaces inherited from the Physical Architecture of sub-systems.
   5. Equip the Physical Architecture with Design Properties such as modularity, evolution capability, adaptation capability to different environments, robustness, scalability, resistance to environmental conditions, etc.
3. Assess candidate Physical Architectures and select the most suitable:
   1. 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.)
   2. Assess candidate Physical Architectures against criteria. Select the most suitable one comparing scores and rationales regarding criteria. Use preferably the System Analysis Process to perform assessments – see System Analysis topic.
4. Synthesize the selected Physical Architecture
   1. Formalize physical elements and properties. Verify that System Requirements are satisfied and the solution is realistic.
   2. Identify derived physical and functional elements created for the necessity of design, and corresponding System Requirements.
   3. Establish traceability between System Requirements and physical elements, and allocation matrices between functional and physical elements.
5. Prepare acquisition of each system or System Element:
   1. Define its mission and objectives from allocated Functions and effectiveness.
   2. Define its Stakeholder Requirements (the concerned stakeholder being the current studied system). Additional information about development of stakeholder requirements can be found in Stakeholders Requirements topic.
   3. Establish traceability between its Stakeholder Requirements and design elements of the studied system. This allows traceability of requirements between two layers of systems.

Artifacts and Ontology Elements

This process may create several artifacts such as:

1. System Design Document (describes selected logical and physical architectures)
2. System Design Justification Document (traceability matrices and design choices)
3. System Element Stakeholder Requirements Document (one for each system or System Element)

This process handles the ontology elements of Table 3.

TABLE 3 TABLE 3 - Ontology elements handled within Physical Architecture Design

Note: The element "Interface" may include both functional and physical aspects. It can be used for technical management purpose.

Note: System Element Requirements become Stakeholder Requirements applicable to the System Element of the lower layer of decomposition.

Methods and Modeling Techniques

Physical Architecture Design uses modeling techniques such as:

• Physical Block Diagrams (PBD)
• SysML Block Definition Diagrams, Internal Block Diagrams (OMG. 2010), etc.

Practical Considerations

Major pitfalls encountered with Physical Architecture Design are presented in Table 4.

TABLE 4 TABLE 4 - Pitfalls

Proven practices with Physical Architecture Design are presented in Table 5.

TABLE 5 TABLE 5 - Proven practices

References

Works Cited

Citations

Primary References

Primary references.

Additional References

Additional References.

Comments from 0.5 Wiki

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

SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

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

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

blog comments powered by Disqus