29、AUTOSAR相关技术及嵌入式系统安全解析

最新推荐文章于 2025-10-28 13:36:49 发布

html8

最新推荐文章于 2025-10-28 13:36:49 发布

阅读量44

点赞数

CC 4.0 BY-SA版权

分类专栏：嵌入式软件定时之道文章标签： AUTOSAR TIMEX ARTI

本文链接：https://blog.youkuaiyun.com/html8/article/details/152207306

嵌入式软件定时之道专栏收录该内容

30 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

AUTOSAR相关技术及嵌入式系统安全解析

1. AUTOSAR中的时间参数

在AUTOSAR中，有两个重要的时间参数：
- GET（Gross Execution Time，总执行时间） ：它是通过一个循环周期的开始时间和结束时间的差值来计算的。具体而言，是从 DeterministicClient.WaitForNextActivation() 函数返回开始，到该函数再次被调用为止。
- CET（Core Execution Time，核心执行时间） ：在RTOS环境中，AUTOSAR CP和POSIX应用通常应反映处理器处理相关代码所花费的CET。由于一个进程可以启动多个线程，并且这些线程可以在同一处理器的不同CPU上同时执行，因此需要将所有线程的运行时间相加。计算的基础是POSIX提供的RUNT时间。需要注意的是，当多个线程并行处理时，这种求和的结果可能会使一个循环周期的CET大于同一循环体的GET。

2. TIMEX（AUTOSAR Timing Extensions）

TIMEX于AUTOSAR Release 4.0引入，其目标是正式描述时序方面的内容，并能够指定正式的时序要求。它使用AUTOSAR XML作为描述格式，这意味着即使是像“任务A的响应时间不得超过两毫秒”这样简单的时序要求，也会产生许多行ARXML代码。只有经验丰富的TIMEX专家才能解释甚至创建这样的代码。如果有工具能够减轻开发人员处理ARXML的繁琐工作，这就不会是一个大问题。然而，在TIMEX作为标准可用的10多年里，没有一家工具供应商着手开发这样的工具。

2.1 TIMEX的目标

TIMEX定义时序要求有两个目标：
- 支持系统配置，使配置决策能最好地满足时序要求。
- 验证时序要求是否得到满足。

假设为项目的所有软件组件全面、正式地指定了时序要求，那么操作系统的自动配置以及可运行实体到任务、任务到CPU的自动分配将是可行的。尽管如今的AUTOSAR工具距离这一目标还很远，但以精确形式提供所有时序要求是迈向完全自动化配置的第一步。

2.2 事件和事件链

TIMEX指定的时序要求基本上可以应用于事件和事件链。事件是所有可唯一识别的AUTOSAR事件，例如数据的发送或接收、服务的请求、相关反馈的接收，或者可执行单元的激活、启动或终止。事件链是由两个或多个事件组成的链，通常将这些事件链进行分层组织是很有用的。

例如，假设存在一个要求，即车辆的刹车灯在踩下刹车踏板后最迟200毫秒内亮起。这个要求在顶层可以映射为一个包含两个事件的事件链：
- 刹车踏板从“未踩下”变为“踩下”。
- 刹车灯从“关闭”变为“亮起”。

刹车踏板很可能与刹车灯连接在不同的控制单元上，因此至少会涉及两个ECU，如果这两个ECU之间有网关，可能会涉及更多ECU。刹车踏板被踩下的信息（事件1）将首先到达控制单元A，在那里对收到的信息进行合理性检查（事件2）并进一步处理（事件3）。事件4表示发送信息的请求，事件5表示实际发送的时刻。这个过程会一直持续，直到最后通过事件x使刹车灯亮起。因此，刹车灯在踩下刹车踏板后最迟200毫秒内亮起的端到端要求必须分解为活动链的各个部分。

2.3 TIMEX要求类型

TIMEX定义了不同类型的要求（约束），以下是每种类型的典型应用示例：
| 要求类型 | 典型用例 |
| ---- | ---- |
| EventTriggeringConstraint | 监控周期性事件的抖动 |
| LatencyTimingConstraint | 避免由于发送方/接收方不同步或同步不良而导致的数据重复接收或丢失 |
| AgeConstraint | 确保数据不过时 |
| SynchronizationTimingConstraint | 同步子系统以避免竞态条件 |
| OffsetTimingConstraint | 监控两个事件之间的期望时间偏移 |
| ExecutionOrderConstraint | 监控可运行实体处理过程中的期望顺序 |
| ExecutionTimeConstraint | 监控允许的最大CET，例如可运行实体的CET |

2.4 AUTOSAR/TIMEX视图

AUTOSAR从不同的角度（视图）看待系统，TIMEX采用了这种方法，以便将时序请求始终分配到特定的TIMEX视图。具体如下：
- VfbTiming ：AUTOSAR软件组件（SW - Cs）通过虚拟功能总线（VFB）交互期间的时序。
- SwcTiming ：软件组件的内部时序。
- SystemTiming ：跨控制单元的时序。
- BswModuleTiming ：基本软件模块（BSW）的内部时序（类似于SwcTiming）。
- BswCompositionTiming ：多个基本软件模块交互期间的时序。
- EcuTiming ：完全配置的控制单元的时序。在这个完整的配置中，所有软件组件和基本软件模块的交互都有明确的定义。相比之下，其他视图独立于其在特定ECU中的使用来指定时序要求。

3. ARTI（AUTOSAR/ASAM Run - Time Interface）

ARTI于2016年推出，旨在显著简化AUTOSAR项目的时序分析。它的名称与OSEK运行时接口ORTI相似，这是有意为之。在某些方面，ARTI可以被视为ORTI的继任者，但在其他方面，它有了显著的超越。

在ARTI的开发过程中发现，将所有ARTI功能都组织在AUTOSAR之下是没有意义的，因为ARTI的大部分内容并非特定于AUTOSAR，也可用于非AUTOSAR应用。因此，2019年初启动了一个ASAM项目，并于2020年2月完成。ASAM代表“自动化和测量系统标准化协会”，是一个支持和组织软件开发、仿真、诊断以及自动化和测量程序标准化的注册协会。

3.1 AUTOSAR ARTI和ASAM ARTI的目标和功能

AUTOSAR ARTI的目标和功能 ：
- 具有操作系统感知的调试，即使用一个“了解”操作系统的调试器，例如可以显示所有任务的状态。ARTI的后续版本还将为调试器提供有关其他AUTOSAR模块的信息，以便实现RTE感知、COM栈感知等。
- 与调试类似，跟踪也可以收集、可视化和评估特定于操作系统、COM栈、RTE等的信息。
- 跟踪可运行实体。
- 跟踪用户定义的事件，从而将“感知”扩展到应用程序。
- 支持基于硬件的跟踪。
- 支持基于软件的跟踪。
- 基于测量进行性能分析，可通过软件插桩或特殊硬件（如英飞凌AURIX的性能计数器）实现。
- 多核跟踪，包括不同CPU跟踪的同步。
- 多ECU跟踪，包括不同ECU跟踪的同步。
- 跟踪和测量TIMEX约束，即跟踪和测量相应的事件和事件链。
- 支持AUTOSAR AP。
ASAM ARTI的目标和功能 ：
- 用于交换跟踪数据的标准化跟踪格式。
- 用于交换时序参数的标准化格式。

3.2 AUTOSAR ARTI的工作流程

AUTOSAR ARTI的任务是在V模型的左侧创建先决条件，以便后续在右侧进行运行时测量和跟踪记录。具体步骤如下：
1. 使用ARTI扩展ECU配置。ECU配置包含各个AUTOSAR模块的代码生成器生成代码所需的所有信息。此时的一个核心方面是哪些AUTOSAR模块将在后续软件中支持ARTI。
2. 代码生成器读取ECU配置。为了更清晰，通常只显示两个生成器：一个用于操作系统，另一个用于RTE。但这个概念可以应用于所有对其服务和数据流进行时序分析可能有意义的AUTOSAR模块。

graph LR
    A[ECU配置] -->|使用ARTI扩展| B[扩展后的ECU配置]
    B -->|代码生成器读取| C[操作系统代码生成器]
    B -->|代码生成器读取| D[RTE代码生成器]
    C --> E[生成操作系统代码]
    D --> F[生成RTE代码]

3.3 ASAM ARTI的工作流程

AUTOSAR ARTI用于为特定软件版本启用跟踪或运行时测量，以收集所有必要的信息。关于系统配置的信息（即存在哪些任务、哪些可运行实体、可运行实体如何分配到任务等）将写入一个新的AUTOSAR XML文件（在相关图中显示为“ARTI Extract”）。

跟踪工具可以读取此信息并从ECU读取跟踪数据。通常，它会显示跟踪本身，也可以将其保存为ASAM ARTI跟踪格式，以便其他工具读取、解释和评估跟踪数据。评估跟踪数据的一个结果可能是确定所有时序参数（如核心执行时间CET、响应时间RT等）的最小值、最大值和平均值。

通过这种方式获得的性能分析数据可以存储在ASAM ARTI性能分析数据格式中，然后作为调度仿真或静态调度分析的输入数据。除了跟踪，纯运行时测量技术也得到支持。在这种情况下，通过ARTI钩子调用的代码不会生成任何跟踪数据，但会直接计算所需的时序参数。运行时确定的性能分析数据必须以合适的形式读取出来，通常使用为此目的设计的PC软件来实现。该PC软件可以将数据保存为ASAM ARTI性能分析数据格式。

ASAM规范“ARTI ASAM Run - Time Interface”定义了跟踪和性能分析数据的格式，这两种格式都基于另一个ASAM标准，即第四版的测量数据格式（简称MDF4）。MDF4是一种二进制数据格式，旨在高效存储大量数据，以便进行后处理或永久存储。ASAM ARTI跟踪数据和性能分析数据可以选择包含有关系统配置的信息，例如AUTOSAR XML文件“ARTI Extract”中包含的信息。

graph LR
    A[AUTOSAR ARTI收集信息] --> B[写入ARTI Extract文件]
    B --> C[跟踪工具读取信息]
    C -->|从ECU读取跟踪数据| D[显示或保存跟踪数据]
    D -->|评估跟踪数据| E[确定时序参数值]
    E -->|存储为ASAM ARTI格式| F[用于调度仿真或分析]

4. 技术报告“Timing Analysis”

该报告通过用例来探讨时序主题，这些用例分配到V模型的不同级别或不同使用领域，具体如下：
- 设计级别
- 功能级别
- 分布式功能的端到端时序
- 网络级别
- ECU级别

此外，该报告还涉及时序参数的定义和与时序相关的方法。其创作者欢迎有兴趣的人参与，唯一的要求是具有AUTOSAR会员身份（高级合作伙伴、开发合作伙伴或参会者），此外，还需要对时序主题有浓厚的兴趣。

5. 总结

TIMEX和AUTOSAR ARTI在AUTOSAR的时序分析中都有重要作用。TIMEX虽然目标明确，但在实际应用中由于缺乏相关工具支持，其广泛使用仍有待观察。而AUTOSAR ARTI相对较新，需要在实践中证明自己。如果成功，它将大大改善AUTOSAR模块（尤其是操作系统）与时序分析工具的交互，ASAM ARTI也将极大简化时序分析工具之间的数据交换。

6. 嵌入式系统安全与ISO 26262

嵌入式系统的安全至关重要，因为软件错误可能会导致潜在的灾难性后果，例如核电站冷却系统控制、起搏器、飞机飞行控制器或车辆刹车控制单元等。虽然时序只是嵌入式软件众多方面中的一个，但没有稳定和安全的时序，就不可能有安全的嵌入式软件。

6.1 安全基础

仅仅追求安全是不够的。如果集成足够多的监控器，在其中一个被激活时能将系统的关键功能切换到安全状态，构建一个非常安全的系统并不困难。然而，这样做可能会以极低的可用性为代价来换取安全性。在极端情况下，产品虽然安全，但实际上无法执行其功能。因此，必须为错误率和可用性定义合适的值。

6.2 风险

在安全方面，风险是一个重要的概念。有两种常见的风险定义方式：
- EN ISO 12100:2010将风险定义为发生概率和损害程度的组合，通常通过简单计算两者的乘积来量化：
[Risk = Probability of occurrence \cdot Extent of damage]
- 另一种类似的定义在ISO 26262中使用，还考虑了危险发生时的可控性，公式如下：
[Risk = \frac{Probability of occurrence \cdot Extent of damage}{Controllability}]

6.3 安全完整性级别（SIL）

几乎每个安全标准都定义了安全完整性级别。在进行相应的风险分析后，嵌入式系统的每个组件（包括硬件和软件）都会被分配一个特定的安全完整性级别。这是为了回答一个问题：如果没有其他安全机制起作用，所考虑的组件发生故障可能会导致多少人员伤亡？

例如，刹车阀的电气组件如果发生故障，可能会导致车辆的一个车轮突然急剧刹车。如果这种情况在高速公路上高速行驶时发生，很容易想象会发生一起造成多人死亡的事故。而后备箱内部照明的控制电子设备则不同，即使发挥很大的想象力，也很难设想出危险情况，例如因过热引发火灾是不可能的。不同的标准提供不同的安全完整性级别。

6.4 第三方组件的保护方式

在绝大多数情况下，嵌入式系统的软件并非由一家公司100%创建，通常会集成多个供应商的软件组件，包括操作系统、驱动程序、引导加载程序、协议栈、单个算法等。对于这些第三方组件，有三种基本的保护方式：
- In context（在上下文中） ：供应的组件以与自行开发代码相同的方式进行认证。虽然听起来简单，但有时很难甚至不可能做到。为了能够像分析、测试和保护自己的代码一样处理供应的代码，源代码的可用性几乎是必需的。因此，对于供应商不提供源代码的组件，很难进行上下文认证。
- Out of context（脱离上下文） ：组件独立于特定项目或应用进行认证。在ISO 26262中，这更具体地表现为一个（系统）元素脱离上下文（SEooC），即一个组件根据ISO 26262开发并认证，独立于特定项目。此外，还有一些组件最初并非根据ISO 26262开发，但后来根据该标准进行了调整并认证，这类组件被称为商用现货（COTS）软件组件。使用SEooC或COTS组件时，用户仍需确保在项目中考虑到在产品和组件认证过程中创建的安全手册。安全手册可以被视为组件安全使用的一种用户手册，用户必须证明已经为组件的安全运行建立了所有必要的边界条件，并考虑了组件施加的限制。需要注意的是，这种方式所需的工作量比“在上下文中”保护要小得多。
- Proven in operation（经运行验证） ：在验证过程中，可以提出一个论点，即某个组件已经多次使用且在很长一段时间内没有出现任何问题。在这种情况下，必须证明该组件在当前项目中的边界条件与已证明运行良好的项目相比没有差异。有时，在安全相关项目中会故意使用较旧版本的编译器，因为它经过了充分测试。在这种情况下，必须单独检查自旧编译器发布以来发现的所有编译器错误对当前项目的相关性。

综上所述，在嵌入式系统的开发中，不仅要关注AUTOSAR相关的时序技术，还要重视安全问题，合理评估风险，选择合适的安全完整性级别和第三方组件保护方式，以确保系统的安全性和可靠性。

AUTOSAR相关技术及嵌入式系统安全解析

7. 安全与可用性的平衡探讨

在嵌入式系统的安全设计中，安全与可用性的平衡是一个关键问题。如前文所述，单纯追求高安全性可能会牺牲系统的可用性，但如果过于注重可用性而忽视安全，又会使系统面临潜在的灾难性风险。

为了实现两者的平衡，需要进行细致的风险评估和需求分析。首先，明确系统的关键功能和非关键功能，对于关键功能，如车辆的刹车控制、飞机的飞行控制等，应确保其具有较高的安全性，同时尽量减少对可用性的影响。可以通过采用冗余设计、故障诊断和容错机制等方法来提高安全性。

例如，在车辆的刹车系统中，可以采用双回路制动系统，当一个回路出现故障时，另一个回路仍能提供一定的制动能力，从而在保证安全的前提下，维持系统的基本可用性。对于非关键功能，如车辆的娱乐系统，可以适当降低安全要求，以提高系统的整体可用性。

在实际操作中，可以按照以下步骤进行安全与可用性的平衡设计：
1. 功能分析 ：对系统的所有功能进行详细分析，确定哪些是关键功能，哪些是非关键功能。
2. 风险评估 ：针对每个功能，评估其发生故障可能带来的风险，包括损害程度、发生概率和可控性等。
3. 安全策略制定 ：根据风险评估结果，为不同功能制定相应的安全策略，如冗余设计、故障诊断等。
4. 可用性分析 ：在实施安全策略的同时，分析其对系统可用性的影响，确保在可接受的范围内。
5. 权衡与优化 ：根据安全和可用性的要求，对设计方案进行权衡和优化，找到最佳的平衡点。

8. 不同风险定义方式的应用场景

在安全领域，不同的风险定义方式适用于不同的场景。EN ISO 12100:2010将风险定义为发生概率和损害程度的乘积，这种定义方式简单直观，适用于对风险进行初步评估和比较。例如，在对多个项目或系统进行风险排序时，可以使用这种定义方式快速确定风险的相对大小。

而ISO 26262中使用的风险定义方式，考虑了危险发生时的可控性，更加全面和细致。这种定义方式适用于对风险进行深入分析和精确评估的场景，特别是在涉及到安全关键系统的设计和开发中。例如，在设计核电站的控制系统时，需要考虑到各种可能的故障情况以及操作人员对这些故障的控制能力，使用ISO 26262的风险定义方式可以更准确地评估风险，从而采取相应的安全措施。

下面通过一个表格来对比两种风险定义方式的应用场景：
| 风险定义方式 | 公式 | 应用场景 |
| ---- | ---- | ---- |
| EN ISO 12100:2010 | Risk = Probability of occurrence * Extent of damage | 初步风险评估、项目或系统风险排序 |
| ISO 26262 | Risk = (Probability of occurrence * Extent of damage) / Controllability | 安全关键系统设计、深入风险分析 |

9. 不同安全完整性级别（SIL）的选择与实施

不同的安全标准定义了不同的安全完整性级别（SIL），在选择和实施SIL时，需要根据系统的具体需求和风险评估结果来进行。

首先，要明确系统的安全目标和要求，确定所需的SIL级别。一般来说，安全关键系统需要较高的SIL级别，如飞机的飞行控制系统、核电站的反应堆控制系统等，通常需要SIL 3或SIL 4级别。而对于一些非安全关键系统，如家用电子设备的控制系统，可以选择较低的SIL级别，如SIL 1或SIL 2级别。

在实施SIL时，需要遵循相应的标准和规范，进行系统的设计、开发、测试和验证。具体步骤如下：
1. 需求分析 ：明确系统的安全需求和功能需求，确定所需的SIL级别。
2. 设计阶段 ：根据SIL级别要求，进行系统的架构设计和详细设计，采用适当的安全机制和技术，如冗余设计、故障诊断、容错机制等。
3. 开发阶段 ：按照设计要求进行代码开发，确保代码的质量和可靠性。同时，进行代码审查和测试，以发现和纠正潜在的安全问题。
4. 测试阶段 ：进行系统级测试，包括功能测试、性能测试、安全测试等，验证系统是否满足SIL级别要求。
5. 验证阶段 ：进行独立的验证和确认活动，确保系统的安全性和可靠性。可以采用第三方认证机构进行认证，以提高系统的可信度。

10. 第三方组件保护方式的综合应用

在嵌入式系统开发中，使用第三方组件是很常见的，但需要采用合适的保护方式来确保其安全性。

对于源代码可用的第三方组件，可以优先考虑“in context”保护方式。这种方式可以对组件进行全面的分析和测试，确保其与系统的其他部分兼容，并满足系统的安全要求。具体操作步骤如下：
1. 获取源代码 ：从供应商处获取第三方组件的源代码。
2. 代码审查 ：对源代码进行详细审查，检查是否存在安全漏洞和潜在的问题。
3. 集成测试 ：将组件集成到系统中，进行全面的测试，包括功能测试、性能测试、安全测试等。
4. 认证：按照系统的安全要求，对组件进行认证，确保其符合相应的安全标准。

对于源代码不可用的第三方组件，可以选择“out of context”或“proven in operation”保护方式。“out of context”保护方式适用于经过认证的SEooC或COTS组件，使用时需要仔细审查其安全手册，确保在项目中考虑到所有必要的边界条件和限制。“proven in operation”保护方式适用于已经在多个项目中成功使用的组件，但需要证明其在当前项目中的边界条件与以往项目相同。

在实际应用中，可以综合使用这三种保护方式。例如，对于一些关键的第三方组件，可以采用“in context”和“out of context”相结合的方式，先对组件进行独立认证，然后在集成到系统中时进行全面测试。对于一些非关键的第三方组件，可以采用“proven in operation”方式，以减少开发成本和时间。

graph LR
    A[第三方组件] -->|源代码可用| B["in context保护"]
    A -->|源代码不可用| C["out of context保护"]
    A -->|已多次成功使用| D["proven in operation保护"]
    B --> E[代码审查]
    B --> F[集成测试]
    B --> G[认证]
    C --> H[审查安全手册]
    D --> I[证明边界条件相同]