ARTICLE · 1219532
外来技术上车记:01_IT/互联网软件
外来技术上车记:01_IT/互联网软件1996 年 4 月 12 日，Gartner 发了两份研究笔记，编号 SPA-401-068 和 SPA-401-069，标题都叫面向服务的架构。那时候的 SOA 解决的是企业 IT 的老问题：系统各建各的，逻辑和数据锁在孤岛里，改一个流程要动十个系统。 二十多年后，这套思路出现在一辆宝马里，换了个名字，叫 SOME/IP。 从企业 IT 到车载网络，中间隔着的不是一次简单的技术平移。IT 软件赢在快速迭代，车赢在十五年不出错。一个活的东西，要放进一个要求它别乱动的地方，这才是这一期要讲的事。 IT 软件上车，真正的动作不是移植，是冻结。 冻结的对象不是代码，是接口和版本。接口冻结了，实现才可以换；版本冻结了，整车才可以承诺十年维护。谁能在冻结的同时保留一点可替换的空间，谁就找到了 IT 和车之间的那条缝。 这条缝，行业用了二十年才把它撑开。 
Gartner 在 1996 年提出 SOA 时，给的定位是多层计算，让组织在多个应用之间共享逻辑和数据。它的核心不是某个协议，而是一种组织方式：把功能拆成服务，服务之间用契约连接，各自独立演进。 这套东西后来在互联网公司被推到极致。微服务、容器、持续交付，都是同一条线上的东西。IT 的赢法很清楚：用快速迭代换试错速度，用规模摊薄成本。 车一开始想要的，恰恰是这套东西的反面。 2003 年 7 月，宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众一起成立了 AUTOSAR。它要解决的是 ECU 软件和硬件绑死的问题，让软件可以跨车型复用。 AUTOSAR Classic 借了 IT 的分层思想：应用层、运行时环境、基础软件。但它做了一个和 IT 完全相反的选择：静态配置。哪个任务什么时候跑、发什么报文、占多少内存，在编译时就定死。运行时不做动态发现，不做动态部署，不做热更新。 这不是保守，是车的约束决定的。硬实时回路要求微秒级确定性，动态发现和垃圾回收都可能带来不可预测的延迟。 AUTOSAR 从 IT 那里拿走了分层，把动态留在了门外。这是车对 IT 的第一次改造：学结构，不学节奏。 真正的转折发生在 2011 年。宝马为车载以太网提出了 SOME/IP，全称是 Scalable service-Oriented MiddlewarE over IP。它把服务发现、远程调用、发布订阅带进了车内网络。 为什么是宝马，为什么是那一年？因为 ADAS 和座舱的带宽需求开始超过 CAN 和 FlexRay 的能力，摄像头、雷达、显示器的数据要在域控制器之间流动。传统的信号导向通信不够用了，车需要一种更接近 IT 的服务导向通信。 但 SOME/IP 不是 REST。它保留了车的性格：服务 ID 静态分配，报文长度有界，序列化规则固定，服务发现也有一套受控的机制。它把 SOA 的思想带进来，把 Web 的随意性挡在门外。 后来 SOME/IP 被 AUTOSAR 采纳，进入 4.1 规范，成为 Classic 和 Adaptive 之间的桥。车厂第一次承认：服务化不是互联网的专利，车也可以有服务，只是服务必须按车的规矩来。 服务化要有路。IT 的以太网是四对线、RJ45、十五米以内的办公室布线，直接搬到车上，重量、成本、EMC 都不成立。 2011 年，Broadcom 推出 BroadR-Reach，用单对非屏蔽双绞线跑 100 Mbps。同年 11 月，Broadcom、NXP、Freescale、Harman 成立 OPEN Alliance，宝马和现代是创始车厂成员。2015 年 10 月，IEEE 发布 100BASE-T1。 这条时间线很关键。车不是把 IT 以太网原样拿来用，而是把物理层重做了一遍：单对线、宽温、抗干扰、长距、低功耗。上层协议可以借，下层物理必须重造。这是 IT 技术上车的第二条规律。 2017 年 3 月 31 日，AUTOSAR 发布 Adaptive Platform 的第一个版本 R17-03。它基于 POSIX，支持动态服务、C++ 接口、OTA 和更新管理，面向高算力域控制器。 同一年，Google 发布 Android Automotive OS。2020 年，Polestar 2 成为第一款量产搭载车型。 这两件事放在一起看，意思很清楚：车厂终于承认，一套平台同时服务硬实时和富应用是不可能的。Classic 继续守着车控，Adaptive 去接高算力，座舱则交给 Android 这样的活技术。 但 Android 不能直接跑在安全回路上。于是有了第三件事：虚拟化。2017 年 6 月，BlackBerry 发布 QNX Hypervisor 2.0，用分区把安全关键系统和信息娱乐系统隔开。后来国内的一批座舱方案，也基本沿着这条路走。 虚拟化是这场冻结里最关键的一件工具。它让 Android 可以按季度更新，同时让仪表和车控待在一个不跟随更新的分区里。两个世界共享一块芯片，但不共享命运。 2012 年 9 月 11 日，特斯拉给一百多辆 Model S 推送了软件 1.9.11，这是汽车行业第一次整车 OTA。 OTA 看起来是 IT 运维的搬运，实际改造量很大。车不能像手机一样，更新失败就变砖。所以要有 A/B 分区、原子切换、回滚、断电安全、签名链、防回滚。IT 的持续交付，到了车上必须变成可回滚的交付。 这套东西后来成了智能车的标配。它的意义不只是省了几次召回，而是让车厂第一次拥有了软件发布权。发布权意味着节奏，节奏意味着可以持续改进。但节奏仍然被安全边界框住，这就是冻结和更新的共存方式。 把同一时期的 IT 技术放在一张表里，能看出一个很清楚的分层。
这张表最有意思的地方不是哪些成功了，而是成功的都改了位置。REST 留在云侧，容器不进安全回路，浏览器换成游戏引擎，Android 放进虚拟机。IT 技术上车，很少原样留在它原来的位置。 再看一组语义差异，这组差异决定了改造的深度：
这六行放在一起，就能理解为什么 IT 技术上车总是要掉一层皮。不是技术不够好，是默认值不一样。 SOA 给车最大的礼物，不是某个协议，而是契约这个概念。服务提供什么、怎么调用、返回什么，用接口描述固定下来。接口固定了，背后的实现可以换，供应商可以换，版本可以升级。 AUTOSAR 的软件组件、SOME/IP 的服务 ID、DDS 的 Topic 和 QoS，都是这个思路。冻结的粒度从代码上移到了接口上，这是车能接受 IT 技术的前提。 虚拟化解决的是共存问题。Android 可以每季度更新，仪表和车控不能。Hypervisor 把两块内存、两套调度、两个故障域隔开，中间只留受控的通信通道。 QNX Hypervisor 2.0 在 2017 年把这个做法产品化。后来高通座舱平台、国内一批域控方案，都沿着这个架构走。虚拟化不是让 Android 变安全，而是让 Android 的危险不传到安全侧。 OTA 的核心不是下载，是切换。A/B 分区让新版本先写到备用分区，校验通过后原子切换。失败就回滚，断电也不影响。 这套机制看起来是工程细节，实际是商业模式的底座。没有回滚，车厂不敢推 OTA；没有 OTA，车就永远停在出厂版本。冻结和更新不是对立的，回滚就是它们之间的桥。 最彻底的一种冻结，是不让活的东西上车。REST、gRPC、大模型推理、推荐算法，放在云侧，车只保留一个稳定的客户端。 这样做的好处是，云侧可以随便迭代，车侧不用跟着变。坏处是依赖网络，弱网和断网要有降级方案。车是一个实时边缘，不是数据中心。这条边界划清楚了，很多争论就没有了。 三个案例，三种失败。 MOST是 2000 年代的车载光纤环网，主要跑信息娱乐。它的问题不是技术不先进，而是专有、贵、带宽天花板低。以太网一来，它就没有位置了。 FlexRay来自航空的时间触发总线，10 Mbps，双通道冗余，听起来很适合车。但它成本高、生态小，最后被以太网加 TSN 吃掉。它的失败说明，约束同构不代表商业成立，成本摊薄是另一道关。 42V是 2000 年代初的电气系统升级，思路来自 IT 电源和工业供电。技术方向没有错，但生态没人跟，供应商不愿意为单一市场重做全套零部件，最后被 48V 取代。单点技术引进可以试点，系统级引进必须有人一起摊成本。 这三个案例放在这一期的结尾，是因为它们都不属于纯 IT，但都遵循同一条规律：技术可行，不等于生态可行。 把 IT 技术按位置分三层，判断就清楚了。
越靠近安全回路，越不能引进活技术。这条规则比任何具体技术选型都重要。它解释了为什么 Android 只能在座舱，为什么 ROS 量产要被替换，为什么大模型只能放在云侧或体验层。 判断一项 IT 技术能不能上车，问三个问题： 三个都是是，可以上车。有一个否，就留在云侧或座舱沙箱里。这不是保守，这是把不确定性关进它该待的地方。 IT 软件上车这条链，机会和卡点是分开的。 机会在中间件和工具链。SOME/IP、DDS、AUTOSAR AP 的实现，配置工具、测试工具、诊断工具，这些是车厂和 Tier1 都要用的东西。国内已经有一批公司在做，竞争也很激烈。谁能把工具链和认证证据链做完整，谁就能吃到这块市场。 卡点在内核和虚拟化。Hypervisor、实时 OS、功能安全内核，这些底层东西的验证周期长，客户切换成本高。QNX 在座舱虚拟化上的位置，不是一天建起来的。国产替代要过的不只是技术关，还有十年供货和 ASIL 证据链。 OTA 的云侧容易，车侧难。云侧可以自研，车侧要过 A/B 分区、回滚、签名、断电安全、法规。很多团队低估了车侧的工作量，最后卡在量产验证上。 Android 的依赖是结构性的。座舱用 Android，意味着应用生态、开发者工具、地图服务都跟着 Google 走。车厂能控制的是硬件和部分系统服务，控制不了生态的节奏。这是引进活技术的代价，也是虚拟化必须存在的原因。 IT 软件上车，做的其实是一件事：把一套靠快速迭代取胜的技术，改造成一套靠确定性生存的系统。 具体做法只有四件事： 判断标准只有三条： 车不是不能拥抱 IT，车只是不能让 IT 的节奏决定车的命运。冻结不是拒绝变化，是给变化划一条可控的边界。谁把这条边界画得清楚，谁就能既享受 IT 的生态，又守住车的确定性。
01｜IT/互联网软件：活技术怎么被冻结
合集：外来技术上车记
副标题：IT/互联网软件：活技术怎么被冻结
一、先给结论
二、纵向：一条走了二十年的路
1996：SOA 的原点
2003：AUTOSAR 学会了分层，但拒绝了动态
2011：宝马把服务搬进车里
2011 到 2015：以太网先被重做了一遍
2017：AUTOSAR 分裂，Android 上车
2012：OTA 把运维带进车里
三、横向：哪些上了车，哪些没有
四、交汇：冻结的四种手法
1. 冻接口，不冻实现
2. 用虚拟化切开两个世界
3. 用 A/B 分区兜住更新
4. 把活的东西赶到云侧
五、失败案例：MOST、FlexRay、42V
六、判据：三层技术，三种命运
它在不在安全回路里？ 它的接口能不能冻结？ 它的更新能不能回滚？
七、对中国供应链的含义
八、一页纸结论
冻接口，不冻实现； 用虚拟化切开安全侧和体验侧； 用 A/B 分区和回滚兜住更新； 把不需要上车的活技术留在云侧。
它离安全回路有多远； 它的接口能不能冻结； 它的更新能不能回滚。
