看门狗应用软件为汽车安全相关系统提供可靠性服务.doc

Application of Software Watchdog看门狗应用软件为汽车安全相关系统提供可靠性服务第 9页 共 9 页学号：201020700028 刘翔Xi Chen戴姆勒克莱斯勒股份公司，斯图加特, 德国Juejing Feng德国亚琛工业大学juejing.fengrwth-aachen.deMartin Hiller沃尔沃科技公司 -哥德堡，瑞典Vera Lauer戴姆勒克莱斯勒股份公司，斯图加特, 德国摘要在汽车电子面对挑战，造成了应用软件组件密度的增加和未来的安全系统的高可靠性要求，为了在运行时监测单独应用软件组件，一个可靠的软件服务是需求，以提高整个系统的可靠性。本文提出了一个提供心跳监测和程序流检测的软件看门狗服务应用。软件看门狗为一个为汽车安全电子产品集成了软件平台。给出了一个以Matlab/Simulink模型为基础的设计和软件看门狗在硬件循环验证程序中的评价。索引词 - 软件看门狗，心跳监测，程序流检测，汽车可靠性软件平台和软件服务1. 介绍和背景近年来，通过不断触发需求增加安全性和舒适性，在汽车板上的电气和电子（电子/电气）已受到更多的严格的需求。一方面，通过电子和软件实现，应用的复杂性和数量急剧增加是显着的1。另一方面，在可比的成本下，同最先进的机械系统相比，电子/电气系统及网络应至少表现出同样的可靠性。随着功能强大的微控制器引入和成本的原因，由于越来越多的功能将被整合在一个ECU上，ECU（电子控制单元）的数目将被合并，甚至减少。面对这一挑战，确定一个通用的软件平台和标准化软件服务是两个关键的方法。AUTOSAR联盟2 是一个首创的中心标准,它的目的是为每一用在汽车上的ECU提供一个标准的软件平台。根据AUTOSAR理想，未来的嵌入式软件将从ECU的硬件细节独立出来开发。应用软件组件被映射到不同的ECU。那里应用程序被划分成叫做运行状态的代码序列元件。来自不同的应用程序运行状态能被映射成同一任务，而且来自不同的应用程序的任务也能映射到同一个ECU。因此，来自不同的软件组件的运行状态可以被映射到同一个任务是可能的。考虑就绪状态可靠性需求，对于两个就绪状态不同的时间限制是要求的。在故障检查和错误过程中，那些运行过程应该被区别对待。考虑到目前的趋势，我们需要更有力的服务来检测时间和程序流故障。这些服务不仅需要在系统集成和验证阶段，而且在运行阶段。对容错具有灵活的可靠性3软件服务的，一个定义良好的分层软件平台，是在汽车应用中提供安全相关的控制系统的关键问题。旨在监测时间行为和程序流，软件看门狗服务，是在欧盟项目EASIS设计范围内（电子体系结构和系统安全集成工程，看）。这个项目是一个22个欧洲行业领先的汽车制造商，系统供应，工具生产和研究机构组成工业联合。今天，安全系统主要是单机系统，跨域边界很少或没有联系（在上下文中，域是指如动力系统，底盘，和车身）。所谓集成安全系统（IIS）越过主动和被动域边界安全系统的组合。链接到远程处理服务也包括在这个术语中。2.相关的工作对于汽车安全系统，满足的实时需求在一个决定性的方式中是一个关键问题。为了满足时间约束，不同的监测机制得到发展，象ECU硬件看门狗356，截止监测78和执行时间监测9。为了确保正确的程序执行序列，带有控制流检测方法与签名技术已经在IT工业上开发出来。一个硬件看门狗把嵌入式软件作为一个整体，随着在一个ECU单元应用密度的增加，为了监测在一个更细节级别上的执行，例如，在任务级或者运行级，硬件看门狗应该提供软件服务。OSEKTime 8操作系统的截止日期监测和AUTOSAR OS执行时间监测介绍了任务的时间监测，但是任务层的故障检测粒度对运行状态不是足够的好。在控制流检查领域，许多检测程序流正确性的工作已经在IT工业中做出来了。大部分的当前控制流检测方法是基于指定签名，如10介绍块。 如一个技术经历从高性能开销和关于程序修改方法的低灵活性。3.功能设计软件看门狗是假定确保系统的实时性特征。追查的实时性要求以及对违反时机及早发现故障原因是不容易的，因为导致错误的时间复杂局面。一个时序违反约束可能是下列两类之一：1. 对象挂起由于被阻塞请求的资源的结果，无论是由物体本身或其他对象，足够长的违反时序约束。2. 对象是过分派出执行。根据分类，通过监测活着和运动状态到达率，软件看门狗标识这两种情形。为了正确地执行任务，程序流通过检测软件看门狗处理运动状态作为基本块。详细地介绍软件看门狗设计理念之前，我们将简要地描述EASIS软件平台，在这个平台里，软件看门狗被集成。3.1. EASIS 可靠的软件平台对于跨域边界的ISS应用，EASIS软件平台11聚焦在ECU单元上。通过提供一个标准的接口软件平台，它隔开安全相关的软件应用和硬件底层的ECU。如图1所示，通过L4活动有关EASIS软件平台覆盖层L2。ISS可靠性软件服务的第三层的服务宗旨，以增强安全性，可靠性，可用性和保密性的新的安全功能。在L3 ISS网关服务提供安全域间的通信服务。一个遵守OSEK操作系统7是在L2和L3交叉集成的，象软件看门狗一样带有安全相关服务。驱动设备，微控制器抽象层和容错硬件平台分别地驻留在L2和L1。图1：EASIS 软件拓扑3.2. 软件看门狗设计软件看门狗设计（如图2所示）如下运行状态心跳监测楖念。通过运行状态心跳提供的信息，定期监测运行状态和执行序列是可能的。此外，任务状态，应用程序状态和全球ECU状态可以得到。这样，在EASIS软件拓扑结构中，象故障管理框架12，软件看门狗能被设计成可获悉其它可靠的软件服务。一个一般的故障处理平台服务，依赖于源，类型和故障检测严重程序来进行不同的故障处理。图2：软件看门狗功能体系统结构软件看门狗有三个基本的单元：心跳监测单元，程序流检测单元和任务状态指示单元。心跳监测单元 ：随着一个心跳指示例程帮助下，运行报告它们的软件看门狗心跳。程序流检测单元(PFC)：程序流检测服务监测可运行的执行序列，通过用一套预先设置前任可能的后继者比较真正执行的后继者。任务状态指示(TSI)单元 ：在上面两个块运行状态监测检测到错误，将报告到TSI单元。TSI单元接着比较检测到的错误数目与一些预先定义的阀值和产生在运行中的个别监督报告。这些报告可以用来推导任务状态，这反过来又可以用于确定应用程序使用状态。3.2.1. 心跳监测心跳监测提供了一个机制来定期监测独立运行活动和到达率。以下故障类型处理：故障类型活动监测：由于一些原因和它的活动显示例程不执行频率足够高，导致运行被阻塞或者抢占。故障类型的到达率监测：在一个时期内，与预期相比有许多监测运行的活动的指示。在EASIS中，通过在活动计数(AC)和到达率计数(ARC)来存贮运行的心跳，我们选择一个被动的方法来记录和监测运行更改。这些两种类型计数被分配到每个可运行，以便在定义的监测时间内记录他们的心跳，这个监测时间在下一个时期开始之前，依照故障假设和立即检测。监测时期记录在活动循环计数(CCA)里和到达率循环计数(CCAR)。如果期间定义在故障假设到期或在检测到错误最后一个周期，所有哪些循环计数将被复位到零。除了数据资源用作计算外，为了控制运行中的心跳监测，一个活动状态被分配到每个运行状态。3.2.2. 程序流检测正确的程序流是一个正确可执行计算机程序的基本的部分。在嵌入式系统中，下列故障可能引起程序流错误：在软件设计产生的故障，实现和/或集成。在系统中瞬态的故障，例如，内存错误。程序计数器失效。为了减少在程序流检查过程中所涉及的开销，以及系统的复杂性，只有的安全性至关重要的运行序列将监测。跟着活动指示例程的帮助，这些将同自动生成粘结代码一起集成到运行中，其中观点目前正在执行的动行中可以得出。相对于使用广泛的讨论方法嵌入式签名所提出的建议10，或与看门狗处理器如13所讨论的，具有查找表的简单办法是尽量减少应用性能损失和广泛的应用修改的要求。在查找表里，监测运行的所有可能的前驱/后继关系被存贮和与实际执行序列比较。3.2.3. 任务状态指示 为了完成全局监测，通过集成运行状态监测的结果，运行中的错误的消息被记录在一个错误指示向量里任务状态指示单元。如果在一个错误指示向量里一个元素之一达到门阀值，整个任务将会认为故障。基于应用程序和任务映射信息，相应故障处理作为一个ECU全局视图将被采用：如果全局ECU状态是“故障”，依赖于应用需求和限制，ECU可能会影响到一个软件复位。如果一个全局ECU状态是“ok”,“失效”的应用软件组件可能复位或终止。如果有其他的任务，这不属于已终止/重新启动任何应用程序，这些任务可能会被操作系统提供的服务终止并重新启。4.确认我们探索验证软件看门狗细节处概念，简要介绍了EASIS验证活动，开发过程，方法和原型工具链表将会被给出。4.1. 简介EASIS验证 EASIS 体系结构验证器1415聚集在原型和EASIS体系架构一些大多数相关的特征，包括故障容忍硬件，可靠性软件体系结构和服务。EASIS HIL（硬件循环）验证主机一个数目的ISS-应用，象驾驶辅助应用SafeLane和带有转向线控技术的安全速度。SafeLane是车道偏离警告应用程序，和安全速度是一个系统的自动限制汽车速度达到一个外部命令最大值。在体系统结构结点验证包括故障容错执行器和传感器结点，驾驶动态控制，环境仿真，照明结点和一个门结点，它联接到TCP/IP的不同汽车域，CAN（控件网络区）16和FlexRay16.4.2. 验证过程简介该软件看门狗验证执行对EASIS中心节点架构验证。中心结点是一个机动盒子，即一个来自数据空间系统的17快速原型平台，带有控制算法和可靠性软件服务。例，软件看门狗被集成，有安全速度的安全应用。图3：工具链和开发过程如图3所示，软件看门狗验证过程如下模型和基于开发过程的模拟，其中一个子系统开发和带有一个模拟工具帮助（软件循环测试）在纯软件环境测试。在带有仿真模型帮助的一个成功的功能测试之后，在一个公共硬件平台的软件实现将不仅被发起。在应用程序需求分析之后的第一步，通过用Matlab/Simulink(一个流行的运行建模方法)来整个系统构建和建模，系统功能设计被发起。在第三步，作为一个虚拟原型，软件看门狗的原型和模拟在一个虚拟的PC机上。在接下来的步骤，基于虚拟原型和其它汽车限制，例如内存和时间需求，的知识获取，机动盒子被选择为了验证和评估在EASIS体系结构验证中的概念。软件看门狗的虚拟原型和模型的安全应用将会被映射到任务和系统结构的进度上。单独的软件说明C-代码将被产生，编译和装载进快速原型平台。4.3.软件看门狗的建模，仿真和原型为了任务建模分离和在OSEK运行的程序流，采用在Matlab/Symulink中状态流。状态流是一个设计和开发工具使用在基于有限状态机的复杂系统建模行为。运行状态用一个带有功能调用的子系统建模和在一个定义的可执行序列被发送到状态流的事件触发。一个功能调用子系统是一个块在Matlab/Simulink,这个块能被另一个块作为函数调用。例如，如图所示图4，应用安全速度能被划分成三个运行状态：在GetSensorValue中传感器读值，在SAFE_CC_process中控制算法和在Speed_process中设置执行器。有被状态流图安全速度作为函数子调用而被触发，其中实现运行顺序执行。为了显示运行的活动性，更深一层的功能子系统调用来模拟粘合代码的实现，它将报告运行的执行。图4：运行建模和程序流心跳监测单元和任务指示单元的时间触发行为用时间计数来建模。这样，为了模拟在操作系统中不同的任务调度机制，不同时间计数器可以分配到状态流中。另一方面，用一个事件触发流图建模程序流图检测单元。4.4 在EASIS软件平台中软件的看门狗集成继EASIS软件平台分层体系架构（看图1）,软件看门狗服务集成到L3作为一个独立的模块，作为与其它软件模块的定义接口。在软件看门狗中有两个主要的接口。在L1为应用程序软件组件的服务的第一接口是：报告他们的活动指示到软件看门狗。另一个接口被用来作为软件看门狗报告检测到故障到故障管理框架。故障管理框架是一个一般的故障处理系统，如收集故障检测信息，并告知应用有关故障检测。最后，用操作系统帮助和故障管理框架来制定出协调故障处理。4.5. 在EASIS中软件看门狗的验证器评估。看门狗的评估是基于在设计阶段故障/错误定义来执行的。因为不同的故障能导致同样的错误，错误注射应用于设计评估和软件看门狗原型。这样一个方法有优势，那就是可靠性需求能在一个前期投资系统开发的方式中被测试。这一概念能从特定的故障类型中被独自验证。故障，这是很难注入测试平台或在道路测试，可以比较容易地模拟有错误。在这里程序流重复被用来操作可执行频率和运行序列，通过改变运行的时间参数，操纵循环计数和建立无效的可执行流，等。数字空间实验环境操作台提供可能性：运行定时参数来操纵数据分配以及确定运行时无效的执行分支的条件。因些，它被用来触发错误注射过程应用程序的执行和以及可视化结果。通过构建不同的评估案例，三个软件看门狗主要的功能，即活动错误检测，错误到达速率和程序流错误，成功地验证。下面的屏幕截图证明了通过注入心跳或程序流错误一些评估案例生成。在X轴的每个小区图指示时间的推移，它有10毫秒一个标量。在Y轴显示了计数器的值和检测到错误数据。为了注射心跳错误，一个时间标量连接到滑动的工具来改变执行的频率，例如，图5用一个注射活动错误显示测试。以及类似测试用到达率错误和控制流错误执行。在最后一点“AM Result”(活动监测结果)在Y-值的增量指示了错误检测。图5：带有注入活动错误测试图6：显示了案例：通过软件看门狗单元协作，错误状态的真实原因被标识。这里，通过心跳监测单元，检测到的活动错误事实上是程序流错误引起的，这些将用图“PFC 结果”（程序流检查结果）报告。在三个程序流错误（这儿被设置作门阀值）检测之后，任务的状态被设置成“故障。只有一个活动积累的错误报告。图6：故障检测单元协作5.结论和展望结论在这篇论文中反映了在汽车软件开发过程中软件看门狗的概念和设计在目前流行趋势。软件看门狗，一个软件实现可靠性服务，监测应用运行状态个别的时间限制和他们的程序流。它证明了在改进在分布式汽车嵌入式系统可靠性方面功能的潜力。软件看门狗的接口为更深一层的故障处理和可变的故障包容、容错提供信息。许多有价值的经念被取得在建模，仿真和ISS应用的快速原型和使用运行概念的软件可靠性服务中。展望在EASIS结构验证中，更进一步故障检测覆盖范围的分析能对映射和软件看门狗应用在不同安全系统中所遇到的单个可靠性需求更加有兴趣。软件看门狗关于故障处理策略，特别关系到应用的重新动态配置和监测单元协作更进一步评估来自飞思卡尔S12XF微控制器一个评估。参考文献1 M. Broy，“汽车软件和系统工程，”PROC. 第25届国际会议软件工程，第719 - 720,2003 2 AUTOSAR伙伴，/ 3 Z.T. Kalbarczyk，等，变色龙：一个关于自适应容错软件基础设施，并行和分布式IEEE交易系统，卷10，第6期，1999年6月 4 K. Tindell，F.沃尔夫，R.恩斯特，“安全汽车软件开发”，发表会议记录设计，自动化测试，在欧洲会议展览（DATE03），IEEE计算机学会，德国慕尼黑2003年3月。 5 D. Lantrip，“一个多任务系统的通用看门狗定时器组件，”嵌入式世界，1997年。 6 J. Ganssle，“监督看门狗”嵌入式世界，2003年。 7 OSEK，“OSEK / VDX操作系统规范2.2.3”2005年，/files/pdf/specs/os223.pdf 8OSEK，“OSEK/VDX的时间触发的操作系统1.0，”2001年，/files/pdf/specs/ttos10.pdf 9 AUTOSAR联盟，“AUT