os和seo有什么差别_AUTOSAR中的功能安然方法

本文紧张分三大块：功能安全机制；功能安全方法；硬件诊断。
一样平常来说，只有在理解了功能安全机制以及理解AUTOSAR对付功能安全有哪些必要信息是须要知道的，否则对付开拓职员来说，很难在一个项目中能够高效地实现功能安全完备地系统。
本文内容非常适宜和功能安全事情干系的开拓者阅读，同时，作为AUTOSAR的一些观点知识，也非常适宜其他AUTOSAR工程干系职员进行阅读，为之后的详细配置打下根本。

功能安全机制

当代ECU包含高度模块化的嵌入式软件，可以组合非功能安全，和功能安全的SWC，它们分别拥有不同的ASIL安全等级。

根据ISO26262，如果嵌入式软件包含不同ASIL等级的SWC，要么全体软件工程都须要基于最高安全等级的哀求进行开拓，要么须要担保拥有更高安全等级的SWC的操作不会受到其他SWC的滋扰，也即须要做到FFI(Freedom from interference)的设计。

ISO26262标准也供应故障示例，这些故障/缺点会导致SWC之间产生干涉/滋扰：

内存分区 Memory Partitioning

基于更低安全等级哀求开拓的SWC，可能会涌现缺点地访问到更高安全等级SWC的内存区域，产生滋扰。
为此，SWC须要运行在不同的内存区域，或者不同的内存分区，来防止类似的内存访问违例。

在AUTOSAR中，我们须要借助于OS和RTE模块的功能来实现。

故障模式

根据ISO26262，以下内存干系的故障影响被视为SWC之间产生滋扰的缘故原由：

内存分区可以通过限定对付内存以及内存对应的硬件的访问，来达到内存保护的目标。
内存分区意味着，各OS Application运行在相互保护（不干涉）的内存区域（分区）。
也便是说，在某一个分区上运行的代码，无法修正另一个分区的内存。

此外，内存分区也可以保护只读内存段（例如代码实行）以及内存对应的硬件。

内存分区和用户/特权模式可以担保SWC之前互不滋扰——纵然某一个SWC涌现了内存干系的故障，也不会对其他软件模块有影响，如果一个SWC运行在用户模式，那么它对CPU资源/指令的访问也是受限定的。

AUTOSAR中的内存分区

AUTOSAR规范中有这样的描述：一个分区应该用一个OS Application实现；SWC被分组到单独的用户模式内存分区中。
以是内存分区的功能须要由RTE和OS来完成。

从架构上来说，运用软件运行在RTE之上，SWC之间相互连接并共同完成功能。

SWC与硬件无关，以是它们可以被集成到任一ECU上，SWC内部的变量和函数调用，都是封装起来，对外界来说是隐蔽的，只有外部的RTE调用会作为公开接口。

SWC也有运行时须要被调用的函数，AUTOSAR中，这些函数关联到Runnable上。
Runnable无法自己调用自己，它们必须被分配到操作系统的可实行实体上，实际配置当中可以通过将Runnable分配到某一OS任务中。

根据配置的不同，Runnable会周期实行或者以事宜驱动的办法被触发，Runnable分配到Task的关系可参考下图：

OS Application

AUTOSAR OS Application是一系列OS工具的组合：Task, ISR，调度表，Counter，Alarm。
所属同一OS Application的工具，可以相互访问。

同一OS Application的OS工具，可能会属于不同的SWC，RTE通过实现一个OS Application所有成员都能访问的内存区域，没有限定的办法，来实现SWC之间高效的通信。

OS Application有两类：

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来完成。

AUTOSAR运用的内存分区

AUTOSAR OS规范中干系的需求如下表：

虽然一个项目当中可以有不同ASIL等级的SWC，但是不同ASIL等级的SWC不应当被分配到同一OS Application当中，内存分区无法在这种情形下供应FFI的支持。

SWC内的内存分区

同样，有一种情形是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被集成在处理器的核上，也便是说MPU只掌握对应核的访问权限。
例如DMA掌握器和其他核，则不受这些MPU的掌握。

下方列表展示了内存保护单元配置的干系场景：

X-须要保护，O-保护可选

案例1：SWC在同一分区

SWC可以访问相互的RAM区域，因此有可能改变对方内存中的内容。

SWC无法访问外设，由于设计上来说SWC本就不知道底层架构。
如果SWC拥有外设的直接访问权限，就意味着系统很可能是不屈安的。

案例2：SWC在不同分区

SWC无法访问对方的RAM区域，因此也无法改变对方内存中的内容。

SWC无法访问外设，由于设计上来说SWC本就不知道底层架构。
如果SWC拥有外设的直接访问权限，就意味着系统很可能是不屈安的。

案例3：MCAL驱动

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。

2. 授信OS Application不受内存分区影响。

3. 内存分区不支持task级别。

4. 内存分区功能会影响系统整体运行性能。

5. BSW模块分区并不做哀求。

韶光监控 Timing Monitoring

一个功能安全的系统，哀求系统中的动作能在精确的韶光实行。
SWC无法自己决定自己的精确运行韶光，须要依赖于运行时环境以及根本软件，在集成过程中，要担保SWC的韶光约束。

失落效模式

根据ISO26262，以下韶光或实行故障被视为SWC之间的滋扰缘故原由：

壅塞运行去世锁活锁禁绝确的实行韶光分配SWC之间的禁绝确同步

韶光保护和监控和以下属性有关：

监控任务在特定时间调度不超过预期实行韶光不独占OS资源

为了担保功能安全干系功能知足韶光约束，应该能够检测并处理某一任务独占CPU（过高的CPU负载，很多中断要求）的情形。

AUTOSAR供应下列韶光监控机制：

1. OS供应的韶光保护机制

2. Watchdog Manager供应的韶光、逻辑链监控的功能

操作系统的韶光保护

根据AUTOSAR OS规范，实时操作系统在运行时发生任务或中断没有在预期韶光内实行结束，被视为发生了韶光故障。

AUTOSAR OS并不供应deadline supervisor来作韶光保护，deadline superviosr不敷以精确地识别出导致了系统的韶光故障的任务或中断，由于实际情形下，有可能是被一个没有关联的任务或中断滋扰了实行过程。

在例如AUTOSAR OS这样有固定优先级抢占的操作系统，任务或中断是否在deadline之前能实行完毕，和以下几个成分有关：

任务或中断的实行韶光因其他低优先级任务或中断锁住了共享的资源，或者是关闭中断这期间而产生的壅塞韶光任务或中断的韶光间隔

为了实现安全和精确的韶光保护，操作系统须要能在运行时掌握这些成分，担保任务或中断能够达到deadline的哀求。
AUTOSAR OS供应以下韶光保护机制：

实行韶光保护。
任务实行韶光上限，或者Cat2类型中断，它们也被称作为实行操持（Execution Budget），由OS监控来避免韶光缺点。
锁韶光保护。
资源、锁、中断挂起的韶光上限，它们也被称作为锁操持（Lock Budget），由OS监控。
韶光间隔保护。
两次任务被激活或者Cat2类型中断的韶光间隔，也被称作为韶光框（Time frame），由OS监控。

检测和反应

WdgM模块根据每一个Supervised Entity确当地状态和全局监控状态，可以基于配置进行对应的规复操作。

限定

WdgM并不限定Checkpoint的颗粒度，如果一个SWC只有一个checkpoint，代表某一runnable是周期实行的，那么WdgM只能检测这个Runnable是否按照周期在实行。
相对的，如果在每一个实行块和分支都加上了Checkpoint，那么WdgM还可以检测SWC的实行流程。
当然，更高的颗粒度意味着WdgM的配置和繁芜度也会相应地增加和提升。
Deadline Supervision只检测是否有延时，但是涌现根本不调用End Checkpoint而导致的Timeout，则无法检测出来。
Deadline Supervision不能嵌套利用。
—— Start 1, Start 2, End 2, End 1WdgM没有指定是否可以在一个Supervised Entity中设置多个Alive Supervision checkpoint。
不过推举的做法是只能由一个Alive Supervision checkpoint。
关闭或重启包含Supervised Entity的分区时，集成代码应该调用WdgM的函数关闭（关闭并重启开启）Supervised Entity。
Library不能调用BSW，以是无法被WdgM监控，但是可以通过在library调用的前后设置checkpoint的办法来作Deadline Supervision.BSW模块如何用Supervised Entity ID来识别，并没有标准化。
逻辑监控 Logical Supervision

逻辑监控用来检讨软件的精确实行，关注于掌握流缺点。
当发生掌握流缺点时，会导致走向非预期的程序实行顺序，终极导致数据不一致，数据破坏或者其他软件故障。

限定

Logical Supervision不支持一个checkpoint存在于多个Graph中。
WdgM不支持在可以并发调用的Supervised Entity进行Logical Supervision。
关闭或重启包含Supervised Entity的分区时，集成代码应该调用WdgM的函数关闭（关闭并重启开启）Supervised Entity。
端到端保护 End-2-End Protection

在分布式系统当中，如果存在一些安全操作依赖于某些数据，那么发送端和吸收真个对这些数据进行的交流过程就会影响到功能安全。
因此须要想办法担保通信数据发生数据不一致等情形的故障不会影响程序。

故障模式

根据ISO26262，在不同的软件分区和ECU上实行的SWC交流数据时，以下情形被视为信息交流干系故障：

信息重复：信息收到不止一次信息丢失：部分信息丢失信息延迟：比预期更久的韶光才收到信息信息插入：有额外信息被加入到信息当中信息伪装，或地址缺点：不真实的数据被作为真实数据吸收；发送给了禁绝确的吸收方或者吸收了禁绝确的发送方的信息序列禁绝确：信息序列被修正信息破坏：信息被修正发送方发送到多个吸收方的数据不一致应该从发送方收到，但吸收方并未收到无法访问通信通道

E2E保护假定安全干系的数据交流应该在运行时被保护起来，可能的故障缘故原由有随机硬件故障（例如CAN收发器寄存器破坏），滋扰（例如EMC滋扰），或者是软件的缺点实现（例如RTE, IOC，COM）。

从SWC角度来说，通过RTE进行数据传输的行为便是大略的点对点连接，然而，实际上通信连接的抽象的详细是由各个软件层，通信协议栈，驱动和底层硬件实现的。
基于这样的繁芜度，随之而来的是故障可能性的提升。

利用E2E机制是假定安全干系数据须要能在通信过程中担保数据不会受到故障的影响。
E2E保护最主要的部分，是保护能力和灵巧性的标准化。

E2E保护的架构是这样实现的：包含运用数据的数据元素，在发送方会加上额外扩展的掌握信息，也即E2E头部。
掌握信息一样平常包含Checksum, Counter和其他选项。
扩展后的数据被供应给RTE做传输。

在吸收方，会对吸收到的数据中的E2E头部和运用数据做检讨，如果检讨通过，掌握信息会被移除，运用数据会被供应给对应的SWC。
如果有缺点，缺点处理是在吸收端进行。

E2E Profiles

AUTOSAR指定了一组标准、可配置的E2E profiles，供应不同的保护机制实现，定义了对应E2E头部的格式。

从下列数据保护机制中挑选不同的组合，即不同的E2E Profile：

CRC checksum，由CRC library供应每次发送要求时都会自加序列Counter，吸收方会检讨是否精确每次发送要求时会自加Alive Counter，吸收方会检讨是否改变，但不检讨自加值是否精确通过port发送数据时会附上唯一的port ID超时检测：吸收方通信超时和吸收方确认超时

AUTOSAR标准定义了三种E2E Profile—— Profile 1, Profile 2和 Profile 4，后续发布会更新Profile 5和Profile 6。

应该只在项目当中利用标准E2E Profile，只有在legacy软件当中，由于分外情形，可以利用非标准E2E Profile配置。

Profile 1描述如下：

虽然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以内。

AUTOSAR最大支持4kB长度的PDU，由于利用了8-bitCRC校验值，Profile 1和Profile 2只支持最大30或42byte PDU长度的ASIL D数据传输。
自4.2.1标准以来，定义了Profile 4来适配大数据的传输，CRC校验值为32bit长。

Profile 4的头部构造如上图。

E2E状态机

吸收方根据设置的Profile来验证头部信息和运用数据是否匹配，决定当前周期吸收的数据是否精确，涌现缺点时供应额外信息。

4.2.1版本规范以来，引入了状态机的观点，可以帮助决定吸收到的运用数据在更高一级的细节上是否可以吸收，也便是说运用会收到这次通信的一个整体状态，而不须要去判断每一个的状态值。
状态机是可配置的，可以设定丢失或者重复的次数，是否可以故障规复，通信初始化等待。

E2E Library的集成

E2E Library可以利用E2E Wrapper来完成SWC之间安全干系数据的保护。

E2E Library也可以通过COM回调的办法来保护I-PDU。

当然，你也可以将上述两种方法合营起来利用。

自4.2.1版本规范以来，你也可以利用RTE Data Transformer来基于RTE级别完成繁芜数据交流的保护。

E2E Wrapper

为了利用E2E Library完成数据保护，E2E Wrapper通过封装Rte_Write和Rte_Read的办法为SWC供应接口。

在这种办法中，安全干系SWC会有自己额外的sub-layer，卖力繁芜数据布局到对应的IPDU中。

E2E保护是一种对称式的办理方案，对付实际的通信资源，它并不关心，不同的项目，SWC无需修正逻辑，只须要变更底层配置。
利用E2E Wrapper后，纵然底层通信软件协议栈不是功能安全的，仍可以为SWC双方供应功能安全的数据通信。
不过呢，E2E Wrapper不支持SWC的多实例化。

Transmission Manager

如果在某一个ECU系统中无法为COM和RTE供应操作完全性，还是传输安全数据的办理方案。

在发送方，会有一个称作为Transmission Manager的SWC，它包含E2E Wrapper，Transmission Manager会网络干系SWC的安全数据，利用E2E Wrapper来保护他们，末了将数据供应给RTE。
吸收方即这个过程反过来实行。

COM E2E回调

E2E Library可以由COM回调来进行调用，保护IPDU，不过这种办法仅限用在供应了COM和RTE操作完全性的系统上。

RTE Data Transformer

这种方案的差异，可以通过示例图很直不雅观的看出：

RTE吸收到数据往后，基于配置（例如序列号，E2E保护，加密，压缩）然后进行数据转换，将终极的结果数据交给COM进行处理。
RTE Data Transformer的所有配置都在设计arxml的时候完成，实际代码全部都是由工具天生出来的，SWC并不须要关心详细用了哪些保护机制。

这种方案须要在RTE的操作完全性被供应的情形下利用。

限定

只是利用E2E Library并不能担保端到真个安全通信，用户须要解释所选的Profile供应足够的缺点检测能力（例如硬件缺点率的评估，bit error缺点率，网络中的节点数量，的重复率，网关的利用）

SWC在RTE之间的通信不仅仅是一个大略的点对对通信，诸如数据转换，过滤，短缺关照，C/S通信参数顺序缺点，传输延迟等待也须要被考虑进来。

当运行时负载过高时，有可能会禁止利用E2E保护。

E2E不担保数据的实时性。

功能安全方法

AUTOSAR供应了上述很多功能安全机制，在功能安全软件开拓阶段，AUTOSAR也供应功能安全方法来进行支持。

可追溯性是安全干系系统实现的条件。
AUTOSAR供应从项目目的到AUTOSAR架构的软件规范的可追溯性。

AUTOSAR并不会供应所有可能须要的在运用开拓过程中的安全方法，因此安全干系运用的实现必须担保安全开拓生命周期是充足的。

包括但与限于：

AUTOSAR规范并不定义ISO26262中描述的SEooCAUTOSAR并不定义类似于HARA或HAZOP这种风险剖析管理等方法没有Safety Case没有功能安全审计没有conformance testSWC实现的AUTOSAR feature追踪对付AUTOSAR规范的验证软件集成测试