汽车电子构架演进二AUTOSAR的组成和演进前文了解了汽车ECU和域控制器从汽车功能上进行了说明。这些功能的具体实现还是需要电路板软件来实现的。AS这个平台代码路径https://github.com/thatway1989/as通过qemu虚拟机可以模拟了一个域控制器的硬件并且上面跑的代码就是AUTOSAR CP的代码。硬件这里不去研究上面运行的AUTOSAR软件结构是什么样的怎么进行编程实现本文将进行说明。1. ECU到域控制器的变化上图中列举了两个功能车门ECU和车顶灯ECU ECU的软件框架。可以看到除了最上面的一层控制逻辑的SWC下面的部分是可以共用的也就是软件是可以复用的。融合的思路很简单第一步把相同的部分找出来第二步部分规定一个接口规范如果有不同的部分就按照接口去跟相同的部分对接。这样就拼接成一个整体了。如下复用就涉及到统一接口的问题大家都按照统一的一个规范搞就可以兼容互换以此诞生了AUTOSARAutomotiveOpen System Architecture组织中文是“汽车开放系统架构”如下图中应用软件层是根据不同的需求会变化的同样对于底层硬件根据供应商价格和性能的不同也是会不断更换。可以把中间的这一层不变的东西抽取出来任你上下面怎么变我都不用动一次做好就不需要投入人力去开发这一部分这样就节省了软件开发成本。相同的部分抽取出来如下图所示2. AUTOSAR的分层结构分层架构是AUTOSAR的一个核心是实现软硬件分离的关键。这个过程比如做菜的话SWC就是炒菜RTE就是锅那BSW就是切好的菜包括洗菜、切菜等硬件就是未加工的菜。如果要做不同菜未加工的菜Hardware和炒菜的方法SWC可以根据客人的需求变化但是锅RTE和洗菜切菜BSW就不用变化了。SWCSoftwareComponentas中代码路径as/com/as.application/common/test 对于应用来说每个车的功能都不同千变万化又有创新性比如车灯控制每个车的车灯个数和位置都不一样车顶控制的软件肯定不一样。应用软件层Application Software LayerASW包含若干个软件组件Software ComponentSWC软件组件间通过端口Port进行交互。RTERuntimeEnvironmentas中代码路径as/com/as.application/common/rte当SWC变化的时候下面的软件都不变这时候就需要一个软总线就好像一条高速公路不管你从什么类型的路上这条高速都按照高速公路的规则运行。这个高速公路就是RTE。运行时环境Runtime EnvironmentRTE作为应用软件层与基础软件层交互的桥梁为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务为应用层软件组件提供了标准化的基础软件和通信接口使得应用层可以通过RTE接口函数调用基础软件的服务。此外RTE抽象了ECU之间的通信即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关所以必须为每个ECU分别实现。BSWBasic SoftwareLa****yeras中代码路径as/com/as.infrastructure基础软件层Basic Software LayerBSW又可分为四层即服务层Services Layer、ECU抽象层ECU Abstraction Layer、微控制器抽象层Microcontroller Abstraction LayerMCAL和复杂驱动Complex Drivers如下图AUTOSAR基础软件层上述各层又由一系列基础软件组件构成包括系统服务System Services、存储器服务Memory Services、通信服务Communication Services等如下图所示。它们主要用于提供基础软件服务包括标准化的系统功能和功能接口。AUTOSAR基础软件层结构1服务层服务层Services Layer提供了汽车嵌入式系统软件常用的一些服务其可分为系统服务System Services、存储器服务Memory Services以及通信服务Communication Services三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统Real Time Operating SystemRTOS等服务。除了操作系统外服务层的软件模块都是与ECU平台无关的。2ECU抽象层ECU抽象层ECU Abstraction Layer包括板载设备抽象Onboard Devices Abstraction、存储器硬件抽象MemoryHardware Abstraction、通信硬件抽象Communication HardwareAbstraction和I/O硬件抽象Input/OutputHardware Abstraction。该层将ECU结构进行了抽象负责提供统一的访问接口实现对通信、存储器或者I/O的访问从而不需要考虑这些资源是由微控制器片内提供的还是由微控制器片外设备提供的。该层与ECU平台相关但与微控制器无关这种无关性正是由微控制器抽象层来实现的。3微控制器抽象层微控制器抽象层MicrocontrollerAbstraction LayerMCAL是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动Microcontroller Drivers、存储器驱动MemoryDrivers、通信驱动Communication Drivers以及I/O驱动I/O Drivers如下图所示。4复杂驱动层由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题难以抽象所以在AUTOSAR规范中这部分没有被标准化统称为复杂驱动Complex Drivers。SWC拓展知识服务软件组件Service SWC。应用软件组件Application SWC主要用于实现应用层控制算法。传感器/执行器软件组件Sensor/ActuatorSWC用于处理具体传感器/执行器的信号可以直接与ECU抽象层交互。标定参数软件组件Parameter SWC主要提供标定参数值。ECU抽象软件组件ECUAbstraction SWC提供访问ECU具体I/O的能力。该软件组件一般提供引用C/S接口的供型端口即Server端由其他软件组件如传感器/执行器软件组件的需型端口Client端调用。此外ECU抽象软件组件也可以直接和一些基础软件进行交互。复杂设备驱动软件组件Complex Device Driver SWC推广了ECU抽象软件组件它可以定义端口与其他软件组件通信还可以与ECU硬件直接交互。所以该类软件组件灵活性最强但由于其和应用对象强相关从而导致其可移植性较差。服务软件组件Service SWC主要用于基础软件层可通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。3. AUTOSAR方法论这里的方法论见我之前的评价AUTOSAR入门-江湖软件提供商外国的感觉有点居心叵测把软件做成能多傻瓜化就多傻瓜做成了工具链车厂的人在界面傻瓜点点配置下就自动生成软件了一行代码也看不到给的代码全是宏就不是让人看的。让你啥都不会然后涨价爱用不用不用没了反正你自己也不会也搞不出来。–这就是AUTOSAR的方法论这里好像解释成阴谋论了。下面就来说说怎么在界面上点一点这个过程。1)ECU提取文件生成上面图中就是OEM提供ECU提取文件的过程这里面用到SWC 描述文件、系统约束描述文件、ECU 资源描述文件。过程如下三种文件导入系统配置的编辑工具中生成系统配置描述文件就是整车的描述文件。整车的描述文件导入系统配置提取工具中得到每个 ECU 的提取文件包含了每个 ECU 需要用到的信息。ECUEXECU Extractof System Description即前面的 ECU 提取文件由 OEM 交给 TIER1TIER1 根据这个文件设计和开发 ECU。ECUEX 是 arxml 文件但如果只做通信矩阵DBC 也可以。2arxml文件生成首先根据需求对硬件进行配置也就是使用EB工具配置MACL生成MACL信息文件的arxml文件。3代码生成根据arxml文件这里生成的代码分为两类给BSW用的和给SWC用的。a首先给BSW系统服务用的这部分生成的是配置代码可以理解为C语言的全局变量可以作为函数执行的参数另一方面是生成宏控制程序的执行流程然后跟BSW中不动的代码一块参与编译。as中代码路径as/com/as.tool/config.infrastructure.system/argenb给SWC用的代码一般是智能化方面的代码比如智能驾驶深度学习的参数需要一些工具比如matlab生成。4. AUTOSAR从CP到AP过渡上面讲的都是AUTOSAR CP的功能。CP里面首先做到了硬件的复用即用一块电路板实现多块的功能然后功能上进行了复用比如里面对CAN的服务就一个模块。但是在软件资源方面比如内存和CPU并没有进行复用。这里先说一个静态系统和动态系统的概念静态系统系统的资源在运行前就已经分配好了就像10块钱5个人分每人2块多少就这样了。动态系统系统的资源运行起来后了按需分配比如还是5个人但是不会同时需要用钱一共准备5块钱就够用了谁需要就给谁这样就节省了资源。CP就是静态系统所有的数据通道内存资源都是分好的并且CPU是单片机时间片也是分好的优点就像计划经济稳定。但是这样一个系统的规模是有瓶颈的当需要分配的单位越来越多的时候硬件已经不堪重负了。不复用不变通整个系统就会走向灭亡。上图中可以看到AP中有了操作系统和服务采用的面向对象的语言C当有服务请求的时候就从服务类里面new一个对象现用现分资源用完立即资源回收。从整个系统通信角度看也从面向信号到面向服务转变。汽车智能化构件越来越复杂是推动CP到AP的根本因素在这个过程中有两个方面尤为突出就是基于以太网的组网和复杂CPU的发展。智能化要联网协作节点越来越多并且可能会通过无线接入Internet网络实现远程控制。另外联网的设备比如摄像头的数据量激增汽车上传统的基于信号的通信比如CAN和LIN已经满足不了需要采用更复杂功能更强的以太网通信车载以太网为汽车ECU带来了更高的带宽使得数据的大量传输能够在短时间得以实现。以太网为更加有效地传输长消息和提供点对点通信提供了有效的解决方案。然而AUTOSAR另一平台CP则是为了传统的车载通信技术CAN设计的不能很好地兼容以太网难以支持基于车载以太网的通信。近些年来汽车变得越来越智能随之汽车对处理器的性能也提出了更高的要求诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。活多就得一个人都干了像上图中的一人乐队一样。上图中可以看出来由传统观念的一个操作系统用一个CPU变成多个CPU提供一个服务一个服务支撑多个操作系统。就像有地一块种有饭一起吃一样这样才能集中力量办大事。从处理器和半导体的技术角度来看一个CPU提高性能的唯一方法是多核并行运行然后如果还不行那就多个CPU再并行起来以提供更强的算力。另一方面不同的操作系统比如控制系统的实时操作系统娱乐域的非实时操作系统控制系统的RTOS等可以满足不同的需求需要在系统中共存。那么所有的软件都运行一个硬件集合上面而不是各自为战这样效率就又可以提升。真是计算机计算的发展就是未来榨取更多的硬件资源。就像很多各种各样的烧煤风力等发电站现在一个大型核电站就搞定了所有能源集中供应。AP和CP的优势不同在系统上需要同时运行起来。所以AP 不会取代 CP 或非 AUTOSAR 平台。相反AP 和后端系统以及路边基础设施共同协作发挥各自的优势一起工作形成一个完整的系统。后记Autosar AP还在规划中速度比较慢但是对于汽车电子的一些趋势已经很明显的显现将在下次的文章中说明。Talk is cheapshow methe code后续会继续更新纯干货分享无广告不打赏欢迎转载欢迎评论交流往期见话题标签AUTOSAR入门公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io 汽车电子构架演进（二）AUTOSAR的组成和演进
汽车电子构架演进二AUTOSAR的组成和演进前文了解了汽车ECU和域控制器从汽车功能上进行了说明。这些功能的具体实现还是需要电路板软件来实现的。AS这个平台代码路径https://github.com/thatway1989/as通过qemu虚拟机可以模拟了一个域控制器的硬件并且上面跑的代码就是AUTOSAR CP的代码。硬件这里不去研究上面运行的AUTOSAR软件结构是什么样的怎么进行编程实现本文将进行说明。1. ECU到域控制器的变化上图中列举了两个功能车门ECU和车顶灯ECU ECU的软件框架。可以看到除了最上面的一层控制逻辑的SWC下面的部分是可以共用的也就是软件是可以复用的。融合的思路很简单第一步把相同的部分找出来第二步部分规定一个接口规范如果有不同的部分就按照接口去跟相同的部分对接。这样就拼接成一个整体了。如下复用就涉及到统一接口的问题大家都按照统一的一个规范搞就可以兼容互换以此诞生了AUTOSARAutomotiveOpen System Architecture组织中文是“汽车开放系统架构”如下图中应用软件层是根据不同的需求会变化的同样对于底层硬件根据供应商价格和性能的不同也是会不断更换。可以把中间的这一层不变的东西抽取出来任你上下面怎么变我都不用动一次做好就不需要投入人力去开发这一部分这样就节省了软件开发成本。相同的部分抽取出来如下图所示2. AUTOSAR的分层结构分层架构是AUTOSAR的一个核心是实现软硬件分离的关键。这个过程比如做菜的话SWC就是炒菜RTE就是锅那BSW就是切好的菜包括洗菜、切菜等硬件就是未加工的菜。如果要做不同菜未加工的菜Hardware和炒菜的方法SWC可以根据客人的需求变化但是锅RTE和洗菜切菜BSW就不用变化了。SWCSoftwareComponentas中代码路径as/com/as.application/common/test 对于应用来说每个车的功能都不同千变万化又有创新性比如车灯控制每个车的车灯个数和位置都不一样车顶控制的软件肯定不一样。应用软件层Application Software LayerASW包含若干个软件组件Software ComponentSWC软件组件间通过端口Port进行交互。RTERuntimeEnvironmentas中代码路径as/com/as.application/common/rte当SWC变化的时候下面的软件都不变这时候就需要一个软总线就好像一条高速公路不管你从什么类型的路上这条高速都按照高速公路的规则运行。这个高速公路就是RTE。运行时环境Runtime EnvironmentRTE作为应用软件层与基础软件层交互的桥梁为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务为应用层软件组件提供了标准化的基础软件和通信接口使得应用层可以通过RTE接口函数调用基础软件的服务。此外RTE抽象了ECU之间的通信即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关所以必须为每个ECU分别实现。BSWBasic SoftwareLa****yeras中代码路径as/com/as.infrastructure基础软件层Basic Software LayerBSW又可分为四层即服务层Services Layer、ECU抽象层ECU Abstraction Layer、微控制器抽象层Microcontroller Abstraction LayerMCAL和复杂驱动Complex Drivers如下图AUTOSAR基础软件层上述各层又由一系列基础软件组件构成包括系统服务System Services、存储器服务Memory Services、通信服务Communication Services等如下图所示。它们主要用于提供基础软件服务包括标准化的系统功能和功能接口。AUTOSAR基础软件层结构1服务层服务层Services Layer提供了汽车嵌入式系统软件常用的一些服务其可分为系统服务System Services、存储器服务Memory Services以及通信服务Communication Services三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统Real Time Operating SystemRTOS等服务。除了操作系统外服务层的软件模块都是与ECU平台无关的。2ECU抽象层ECU抽象层ECU Abstraction Layer包括板载设备抽象Onboard Devices Abstraction、存储器硬件抽象MemoryHardware Abstraction、通信硬件抽象Communication HardwareAbstraction和I/O硬件抽象Input/OutputHardware Abstraction。该层将ECU结构进行了抽象负责提供统一的访问接口实现对通信、存储器或者I/O的访问从而不需要考虑这些资源是由微控制器片内提供的还是由微控制器片外设备提供的。该层与ECU平台相关但与微控制器无关这种无关性正是由微控制器抽象层来实现的。3微控制器抽象层微控制器抽象层MicrocontrollerAbstraction LayerMCAL是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动Microcontroller Drivers、存储器驱动MemoryDrivers、通信驱动Communication Drivers以及I/O驱动I/O Drivers如下图所示。4复杂驱动层由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题难以抽象所以在AUTOSAR规范中这部分没有被标准化统称为复杂驱动Complex Drivers。SWC拓展知识服务软件组件Service SWC。应用软件组件Application SWC主要用于实现应用层控制算法。传感器/执行器软件组件Sensor/ActuatorSWC用于处理具体传感器/执行器的信号可以直接与ECU抽象层交互。标定参数软件组件Parameter SWC主要提供标定参数值。ECU抽象软件组件ECUAbstraction SWC提供访问ECU具体I/O的能力。该软件组件一般提供引用C/S接口的供型端口即Server端由其他软件组件如传感器/执行器软件组件的需型端口Client端调用。此外ECU抽象软件组件也可以直接和一些基础软件进行交互。复杂设备驱动软件组件Complex Device Driver SWC推广了ECU抽象软件组件它可以定义端口与其他软件组件通信还可以与ECU硬件直接交互。所以该类软件组件灵活性最强但由于其和应用对象强相关从而导致其可移植性较差。服务软件组件Service SWC主要用于基础软件层可通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。3. AUTOSAR方法论这里的方法论见我之前的评价AUTOSAR入门-江湖软件提供商外国的感觉有点居心叵测把软件做成能多傻瓜化就多傻瓜做成了工具链车厂的人在界面傻瓜点点配置下就自动生成软件了一行代码也看不到给的代码全是宏就不是让人看的。让你啥都不会然后涨价爱用不用不用没了反正你自己也不会也搞不出来。–这就是AUTOSAR的方法论这里好像解释成阴谋论了。下面就来说说怎么在界面上点一点这个过程。1)ECU提取文件生成上面图中就是OEM提供ECU提取文件的过程这里面用到SWC 描述文件、系统约束描述文件、ECU 资源描述文件。过程如下三种文件导入系统配置的编辑工具中生成系统配置描述文件就是整车的描述文件。整车的描述文件导入系统配置提取工具中得到每个 ECU 的提取文件包含了每个 ECU 需要用到的信息。ECUEXECU Extractof System Description即前面的 ECU 提取文件由 OEM 交给 TIER1TIER1 根据这个文件设计和开发 ECU。ECUEX 是 arxml 文件但如果只做通信矩阵DBC 也可以。2arxml文件生成首先根据需求对硬件进行配置也就是使用EB工具配置MACL生成MACL信息文件的arxml文件。3代码生成根据arxml文件这里生成的代码分为两类给BSW用的和给SWC用的。a首先给BSW系统服务用的这部分生成的是配置代码可以理解为C语言的全局变量可以作为函数执行的参数另一方面是生成宏控制程序的执行流程然后跟BSW中不动的代码一块参与编译。as中代码路径as/com/as.tool/config.infrastructure.system/argenb给SWC用的代码一般是智能化方面的代码比如智能驾驶深度学习的参数需要一些工具比如matlab生成。4. AUTOSAR从CP到AP过渡上面讲的都是AUTOSAR CP的功能。CP里面首先做到了硬件的复用即用一块电路板实现多块的功能然后功能上进行了复用比如里面对CAN的服务就一个模块。但是在软件资源方面比如内存和CPU并没有进行复用。这里先说一个静态系统和动态系统的概念静态系统系统的资源在运行前就已经分配好了就像10块钱5个人分每人2块多少就这样了。动态系统系统的资源运行起来后了按需分配比如还是5个人但是不会同时需要用钱一共准备5块钱就够用了谁需要就给谁这样就节省了资源。CP就是静态系统所有的数据通道内存资源都是分好的并且CPU是单片机时间片也是分好的优点就像计划经济稳定。但是这样一个系统的规模是有瓶颈的当需要分配的单位越来越多的时候硬件已经不堪重负了。不复用不变通整个系统就会走向灭亡。上图中可以看到AP中有了操作系统和服务采用的面向对象的语言C当有服务请求的时候就从服务类里面new一个对象现用现分资源用完立即资源回收。从整个系统通信角度看也从面向信号到面向服务转变。汽车智能化构件越来越复杂是推动CP到AP的根本因素在这个过程中有两个方面尤为突出就是基于以太网的组网和复杂CPU的发展。智能化要联网协作节点越来越多并且可能会通过无线接入Internet网络实现远程控制。另外联网的设备比如摄像头的数据量激增汽车上传统的基于信号的通信比如CAN和LIN已经满足不了需要采用更复杂功能更强的以太网通信车载以太网为汽车ECU带来了更高的带宽使得数据的大量传输能够在短时间得以实现。以太网为更加有效地传输长消息和提供点对点通信提供了有效的解决方案。然而AUTOSAR另一平台CP则是为了传统的车载通信技术CAN设计的不能很好地兼容以太网难以支持基于车载以太网的通信。近些年来汽车变得越来越智能随之汽车对处理器的性能也提出了更高的要求诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。活多就得一个人都干了像上图中的一人乐队一样。上图中可以看出来由传统观念的一个操作系统用一个CPU变成多个CPU提供一个服务一个服务支撑多个操作系统。就像有地一块种有饭一起吃一样这样才能集中力量办大事。从处理器和半导体的技术角度来看一个CPU提高性能的唯一方法是多核并行运行然后如果还不行那就多个CPU再并行起来以提供更强的算力。另一方面不同的操作系统比如控制系统的实时操作系统娱乐域的非实时操作系统控制系统的RTOS等可以满足不同的需求需要在系统中共存。那么所有的软件都运行一个硬件集合上面而不是各自为战这样效率就又可以提升。真是计算机计算的发展就是未来榨取更多的硬件资源。就像很多各种各样的烧煤风力等发电站现在一个大型核电站就搞定了所有能源集中供应。AP和CP的优势不同在系统上需要同时运行起来。所以AP 不会取代 CP 或非 AUTOSAR 平台。相反AP 和后端系统以及路边基础设施共同协作发挥各自的优势一起工作形成一个完整的系统。后记Autosar AP还在规划中速度比较慢但是对于汽车电子的一些趋势已经很明显的显现将在下次的文章中说明。Talk is cheapshow methe code后续会继续更新纯干货分享无广告不打赏欢迎转载欢迎评论交流往期见话题标签AUTOSAR入门公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io