从Autosar+MBD+功能安全的角度谈谈汽车电子开发.docVIP

从（Autosar+MBD+功能安全）的角度谈谈汽车电子开发 01 智能汽车的多域融合趋势 近几年，随着汽车行业的快速发展，尤其是国内一波补贴过后，多多少少留下一些扎扎实实造车的企业，他们将一些国外先进的技术带入到汽车产品开发中，这些技术慢慢在汽车行业（包括乘用车和商用车）得到普及，本文主要从三个技术角度（即Autosar、MBD、功能安全）来聊聊成为标配的汽车电子技术。 针对每项技术，主要分两步来阐述： 第一步说明这个技术的作用； 第二步说明这个技术如何用到产品上。 02 Autosar 2.1 作用 Autosar是一批顶尖的主机厂和零部件厂制定出来的一套汽车电子软件开发方法。软件在汽车电子产品中占据的比例越来越高，汽车又是对软件质量要求极其严格。那么Autosar给我们带来了什么？ a、它提供了需求，在Autosar的需求文档中，它给我们收集了汽车行业很多的需求，给我们打开了一扇汽车行业的窗口。 b、它提供了一套架构，它给我们展示了分层、分模块的矩阵式架构，定义了各个标准模块以及其中的接口，统一了汽车行业基本功能模块的交互和定义。 c、它提供了一套开发方法，Autosar要求按照V模型进行正向开发。 d、它降低了开发难度，提高了软件质量，Autosar源码的开发一般交给专门的组织来开发，并且代码和工具经过第三方认证，而应用autosar的人只需利用Autosar工具链配置生成开发代码即可。 e、说一点它的弊端吧，目前工具链偏贵，并且工具链目前的自动化程度不够高，尤其是集成效率不够高。随着越来越多巨头（百度、华为等）加入后，相信这些问题会逐步解决。 2.2 应用 主要以开发ECU角度来说明，这里不以整车开发角度。 工具链：主流有Vector、ETAS、EB，这里以Vector和ETAS工具链为例说明。Vector ?Developer用于应用层架构设计，Vector Configurator 用于BSW+RTE配置; ETAS ISOLAR系列（RTA-RTE RTA-OS）全套开发融合；MCAL目前主要还是使用EB的 Tresos工具。好用度或自动化程度上，VectorETAS，价格反之。由于Vector系列占主流，因此以Vector工具链作主要说明，而关键点时也会提到ETAS（只是作为一个用户体验角度说明，不带任何广告以及倾向，若涉及相关利益请通知删除）。 以下以开发一个ECU为例说明： 客户输入：CAN矩阵（DBC文件），诊断表（CDD文件或ODX文件）以及客户需求表（SOR文件等）。 autosar部署： 假如选型芯片为英飞凌 Tcxx系列 ，目前比较主流。 第一步根据HSI，在EB Tresos中配置好MCAL，配置好后可以导出Arxml，方便下一步集成到Vector或ETAS工具。 第二步将MCAL集成到Autosar工程中，这一步的目的就是将OS依赖芯片相关的内容（计数器、时间等）集成进来，当然也包含一些其他的依赖MCAL的内容，如CAN驱动、Eeprom/模拟Eeprom、Spi、看门狗等，这些建议在EB工具下配置，自动化程度会好一些（不管是ETAS还是Vector兼容第三方工具都不是特别好）。 第三步将BSW所需的模块加入到Autosar工程，如BswM、EcuM、WdgM、NvM、Dem、Dcm、Com等所需的的模块加入都工程。 第四步将DBC文件和CDD文件导入Autosar工程（这一步Vector和ETAS最新工具链都是支持的），这一步会将Com协议栈的大部分配置项和Dcm、Dem的大部分配置项生成，可是Vector和ETAS在这里都没有做到完美，很多配置项都需要手动调整。 第五步调整COM协议栈以及UDS协议栈配置项，配置NvM/MemIf/FEE/Fls、配置WdgM/WdgIf/Wdg、配置Xcp等。 第六步配置ECUC、OS，RTE，ECUC主要涉及到分区，以及Core Hardware定义等，OS主要涉及Task、Counter、Application等配置，方便后续Mapping，这里说明一下ETAS中OS的管理用的另外一个工具RTA-OS，其一致性做的不够好。 第七步配置应用层SWC，当然这一步也可以在第一步开始的时候执行，主要配置应用层的组件、接口、函数等。 第八步连线+Mapping，这里主要是将需要调度的Mapping到Task或中断（中断手动放入入口函数），还有就是PRPort口之间的连线（包括SWC与SWC，SWC与BSW组件）。 至此，Autosar工程基本部署完成，后续只需将MCAL+BSW+RTE+ASW的代码集成到一起即可，说实话，这里的集成过程目前由于工具链的问题，效率自动化程度都不高，尤其是ETAS需要写很多脚本支持。 当然，这里还有两个概念提及一下，IO抽象以及