Table of Contents
- 4.1. Define Physical Architecture
- 4.2. Allocate Requirements to Components and Interfaces
- 4.c. Physical Chains all
Introduction
“The Physical Architecture of a system is a hierarchical description of the resources that comprise the system... [It] provides resource for every function identified in the functional architecture” [Buede 2009]. It defines the physical components of the system and "serves as the integrating framework for all components to work together" [Friedenthal et al. 2012]. The definition of the physical architecture is a step that is present in many major systems engineering frameworks. For example, the INCOSE Systems Engineering Handbook presents the "Synthesize Candidate Physical Architectures" step in the context of the Object-Oriented Systems Engineering Methodology (OOSEM), where the physical architecture describes "relationships among physical system elements, including hardware, software, data, people, and procedures." [INCOSE, 2015, p.196].
The physical architecture view 4.1. depicted in Fig. 1 shows the relationships between the view 4.1. and other arKItect SEA views. The view 3.1. Functional Architecture Design is related to the view 4.1. via the allocation of system functions and flows to components and physical interfaces. We will provide definitions for components and physical interfaces in the following.
Fig. 1: Pyhsical architecture step in arKItect SEA
Definitions
In the following, we provide the definitions of the physical architecture modeling elements:
- Components: “A Component is a coherent and somewhat independent ‘component’ of a larger system” [Ericson 2011].
- Physical Interfaces: physical means to support the Flows between:
- the System and its environment,
- the Components.
Thus, we have the Physical Interfaces at two levels: internal and external.
- Physical Relations: links to connect Components and Physical Interfaces.
- Link Areas: connection zones inside Components to support Physical Relations.
Table provides a comparison of the arKItect SEA physical architecture model elements and corresponding model elements from the INCOSE Systems Engineering Handbook, NASA Systems Engineering Handbook, the ISO/IEC/IEEE 42010 standard, and the 4+1 View Architecture Model. Although the model elements vary in abstraction, there is at least partial correspondence between the model elements in all references. The INCOSE SE Handbook and the NASA SE Handbook basically use the same language for describing physical architectures. The ISO/IEC/IEEE 42010 standard is more generic and briefly mentions the "physical view" and interfaces between architecture elements. The 4+1 View Architecture Model that is intended for an application to software-intensive systems includes a physical view with components and connectors. By contrast, the notion of interface is missing. The OOSEM methodology presented in [Friedenthal et al., 2012] is based on the System Modeling Language (SysML). The equivalent of "component" in arKItect SEA is "physical component". Physical components have interfaces that are represented by ports. Connectors represent connections between ports.
Table 1: Comparison of arKItect SEA physical architecture model elements and major systems engineering references
| arKItect SEA | INCOSE SE Handbook [INCOSE, 2015] | NASA SE Handbook [NASA, 2007] | ISO/IEC/IEEE 42010 [ISO/IEC/IEEE, 2011] | 4+1 View Architecture Model [Kruchten, 1995] | OOSEM SysML methodology [Friedenthal et al., 2012] |
|---|---|---|---|---|---|
| Physical architecture | Physical architecture | Physical architecture | Physical view | Physical view | Physical architecture |
| Component | Component | Component | - | Component | Physical component |
| Physical interface | Physical interface | Physical interface | Interface | - | Port |
| Physical relation | Relationship | Relationship | - | Connector | Connector |
Objectives
In this step, the objective is to design the Physical Architecture with Physical Interface and components of the studied System and then to allocate Requirements to them. Using the LapTop example, we will here define physical relations between LapTop and its environment and within the LapTop's components.
We will define here:
- Physical Interfaces,
- components.
We will allocate here:
- Requirements.
Figure 1 shows the final result of the LapTop example in this view.
Figure 1. Final result of the Physical Architecture of LapTop
In the next sections, we'll explain the sub-views of the view 4 which allow to define Physical Architecture and to allocate Requirements to its Components and Interfaces. The points are explained in two parts:
- in a graphical view called Internal Block Diagram (IBD, below the toolbar, see figure 2),
- in a tabular view (available through Project Tools icon in the toolbar, see figure 3).
Figure 2. Internal Block Diagram tab
Figure 3. Project Tools icon to access Tabular Views
References
Buede, D. M. (2009). Physical architecture development. The Engineering Design of Systems: Models and Methods, Second Edition, 252-283.
Ericson, C. A. (2011). Concise encyclopedia of system safety: definition of terms and concepts. John Wiley & Sons.
ISO/IEC/ IEEE (2011). International Standard ISO/IEC/ IEEE 42010
Kruchten, P. B. (1995). The 4+ 1 view model of architecture. IEEE software, 12(6), 42-50.
NASA, S. (2007). NASA systems engineering handbook. National Aeronautics and Space Administration, NASA/SP-2007-6105 Rev1.
Walden, D. D., Roedler, G. J., Forsberg, K., Hamelin, R. D., & Shortell, T. M. (Eds.). (2015). Systems engineering handbook: A guide for system life cycle processes and activities.