汽车电子笔记之：CP AUTOSAR架构及概念（补充一）

目录

1、概述

2、架构描述

2.1、基础软件层(BSW)

2.2、RTE

2.3、VFB

2.4、PortPrototype

2.5、Component

2.6、Composition与原子组件

2.7、VFB与ECU软件架构

2.8、组件与Runnable的关系

2.9、Runnable的概念

2.10、组件的实现与RTE的作用

2.11、应用软件层

2.12、应用层的成员结构

2.13、SWC

2.14、SWC开发

2.15、Internal Behaviour

3、Autosar cp开发方法论

3.1、开发抽象系统描述和基于VFB的系统描述

3.2、开发系统和子系统

3.3、开发应用软件和基础软件

3.4、ECU软件集成

3.5、Autosar CP工具链

3.5.1、系统设计工具

3.5.2、软件组件设计工具

3.5.3、MCAL/BSW 配置及 RTE 代码生成工具

3.5.4、编译与调试工具

1、概述

        AUTOSAR 就是Automotive Open System Architecture的简称，即汽车开放系统架构。 它将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，大部分情况下只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。它对软硬件的解耦，可以使得应用软件不依赖硬件进行开发。AUTOSAR的计划目标主要有三个：

        一是建立分层的体系架构；

        二是为应用程序的开发提供方法论；

        三是制定各种应用接口规范。

2、架构描述

        下图为autosar整体的架构图。首先就能看出AutoSAR主要分为3个层级：应用软件层（AppL），实时运行环境（RTE）和基础软件层（BSW）

        应用软件层（Application Layer）：执行用户应用层代码的地方

        实时运行环境层（Runtime Environment）：提供应用层所需要的一些资源，同时将应用层和底层分离

        基础软件层（Basic Software）：这一层从图中就可以看出，比其它几层都庞大，它主要是将对硬件的操作封装成统一AutoSAR标准的接口，供上层系统调用，需要将其封装到一个标准操作系统的状态才行。

        硬件层（Hardware）：由硬件工程师设计的PCBA

2.1、基础软件层(BSW)

        基础软件层又分为四大类，分别是如下描述：

        微控制器抽象层（MCAL）：就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库Api。就是说这套Api是不同厂商都支持的，但是底层怎么实现，就是芯片厂商的事了。同时也有软件工具EB，可以通过界面配置MCAL功能

        ECU抽象层：如果说MCAL只封装了芯片，那么ECU抽象层就是将硬件上所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC397，还有采样电路，电源电路，CAN电路等等。而MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。所以不管硬件是如何实现的，这里封装后，也形成了统一的Api

        服务层：这里有是更加高级的一层了，服务层里是包含操作系统（OS）的。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。

        复杂驱动：又叫做CDD，主要工作是将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能。（简单说就是其他的概念）

2.2、RTE

        RTE(Run-Time Environment)是autosar ECU架构的核心。它实现了autosar VFB(Virtual Functional Bus)的接口，通过autosar提供的基础服务，使得上层应用之间能够进行通信。并充当上层应用访问OS和BSW层的手段。

        原则上，RTE可以在逻辑上分为两个部件：

        上层应用之间的通信。

        上层应用的调度。

        RTE为不同的上层应用之间的通信提供了不同的范例：sender-receiver(消息传递)、client-server（函数调用）、mode switch（模式切换）。

        每个通信范例都可以应用到intra-task software component分发(包括同一ECU内、同一分区内)、inter-partition software component分发、inter-ECU software component转发。

Inter-ECU communication	ECU之间的通信，通常使用COM。
Inter-partition communication	一个ECU内部，但是不同的分区之间的通信，由不同的OS应用程序表示。它可能涉及使用OS机制，如IOC或受信任的函数调用。这些partition分区可以位于不同的内核上，也可以使用ECU的不同memory section.
Intra-ECU communication	一个ECU内的通信。
Intra-partition communication	一个ECU的一个partition分区内的通信。在这种情况下，RTE可以利用internal buffer和quene进行通信。

2.3、VFB

        Virtual Functional Bus(虚拟功能总线)，在autosar中，application是互连组件的composition（组成）（这个感觉不对，Appliaction个人理解上对应到了功能安全、OS层面了）。在以整车为系统设计时，每个组件会被映射到了特定的ECU，这样就会出现有些组件在不同的ECU内。这时组件之间的虚拟连接会出现两种情况，被映射到本地连接（同一个ECU内），或者通过网络技术特定的通信机制（例如CAN或FlexRay），映射到不同的ECU上。VFB的作用，就是给应用层屏蔽这些通信差异，让应用组件设计时，只感知端口即可。

2.4、PortPrototype

        Autosar规范了软件组件的端口，根据输入/输出方向可分为需型端口（Require Port，RPort）、供型端口（Provide Port，PPort）以及供需端口（Provide and Require Port，PRPort）。

        1）需型端口（Require Port，RPort），用于从其他软件组件获取所需数据或者请求的操作；

        2）供型端口（Provide Port，PPort），用于对外提供某种数据或者某类操作；

        3）供需端口（Provide and Require Port，PRPort），兼有需型与供型两种端口的特性。

        由于端口仅仅定义了方向，在AUTOSAR中端口的属性则用端口接口（Port Interface）来表征。端口接口主要有以下几种类型：

1） 发送者--接收者接口（Sender--Receiver Interface）

2） 客户端--服务器接口（Client--Server Interface）

3） 模式转换接口（Mode Switch Interface）

4） 非易失性数据接口（Non-volatile Data Interface）；

5）参数接口（Parameter Interface）；

6）触发接口（Trigger Interface）；

        比较常用的端口接口是发送者--接收者接口（Sender--Receiver Interface）和客户端--服务器接口（Client--Server Interface）.

        对于发送者--接收者接口（Sender--Receiver Interface），其主要用于数据的传递，发送者发送数据到一个或多个接收者，也可以多个发送者发送数据到一个接收者。该类型接口中定义了一系列的数据元素（Data Element，DE），并且彼此相互独立。如下图所示，该SR接口中定义了两个数据元素，名字为DE_1和DE_2，并且每个数据元素的数据类型各不相同。

        需要说明的是，一个软件组件的多个需型端口、供型端口、供需端口可以引用同一个发送者--接收者接口，并且它们可以使用该接口中所定义的任意一个或者多个数据元素，而不一定使用所有数据元素。

        对于客户端--服务器接口（Client--Server Interface），其主要用于操作（Operation，OP）即函数调用关系，服务器是操作的提供者，多个客户端可以调用同一个操作，但同一客户端不能调用多个操作。客户端--服务器接口（Client--Server Interface）定义了一系列操作函数，它们由引用该接口的供型端口所在的软件组件来实现，并提供给引用该接口的需型端口所在的软件组件调用。下图展示了客户端--服务器接口定义的两个操作OP_1和OP_2，并对每个操作都定义了相关参数和方向，即函数的形参。

2.5、Component

        组件在软件构件著作中的描述：它是一个组装单元，它具有约定式规范的接口，以及明确的依赖环境，可以被独立的部署，由第三方组装。

        Autosar中，在VFB 级构建系统时使用的中心结构元素是“组件”，application就是由一个个组件组成。组件有定义良好的“端口”，通过这些端口，该组件可以与其它组件交互。一个端口总是只属于一个组件，并表示一个组件与其他组件之间的交互点。

        组件可以有多个端口，如下图，显示了一个“座椅加热控制”的组件类型的定义示例，该组件类型基于几个信息源控制座位上的加热元件。在本示例中，组件类型需要以下信息作为输入：

        1. 乘客是否坐在座位上（通过端口“SeatSwitch”，S/R端口）

        2. 座位温度刻度盘的设置（通过端口“Setting”，C/S端口）

        3. 来自中央电源管理系统的一些信息（通过端口“PowerManagement”，S/R端口），这个系统可以在某些条件下禁用座位加热。

这个组件控制着如下信息：

        1. 与座椅温度相关的LED仪表盘。（通过端口“DialLED”，S/R端口）

        2. 加热电子元件（通过端口“HeatingElement”，C/S端口）

        最后，组件可以校准（通过端口“Calibration”），需要组件运行所在ECU的状态（端口“ECU Mode”），并访问本地非易失存储器（“端口nv”）。

        组件也可以仅有少量端口。下图展示了一个传感器/执行器组件（“座椅加热”）。这个组件的输入是加热元件的设置信息（通过端口“setting”），并直接控制座椅加热硬件（通过端口“IO”）。

        对于组件，Autosar还支持组件的多次实例化（实例化等同于具体的哪件事儿），比如可以把座椅加热组件，实例化为左前座椅加热，右前座椅加热。

2.6、Composition与原子组件

        一个由多个组件和连接器组成的子系统被打包成一个“组合”。构成组合的组件，被称作原型。一个组合本身就是一个组件类型，可以有自己的端口。组合可以作为结构元素来构建任意数量的层次系统。

        如下图，描述了组合“座椅加热控制与驱动”的定义。这一组合包含三个原型:原型“SHDial”(组件类型“加热刻度盘”)，原型“SHC”(组件类型“座椅加热控制”)和原型“SH”(组件类型“座椅加热”)。该组合本身是一个组件类型，有6个端口。

此处有个疑问点：原型是不是SWC？

        在AUTOSAR中，组件类型要么是“组合”，要么是“原子”。组合是通过相互连接的原子组件来定义的。原子组件不能进一步分解为更小的组件。

        如下图，显示了组合作为组件类型的使用。本质上显示了另一个包含三个原型的组合:“SHFrontLeft”和“SHFronright”(都是“SeatHeatingControlAndDrivers”类型)、”PM”(电源管理)。

        组合等同于多个SWC组成。

2.7、VFB与ECU软件架构

        当一个由原子组件和连接器组成的子系统部署在一个ECU网络上时，所有原子组件都映射到一个ECU上。组件之间的相应连接器由ECU内部或ECU之间的通信机制实现。

        在图3.11的例子中，原子组件“SHDialFrontLeft”和“SHCFrontLeft”被映射到“ECU1”，而原子组件“PM”被映射到“ECU3”。这意味着前两个组件之间的连接器是在ECU1内处理的，而组件“SHCFrontLeft”和组件“PM”之间的连接将通过ECU1和ECU3之间的网络连接运行.

        下图显示了AUTOSAR分层软件体系结构上的标准组件视图，该体系结构是单个AUTOSAR ECU的体系结构。组件的“AUTOSAR接口”指的是组件的全部端口集。标准化AUTOSAR接口是符合AUTOSAR标准的接口。通常，AUTOSAR服务层提供的就是这样”标准化AUTOSAR接口”。

        下图显示了图3.11的例子中ECU1可能的具体架构。映射到ECU1上的原子软件组件被连接到为ECU1生成的运行时环境中。这个运行时环境通常会实现本地组件"SHCFrontLeft"和"SHDialFrontLeft"之间的本地连接。

        此外，运行时环境还负责路由来自前往远程组件的信息。在本例中，端口“PowerManagement”被路由到底层基础软件中的通信栈。RTE还将组件“SHCFrontLeft”与本地标准化AUTOSAR服务挂钩，例如本地非易失存储器(通过端口“nv”)和ECU本地状态信息(通过端口“ecuMode”)。

2.8、组件与Runnable的关系

        VFB是一个系统建模和通信概念，它允许组件分布在ecu网络中。组件与其他组件之间的交互是通过组件的端口及其相关接口来描述的，这些端口定义了组件提供或要求的操作、数据元素、模式集或校准参数。

        然而，组件的实现还需要访问额外的资源，主要是内存和CPU调度(根据特定的定时计划或响应某些事件执行的代码)。由于这些调度问题与构件的通信需求密切相关，RTE必须同时满足这两个方面。因此，RTE必须为组件提供一个完整的环境，包括:

•适当的机制，通过这些机制，组件的实现(例如在“C”这样的编程语言中)可以:

        1. 为组件的PPort中的数据元素提供值

        2. 读取/使用组件RPort中的数据元素的值

        3. 访问组件的校准参数

        4. 为组件的PPort中的操作提供实现

        5. 通过组件的RPort调用其他组件提供的操作等。

•通过适当的机制调用组件的实现(例如“C”函数)，以响应:

        1. 固定时间的调度(例如:许多组件需要“周期性地”运行)

        2. 与通信机制相关的事件(例如，一些组件可能希望在接收到来自其他组件的数据时得到通知)

        3. 与物理事件有关的事件(即触发事件)。

        4. 组件的实现可以通过适当的机制访问其他公共资源，例如特定于实例的内存

        5. 由于AUTOSAR ECU通常是一个多线程环境，RTE还必须提供所有常用的同步机制。

        为了满足这些需求，autosar提供了一种结构“Runnable”。但是，在一些用例中，SoftwareComponentType可能会定义为没有内部行为的Runnable可运行。例如，如果不需要代理任何NvMService端口或NvMAdmin端口，NvBlockSoftwareComponent不需要任何RunnableEntity。

2.9、Runnable的概念

        以下图举例，描述了映射应用程序的逻辑组件（“SHCFrontLeft”）视图。通过它的端口，该组件表示它需要从其他组件获得哪些信息，并向其他组件提供哪些信息。

        然而，组件的实际实现是由一组“Runnable”组成。一个“Runnable”是一个由组件提供的指令序列，可以由运行时环境启动。“Runnable”一词的用法与Java中的“runnable”接口是一致的:“runnable接口应该可以由任何类实现，其实例由线程执行”。

        下图展示了原子组件和RTE的交互实现视图，该组件提供了6个端口与其他组件交互。内部设计了两种Runnable。分别是“主循环”Runnable，“设置”Runnable。主循环Runnable要求RTE以指定的速率周期性的调用；当其他组件发送设置信息到“Setting”端口时，RTE要调用“设置”Runnable。Runnable要进行实际的端口通信也需要使用RTE提供的操作来实现。以图中为例，“Setting”Runnable要获取SeatSwitch端口的“乘客检测”信息，将调用RTE提供的“Rte_Read_SeatSwitch_ PassengerDetected()”操作。

        原子软件组件和ECU上的RTE之间交互的实现视图

        一个原子软件组件可以只提供一个Runnable，也可以包含大量Runnables。一个Runnable可以是一段非常简单的代码，用于执行简单的算法或复杂的程序。

        一个“Runnable entry”在一个“任务”的上下文中运行。任务为“可运行实体”提供公共资源，如上下文和堆栈空间。通常，操作系统调度器负责在运行时决定哪个“任务”可以在ECU的CPU(或多个CPU)上运行。调度器可以使用许多标准策略(例如，基于优先级的抢占、轮询、时间触发……)。

2.10、组件的实现与RTE的作用

综上所述，一个原子软件组件的实现本质上由三个方面组成:

        1. 组件模型（使用port与port interface的概念）。用于在VFB 级，将组件与其他组件连接起来。

        2. 实现代码，由Runnable实现组件，它是可以由RTE执行的代码片段。

        3. 对RTE的要求：

哪些可运行对象需要周期性执行。

哪些可运行对象需要响应与通信一些事件。

组件希望如何访问端口信息或者调用其他组件的操作。

组件需要的任何其他资源，比如Autosar 服务和本地内存。

在配置正确的AUTOSAR ECU中，RTE将满足组件的需求。如:

确保可运行程序在正确的时间被调用

提供组件访问数据或调用操作所需的函数

提供组件所需的所有其他资源

2.11、应用软件层

基于统一的autosar标准接口与运行环境，进行应用软件的开发。它由一个个swc构成。

它位于autosar软件架构顶层，与ECU和位置无关。

2.12、应用层的成员结构

注意一下Component与SWC不一样的，例如Component也包含了Com\Dem\Dcm等。

应用软件层包含若干个软件组件(SWC，Software Component)，软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体Runnable，运行实体中封装了相关控制算法，其运行可由 RTE 事件触发。所以AppL主要的组成就分下面三部分：

1. 应用软件组件（SWC）

2. AutoSAR标准接口（Port）和连接器（Connect）

3. 可运行实体（Runnable

2.13、SWC

        软件组件不仅仅是应用层的核心，也是一些抽象层、复杂驱动层等实现的载体。AUTOSAR软件组件大体上可以分为原子软件组件（Aotmic SWC）和组合组件（Composition SWC）。原子软件组件则可根据用途分为以下几种类型：

        1）应用软件组件（Application SWC），主要实现应用层算法；

        2）传感器/执行器软件组件（Sensor/Actuator SWC），主要用于处理具体传感器/执行器的信号，可以直接与ECU抽象层进行交互；

        3）标定参数软件组件（Parameter SWC），主要提供标定参数值；

        4）ECU抽象软件组件（ECU Abstraction SWC），主要提供访问ECU具体I/O的功能，其一般提供引用C/S接口的供型端口，即Server端口，交由其他软件组件的需型端口（Client端口）调用；

        5）复杂设备驱动软件组件（Complex Device Driver SWC），其可以定义端口与其他软件组件进行通信，还可以与ECU硬件直接交互，但由于此特点，导致其移植性较差；

        6）服务软件组件（Service SWC），主要用于基础软件层，通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互；

        SWC成员之间不是直接通信的，如下图，它们之间的通信是通过虚拟功能总线（VFB）进行的。各个SWC之间通过蓝色的线去通信，这个线可以把它当作上述描述的连接器（Connect，也就是上述所说的全局变量），其中，蓝色线的每个出口和入口都应该遵循标准的AutoSAR端口。

SWC的分配

SWC的分配

        把下面5个SWC分配到两个ECU中。将车灯开关、调光控制器和左右顶灯（此处以左顶灯为例）放到一个ECU中由车身顶部的一个芯片控制；将左右车门开关（此处以左车门为例）和车门开关逻辑单元放到专用的车门ECU芯片中控制。如下图：

其实介绍到这里，你会发现概念上与上面章节有重合

        两个ECU即为两个控制器，分别位于车身前部的车门控制器和位于车身顶部的顶灯控制器。ECU内部的SWC是通过RTE的管理来通信的；而跨ECU的通信就是通过外部总线（一般为CAN，就是车身上连接各ECU的CAN双绞线束）。

2.14、SWC开发

SWC的开发主要分为三部分：

1. SW-Component Type Description

软件组件类型描述，属于最顶层的SWC的描述，描述内部最小的SWC所使用的接口、数据等，描述SWC间的交互和通信关系，定义SWC的分层结构。

2. SW-Component Internal Behavior Description

软件组件内部行为描述，主要定义RTE层面的使用对象，定义RTE的调度实体，定义相关的触发事件，定义Timing相关的交互参数。

3. SW-Component Implementation Description

软件组件实现描述，最下层的SWC的描述，根据定义的行为产生相关的代码，根据SW-Component定义的交互接口产生相关的接口函数和数据定义，产生RTE交互的接口API以及资源使用。

2.15、Internal Behaviour

软件组件的内部行为（Internal Behaviour，IB）主要包括：

1）运行实体（Runnable Entity，RE），其是一段可执行的代码，封装了一些算法。一个软件组件可以包含一个或多个运行实体；

2）运行实体的RTE事件（RTE Event），每个运行实体都会被赋予一个RTE事件，该事件可以引发这个运行实体的执行。对于RTE事件可以分为多个种类，较常用的RTE事件主要有以下几种：

①周期性事件（Timing Event）；

②数据接收事件（Data-received Event）；

③客户端调用服务器事件（Sever-Call Event）；

下图展示的三个运行实体则对应了三种常用的RTE事件（这篇文章感觉此处写错了，没有看到三种常用的RTE图示啊）。

3）运行实体与所属软件组件的端口访问（Port Access），其是和端口所引用的端口接口类型密切相关的。

对于S/R通信模式，可分为显示（Explicit）和隐式（Implicit）两种模式。若运行实体采用显示模式的S/R通信方式，则数据读写是实时的。当多个运行实体需要读取相同的数据是，若能在运行实体运行之前先把数据读到缓存中，在运行实体运行结束之后再把数据写出去，则可以改善运行效率，这就是隐式模式。下图展示了两种模式的不同之处。

对于C/S通信模式，可分为同步（Synchronous）和异步（Asynchronous）两种模式，其对比如下图所示。

4）运行实体间变量（Inter Runnable Variable，IRV） ，即两个运行实体之间交互的变量，其关系如下图所示。

3、Autosar cp开发方法论

        Autosar CP为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个ECU开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果。开发一个系统可分解为以下四个阶段：

        1. 开发抽象系统描述和基于VFB的系统描述。

        2. 开发系统和子系统。

        3. 开发应用软件和基础软件。

        4. ECU软件集成。

3.1、开发抽象系统描述和基于VFB的系统描述

        如图所示，该阶段首先基于功能提出对整个系统的技术要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确定之前就开始基于 VFB 进行系统架构设计，将功能视角的系统架构转为 VFB 视角的系统架构。

3.2、开发系统和子系统

        如同所示：该阶段将整车的电子电气架构作为输入，结合网络拓扑和硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU，并且将 VFB 的接口转换成能够在通信总线上传输的数据，最后生成系统摘要（System Extract）和 ECU摘要（ECU Extract）供 ECU 软件集成时使用。

3.3、开发应用软件和基础软件

        在VFB视角的系统架构设计完毕后，即可进行原子级 SWC开发包括实现其内部行为，无需关心具体ECU信息。另一方面，在系统和子系统设计完成后，即可进行基础软件开发。因为基础软件独立于 VFB，所以只要在 ECU软件集成前完成开发即可。

3.4、ECU软件集成

        当 ECU 摘要、基础软件、SWC都开发完成后即可进行 ECU软件集成。在该阶段工程师定义好调度表，将SWC 运行实体分配到任务中、补充基础软件配置、生成RTE后即可编译链接生成可执行文件。

        总的来说，该方法论将汽车嵌入式软件开发分为系统架构级、ECU级和SWC级。系统架构级开发可进行整车级别的软件架构设计以及相关功能模块的定义。ECU级开发则着重开发单片机底层软件。SWC级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的ARXML文件进行交互。

3.5、Autosar CP工具链

        V 模型是目前汽车电子软件开发过程中采用的主流开发模式，V 模型左侧统称为设计阶段，主要涵盖业务需求分析（Requirement Analysis）、系统设计（System Design）、架构设计（Architectural Design）、模块设计（Module Design）和编码（Coding）五个阶段。V 模型右侧统称为测试阶段，涵盖单元测试（Unit Testing）、集成测试（Integration Testing）、系统测试（System Testing）和验收测试（Ac- ceptance Testing）四个阶段。在V 模型左侧，当前主流商用工具链可以全面支撑 AUTOSAR CP 开发方法论中提到的系统架构级、ECU 级和 SWC 级开发。

参照 AUTOSAR CP 方法论和开发流程，开发工具主要分为以下四类：

        1. 系统设计工具。

        2. 软件组件设计工具。

        3. MCAL/BSW 配置及 RTE 代码生成工具。

        4. 编译与调试工具。

3.5.1、系统设计工具

        一般由 OEM 使用，主要用于完成软件组件框架（端口、端口接口、数据类型、运行实体、触发事件）的设计及框架代码生成；实现软件组件间通信端口的连接；导入 DBC、LDF 等传统网络描述性文件实现软件组件向 ECU 映射等工作。

3.5.2、软件组件设计工具

        一般由 Tier1 使用，主要用于软件组件框架的搭建，生成符合 AUTOSAR 规范的代码与软件组件 ARXML 文件。之后将 ARXML 文件导入 Matlab Simulink 后可继续进行控制算法模型开发，开发完成后通过自动代码生成获得的 C 代码将用于 ECU 软件集成。

3.5.3、MCAL/BSW 配置及 RTE 代码生成工具

        MCAL（微控制器抽象层） 配置工具主要用于底层驱动的配置与配置代码生成、

        BSW 配置工具主要用于基础软件协议栈的配置与配置代码生成，生成后的配置代码需要与工具供应商提供的静态代码一同进行 ECU 软件集成。

        RTE 代码生成工具以软件组件 ARXML 或基础软件配置ARXML 为输入，生成符合 AUTOSAR CP 标准的 RTE 代码，向软件组件提供可靠的通信和调度服务。

3.5.4、编译与调试工具

        用于 ECU 软件集成时的编译与调试。由于 AUTOSAR CP 工程代码量十分庞大， 所以对编译器和调试器的要求也相对较高。

声明：文章属于转载，原文请见如下链接，如有侵权，请联系本人删除。

AutoSar 架构与概念 - 知乎