由盖世汽车、AUTOSAR组织、上海车展三方联合主办的SDVF2021第二届软件定义汽车高峰论坛暨AUTOSAR2021中国日于4月19-21日在上海举办，本次活动也是2021上海车展的同期活动之一，同时也是AUTOSAR组织在中国区唯一官方会议。本次会议邀请到了东风汽车公司技术中心主任工程师樊昀女士在本次论坛进行了题为《AUTOSAR在东风的应用及发展》的主题演讲，以下是她在本次演讲的主要内容：
非常荣幸今天能被邀请过来跟大家分享AUTOSAR在东风的应用与发展。我今天想给大家分享的内容包括东风引入AUTOSAR的背景，AUTOSAR在东风的发展演进，AUTOSAR在东风所开发的项目，还有我们的建议与体验。
AUTOSAR在东风引入背景，普华的刘总讲到当时采用AUTOSAR的原因，我觉得讲的非常好。我们当时引入AUTOSAR也是因为汽车软件面临着大量电子化，MCU数量激增，整车厂需要维护多个MCU开发。采用传统的开发模式就面临着很多的弊端，为了解决这些问题，我们的总师高瞻远瞩，引入了AUTOSAR。因为AUTOSAR有统一的接口，我们可以采用配置的方式，它的基础软件都是商业化的代码，安全性和可靠性都是非常高。
这个是AUTOSAR在东风的发展演进，东风做AUTOSAR开发差不多有十年了，2010年的时候我们组织了团队对AUTOSAR进行了预研。2015年第一代发动机控制系统就是基于AUTOSAR开发的，同年我们购买了AUTOSAR平台。2018年的时候第一代发动机控制系统EMS实现了量产，同时匹配了多款车型，第一代网关项目也实现了量产。目前为止，基于AUTOSAR开发的项目包括多款域控制器和自动驾驶项目，以及第二代中央网关的项目。
因为我是做AUTOSAR基础软件的开发，大约做了有八年左右时间，所以今天给大家讲的更多是技术的分享。我们当时在做AUTOSAR之初采用的方式跟现在大家很多公司采用的方式一样，拿到配置工具之后先导入DBC文件做通讯协议栈开发，再添加其他模块，再做上层SWC开发，最后得到系统描述文件，导出ECU extract，最后进行集成编译。当然我们涉及到AUTOSAR模块有：系统服务、安全的、内存管理、诊断等各个方面。最初开始采用这种方式在项目开发过程中就发现了很多的弊端，于是在我们项目开发中对我们工具链进行逐渐完善。
这个图是东风在目前为止采用的标准化AUTOSAR开发流程，从需求、架构、基础软件、应用软件、集成都有完善的工具链。可能很多在应用或者即将应用AUTOSAR都会面临这样一个问题。我们的需求及架构工具用的是systemweaver，开发工程师可以在里面创建所需要的SWC接口，当然我们现在还在里面维护了数据类型库，我们知道在AUTOSAR开发过程中数据类型是一个比较复杂的东西，虽然写代码的时候觉得数据类型很简单，但是在AUTOSAR里面数据类型涉及到三种，包括application datatype，implementation datatype，base type，每个对应关系都需要把它定义的很清楚。SWC工程师在里面创建接口，因为可以引用里面的数据类型库，创建完之后可以导出XML的文件，这个xml文件包含了他所需要的输入输出接口，这个文件可以通过我们的工具导到Matlab里面做下一步的策略逻辑的开发。
当应用软件和基础软件开发完之后，开发完之后我们有一个集成工具叫Jenkins，这个工具是开源的，为什么我们采用这个工具呢？我们都知道AUTOSAR贵，我们不可能让每一个工程师都有一个账号电脑上，应用工程师在做集成的时候怎么办呢？我们就有了这个工具，它是基于web页面，调用批处理文件实现代码集成编译。如果要想集成一版软件，比如说项目经理，他要求在某一个节点之前集成符合某个需求的一版软件，他就会通过我们另外一个工具发给大家CR，在这个时间节点之前我们就会把对应的版本上传到版本管理工具，到集成软件的时候，项目经理就会去请求版本工具里面所对应的版本下载到服务器上。这个服务器性能非常强大，因为它要做得工作就是将工程下载到本地之后需要调用matlab接口生成SWC对应的代码以及对应的arxml文件。目的就是为了屏蔽应用工程师复杂的工作，因为他需要在里面不但创建接口，还要知道采用触发方式是什么样的。采用了我们的工具之后，他不需要关心这些内容，他所需要关心的就只是它的策略。我刚才所说的AUTOSAR定义的内容，全部给它做了一个封装，生成代码的时候同时生成符合AUTOSAR的文件。
在2020年东风基于战略需求更换了AUTOSAR平台，其实对于我们来说也是一个很大的挑战。因为我们知道每家工具是不一样的，你想把现有流程匹配到新的工具上面还是需要做很多的工作。但是我们的专家做了一个Python框架，在这个框架下面更改AUTOSAR描述文件，让它匹配新的平台工具。也就是说，在现有架构不变情况下只是更换一下脚本做自动的匹配，这个工作已经完成了，已经应用到新的项目之中了。
这里给大家分享的，大家现在也许正在遇到的或者即将遇到的问题。这里面有一个非常好的技术在这个地方。东风在做中央网关开发的时候，我们知道网关主要是进行信号路由或者报文路由，不管是采用哪家工具，我们把DBC导进去之后自动配置全是信号路由。那么，对于报文路由的需求，传统的方式来做这个工作，就需要在COM中将报文和信号删除，然后在PDUR中将src和dest进行更改，这种方式弊端是每次都要进行几百个信号的删除以及上百个PDUR的数据操作，但是每一次需求的变更，我们都需要重新导入DBC，那以前的工作可能就要推倒重来。当时为了解决这个问题，我们写了一个脚本，也就是说，我们可以通过配置文件，只需要维护一个配置文件，运行一下我们的脚本，全部帮你你配置好，不需要人工再做配置。
第一模块是BswM模块，它的逻辑很简单，但是配置起来很麻烦，因为涉及到很多条，每一条都需要进行配置。因为在网关开发过程中有一个需求，网关需要最大覆盖化，所有车型只发布一版软件，通过改配置实现不同车上报文路由的转发，我们就需要通过这个模块进行管理。
这个地方有一个截图，把每一条加起来，如果是手动配置大概有1000条左右，每一次需求变更全部都要推倒重来。我们后来就用了自动化脚本实现这部分内容，当然实现的还有网关集成诊断的功能。现在验证结束以后后面再有新的开发都是一键生成。
我还想说的是在做诊断开发过程中很多厂家说，我是可以导入CDD文件，支持导入ODX文件，实际上东风也没有导入CDD文件也没有导入ODX文件，我们之前做法是做维护，通过自动化脚本直接实现自动化配置。现在我们换了工具还是可以通过一个列表把DTC定义好，所需要的参数都定义好之后运行一个自动化脚本，它就可以完全实现自动化配置。我为什么要提这个？这个在我们迭代开发过程中是很能提高我们工作效率的。因为从一个需求到一个软件版本的发布要求时间只有两周左右。
我再说一下软件集成流程。采用一整套流程方法，这个流程从架构设计，接口设计，BSW开发，当然也包括CDD复杂驱动模块的开发，可能那部分占的时间比较久，因为你要写底层芯片的驱动，到接口Mapping，我们的Mapping工作也是属于半自动化的，因为我们在做SWC开发的时候要求上层之间的输入和输出接口名字一致，这样就可以通过脚本实现自动化的匹配。底层和上层接口可以不一样，我们也是通过一个表做一个人工的核查，导出一个表实现自动化的配置，最后到RTE的自动化配置与生成，最终实现软件的集成编译。
这个地方是开发我们第二代发动机控制系统的时候，因为我们第一代发动机控制系统由于整个工具链还不是很熟悉，当时对AUTOSAR了解不是很深入，花了很长时间。但是我们在做第二代发动机EMS控制系统以及其他控制器开发过程中，我们开发的速度就明显比以前快很多。为什么？我们有300多个模块库，涉及到各个领域的，扭矩的，燃烧的，通用模块库等，那些通用模块库基本上都适用于各个模块的开发。我们把模块库把所需要的模块提取出来，然后做BSW开发，BSW诊断部分除了新增的，其他的基本上是沿用以及自动化配置，不需要人工做处理。IO抽象模块这块代码和接口也是实现了自动化生成，包括.c文件，因为对于有些项目来说，这个接口有几百个，我们现在正在开发的中央控制系统确实它的接口就有几百个，如果人为做这项工作的话，你要花很长的时间，而且不能保证人工出错的概率，这块我们也是通过自动化脚本来做的。
这是我们采用AUTOSAR架构所进行开发的项目。第二代发动机控制系统匹配的是2020年获得十佳发动机的C15TDR发动机。我们同时匹配这个发动机还有VECU的项目，搭载到HEV车型上面，今年已经实现了量产。第二个是域控制器，中央安全网关的开发已经实现PT装车，预计2021年量产，同步匹配多款车型。我们还有域控制器，CCU域控制器开发，自动驾驶项目等目前也在开发阶段。
这是东风从2015年以来基于AUTOSAR开发的控制器。第一代发动机EMS，当时匹配了好多个车型，网关项目，ADAS项目，第二代EMS，这是东风采用AUTOSAR架构开发的。我们刚开始采用AUTOSAR的时候开发一个ECU可能要花很长时间，但是在我们工具链整个流程建立起来之后，开发一个产品时间是很短的，相对于以前传统的方式，开发周期很短，而且可靠性比较高。
这么多年来，AUTOSAR给东风到底带来了什么好处？1、高质量。以前我们采用手写代码的方式，是几个工程师在战斗。现在我们采用平台，BSW代码都是供应商提供的，我们相当于后面还有一个团队陪着我们在战斗。2、低成本。大家都说采用AUTOSAR平台好贵，但是从长远来看是值得的，因为你不用花很多人力和时间成本去找BUG。3、短周期。在开发过程中，可以看到你的体系流程建立起来之后开发一款产品，它的时间可以大大的缩短。
我们东风在AP AUTOSAR上面做了一些预研工作，希望下次再开这个会议的时候，能有东风工程师讲一下AP AUTOSAR在东风发展的情况。
最后跟大家分享一下收集的工程师的一些建议以及这么多年来我们去做AUTOSAR心得体会。说起体会来还是挺复杂的，做了这么多年AUTOSAR，还是有很多感触的。
在这里我想用王国维的读书三境界形容一下，我们在使用AUTOSAR过程当中的三个境界。第一个境界是：昨夜西风凋碧树，独上高楼，望尽天涯路。刚开始是拿着AUTOSAR标准几个人在翻译，一句话一句话翻译，翻译完之后，我不知道它在讲的是什么，不知所云。第二个境界是：衣带渐宽终不悔，为伊消得人憔悴。我们在真正做项目开发的时候看它的代码，再同步去看标准，再去看代码看配置背后所蕴含的含义，从工程中去了解标准的含义。第三个境界：众里寻他千百度，蓦然回首，那人却在灯火阑珊处。当一个项目一个一个项目做下来，做了几个项目之后再去看标准，你就会豁然开朗，你才知道原来那些参数是什么意思，那个时候你再看的时候就会觉得AUTOSAR确实很好用。
路漫漫其修远兮，当然东风也面临很多的挑战，但是我们东风依旧会不忘初心，上下求索。同时也希望AUTOSAR能够发展的越来越好，让每一个使用AUTOSAR的人能够体会到它的美，谢谢大家。
下面是东风汽车在本次大会中的精彩瞬间：
