继上篇介绍AUTOSAR基础篇之Event（上）之后，本文将重点介绍Event的优先级，Event Displacement、Event Dependency Node、Event Storage Condition四个方面给大家介绍。
- Event优先级
Event优先级的提出是为了解决当ECU内部存储的Event入口已满的前提下，如何决定当前发生的Event怎样存储的问题，到底是舍弃当前新产生的Event还是剔除已存入却已经恢复或者非Active状态的Event来保证最新Active状态的Event存入NVM，这对于故障分析处理也是十分必要的。一般如下所示，Event优先级存在以下几个特点，如下图1所示：
图1 Event优先级的基本特征
有一点需要说明的是针对多个event Map至同一DTC的场合，对于客户可见的同一DTC下所map的所有event一般都应赋予同一优先级，而对于内部event的处理，可以采用不同的优先级，即不需要考虑是否Map同一DTC。这样做的好处在于对客户而言，可以给到统一的故障信息，对供应商而言，可以保留最为重要的event信息，一举两得！同时，Event的优先级也会在下面Event Displacment的过程中发挥至关重要的作用。
2. Event Displacement
一般而言，对于ECU内部存储event的数量是一定的，通常也称为event memory entry，当前该大小取决于ECU本身存储空间，但一般不少于10个event memory entry。而event displacement仅发生在当event memory entry已满的情形下，应按照一定的策略来决定如何对新增的event进行存储。根据AUTOSAR标准，其提供了一套较为行之有效的策略供参考，且这一套机制在DEM模块实现，该模块按照这下列三大原则来实现Event displacement：
· Event Priority（这是最重要的评判原则，数字越小存储优先级越高）；
· Event Active或者Passive状态（Active存储优先级高于Passive优先级）；
· Event Occurence time（最近发生的存储优先级高于较早发生）；
为了更好的表达这三者在Event displacement中如何发生作用，以下图2中所示，该图以非排放相关系统故障监控为例，清晰表达了这三者之间如何协同作用来完成event的存储。
图2 Event Displacement Strategy
3. Event Dependency Node
在谈Event Dependency之前，我们需要引入一个概念：MonitoringComponent， 该组件代表整个ECU系统可被划分为几个大的组件来统一监控，不至于对所有Event离散型监控，因为Event也是存在类别或者依赖关系，Event之间的这些关系同样的可以映射到MonitoringComponent中。比如当某个Event发生时，有些Event就会必定发生，那么这些Event是不是应当过滤掉呢；当某组件模块发生模块，那么其依赖模块是不是也会存在问题呢？因此该组件模式就会在此发挥十分重要的作用，如下图3所示，就表现了ECU硬件组件以及COM组件模块之间的依赖关系。
图3 Event Dependencies
通过上图我们能简要知道对于存在依赖关系的event可通过上述Dependency Gragh 来体现。那么，具体到软件内部，一般做法又是如何处理的呢？接下来我们来看下图4所示的示例来完整解释对于上述过程的一般性做法:
图4 Event Dependency Gragh
正如前面讲到，当某个Event发生时，其他Event也会相继发生，那么此时我们称前者为Causal Fault， 而后者则被称为Consecutive Fault。对于Causal Fault ECU会正常执行Event handling，但是对于Consecutive Fault则会直接Ignore掉。下面我们假定五种情形，来看看DemComponent如何发挥作用：
A. 若Event A, Event B同时发生或者A先于B发生时，Event A则被视为CausalFault，而Event B作为ConsecutiveFault直接忽略掉；
B. 若Event B已经发生时，Event E就会当做Consecutive Fault直接忽视掉，因为Component 1即为Failed状态，其子Component下的Event都会被视为Consecutive Fault忽视；
C. 若Event E发生时，Event H发生时，两者都会被视为Causal Fault完成正常的Event handling，因为两者并没有存在父子关系，DEM模块会平等对待此类型的Component；
D. 若Compopnent 2模块忽视自身优先级且Component 1 处于Not Fail状态时，那么该模块2下所有的event都是平等关系，按照正常Causal Fault处理；若此时Component 1为Fail状态时，那么Component2下的所有Event均会被视为Consecutive Fault来处理；
E. 若Component 3被设置成Not Available，那么该模块也会被视为不存在整个ECU系统中，而其下的所有Event均会被设置为不可见状态；
4. Event Storage Condition
当一个Event经过上述的Event handling过程之后，其最终能否为其分配Event Memory Entry不仅取决于Event memory是否已满，在此之前还有一关要过，那就是Storage Condition。一个Event 可以存在0个或者多个StorageCondition，Storage Condition条件的设定可由DEM提供API函数Dem_SetStorageCondition来实现，每个Storage Condition可根据客户需求自由实现。如下图5所示，就体现了不同Event是否满足Storage Condition下的DEM处理过程。
图5 Event Storage Condition Processing
如上图所示，EventA的StorageCondition为1，EventB的StorageCondition为1,2，Event C的Storage Condition为1,2,3。上述Event A、B、C在经过Storage Condition Filter之前都会进行前置处理即EnableCondition Filter与Event handling过程，假定这三个event都满足各自的Enable Condition，但当前仅有Storage Condition1成立，那么仅存在Event A被存入Event Memory，Event B与C则会在这一环节被过滤，无法存储至event Memory中。不过Event B、C虽不满足上述的相应的StorageCondition, 但需要特别注意的是event B、C的Status的Bit 3（Confirmation bit）位会不为1，其余Bit还是执行正常的event handling，以便来表征该类Event 未被最终存储至Event Memory中。
除了上述列出来的常见的几大属性以外，Event还有很多属性，如Event Retention、Event Status，Aging等，大家如果感兴趣，可以多多参考AUTOSAR的相关文档来进行学习。一天的社区图书馆学习就结束了，后续会针对这些模块我也会做进一步的综合分享，也十分欢迎关注转发、点赞收藏，你的鼓励将是我分享的强大动力！感谢你阅读至此，希望能给你些许帮助！