物理架构模型开发可用作“开发候选架构模型和视图”活动的任务，或系统架构定义流程的子流程（请参阅 系统架构文章）。 其目的是详细说明物理的、具体的解决方案的模型和视图，以适应 逻辑架构模型并满足和权衡系统要求。 一旦定义了逻辑架构模型（请参阅逻辑架构模型开发)，必须确定具体的物理元素，这些元素可以支持功能、行为和时间特征以及从非功能系统需求推导出的系统的预期属性（例如，限制更换过时产品，和/或持续的产品支持） .

物理架构模型是为产品 、 服务 或 企业 提供解决方案 的物理元素（ 系统元素和 物理接口）的排列 。 它旨在满足逻辑架构元素和系统要求 ISO/IEC/IEEE 26702 (ISO 2007)。 它可以通过技术系统元素来实现。 系统需求被分配给逻辑和物理架构。 最终的系统架构通过系统分析进行评估，完成后成为系统实现的基础。

在某些情况下，特别是当将多个系统定义为一个公共物理架构模型时，物理架构模型的驱动因素之一可能是接口标准； 这些物理接口很可能是这些系统最重要的问题之一。 这种接口标准很可能在系统要求的高层次上被强制要求。 另一方面，在物理架构模型开发过程中也有可能衍生出标准，这些标准可能是实现理想工程成果的关键推动因素，例如：系统系列、技术插入、互操作性和“开放系统”。 例如，今天的视频、高保真和计算机系统都受益于接口标准的采用。 其他例子存在于大多数工程领域，从螺母和螺栓，

注意：术语 物理架构 是 系统架构物理视图的缩写 。

概念和原则

系统元素、物理接口和物理架构模型

系统元素是系统的离散部分，可以实施以实现设计属性。 系统元素可以是硬件、软件、数据、人、过程（例如，向用户提供服务的过程）、程序（例如，操作员指令）、设施、材料和天然存在的实体（例如，水、有机体和矿物），或这些 ISO/IEC/IEEE 15288 (ISO 2015) 的任意组合。 物理接口 将 两个系统元素绑定在一起； 这类似于链接或连接器。 表 1 提供了一些系统元素和物理接口的示例。

表 1. 系统元素和物理接口的类型。 （SEBoK 原创）

由数以千计的物理和/或无形部分组成的复杂系统可以由多个系统层 和系统 元素构成。 一个系统的结构层次中的元素数量限制在少数，以便于管理系统定义； 一个共同的准则是 五个加或减两个 元素（参见图 1 中的插图）。

图 1. 系统层和系统元素（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

物理架构模型由系统、系统元素和这些元素之间的所有必要物理接口以及外部元素（所考虑层中的相邻或启用系统和/或系统元素以及全局上下文中的相关元素）构建而成。感兴趣的系统） - 参见图 2 中的插图。

图 2. 物理架构模型表示（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

设计属性

设计属性 是在系统架构期间获得的属性，并通过分配非功能性需求、估计、分析、计算、特定方面的模拟或通过定义与系统元素相关联的现有元素 创建 物理接口和/或物理架构。 如果定义的元素符合要求，则设计属性将与（或可能等于）要求相关。 否则，必须识别可能修改需求或设计属性的任何差异并检测任何偏差。

利益相关者的关注点与系统在操作、环境和/或物理约束以及更一般的生命周期约束中的预期行为相对应。利益相关者要求和系统要求 将这些关注点表达为系统的预期能力（例如，可用性、互操作性、安全性、可扩展性、环境适用性等）。 建筑师和/或设计师从需求中识别这些能力，并推断出相应的定量或定性设计属性，以适当地装备他们的物理架构模型（例如，可靠性、可用性、可维护性、模块化、稳健性、可操作性、气候环境耐受性、尺寸限制等） . 有关如何将其中一些属性包含在架构和设计中的进一步讨论，请参阅 相关学科 部分 中的 系统工程和质量属性一文。

逻辑元素到物理元素的分配和分区

为系统开发候选物理架构模型包括首先识别可以执行逻辑架构模型功能的系统元素，以及识别能够执行输入-输出流和控制流的接口。 在识别潜在元素时，系统工程师需要在逻辑架构中分配设计属性； 这些属性是从系统要求 推导出来的。 分区和分配是分解、收集或分离功能的活动，以便于识别支持这些功能的可行系统元素。 它们要么存在并且可以重用或重新利用，要么可以被开发并在技术上实现。

分区和分配使用标准来查找功能之间的潜在关联。 系、能源和材料）、集中式或分布式控制、接近频率水平的执行、可靠性条件、环境阻力水平和其他企业约束。

当需要几组不同的技术、知识和技能来建立候选物理架构模型时，需要采用并行工程方法。 在对各种系统元素进行功能划分和分配期间尤其如此，其中系统工程师必须考虑兼容性问题和 紧急属性。 （有关可能的方法的讨论， 请参见 SEBoK 第 2 部分：综合可能的解决方案。）

开发候选物理架构模型

物理架构模型开发活动的目标是提供由合适的系统、技术系统元素和物理接口组成的最佳物理架构模型（即，根据商定的限制或余量，最多可以满足所有系统要求的架构）每个要求）。 最好的方法是产生几个候选的物理架构模型，对它们进行评估和比较，然后选择最合适的一个。

候选物理体系结构模型根据亲和性标准进行详细说明，以构建一组系统元素（即，分离、聚集、连接和断开系统元素的网络及其物理接口）。 这些标准与用于对系统元素进行分区和分配功能的标准相同。 物理架构模型开发可能以不同的方式关注，例如，它可能解决：

• 减少物理接口的数量
• 可单独测试的系统元素
• 兼容技术
• 空间元素接近度的度量
• 易于处理（重量、体积和运输设施）
• 优化元素之间共享的资源
• 模块化（即元素的相互依赖性低）
• 弹性（即高度可靠、可维护或可替换的元素）

评估和选择首选候选人

可行的物理架构模型能够实现逻辑架构模型中指定的所有必需功能或能力。 架构和设计活动包括评估以获得设计属性、成本、风险等之间的平衡。通常，系统的物理架构模型更强烈地由非功能性需求（例如，性能、安全性、安全性、环境条件、约束等）而不是按功能。 可能有许多（物理）方法来建立功能，但满足非功能性需求的方法较少。 首选物理架构模型代表系统元素、它们的物理关系和接口的选择。 通常， 在做出任何剩余的权衡并最终确定系统的算法和参数之后，这种物理架构仍将进行进一步的系统工程以实现完全优化的系统。 需要进行某些分析（效率、可靠性、成本、风险等）以获得足够的数据来表征候选架构在系统要求方面的全局行为和结构； 这通常被广泛称为系统分析。 其他分析和评估需要来自不同相关技术和专业（机械、电子、软件、热力学、电磁兼容性、安全性、安保等）的知识和技能。 它们是通过系统的相应专家分析来执行的。

遗留系统和系统系统

很少有系统在不与系统上下文 中的其他系统交互的情况下存在或运行 。 这些交互可能与其他运营系统或维护和支持系统有关，而这些系统又可能是遗留系统（已经在使用）或未来遗留系统（正在开发中并且可能与未来感兴趣的系统一起运行）。

最佳选择的方法将取决于 感兴趣系统(SoI) 与其更广泛的上下文之间的交互强度。 虽然这些交互很小，但可以通过定义一组系统必须遵守的静态外部接口要求（例如技术标准）来解释它们，方法是将这些作为约束条件包含在系统要求中，并通过设计保证确保合规性。

在交互更密集的情况下（例如，在与其他系统交换连续信息的情况下），这些将必须被视为 系统上下文系统的一部分，而将被视为企业系统工程 方法的一部分。

另一个重要的考虑因素可能是在 SoI 和其他系统之间共享技术或系统元素，通常作为系统系列的一部分（许多示例发生在汽车和航空航天工业中）或重用现有遗留系统元素。 这里需要一定程度的自上而下或中间出设计工作，以确保感兴趣的系统体现所需的系统元素，同时尽可能符合利益相关者和系统要求，任何妥协都被理解和管理。

如果感兴趣的系统旨在用于一个或多个服务系统或 系统配置系统，这将影响其物理架构模型。 这些 SoS 的特性之一是使用中的组件系统的后期绑定。 此类组件系统必须使用开放或可配置的接口进行架构，必须具有明确定义的功能，并以与使用它们的 SoS 相关的方式打包，并且必须包含一些方法，以便在需要时识别并包含在 SoS 中.

服务系统和 SoS 都将由高级物理架构模型定义，该模型将用于定义应包含在概念定义 中的相关 SoS 关系、接口和约束。 结果将嵌入利益相关者和系统需求中，并在开发、实现和使用过程中通过接口协议和跨项目通信进行处理。

有关构建 SoS 的特殊注意事项的更多信息， 请参阅 SEBoK 第 4 部分：系统工程的应用。

过程方法

目的

物理架构模型开发的目的是定义、选择和综合一个能够支持逻辑架构模型的系统物理架构模型。 物理架构模型将具有解决利益相关者关注或环境问题并满足系统要求的特定属性。

由于使用环境或技术可能性的演进，由系统元素组成的物理架构 应该沿着系统的生命周期演进，以便在其所需的有效性范围内继续执行其任务. 根据演化是否影响逻辑架构 模型元素，对系统元素的分配可能会改变。 物理架构模型配备了特定的设计属性，以不断挑战进化。

通用输入 包括选定的逻辑架构模型、系统需求、架构师识别和利用以回答需求的通用模式和属性、系统分析的结果以及系统验证和系统确认的反馈。

通用输出 是选定的物理架构模型、功能元素到物理元素的分配矩阵、具有系统需求的可追溯性矩阵、构成物理架构模型的每个系统和系统元素的利益相关者需求以及被拒绝的解决方案。

进程的活动

在此过程中要执行的主要活动和任务包括：

• 将功能元素划分并分配给系统元素：
  • 寻找能够执行功能和物理接口以承载输入输出和控制流的系统元素或技术。 确保系统元素存在或可以设计。 使用从设计属性推导出来的标准（它们本身从非功能性系统需求推导出来）评估每个潜在的系统元素。
  • 使用给定的标准对功能元素（功能、场景、输入输出、触发器等）进行分区，并将分区集分配给系统元素（使用相同的标准）。
  • 当无法识别对应于分区功能集的系统元素时，分解功能直到可以识别可实现的系统元素。
  • 检查技术的兼容性以及所选系统元素之间接口的兼容性。
• 构成候选物理架构模型。
  • 因为分区的功能集可能很多，所以通常有太多的系统元素。 为了定义可控架构，必须将系统元素分组为称为系统元素组的更高级别的系统元素，在工业中通常称为子系统。
  • 构成若干不同的系统元素群，对应于基本系统元素的不同组合。 一组系统元素组加上一个或几个不可分解的系统元素形成了所考虑系统的候选物理架构模型。
  • 表示（使用模式）每个系统元素组的物理架构模型，将其系统元素与承载输入输出流和触发器的物理接口连接起来。 根据需要添加物理接口； 特别是，将带有外部元素的接口添加到系统元素组中。
  • 表示从系统元素组、不可分解系统和继承自系统元素组的物理架构模型的物理接口构建的所考虑系统的综合物理架构。
  • 增强物理架构模型的设计属性，如模块化、进化能力、对不同环境的适应性、鲁棒性、可扩展性、对环境条件的抵抗力等。
  • 如果可能，使用可执行架构原型（例如，硬件-软件 (HW-SW)-in-the-loop 原型）来识别潜在缺陷并根据需要更正架构。
• 评估物理架构模型候选并选择最合适的模型：
  • 使用系统分析过程执行评估（请参阅系统分析主题）。
  • 使用决策管理流程来支持交易和首选备选方案的选择（请参阅决策管理主题）。
• 综合选定的物理架构模型：
  • 形式化物理元素和属性。 验证是否满足系统要求以及解决方案是否切合实际。
  • 识别为架构和设计的必要性以及相应的系统要求而创建的派生物理和功能元素。
  • 在系统需求和物理元素之间建立可追溯性，并在功能元素和物理元素之间分配矩阵。

工件、方法和建模技术

物理架构描述使用建模技术来创建和表示物理架构。 一些常见的物理模型包括结构块、体量、布局和其他模型。 建模技术可能是：

• 物理框图 (PBD)
• SysML 块定义图 (BDD)
• 内部框图 (IBD) (OMG 2010)
• 可执行架构原型
• 等等。

根据要使用的领域类型（国防、企业等）， 架构框架可以提供有助于权衡候选架构的描述。 请参阅企业系统工程关键概念中的“企业架构框架和方法”部分。

实际考虑

接下来的两节将描述与物理架构开发相关的关键缺陷和良好实践。

缺陷

表 3 提供了在执行物理架构模型开发过程中遇到的一些关键缺陷。

表 3. 物理架构开发的缺陷。 （SEBoK 原创）

===经过验证的实践===+

表 4 提供了从参考文献中收集到的一些经过验证的实践。

表 4. 物理架构开发的成熟实践。 （SEBoK 原创）