AUTOSAR基础篇之Event_新能源技术.docVIP

AUTOSAR基础篇之Event ?1 Event 使能条件 作为事件监控的基本单元，Event能否开启监控绝大部分情况下都需要满足一定条件，只有这样，才能够保证Event监控是否存在意义，若不加以相关的限制条件，那么会导致增加诸多的信息干扰导致最终无法快速排查Root Cause，说的简单点，就是起到了Event过滤器的作用。通过该Event过滤器，可以得到你所允许上报或者抑制的Event上报。 ·??????比如典型实例就是当总线Busoff发生时，同时会发生很多报文丢失的故障，但是这些timeout故障只是sequential events，是顺理成章的事。但我们不希望报出这些sequential events，就会为这些Event添加相应的Busoff的使能条件。即只有当总线没有发生Busoff时，才允许记录这些Timeout的events, 才显得更有意义！ ·??????比如上电经过特定时间之后才允许开启电压监控，因为ECU刚上电电压不稳定是一个正常过程，应当予以过滤掉，故而为电压监控的event添加上电初始化时间的使能条件。即在上电特定时间内禁止电压相关事件监控，其余事件可以正常开启监控； ·??????再比如有些event需要获取KL15状态信息或者其他的一些综合条件，才能够进行event上报，因此使能条件可以自由根据客户的需求进行添加，当然如果涉及到event之间的依赖关系，也可以利用Dependency Node来起到Event过滤器的作用，后面会继续讲到。 event的使能条件就相当于event过滤器，可以实现event在某种特定条件下event才被允许上报，为了更为清楚的了解到event上报的全部流程，如下图1所示： ?图1?event上报处理流程图 ?在上图中可以看出，一个Event从上报到最终被存储需要经历种种千辛万苦的考验，才能最终落地生根，修成正果被你所看到。 S1：首先，需判断是否开启了Operation Cycle，如果是，则继续下面Enable Condition的判断，否则就直接结束； S2：若Enable Condition Fulfilled，则进行85诊断服务的判断，若不满足，则直接结束； S3：若此时使能了85服务，则直接结束，若没有，则可以继续往下进行Debouncing； S4：经过Debouncing之后，若Event发生变化，则也会反映到DTC Status的变化，若没有变化或者没有结果，便可以直接结束； S5：到此并没有结束，Event能否正确存储至NVM中，取决于是否满足Storage Condition, 同时，在满足存储条件之后，若event entry已满，能否最终存储还取决于event优先级以及event之间的依赖关系等。? 2 ?Event 上报方式 ? ? ? 当Event满足上述的使能条件之后，其触发的方式主要分为两种：循环上报型与Event触发型，两者的区别显而易见，前者Event一旦触发，就会循环不断地上报event状态，后者则是Event状态发生变化的时候，才会触发一次，并不会一直上报。有小伙伴就问了，为啥要做这两种区别呢，故障一旦触发，一直上报不就行了吗？问的在理，这是因为从软件架构设计的层面考虑到，event上报来源于各个SW-C模块，经过RTE传输至故障处理模块，但是模块上报的Event数目非常多，如果都采用Polling上报的方式，那么无疑会增加RTE传输数据的负担，而且对于故障处理模块而言，其实只需知道你的最新状态即可，所以在这种情况下，采用Event触发型无疑是更明智的选择，即仅当Event状态发生变化时才会触发一次上报。如下图2所示，体现了两种不同上报方式的优缺点以及应用场合。 图2?Event触发方式的对比 ?从上图2可以看出，无论是采用循环上报还是Event触发方式上报，本质上都是调用相同的DEM?API函数接口来实现Event进一步的处理，因此，在event上报选择方式上面，应当结合图中优缺点综合考虑，切不可一刀切，应当建立在软件架构的基础上去实现客户的需求，才能保证选择方式的合理性。 3 Event去抖动策略 当Event上报之后交由故障处理模块处理，在处理的过程中有一个非常重要的环节：去抖动策略，该策略就是为了防止所有故障误报应运而生?，只有经历了去抖动算法之后，Event的最终状态才能够被确定，也就是PASS、FAIL, No Result这三类。一般而言，去抖动策略也分为两种：TimeBase与Counterbase，TimeBase是通过计时来完成对Event的去抖动的过程，而CounterBase则是通过计数来完成对Event的去抖动，比如timeout类故障，可以直接采用TimeBase的策略来完成去抖动，比如Ev