655_AUTOSAR_EXP_VFB文档阅读12
作者：互联网
继续梳理《AUTOSAR_EXP_VFB》，把文档分成一个个小块逐个击破。2万多页的文档肯定不是一蹴而就的，慢慢来，得学会享受着其中的过程。这次的梳理内容，主要是从接收方的角度来看VFB的通信功能设计。
接收者可以访问与接收组件的 RPort 关联的 SenderReceiver 接口中定义的每个数据元素的值。
对于具有“last-is-best”语义的数据元素，接收者可以访问该数据元素的最新值。 或者，接收器被告知数据元素是“无效的”（如果数据元素支持此功能）。 接收者可以访问数据元素的生命信号，无论其值是有效的还是过时的。 生活是通过配置 VFB 来定义的（见表 4.2 中的属性“TIME_FOR_RESYNC”和“ALIVE_TIMEOUT”）。
如果是队列处理的话，数据是否有效其实是容易说明的，依据队列是否为空即可。
这是几条设计要求：
在配置时，必须定义组件的 RPort 或 PRPort 中每个 last-is-best 数据元素的初始值。
接收方通过接收组件获取到的数据元素的当前值，当发送组件没有提供值时，是配置的 RPort 或 PRPort 的初始值。
如果数据元素支持，接收组件的初始值可以是“无效的”。
在配置时，必须知道组件的 RPort 或 PRPort 中的每个 last-is-best 数据元素是否要获知该数据元素的生命信号。
获取数据元素生命信号的接收器必须配置接收之间的时间段。此阈值决定了数据元素的有效性：有效或者超时。
对于具有入队语义的数据元素，接收者本质上只有一个操作：从队列中获取下一个数据元素。 如果队列为空，则将此结果返回给接收者。 否则，读取下一个数据元素值并从队列中取出（换句话说，这是一个“消耗读取”）。 队列的容量通过配置 VFB 来定义（见表 4.2 中的属性“RECEIVER_QUEUE_LENGTH”）。
说的非常啰嗦，其实就是一句话：接收者可以进行出队操作。
总结设计的原则：
与具有入队语义的数据元素关联的队列最初是（在发送方向队列添加值之前）为空队列。
逻辑上，队列位于接收方一侧。这个，看起来是对定义方做了一个指明。
配置时必须知道接收者队列的大小。
接收者队列具有先进先出语义。
接收者队列为满时一个新的值到达，这个值被丢弃（“队列溢出”）。看起来，这里直接明确说明了不允许复写。
如果接收者在配置时表示它需要“队列溢出”这个通知，则可以通知接收者“队列溢出”。
表 4.2 概述了接收方可以用来控制发送方-接收方通信模式行为的通信属性。这些属性是在单个数据元素或模式组级别定义的。
结合之前看过的发送，1,2,5条还是容易理解的。增补一下其他的几条。
同步时间：数据丢失之后，允许的数据同步时间。
活动超时：接收器指定接收数据元素可能需要的最长时间 如果未在定义的时间段内接收到数据元素，则数据元素“过时”。从后面的描述看，这些其实是可选的。
接收事件：这意味着当接收到数据元素或模式切换的新值时，RTE 会通知接收应用程序。 这意味着接收组件不需要轮询但可以等待新的数据元素或模式更改。也是可选的，但是我觉得这种事件机制在CPU利用以及实时性上应该会有优势。
接收的相关信息看起来是比发送多一些。这一部分，前两个其实没有什么分析梳理的必要了，只是具备一个通用化的概念。看看剩下的两个。
滤波：如果数据元素的值通过滤波器的条件，则数据元素仅传递给应用程序。 如果数据元素的新接收值未通过过滤器的条件，则该值将被丢弃（未添加到排队接收器的队列中或未更新数据元素的当前值以用于最后一个最佳接收器 ）。 VFB 提供与OSEK-COM V3.0.3, P.12 中定义的过滤器相同的过滤器（可能叫做过滤器会更好一些，前面的滤波器可能翻译不对，不改了，保留一下自己分析的思路）。 这些过滤器只能应用于原始类型的数据元素。
软件实施机制：当使用参数接口时，可以键入访问参数的机制。这将允许在处理固定数据交换时进行预编译时间和编译时间优化。
这一条我其实是在实践中是没有用过的，但是这一条描述突然间让我联想到了hightec编译器说明书中一些只读等专用分区的处理。如果有这样的处理，编译器会有优化访问速度的手段？
这次从接收方的角度梳理了VFB的通信，从软件设计经验的印证以及对我以后软件设计的启发都有一定的帮助。唯一的难点可能还是这个抽象度还是有的，没有实际东西的结合，立即诶着实不容易。
标签：AUTOSAR,12,队列,元素,VFB,接收者,接收,数据 来源： https://blog.51cto.com/greyzhang/3004886