智能汽车车用基础软件平台 架构下的关键技术设计

时间同步测试主要包含 gPTP 协议一致性测试和 gPTP 配置测试，如表 3.2-6 为网络诊断基础验证的部分用例，详细测试用例中的每条用例应包含有唯一的编号、需明确需求点、测试目的、测试环境、测试步骤、评价标准等内容。时钟同步测试验证部分用例如表 3.2-6 所示：

表 3.2-6 时钟同步测试验证部分用例

2. 嵌入式系统时间特性分析

近年来，随着汽车功能的不断完善和多样化，车载电子系统日益复杂。从控制器层面看，集成度越来越高，CPU 负载不断增加。如何确保软件集成安全、优化设计、提高资源利用率、降低成本成为相关设计人员亟待解决的问题；另一方面，ISO26262 及 ASPICE 等相关标准中分别在软件架构、单元和集成阶段对性能分析提出了明确的需求。如何验证满足实时系统的时间性能需求，构建符合 ISO26262 和 AS-PICE 标准的产品也越来越引起相关人员的重视。

针对上述问题，AUTOSAR 标准在 4.0 版本以后即对嵌入式系统性能分析提出了相关方法论指导。其中，《AUTOSAR Specification of Timing Extensions》主要定义了不同级别的时间行为需求 / 规范标准，《Recommended Methods and Practices for Timing Analysis and Design within the AUTOSAR Devel- opment Process》（以下简称 Timing Analysis）主要提供了性能问题方法论指导。如图 3.2-8 所示：

图 3.2-8 时间特性分析层级概览（截图自AUTOSAR标准）

就分析内容而言，根据相关标准的定义，嵌入式系统的性能问题主要分为控制器级、网络级和功能级（端到端）三个维度。本文主要关注控制器级别的相关性能问题。结合欧洲相关标准的定义，控制器级 别的性能分析问题又可以进一步分为代码级分析和调度级分析。其中，代码级分析的对象为单个的任务（Task）/ 中断（Interrupt），不考虑任务 / 中断 / 进程间的抢占情况。而调度级分析则主要考虑多任务 / 中断间相互抢占的情况下，各任务 / 中断的响应时间的结果（包括本身的代码执行时间和被抢占的时间）。如图 3.2-9 所示：

图3.2-9不同时间特性分析方法的相互关系（来源：AUTOSAR标准）

就分析方法而言，可以分为理论分析、仿真和追踪三种，或者基于模型和基于追踪两种。后者与时间特性流程 / 研发流程更相契合。在本文中，我们采取后一种分类方法进行相关介绍。

(1) 基于模型的分析

基于模型的分析按照分析内容，又分为代码级分析和调度级分析。

根据 ISO26262 及 ASPICE 标准，代码级的相关指标主要包括最差情况代码执行时间（WCET， WorstCase Execution Time）和最差情况堆栈用量分析。调度级分析要求指标主要包括 CPU 负载、Task\Interrupt\Event Chain 最差情况响应时间（WCRT，WorstCase Reaction Time）等。

① 代码级基于模型的分析方案

代码级基于模型的分析方法是指不需要在实际的目标硬件环境中运行，而是通过直接从程序结构中计算出代码最差情况执行时间，或者在目标环境仿真器中仿真而得出代码执行时间分布范围的方法。

为了满足功能安全和ASPICE  中对性能问题最差情况的分析要求，一般推荐使用基于模型的分析方案。常见的分析方案如图 3.2-10 所示：

图3.2-10代码级基于模型的性能分析方案

常见的代码级基于模型的性能分析工具有 aiT、TimingProfiler、StackAnalyer 等。

② 调度级基于模型的分析方案

调度级基于模型的分析方法是指不需要在实际的目标硬件环境中运行，而是基于目标操作系统、代码执行时间范围和调度配置进行静态数值分析而计算出最差情况任务 / 中断响应时间，或者在调度仿真器中仿真而得出任务 / 中断响应时间分部范围的方法。

为了满足功能安全和ASPICE  中对性能问题最差情况的分析要求，一般推荐使用基于模型的分析方案。常见的分析方案如图 3.2-11 所示：

图3.2-11调度级基于模型的性能分析方案

常见的调度级基于模型的性能分析工具有 Symtavision、Inchron、Timing-Architects 等。

嵌入式实时系统必须保证每一个操作系统的任务均在规定的时间内作正确的响应，如果由于某个任 务执行时间过长或者调度设计不合理而影响其他的任务的正常执行，进而超出任务规定响应时间的情况， 会对系统的正常运作造成很大的影响。根据软件的严重度等级，这些潜在安全隐患的排除需要通过形式 化的验证方法或者具有充分的测试覆盖度的测试方法进行证明。针对性能问题，在适航标准 DO178B 的第六章中明确指出 “Testing, in general, cannot show the absence of errors” ，也就是说，测试一般不能用来证明某些性能问题的清除，比如代码执行时间、堆栈用量、代码运行时错误等，一般通过测试来证明是不足够的，因为没有一种测试的手段可以对性能问题达到 100% 的覆盖度，即无法找出 WorstCase 的工况。因而，标准中提出某些性能错误的排除可以通过形式化的方法（Formal methods）进行证明， 而形式化方法即为一种基于模型的分析方法。此外，由于基于模型的分析方法不需要硬件环境，使得在 设计阶段即对性能问题进行分析成为可能，从而尽早地发现和排除相关问题，避免在集成阶段再发现问 题而导致时间和成本的浪费。

(2) 基于追踪的分析

基于追踪的分析按照分析内容，又分为代码级追踪和调度级追踪。

追踪的对象是实际目标系统，一般通过代码插桩等手段，持续地进行事件（events）及对应时间戳(time stamp) 的采集和记录，这些记录的数据可以存放在目标硬件的内存或者通过相关接口实时导出。这些事件的选择可以是代码块级别、函数级别或任务 / 中断级别等，也可以细化到机器指令级别。根据不同的事件级别可以基于追踪文件分别重建代码块、函数、任务 / 中断、甚至是每个机器指令的实际执行时序情况。相应的，对机器指令、代码块、函数等基于追踪文件的时序重建，可以分析得到代码执行时间最小值、最大值、平均值等数据，即为代码级追踪分析的内容。而对任务 / 中断基于追踪文件的时序重建，可以分析得到任务 / 中断延时和 CPU 实时负载的最小值、最大值、平均值等数据，即为调度级追踪分析的内容。

常见的追踪分析方案如图 3.2-12 所示：

图3.2-12基于追踪的性能分析方案

常见的基于追踪的代码级性能分析工具有 TimeWeaver+Lauterbach、Gliwa、RapiTime 等；常见的基于追踪的调度级性能分析工具有 TraceAnalyzer、Lauterbach、iSystem、Greenhill、RapiTask、Gliwa 等。

识别二维码或点击阅读原文下载：
《中国汽车基础软件发展白皮书》