我是穿拖鞋的汉子，魔都中坚持长期主义的工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
人们会在生活中不断攻击你。他们的主要武器是向你灌输对自己的怀疑：你的价值、你的能力、你的潜力。他们往往会将此伪装成客观意见，但无一例外的是，他们想让你怀疑自己。
本文主要介绍车载基础软件——嵌入式系统时间特性分析。
文章主要有如下几个内容：
-> 1、网络管理测试验证
-> 2、诊断服务测试验证
-> 3、BSW层里的操作系统OS
近年来，随着汽车功能的不断完善和多样化，车载电子系统日益复杂。从控制器层面看，集成度越来越高，CPU 负载不断增加。如何确保软件集成安全、优化设计、提高资源利用率、降低成本成为相关设计人员亟待解决的问题；另一方面，ISO26262 及 ASPICE 等相关标准中分别在软件架构、单元和集成阶段对性能分析提出了明确的需求。如何验证满足实时系统的时间性能需求，构建符合 ISO26262 和 ASPICE 标准的产品也越来越引起相关人员的重视。
针对上述问题，AUTOSAR 标准在 4.0 版本以后即对嵌入式系统性能分析提出了相关方法论指导。其中，《AUTOSAR Specification of Timing Extensions》主要定义了不同级别的时间行为需求 / 规范标准，《Recommended Methods and Practices for Timing Analysis and Design within the AUTOSAR Development Process》（以下简称 Timing Analysis）主要提供了性能问题方法论指导。如图：
就分析内容而言，根据相关标准的定义，嵌入式系统的性能问题主要分为控制器级、网络级和功能级（端到端）三个维度。本文主要关注控制器级别的相关性能问题。结合欧洲相关标准的定义，控制器级别的性能分析问题又可以进一步分为代码级分析和调度级分析。其中，代码级分析的对象为单个的任务（Task）/ 中断（Interrupt），不考虑任务 / 中断 / 进程间的抢占情况。而调度级分析则主要考虑多任务 /中断间相互抢占的情况下，各任务 / 中断的响应时间的结果（包括本身的代码执行时间和被抢占的时间）。如图：
就分析方法而言，可以分为理论分析、仿真和追踪三种，或者基于模型和基于追踪两种。后者与时间特性流程 / 研发流程更相契合。在本文中，我们采取后一种分类方法进行相关介绍：
一、基于模型的分析
基于模型的分析按照分析内容，又分为代码级分析和调度级分析。根据ISO26262 及 ASPICE 标准，代码级的相关指标主要包括最差情况代码执行时间（WCET，WorstCase Execution Time）和最差情况堆栈用量分析。调度级分析要求指标主要包括 CPU 负载、Task\Interrupt\Event Chain 最差情况响应时间（WCRT，WorstCase Reaction Time）等。
->代码级基于模型的分析方案
代码级基于模型的分析方法是指不需要在实际的目标硬件环境中运行，而是通过直接从程序结构中计算出代码最差情况执行时间，或者在目标环境仿真器中仿真而得出代码执行时间分布范围的方法。
为了满足功能安全和 ASPICE 中对性能问题最差情况的分析要求，一般推荐使用基于模型的分析方案。常见的分析方案如图所示：
常见的代码级基于模型的性能分析工具有 aiT、TimingProfiler、StackAnalyer 等。
-> 调度级基于模型的分析方案
调度级基于模型的分析方法是指不需要在实际的目标硬件环境中运行，而是基于目标操作系统、代码执行时间范围和调度配置进行静态数值分析而计算出最差情况任务 / 中断响应时间，或者在调度仿真器中仿真而得出任务 / 中断响应时间分部范围的方法。
为了满足功能安全和 ASPICE 中对性能问题最差情况的分析要求，一般推荐使用基于模型的分析方案。常见的分析方案如图所示：
文章来源：https://www.toymoban.com/news/detail-454471.html
常见的调度级基于模型的性能分析工具有 Symtavision、Inchron、Timing-Architects 等。
嵌入式实时系统必须保证每一个操作系统的任务均在规定的时间内作正确的响应，如果由于某个任务执行时间过长或者调度设计不合理而影响其他的任务的正常执行，进而超出任务规定响应时间的情况，会对系统的正常运作造成很大的影响。根据软件的严重度等级，这些潜在安全隐患的排除需要通过形式化的验证方法或者具有充分的测试覆盖度的测试方法进行证明。
针对性能问题，在适航标准 DO178B 的第六章中明确指出 “Testing, in general, cannot show the absence of errors” ，也就是说，测试一般不能用来证明某些性能问题的清除，比如代码执行时间、堆栈用量、代码运行时错误等，一般通过测试来证明是不足够的，因为没有一种测试的手段可以对性能问题达到 100% 的覆盖度，即无法找出 WorstCase的工况。因而，标准中提出某些性能错误的排除可以通过形式化的方法（Formal methods）进行证明，而形式化方法即为一种基于模型的分析方法。此外，由于基于模型的分析方法不需要硬件环境，使得在设计阶段即对性能问题进行分析成为可能，从而尽早地发现和排除相关问题，避免在集成阶段再发现问题而导致时间和成本的浪费。
-> 基于追踪的分析
基于追踪的分析按照分析内容，又分为代码级追踪和调度级追踪。
追踪的对象是实际目标系统，一般通过代码插桩等手段，持续地进行事件（events）及对应时间戳(timestamp) 的采集和记录，这些记录的数据可以存放在目标硬件的内存或者通过相关接口实时导出。这些事件的选择可以是代码块级别、函数级别或任务 / 中断级别等，也可以细化到机器指令级别。根据不同的事件级别可以基于追踪文件分别重建代码块、函数、任务 / 中断、甚至是每个机器指令的实际执行时序情况。
相应的，对机器指令、代码块、函数等基于追踪文件的时序重建，可以分析得到代码执行时间最小值、最大值、平均值等数据，即为代码级追踪分析的内容。而对任务 / 中断基于追踪文件的时序重建，可以分析得到任务 / 中断延时和 CPU 实时负载的最小值、最大值、平均值等数据，即为调度级追踪分析的内容。
文章来源地址https://www.toymoban.com/news/detail-454471.html
常见的基于追踪的代码级性能分析工具有 TimeWeaver+Lauterbach、Gliwa、RapiTime 等；常见的基于追踪的调度级性能分析工具有 TraceAnalyzer、Lauterbach、iSystem、Greenhill、RapiTask、Gliwa 等。
搁笔分享完毕！
愿你我相信时间的力量
做一个长期主义者
到了这里，关于车载基础软件——嵌入式系统时间特性分析的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![软考-嵌入式系统设计师：[嵌入式系统基础:笔记(一)]](https://imgs.yssmx.com/Uploads/2024/01/401500-1.png)
