全部学习汇总：GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
继续学习AUTOSAR，啃官方文档。
4.2.3.2 客户端/服务器通信中的错误处理
本节描述了在应用软件组件内或在 VFB [3] 通信期间发生的错误的处理。 由基础软件模块创建和消耗的错误不在本文档的范围内，因此将不讨论。
因此，本文档范围内的错误分为两个简单的类别：
• 基础设施错误和
• 应用程序错误。
软件组件实现使用 RTE API 方法与其他软件组件通信。 在此通信期间，某些错误可能因基础设施故障而发生，例如总线不工作，或预期数据值未及时到达。
这些错误列在 RTE 规范 [2] 中，因为它们是 VFB 提供的基础设施的固有特征。 因此，软件组件通常不会自行引发基础架构错误。
相反，AUTOSAR 基础软件和 RTE 将确定基础设施故障并将相应的错误代码传达给相关的软件组件。
AUTOSAR 系统不需要明确描述基础设施错误
由于固定的基础设施错误集被定义为 VFB 的隐含部分，因此 AUTOSAR 系统的开发人员不需要明确描述这些。
假设这些可能发生在运行时，应用程序开发人员应该采取措施来处理它们。
另一方面，应用程序错误特定于以 PortInterface 形式描述的功能或信息。 不可能预先定义此类错误，而是在某个 PortInterface 的设计时定义它们。
原则上，此类 ApplicationErrors 可能是各种 PortInterfaces 的一部分。
AUTOSAR 仅支持 ClientServerInterfaces 的 ApplicationErrors
到目前为止，AUTOSAR 仅支持（如图 4.4 所示）用于 ClientServerInterfaces 的 ApplicationErrors。
一个 SwComponentType 范围内的 ApplicationError
SwComponentType 可能具有由不同 PortInterfaces 键入的 PortPrototypes，它们具有相同的 shortName 但有冲突的 ApplicationErrors。
如果具有相同 shortName 的 ApplicationErrors 确实具有不同的 errorCodes，则 ApplicationErrors 被认为是冲突的。
ApplicationError.errorCode 的值
ApplicationError.errorCode 的值不得超过闭区间 1 .. 63. 以下例外适用：仅在可能的错误应该代表 E_OK 的情况下，才允许值 0。
通过 [constr_1108] 可以确保只使用返回值的六个最低有效位来指示应用程序错误。
这是与 AUTOSAR 接口的元素相关联的用户定义错误。 它特定于 AUTOSAR 软件组件提供的特定功能或服务。
因此，ClientServerOperations 可能与它们可能引发的许多 ApplicationError 相关联。 这些错误被定义为 ClientServerInterface 的一部分。
引用 ApplicationError
ClientServerOperation 引用的可能错误应由也拥有 ClientServerOperation 的 ClientServerInterface 拥有。
4.2.4 外部触发事件通讯
外部触发事件通信的语义
外部触发事件通信的底层语义是触发源可以在连接的触发接收器中启动 RunnableEntitys 的执行。 通常（但不一定）这些 RunnableEntity 按顺序执行。
TriggerInterface
外部触发事件通信的底层语义是触发源可以在连接的触发接收器中启动 RunnableEntitys 的执行。 通常（但不一定）这些 RunnableEntity 按顺序执行。
触发器接口声明了可以由触发器源发送的多个触发器。
在给定上下文中提供（即释放）或需要（即用于激活某物）的触发器。
这用于指定基于 ASAM CSE 代码的多维时间值。 它由定义时间基础的代码和最终确定时间值的比例因子指定。
例如，如果 cseCode 为 100，cseCodeFactor 为 360，则表示 360 度角。 如果 cseCode 为 2 且 cseCodeFactor 为 50，则表示 50 微秒。
如图 4.5 所示，一个 TriggerInterface 由 Trigger 组成。
周期性触发周期
触发器可以选择定义周期性触发的周期。 它通过元类 MultiDimensionTime 以时间或角度表示。 请注意，如果触发器来自基础软件，则主要用例是指定属性，例如来自复杂驱动程序，它不用作 RTE 生成器的输入。
除此之外， TriggerInterface 没有定义任何时间信息（例如源预期汇反应的速度有多快）。 这是模板中计时信息的属性。
触发接收器和触发源
由 TriggerInterface 键入的 RPortPrototype 不应被多个 SwConnector 引用，而 SwConnector 又引用由包含具有相同 shortName 的触发器的 TriggerInterfaces 键入的 PPortPrototype。
[constr_1104] 归结为触发器通信不得在 n:1 场景中实现的要求。
需要明确的是，触发器通信不支持 n:1 场景，因为它没有活跃的用例。 支持需要为触发器通信实施队列管理。
触发器的队列处理
触发器接收器的一边。 为了支持这个用例，可以以队列的方式处理触发事件通信。
在这种情况下，触发器被添加到队列中，当当前触发器的处理完成时，最前面的触发器从队列中取出并处理。 请注意，队列大小不受本文档范围内的定义的约束。 实际队列大小是在 RTE 配置过程中定义的。
触发器是否受制于排队处理的规范由属性 Trigger.swImplPolicy 控制。
Trigger.swImplPolicy 的允许值
Trigger.swImplPolicy 属性的唯一允许值是 STANDARD（在这种情况下触发器处理不使用队列）或 QUEUED（在这种情况下触发器处理肯定使用队列）。
有关将 TriggerInterface 键入的不同类型 PortPrototype 相互连接的能力的更多信息，请参阅 [constr_1204] 和 [constr_1205]。
这部分主要是看了端服务器通信错误处理以及外部事件触发通信。前者讲了大概的工具要求，也能够看得出一般的处理机制，比如哪些在基础软件处理哪些在应用软件处理等。而后者，在很大程度上其实是属于任务调度的，我觉得这部分其实应该有一些跟操作系统沟通的部分。
