软件定义汽车-AUTOSAR解决方案

引言

接下来我们看到2002年奔驰的e-class基于 络电控系统车型，这个车型跟传统汽车上的电子电气架构有联系。在这个架构上面，不是一个功能，而是有很多功能都是用电控去实现，软件已经在每一个控制器上发挥了很重要的作用，去实现每个控制器上的特定功能。

我认为这是软件汽车的发展，从最初实现单个功能，到实现汽车上普遍的很多的控制功能。

我们看到最新的，可能很多朋友认为软件定义汽车重要的标志，或者说我们认为所谓软件定义汽车应该是这样的，它就是2016年的Waymo，源于谷歌无人驾驶项目，可能更早就已经开始了，但是2016年可以作为标记，Waymo的成立，无人驾驶汽车采用人工智能的技术，去实现汽车的感知决策和控制，完全和以前的电控技术、软件技术是不同的。

关于“软件定义汽车”的定义，我前几天在百度上面看了一下，当然用百度查出来，是百度最先提出来的软件定义汽车，不是由于机械的原因或者是功能上决定一个汽车的状态，而是由于软件定义汽车的状态，特别是人工智能的、AI的软件，这才是软件定义汽车源于百度的解释。

这是有不同的解释和不同的阶段，我认为这都没有关系，软件定义汽车是一个过程，未来是什么样，可能没人知道。我试着做一些预测，或者说我看到一些可能发展的未来，我下面会继续讲。

第二页我还是说一下过去，有一点点未来，但是大部分都是过去。

我们再回过头来看技术，从技术看到商业，再看一下技术。这张图已经有朋友用过，这张图是麦肯锡的调研 告，它归纳了很多其他方面的研究，综合这些方面，不是自己提出来的，但是我觉得综合的还是蛮好的。

汽车电子电气架构

汽车电子电气架构方面，功能在汽车上的分布，归根到底是这样的定义，在整个历史上面是分成五个阶段，目前可能处在第三个阶段。从大的概念来讲，到目前为止，我们看到很多车辆都是以分布式的电子电气架构为主，所谓分布式就是没有中心的，一辆车上没有中心的，每个功能有每个功能的电控系统，这些电控系统形成一个 络，这个 络是CAN总线的 络，上面会有很多 文传递，这样的结构。

第一阶段、第二阶段、第三阶段无非是这个 络会越来越复杂，综合来说还是一个分布式的结构，会从单个系统变成一些子系统，这些子系统之间的连接，会越来越多，会有一些交叉性的功能互联，这是目前电子电气架构的状态。

再往下整车会有一个中心的结构，这个结构是计算平台，智能驾驶的大脑，现在还不能确定，有很多方案会往这上面去设计，但是我们知道很可能的一个架构特征就是域会融合，不是截然分开不同的域，而是说每一个域和每一个域之间功能会互相融合，这种结构上，很多资源可以共享，比如传感器，很多控制器可能会共用一个前端的传感器，传感器会把数据先做域处理，处理之后后面控制器里拿到处理过的数据，然后去做功能。

另外一方面，过去讲的域控制器，相互之间可以做融合。第二个是功能可以互为共享，或者说互为冗余等等，这些方面的新设计都可以基于这样的架构出来，我们现在可能看不到新的设计，因为我们的架构限制了我们的眼光，这个架构变化之后，很多新的设计，很多新的思路可以根据这个架构生发出来。这是电子电气架构的发展趋势。软件定义汽车可以在新的架构里面生发出新的思想，有新的功能出来。

自动驾驶的分级

我们再看另外一个维度，这个表大家比较熟悉，我们的历史还可以这样来讲，用自动驾驶的分级讲历史。在这个过程中，完全人工驾驶的汽车是L0级的，汽车完全听从人类驾驶者的指令去工作。在这个之后L1级，就是所谓的辅助驾驶，辅助驾驶就是对加减速以及转向其中一项来提供车辆的辅助，驾驶员来负责区域的驾驶动作，这是辅助驾驶概念，比如说我在行驶的时候，可以跟随前面的车辆，自动巡航的功能，在道路上跟随前面的车辆，当你在高速公路上的时候，可以大大减缓驾驶的辛苦。这是L1级的辅助驾驶。

软件定义汽车的挑战

这是我对汽车上软件定义汽车方面的想法。它会带来一些挑战，有三个方面的挑战，第一个是架构设计的挑战，我刚才讲到的软件的架构，如果要做成高内聚、低耦合以及可以快速的有效率的开发，这是一个新的架构挑战。第二个功能安全的挑战，本来我这个题目就是讲功能安全的，我可能会讲一点，但是我会把功能安全大部分留在后面另外一个话题去说。功能安全挑战是什么我们说软件是可以不断迭代升级优化甚至个性化的时候，软件的验证如何来做，我们在生产之前必须要做验证，必须要确保可靠性，这对传统的功能安全概念会是一种挑战，新的挑战。

功能安全的挑战会是什么样的边这张图是功能安全的标准，就是主流标准IOS 26262，在功能安全里常常听到功能安全等级，右边是方法，我们会把一个系统从三个角度去看，比如要做一个发动机的控制系统，我们看发动机控制系统一旦发生故障严重度是什么，最左边这一类就是第一个维度，严重会导致轻度或者中度的伤害，还会危及生命，还是会造成必然的致命的伤害，发动机控制系统在严重等级上处于哪个位置。

我们还要对加密解密算法，做一些轻量级以及高效的优化，使它适用于车内的环境。除了具体技术之外，我们需要一个信息安全体系。跟功能安全相比，信息安全体系可能还比较滞后，对功能安全来说，我们很清楚的流程标准ISO26262已经定义了，我们首先要做危险危害分析和风险评估，对这个系统，我们要去设计这个系统的功能安全技术概念，如果是一个系统需求，如果是一个软件，就是软件需求规格。

我们要做系统设计，以及硬件和软件的设计和开发实现，最后做验证和确认，这些步骤是一个方法论，有很多具体的要求、手段在这个方面来实施，这是功能安全方面比较成熟的流程。在信息安全方面还没有这样的标准化流程，目前还没有公认的标准化流程出来，这是需要我们根据车辆的发展和信息安全的要求，再去设计和建立起来的体系。

整体安全就只有功能安全和信息安全都完善的情况下，才是真正的安全。

AUTOSAR解决方案

下面我介绍一下AUTOSAR的解决方案，前面讲了一部分AUTOSAR怎么提供低耦合、高内聚的架构。AUTOSAR结构，目前来说AUTOSAR组织在汽车里面得到普遍应用的主流的结构。在这个结构里面，是一个模块化的，我们看到不同的颜色，从下面开始，硬件上面会有一层驱动以及IO驱动，隔离软件和硬件的差异性。

这三个软件组件通信都是通过AUTOSAR进行的，组件之间的数据通信是通过抽象程度非常高的接口，这个接口对一个软件组件来说，需要往总线上发数据的时候，只是发送一条消息。至于说总线到底是在一条总线还是在其他的以太 总线上，对应用软件是不关心的。至于这三个组件，我们是在同一个ECU上，还是在不同的ECU上，对于软件组件的开发者也是不关心的。

大家或许会觉得奇怪，为什么一个算法执行器和传感器在不同ECU上，将来设计的时候，按照AUTOSAR方法论，可以共享的。如果有两个ECU，或者三个ECU，用同一种方法拿数据，只需要有一个设计出来就可以了。

RTE软件总线实现的功能，一方面是隔离了应用软件和基础软件，另一方面是隔离了底层RTE以及互相连接的逻辑拓扑。对于上层的组件来说，只要发送和接收数据就可以，至于数据在哪个ECU上面，以及通过哪条总线弄的，取决于RTE的配置。对AUTOSAR的思想来说，软件+配置才是最终软件的实现。

基础软件会有配置文件，RTE也会有配置文件，配置文件里描述了哪个ECU上面有哪个软件组件，哪个ECU用什么的组件。修改软件布局的时候需要修改的基本上就是配置部分，方法论对于未来软件开发工程化和实现的低耦合，复用，以及软件模块的跨平台思想设计，这是AUTOSAR解决方法。

AUTOSAR具体来说功能有哪些，这是普华产品，但是对所有的AUTOSAR供应商来说，都是一样的，因为标准制定是同样的情况。我们有操作系统，这是一个核心的部分，有诊断，有标定，有 络管理，有通信，存储管理，底层驱动，有复杂驱动，大致有这么多模块。除了RTE，RTE是非常重要的部分，但是功能已经描述清楚了。操作系统这些大家都知道了，不细讲，因为AUTOSAR操作系统都是需要有精简、性能强特点，功能隔离保护，内存保护，都在标准里面有定义。要讲的就是说有一个非常重要的特点，我这里没有写进去，实际上是非常重要的，终端响应和任务切换快，这是不准确的，对于实时系统来说，当然要性能高，这是必然的，要快，这是必然的。更重要的要求是确定性，多任务的系统里面，A任务如果是定义的10毫秒的周期，必然在任何情况下都是10毫秒的周期能完成，不可以说在某一种负载情况下面，某一种比较困难的情况下面，或者某种异常的情况下，达不到时间周期，10毫秒并不是很短的周期，但是我定义10毫秒就是切实的10毫秒。发生中断的时候，发生任务调度的时候，不可以有预料不到的东西，确定性是比性能更重要的特征，任何情况下，性能是不能低于时间的，这是操作系统的要求。

诊断协议栈包括UDS、J1939，这是行业里一直在用的，我们可以灵活的配置诊断协议，可以配置传输层的时间参数，可以用诊断规范，把诊断规范对应到配置上面去，可以实现多帧传输。标红部分就是跟诊断协议相关的部分。

络管理跟整车级的能耗， 络的状态都是有非常密切的关系， 络管理是具备了静态配置，动态监控的功能，我们可以支持两种标准，一种是AUTOSAR，也可以支持NM 2.5.3。很多情况下整车厂有自己的规范，可以根据整车厂自己的规范配置到相应的区域里面去。还有存储管理模块，可以支持flash存储介质等方面的内容。

MCAL驱动在AUTOSAR处在最底层的基础软件，也是基础软件一部分，提供的主要是屏蔽芯片上面的差异，向上提供标准的微控制器驱动接口。通过MCAL基础软件和芯片的适配性非常强。

我介绍一下普华，普华现在跟其他国外的AUTOSAR供应商是一样的模式，基本上在MCAL方面会跟芯片原厂合作，由芯片厂提供标准MCAL软件我们做集成，由于提供标准接口之后，这个集成工作会非常高效，包括MCAL和基础软件的集成，包括和底层的芯片在运行上的问题技术支持，这些方面都会有。

操作系统如何实现功能安全，操作系统是采用功能安全的机制去实现功能安全。功能安全机制起什么作用这里只是一个引导或者开端，我们在6月16 举办功能安全日，我会介绍功能安全实际的工作流程，对操作系统实现功能安全来说，方法论是很类似的，可以作为软件功能安全的借鉴。

功能安全会有很多相关安全模块，大部分的模块都会有功能安全要求，不仅仅标出来的模块，真正实现的时候，需要跟应用，由应用选择哪些模块会在具体场景上使用，我们在这些场景上面去实现功能安全。这是功能安全选模块时候的必要条件，当然有两者，OS是必须要选择的，如果说我前面已经讲过，OS没有达到功能安全，在其他的模块实现功能安全是远远不够的，这里面很重要的公共安全密切相关的模块。

第二个信息安全的方法是SecOC，这个安全机制为PDU做的，前面是为信 做的。对PDU来说，我们在发送的时候，需要对PDU实现认证机制，PDU的数据，会增加SecOC的模块，进行加密和解密，然后做通信，数据就是加密过的数据了。

最后花一点点时间介绍一下普华，普华软件是中国电子科技集团的下属企业， 2008年注册成立，2009年开始正式运营，到现在差不多12年的时间，公司员工有600多人，普华作为国家的基础软件战略平台，通过国家的支持以及跟车厂的合作，产生了产品，并且这个产品是不断的通过业务创新，通过市场推进，目前在国内汽车电子AUTOSAR市场上，还是普遍得到了应用。

普华汽车电子事业部是我们公司核心业务部门，我们负责汽车电子AUTOSAR产品的开发，以及产品销售和技术服务。公司的总部在上海，汽车电子事业部在上海、西安、成都，三个地方，这是我们国内的布局。

普华是2010年加入AUTOSAR组织，2018年成为中国软件企业里面唯一一家高级合作伙伴，AUTOSAR高级合作伙伴世界上应该有58家，是有变化的，会多一点，少一点，每年都会有变化。中国企业在高级合作伙伴里面，有4家，普华是唯一一家作为软件AUTOSAR供应商的，我们作为标准软件的供应商，其他的中国企业还有长城、华为、百度，就四家在高级合作伙伴里，高级合作伙伴做什么事情简单介绍一下AUTOSAR组织架构，合作伙伴的分类。

AUTOSAR是一个汽车开放系统组织，标准是开放，大家都可以拿技术标准来开发产品，如果说你是商业化用AUTOSAR开发产品，用标准开发产品，需要成为合作伙伴才可以，至少有一个灰色的部分，就是关联合作伙伴，加入关联合作伙伴就可以合法用标准开发软件，就可以用它的体系架构。

在AUTOSAR组织里面参与标准制定工作，普华一直做AUTOSAR，我们必须要做参与的工作，比如做新版本开发的时候，最近在R20-11版本，今年下半年要发布的版本里面的模块，会跟所有高级合作伙伴讨论这个模块标准的设计以及做一些概念性的开发，这些工作都是在高级合作伙伴里面做的，付出会比较多一点，因为我们做这个业务的，我们也必须去做这些工作，在这些做AUTOSAR组织安排的工作。

我们在这个月，差不多一个星期前，我们获得了德国莱茵TUV功能安全产品认证，普华灵智ORIENTAIS操作系统是国内第一个通过功能安全产品认证达到最高安全等级ASIL D的AUTOSAR操作系统，这是认证证书。我们会在6月16 ，12天以后会办一个活动，叫功能安全技术日，在国内大家推动倡议软件的功能安全怎么做更好，我们也会分享，我会把功能安全普华实战的过程，在那个活动上跟大家做分享，希望大家可以关注这个活动。

我们的合作伙伴，有国际主流的芯片厂商，有AUTOSAR组织，有国内整车厂，都是我们的合作伙伴。