18、嵌入式分布式系统形式化方法与开发流程解析

嵌入式分布式系统形式化方法与开发流程解析

1. AutoFocus的输入定义分析与系统行为处理

AutoFocus目前提供基于符号模型检查的输入定义分析。在系统中，关键站计算机（Vital Station Computer）存在一些未定义行为，这是由站计算机要处理的状态报告所导致的。例如，在收集和发布状态下，St通道存在缺失的输入模式。根据假设，状态报告仅在为状态消息保留的协议时隙内发出，但诸如列车时钟漂移、网络抖动等故障行为可能会破坏这一假设，所以我们需要能够检测此类情况的完整输入定义。通过添加相应的转换，我们可以添加适当的反应，如向操作员控制台发出警告。

非关键站计算机（Non - vital Station Computer）的行为也存在未完成的输入定义情况。例如，在计算命令时，如果收到新报告，没有定义相应的反应。在这种情况下，模拟和代码生成会执行标准完成操作，即忽略收到的消息。由于关键站计算机的行为不会出现这种情况，默认的操作完成处理可能被认为是足够的。然而，关键站计算机的这种反应可能表明其计算出现故障，因此，为了提高整个系统的鲁棒性，对这些意外情况采取更复杂的反应（如系统关闭）可能是合理的。

在建立了完整的行为之后，我们要确保转换是确定性的，以消除另一个可能的缺陷来源。AutoFocus通过比较所有转换对的启用条件，检查是否有两个转换由相同的（控制和数据）状态及收到的消息启用。虽然这不一定会导致非确定性或故障行为，但在嵌入式系统中，这种情况通常是不希望出现的。由于两个组件已经被确定性地定义，因此在这里不需要进一步的步骤来实现鲁棒的实现。

2. 基于模型开发的步骤及优势

基于模型的开发旨在将形式化方法的结构化和精确性添加到开发过程中，同时由应用领域的模型而非数学形式主义驱动。它通过明确关注特定问题并为开发的每个步骤提供合适的、通常由计算机辅助软件工程（CASE）支持的技术，有助于降低开发过程的复杂性，具体步骤如下：
1. 步骤1：关联需求与模型 ：通过将非正式需求与系统和环境的模型相链接，我们可以机械地检查是否涵盖了所有非正式需求，追溯哪些需求与设计决策相关，并分析更改非正式需求对模型的影响。更重要的是，它有助于构建需求结构，更好地理解需求，并识别需求中的未决问题。
2. 步骤2：建模环境与接口 ：对环境及其与系统的接口进行建模，避免对环境的隐含假设，精确理解系统如何影响环境、环境如何对这些影响做出反应以及可以从环境中获取哪些数据。特别重要的是，我们要精确说明我们认为环境具有的哪些属性是理所当然的，以及为了实现系统所需的安全行为必须容忍哪些可能的故障行为。
3. 步骤3：定义系统抽象行为 ：定义系统的抽象、可能不完整和非确定性的行为，描述一个高级的初始设计，而不引入使设计复杂化或限制进一步决策的实现细节。此外，为进一步的分析和开发步骤奠定基础。
4. 步骤4：分析模型有效性 ：分析系统和环境的模型的有效性，确保它们对后续步骤有用。使用模拟或概念一致性检查，识别诸如环境的不现实行为、缺少输入定义或输出响应性等未决问题。
5. 步骤5：验证系统与环境行为 ：使用更强的技术来确定系统定义的行为是否确保了环境的预期行为。使用形式验证，表明在最优情况下系统保证了环境的安全要求；此外，使用故障分析，表明在对环境进行定量假设的情况下，也满足了中间要求。
6. 步骤6：应用结构细化 ：通过将系统分解为相互作用的子组件，添加关于系统架构的进一步设计决策。通过为每个子组件添加行为，确保细化后的系统实现了抽象系统。
7. 步骤7：限制非确定性或未定义行为 ：对引入组件的未充分指定的行为添加进一步的设计决策，从而在保持整体功能的同时，使系统的反应更加优化。
8. 步骤8：检查组件未定义行为 ：检查系统组件是否存在可能的未定义行为，识别在最终实现中需要解决的剩余未决行为。通过为未决行为添加标准反应，提高系统对意外行为的鲁棒性。

以下是基于模型开发步骤的mermaid流程图：

graph LR
    A[步骤1：关联需求与模型] --> B[步骤2：建模环境与接口]
    B --> C[步骤3：定义系统抽象行为]
    C --> D[步骤4：分析模型有效性]
    D --> E[步骤5：验证系统与环境行为]
    E --> F[步骤6：应用结构细化]
    F --> G[步骤7：限制非确定性或未定义行为]
    G --> H[步骤8：检查组件未定义行为]

3. 形式化方法在分布式系统设计中的适用性分析

使用形式化方法设计安全关键分布式系统是否合适是一个值得探讨的问题。到目前为止，许多分布式系统在没有使用这些形式化符号的情况下开发出来，它们确实存在，但并不真正安全。当这些系统崩溃时，其故障可能会对环境造成危险影响。

大多数现有的解决方案存在一些缺点：
- 部分性 ：从“传统”软件开发的角度来看，它们只能考虑实际开发的一小部分。例如，在某些情况下，仅对控制算法进行形式化指定，或者仅涉及系统的静态视图。
- 难度大 ：使用了许多不同的形式化符号，有些是专有的，有些是经过改编的。所有这些都需要深厚的软件数学背景，而且这些形式化符号非常专业化，要求软件工程师掌握所有这些符号似乎是不可能的。
- 验证困难 ：验证步骤需要一个可靠和稳定的基础，但系统需求文档（SRD）即使从长远来看也将是非正式的，不能作为这样的基础。上层开发阶段的验证基于“弱”技术，如“交叉阅读”和“检查”，这些技术在语义上相对较弱。

然而，形式化符号也有一些有趣的优点：
- 表达的部分性优势 ：这些符号专门用于静态或动态方面，关注点的分离有助于更相关的开发。
- 规范的精确性 ：使用形式化符号指定系统的部分与使用编程语言编码一样困难，但最终的规范更精确、抽象和可读。形式化方法具有精确性、抽象性和可读性等特点。精确性体现在形式化语言有明确的语义，只要语法正确，每个句子只有一种含义；抽象性使得编程不能使用编程语言进行规范，并且有助于降低系统的复杂性；可读性方面，形式化符号比编程语言更易于开发者之间共享语义。
- 满足重要需求 ：形式化符号可以表达系统的功能和非功能属性（即约束），并且根据所考虑的开发阶段的输入，可以对规范进行验证。

所有提出的技术有两个共同点：一是使用半形式化符号（如UML）作为所有开发的起点；二是形式化符号的可扩展性。由于UML及其底层过程将问题分解成较小的部分，因此可扩展性不再是一个问题。

4. 安全关键分布式系统的开发流程探讨

在证明了专用形式化符号是设计安全关键分布式系统（部分）的正确方法之后，还剩下两个问题：
1. 哪些形式化符号适合哪些设计/开发阶段？
2. 应该建议什么样的开发过程？

对于这些问题，没有具体的答案。目前呈现的解决方案中，除了一种情况外，没有遵循精确的开发过程。不过，可以考虑两种类型的方法：
- 长期方法 ：建议一种全新的、更侧重于形式化符号的开发过程。这种待发明的过程还远未完善，许多研究正在进行中，迟早会投入使用。然而，这种方法成本太高（仍然需要高技能的专家），不适合“经典”工业项目。
- 短期方法 ：建议一种设计/开发过程。从实际角度来看，开发团队有重要的背景需要尽可能地保留和丰富。对于当前的系统开发技术和明确（或隐含）涉及的过程，有必要进行扩展，使每个所需的形式化符号能够在设计/开发过程中找到合适的位置。例如，可以采用“传统V模型”，然后逐步确定可以使用哪些形式化符号。也就是说，形式化符号作为补充使用，每个形式化符号的选择基于开发者的专业知识和相应开发步骤的需求。

选择形式化符号还应直接取决于至少一个工具的可用性。合适的工具可以更好地评估专用的形式化规范。最终，形式化方法对于设计和规范关键系统是有用的，但需要一个适应半形式化符号的设计/开发过程。每个半形式化符号应与一个更形式化的符号相关联，并且后者应由工具支持。这种简单的设计/开发过程是二维的，垂直维度遵循“V循环模型”的下行线，水平维度允许将半形式化模型转换为通过适当支持工具评估的形式化模型。这种二维过程可以被视为任何经典开发过程的扩展，形式化符号是帮助设计/开发高度关键系统的额外（且更精确）的方式。

以下是两种开发方法的对比表格：
| 开发方法 | 特点 | 适用情况 |
| ---- | ---- | ---- |
| 长期方法 | 全新，更侧重于形式化符号，成本高，需高技能专家 | 不适用于“经典”工业项目，研究阶段 |
| 短期方法 | 扩展现有过程，形式化符号作为补充，基于开发者知识和需求选择符号 | 适合当前开发团队，可结合现有技术 |

嵌入式分布式系统形式化方法与开发流程解析

5. 形式化方法在不同系统中的具体体现

在关键站计算机和非关键站计算机的实际运行中，形式化方法的重要性得到了充分体现。关键站计算机由于状态报告处理导致的未定义行为，会影响整个系统的稳定性。例如，St通道在某些状态下缺失输入模式，可能会使系统无法准确响应环境变化。通过AutoFocus的输入定义分析，可以及时发现这些问题，并添加相应的转换和反应，如发出警告，从而提高系统的安全性。

非关键站计算机在计算命令时对新报告的无反应情况，虽然通过默认的标准完成操作（忽略消息）可以暂时解决，但从系统整体的鲁棒性考虑，可能需要更复杂的反应机制。这表明在系统设计中，即使是非关键组件，也需要谨慎处理未定义行为，以避免潜在的故障。

6. 基于模型开发步骤的深入理解

基于模型的开发步骤为系统开发提供了清晰的框架。每个步骤都有其独特的作用，并且相互关联，共同推动系统从抽象设计到具体实现的过程。

• 步骤1 - 关联需求与模型 ：这一步骤是整个开发过程的基础，它确保了系统的设计与用户的需求紧密相连。通过机械检查和追溯需求，可以及时发现需求中的漏洞和不一致性，避免在后续开发中出现问题。
• 步骤2 - 建模环境与接口 ：对环境和接口的精确建模，使开发者能够更好地理解系统与外部世界的交互方式。明确环境的属性和可能的故障行为，有助于设计出更具适应性和安全性的系统。
• 步骤3 - 定义系统抽象行为 ：在这个阶段，开发者可以专注于系统的核心功能，而不必过早考虑实现细节。抽象行为的定义为后续的细化和优化提供了方向。
• 步骤4 - 分析模型有效性 ：通过模拟和概念一致性检查，能够及时发现模型中的不合理之处，如环境的不现实行为或输入输出的缺失。这有助于在开发早期解决问题，降低开发成本。
• 步骤5 - 验证系统与环境行为 ：形式验证和故障分析确保了系统在各种情况下都能满足安全要求。这一步骤是系统安全性的重要保障。
• 步骤6 - 应用结构细化 ：将系统分解为子组件，并为每个子组件添加行为，使系统的架构更加清晰和模块化。这有助于提高系统的可维护性和可扩展性。
• 步骤7 - 限制非确定性或未定义行为 ：对未充分指定的行为进行细化，使系统的反应更加可预测和优化。这有助于提高系统的性能和稳定性。
• 步骤8 - 检查组件未定义行为 ：在最终实现之前，检查组件的未定义行为并添加标准反应，能够增强系统对意外情况的鲁棒性。

以下是对这些步骤的详细对比表格：
| 步骤 | 主要作用 | 关键成果 |
| ---- | ---- | ---- |
| 步骤1 | 关联需求与模型，确保需求覆盖和可追溯性 | 清晰的需求结构和影响分析 |
| 步骤2 | 建模环境与接口，明确交互方式和环境属性 | 精确的环境和接口模型 |
| 步骤3 | 定义系统抽象行为，专注核心功能 | 高级初始设计 |
| 步骤4 | 分析模型有效性，发现不合理之处 | 有效的模型和问题识别 |
| 步骤5 | 验证系统与环境行为，确保安全要求 | 安全可靠的系统设计 |
| 步骤6 | 应用结构细化，分解系统为子组件 | 清晰模块化的系统架构 |
| 步骤7 | 限制非确定性或未定义行为，优化系统反应 | 可预测和优化的系统行为 |
| 步骤8 | 检查组件未定义行为，增强鲁棒性 | 对意外情况有应对能力的系统 |

7. 形式化方法优缺点的综合考量

形式化方法在分布式系统设计中既有优点也有缺点，开发者需要综合考虑这些因素，合理应用形式化方法。

优点方面，其表达的部分性优势使得关注点分离，有助于更有针对性的开发。规范的精确性确保了系统的设计更加准确和可靠，提高了系统的质量。满足重要需求则使得系统能够更好地实现功能和非功能属性，并且便于验证。

缺点方面，部分性导致其只能覆盖实际开发的一部分，难度大要求开发者具备深厚的软件数学背景，验证困难则使得上层开发阶段的验证不够可靠。

为了充分发挥形式化方法的优势，同时克服其缺点，可以采取以下策略：
- 结合半形式化符号 ：以UML等半形式化符号为起点，逐步引入形式化符号，降低开发难度。
- 选择合适的工具 ：利用工具支持形式化符号的使用和验证，提高开发效率和准确性。
- 分阶段应用 ：根据开发阶段的需求，选择合适的形式化符号进行应用，避免过度使用。

8. 开发流程的选择与优化

在选择开发流程时，需要考虑开发团队的能力和项目的实际需求。长期方法虽然具有前瞻性，但成本高，不适合“经典”工业项目。短期方法则可以在保留开发团队现有背景的基础上，逐步引入形式化方法，是一种更实际的选择。

以下是短期方法的具体操作步骤：
1. 采用“传统V模型” ：以“传统V模型”为基础，确定开发的整体框架。
2. 确定形式化符号 ：根据开发团队的专业知识和每个开发步骤的需求，选择合适的形式化符号。
3. 工具支持 ：确保所选的形式化符号有相应的工具支持，以便更好地进行规范和验证。
4. 逐步引入 ：在开发过程中，逐步引入形式化符号，避免一次性引入过多导致开发困难。

mermaid格式流程图展示短期方法的开发流程：

graph LR
    A[采用“传统V模型”] --> B[确定形式化符号]
    B --> C[工具支持]
    C --> D[逐步引入形式化符号]

通过合理选择和优化开发流程，可以更好地应用形式化方法，提高安全关键分布式系统的设计和开发质量。