AUTOSAR软件架构：软件分层概述 / 开普饭

写在最前面：虽然本文主要内容来源于AUTOSAR标准文档，但绝非简单的翻译。我也知道网络上有很多这样的入门文章。但我还是准备写点我自己的东西，还是我的原则，单一的搬运工没意义。既然包含了我自己的理解，受知识所限，我也无法保证100%正确，但我想这也许会引发你更多思考。希望对你有帮助。

文章目录AUTOSAR 的应用范围汽车ECU通用特性AUTOSAR扩展性AUTOSAR软件分层顶层图粗观详细视图微控制器层/MCALECU抽象层复杂驱动/CDD服务层RTE1AUTOSAR 的应用范围AUTOSAR是专门针对汽车ECU而设计的系统架构，这一点我们从它的名字也可以很清楚的知道（AUTomotive Open System ARchitecture）。那汽车ECU有什么特别之处呢？为何还要单独设计一套这么复杂的东西呢？这里不谈原因，原因太多，比如其使用环境复杂，又或者是资本家的游戏等等。这里我们只谈ECU的一些通用特性。1.1 汽车ECU通用特性汽车ECU通常有以下属性：汽车ECU也属于嵌入式ECU，通常它们与硬件有很强的关联，比如控制的传感器或者执行器。通常它们需要接入汽车网络与其他ECU通信以实现更丰富的功能。汽车行业里面常见的网络通信总线有：LIN, CAN, FlexRay, Ethernet等。相比于我们常见的PC电脑，或者我们的手机，又或者很多大型工业控制器，汽车ECU使用的微控制器（MCU）的资源都比较有限，比如它的计算能力，存储能力等要弱很多。通常这类MCU的存储空间（RAM）都在几十K~几百K（上兆的都很少），而我们的手机基本上都是以G为单位。通常在它上面跑的都是实时系统（RTOS）,而不像我们电脑上的Windows/Linux，或者手机上的Android/IOS。（这里指我们最常见的，实际上后面所列这些系统也有很多分支专门处理这种实时性要求高的场景）。这里说的RTOS通常都很小巧，小的只有几K大小，常见的有OSEK/AUTOAR OS, uCOS, FreeRTOS等等，这个市场这种级别的OS太多，甚至你自己也可以动手写一个。代码/程序在内部/外部Flash上面运行。不像我们电脑还有个硬盘。注意:AUTOSAR里面ECU的概念指一个微控制器（MCU）加上外设以及相关的软件/配置，不包含机械设计。也就是说如果你设计了一个产品，一个盒子里面包含了很多个MCU，那么这些MCU每个都要进行独立描述，每个MCU加上它的外设及软件都是一个AUTOSAR-ECU实例。1.2 AUTOSAR扩展性AUTOSAR软件架构是一些通用方法，具有很强的可扩展性，那所谓的扩展性到底体现在什么地方呢？AUTOSAR里面规定了很多软件模块，对这些模块的行为，配置参数，API等等都做了详细的规定，这些模块我们叫标准模块。但我们不可能规定完所有的东西，比如各式各样的传感器，执行器等等，它们太多太多。这些没有被包含在标准里面的东西我们可以通过CDD（Complex Device Drivers ）/复杂设备驱动来实现。这里需要强调的是，标准模块并不意味着就完全不能改了，很多时候我们发现即使标准模块规定了很多东西，看起来很完善，但是不同厂家也不可避免的有自己的特有的东西，所以这部分就不是标准的啦，所以AUTOSAR也允许进行扩展，这就是扩展性体现的地方。同样上面我们提到的CDD，其实也是一种扩展，因为它们都没有包含在标准里面嘛。注意：1、扩展并不意味着你想怎么弄怎么弄，AUTOSAR对这些扩展也做了一些通用的规则，流程等等。你必须遵循这些基本的流程、规则。2、模块可以根据你自己的需求自行添加扩展，但是层级不能增加。关于层级会在后文描述。2AUTOSAR软件分层2.1 顶层图AUTOSAR架构最上层抽象分为3层，分别是：应用层/Application Layer运行时环境/RTE(Runtime Environment)基础软件/BSW(Basic Software)BSW以下就是硬件（MCU）了。如下图所示：

2.2 粗观基础软件/BSW(Basic Software)又继续细分为：服务层/Services LayerECU抽象层/ECU Abstraction Layer微控制器抽象层/Microcontroller Abstraction Layer复杂驱动/Complex Drivers所谓的层，我们通常的理解就是横向的，就向上图那样。但是这里BSW的分层不像上图那样规则，没有严格意义上的横向上的一层一层的，有些是在纵向上跨了多个层的，但横向上看大体上你可以说分为3层（之所以我这里强调横向，是因为后面马上会提纵向划分）。如下图红框所示：

2.3 详细视图上面提到还有纵向划分，是的，BSW的每一层继续在纵向上划分为各个功能组，比如系统服务，内存管理，通信服务等等。如下图所示：

从上图中看，我个人理解，我们也可以说CDD是纵向的独立的一个功能组，这都没问题（标准里面将其归纳在上面提到的层里面，而不是功能组里面）。但我认为这不影响我们理解，也不是重点，只是一个概念而已，比较虚，不管你怎么理解，你记住这个图就够了。这些跨越多个层级的都是一些比较特殊的，比如左侧的系统服务，跨越多个层级的包含OS；右侧的CDD，前面已经提到过；然后还有一个I/O硬件抽象，这部分因为比较简单，上面没有类似于其他功能组需要的各种协议栈，或者管理模块等，所以直接就到RTE层了。上图看起来，每个功能组在纵向上都是一个分类，但这并不是说每个模块/功能组只能在自己所属纵向上使用。比如SPI底层驱动可能划分在Communication Drivers里面。但是该模块的调用路径很可能是通过RTE → I/O Hardeare Abstraction → SPI。但是像CAN这种外设，它就是通过RTE → Communication Services → Communication Hardware Abstraction → Communication Drivers/CAN这条线来使用的。这里提前说了一些调用关系，因为有点关联，具体的每个模块/层级/功能组的调用关系实际上AUTOSAR是有规定的，具体后面再说，这里就不展开了。需要说明的是，我们实际使用的时候也是可以跳开某些层级进行使用（也就是中间某些层不用）。这就是分层的好处。高度耦合，同时又很松散。什么意思呢？这不是自相矛盾嘛。这里的高度耦合是指每个模块内部是高度耦合的，我们把联系紧密的放到一个模块里面。而松散指模块之间的耦合是非常低的，假如你不想要某些功能的时候直接跳过即可。当然这里只是说你非要这么用，技术层面是可以的。如果你开发一个完全满足AUTOSAR的产品，那你还是老老实实按照这个来吧。2.4 微控制器层/MCAL

微控制器层/MCAL是基础软件/BSW里最底下的软件层，它包含了内部驱动，这些驱动直接去访问操作微控制器及其内部外设。也就是依赖于微控制器。作用：让MCAL层的上层软件独立于/不依赖微控制器。举个例子：假如你有一个项目，一开始用了芯片A，啥功能都做完啦，现在老板说我们要节省成本，我们换个芯片吧（叫芯片B），芯片B不但便宜，还Pin2Pin兼容。这时候做应用及上面服务层的同事一片叫好（反正没他们啥事，吃瓜群众）。做MCAL的人就苦逼了，他们得重新针对新的芯片B重新弄一遍。这就是上面不依赖于芯片，有MCAL搞定。2.5 ECU抽象层

ECU抽象层是MCAL层的接口，你会发现在这一层里面有很多名为Xxx_If的模块，与MCAL层相应模块对应。实际上这一层也包含驱动程序，但是是针对外部设备的驱动，而上一章节MCAL是针对微控制器内部外设的。举个例子比较好理解，如前面章节所述，MCU的资源有限，有些时候我们需要使用外扩Flash，通常这种外扩Flash是通过SPI这种端口连接的。我们知道芯片内部自带的Flash是由MCAL里面的Fls模块负责的，那现在这个外扩Flash就自能自己实现啦，所以从这一点来说，它属于CDD范畴。但是它和图示所示CDD不一样的是，它不是直接就到RTE了，而是需要通过ECU抽象层里面Memory相关模块统一管理，所以站在这个层面来看，也可以说是存储相关模块的一个扩展吧（只是这个扩展本身是CDD实现的），并且这个链路中，它还需要使用MCAL里面SPI模块（假设是SPI接口）。所以实际使用中，是不是模块之间的关联也没有图上看起来那么简单啦？（复杂就对了，这就是AUTOSAR 。😄）这里需要注意的是，上面的例子说的外扩Flash不包含那种芯片通过QSPI直接映射的Flash，这种通常是由MCAL/Fls来负责实现的。回到正题，也就是说ECU抽象层提供给上层使用的API与芯片以及ECU设计已经没有关系了，上层不用关心是内部的外设还是外部的设备。也不用关心是通过什么端口类型，哪个端口连接的等等。前面说的是站在上层视角来看的，那么这一层本身来看它与芯片无关，但是与ECU设计有关。所以它的作用：让上层软件独立于ECU硬件布局。举个例子：假如你有一个项目，啥功能都做完啦，突然甲方大大说，以前我们用的LIN总线通信太慢啦，改为CAN吧，这么简单，就今晚交付吧。应用层的同事还是那么洋洋得意，瞌着瓜子。负责MCAL及ECU抽象层的同事已经马不停蹄搬砖啦。该改端口的改端口，该适配信号的适配信号。现在应该懂了吧。2.6 复杂驱动/CDD

如图所示，复杂驱动层从硬件直接跨越到RTE层。CDD为集成特殊功能提供了可能性。比如：那些没有在AUTOSAR里面规定的外设驱动。对时序约束很高的驱动。或者用于迁移集成等。注意：CDD虽然名字叫驱动，但它其实也可以是应用程序。与ECU硬件及MCU相关。2.7 服务层

服务层是基础软件的最高层，它提供了：操作系统车辆网络通信管理服务内存服务（NVRAM管理）诊断服务（包括UDS通信，内存错误和故障处理）ECU状态管理，模式管理逻辑和程序时序流监控（Wdg管理）作用：给应用层，RTE，BSW模块提供基础服务。这一层对ECU没有依赖了，对MCU只能说大部分没有依赖，余下的那一小部分依赖就是OS。通常OS需要针对不同MCU/架构进行移植。注意：对I / O信号的访问是由ECU抽象层实现的。上面提到服务层应用层，RTE提供服务比较好理解。容易忽略的是也对BSW模块提供服务，其实也很好理解，比如其他BSW模块可能不可避免的需要使用OS服务。这又涉及到前面提到过的调用关系了。总的来说大的原则是从上至下调用。但横向互相调用也是可以的。只有下面调用/通知上面这种情况，AUTOSAR使用callback机制。2.8 RTE

RTE是为应用软件提供通信服务的。这些AUTOSAR软件组件之间/软件组件与服务之间的通信都由RTE来实现。这里说的应用软件包含AUTOSAR软件组件/传感器/执行器组件等。在RTE以上的软件架构风格由下面这种“层”的概念变为“软件组件”的风格。作用：针对ECU进行映射以达到AUTOSAR组件完全独立/不依赖于ECU。

<<< BC-Auto 小助手微信最专业的智能汽车社群，值得你的加入

AUTOSAR软件架构：软件分层概述

相关推荐