逻辑体系结构模型开发可以用作活动“开发候选体系结构模型和视图”的任务，或者是系统体系结构定义过程(参见系统体系结构)的子过程。它的目的是细化未来工程系统的功能和行为的模型和视图，因为它应该在服务中运行。一个工程系统(SoI)的逻辑架构模型由一组相关的技术概念和原则组成，这些概念和原则支持系统的逻辑操作。它可能包括功能体系结构视图、行为体系结构视图和时间体系结构视图。在体系结构框架中还建议其他视图，具体取决于领域。

注意:术语逻辑架构是表达系统架构的逻辑视图的缩写。

概念和原则

功能体系结构模型

功能架构模型是一 组功能及其子功能，它们定义了系统为完成其任务而执行的转换。

功能和输入-输出流 ——在系统架构的上下文中，功能和输入-输出流是架构实体。函数是一种 转换输入并生成输出的动作，涉及数据、材料和/或能量。 这些输入和输出是函数之间交换的流项。 函数的一般数学符号是 y = ƒ( x ,t) ，其中 y 和 x 是可以用图形表示的向量，t = 时间。

为了定义系统的完整功能集，必须识别系统所需的所有功能及其派生需求，以及这些功能的相应输入和输出。 一般来说，有两种功能：

1. 直接从功能和接口需求推导出来的功能。 这些功能表达了系统满足其系统要求所必需的预期服务。
2. 从物理架构 模型的替代解决方案派生和发布的功能， 并且取决于设计的结果； 此外，他们依靠技术选择来实现逻辑架构模型元素。

功能层次结构/功能分解 - 在层次结构的最高级别（图 1），可以将系统表示为一个独特的中心功能（定义为系统的任务），在许多方面类似于“黑匣子” ”（图 1 中的 A-0 计划中的“F0”）。 为了详细了解系统的功能，将此“层级负责人”（F0）分解为子功能（F1、F2、F3、F4），分组形成层级的子级别（计划 A0）等等。 功能层次结构的最后一级的功能可以称为叶功能（计划 A2 中的 F21、F22、F23、F24）。 层次结构（或分解）将一个复杂的或全局的功能分解为一组功能，这些功能的物理解决方案是已知的、可行的或可以想象的。

这种功能层次视图代表了功能的静态视图，根据所使用的综合方法 ，这些功能将在多次迭代中以不同级别填充。 通常，它不是由单个自上而下的分解创建的。 静态功能层次结构本身并不代表输入和输出流的交换效率，可能需要与下面的其他模型一起查看。

图 1. 功能分解（Faisandie 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。

行为架构模型

行为架构模型是功能及其子功能以及接口（输入和输出）的排列，它定义了执行顺序、控制或数据流的条件以及满足系统要求（ISO/IEC）所必需的性能 水平 26702:2007)。 行为架构模型可以描述为一组相互关联的功能和/或操作模式场景。

控制（触发器） - 控制流是一个元素，它激活一个函数作为其执行的条件。 此元素的状态或它所代表的条件激活或停用功能（或其元素）。 控制流可以是信号或事件，例如将开关移至 打开 位置、警报、触发器、温度变化或按下键盘上的键。

场景（函数） - 函数场景是一系列函数，它们作为序列执行并由一组控制流同步，以实现输入到输出的全局转换，如下图所示。 函数场景表达了上层函数的动态。 通过考虑功能层次结构的每个级别和系统层次结构的每个级别的两种情况来开发行为架构。 在表示功能和行为架构模型的场景时，使用图表作为建模技术是合适的，例如功能流程图 (FFBD) (Oliver, Kelliher, and Keegan 1997) 或使用 SysML (OMG 2010) 开发的活动图。 图 2 和图 3 提供了这些图表的示例。

图 2. 场景说明 (eFFBD)。（SEBoK 原创）

图 3. 场景图解（活动图）。 （SEBoK 原创）

操作模式 - 可以通过抽象将输入转换为每个功能的输出并关注功能及其控件的活动或非活动状态来查看功能场景。 此视图称为 模式场景 ，它是一系列模式，作为系统各种模式之间的一系列转换执行。 从一种模式到另一种模式的转换是由控制流（事件/触发器）的到达触发的。 如下图 4 所示，可以在事件或触发器到达后在两种模式之间的转换中生成动作（功能）。

图 4. 运营模式情景（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

行为模式 ——在定义场景或行为架构模型时，架构师可以选择识别和使用已知模型来表示预期的转换和行为。 模式是通用的基本模型，根据处理的复杂性可能或多或少复杂（Gamma、Helm、Johnson 和 Vlissides 1995）。 一个模式 可以用不同的符号表示。 行为模式分为几类，可以在以下示例中看到（另见 SEBoK 第 2 部分：系统思维模式）：

• 基本模式或构造链接功能 - 例如序列、迭代、选择、并发、多个出口、带出口的循环和复制。
• 复杂的模式——例如监控治疗、交换消息、人机界面、模式监控、流程的实时监控、队列管理和带监督的持续监控。
• 故障检测、识别和恢复 (FDIR) 模式 - 例如被动冗余、主动冗余、半主动冗余和性能降低的处理。

时间架构模型

时序架构 模型是根据 执行频率级别推导出的系统功能分类。 时间架构模型包括功能的同步和异步方面的定义。 系统内部发生的决策监视遵循相同的时间分类，因为决策与功能的监视有关。

时间和决策层次概念 - 并非系统的每个功能都以相同的频率执行。 频率根据时间和功能启动和执行的方式而变化。 因此，必须考虑几类性能。 有循环执行的同步函数和在事件或触发器发生后执行的异步函数。

更具体地说， 实时 系统和 命令控制 系统结合了循环操作（同步）和事实方面（异步）。 循环操作包括根据频率共享功能的执行，这取决于捕获或分派输入/输出和控制流的约束。 可以区分两种类型的异步事件：

1. 高频干扰（图 5 底部）- 在它们发生的级别或上一级做出的决定。 目标是阻止干扰影响低频，以便系统继续实现其任务目标。 这是引入异常操作的方式，典型的例子与操作问题、故障或失败有关。
2. 低频变化（图 5 顶部）——与上层做出的变化有关的决定。 最终目标是将它们传送到底层以实施修改。 一个典型的例子涉及操作员的操作、维护操作等。

图 5. 时间和决策层级（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

过程方法

目的

逻辑架构模型开发的目的是定义、选择和综合系统的逻辑架构模型，以提供一个框架来验证未来系统在所有操作场景中是否满足其系统要求，其中系统之间的权衡在开发此类系统时可以探索需求。

流程的通用输入包括系统需求、架构师识别和用于回答需求的通用架构模式、系统分析流程的结果以及系统 验证 和 确认流程的反馈 。 根据所选择的生命周期模型，将有这些输入和输出以及它们之间的关系在整个过程中演变和变化的迭代（另请参见应用生命周期过程）。

流程的一般输出是单个逻​​辑架构模型或一组候选逻辑架构模型以及所选的独立逻辑架构模型及其选择的基本原理。 它们至少包括视图和模型。 这些涉及功能、行为和时间视图，逻辑架构模型元素和系统需求之间的可追溯性矩阵。

进程的活动

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

• 识别和分析功能和行为要素：
  • 通过分析功能、接口和操作需求，从系统需求中 识别功能、输入-输出流、操作模式、模式转换和操作场景。
  • 为每个功能和输出定义必要的输入和控制（能量、材料和数据流），从而扣除必要的功能以使用、转换、移动和生成输入-输出流。
• 将系统要求分配给功能和行为元素：
  • 通过分配性能、有效性和约束要求，正式表征函数表达式及其属性。 特别是，研究需求的时间方面，以将持续时间、响应时间和频率分配给功能。
  • 通过分配接口、有效性、操作、时间和约束要求，正式表征输入、输出和控制流表达式及其属性。
  • 在系统需求与这些功能和行为元素之间建立可追溯性。
• 为每个候选定义候选逻辑架构模型：
  • 分析系统要求（如果有）中所述的操作模式和/或使用先前定义的元素来模拟操作模式的序列和模式的转换。 最终将模式分解为子模式，然后为每个操作模式建立一个或几个功能识别和/或使用相关通用行为模式的场景。
  • 整合这些功能场景以获得系统的行为架构模型（动态行为的完整图景）。
  • 根据需要分解先前定义的逻辑元素以实现实现。
  • 将时间约束分配和合并到先前定义的逻辑元素，例如时间段、持续时间、频率、响应时间、超时、停止条件等。
  • 为与决策级别对应的功能定义多个级别的执行频率，以便监控系统操作，在此时间基础上优先处理处理，并在这些执行频率级别之间共享功能以获得时间架构模型。
  • 执行功能故障模式和影响分析，并根据需要更新逻辑架构元素。
  • 使用模拟器执行模型（如果可能）并调整这些模型以获得预期的特性。
• 综合选定的独立逻辑架构模型：
  • 通过根据评估标准（与系统需求相关）评估候选逻辑架构模型并比较它们来选择逻辑架构，使用系统分析过程执行评估和决策管理过程以进行选择（请参阅系统分析和决策管理主题）。 这种选择的逻辑架构模型被称为 独立的逻辑架构模型 ，因为它尽可能地独立于实现决策。
  • 识别和定义为设计的必要性创建的派生逻辑架构模型元素，并与派生的系统需求相对应。 将这些要求分配给适当的系统（当前研究的系统或外部系统）。
  • 验证和验证选定的逻辑架构模型（尽可能使用可执行模型），根据需要进行更正，并在系统需求和逻辑架构模型元素之间建立可追溯性。
• 反馈逻辑架构模型开发和系统需求。 此活动在物理架构模型开发过程之后执行：
  • 如果可以将分配的逻辑架构 建模 到系统和系统元素，并根据需要添加任何功能、行为和时间元素以同步功能和处理。
  • 定义或整合由所选逻辑和物理架构模型引入的派生逻辑和物理元素。 定义相应的派生需求并将它们分配给适当的逻辑和物理架构元素。 将这些派生的需求合并到受影响系统的需求基线中。

工件、方法和建模技术

逻辑架构描述使用归类于以下模型类型的建模技术。 已经开发了几种方法来支持这些类型的模型（一些是可执行模型）：

• 功能模型——包括结构化分析设计技术 (SADT/IDEF0)、系统分析和实时 (SA-RT)、增强功能流程图 (eFFBD) 和功能分析系统技术 (FAST) 等模型。
• 语义模型——包括实体关系图、类图和数据流图等模型。
• 动态模型——这些模型包括状态转换图、状态图、eFFBD、状态机图 (SysML)、活动图 (SysML) (OMG 2010) 和 petri 网。

根据领域的类型（例如国防、企业），架构框架提供的描述可以帮助表示架构的其他方面/视图 - 请参阅企业系统工程关键概念中的“企业架构框架和方法”部分。 另请参阅使用与 ISO/IEC/IEEE 42010 (ISO 2011) 相关的通用模板的实用方法。

实际考虑

如上所述，逻辑架构模型的目的是描述系统必须能够做什么才能满足规定的需求。 这应该有助于确保所有利益相关者的需求和/或关注点都能通过任何解决方案得到解决，并且可以考虑创新解决方案以及基于当前解决方案技术的解决方案。 在实践中，问题利益相关者推动他们自己的议程以及解决方案架构师或设计师提供他们熟悉的解决方案是人类的天性。 如果逻辑架构模型没有在选定的生命周期中正确实施，问题和解决方案的利益相关者很容易忽略它并恢复他们自己的偏见（请参阅第 5 部分：启用系统工程）。 如果逻辑架构模型本身成为终结或与主要生命周期活动脱节，则这种情况会更加严重。 这可以通过使用抽象语言或符号、详细程度、所花费的时间或与创建它的目的不匹配的过于复杂的最终架构来实现。 如果架构的语言、范围和及时性与问题利益相关者或解决方案提供者不匹配，他们就更容易忽视它。 接下来的两节将描述有助于避免与逻辑架构模型相关的问题的关键缺陷和良好实践。

缺陷

表 1 提供了开发逻辑架构时遇到的一些关键缺陷。

表 1. 逻辑架构开发的缺陷。 （SEBoK 原创）

实践证明

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

表 2. 经验证的逻辑架构开发实践。 （SEBoK 原创）