26、开发过程中的时序方法学

开发过程中的时序方法学

1. 时序相关需求

1.1 时序需求的识别与格式

• 通过访谈识别时序需求 ：定义嵌入式系统的时序需求时，可按顺序访谈功能开发者、网络专家和集成商。功能开发者需说明其开发功能的时序要求，问题涉及物理层、模型层、软件组件层等不同抽象层次的功能。集成商通常有丰富的嵌入式软件时序经验，能提供功能开发者未考虑到的需求。可参考特定的问卷来收集时序需求，并将其纳入需求规格说明中。问卷包含日期、项目名称、填写人、时序需求简要描述、需求相关内容、相关时序参数、值的类型及具体值等信息。
  | 问卷内容 | 详情 |
  | ---- | ---- |
  | 日期 | 填写问卷的日期 |
  | 项目名称/ID | 具体项目的名称或编号 |
  | 填写人 | 填写问卷的人员姓名 |
  | 时序需求简要描述 | 对时序需求的详细说明 |
  | 需求相关内容 | 如代码/功能、物理层、模型层等 |
  | 相关时序参数 | 如CET（核心执行时间）、DT（时间差）等 |
  | 值的类型 | 最小允许值、最大允许值等 |
  | 具体值 | 如时间值（µs或ms）或执行顺序 |

• 时序需求的格式

  • AUTOSAR项目 ：可使用AUTOSAR Timing Extensions (TIMEX) 正式将时序需求插入需求规格说明中。但截至2020年夏季，使用TIMEX制定时序需求的情况极为罕见，因为相关工具支持不足，且AUTOSAR XML语法是为生成而非手动创建设计的，其语义也非常复杂，使用前需要大量培训。
  • 非AUTOSAR项目 ：可将访谈得到的时序需求直接记录下来。指定选定的时序参数的最大或最小允许值有诸多优点，如易于理解、可使用自定义格式、工具使用格式或标准化格式进行正式指定（如ASAM ARTI），还能被时序工具直接处理。

1.2 方法和工具相关需求

• 项目阶段与时序分析 ：需考虑在哪些项目阶段以及在何种程度上进行时序分析。对于安全相关项目，有具体的时序分析要求。
• 工具和方法的选择 ：工具和方法的一个明显要求是捕获和验证之前指定的具体时序需求。可使用多种技术来确定和监控时序参数，如时序测量、跟踪、代码模拟和静态代码分析等。选择工具和方法时，没有简单规则，需考虑开发者和项目的具体要求以及当前使用的工具和内部开发流程。
• 项目合作伙伴的参与 ：确定使用哪些分析技术后，需明确项目合作伙伴以何种形式参与，这决定了哪些需求、方法和工具需要包含在规格说明中。例如，航空领域的飞行控制器制造商在与供应商合作时，因未明确测量技术对自身开发部分的可用性，导致自身开发代码时缺乏测量技术。
• 相关问题考虑 ：在定义规格说明时，可考虑以下问题：
  • 项目是否为安全关键项目，是否考虑了相关安全标准的时序要求？
  • 预期的时序分析技术能否充分捕获和测试/验证所有具体时序需求？
  • 是否有可用于高效时序调试的分析技术？
  • 是否可以在无硬件的情况下进行调度分析和优化？
  • 哪些项目合作伙伴应访问哪些工具和时序分析结果？
  • 测试应在何处、何时以及在何种程度上进行？
  • 是否明确定义了如何确定CPU负载？

1.3 通用需求模板

一些项目在创建需求文档后，将许多时序分析需求进行了通用化处理，收集到一个模板池中，供未来项目创建规格说明时使用。使用这些模板能显著节省创建规格说明的时间，且能确保规格说明的编写者至少考虑了对安全ECU成功开发至关重要的时序方面。不过，这些模板需要维护和沟通，包括根据不断变化的开发过程和环境进行更新，以及对编写需求规格说明的人员进行培训。

2. 开发过程中的协作

项目合作伙伴（客户和供应商）在时序方面的合作，核心问题已在前面的需求中确定。但提前讨论和明确合作的其他相关主题可节省大量时间。重要的是在不泄露知识产权（IP）的情况下交换时序相关信息。代码可在目标代码级别而非源代码级别进行交换。所有非IP相关的时序分析信息应存放在所有项目合作伙伴都可访问的公共区域，如时序分析工具的项目文件。当涉及仪器化时，时序工具源代码的通用部分也应属于公共领域。每个项目合作伙伴可对其受保护部分进行仪器化，但需为每个仪器化点分配唯一的ID，可在项目开始时为每个合作伙伴分配一个ID范围以避免冲突。

graph LR
    A[客户] -->|交换目标代码| C[公共区域]
    B[供应商] -->|交换目标代码| C[公共区域]
    C -->|共享非IP信息| A
    C -->|共享非IP信息| B
    A -->|自行仪器化| D[客户私有数据]
    B -->|自行仪器化| E[供应商私有数据]

3. 时序概念、调度布局和操作系统配置

确定具体的时序需求并选择处理器后，可着手制定时序概念，再由此推导调度布局，最终确定操作系统配置。在理想情况下，这些步骤应在处理器选择之前进行，并对其产生重大影响。但实际上，处理器通常在时序概念制定之前就已确定。软件在处理器不同核心上的分配没有简单规则，每个项目有具体要求，且分配时涉及的因素有时相互矛盾。当有了时序概念和调度的初步想法后，可将其转移到调度模拟中，通过模拟可使想法更具体并进行细化，还可使用静态调度分析验证概念是否满足所有情况下的需求。

4. 时序调试

传统的调试工具主要关注软件的功能方面，通过在错误明显的点停止软件来检查变量内容并跟踪软件流程。但对于调试时序问题，这种方法作用有限。许多嵌入式系统依赖其环境，无法停止并逐步执行软件，且大多数时序问题出现在调度级别，而非代码级别。跟踪是了解真实系统调度级别的最佳方法，无论调度跟踪是通过仪器化还是硬件创建的，重要的是能够可视化所有相关CPU上的中断和任务、线程和进程的执行以及相关数据的交换。

5. 时序优化

通常在项目中，时序优化并非开发过程中的固定步骤，多数情况下是在出现时序问题后才开始进行时序调试和优化。但在项目规划时考虑优化能力是值得的。若一切正常，则无需进行优化；若出现问题，可参考相关内容获取多种可能的优化方法。

开发过程中的时序方法学

6. 时序需求分析流程总结

为了更清晰地展示时序需求分析的整个过程，我们可以总结出以下流程图：

graph TD
    A[开始] --> B[识别时序需求]
    B --> C{项目类型}
    C -->|AUTOSAR项目| D[使用TIMEX插入需求]
    C -->|非AUTOSAR项目| E[记录时序需求]
    D --> F[检查工具支持和语义复杂度]
    E --> G[指定参数值及优点处理]
    F --> H[工具和方法选择]
    G --> H
    H --> I[确定项目伙伴参与形式]
    I --> J[考虑相关问题]
    J --> K[使用通用需求模板]
    K --> L[结束]

这个流程图涵盖了从识别时序需求开始，根据项目类型选择不同的需求处理方式，再到工具和方法的选择、项目伙伴的参与以及相关问题的考虑，最后使用通用需求模板完成整个流程。

7. 开发协作中的信息交换表格

为了更直观地展示项目合作伙伴（客户和供应商）在协作过程中信息交换的情况，我们可以列出以下表格：

信息类型	客户	供应商	公共区域
目标代码	提供	提供	存储和共享
非IP相关时序分析信息	可访问	可访问	存储和共享
私有仪器化数据	自行管理	自行管理	不共享

通过这个表格，我们可以清晰地看到不同类型的信息在项目合作伙伴和公共区域之间的流向和管理方式。

8. 时序概念到配置的步骤列表

从时序概念到操作系统配置的步骤可以详细列出如下：
1. 确定具体的时序需求。
2. 选择处理器（实际中处理器可能提前确定）。
3. 制定时序概念，考虑软件功能、时序和安全等多方面因素。
4. 根据时序概念推导调度布局。
5. 确定操作系统配置。
6. 将初步的时序概念和调度想法转移到调度模拟中进行细化。
7. 使用静态调度分析验证概念是否满足所有情况下的需求。

这个列表清晰地展示了从时序概念到最终操作系统配置的详细步骤，每个步骤都有其特定的任务和目标。

9. 时序调试与传统调试对比

为了更好地理解时序调试与传统调试的区别，我们可以列出以下对比表格：

调试类型	关注重点	调试方式	适用问题类型
传统调试	软件功能方面	在错误明显点停止软件，检查变量内容，单步跟踪流程	功能相关的软件错误
时序调试	系统调度级别	通过跟踪可视化中断、任务、线程和进程执行及数据交换	时序相关的软件问题

通过这个表格，我们可以清楚地看到两种调试方式在关注重点、调试方式和适用问题类型上的差异。

10. 时序优化的建议

虽然时序优化通常在出现问题后才进行，但在项目规划阶段就考虑优化能力是很有必要的。以下是一些在项目规划和执行过程中可以采取的建议：
- 在项目规划时，预留一定的资源和时间用于可能的时序优化。
- 建立定期的时序检查机制，在项目的不同阶段对系统的时序性能进行评估。
- 培养团队成员对时序问题的敏感度，提高他们在开发过程中发现和解决时序问题的能力。
- 利用调度模拟和静态调度分析等工具，在项目早期发现潜在的时序问题并进行优化。

通过遵循这些建议，可以在项目开发过程中更好地应对时序问题，提高系统的整体性能和稳定性。