由盖世汽车、AUTOSAR组织、上海车展联合主办的2021第二届软件定义汽车高峰论坛暨AUTOSAR中国日在上海成功举办，本次论坛也是第十九届上海国际汽车工业展览会的同期活动。本次会议邀请到了北汽研究院智能网联中心专业总师褚景尧先生在本次论坛进行了题为《车载软件的开发和挑战》的主题演讲，以下是他在本次演讲的主要内容：
尊敬的各位嘉宾和汽车同仁们，大家上午好！我是北汽研究院的褚景尧。非常高兴盖世的再次邀请和大家一起分享车载软件的开发，希望和大家共同探讨这个大话题。
我演讲的题目是整车智能化下车载软件的开发和挑战。说句心里话，接到邀约的时候，我心里还是非常忐忑的。首先这个话题非常大，非常难，针对传统汽车人讲软件，很容易就掉进技术坑中，假如针对软件开发人才讲汽车复杂性，就会跳跃到汽车的长远规划中，总感觉很难将两者融会贯通。其次，我两年前和大家分享过一次，是以汽车工程师的身份，也算是班门弄斧。经过短暂的思考，我决定换个行头，以程序员的身份来和大家分享一次。因为我也干过10多年的软件开发，软件行业日新月异，所以肯定有讲的不对的地方，请大家批评和指正。我们看到虽然有Tesla，造车新势力三驾马车珠玉在前，但是最大的软件公司之中的Apple、Google的造车计划还停留纸面上，而传统主机厂大众、丰田、BBA等的软件实施计划并不一帆风顺。所以，本次分享则更侧重于如何搭建两者之间桥梁和纽带，促进两个行业的快速融合，提供一点点自己的建议和意见。至于软件如何定义汽车，何时定义汽车，话题太大，此次只是浅尝而至，不做详细的阐述。
其实大家可以想一想，如今ICT技术如此成熟，软件定义手机，软件定义家电是否成为耳熟能详的网络用语了么？没有。软件定义的核心思想是将软件的地位和硬件放到同等重要的位置，就想小平同志说的一样“两手抓两手都要硬”，软硬解耦， 实现API标准化，万物可编程以开发丰富的场景、应用、服务，提升用户体验，达到人车合一。而汽车是非常复杂的硬件和软件系统，先定义好“充分且必要并保证系统可靠升级”硬件平台是前提，基于稳定的硬件平台，开发好的车载软件，是目前优先要解决的问题。而不能无限夸大软件的能力，这才符合软件、乃至汽车软件的正确发展规律。
两年前提出了软件开发，软件赋能和软件驱动三个的阶段。经过两年的快速发展，个人觉得需要调整一下顺序，并且增加一个“软件定义汽车”的阶段。第一阶段，软件赋能。通过大力宣传智能化汽车，毫无疑问，自主品牌的曝光率得到了提升，同时也促进了汽车销量。而且通过部分软件功能或者用户使用流量，创造新的有别于整车销售的收益价值。这里也给大家汇报一下，北汽车联网平台数据显示，用户无限流量免费两年后大约以5%~10%的流量续费率，别看数量小，毕竟迈出了可喜的一步，且大大超出了我们的预期。 当然收益价值不仅仅是直接的金钱回报，也包括提升用户体验，增加舒适型，增加安全性，提升行车便利性，无论是自动驾驶还是智能座舱都可以为这一点提供或多或少的技术支撑，对产品力和品牌力有着一定的贡献。当然有得必有失，智能化的背后是零部件成本的上涨和高额的开发费用，权衡利弊后，主机厂都意识到战场的转移。于是快速进入到了第二阶段，就是自主软件开发。随着造车新势力自主软件开发，带动传统车企铺天盖地的软件人员招聘和成立合资公司的消息。基本可以理解为自主品牌正在攀登软件开发这一座大山。目前整个汽车行业在智能网联的大趋势下，都在厉兵秣马，招聘软件研发人员，搭建开发平台，搭建开发工具，开发软件测试工具以及验证平台，所有的主机厂都在增加投入，为未来蓄力。一旦软件可自主开发，软件驱动就成为水到渠成的事情。当然这是一个非常难的事情，需要识别出巨大的商机，譬如先行技术的科技载体，巨大的商业价值、填补市场空白或者是庞大的用户群体。先行的技术载体肯定首当其冲，汽车是目前机械和电子电气最好的结合载体，那么实现自动驾驶就是最主要的目标，也是整个汽车人的梦想。实现了自动驾驶，既会产生巨大的商业价值，也能填补市场空白。虽然用户群体没有手机巨大，但是一旦实现软件平台化，像微信、QQ音乐、百度地图、抖音不依赖与手机品牌一样，也会产生专属领域内的专属价值。自动驾驶的成熟，个人觉得软件定义汽车的时代才真正来临，首先是汽车的属性发生了根本性的变化，出行是必须但不是主要问题，旅途中所作所为成为了核心，依照不同的时间段，调用什么性质的车（这时候说开车都不对了，因为人在车里可以做自己喜欢的事情），譬如冥想车、娱乐车、用餐车、会议车……等等。然后就是车辆实现了自动驾驶，那么车的形状可能就无关紧要了，根据平台化的底盘、模块化的配置、商业化的需求、个性化的造型，完全可以打造出真正属于自己的一辆车。如图中所示（Richard Scarry‘s Cars and Trucks and Things That Go），车辆形状不一，用途不一，依然畅通无阻的行驶在道路上。童话照进现实，汽车行业变得更加丰富多彩，软件价值将会发挥更大更核心的价值。最后就是乘用车和商务车是否还有差异，需要整个行业好好考虑一下。假如自动驾驶车辆能够随叫随到，随出行中的用途而可选择不同属性的车辆，那还需要购买私家车么？这个话题非常有意思，希望有机会能够和大家一起再次构想未来。
所以汽车的智能化、软件化还是需要不断摸索，不断前行。我们依然希望通过手机智能化的开发之路为我们提供支撑，因为手机和车机的大屏显示、主控制器、传感器、电源管理、大数据、导航等应用都非常类似，手机的发展无疑可以为智能汽车的发展提供有力支撑。
首先介绍一下手机从功能机进化为智能机的几个关键因素。第一. 高性能硬件，包括高算力芯片和高性能传感器，这个不是本文的重点，就不做详细阐述。第二. 高速通信网络，这是智能机发展的基础。大家都经历过2G/3G网速特别慢的时代，就能明白那个时代其实对智能机是没有需求的，网页需要刷半天，QQ聊天还不如发短信，在线视频、游戏总卡机，那个时代智能机根本不智能。第三. 强大开源的操作系统（开源主要相对于中国来说，对美国不是很实用）。操作系统是软件开发集大成者的产物，是不是在概念上和汽车很类似？没有Google的开源操作系统，就没有智能手机时代，确切的说，就没有现在的华为、小米、OV、Samsung、Sony等的百花齐放。第四，开放的开发者平台。无论是Google的Android，还是Apple的iOS操作系统，都精心设计了容易上手开发的开放的开发者平台。这就吸引了大部分的国家和个人忘记了OS的重要性，而转向入门简单、开发容易、见效更快的应用商城和应用市场的开发。第五. 丰富多彩的应用开发。就是广大用户喜闻乐见的、各式各样、满足各种欲望的APP。 通过人口红利和高体验服务，实现软件快速获取利益价值，可以说应用软件对手机转变的助推力非常大。
综上所述，我们会发现，汽车智能化所需的转变条件基本一致。也是以高性能硬件、高速通信网络（车内和车外）等硬件为基础，通过开发强大的操作系统（开源和封闭都可以）、开放的开发者平台、丰富多彩的应用开发，完成对传统汽车对智能汽车的转变。
再简单的说一下手机软件的两种开发逻辑。一种是国外的，一种是国内的。国外的开发流程是什么呢？无论是功能机的Symbian，还是智能时代的Android或者iOS，我们首先看到的是操作系统，然后是开发者平台，而后是APP，而这些背后则是编程语言。而目前中国的状态是：APP是第一位，然后是基于某种特定技术应用的开发者平台，接下来是操作系统（OS）。不管怎么样，中国商用的操作系统已经起步，无论是Alios，还是Harmony OS，为我们提振不少士气。聊到OS这个话题，我还是忍不住好奇去百度了一下国产操作系统。虽然都是Linux版本，但是还是希望能够尽快有更多的商业化版本OS能够普及到国产预装PC/Laptop/Phone中去。至于编程语言，至少被普遍应用的编程语言，我们国家现在还是零。C、C++、Objective-C语言之父是美国人，这些编程语言对汽车软件开发非常重要，后面会讲到一些，希望大家要记住。就连日本也发明了编程语言，而且是通过东方的理念“重视人的作用，人要成为计算机的主人”去开发编程语言的，所以我们还有很长的路要走。
关于操作系统OS的开源或者不开源，这里再做进一步的阐述。我们知道，手机有两大操作系统（目前还没有统计鸿蒙操作系统），一个是谷歌的Android操作系统，一种苹果的iOS操作系统。基于目前我们操作系统能力还比较薄弱，所以很多主机厂采用了AutoSAR软件架构来开发新的架构和智能驾驶。那么我们首先来看看Tesla，这个引导整车智能化的主机厂采用的是什么操作系统呢？于是我登录了Tesla的github，网址是https://github.com/teslamotors。查到了一些非常有用的信息 。首先我们看到的是Linux sources，这也就和新闻中使用Linux 操作系统想吻合。然后还有就是我看到了React Native，React是Facebook开发的一款Javascript库，使用这个库可以很好的编写漂亮的网页UI，能简化前端程序员很多操作。 而React Native是在React基础上发展而来，目的让程序员能够真正用Javascript去开发手机端的APP，像浏览WebAPP 一样，但是同时具有NativeAPP的流程与操作体验。 还有细小的Rock solid productions， 产品是Creation and design of motion graphic projects。而这个语言是Objective-c，说明是Tesla开发的iOS APP。之前Google和 Tesla就激光雷达和高精地图争论了很多年，这是否意识这Tesla有所转变呢？最右边的TOP language中No. 1竟然是Ruby，看来脚本语言在全世界还是比较流行的。好在还有C++，C在撑场面，否则不知道Tesla在干什么。假如今天有Tesla的朋友在场，希望能够线下交流一下。那么问题来了，Tesla没有采用AutoSAR架构，而是采用了类似于苹果iOS系统一样自己开发，自己定义，这值得我们深思。
接下来我们就来聊一聊AutoSAR，猜测一下为什么Tesla采用Linux的原因。因为明天是AutoSAR中国日，而且这里有太多的AutoSAR专家，我就不班门弄斧了。从好处来讲，我理解AutoSAR的终极奥义就是：软硬解耦，软件标准化，硬件可替换。这个让我想到了中关村海龙大厦电脑城，也就是传统的攒电脑。只不过攒电脑时是选择CPU，主板、内存、显卡等等，而对于汽车来说，变成了ADAS模块、APA模块、车身控制模块、动力和底盘控制模块、BMS控制模块等等。那么对于主机厂来说，假如Tier1的零部件开发采用了AutoSAR软件架构，主机厂也采用相同的AutoSAR管理网络架构，那么主机厂就可以不用关心由哪个Tier1提供零部件和那些Tier1 关心的“难度最大的底层软件问题”。直接寻找性价比最好的Tier1，绕路超车，自己构建场景和开发上层功能，就ok了。所以说AUTOSAR的出现极大的解决了主机厂和供应商之间最大的苦恼。那么为什么Tesla没有采用AutoSAR呢？1. 雄厚的软件开发实力。硅谷三强+Amazon，其中苹果和谷歌还一直在造车的漩涡中。2. AllIn的掌控能力。Tesla希望能够把控ECU每一个环节的开发，其电池和BMS的开发就重充分说明了这一点。但是基于AUTOSAR开发的控制器的底层软件工作由供应商完成，供应商占据着绝对的主导权，主机厂想要整车OTA还需要通过供应商完成。3. 强大的可扩展能力。智能化代表着什么，代表着AI，代表着灵活多变，代表着常用常新。未来承载自动驾驶的是强大的计算平台和系统架构，在Tesla看来，应该有一个完全与之匹配的操作系统才能驾驭。我想这也是Tesla为什么开发自己操作系统的原因。回过头来看，这和我刚才讲过的国内外软件开发模式是不是又有点类似？作为新一代汽车人，我们有必要深刻思索中国应该怎么做，应该是什么样的开发模式。即使现在受条件所限，不能从编程语言、操作系统开始，那我们也应该意识到问题的根源所在。“师夷长技以制夷”，确定Adaptive AutoSAR能够承载到那个时间点，那个层级，深入其中，才是根本。
说到AutoSAR，还不得不提到另外一个组织。MISRA全称是 (The Motor Industry Software Reliability Association 汽车工业可靠性联合协会) ，成员包括了大部分的欧美汽车厂商。可能在座的很多人都没有听说过这个组织。但是他们和AutoSAR的关系越来越近了。最新的消息显示，MISRA C++和AUTOSAR C++的未来合并，两种领先的安全性至关重要的C++编码标准合并，对于采用AutoSAR的主机厂和供应商都是一大利好，至少在未来软件编码安全等级上有所保障。MISRA现在有四种guidelines，包括AutoCode、 SaftyAnalysis、C、C++。其中C、C++是严格的语言编码规范。我们拿MISRA C Coding Standard举个例子，这个标准包括了大概100多条C语言编码标准，目的是为了帮助汽车厂商开发出安全，高可靠性的嵌入式软件。有些编码标准让其他行业开发人员觉得不可思议，比如下面这几条：不得使用逗号运算符；不得使用三元操作符； 不得使用goto和continue语句；不能使用动态堆的内存分配，这排除了对函数alloc，malloc，realloc和free的使用，所以导致库string.h中的函数要谨慎使用。如果完全按照这个标准来书写代码，首先是代码可读性强，可靠，可移植性强和易于维护，其次是可以很容易的达到高功能安全等级。不过MISRA标准过于严苛，主机厂还是要根据实际情况执行。
说完AutoSAR，我们再聊一下SOA。这个面向于服务的分布式架构听起来是不是很难懂，但是说起来与之对应的架构C/S或者B/S架构，是不是大家就有一种恍然大悟的感觉。所以SOA在云端服务器的开发法和部署中是非常常用的架构。C/S最好理解，一个客户端（应用）对应一个服务器。B/S则是桌面即浏览器，浏览器可以做任何事情。服务器端分层，前端应用服务处理数据+应用接口，后端存储和分析数据。SOA就是B/S的再次扩展，将不同的服务部署于不同的服务器，也算是术业有专攻，中间层通过HTTP链接或者SOCKET的RPC调用，获取云端服务。生成XML或者json的标准数据，植入不同终端的不同工程中，完成程序的开发（这个图是我从网络中获取的，假如有侵权行为，请及时联系我）。好处就是服务功能的更新只需要更新部署在自己的服务器，而无需更新其他服务器的服务，甚至有些终端也不需要更新。我们回到车端，基于AutoSAR开发的中央智能安全网关基本上就是采用这种架构，将传统的网络信号组成一个个很小的服务，既保证底层传感器或者控制器的独立性，又能在上层基于不同的服务灵活的开发不同的场景。假如有这方面的专家，我们可以随时沟通，可以不断的修订和改正我们开发中的问题。但是个人觉得SOA的用途在未来的自动驾驶上。根据中国汽车学会的智能网联汽车技术路线图2.0解读得知，自动驾驶中对云和实时通信的要求，未来将一部分算力移到云端也是未来的方向。那么云端+一到两个计算平台，实现服务的双层或三层备份，即采用了SOA架构也可以实现功能安全，也是自动驾驶的行之有效的解决方案。
有了计算平台，AutoSAR，SOA架构，是否就可以搭建开发者平台了呢？目前我觉得还很难下定义。开放平台分为两种：一种是系统级开放平台：基于操作系统，释放上层API，开发个性化的软件。Google的基于Linux平台的开源手机操作系统就被认为最成功的开放平台，也造就了中国手机行业的虚假繁荣。目前国内只有Huawei的Harmony OS和阿里的AliOS。而后者的开放平台已经发布，不知道在座的工程师有多少人基于它开发过应用？假如有AliOS的工程师在场的话，我们也可以一起探讨一下。 另外一种是应用级开放平台：基于特定的技术，该技术被未来广泛应用、有着高数量等级的用户使用趋势，开放相应的函数接口，开发好用的功能。譬如百度apollo、腾讯微信小程序、科大讯飞语音，小米IoT等等，这有利于快速推进该项技术的发展和应用，个人觉得目前大有可为。那么问题来了，主机厂是该封闭，还是该开放？开放是采用系统级开发，前提是有自己核心的操作系统，还是应用级开放。这些都是每个主机厂内部不断探讨的话题，为什么？因为难度大。一个是开发模式冲突，另外一个是系统级复杂度高。
先说一下汽车的开发模式：A-SPICE。这个对于在座的传统汽车人非常熟悉，现在各大主机厂的软件开发流程基本上给都是按照A-SPICE来制定的。而Agile则是互联网常用的开发模式。如何将Agile嵌入到A-SPICE开发中？我觉得有以下几个前提：第一自主开发，面对智能化的需求千变万化，假如没有自主研发，供应商的合同都无法签订。要么就是增加天价的开发费，要么就是导致SOP delay，这个代价是主机厂无法承受之痛；第二是项目、产品、开发、测试、质量、路试人员都熟悉了解Agile，假如只有开发和测试，这里的测试指的是软件测试人员使用了敏捷开发模式，而质量和路试人员没有意识到的话，那么软件开发和测试人员面对的将是灾难，大家可以脑补一下场景互联网开发中产品经理和研发的相爱相杀；最后是OTA，好在有了OTA，让一切都有可能成为现实。但是要想实现OTA，整车开发流程的终点就不在是SOP了，而是汽车整个生命周期，这又反向推动软件需要自主开发。
接下来说一下下一个难点，那就是系统的复杂度。面向于计算平台的软件整体架构基本上就是这个样子。从底层看，脱离硬件后首先是虚拟化平台，为什么不直接是操作系统呢？既然是计算平台，就要支持不同的硬件，具备不同的安全等级，那么解决这些问题的主要方法，就是虚拟化。虚拟化之后，就是操作系统，除了多任务分时操作系统，POSIX系统，还需要有实时操作系统高要求，保证感知决策执行的实时性。然后是SOME/IP，DOIP，FOTA等通讯协议，然后是AutoSAR或者API，搭建标准的API或者RTE，对于主机厂会有很多的优势，保证后续开发延续性。大家会问为什么这么复杂，主要就是因为这是面向未来的自动驾驶。未来计算平台肯定会更加复杂，但是我们现在就要考虑。考虑座舱平台，驾驶平台，云平台的共同工作的能力。
除了系统复杂度，还有技术复杂度。根据智能网联汽车2.0的技术路线图，我们看到软件非常多，涉及到方方面面。我就不一一阐述了。但是这些技术的背后，是什么。是编程语言和操作系统。我希望我下一次再参加盖世汽车的论坛时，这里会出现中国设计的编程语言和操作系统。
虽然有困难，有复杂度，道路是曲折的，前途是光明的。目前多行业协作已经开始，下一步完成自主研发和合作开发，打造开发者平台，最后创建汽车自己的应用商城后，就是我们汽车人的胜利。