继续梳理《AUTOSAR_EXP_VFB》。这一次，着重从发送方的角度看一下通信相关的一些设计。
从发送者的角度来做分析
发送方组件的 PPort 中具有“last-is-best”语义的每个数据元素始终具有当前值。 这种数据元素的初始当前值可以通过 VFB 的配置来定义（参见表 4.1 、4.2中的属性“INIT_VALUE”）。发送组件可以更改数据元素的当前值，从而覆盖数据元素的先前值。
当数据元素具有进入队列的语义时，发送方产生的连续值存储在队列中。 初始队列的长度为零（没有可用的值）。 每次发送方产生一个新值时，该值都会添加到队列中，直到达到任意且可配置的条目数。
发送组件不知道接收方的身份和数量。 它的行为与接收器的存在与否无关。 发送方-接收方通信允许发送方和接收方之间强解耦。 发送方只提供信息，接收方自主决定何时以及如何使用这些信息。 分发信息是通信基础设施的责任。 然而，在某些情况下，当已知发送方与其接收方之间的通信系统的预期服务质量被违反时，发送应用程序希望得到通知（参见表 4.1 中的属性“TRANSMISSION_ACKNOWLEDGEMENT”）。
这里提到的希望得到通知，结合我之前接触到的信息，很可能有一个例子是可以作为这个参考的，比如有些数据需要有一定的连续性。接收方会对此做一定的判断。
这是一条设计要求：在配置时，必须知道组件的 PPort 或 PRPort 中的每个数据元素是要通知组件成功传输还是超时传输类型。
从这里看，我前面的理解其实有一定的靠谱。但是，从这种行为描述来看，是不是PPort不一定能够满足全部的要求，得是PRPort？
这是前面提到的表。表 4.1 概述了发送方可用于控制发送方-接收方通信模式行为的通信属性。 这些属性是在单个数据元素或模式组级别定义的。
上面的三个属性依次为：初始值，而且可以被接收方覆盖；可以令发送数据无效，由发送方实施；如果是队列的话，队列的长度。
隐性发送：一般来说发送方显性发送并且修改当前的模式，而隐性则意味着Runnable可以在运行的时候修改数据，但是当Runnable结束之后，RTE会提供给接收方最新的数值。从描述信息看，这个其实是针对数据写入的处理，因此得出一个结论：这个其实是修改数据时候是必须声明写入才可以修改还是可以随意修改的一个差异。
传输确认事件：当数据已正确发送或模式切换已由 RTE 执行时，将通知发送组件。 如果超时发生在此确认之前，则会通知发送方基础设施错误。
关于上面这一条，在实际的实施中我暂且还不知道如何实现的。但是我赶紧这个很可能会是我遇到的一些数据不一致的现象的一个解决方案。
是否已经入队：这个其实就是普通软件意义上的入队。
这次小结到此结束，近段时间的啃读有些挑战，内容的确是稍微枯燥了一点。而且，由于本身意义的转换，很难跟我之前的工作产生足够的联想。速度稍微放慢一点也好，或许这样扎实了，后面其他文件的阅读会更加顺手一些。
