22、嵌入式系统跨学科接口设计与模型验证

最新推荐文章于 2025-10-26 15:56:45 发布

gamma

最新推荐文章于 2025-10-26 15:56:45 发布

阅读量49

点赞数

CC 4.0 BY-SA版权

分类专栏：敏捷MBSE：从理论到实践文章标签：嵌入式系统跨学科接口设计模型验证

本文链接：https://blog.youkuaiyun.com/gamma/article/details/151602468

敏捷MBSE：从理论到实践专栏收录该内容

28 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

嵌入式系统跨学科接口设计与模型验证

1. 跨学科接口设计的重要性

在嵌入式系统开发中，跨学科接口的定义至关重要。例如，在选择处理器时，经过分析确定 32 位、运行频率为 120 MHz、拥有 1 MB ROM 和 1 MB RAM 的 STM32F2 ARM 处理器最符合需求和未来扩展。然而，开发中常见的失败点是未能充分确定跨学科接口，尤其是电子 - 软件接口。软件工程师倾向于开发便于软件实现的接口，电子工程师则侧重于简化电子设计的接口，因此跨学科接口最好由所有相关工程学科合作开发。

2. 跨学科接口设计流程

以下是跨学科接口设计的具体流程：
1. 明确目的 ：详细说明系统或子系统设计中各工程方面之间的交互。
2. 输入和前提条件 ：
- 明确部署架构（通常是子系统）的外部接口和职责（需求）。
- 理解各工程方面对设计的贡献（即分配给各方面的需求）。
3. 输出和后置条件 ：完成设计后，各学科之间的接口应得到充分定义，以支持相关方面的设计。

3. 具体操作步骤

审查对工程方面的分配 ：回顾之前分配给不同工程学科的需求、值和功能，清晰理解各工程方面的贡献是创建良好跨学科接口的关键步骤。
识别需与其他方面交互的方面属性 ：接口旨在定义协作元素之间的交互。例如，电子传感器为软件提供值进行处理，软件方面的设备驱动程序需与电子方面的实际传感器交互，这会产生某种服务或流连接。
定义需交互的方面之间的端口对 ：确定两个方面的属性需交互后，定义它们之间的端口对，以传递将添加到接口的值或服务调用。
定义不同方面属性之间的交互 ：接口需明确方面之间交互的具体性质。例如，软件传感器设备驱动程序可能向硬件寄存器写入信号，等待至少 1 毫秒后读取值并进行缩放。
适当捕获交互元数据 ：元数据用于捕获接口中不明显或难以用其他方式建模的方面。如传感器控制寄存器中，写入位 0 为 1 可激活传感器，写入 0 无效果；位 1 - 5 可能提供只读错误代码。软件激活传感器后需等待 1 毫秒才能读取值，这一信息需作为元数据在接口中捕获。
将跨方面的交互分组到接口中 ：所有方面之间的交互都应在接口中捕获，包括如何被各方面访问的相关信息。软件与电子接口常见的技术手段是内存映射寄存器和硬件生成的软件中断。
在接口利益相关者之间协商接口细节 ：各工程学科应能自由运用专业技能开发方面，同时所有利益相关者（包括系统工程师、软件工程师、电子工程师和机械工程师）应就接口规范达成一致。
将商定的接口存储在配置管理中 ：即使接口未来可能更改，也应建立一个“已知目标”。存储接口可建立基线和真实来源，若发现接口不足，可重新协商并更新配置管理基线。

4. 示例：动力传动子系统接口定义

以动力传动子系统接口定义为例，具体操作如下：
1. 审查对工程方面的分配 ：回顾之前的示例，审查需求、值和功能分配。
2. 识别需与其他方面交互的方面属性 ：关注分解到不同方面的子系统特征，避免过度指定方面设计。
3. 定义需交互的方面之间的端口对 ：之前已定义端口并添加空接口。
4. 定义不同方面属性之间的交互 ：使用 SysML 代理端口，将交互捕获为接口块。软件 - 电子接口主要由硬件寄存器组成，如 iSW_EE_Control 和 iSW_EE_Comm 接口块包含控制和数据寄存器。控制寄存器用于触发硬件动作或读取状态信息，数据寄存器用于传输数据。iSW_EE_Comm 接口块还有两个 64 字节块，用于发送和接收 CAN 总线消息。
5. 适当捕获交互元数据 ：创建一组构造型并放入交接配置文件中，用于建模接口的相关元数据。
6. 将跨方面的交互分组到接口中 ：已将接口块特征直接添加到接口块中。
7. 在接口利益相关者之间协商接口细节 ：利益相关者开会审查和协商接口细节，接口将成为各方遵守的合同。
8. 将商定的接口存储在配置管理中 ：将定义的接口在配置管理中建立基线，各方同意遵守。若后续发现问题，可重新协商接口定义。

5. 模型验证与确认

系统开发需要证明系统满足利益相关者的需求，包括提供认证和系统维护所需的重要信息（如可追溯性）、向利益相关者展示工作产品内容（如演练和模拟）、支持分析（如模拟和分析）、证明设计满足需求（验证）以及证明系统满足利益相关者需求（确认）。这一过程贯穿系统开发的始终。

6. 模型验证的相关方法

以下是一些模型验证的方法：
1. 模型模拟
2. 基于模型的测试
3. 可计算约束建模
4. 可追溯性
5. 有效的审查和演练
6. 测试驱动的建模

7. 模型的局限性

乔治·博克斯曾说“所有模型都是错误的，但有些是有用的”。在系统领域中，模型是对真实系统的近似，存在以下局限性：
1. 抽象性 ：模型专注于系统的相关细节，忽略其他方面，因此不包含系统的所有方面。
2. 细节层次 ：模型在不同细节层次上表示信息，如模拟水处理系统中的流体流动时，不考虑分子层面的相互作用。
3. 精度：模型以认为足够的精度表示信息，如模拟飞机方向舵控制面的运动时，可能只需要三位有效数字和 ± 0.5 度的精度。

8. 模型正确性的判断

考虑模型时会产生以下问题：
1. 模型是否正确？
2. 正确意味着什么？
3. 如何判断？

对于“正确”的定义，如果认为好的模型有明确的范围和目的，那么正确意味着以必要的精度和正确性解决该范围以满足其目的。判断模型是否正确，需证明其满足范围和目的，可通过生成证据来确认。

9. 总结

跨学科接口设计和模型验证是系统开发中不可或缺的环节。跨学科接口设计需要各工程学科的协作，遵循明确的流程和步骤，以确保接口的合理性和有效性。模型验证则需要采用多种方法，认识到模型的局限性，并通过生成证据来判断模型的正确性。只有这样，才能开发出满足利益相关者需求的系统。

以下是跨学科接口设计流程的 mermaid 流程图：

graph LR
    A[明确目的] --> B[输入和前提条件]
    B --> C[审查对工程方面的分配]
    C --> D[识别交互属性]
    D --> E[定义端口对]
    E --> F[定义交互性质]
    F --> G[捕获元数据]
    G --> H[分组交互到接口]
    H --> I[协商接口细节]
    I --> J[存储接口到配置管理]
    J --> K[输出和后置条件]

以下是模型验证方法的表格：
| 方法 | 说明 |
| ---- | ---- |
| 模型模拟 | 对模型进行模拟操作 |
| 基于模型的测试 | 以模型为基础进行测试 |
| 可计算约束建模 | 建立可计算的约束模型 |
| 可追溯性 | 确保模型的可追溯性 |
| 有效的审查和演练 | 进行有效的审查和演练 |
| 测试驱动的建模 | 通过测试驱动模型的开发 |

嵌入式系统跨学科接口设计与模型验证（续）

10. 跨学科接口设计的技术细节分析

在跨学科接口设计中，电子 - 软件接口的技术细节尤为关键。以动力传动子系统的软件 - 电子接口为例，iSW_EE_Control 和 iSW_EE_Comm 接口块的具体设计体现了接口的复杂性和重要性。

10.1 iSW_EE_Control 接口块

该接口块的控制寄存器具有多种功能，具体如下：
| 位 | 功能 | 操作说明 |
| ---- | ---- | ---- |
| 0 | 启动监测和提供阻力 | 软件写入 1 时，硬件开始监测踏板并提供阻力，同时测量踏板位置、速度和功率，并将值写入相应寄存器；写入 0 时，停止相关操作。硬件需确保在一个 CPU 周期内完成寄存器更新，防止竞态条件。 |
| 1 | 电机供电错误指示 | 软件只读，0 表示无错误，1 表示有错误。 |
| 2 | 踏板位置或速度测量错误指示 | 软件只读，0 表示无错误，1 表示有错误。 |
| 3 | 骑手提供功率读取错误指示 | 软件只读，0 表示无错误，1 表示有错误。 |
| 4 - 7 | 未使用 | - |

其他寄存器用于表示电子设备的测量值（软件只读）或软件命令的阻力值（软件只写）。电子设备使用 8 位（如踏板速度和位置）或 16 位（如阻力和功率）来表示这些值。软件需要将这些值缩放为有意义的单位。

10.2 iSW_EE_Comm 接口块

该接口块的核心是 CAN 接收缓冲区和 CAN 发送缓冲区，每个缓冲区为 64 字节宽的可字节寻址内存寄存器，用于存储 CAN 总线消息。其交互流程如下：

发送消息流程 ：
1. 软件检查 CAN 控制寄存器的位 0，如果为 0，则可以向 CAN 发送缓冲区写入数据；否则，软件必须等待。
2. 软件将需要发送的 CAN 总线消息写入 CAN 发送缓冲区。
3. 软件将 CAN 控制寄存器的位 0 写入 1。
4. 硬件将该位的读值设置为 1。
5. 硬件将消息发送到 CAN 总线上。
6. 消息发送完成后，硬件将控制寄存器位 0 的软件读值设置为 0。
7. 硬件向软件生成中断 2，指示 CAN 发送缓冲区可用。
8. 软件可安装中断服务例程（swCANMsgSend）以发送下一条消息。

接收消息流程 ：
1. 硬件开始接收 CAN 总线消息，并填充 64 字节宽的 CAN 接收缓冲区。
2. 消息接收并存储完成后，硬件生成中断 3（swCANMsgReceived），并将控制寄存器位 1 的读值设置为 1，指示有消息可用。
3. 软件可以轮询控制寄存器的位 1 或安装中断服务例程来读取消息。
4. 软件读取消息后，应将位 1 写入 0，该值对硬件无影响，但作为软件的标志。

11. 模型验证的实际应用

在实际系统开发中，模型验证的各种方法都有其独特的应用场景。

11.1 模型模拟

模型模拟可以在系统实际开发之前，对系统的行为进行预测和分析。例如，在模拟动力传动子系统时，可以通过模拟不同的输入条件，观察系统的输出响应，从而评估系统的性能和稳定性。

11.2 基于模型的测试

基于模型的测试可以根据系统模型生成测试用例，对系统进行全面的测试。例如，根据动力传动子系统的接口模型，生成测试用例来验证软件 - 电子接口的正确性和稳定性。

11.3 可计算约束建模

可计算约束建模可以对系统的约束条件进行精确的描述和验证。例如，在动力传动子系统中，对电机的功率、转速等参数设置约束条件，通过可计算约束建模来确保系统在正常运行时不会超出这些约束。

11.4 可追溯性

可追溯性可以确保系统开发过程的透明度和可审计性。例如，通过建立需求、设计、实现和测试之间的追溯关系，可以快速定位问题的根源，提高系统的质量和可靠性。

11.5 有效的审查和演练

有效的审查和演练可以及时发现系统设计和实现中的问题。例如，在动力传动子系统的开发过程中，定期进行设计审查和代码演练，确保各工程学科之间的接口设计符合要求。

11.6 测试驱动的建模

测试驱动的建模可以确保系统模型的正确性和完整性。例如，在开发动力传动子系统的软件时，先编写测试用例，然后根据测试用例来开发软件模型，确保软件模型满足系统的需求。

12. 模型验证流程

以下是模型验证的 mermaid 流程图：

graph LR
    A[确定验证目标] --> B[选择验证方法]
    B --> C[执行验证操作]
    C --> D[分析验证结果]
    D --> E{结果是否符合要求?}
    E -- 是 --> F[结束验证]
    E -- 否 --> G[修改模型]
    G --> B