04 December 2015

Architectural Design: Physical – SEBOK (36)

The purpose of physical architecture definition (or design) is to create a physical, concrete solution that accommodates the 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).

A physical architecture is an arrangement of physical elements (system elements and physical interfaces) which provides the designed solution for a product, service, or 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 are allocated to both the logical and physical architectures. The global system architecture is assessed with system analysis and when achieved becomes the basis for system realization.

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 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 binds two system elements together; this is similar to a link or a connector.

Types of System Elements and Physical Interfaces. (SEBoK Original)

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 systems and 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.

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.

Because of the evolution of the context of use or technological possibilities, the physical architecture which is composed of 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 elements, allocations to system elements may change. A physical architecture is equipped with specific design properties (glossary) 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 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.

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:

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

2.- Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria and allocate partitioned sets to system elements (using the same criteria).

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

4.- Check the compatibility of technologies and the compatibility of interfaces between selected system elements.

Model candidate physical architectures; for each candidate:

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

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 non-decomposable system elements form a candidate physical architecture of the considered system.

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

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

5.- Equip the physical architecture with design properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.

6.- 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:

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

Synthesize the selected physical architecture:

1.- Formalize physical elements and properties. Verify that system requirements are satisfied and that the solution is realistic.

2.- Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding system requirements.

3.- 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:

1.- Define the system or system element’s mission and objectives from allocated functions and effectiveness.

2.- Define the stakeholder requirements (the concerned stakeholder being the current studied system).

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