五千字长文梳理AUTOSAR方法论

t007

本文来源：AUTOSAR_BSW06_5000字长文梳理Autosar 方法论

一直在想，文章不应该是长篇大论，文章的首要目的一定得是有趣，得让人发自内心的想要看下去，就好像赵本山的小品一样。技术文章也一样。我尽我所能写的有趣、通俗、易懂，让你看了一遍之后，对于标题的内容有大致的印象。当然建议大家不要死记硬背，理解至上，想不通的时候就回来翻翻，就像一本笔记。

你不好奇吗？周围的人都在讲AUTOSAR，AUTOSAR到底是什么？

如果说，Dem Dcm Com这些模块是一片片树叶的话，那么方法论就如同一颗大树，把所有的这些内容紧密联合起来。他们共同的作用，让整个ECU保持良好的健康的运转。那么这篇文章，我们来主要讲下AUTOSAR的方法论，接下来我会从以下几个部分来聊聊AUTOSAR方法论的内容：

AUTOSAR方法论是什么？

自顶向下的设计思想——很有用；

AUTOSAR工作流程的简要介绍（详细的我也没接触过呀）

这三个点弄明白了，也就基本清楚AUTOSAR方法论的核心了；
一、AUTOSAR方法论是什么？

说白了就是整套的AUTOSAR的概念，是如何应用到项目上去的？

通俗的说就是：搭建符合AUTOSAR架构的ECU软件的详细工作流程。

大多数人，可能都只是负责整个开发过程中的一环、例如整车架构师、app算法工程师、底层架构工程师、底层软件开发工程师（包含AUTOSAR配置在里面）

/* 有些人可能对于方法论这个字眼可能很抵触。觉得都是形而上学的东西，会不会无所谓，不影响实际的工作内容。但实则不然，熟悉整体的autosar工作流程，可以帮助你在ECU开发工作过程中更快的明确自己的角色定位。有些人做了很多年；可能一叶障目不见泰山，依旧不清楚自己在整个软件开发体系中是一个怎么样的定位。

举个例子，有些人站在山脚搬石头，心里的想法就是把石头搬上车，完成自己的工作，然后默默无闻的勤恳的干下去；有些人呢，虽然在搬石头，但是，通过经常到山顶去远望，他知道自己在干一件很伟大的工程；同时发现了，除了搬石头外还有很多其他的工作岗位更加适合自己（例如趴在老板怀里。。。）。。。我的思路歪了。

话糙理不糙，想必大家明白方法论的重要性了吧！*/

一些必要的概念先列举下：

ECU （控制器）供应链上的称呼

想必大家经常都在说OEM、TIER1、TIER2这些名称，在大厂工作的童鞋可能相对比较了解一些。这里为了确保大家都能理解，所以还是先解释一下：

OEM:（整车厂）（主要做整车的装配工作）

TIER1: 一级供应商，大陆、博世等（主要给OEM供应ECU等）

TIER2: 二级供应商，英飞凌、NXP等（主要给TIER1供应零件，比如ECU上的芯片、MOS管和电路板等）

而TIER1生产制造ECU，就需要受到OEM的一系列的规定和约束，才能提供OEM所需要的ECU设备。而我们的AUTOSAR也是将一辆汽车设计ECU软件的几乎所有流程都囊括在内了。
二、自顶向下的设计思想——很有用

自顶向下的设计方法是一种逐步求精的设计程序的过程和方法，‌它强调从系统的整体出发，‌首先对最高层次中的问题进行定义、‌设计、‌编程和测试，‌然后将未解决的问题作为子任务放到下一层次中去解决。‌这种设计方法的特点是层次清楚，‌编写方便，‌调试容易。‌通过逐层、‌逐个地进行定义、‌设计、‌编程和测试，‌直到所有层次上的问题均由实用程序来解决，‌从而设计出具有层次结构的程序。‌自顶向下的设计方法不仅适用于软件工程领域，‌还被广泛应用于系统工程、‌电子设计自动化（‌EDA）‌等多个领域。‌

在软件工程中，‌自顶向下的设计方法强调首先从整体上规划整个系统的功能和性能，‌然后对系统进行划分，‌分解为规模较小、‌功能较为简单的局部模块，‌并确立它们之间的相互作用关系。‌这种划分过程可以不断地进行下去，‌直到划分得到的单元可以映射到物理实现。‌自顶向下设计的优点在于其能够提供一个清晰的结构化设计流程，‌有助于提高设计效率和可维护性。‌

此外，‌自顶向下的设计方法还涉及到从顶层开始，‌连续地逐层向下分解，‌直到系统的所有模块都小到便于掌握为止。‌这种方法要求设计师首先对所设计的系统有一个全面的理解，‌通过逐步求精的方式，‌将大型复杂的系统分解为较小的、‌更易于管理的部分，‌从而降低了设计和实现的复杂性。

举个好玩的例子：最终设计目标：把大象塞进冰箱，按照自顶向下的设计思想，我可以把实现目标分为以下三步：

打开冰箱门；

把大象塞进去；

把冰箱门带上。

那接下来，这三步就成为了中间设计目标， 我再依据这三个目标逐步的来进行分解，逐层向下分解，直到能够分解成不可拆分的部分（对于软件工程来说可能是具体的实现了（比如功能代码、或者硬件电路等等））。最终再把所有的、不可拆分的实现组合起来，就形成了完整的ECU。

明白了吧！！！其实很简单的。

AUTOSAR实际上大体就沿用了这种自顶向下的设计思维，我们接着往下看。
三、AUTOSAR工作流程的简要介绍

依据《AUTOSAR规范与车载控制器软件开发中》的定义，ECU的开发主要涉及系统级、ECU级别和软件组件级别的开发；

系统级：主要考虑系统功能需求、硬件资源、系统约束、然后建立系统架构；

ECU级：根据抽象后的信息对ECU进行配置；完善应用功能所需的底层软件功能；

软件组件级：在系统级和ECU级配置的同时，同步进行软件组件（SWC）的开发；

我大白话解释下：说白了就是，一个车型，首先要根据市场环境、公司战略等，定义好最上层都需要这台车具备什么功能，类似于动力类型、舒适性要求、灯光要求、智能座舱要达到的级别等诸如此类。算了，为了让大家有深层次理解，我再贴个图吧。


大家脑子里带着自顶向下的思路来考虑上边的步骤，大致应该明白了吧！要实现以上这6步，可不容易，需要中间许许多多的支持，链接的纽带很多；要解决的问题也很多，我们接着往下讲， 大家带着上面的理解，往下看就行。
1.具体工作流程

从OEM开始设计汽车电子架构开始，到各TIER1完成每个ECU的软件设计的一整套流程。
2.具体的交换文件

OEM和TIER1之间、TIER1内AUTOSAR底层和应用层之间和MCAL与BSW之间都是需要文件交互的。

但我们不可能用word来交换这些信息，比如OEM想要告诉TIER1车辆的CAN报文有哪些这个内容。

使用word的话，OEM编辑起来费时费力，TIER1阅读起来也费事费力；

所以AUTOSAR规定了一种新的文件格式：.arxml，

这种格式基于.xml文件，加上AutoSAR的缩写ar就成了arxml。

用它的好处就是可以由DaVinci等AUTOSAR配置软件自动生成。并且格式固定，便于解析；

比如整车厂用一套软件设计好了整车的CAN通信矩阵，直接导出.arxml，然后发给TIER1；

TIER1在Davinci中打开，所有的内容一目了然，并且自动将CAN、CANIF、PUDR等模块配置好了。

（是不是很方便！不过现在很多厂商还仍然沿用的是DBC文件，其实也都差不多，不过AUTOSAR建议使用arxml文件）
3.具体的操作工具链

符合AUTOSAR的工具链，就比如DaVinci、ETAS这种。
4.实际工作中的工作流程

1. OEM通过一些软件设计出整车的通信矩阵，并导出DBC、FIBEX或LDF文件；

2. OEM将这些文件发送给TIER1；

3. TIER1如果有DaVinci这样的软件，可以导入进去直接自动配置Communication的大部分功能
5.标准工作流+单个ECU的系统实现方法：

下图中主要是在标准AUTOSAR流程中，OEM从需求到生成最终文件（给到每个ECU制造厂商）的主要流程。图中流程的需要软件工具的支持（比如Vector的PREEvision），这样就能做到自动生成相应的描述文件了。图中绿色箭头的含义是：在设计之初，可能需要反复修改。



OEM设计ECU的流程图

这里的虽然是讲单个ECU的开发，实际上还是从整车角度出发，最终生成的就是单个ECU的提取文件，这些提出文件会发给每个ECU的供应商进行开发（APP+BSW等）；流程还是之前说的那三步：

a. 首先是列出需求和资源，这里就用了三种文件来描述这些需求和资源：

SWC描述文件；

系统约束描述文件；

ECU资源描述文件。

b. 然后将这三种文件导入到系统配置编辑工具种，生成系统配置描述文件。该描述文件就是整车的描述文件了

c. 最后将系统配置描述文件导入到系统配置提取工具中，导出每个ECU相应的提取文件。该文件中就包含了每个ECU会需要用到的信息，比如通信矩阵、SWC等信息
5.1 各描述文件的介绍：

下面的内容请结合上图阅读就能比较详细的掌握图中的内容了，本章节要能明白上图在做啥和每个文件在做啥，就算是大功告成了。当然如果同学你是OEM的，下面的文件应该都要详细掌握；

1) SWC描述文件

首先要说明的一点是，SWC描述文件可能有多个文件。主要包含以下信息：

每个SWC的Data和Operations

每个软件组件需要的资源（比如存储、CPU时间和其他）

SWC的接口（Repetition rate）

运行机制

其实说明白就是之前讲过的APPL中讲过的那些内容

2) 系统约束描述文件

该文件主要包含以下信息：

网络拓扑

通信矩阵

总线波特率，定时等

协议

其实就是对整车的公共信息的描述

3) ECU资源描述文件

这个简单说就是哪些ECU能实现哪些具体的功能，具有哪些资源。从而能然系统设计者通过该文件，将不同功能的SWC分配到对应的ECU中。比如 一个SWC的功能是读取温度传感器的值，那么就需要分配给具有温度传感器的ECU中，主要有以下信息：

传感器、执行器

存储器

处理器

通信外部设备（比如外置收发器）

引脚分配

4) 系统配置描述文件

说白了就是对上述三种文件的汇总，包含了整车的上述所有信息。

5) ECU提取文件

就是将系统配置描述文件的信息分配给单个ECU，使得单个ECU得到其需要的信息，不需要的信息就过滤掉了。ECU通过这些信息就能搭建起来自己的软件（当然还需要RTE配置文件、BSW各模块配置文件、MCAL配置文件和源代码等）。重点针对第5条ECU提取文件再进行下重点介绍，因为针对单个ECU开发来讲，OEM给到Tier1 的一般都是这个东西--ECUEX文件。

什么是ECUEX文件呢？ECU提取文件（见下图）就是本节讲的ECUEX文件（全称是ECU Extract of System Description），简单说就是OEM和TIER1交接的文件。

该文件由OEM设计整车时生成，并根据不同的ECU提取出对应的ECUEX文件交接给TIER1，TIER1拿到文件后便可以根据上面的信息来设计和开发ECU。ECUEX文件是arxml文件，但是如果只做通信矩阵这些内容，DBC这类文件也可以胜任（不过随着时代的进步，以后还是慢慢改成arxml最好）。主要可以包含以下内容（也可以只包含其中一部分）：

通信矩阵：比如CAN总线包含的信息，像CANID号、signals、扩展帧还是普通帧和波特率之类的信息。

SWCs、Ports等：SWC以及内部的runnable都可以在ECUEX文件中给出；还包含其Ports；还有SWC之间的连接关系（Connecters）。

数据映射（Data Mapping）： 将总线的信号（NetworkSignals）映射到SWCs中。

ECUEX文件可以很简单（简单到只有通信矩阵），也可以很复杂。目前整体的实现情况来看，主要有三个层次：

等级1：目前普遍状态都是这样的，没办法，最简单，OEM的事情最少；该等级OEM主要还是只做通信矩阵，不过不再使用.dbc这类文件，而是使用.arxml了。下表列出OEM和TIER1的分工：

等级2：进阶状态，OEM进一步做了更多的工作，好处就是能使得整车设计更加协调一致，更加容易把控。



等级3：终极状态，这一等级中，OEM甚至参与了部分的功能设计与实现，这里是说OEM和TIER1都会负责一部分。



总结：大家多品品这个自顶向下的思维架构，其实在日常生活和工作的很多方面都可以运用，利用工作的拆分，工作内容的划分等等。对我个人而言我觉得很有帮助。

最后想问问大家，看完有啥印象了不？感谢大家的观看！希望能对大家有所帮助！

---

本文作者：一片绿叶，欢迎关注作者的知乎，创作不易，欢迎点赞再看收藏关注！

汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。