博世张人杰：Autosar在面向服务架构中的支持与应用

由盖世汽车、AUTOSAR组织、上海车展三方联合主办的SDVF2021第二届软件定义汽车高峰论坛暨AUTOSAR2021中国日于4月19-21日在上海举办，本次活动也是2021上海车展的同期活动之一，同时也是AUTOSAR组织在中国区唯一官方会议。本次会议邀请到了博世工程技术服务有限公司电子电气架构工程师张人杰先生在本次论坛进行了题为《Autosar在面向服务架构中的支持与应用》的主题演讲，以下是他在本次演讲的主要内容：

大家好，非常感谢盖世汽车和中国AUTOSAR给我们准备这样的交流平台，同时感谢AUTOSAR组织给我这个机会，在这里和大家分享一下AUTOSAR在面向服务架构里面的支持和应用。我今天分享的几点内容分别是未来出行的愿景，博世电子电气架构的开发流程，AUTOSAR是怎么针对面向服务架构的实现和支持。

大家都知道在新一轮全球科技革命和产业变革驱使下，互联化，定制化，自动化，电动化已经成为了汽车产业的一个趋势。在这四化里面因为政策和环境的影响，电动化已经成为了最先布局的方面，而随着车联网自动驾驶的融入，汽车的功能也变得越来越多样化，定制化的汽车功能也成为了衡量一个汽车品质的标准之一。总之，电动化成为未来出行的一个基本要求，由互联化，自动驾驶，定制化带来的智能出行成为了我们对于未来出行一个美好的期许。

随着四化逐渐的理解和落地，我们发现汽车产业需要更先进的架构，更强大的硬件和更丰富的软件来支持。当下汽车产业随着软件功能数量增加导致软件周期迭代的缓慢，成本上升，同时因为我们电子电气架构还是以分布式ECU为主，导致软件数量上升，硬件数量也逐渐上升，对于OEM来说硬件采购成本，包括对于供应商管控难度都在上升。另外网络安全也导向一个最终话题，就是汽车产业开发成本上升。

而随着新‘四化’带来的美好设想，汽车需要更强大的架构，硬件，软件的加持。但是回头再看传统汽车产业的设计开发流程。面临着汽车功能数量增多，功能更复杂导致功能开发周期过长，硬件数量激增导致电子电器架构复杂度急剧上升，汽车互联带来的更多信息安全和功能安全的考虑，对于各种资源的高效利用需求比如重量，通信负载，能量消耗的问题。另外面临着客户需要更好的用户体验，面临着跨域功能的多方协作的挑战。而所有的这一些都带来了一个核心问题汽车设计开发生产成本的上升，毕竟汽车作为一件商品，怎么样能够在兼顾四化的同时又能提供极具性价比的汽车成为了OEM的考虑的问题。而软件定义汽车，面向服务架构的提出就是为了能够解决以上的问题。面向服务架构，我们所说的SOA能够解决软件开发迭代周期过长的问题，同时也推动了架构从分布式ECU到基于高性能运算平台的域集中式的变革。而软件定义汽车更是强调了软件的重要性，也凸显了Autosar的必要性。

我们看一下博世对于软件定义汽车架构的理解，主要分为两端，一个是车端，一个是云端。车端包含在云端实现的汽车服务和平台的服务，博世IoT的服务。从车端可以看到，我们分成了两个部件：硬件和软件。再往上所有层级都是以软件为划分，所以凸现了软件的重要性。再往上一层是硬件虚拟化和硬件抽象层，这一层对于下层硬件进行抽象和虚拟化，是为了提供给操作系统对硬件的调用，同时也保证不同的操作系统可以共享同一个硬件。在支持的操作系统里面，大家熟悉的OSEK，当然也有性能更强的linux和安卓和QNX，再往上就是和AUTOSAR相关的，协议，中间件，底层软件，这一层就是AUTOSAR大放异彩的地方，为不同的供应商和OEM减少软件开发复杂度，提高了软件的通用性。再往上便是应用层和接口层，可以看到博世在软件定义层面将汽车分成几个层级。我们换一个维度来看，从电子电气化角度来看从分布式控制器到域集中控制器，它们又有怎样的能力呢。

博世的汽车电子和软件包括了汽车电子，动力，自动驾驶，驾驶辅助，车载多媒体，软件架构。车身电子中包含网关，中央控制器，域控制器，车身控制单元，DC/DC转换器。动力电子中包括VCU-plus，自动驾驶和驾驶辅助里又包括了各类传感器，Dasy，VMC等。在车载多媒体方面包括显示，娱乐等汽车电子。而在软件方面拥有早期基于CP开发的CUBAS底层软件，应用在ESC，ebooster，Radar等多个控制器上，现在又有基于AP开发同时兼容CP的VRTE（vehicleruntimeenvironment）。这一切都构成了博世汽车的跨域汽车电子软件。同时依赖于这些宝贵的产品和经验，我们的EEA设计更加丰富全面，跨域之间功能设计更加合理。

既然博世有这样的经验和技术，那在平常E/E里面怎么实现更好的布局和域之间接口的设计呢？博世的架构设计流程是MBSE（基于模型的系统工程设计）的设计方法，但是我们将EE架构开发抽象成3个部分，整车，系统，零部件，在L1中，我们将用户的需求基于场景进行用例分析，从而获得用户功能的模型包括了用户功能间的交互接口。此刻的用户功能则是一个黑盒模型，比如用户开启了TCS-OFF功能，而内部的逻辑需要再进行白盒化分析从而得到系统需求，TCS-OFF功能开启涉及到的内部逻辑。细分下来就是按键的功能需求，扭矩控制的功能需求等，再将这些功能放置到相应的域中，这里的变化就比较多了，比如实体按键，软开关，分属在不同的域（车身或者娱乐），再把对应的需求划拨到分配好的零部件中，我们就变成了零部件的需求，可以把这个零部件提供给OEM或者供应商进行系统开发。

这块就是我们博世对于整车电子电气架构开发方法，不管是面向功能架构，还是面向服务架构，这套开发方法都可以应对这些场景的。

其实未来的E/E架构主要分为两个方面，这张发展趋势图很明显，主要是硬件减少和功能上移，随着硬件减少和功能上移，但是其实软件并没有减少，反而会越来越多。

目前汽车行业E/E架构还是以分布式ECU，ECU分布式，CP就服务在ECU控制器上面，它能解决的问题就是实现了软硬件解耦，提供了统一的标准，提高了软件的高通用性。随着基于高性能预算平台的域集中式或者中央计算平台架构的出现，已经不仅仅是ECU这么简单了，上面一个运算平台上面可能会运行不同的操作系统和大量的应用软件，操作系统和应用软件之间是如何实现解耦的？就需要一个中间件的实现，如果不解耦的话，不同操作系统可能开发数十个应用来进行，实现解耦就需要中间件实现，中间件的出现一方面是对下层硬件资源进行抽象,利用，另一方面对上提供下层ECU服务的接口，包括诊断的服务，控制器，高性能运算平台的服务给上层提供软件的开发。

这也是SOA解决的比较核心的问题，就是说如何实现应用开发和E/E架构的解耦，减少软件工作量，减少网络接口配置的工作量。如果我们腾实现这些硬件层，中间层，应用层的解耦，同时它们不同组件中迭代的周期也会不一样，应用层软件迭代周期就会变得很快，可以丰富大家对于定制化的要求。这也伴随着一个问题的到来，我们发现各个层级之间分的很清楚，我们可以类比于CP，把硬件层和软件层做了区分，那CP就规定了硬件层和软件层有一个统一的标准，统一的接口。既然我们把这三个层级也进行了分层，中间件作为承上启下的部件那是不是需要一个标准来进行接口的规范化？那自适应AUTOSAR就随之而来了，自适应AUTOSAR给我们中间件提供了一个非常详细的标准，完善的规范来帮助我们来完成中间件的开发。

博世对于汽车计算机的架构也是分成三层，硬件层，应用层，中间层。那我们是怎么根据AUTOSAR进行中间层开发呢？我们把它分为三步：第一步是对中间件功能进行隔离，分成5层，分别是硬件抽象层，操作系统接口层，面向服务中间件层，ECU平台服务层，面向整车平台服务层。再往下我们根据已经成功分层的中间层的结构再去合理的根据AUTOSAR功能模块，包括功能集群的分布，将不同的功能集体方法到不同的层级中，这样的好处是，因为我们知道AUTOSAR版本是一直在改变的，打个比方之前这个版本S2S是作为单独服务，但是最近版本又把它集成进Communication management了，如果我们进行分层化和模块化开发的话就可以快速的针对AUTOSAR的改变，我们会把模块进行重新的集合和打包。我们再根据这样的软件的模块进行具体的设计和开发，这样就得到了我们的产品VRTE。它提供的是一个面向自适应AUTOSAR的中间件，同时也支持经典AUTOSAR。它支持多种操作系统，另外也支持加密第三方软件的集成和多功能域的集成。同时博世中间件软件不仅是一套软件的模块，它更是集成了开发套件，能够支持上层应用的开发。

可以看到博世软件层级是这么八层，中间五层主要是中间层。第一层硬件抽象层，它做得是跟CP一样的工作，是把硬件设备接口进行统一化处理，内部实现方式大家都不一样，但是接口标准是一样的。第二层是操作系统接口层,包括各种通信的协议栈。第三层是面向服务的通信中间件，比如communicationmanagement。第四层是ECU平台服务，就是原子级的服务，它对下层ECU提供的服务提取出来，然后作为ECU平台服务供给上面整车层开发，整车层集合各个原子服务集，基于服务集我们进行上层更高级应用的开发。同时还提供保护域的功能，比如说基础设施保护方面，我们通过安全域的划分和进程的管理来实现保护操作系统和软件的安全。另外在共享通信方面也通过比如流量检测等功能来保护安全。

在应用层保护方面讲一下功能安全，其实功能安全主要分析还是看各个功能安全目标，如果这个应用功能安全等级非常明确之后，那我们就把它运行在域控制器上面。这块就是软件中间层包含的功能和内容。

既然说到中间层已经可以根据Adaptiveautosar进行开发，而中间件是实现SOA面向服务开发的一个必要的组件，它的目的也是为了减少软件的耦合度，更新软件的开发周期。那么应用层进行开发的时候是怎么样实现相互独立开发，开发流程包括什么，又是怎么利用中间件的接口进行配置和开发的？

首先，基于目标硬件操作系统的选择QNX,Linux,androidy，我们也选择对应的开发工具Momentics还是eclipse还是adaptivestudio等之后在项目包里面主要分成三个部分，首先是应用设计，主要做得是应用接口的设计，包含三个部分：端口的定义，对于下层中间件平台服务调用的定义，数据传输时候对数据类型的定义。静态代码其实就是逻辑代码，Configuration就是修改通讯实例。我们通过生成技术生成应用，应用包括两种类型的文件，一个是C++，因为AUTOSAR要求C++作为唯一代码语言。应用设计也生成了Proxy和Skeleton代码，剩下这些API和网络，路由就是通过Application配置。

在具体编译的时候，不管即将运行在的操作系统类型是什么，整个配置是一致的，但是在编译的时候会根据系统运行的目标操作系统，可以针对性使用它的编译器。如果运行在QNX就用qcc，如果是linux可能就用gcc编译器，这样就得到了整个APP的应用。整个APP应用包括可执行文件和中间层配置文件。

其实这一套就实现了应用层软件和中间件开发的分离，因为有AUTOSAR统一接口和标准，那我们之前的配置，里面的内容都是一样的，不管是什么操作系统只要对编译进行选项的调整就可以得到一个应用程序。

随着面向服务架构和中间件的出现也改变了以往的商业模式（合作方式），第一种是博世一整套都由我们来提供。慢慢的演变成我们提供硬件或者中间件，你们可以通过中间件统一端口接口，第三方OEM或者第三方供应商进行应用开发。当然也可以只由博世提供中间件，硬件和应用都由第三方来开发，当然也可以基于博世的中间件进行二次开发，基于二次开发的中间件，大家无论是使用第三方硬件也好，博世硬件也好，进行应用的开发。可以说中间件成为了解决SOA面向服务架构的一个关键点。