全部学习汇总： https://github.com/GreyZhang/hack_autosar
继续梳理《AUTOSAR_EXP_VFB》，今天应该能够完成这个文件的梳理。
与非 AUTOSAR-ECU 的交互
简介
本节描述与非 AUTOSAR-ECU 在 VFB 级别的交互。 这种交互例子：软件移植。
非 AUTOSAR-ECU 是什么呢：
未根据 AUTOSAR 机制开发的 ECU。 例如：
将 AUTOSAR ECU 集成到现有的 ECU 系统中；
将 AUTOSAR ECU 系统连接到现有的 ECU 系统；
在 AUTOSAR ECU 系统中重用现有的 ECU AUTOSAR软件。
ECU在AUTOSAR的标准下开发的，但现在很久保持不变。 例子：
重用策略（接管完全不可更改的 AUTOSAR ECU）；
具有未实施 AUTOSAR VFB / AUTOSAR RTE 的 ECU 的智能（“智能”）传感器/执行器。 例子：
使用商用 LIN 节点。
本文档未分析 AUTOSAR SW-C 与一个 ECU 内的非 AUTOSAR 软件的交互。
最初看这个文件，可能还以为会跟我现在工作中遇到的制作AUTOSAR非标件的工作很相似，现在看起来我遇到的困惑还是无法找到答案。这里的玩法路子还没有我现在遇到的这么野。
交互问题
与非 AUTOSAR-ECU 的交互会产生以下问题：
与非 AUTOSAR-ECU 上的应用程序接口的交互：
端口/接口必须映射到预定义的通信消息（可能通过网关）；
非 AUTOSAR-SW 组件当前未在 VFB 级别建模：
AUTOSAR-SW 组件的未连接端口；
隐藏的通信负载；
旧系统不支持客户端-服务器这样的组件。
在非 AUTOSAR ECU 上实现的服务的交互/支持：
必须并行支持旧的服务/协议，以实现互操作性，例如网络管理。
通信系统支持的附加服务（例如总线睡眠/总线唤醒）。
LIN 节点本身不受影响，因为它使用主从模式：
服务/协议在任何情况下都必须由主节点（在这种情况下为 AUTOSAR ECU）管理和实施；
节点功能文件 (NCF) 中可用的所需配置数据
支持增强服务/协议的问题（例如网络管理、诊断（连接到 AUTOSAR SW-C）、传输协议层等）。
补充理解：之前对LIN知之甚少，看起来这个对于软件架构的依附度不是很高。如果是这样，其实我觉得SENT也应该是这类情况。
非 AUTOSAR ECU 是连接到相同还是不同的通信系统与 VFB 无关，因为在 VFB 级别上没有考虑任何硬件。 出于同样的原因，网关配置与 VFB 无关。
交互描述
对于所有类型的非 AUTOSAR-ECU 交互的建模都是相同的。
非 AUTOSAR ECU 被建模为具有单独 AUTOSAR SW-C（带有 AUTOSAR SW-C 描述）的单独 ECU，这将不会实现。 为了启用与非 AUTOSAR ECU 的通信，AUTOSAR ECU 上的 RTE 必须为非 AUTOSAR 通信实现接口封装。通信消息、配置和负载由系统约束模板定义（对于 LIN 节点，节点功能文件中包含的信息 （NCF）必须集成到系统约束模板中）下图（图 12.1：与非 AUTOSAR ECU 的交互）应通过提供非 AUTOSAR-ECU 与 AUTOSAR ECU 交互的示例来阐明交互。 示例中显示了端口类型转换器（适应客户端服务器/发送方接收方通信）。 端口类型转换器必须位于 AUTOSAR-ECU 上； 它不一定需要位于最终通信伙伴所在的同一 ECU 上。 由于转换器来自“AUTOSAR SW-C”类，因此必须作为单独的组件实现。 在以后的解决方案中，它可能是自动生成的 RTE 的一部分。
对于发送方-接收方通信，没有显示适配。 但即使使用相同的通信范式，由于不同的通信属性，也可能需要进行调整。 这将像端口类型转换一样完成。 适配必须作为一个单独的 AUTOSAR SW-C 来实现； 在以后的解决方案中，它可能在自动生成的 RTE 中完成。
通信系统信号（例如 CAN 上的信号）和 RTE 层之间的方式对于 AUTOSAR 和非 AUTOSAR 信号是相同的。
这么看，现在的软件架构中RTE的功能可能还不是很完善。后续的工具如果升级跟得上，很可能非标准的模块集成也可以走RTE来实现。但是，针对于我看的这个标准，目前似乎还没有什么可行性的方案。
这是前面提到的图，增强服务/协议的支持（例如网络管理、诊断（连接到 AUTOSAR SW-C）、传输协议层...）可以由复杂驱动程序或相应基本软件模块的“特殊”实现来处理。
这样，这个文件的梳理基本就结束了，剩下的信息基本都是附录信息，主要是涉及到一些参考文档，暂且不去看了。