简介本文苛重分三大块：效用安然机制；效用安然步骤；硬件诊断。通常来说，唯有正在剖判了效用安然机制以及体会AUTOSAR对付效用安然有哪些需要音信是必要大白的，

通常来说，唯有正在剖判了效用安然机制以及体会AUTOSAR对付效用安然有哪些需要音信是必要大白的，不然对付斥地职员来说，很难正在一个项目中也许高效地告终效用安然完善地编制。本文实质非凡适合和效用安然处事干系的斥地者阅读，同时，行为AUTOSAR的少许观点常识，也非凡适合其他AUTOSAR工程干系职员举办阅读，为之后的详细装备打下底子。

今世ECU包蕴高度模块化的嵌入式软件，可能组合非效用安然，和效用安然的SWC，它们分手具有分歧的ASIL安然等第。

遵循ISO26262，假若嵌入式软件包蕴分歧ASIL等第的SWC，要么悉数软件工程都必要基于最高安然等第的央浼举办斥地，要么必要确保具有更高安然等第的SWC的操作不会受到其他SWC的扰乱，也即必要做到FFI(Freedom from interference)的打算。

基于更低安然等第央浼斥地的SWC，能够会展现过错地探访到更高安然等第SWC的内存区域，爆发扰乱。为此，SWC必要运转正在分歧的内存区域，或者分歧的内存分区，来避免相似的内存探访违例。

内存分区可能通过范围对付内存以及内存对应的硬件的探访，来到达内存爱惜的方向。内存分区意味着，各OS Application运转正在彼此爱惜（不插手）的内存区域（分区）。也便是说，正在某一个分区上运转的代码，无法窜改另一个分区的内存。

内存分区和用户/特权形式可能确保SWC之前互不扰乱——尽管某一个SWC展现了内存干系的障碍，也不会对其他软件模块有影响，假若一个SWC运转正在用户形式，那么它对CPU资源/指令的探访也是受范围的。

AUTOSAR典型中有云云的刻画：一个分区应该用一个OS Application告终；SWC被分组到独立的用户形式内存分区中。于是内存分区的效用必要由RTE和OS来落成。

SWC与硬件无闭，于是它们可能被集成到任一ECU上，SWC内部的变量和函数挪用，都是封装起来，对外界来说是藏匿的，唯有外部的RTE挪用会行为公然接口。

SWC也有运转时必要被挪用的函数，AUTOSAR中，这些函数闭系到Runnable上。Runnable无法本人挪用本人，它们务必被分拨到操作编制的可实践实体上，本质装备当中可能通过将Runnable分拨到某一OS职业中。

遵循装备的分歧，Runnable会周期实践或者以变乱驱动的格式被触发，Runnable分拨到Task的相闭可参考下图：

AUTOSAR OS Application是一系列OS对象的组合：Task, ISR，调理表，Counter，Alarm。所属统一OS Application的对象，可能彼此探访。

统一OS Application的OS对象，能够会属于分歧的SWC，RTE通过告终一个OS Application扫数成员都能探访的内存区域，没有范围的格式，来告终SWC之间高效的通讯。

1. 授信利用(Trusted OS Application): 可能正在运转正在监控或者爱惜效用闭塞的状况，它们可能有不受范围的内存和OS API探访权限。当收拾器支撑时，它们可能运转正在特权形式。

2. 非授信利用(Non-Trusted OS Application): 无法运转正在监控或者爱惜效用闭塞的状况，它们仅具有有限的内存和OS API的探访权限，也无法运转正在特权形式。

一个OS Application可能包蕴众个SWC和它们对应的Runnable。Runnable只被允诺直接探访它所正在的SWC的变量或者举办函数挪用。SWC内部的函数挪用和变量不被其他SWC所知，代码告终上，它们不会存正在于头文献中并供应extern的探访格式。是以，念要直接通过变量或者挪用的格式和其他SWC举办通讯是不行够的。

上图中，OS Application 1中的Runnable1 就可能实践/利用Runnable 2的实质，而正在OS Application 2中，Runnable 4是无法实践/利用Runnable 5的实质。SWC之间的通讯应该通过RTE来落成。

固然一个项目当中可能有分歧ASIL等第的SWC，可是分歧ASIL等第的SWC不应该被分拨到统一OS Application当中，内存分区无法正在这种情景下供应FFI的支撑。同样，有一种情景是SWC内部有分歧ASIL等第的Runnable，可是这种情景无法告终，由于内存分区是基于OS Application的，SWC只可分拨到一个OS Application中，那么也就只可有一个内存分区，无法为Runnable供应分歧的分区以到达爱惜：

假若必定有云云的需求，OS Application级其余分区是不够够的，必要正在Task级别举办内存分区。也即上图的最右侧一面：

AUTOSAR OS典型中对这种场景也有需求界说，可是必要留神的是，这里的刻画都是“可能”/“能够”(may)，也便是说Task级其余分区取决于OS的告终，AUTOSAR自己不做强制央浼。

通常来说，BSW模块运转正在授信形式/监控者形式内存分区当中，一面SWC分组并就寝到非授信/用户形式内存分区当中。片面SWC也运转正在授信/监控者形式内存分区当中。项目中可能有众个非授信/用户分区，每个分区都可能包蕴一个或众个SWC。

正在MPU的支撑下，非授信利用可能被允诺探访众个微节制器地点空间的分区。探访节制网罗读探访，写探访和实践探访。MPU的装备只允诺正在监控者形式下实践。有的微节制器上，MPU被集成正在收拾器的核上，也便是说MPU只节制对应核的探访权限。比如DMA节制器和其他核，则不受这些MPU的节制。

SWC无法探访外设，由于打算上来说SWC本就不大白底层架构。假若SWC具有外设的直接探访权限，就意味着编制很能够是担心全的。SWC无法探访外设，由于打算上来说SWC本就不大白底层架构。假若SWC具有外设的直接探访权限，就意味着编制很能够是担心全的。MCAL组东是读/写/初始化等操作的聚会，他们务必由其他实体，比如BSW或者CDD，来挪用实践。MCAL驱动必要外设空间的读写探访权限，遵循硬件架构，能够必要正在监控者形式运转才华有这些权限。微节制器硬件务必由OS精确装备，当展现不精确的内存探访情景时能检测到，或者能防御云云的情景。运转正在非授信/用户形式内存分区的SWC会被监控。当这种形式下展现犯警内存探访或者CPU指令时，过错操作会被拦截并由硬件爆发exception。OS和RTE通过闭塞分区或者重启此刻分区扫数SWC的格式来收拾这种情景。详细情景视项目而定，可能正在OS中装备Protection Hook的详细告终。假若念体会典型是若何诠释过错收拾的，可能阅读“Explanation of Error Handling on Application Level”。1. ISO26262并未央浼同ASIL等第OS Application内SWC的FFI。一个效用安然的编制，央浼编制中的作为能正在精确的时光实践。SWC无法本人肯定本人的精确运转时光，必要依赖于运转时情况以及底子软件，正在集成经过中，要确保SWC的时光拘束。

为了确保效用安然干系效用知足时光拘束，应该也许检测并收拾某一职业独有CPU（过高的CPU负载，良众断绝哀告）的情景。

遵循AUTOSAR OS典型，及时操作编制正在运转时发作职业或断绝没有正在预期时光内实践结尾，被视为发作了时光障碍。

AUTOSAR OS并不供应deadline supervisor来作时光爱惜，deadline superviosr不够以精确地识别出导致了编制的时光障碍的职业或断绝，由于本质情景下，有能够是被一个没相闭联的职业或断绝扰乱了实践经过。

正在比如AUTOSAR OS云云有固定优先级抢占的操作编制，职业或断绝是否正在deadline之前能实践完毕，和以下几个身分相闭：

实践时光爱惜。职业实践时光上限，或者Cat2类型断绝，它们也被称行为实践设计（Execution Budget），由OS监控来避免时光过错。

锁时光爱惜。资源、锁、断绝挂起的时光上限，它们也被称行为锁设计（Lock Budget），由OS监控。

时光间隔爱惜。两次职业被激活或者Cat2类型断绝的时光间隔，也被称行为时光框（Time f

WdgM模块遵循每一个Supervised Entity的当地状况和全部监控状况，可能基于装备举办对应的规复操作。

Logical Supervision不支撑一个checkpoint存正在于众个Graph中。

WdgM不支撑正在可能并发挪用的Supervised Entity举办Logical Supervision。

闭塞或重启包蕴Supervised Entity的分区时，集成代码应该挪用WdgM的函数闭塞（闭塞并重启开启）Supervised Entity。

正在分散式编制当中，假若存正在少许安然操作依赖于某些数据，那么发送端和收受端的对这些数据举办的相易经过就会影响到效用安然。是以必要念门径确保通讯数据发作数据纷歧概等情景的障碍不会影响步伐。

遵循ISO26262，正在分歧的软件分区和ECU上实践的SWC相易数据时，以下情景被视为音信相易干系障碍：

音信伪装，或地点过错：不切实的数据被行为切实数据收受；发送给了不精确的收受方或者收受了不精确的发送方的音讯

E2E爱惜假定安然干系的数据相易应该正在运转时被爱惜起来，能够的障碍来历有随机硬件障碍（比如CAN收发器寄存器损坏），扰乱（比如EMC扰乱），或者是软件的过错告终（比如RTE, IOC，COM）。

从SWC角度来说，通过RTE举办数据传输的举止便是简便的点对点衔尾，然而，本质上通讯衔尾的概括的详细是由各个软件层，通讯和说栈，驱动和底层硬件告终的。基于云云的繁杂度，随之而来的是障碍能够性的提拔。

利用E2E机制是假定安然干系数据必要能正在通讯经过中确保数据不会受到障碍的影响。E2E爱惜最苛重的一面，是爱惜本事和活络性的轨范化。

E2E爱惜的架构是云云告终的：包蕴利用数据的数据元素，正在发送方会加上特地扩展的节制音信，也即E2E头部。节制音信通常包蕴Checksum, Counter和其他选项。扩展后的数据被供应给RTE做传输。

正在收受方，会对收受到的数据中的E2E头部和利用数据做检验，假若检验通过，节制音信会被移除，利用数据会被供应给对应的SWC。假若有过错，过错收拾是正在收受端举办。

AUTOSAR指定了一组轨范、可装备的E2E profiles，供应分歧的爱惜机制告终，界说了对应E2E头部的式子。

固然Data ID长16bit，可能有良众种ID，但CRC校验值唯有8bit，意味着分歧的ID有能够算计出一样的CRC校验值，是以本质可用的ID数目是受到范围的。（是以，本质情景是Data ID范围正在255以内）E2E Profile 2则正在Data ID爱惜方面利用了分歧的格式。每一对S/R port都有一列Data ID，此刻的Counter肯定利用哪一个Data ID。这种计划使得检测出地点伪装的情景变为能够，但一共能利用的Data ID仍被范围为256以内。

收受方遵循配置的Profile来验证头部音信和利用数据是否配合，肯定此刻周期收受的数据是否精确，展现过错时供应特地音信。4.2.1版本典型以还，引入了状况机的观点，可能助助肯定收受到的利用数据正在更高一级的细节上是否可能收受，也便是说利用会收到此次通讯的一个具体状况，而不必要去判决每一个音讯的状况值。状况机是可装备的，可能设定音讯失落或者反复音讯的次数，是否可能障碍规复，通讯初始化等候。

自4.2.1版本典型以还，你也可能利用RTE Data Transformer来基于RTE级别落成繁杂数据相易的爱惜。为了利用E2E Library落成数据爱惜，E2E Wrapper通过封装Rte_Write和Rte_Read的格式为SWC供应接口。正在这种格式中，安然干系SWC会有本人特地的sub-layer，负担繁杂数据构制到对应的IPDU中。

E2E爱惜是一种对称式的治理计划，对付本质的通讯资源，它并不重视，分歧的项目，SWC无需窜改逻辑，只必要变换底层装备。利用E2E Wrapper后，尽管底层通讯软件和说栈不是效用安然的，仍可认为SWC两边供应效用安然的数据通讯。可是呢，E2E Wrapper不支撑SWC的众实例化。正在发送方，会有一个称行为Transmission Manager的SWC，它包蕴E2E Wrapper，Transmission Manager会搜罗干系SWC的安总共据，利用E2E Wrapper来爱惜他们，末了将数据供应给RTE。收受方即这个经过反过来实践。

E2E Library可能由COM回调来举办挪用，爱惜IPDU，可是这种格式仅限用正在供应了COM和RTE操作完善性的编制上。

RTE收受到数据此后，基于装备（比如序列号，E2E爱惜，加密，压缩）然后举办数据转换，将最终的结果数据交给COM举办收拾。RTE Data Transformer的扫数装备都正在打算arxml的期间落成，本质代码全盘都是由用具天生出来的，SWC并不必要重视详细用了哪些爱惜机制。只是利用E2E Library并不行确保端到端的安然通讯，用户必要诠释所选的Profile供应足够的过错检测本事（比如硬件过错率的评估，bit error过错率，收集中的节点数目，音讯的反复率，网闭的利用）SWC正在RTE之间的通讯不单仅是一个简便的点对对通讯，诸如数据转换，过滤，贫乏通告，C/S通讯参数程序过错，传输延迟等候也必要被斟酌进来。

效用安然步骤AUTOSAR供应了上述良众效用安然机制，正在效用安然软件斥地阶段，AUTOSAR也供应效用安然步骤来举办支撑。

可追溯性可追溯性是安然干系编制告终的条件。AUTOSAR供应从项目主意到AUTOSAR架构的软件典型的可追溯性。不由AUTOSAR供应的效用安然步骤AUTOSAR并不会供应扫数能够必要的正在利用斥地经过中的安然步骤，是以安然干系利用的告终务必确保安然斥地人命周期是填塞的。网罗但与限于：

汽车测试网-建设于2008年，报道汽车测试本事与产物、趋向、动态等 闭系邮箱 marketing#auto-testing.net (把#改成@)