广告
混合ASIL系统的实现
2019-09-05 14:29:19· 来源：Vector维克多
ISO 26262标准[1]阐述了汽车领域中，功能安全相关ECU的开发流程。然而在这些ECU软件里面，只有一部分是功能安全相关的。为了减少额外的、密集的功能安全相关组件
ISO 26262标准[1]阐述了汽车领域中，功能安全相关ECU的开发流程。然而在这些ECU软件里面，只有一部分是功能安全相关的。为了减少额外的、密集的功能安全相关组件的开发工作，可以建立一个满足ISO标准的混合ASIL系统，该系统包含满足ASIL要求的功能和没有条件限定的功能，它会使用到AUTOSAR操作系统和其他的基础软件模块。
ISO 26262标准被越来越多地运用在功能安全相关ECU的软件开发过程中。在开发的初始阶段，开发人员会对正在开发的系统进行危险分析和风险评估。基于发生错误的可能性、导致后果的严重程度以及错误发生后车辆的可控制性，开发人员会制定相应的功能安全目标，并且会注明每一个目标需要达到的汽车安全完整性等级（ASIL等级），由A到D进行分类。
将所有的软件元素标记ASIL等级，通常会导致在功能组上出现不同的ASIL分类。原则上，ECU内部所有软件必须达到所有功能组当中最高的安全等级，但是这样就极大地增加了开发工作量。因为即使是非安全相关的软件，也必须按照安全流程的高要求进行开发。
混合ASIL系统可以让功能组通过适当的保护措施，实现相互之间的隔离，使其不会互相干扰，这样就将单个功能组的开发工作减少到其特定ASIL等级所需的要求。这些保护机制以AUTOSAR操作系统和其他基础软件模块的形式实现，ECU制造商不需要单独开发这些模块。
功能安全技术概念
开发人员必须要确保整个系统满足功能安全需求，系统中的任何一个软件组件都不会影响这些功能安全要求的实现。因此，对于没有安全相关的软件组件来说，唯一的功能安全要求就是必须要遵循无干扰的原则。不受软件组件的干扰，是由三个特性来定义的：
- 安全的内存访问；
- 正确的时间执行；
- 安全的数据交互。
此时，可以通过经典的验证方法来验证组件的无干扰性，例如：代码审查；还可以使用专门开发的代码检查器来检查基础软件的无干扰性[2]；当然，也可以在软件中采取其他措施，去保护软件不受硬件相关问题的干扰。
MICROSAR OS SafeContext（图1）提供的保护机制可以防止错误地篡改内存内容。通过将每个功能组划分为所谓的OS application，每个功能组的数据都被分配到了不同的内存分区中；应用程序的数据，诸如堆栈的上下文相关数据以及重要寄存器里的内容，也一起放置在这些分区中。此时通过芯片内部的内存保护单元（MPU）实现内存分区的访问禁止。
当切换运行任务或中断服务程序时，操作系统会执行上下文的切换。此时会存储上下文数据，并且重新配置MPU，这样可以仅仅为切换后激活的任务或中断服务程序启用内存分区保护（图2）。这个切换是由操作系统来执行的，并且操作系统本身是安全的。因此，AUTOSAR操作系统里面MICROSAR OS SafeContext被分配了ASIL D的等级，并且按照ISO 26262中定义的ASIL D等级进行开发。
综合验证概念
监控功能安全相关系统中的程序流也是非常重要的。AUTOSAR中定义的Watchdog Manager（图1）就是用于此目的，该模块是对MICROSAR OS SafeContext的补充。它是以SafeWatchdog[3]的形式实现，同时满足ASIL D的要求。该组件控制硬件WatchDog，并确保在发生错误时重置ECU。此外，该组件还监视应用程序任务的正确时间流程。开发人员可以为实现监控功能设置一些参数，例如程序流程、周期时间、最小/最大执行时间等。
此外，通过端到端保护实现无干扰的另一个要求——可靠的通信（图1）。在AUTOSAR规范中指定的E2ELib[4]的帮助下，SafeCOM使用CRC和顺序消息号来保护要传输的数据。严格来说，这并不能确保安全通信，而只是通信中的完整性。软件无法防止由于硬件错误导致的数据故障，例如总线被破坏。为确保安全通信，必须在硬件中额外采取一些措施，例如：冗余总线的形式。
应用软件和操作系统的集成
在ISO标准中，由外部供应商开发并提供给ECU制造商的功能安全相关组件被称为“Safety Elements out of Context”(SEooC)，它们包括上面讨论的操作系统、看门狗管理器以及E2ELib。在开发过程中，这些组件的供应商必须在不熟悉ECU项目的情况下对预期的安全目标做出假设。因此，作为集成工作的一部分，ECU开发人员必须检查所提供的SEooC的安全目标是否满足其项目的要求。此外，ECU开发人员还需要遵循软件模块的特殊集成说明。因此，每个SEooC都与安全手册一起提供，其中包含有关安全目标的集成说明和假设。所以即使在有这些SEooC组件的情况下，ECU开发人员也得额外投入一定的精力去完成正确的使用和集成。不过跟将ECU内部所有软件都提升到最高ASIL等级相比，工作量是明显降低的。
总结
TÜV Nord于2012年认证了Vector为TMS570微控制器开发的支持SafeContext的操作系统，使其成为全球第一个通过ASIL D认证的AUTOSAR操作系统。目前Vector正在将此开发方法转移到其他芯片平台上，包含使用越来越多的多核处理器。
MICROSAR OS SafeContext与Safe Watchdog和SafeCOM基础软件模块一起使用，为功能安全相关的ECU提供了安全的开发基础，可用于实施混合型ASIL系统。此外，区别于“freedom from interference in relation to memory access”的功能安全系统实现方式，Vector还将所有基础软件和RTE实现到ASIL D等级。exida分别于2016年和2017年认证了Vector基于AURIX TC275开发的基础软件和RTE，都达到了ASIL D等级。这样，在特定功能安全ECU中，考虑到上下文切换导致的CPU负载的增高，可以将功能软件和基础软件、RTE分配到同一个内存片区，尽可能地减少上下文切换的频率，为功能安全ECU软件系统的设计提供了另外一种可能。
参考文献
[1] ISO 26262 - Road Vehicles - Functional Safety, 2011
[2] G. Heling, J. Rein and P. Markl, “Koexistenz von sicherer and nicht-sicherer Software auf einemSteuergerät” (“Coexistence of safety and non-safety software in one ECU”), ATZ special electronics issue of electronica, pp. 62-65, November 2012
[3] AUTOSAR, “Specification of Watchdog Manager”
[4] AUTOSAR, “Specification of SWC End-to-End Communication Protection Library”
广告 
广告
最新资讯
-
Plus为自动驾驶卡车功能添加了H.E.L.P.警报
2024-12-23 17:18
-
美国能源部发布最新版氢计划
2024-12-23 17:16
-
系统级封装（SiP）在新能源汽车领域的应用
2024-12-23 08:51
-
车载通信框架 --- 智能汽车车载通信架构浅
2024-12-23 08:40
-
全国首例！武汉车网智联公司完成智能网联测
2024-12-23 08:39
广告
广告
