01智能汽车的多域融合趋势近几年，随着汽车行业的快速发展，尤其是国内一波补贴过后，多多少少留下一些扎扎实实造车的企业，他们将一些国外先进的技术带入到汽车产品开发中，这些技术慢慢在汽车行业（包括乘用车和商用车）得到普及，本文主要从三个技术角度（即Autosar、MBD、功能安全）来聊聊成为标配的汽车电子技术。 针对每项技术，主要分两步来阐述： 第一步说明这个技术的作用； 第二步说明这个技术如何用到产品上。 02Autosar2.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工具。好用度或自动化程度上，Vector>ETAS，价格反之。由于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抽象以及CDD，本质上他们就是SWC。 此外ASW配置完后，其实就是一个代码框架，或者就是这个ASW的架构信息，可以导出Arxml文件，供后续进行MBD开发。 03MBDMBD即基于模型开发，目前了解在航空以及风电行业占主流，后续再汽车行业应该也是主流。 3.1 作用 随着Matlab Simulink近几年代码生成水平的提高，代码的执行效率与人员编码水平相比基本相差不大（高手除外，汽车行业软件高手没有遍地都是），同时MBD开发带来了很多好处： a、开发难度降低，类似是图形化的编程方式，使开发更直观，使开发难度降低（我还真见过不会写C代码的汽车行业嵌入式软件工程师）； b、方便仿真，搭完模型后，即可仿真功能是否符合预期； c、方便测试，直接用Harness，测试模型直接生成，同时提供了很多静态测试，只需一键检查，一键生成报告，因此单元测试和静态测试都是十分方便的。 d、说一点它的不好的地方在于，生成的代码的可读性还有待提高。 3.2 应用 以下，我同样以开发一个ECU来说明，同时这个ECU部署了Autosar（RTE）。 MBD主要针对ASW开发，当然如果你想用它开发CDD或IO抽象组件，我觉得未尝不可，怎么方便怎么来。 第一步在Autosar工程中导出组件的arxml文件（arxml文件不建议在Matlab中配置，接口管理不好，同时不能很好的和Autosar工程结合）。 第二步将Arxml文件导入到Simulink中，这个时候在Simulink中就生成了基本的模型框架； 第三步根据要求的功能，搭建模型逻辑（吐槽一下，个人写C代码较多，Simulink的if else没C语言来的方便）； 第四步搭完模型后，进行静态检查，比如MAAB、ISO26262、MISAR C2012等，也有除零检查、溢出检查等，记得生成相关报告； 第五步进行单元测试，一般使用Harness进行单元测试，支持excel测试用例导入，考虑到我们要过功能安全，所以MC/DC达到100%吧； 第六步生成代码，注意这里的配置项和数据字典的管理，选择Autosar风格吧。 MBD生成完代码后，和Autosar相关的代码集成到一起，就可以编译链接生成Elf或Out文件了。 04功能安全首先说说Autosar、MBD与功能安全的关系，Autosar的架构非常符合功能安全要求的分层、分模块的要求，同时Autosar中的分区保护、看门狗功能都是功能安全所需要的，此外Autosar的代码一般经过第三方认证，本来就符合功能安全（若自己开发这么一大套代码，费时费力不说，可能达不到功能安全要求）；MBD开发的工具链也是经过功能安全认证，同时它保证了代码和模型的一致性，方便开发的同时，也很好的提供了统计测试覆盖度MC/DC达到100%的报告。 其次说说功能安全其实是一套系统工程，它围绕如何打造一个安全的产品，从管理、开发、生产维护等角度系统性的说明，本文主要从管理和产品开发的角度来简要说明。 4.1 作用 a、它给我们带来一套管理思想，告诉我们如何管理一个符合安全的产品； b、它给我们带来一套正向开发思想，将V模型应用到开发的各个过程； c、它定义了各个活动的输入输出及依赖项，以及对各个活动的要求，提供了开发参考； d、提供了安全分析的思想，包括FMEA、FTA、FMEDA、DFA等； e、同样提一个缺点，认证过程价格太高，开发过程成本提高，开发模板以及案例太少。 4.2 应用 目前国内逐步有些厂家拿到功能安全认证证书，但是目前还没有看到真正功能安全量产的项目，以下主要针对两个角度谈谈功能安全的应用。 管理角度： 一、要求公司有个功能安全组织，建立安全文化，建立功能安全人才培养体系，提升人员能力； 二、要求具备质量体系，比如经过ISO9001认证； 三、要求具备流程体系，比如ASPICE流程认证，具备文档管理、配置管理、变更管理等能力； 四、要求针对项目，有详细的项目计划、安全计划以及安全档案等； 五、要求进行功能安全认证，包括安全审核、安全评估等。 产品开发角度： 一、概念阶段，主要是定义好项目的边界，告诉哪些要开发，哪些不要开发，哪些责任在我方，哪些责任在集成方，同时提出初步的架构。 二、系统阶段，从系统角度分析项目，在初步架构基础上，定义系统架构，从技术安全角度，定义技术安全方案，从安全分析角度，进行系统FMEA或FTA，从部署角度，定义HSI； 三、硬件阶段，细化需求、细化硬件架构、画PCB板，这里很重要的一步在于，进行FMEDA定量分析，以达到预期的FIT，最后进行相应测试。 四、软件阶段，细化需求、细化软件架构，进行软件FMEA分析，进行Autosar与MBD开发，集成测试等。 版权声明：本文为CSDN博主「AgingMoon」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 |
|
|
