4.2 ARA运行时

4.2 ARA 运行时

本节摘要：ARA 是 Adaptive 应用面对的标准运行时契约，不是又一个操作系统。它不替代 Linux 或 QNX，而在其上规定应用如何启动、如何找服务、如何记日志、如何被资源约束。读完应能区分 OSAL、执行管理和 ara 接口族，并说明清单约束为何是可执行的而不是注释。

阅读收获

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

1. 用时间、空间、语义三类契约描述 ARA。
2. 说明 POSIX 兼容作为可信锚点的意义。
3. 解释执行管理对应用生命周期的监管。
4. 对比 RTE 生成桩与 ARA API 的差异。

一、从运行环境到契约型中间件

高速公路上一次自动变道，中央计算单元可能同时跑感知推理、规划发布、更新管理、界面渲染。它们不共享地址空间，却要协同、可启停、可隔离。维持秩序的不是再写一个内核，而是一层更抽象的运行时契约。这就是 ARA：面向自适应应用的 AUTOSAR 运行时。

常见误读：ARA 等于操作系统抽象层。抽象层存在，只是底座之一。ARA 本身是分层的、策略可插拔的契约体系。在硬件异构和功能迭代加快时，参与方无法预设对方实现，必须对行为边界、资源承诺、状态语义、错误含义达成显式约定。

时间契约：启动延迟上限、周期抖动容忍、服务响应目标。空间契约：内存峰值、CPU 份额、允许访问的持久路径。语义契约：状态机含义，例如停接收新请求但仍处理队列；错误码属于 ARA 级超时还是底层超时；服务发现用什么类型标识。契约让框架不必强制某一种进程间通道或某一种日志格式，但能强制可验证的接口、配置和可观测行为。

图：ARA 契约三层

二、POSIX 锚点和执行管理

Adaptive 选择 POSIX 兼容，是为了让工具链、库、人才和安全模块有一个公共底座，而不是为了在车上复刻桌面发行版。应用仍应优先走 ara 接口。直接依赖某发行版私有特性，移植和认证会一起变难。日志、文件、线程可以存在，但生命周期和通信的主路径应在契约内。

执行管理是中央监管。它按清单拉起应用，监视退出码和资源，异常时重启或停用。应用不要自己发明一套守护进程去抢这个角色，否则会出现双脑。状态管理与执行管理配合：车辆从驻车到行车，哪些应用必须在场，哪些必须退出，是整车模式而不是某个进程的局部 if。

三、和 RTE 对照着学

RTE：生成出来的 C 函数，调用开销可进最坏时间分析，没有服务发现。ARA：C++ 风格 API 族，通信、日志等命名空间，底下可接不同传输。应用获得弹性，失去微秒级证明。所以高等级闭环仍常留在 Classic，Adaptive 侧用监控和降级补安全案例。

资源违例不是可选日志。清单写了 CPU 上限，实际持续超过，框架应触发事件。事件之后是策略：降精度模型、停低优先级渲染、通知诊断。没有策略的违例等于没有契约。设计评审要看策略表，不只看接口表。

⚠️ 常见坑：在 Adaptive 应用里绕过 ara 直接打开原始套接字“先跑通”。跑通之后安全、诊断、发现全部旁路，集成时再补会补不回去。
💡 关键直觉：ARA 像城市交通法规。不规定发动机型号，规定路权和刹车距离的算法。

四、清单是可执行规格

清单描述应用需要的服务、权限、资源、启动顺序。它应进入版本管理，和二进制一起发布。只改二进制不改清单，执行管理会按旧约束管新程序，或反过来。这与 Classic 里 ARXML 和生成代码必须同一次构建，是同一类纪律，只是检查时刻从编译挪到了部署。

冷启动目标若写得比真实初始化短，系统会在路上反复重启应用。写得过长，故障检测变钝。数字应来自测量，而不是抄演示。第 7.3 节会再强调：配置自由度会吃资源，清单自由度会吃确定性。两边都要预算。

五、冷启动、状态机和语言边界

清单里的冷启动时限若短于真实初始化，执行管理会在路上反复拉起应用，诊断会看到一串崩溃。若过长，故障检测变钝。数字应来自测量：包括动态库加载、服务发现首次成功、模型加载。演示环境的固态盘和量产 eMMC 不是同一个时间。把演示数字写进清单，是把实验室乐观带进安全相关监控。

应用状态机应使用平台提供的语义：例如停止接收新请求但仍处理队列。自己发明一套“差不多的状态名”，运维和诊断无法对齐。错误码也要区分 ARA 级超时和底层超时，否则降级策略会找错原因。语言上可以用 C++ 标准版本，也可以用其他被平台支持的语言，但主路径应走 ara 接口。直接依赖发行版私有扩展，移植和认证会一起变难。POSIX 是锚点，不是把桌面习惯原样上车的许可证。

问题：应用自己拉起守护进程有什么害处？

执行管理会按清单监管生命周期，再养一个守护神就是双脑。双脑在重启策略上会打架：一个要杀，一个要保。打架表现为偶发双实例、端口占用、发现表混乱。把健康检查交给执行管理，把业务失败交给诊断事件，比自己写一套 systemd 更符合契约。桌面运维习惯在这里是负担。车上的单脑是为了让状态机可解释，不是为了剥夺你的控制欲。控制欲应花在清单约束和降级策略上。

清单约束与二进制必须同一次发布，这条纪律和 Classic 里描述与生成代码同一次构建是亲戚。只更新二进制不更新清单，执行管理会用旧配额管新程序，新程序可能理直气壮地超限，然后被杀死，表现为偶发功能消失。只更新清单不更新二进制，权限可能被放宽而代码还是旧的，攻击面在纸上扩大。同发布听起来像配置管理常识，在多团队 OTA 流水线里却最容易破：算法团队出包，平台团队出清单，中间靠邮件。邮件不是版本库。版本库才能让回滚同时回滚两样东西。回滚只回一样，车上会处于契约裂缝。裂缝在发现表和权限表上尤其危险，因为应用还在跑，只是跑在错误的法律里。错误的法律比错误的算法更难从日志里看出来，因为日志会说一切正常，正常是相对于那份错误清单而言的。

冷启动时限要用脏存储和实车温度测，不要用演示机的数字。演示机的固态盘和量产存储器不是同一个时间。把演示数字写进清单，执行管理会在路上反复拉起应用，用户看到的是功能闪断，诊断看到的是崩溃风暴，算法团队看到的是“平台不稳定”。不稳定的根因是契约数字撒谎。撒谎的契约比没有契约更糟，因为框架会诚实执行谎言。诚实执行谎言是 ARA 作为执法者的特点：它不管数字漂不漂亮，只管越界。越界就要有策略。策略若是重启，闪断会成为产品体验。体验问题会被当成应用缺陷。缺陷会进入错误的团队。错误的团队会优化算法。算法越优化，初始化越长，越限越频繁。频繁重启是清单与测量脱节的典型闭环。闭环要在测量处剪断，不要在算法处剪断。剪断之后，时限可以放宽或把初始化拆成先可用后变强。先可用是时间契约的产品化，不是牺牲。牺牲的是假装能在演示时间里做完全部加载。
资源违例策略表应覆盖：降精度模型、停低优先级渲染、通知诊断、必要时停应用。表要进版本库。没有表的违例等于没有契约。没有契约的 ARA 只是一套 API 名字。名字不能监管。监管需要动作。动作需要被测试：故意超限，看表是否执行。执行了，运行时才算执法。没执行，清单只是注释。注释在 POSIX 世界里尤其容易被当成“反正还能跑”。还能跑是桌面习惯。车上还能跑可能意味着正在挤占制动相关的同硅资源。同硅资源的挤占是混合架构的内部战争。战争应被配额制止，而不是被友好协商。友好协商没有截止期。没有截止期的协商，Classic 那边的格子会先碎。格子碎了，再漂亮的服务发现也救不了液压。液压不看发现表。液压看时间。时间在清单里必须是测过的，不是希望过的。

清单与二进制同发布这一条，值得在发布检查单上单独成行。只更新其中一样，车上会处于契约裂缝：旧配额管新程序，或新权限套旧代码。裂缝在发现表和权限表上尤其危险，因为应用还在跑，日志还说正常。正常是相对于错误那份清单而言的。把两样东西绑在同一个版本标签上，回滚才能同时撤回法律和身体。法律是清单，身体是二进制。只撤回身体，法律会错判一个健康的人。

执行管理看到的就绪，不等于通信管理看到的可发现，也不等于应用自己认为的初始化完成。三个“好了”必须在清单里写成可观察状态，并允许诊断分别查询。混成一个布尔，路上会出现“应用在跑但方法调不通”的窗口。窗口里规划会用默认值填空，默认值可能是空轨迹。空轨迹比明确离线更危险，因为上层以为服务还在。把状态机当成契约，就要禁止应用私自再做一套就绪标志。第二套标志是微型双脑，同样会在重启策略上打架，只是日志更难看懂。

温故知新

• ARA 不是 OS：是 OS 之上的契约层。
• 三类契约：时间、空间、语义，都要能检查。
• 执行管理是单脑：应用不要再养一个守护神。
• 与 RTE 对照：编译期桩 vs 运行时执法。
• 清单进版本库：和二进制同发布。
• 违例必须有策略：否则契约是标语。

下一节看应用之间如何说话：通信管理如何把服务契约变成发现、绑定和质量保障。