2.2 运行时环境RTE

2.2 运行时环境 RTE

本节摘要：运行时环境是虚拟功能总线在特定 ECU、特定基础软件配置、特定组件部署下的唯一实例。它不是操作系统，也不在运行时查找路由。工具在集成阶段把端口连接编译成内存拷贝或对基础软件的直接调用。读完应能说清 VFB 与 RTE 的差别，以及为什么“静态”对实时和安全是朋友。

核心问题

阅读完本节，你应当能够：

1. 用“概念模型 vs 生成实例”解释 VFB 和 RTE。
2. 画出从系统描述到 RTE 源文件的生成链。
3. 说明同一 ECU 内通信与跨 ECU 通信在生成结果上的差别。
4. 识别手写“更快总线”为何会破坏可分析性。

一、虚拟总线必须落地成路

AUTOSAR 的起点有一张理想图：虚拟功能总线。组件只通过端口说话，不关心对方在哪颗芯片、用哪条总线、内存怎么排。“发送车速”对组件就是一次写端口。理想图不能直接在 CPU 上跑。没有编译器能在不知道寄存器、缓冲区、驱动 API 的情况下，把写端口变成机器码。

于是 RTE 出现：它是理想图在这块地皮上浇出来的路。地皮条件包括微控制器资源、基础软件配置、组件部署、安全等级和栈预算。路必须保留图上的逻辑连接，同时遵守地质和法规：OSEK 风格调度、内存保护、最坏执行时间可分析。

落地不是运行时协商，而是一次性代码生成。配置工具读取：哪些组件在哪颗 ECU；端口如何互连；连接用发送-接收还是客户-服务器；数据类型、周期、是否排队；安全等级和分区。工具再结合通信模块的协议数据单元映射、操作系统任务周期，生成头文件、源文件和启动钩子。这份生成物就是这颗 ECU 独一无二的 RTE。换一颗 ECU，路要重浇，地图可以重用。

图：从虚拟功能总线到 RTE 落地

二、生成结果长什么样

对发送-接收，同一 ECU 内常见生成是带更新标志的结构体拷贝；跨 ECU 则变成对通信模块发送信号的调用，参数在生成时就对上信号句柄。对客户-服务器，生成可能是直接函数跳转，或经服务器运行实体的入口。应用看到的都是 Rte_Write、Rte_Read、Rte_Call 这类名字。名字稳定，底下的路因配置而异。

RTE 不管理 CAN 邮箱，不解析帧标识符，不决定任务优先级。那些是通信栈和操作系统的事。RTE 只做绑定：把这一次写端口，在编译期接到正确的缓冲区或正确的服务函数。所以说它“运行时”，容易误解。它的运行时行为是早就写在只读存储器里的、可被最坏执行时间工具算进去的操作。

这也解释了为何 Classic 禁用随手动态分配。若写端口内部还要现场申请内存、现场查表找路由，截止期证明会塌。静态看起来死板，对制动这种必须给出时间上限的功能，死板是美德。

/* 概念示意：同一 ECU 内的发送-接收，生成后近似于确定拷贝 */
void Rte_Write_Speed_Value(uint16 v)
{
    rte_speed_value = v;
    rte_speed_updated = TRUE;
}
​

跨 ECU 时，同样的应用调用会生成到通信服务。应用源码不用改，配置要改。这是“接口语义恒定、实现形态可变”在 RTE 这一层的具体表现。

三、工程上最容易踩的坑

第一，改生成文件。现场为了赶进度补一行，下次重新生成就丢，或者两人改出分叉。生成文件应视为中间产物，意图回到描述。第二，绕过 RTE 让两个组件共享内存“更快”。更快的代价是安全分析失去边界，多核下出现撕裂。第三，把 RTE 当操作系统：在里面实现调度策略。调度属于 OS；RTE 只把运行实体排进已有任务。

性能方面，Vector 后来的资源消耗基准给出过量级：典型车身域上，RTE 可能吃掉百分之十二到十八的可用内存、百分之九到十四的 CPU，诊断栈再叠上去会更高。数字随配置剧烈变化。优化应先减不必要的运行实体、合并信号组、避免为每个接收者复制一份发送路径，而不是先删分层。第 7.3 节会把这条说透：性能往往被配置自由度吃掉。

⚠️ 常见坑：把 Rte_Write 理解成“已经上总线”。同 ECU 时它可能只是写了块内存，对端还没跑到读。
💡 关键直觉：RTE 是契约编译器。它不在路上指挥交通，它把交通灯的时序浇进水泥。

四、和 Adaptive 的翻译层先打一个桩

第 4 章会讲 ARA。现在只需一个对照：Classic 的翻译发生在编译期，Adaptive 的翻译允许运行时发现服务。两者都拒绝应用直接摸传输细节。若你在 Classic 项目里模仿服务发现，自己写动态绑定，等于放弃了这套栈最贵的那部分——可证明的静态性。需要动态，应走到 Adaptive 或明确的混合网关，而不是把 RTE 改造成“差一点的中间件”。

钩子函数也属于生成合同的一部分。启动、关机、错误钩子让基础软件和应用在确定的生命点见面。应用不要在构造函数式的隐式时机去碰硬件，那个时机在不同芯片上并不相同。把生命事件交给钩子和模式管理，坐标系才稳定。

五、配置项里的一致性与排队

同一运行实体在一个周期内多次读同一信号，配置可以要求快照一致，也可以允许读到更新中的值。控制律通常要快照，否则滤波会吃进半新半旧。排队与否也在生成时决定：排队要预算深度，深度不够会丢边沿；不排队则只要最新。这些选择会变成生成代码里的缓冲区形状，从而进入最坏执行时间。把它们留在口头，等于让生成器替你选默认值，默认值很少符合制动或转向的直觉。

模式切换是另一类生成合同。组件在行车、诊断、刷写下端口行为不同，模式组必须进入描述，RTE 才会生成切换确认和互斥。应用用全局标志模拟模式，运行时环境不知情，诊断会话里仍可能跑行车控制律，或反过来。钩子函数给出启动和关机的确定会面点，避免在“构造函数式”的隐式时机碰硬件——那个时机在不同芯片上并不相同。

工具链侧，常见配置器会读取系统描述和 ECU 配置，输出类型头、组件头、主源和钩子桩。输出应视为中间产物。对比两次生成的差异，是查配置变更的正路；在输出里打补丁，是把中间产物当成产品。产品应是描述加构建脚本。第 5 章会把这条写成单一真相源纪律。现在只需记住：RTE 的“源码”不是人的创作现场，是契约的打印件。

问题：为什么不能把 RTE 理解成“车上的总线进程”？

因为它通常不是一个在运行时解析路由的进程。Classic 上它是生成出来的函数和缓冲区。进程直觉来自桌面中间件，会把人导向动态查找、反射和堆分配。那些东西会破坏最坏执行时间证明。证明一旦破坏，制动相关功能就失去了它选择 Classic 的理由。把 RTE 当成契约打印件，比当成总线更不容易走错。打印件可以对照描述查错；进程会诱使你加日志、加动态、加一层私有协议。

问题：同 ECU 写端口之后，对端为什么还读到旧值？

常见原因是对端运行实体还没轮到，或一致性配置允许读到更新前快照，或你以为已经上总线其实只写了本地内存。跨 ECU 才会走到通信模块。应用日志里看到 Write 成功，只表示生成函数执行了，不表示 CAN 线上有帧。分层提问：先确认连接是同 ECU 还是跨 ECU，再决定用调试器看缓冲还是用分析仪看总线。问错层，工具会诚实地显示另一层的正确现象，于是你开始怀疑栈“有时灵有时不灵”。其实是坐标系没问对。

再补一段生成对照，帮助你在配置器里不迷路。系统描述声明端口连接之后，生成器要决定这条连接的实现形状。形状只有有限几种：带标志的拷贝、带队列的缓冲、对通信发送信号的调用、对服务器入口的跳转。形状选择一旦完成，最坏执行时间分析就有了对象。对象不是“RTE 很慢”这种感觉，而是这一次写端口对应几条赋值、几次判断、会不会关中断。感觉无法进安全案例，对象可以。所以当有人说删掉 RTE 能省百分之十几内存时，先问省掉的是哪些形状的重复实例。重复实例来自过细的端口和重复的发送路径，常常能在配置里合并，而不必拆掉翻译官。翻译官拆掉之后，形状会回到手写胶水，胶水的最坏时间更难算，内存也不见得真省，因为每个人都会再写一份缓冲。

最后用一个最小对照结束本节。打开配置，找一个同 ECU 的发送-接收和一个跨 ECU 的发送-接收，比较生成函数的形状：前者接近赋值和标志，后者接近调用通信服务。形状不同，应用源码可以相同。相同是接口语义恒定，不同是实例化落地。有人觉得相同会让人失去控制感。控制感应放在描述里，而不是放在生成文件的补丁里。补丁会在下次生成时消失，消失时车上的“智慧”也会消失，只留下不可重复的黄金固件。黄金固件是 RTE 这一层最典型的失败纪念碑。纪念碑越少，坐标系越还在。

生成器对未连接端口的处理也要进评审。有的配置会插入默认值，有的会在启动时断言。默认值让虚拟台架变绿，实车传感器未接时控制律仍以为看见了合法零。零可能是合法车速，也可能是线束断开。断开应走无效编码，不应走默认零。默认零是安静成功的亲戚，会把配置错误送进量产。

要点串联

• VFB 是地图，RTE 是路：路因 ECU 而异，地图可复用。
• 生成即绑定：无运行时查找，才进得了最坏执行时间证明。
• RTE 不是 OS 也不是 COM：它只翻译，不调度总线，不抢调度权。
• 同 ECU 与跨 ECU 对应用可长得像：配置决定走拷贝还是走通信栈。
• 不要改生成代码：意图回描述。
• 需要动态绑定就换平台契约：不要把 RTE 改造成私有中间件。

下一节进入市政层：基础软件如何用分层服务把通信、存储、诊断和芯片差异收成可配置资产。