博世郑心航：传统车企和互联网造车在整车os开发上的不同与短板｜明镜pro

近期，博世在江苏省连云港博世(东海)汽车测试技术中心举办汽车与智能交通技术创新体验日。在此次活动中，博世子公司易特驰中国首席技术官郑心航就整车操作系统一些争议性问题进行了深度解答。以下为此次演讲全文：

什么是整车OS？

讲易特驰和博世集团对于整车操作系统的定义，想先转述最近在行业内一些重量级人物目前发表的公开观点。苗圩前部长在一个汽车行业论坛上发表了一个观点：未来3到5年之内，整车操作系统会成为行业内投资建设开发的重点。众所周知，3年之内整个行业普遍受困于芯片短缺，尤其是因为地缘政治，某些国家对我们做技术限制。

操作系统本身，从技术特质来说也可以说是一种高度生态圈化，赢家通吃的概念，我们需要从现在开始就加大投资进行建设，全行业必须秉持开放、开源自主可控的形式来构建这个操作系统。博世集团和易特驰，作为外资公司，非常愿意和我们行业内的客户、合作伙伴共同建设未来自主可控的操作系统。

讲了整车操作系统最近的行业趋势，我们也想借此机会抛出我们对于整车操作系统的定义，这也是我们过去一段时间内根据在国内、国外几十家整车厂第一手反馈得出的定义。

整车操作系统，各大整车厂对它的定义是面向服务架构的中间件。这句话可能有点拗口，基于服务架构，SOA这个词也并不是新鲜的概念。10、20年前电信和IT行业早就引入了这一概念。它的基本思路是将一个比较大的计算系统能够分拆成相互独立的小服务。举个例子，像线上购物的这样一个基本功能，可以拆成检查用户账号余额，检查商家的库存，从账号内扣款，以及向商家的物流系统发送运价，将这些小服务全部串在一起，就构成了线上购物的一个有用功能。回到汽车行业来说，所谓的SOA或者基于服务的中间件平台，也就是整车操作系统，是将车内各不同域的功能全部挂载到一套操作系统，或者是同一套编程接口之上，这是我们整车厂对整车操作系统下的第一个定义。

第二个定义，我们将来所有的汽车软件的开发都会以一种集中化的方式来进行开发、测试和部署。这其实是说整车操作最大的一个优势。在这里我举一个小的例子，最近和一家整车厂在探索一个非常有趣的案例，想要开发智能互联车灯的应用。从功能上来说，现在很多高端车都搭配了前置矩阵大灯，它有一个有趣的功能，可以在路面上投送图标，尤其是在夜间行车过程中。我们现在的基本场景，可以从天气系统或者导航系统感知车周围的情况，比如右后方有一辆车超车了，我们可以通过前置矩阵大灯，自动在前方路段投送一个动态的影像。假设这个场景的开发，按照传统的汽车开发方式，可能需要协调矩阵大灯的供应商，可能需要协调自动驾驶、算法，包括摄像头、传感器的供应商，进行大量车内通信矩阵的设计，每个供应商都需要修改自己的ECU，包括预控制器内的软件、算法，没有一年半载可能搞不下来。更不用说在整个过程当中可能会触发各供应商之间的工程变更费用，这是不能接受的。

但是使用我们这种新型的整车操作系统概念，将来的新应用可能只需要在操作系统之上，通过简单的调用编程接口API，一个简单的大学生可能花2到3周就可以开发完成，这是一个非常好的案例，能够说明将来整个操作系统在汽车软件开发过程当中的价值。

目前我们聊下来，无论是国内的整车厂，还是国外的整车厂，无一例外，都想要依托整车OS构建出一个庞大的开发者生态圈，这也是我们借鉴了现在智能手机行业的一大先进实践。

今天汽车行业所面临的挑战

在目前来说，国内国外整车厂在开发整车操作系统面临了哪些行业挑战？无论是从技术层面，还是业务领域，在谈他们所面临的挑战之前，我们也分享一下过去半年、一年的时间之内，我们与这些整车厂收集的第一手技术和业务开发方向的反馈。

大体来说，目前整车厂开发过程中所采用的技术路线可以分为两类，一类是以传统整车厂为代表，他们使用的开发方式、方法，包括技术栈选择，沿用传统汽车软件开发的那套方式，基本思路是从传统的AutoSAR，包括CP和AP之上逐步扩展，尤其是在功能和实时域相关开发过程当中，在这之上构建出一整套跨域的OS平台。这块虽然从成熟度，包括我们整车厂对这方面的技术把握度都非常驾轻就熟，但是它也会碰到一些显著的问题。

另外一大类，以现在造车新势力，尤其是跨界新品牌进入造车行业的，他们的选择希望以信息娱乐、安卓系统为基础，基于智能座舱逐步往下扩展，希望能够覆盖整车所有的域，能够打造一个整车操作系统平台。这两类的技术路线各有各的技术挑战，基本上可以从三个维度考虑它们面临的问题，即效率、安全和构建生态的难易程度。

首先我们回到传统整车厂在建设操作系统平台过程当中所面临的问题。传统汽车软件开发要求功能安全、可靠性，各种失效场景的判定，尤其是在实时性要求比较强的情况下，开发周期以微模型方式，迭代（时间）非常长。再加上以AUTOSAR为代表的开发领域内，虽然也提出了一些新的概念，但整体来说开发工具链相对不太成熟。

从开发效率角度来说，迭代速度非常慢。从安全角度来说也面临一些问题，虽然是在实时和高功能安全域内进行SOA平台的开发，但是在实际量产项目过程中，会发现我们整个中间件平台，由于是在实时域内的，挤占了大量车内功能安全域的算力资源，很有可能会影响到核心汽车驾乘功能，比如说底盘刹车等，因为会给整车行驶过程中带来大量的安全隐患。

最大的痛点是生态圈建设，现在汽车行业尤其是自动驾驶是一个投资热点，各大车厂都在抢了解车内软件开发的工程师和专家，尤其是在需要懂AUTOSAR的角度来说，可以说整车厂自己内部都找不到足够多的工程师，依托于传统的开发方式构建操作系统。

我们再讲另外一个极端，就是刚才谈到的使用安卓或者是触屏操作系统，进行整车操作系统的开发。从生态构建的角度来说，智能座舱沿用我们以安卓开发速度为主，有极大的生态圈上的优势。工程师的数量非常庞大，但是另外一个角度来说，安卓和智能座舱本身的系统设计之初，就是面向消费者体验的，尤其是专为触屏优化的，某种意义上来说并不具有足够多做通用计算的能力。比如我们想要在车内做一些大数据分析，可能安卓的操作系统就没有足够的工具链。或者在开发一些带功能安全的场景，比如车内仪表盘，那些现在智能座舱的供应商不得不回到传统的开发领域，使用QNX这些强实时操作系统进行相关的开发。所以我们认为，目前整车厂的技术路线或多或少都存在一些比较大的技术障碍和挑战。

今天汽车行业需要什么样的OS

将来的整车OS需要用什么样的技术路线或者用哪一种的设计思路，才能满足未来行业内各类用户包括技术上的挑战？

从过去的趋势来看，其实很多行业内的专家已经做出这样的类比，将来整车操作系统，或者是智能汽车可以看成是带着四个轮子的智能手机。如何看待这个比方？其实并不是说真的要把车内的操作系统换成触控屏，它的核心概念就是如何能够为将来整车操作系统之上的应用开发者提供一个便利的开发环境？

我们可以回过头看看2010年的时候，手机行业面临了一个翻天覆地的变化，从功能机向智能机转变。2010年之前诺基亚占据手机市场的半壁江山，之后发生的故事大家都知道。大家可能会问，是什么原因导致我们从功能机向智能机的核心变革？其中一个关键因素是苹果为代表的一些公司引入了开发者社区，尤其是给智能手机开发者提供一个非常便利的开发环境和工具链。

虽然苹果在初代机推出之后，可能大家都没有意识到，当时并没有对诺基亚造成非常重大的影响。但是真正带来行业市场翻天覆地变化是iPhone3和iPhone4之间，引入了开发者生态和应用商店的概念。将来为了支撑这样一种开发者的体验模式，必须对底层的操作系统技术栈，包括它所提供的开发工具有一个本质性的变革，同时引入跨行业的先进开发技术。

我们在谈易特驰对于将来整车操作系统的技术路线建议之前，也想引入一段我们最近中科院下属重庆中科汽车软件创新中心发布的《汽车软件全景图2022年》。各位了解和关心汽车软件行业的媒体朋友和专家，一定对这份全景图的印象非常深刻。全景图本质上来说，涵盖了从汽车软件开发设计到测试标定，到最终SOP上路之后的各类软件迭代方面的工具链、中间件。其中一个核心观点，和我们博世集团、易特驰总部提出的战略理念不谋而合。

首先，将来智能汽车软件开发模式会从基于信令到面向服务的方式进行转变，也就是刚才提到的SOA的架构，这边就不再重复了。第二，为了支撑将来汽车软件开发，需要引入云原生的概念。而且引入云原生的技术本身，这有助于打破之前提到的可能潜伏在操作系统层面对于整体技术栈卡脖子的尴尬境地，其中重大的影响就是对操作系统计算框架本身，包括在车内引入车规级容器、使用软总线、使用微服务，包括各类信息安全和功能安全的计算框架，以及对于整车、汽车应用软件、应用开发者本身便捷性的开发工具链，这都会带来重大技术和业务价值的提升。

ETAS如何应对市场挑战？

刚才我们介绍了我们认为将来操作系统需要引入的关键性技术，在这里也借此机会解答这个问题。易特驰对于未来整车厂开发整车OS将带来哪些关键性的技术来应对未来市场的挑战？核心来说就是三点：

首先，博世集团和易特驰认为，传统汽车软件开发的中间性工具链并不会被取代，而是会被融合到将来的整车操作系统上去。我们在面向包括客户、甚至博世集团内部，普遍碰到这样的问题，我们用了SOA平台，是不是传统汽车的软件，如底盘、刹车、车身稳定控制等，都会被搬到SOA平台之上？我们的回答非常明确：不会。传统几十年汽车软件的开发，无论是方法论还是规范或工具链都非常成熟，而且必须要应对各自非常特殊的软件开发过程中的各类技术特性，比如说非常强的功能安全的要求、非常强的实时性等。

基于此，传统技术开发软件工具链无可取代，这点毋庸置疑。但是反过来说，我们将来希望能将传统的工具链融合到整体操作系统之上。打个简单的比方，我们开发底盘或者是ESP车身稳定系统，涵盖实时性保障的功能，仍旧需要用我们传统工具链开发。但是ESP可以向SOA平台开放出哪些功能，比如切换驾驶模式，无论是冰面模式、雪地模式，还是调整悬挂的舒适型，这部分的整体模式控制是可以开放到SOA平台上的，由上层的应用开发者进行跨域功能的协调，这是我们第一个观点。

第二，希望在车内引入我们所提到的云原生的架构和软件栈。我们在这里下一个定义，什么是云原生？我们要澄清一个概念，并不是指一般意义上车联网的云端应用开发，而是将过去几十年互联网、IT软件行业内已经非常成熟的服务器开发技术搬到车里来。基本概念就是因为这些工具链非常成熟稳定，选择尤其丰富，同时可以提供充足的工程师及相关的技能资源，对于我们将来加入整车操作系统开发生态圈进入门槛非常低。

在这个基础之上，我们在整车OS云原生的软件栈上提供通用的操作系统Linux内核，在这之上又提供了车规级的容器，可以非常便利地让各类新型的整车应用快速迭代、更新，包括功能升级。同时我们也联合了全球各大整车厂在云原生的框架下，引入了整车数据模型相关的开放式规范，包括一整套工具链，这样方便整车厂在开发操作系统的过程中快速、便捷地将不同车型、车系的软硬件能力全部自动化的映射到SOA，包括操作系统编程API之上。

在这之上才是我们讲到的，将来能够给我们不同车型品牌提供差异化竞争的跨域应用，会由整车软件定义汽车API来提供相关的封装。将来的软件开发者所得到的体验就可以和现在智能手机行业内的开发者体验类似，也就是说可以在自己的PC环境下，启动一个车辆仿真，快速对软件进行开发、迭代，这是一个整体的理念。业务价值上也可以和传统汽车行业的软件开发方式和业务价值做一个简单的类比。为什么我们认为云原生是将来主要整车操作系统的技术方向？

从效率上来说，我们在车内引入了通用操作系统Linux，而且将来大部分的跨域汽车软件可能并不会对整车功能安全要求那么高。从效率角度来说这可以让整车跨域应用开发者，极高效的使用现在云端的各类开发技术。而且对于整车厂最大的一个优势，它不必受限于传统汽车软件那些极其细分市场的工程师和技术战略选择，可以大幅提升我们整体的开发效率。

从安全性的角度来说，刚才云原生也提到一个核心观点，隔离。所谓隔离，就是将来整车应用开发过程当中所占用的计算资源会有单独的SOC，有单独的Linux内核来保障，而不是和实时域的传统汽车软件，包括核心驾乘功能进行竞争。由此，博世易特驰提供一个安全守护的模块，其实就是从整车的角度出发，将各类功能安全的核心控制和维护收归保障操作系统层面智能汽车软件的开发者无需对整车厂功能安全的概念有太强的了解，只要关心自己面向消费者的业务逻辑就可以，这点和智能手机的开发者类似。智能手机应用开发者也无须关心底层操作系统平台的信息安全模型或者概念。

最后一点的角度来讲生态，也是我们最大的优势云原生，依托于几十年互联网IT和软件行业生态圈，无论是工具链的选择，还是工程师的整体人才储备，从数量来说，包括从成熟度，都比传统汽车软件的数量级要大2至3个数量级，构建将来整车操作系统的生态圈，这是我们最方便、最可以落地的技术路线的选择。

也想通过媒体朋友和专家，向行业内发出邀请。刚才提到的云原生概念并不是博世集团和易特驰特有的概念，而是联合了全球各大整车厂和一级供应商，以行业联盟和行业协会的形式，希望共建业界的生态系统，包括云原生的行业组织SOAFEE，由它主导将云原生的概念应用到包括汽车行业内的各类工业场景当中。

COVESA是宝马集团、博世集团共同发起的组织，不仅定义车内不同类型中间件的整合和集成方式，也包括定义整车抽象数据模型，能够和各类现有的传统汽车软件开发工具链打通。博世和易特驰集团也深度参与助力Eclipse开源项目基金会的建设。Eclipse也是IT行业内非常知名、规模很大的开源基金会组织，贡献了很多开源项目。易特驰和博世集团在整个Eclipse基金会贡献了3、4个开源项目，各位有兴趣也可以进一步深入了解。很多开源项目已经可以在互联网免费公开下载。

刚才讲了很多，可能是站在技术前沿的角度，有一点点争议性。也非常欢迎各位在座的专家和媒体朋友会后做深入的一对一交流。最后对易特驰做一个简单介绍。易特驰也是博世最近面向软件转型的代表。如果要问ETAS代表什么意思？字面上来说就是赋能未来的汽车软件（Empoweing Tomorrow’s Automotive Software）。