文章总结： AutoSar是汽车开放系统架构，分为CP和AP两种平台。CP采用分层架构，包括应用软件层、实时运行环境和基础软件层，实现软硬件解耦。AP则是为适应汽车新四化开发的高性能、灵活的架构平台，支持C++编程和SOA架构。文章详细介绍了AutoSar的组件、开发方法论、工具链以及各功能模块，为汽车电子软件开发提供了全面的技术参考。
综合评分： 90
文章分类： 车联网安全,安全建设,技术标准,解决方案,其他
AutoSar 架构与概念
谈思实验室
2025年12月8日 17:56
上海
点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
01
简介
AUTOSAR 就是Automotive Open System Architecture的简称，即汽车开放系统架构。 它将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，大部分情况下只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。它对软硬件的解耦，可以使得应用软件不依赖硬件进行开发。AUTOSAR的计划目标主要有三个：一是建立分层的体系架构；二是为应用程序的开发提供方法论；三是制定各种应用接口规范。
02
AutoSar CP
架构描述
下图为autosar整体的架构图。首先就能看出AutoSAR主要分为3个层级：应用软件层（AppL），实时运行环境（RTE）和基础软件层（BSW）
应用软件层（Application Layer）：执行用户应用层代码的地方
实时运行环境层（Runtime Environment）：提供应用层所需要的一些资源，同时将应用层和底层分离
基础软件层（Basic Software）：这一层从图中就可以看出，比其它几层都庞大，它主要是将对硬件的操作封装成统一AutoSAR标准的接口，供上层系统调用，需要将其封装到一个标准操作系统的状态才行
硬件层（Hardware）：由硬件工程师设计的PCBA
多核微控制器的分层软件架构示例
03
Autosar层级介绍
基础软件层(BSW)
基础软件层又分为四大类，分别是如下描述：
微控制器抽象层（MCAL）：就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库Api。就是说这套Api是不同厂商都支持的，但是底层怎么实现，就是芯片厂商的事了。同时也有软件工具EB，可以通过界面配置MCAL功能
ECU抽象层：如果说MCAL只封装了芯片，那么ECU抽象层就是将硬件上所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC397，还有采样电路，电源电路，CAN电路等等。而MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。所以不管硬件是如何实现的，这里封装后，也形成了统一的Api
服务层：这里有是更加高级的一层了，服务层里是包含操作系统（OS）的。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作
复杂驱动：又叫做CDD，主要工作是将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能。（简单说就是其他的概念）
实时运行环境层
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转发。
VFB
Virtual Functional Bus(虚拟功能总线)，在autosar中，application是互连组件的composition（组成）。在以整车为系统设计时，每个组件会被映射到了特定的ECU，这样就会出现有些组件在不同的ECU内。这时组件之间的虚拟连接会出现两种情况，被映射到本地连接（同一个ECU内），或者通过网络技术特定的通信机制（例如CAN或FlexRay），映射到不同的ECU上。VFB的作用，就是给应用层屏蔽这些通信差异，让应用组件设计时，只感知端口即可。
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，并对每个操作都定义了相关参数和方向，即函数的形参。
Component
组件在软件构件著作中的描述：它是一个组装单元，它具有约定式规范的接口，以及明确的依赖环境，可以被独立的部署，由第三方组装。
Autosar中，在VFB 级构建系统时使用的中心结构元素是“组件”，application就是由一个个组件组成。组件有定义良好的“端口”，通过这些端口，该组件可以与其它组件交互。一个端口总是只属于一个组件，并表示一个组件与其他组件之间的交互点。
组件可以有多个端口，如下图，显示了一个“座椅加热控制”的组件类型的定义示例，该组件类型基于几个信息源控制座位上的加热元件。在本示例中，组件类型需要以下信息作为输入：
-
乘客是否坐在座位上（通过端口“SeatSwitch”，S/R端口）
-
座位温度刻度盘的设置（通过端口“Setting”，C/S端口）
-
来自中央电源管理系统的一些信息（通过端口“PowerManagement”，S/R端口），这个系统可以在某些条件下禁用座位加热。
这个组件控制着如下信息：
-
与座椅温度相关的LED仪表盘。（通过端口“DialLED”，S/R端口）
-
加热电子元件（通过端口“HeatingElement”，C/S端口）
最后，组件可以校准（通过端口“Calibration”），需要组件运行所在ECU的状态（端口“ECU Mode”），并访问本地非易失存储器（“端口nv”）。
组件也可以仅有少量端口。下图展示了一个传感器/执行器组件（“座椅加热”）。这个组件的输入是加热元件的设置信息（通过端口“setting”），并直接控制座椅加热硬件（通过端口“IO”）。
对于组件，Autosar还支持组件的多次实例化，比如可以把座椅加热组件，实例化为左前座椅加热，右前座椅加热。
Composition与原子组件
一个由多个组件和连接器组成的子系统被打包成一个“组合”。构成组合的组件，被称作原型。一个组合本身就是一个组件类型，可以有自己的端口。组合可以作为结构元素来构建任意数量的层次系统。
如下图，描述了组合“座椅加热控制与驱动”的定义。这一组合包含三个原型:原型“SHDial”(组件类型“加热刻度盘”)，原型“SHC”(组件类型“座椅加热控制”)和原型“SH”(组件类型“座椅加热”)。该组合本身是一个组件类型，有6个端口。
在AUTOSAR中，组件类型要么是“组合”，要么是“原子”。组合是通过相互连接的原子组件来定义的。原子组件不能进一步分解为更小的组件。
如下图，显示了组合作为组件类型的使用。本质上显示了另一个包含三个原型的组合:“SHFrontLeft”和“SHFronright”(都是“SeatHeatingControlAndDrivers”类型)、”PM”(电源管理)。
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”)。
组件与Runnable的关系
VFB是一个系统建模和通信概念，它允许组件分布在ecu网络中。组件与其他组件之间的交互是通过组件的端口及其相关接口来描述的，这些端口定义了组件提供或要求的操作、数据元素、模式集或校准参数。
然而，组件的实现还需要访问额外的资源，主要是内存和CPU调度(根据特定的定时计划或响应某些事件执行的代码)。由于这些调度问题与构件的通信需求密切相关，RTE必须同时满足这两个方面。因此，RTE必须为组件提供一个完整的环境，包括:
适当的机制，通过这些机制，组件的实现(例如在“C”这样的编程语言中)可以:
- 为组件的PPort中的数据元素提供值
- 读取/使用组件RPort中的数据元素的值
- 访问组件的校准参数
- 为组件的PPort中的操作提供实现
- 通过组件的RPort调用其他组件提供的操作等。
通过适当的机制调用组件的实现(例如“C”函数)，以响应:
- 固定时间的调度(例如:许多组件需要“周期性地”运行)
- 与通信机制相关的事件(例如，一些组件可能希望在接收到来自其他组件的数据时得到通知)
- 与物理事件有关的事件(即触发事件)。
- 组件的实现可以通过适当的机制访问其他公共资源，例如特定于实例的内存
- 由于AUTOSAR ECU通常是一个多线程环境，RTE还必须提供所有常用的同步机制。
为了满足这些需求，autosar提供了一种结构“Runnable”。但是，在一些用例中，SoftwareComponentType可能会定义为没有内部行为的Runnable可运行。例如，如果不需要代理任何NvMService端口或NvMAdmin端口，NvBlockSoftwareComponent不需要任何RunnableEntity。
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)上运行。调度器可以使用许多标准策略(例如，基于优先级的抢占、轮询、时间触发……)
组件的实现与RTE的作用
综上所述，一个原子软件组件的实现本质上由三个方面组成:
- 组件模型（使用port与port interface的概念）。用于在VFB 级，将组件与其他组件连接起来。
- 实现代码，由Runnable实现组件，它是可以由RTE执行的代码片段。
- 对RTE的要求：
哪些可运行对象需要周期性执行。
哪些可运行对象需要响应与通信一些事件。
组件希望如何访问端口信息或者调用其他组件的操作。
组件需要的任何其他资源，比如Autosar 服务和本地内存。
在配置正确的AUTOSAR ECU中，RTE将满足组件的需求。如:
确保可运行程序在正确的时间被调用
提供组件访问数据或调用操作所需的函数
提供组件所需的所有其他资源
应用软件层
基于统一的autosar标准接口与运行环境，进行应用软件的开发。它由一个个swc构成。
它位于autosar软件架构顶层，与ECU和位置无关。
应用层的成员结构
应用软件层包含若干个软件组件(SWC，Software Component)，软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体Runnable，运行实体中封装了相关控制算法，其运行可由 RTE 事件触发。所以AppL主要的组成就分下面三部分：
- 应用软件组件（SWC）
- AutoSAR标准接口（Port）和连接器（Connect）
- 可运行实体（Runnable）
04
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接口与其他类型的软件组件进行交互；
Autosar中组件类型
SWC成员之间不是直接通信的，如下图，它们之间的通信是通过虚拟功能总线（VFB）进行的。各个SWC之间通过蓝色的线去通信，这个线可以把它当作上述描述的连接器（Connect，也就是上述所说的全局变量），其中，蓝色线的每个出口和入口都应该遵循标准的AutoSAR端口。
SWC的分配
把下面5个SWC分配到两个ECU中。将车灯开关、调光控制器和左右顶灯（此处以左顶灯为例）放到一个ECU中由车身顶部的一个芯片控制；将左右车门开关（此处以左车门为例）和车门开关逻辑单元放到专用的车门ECU芯片中控制。如下图：
两个ECU即为两个控制器，分别位于车身前部的车门控制器和位于车身顶部的顶灯控制器。ECU内部的SWC是通过RTE的管理来通信的；而跨ECU的通信就是通过外部总线（一般为CAN，就是车身上连接各ECU的CAN双绞线束）。
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以及资源使用。
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事件。
3）运行实体与所属软件组件的端口访问（Port Access），其是和端口所引用的端口接口类型密切相关的。
对于S/R通信模式，可分为显示（Explicit）和隐式（Implicit）两种模式。若运行实体采用显示模式的S/R通信方式，则数据读写是实时的。当多个运行实体需要读取相同的数据是，若能在运行实体运行之前先把数据读到缓存中，在运行实体运行结束之后再把数据写出去，则可以改善运行效率，这就是隐式模式。下图展示了两种模式的不同之处。
对于C/S通信模式，可分为同步（Synchronous）和异步（Asynchronous）两种模式，其对比如下图所示。
4）运行实体间变量（Inter Runnable Variable，IRV） ，即两个运行实体之间交互的变量，其关系如下图所示。
05
Autosar CP开发方法论
Autosar CP为基于该规范的系统开发提供了一个通用的技术方法。它定义了从系统开发到单个ECU开发的各个阶段，以及在各个阶段需要完成的工作内容、需要提供的成果。开发一个系统可分解为以下四个阶段：
-
开发抽象系统描述和基于VFB的系统描述。
-
开发系统和子系统。
-
开发应用软件和基础软件。
-
ECU软件集成。
开发抽象系统描述和基于VFB的系统描述
如图所示，该阶段首先基于功能提出对整个系统的技术要求和约束条件，并且从功能视角设计合理高效的系统架构。其次，工程师在车辆电子电气架构尚未确定之前就开始基于 VFB 进行系统架构设计，将功能视角的系统架构转为 VFB 视角的系统架构。
抽象系统描述与基于VFB的系统描述
开发系统和子系统
如同所示：该阶段将整车的电子电气架构作为输入，结合网络拓扑和硬件资源情况将 VFB 视角的 SWC 分配到各个 ECU，并且将 VFB 的接口转换成能够在通信总线上传输的数据，最后生成系统摘要（System Extract）和 ECU摘要（ECU Extract）供 ECU 软件集成时使用。
系统和子系统开发
开发应用软件和基础软件
在VFB视角的系统架构设计完毕后，即可进行原子级 SWC开发包括实现其内部行为，无需关心具体ECU信息。另一方面，在系统和子系统设计完成后，即可进行基础软件开发。因为基础软件独立于 VFB，所以只要在 ECU软件集成前完成开发即可。
ECU软件集成
当 ECU 摘要、基础软件、SWC都开发完成后即可进行 ECU软件集成。在该阶段工程师定义好调度表，将SWC 运行实体分配到任务中、补充基础软件配置、生成RTE后即可编译链接生成可执行文件。
总的来说，该方法论将汽车嵌入式软件开发分为系统架构级、ECU级和SWC级。系统架构级开发可进行整车级别的软件架构设计以及相关功能模块的定义。ECU级开发则着重开发单片机底层软件。SWC级开发则主要开发具体控制算法。各级开发可以并行，不同的开发之间通过标准化的ARXML文件进行交互。
06
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 方法论和开发流程，开发工具主要分为以下四类：
- 系统设计工具。
- 软件组件设计工具。
- MCAL/BSW 配置及 RTE 代码生成工具。
- 编译与调试工具。
系统设计工具
一般由 OEM 使用，主要用于完成软件组件框架（端口、端口接口、数据类型、运行实体、触发事件）的设计及框架代码生成；实现软件组件间通信端口的连接；导入 DBC、LDF 等传统网络描述性文件实现软件组件向 ECU 映射等工作。
软件组件设计工具
一般由 Tier1 使用，主要用于软件组件框架的搭建，生成符合 AUTOSAR 规范的代码与软件组件 ARXML 文件。之后将 ARXML 文件导入 Matlab Simulink 后可继续进行控制算法模型开发，开发完成后通过自动代码生成获得的 C 代码将用于 ECU 软件集成。
MCAL/BSW 配置及 RTE 代码生成工具
MCAL（微控制器抽象层） 配置工具主要用于底层驱动的配置与配置代码生成、BSW 配置工具主要用于基础软件协议栈的配置与配置代码生成，生成后的配置代码需要与工具供应商提供的静态代码一同进行 ECU 软件集成。RTE 代码生成工具以软件组件 ARXML 或基础软件配置ARXML 为输入，生成符合 AUTOSAR CP 标准的 RTE 代码，向软件组件提供可靠的通信和调度服务。
编译与调试工具
用于 ECU 软件集成时的编译与调试。由于 AUTOSAR CP 工程代码量十分庞大， 所以对编译器和调试器的要求也相对较高。
07
AutoSar AP
简介
新四化（电动化，网联化，智能化，共享化）的变革驱使汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及与非车载系统之间的交互。今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域，信息娱乐系统通常使用 Linux 或商业化的通用操作系统，车身控制则使用标准的AUTOSAR CP。
随着未来新技术及深度嵌入式系统对计算能力需求的不断增长，急需第三种控制器—— 域控制器，用于集成特定领域的功能特性（如车辆动力域、车身域等 )，形成域集中或跨域集中式电子电气架构。在未来，随汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构，以及车云协同控制发展。
在这种趋势下，需要高度灵活、高性能、动态通信等特性的新软件架构平台—— Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。
AP特性
AP包含的特性来自于未来的智能ECU和技术驱动两个方面。高性能的计算满足了安全的需要同时也需要很高的能耗，因此带来了许多新的挑战。为了应对这些挑战，AP采用了很多传统ECU未充分利用的技术。有如下几个方面：
C++
Adaptive AUTOSAR平台的应用都将采用C++编程。虽然C语言是嵌入式系统的主要编程语言，具有执行速度快、效率高的特点；但是在性能要求非常高的复杂应用和算法开发上（如机器学习、图像特征识别等）具有面向对象特性的C++显然比C更具有优势。C++能够提供算法开发和性能均衡的软件。并且方便很快地适配和量产开发。
SOA
为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可伸缩性，AP遵循SOA(service-oriented-architecture)的架构。SOA主要基于以下概念：系统由一组服务构成，其中一个可使用另外一个的服务，应用程序可根据自己的需要使用一个或者多个服务；此外服务可以在应用程序运行的本地ECU上，也可以运行在另一个AP实例的远程ECU上。
并行处理能力
分布式计算本质是并行的。先进的多核异构处理器既具有强大的计算能力也能为并行计算提供技术支持，随着多核异构计算技术的发展，AP具有扩展其功能和性能架构的能力。事实上，硬件和接口规范仅是实现AP的一部分，在OS等技术和开发工具的发展上对实现AP的应用也至关重要。
利用现有标准
重新发明轮子是没有意义的，尤其在规范方面。正如已经在c++中描述的那样，AP采取了重用和适应现有开放标准的策略，以促进AP自身的更快发展，并从现有标准的生态系统中受益。因此，开发AP规范的一个关键重点是不要随意引入现有标准已经提供的新替代功能。例如，这意味着不会仅仅因为现有标准提供了所需的功能，但接口表面上不容易理解，就随意引入新的接口。
安全性
AP所针对的系统通常需要某种级别的安全性，可能是最高级别的安全性。新概念和技术的引入不应破坏这些需求，尽管实现这些需求并非易事。为了应对这一挑战，AP结合了体系结构、功能和过程方法。该架构基于基于SOA的分布式计算，这使得每个组件更加独立，避免了意想不到的干扰，具有专门的功能来帮助实现安全和保障，以及诸如c++编码指南之类的指导方针，它促进了像c++这样的复杂语言的安全使用。
动态计划
AP支持应用程序的动态部署，动态地管理资源和通信，以减少软件开发和集成的工作量，从而缩短迭代周期。在AP架构下，不同的应用可能由不同的供应商提供，因此在产品交付阶段，AP允许系统集成商合理限制这种动态部署的特性以降低不必要的风险和影响。
敏捷
敏捷尽管没有直接反映在平台功能中，AP的目标是适应不同的产品开发过程，特别是基于敏捷的过程。对于基于敏捷的开发，至关重要的是系统的底层架构是可增量扩展的，在部署后可以更新系统。AP的体系结构应该允许这样做。作为概念的证明，AP规范本身和演示者(AP的演示实现)都是用Scrum[^1]开发的。
[^1]: Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums. [1]
CP、AP和非AUTOSAR ECU的集成
综合以上的介绍，AP不会替代CP或者非AUTOSAR的平台。而是与这些平台以及外部后端系统(如路边基础设施)交互，形成一个完整的系统(图2-1不同平台部署示例、图2-2 AP与CP交互示例)。例如，CP已经包含了一些SOME/IP协议，AP也支持这些协议。
08
逻辑视图
ARA
在autosar cp中，应用程序是运行在RTE层之上。同样的，autosar ap架构中，也为应用程序提供了实时运行层。如下图AP架构逻辑视图：其中Adaptive Application(自适应应用)运行在ARA(AUTOSAR自适应应用的运行环境)之上。ARA是应用程序（AP中称为Adaptive Application）运行时的基础环境，可以提供多种本地功能供应用程序调用，这些本地功能在AP中统称为Function Clusters，其分为两个部分：Foundation Function Clusters和Service Function Clusters。
语言绑定
这些API的语言基于C++绑定的，C++标准库也可以作为ARA的一部分使用。关于OS接口，只有POSIX标准的单进程概要文件(PSE51接口)作为ARA的一部分可用。选择PSE51是为了为现有的POSIX应用程序提供可移植性，并实现应用程序之间的自由干扰。
C++标准库包含许多基于POSIX的接口，也包括多线程接口。
应用交互
对于AAs之间的交互，PSE51没有包含IPC (Inter-Process- Communication)，所以在AAs之间没有直接的交互接口。通信管理(CM)是唯一的显式接口。CM还为ECU内外部提供面向服务的通信。CM处理服务请求/响应的路由，而不管服务和客户端应用程序的拓扑部署。
非标准接口
AA和功能集群可以使用任何非标准接口，只要它们不与标准AP功能冲突，并且符合项目的安全性/安全性要求。除非它们是纯粹的应用程序本地运行时库，否则应该注意尽量减少这种使用，因为这将影响软件对其他AP实现的可移植性。
OS，处理器，和线程
AP操作系统要提供多进程 POSIX OS的兼容性。每一个AA实现为一个独立的进程。自适应平台服务和非平台服务也实现为进程。
进程可以是一个单线程或多线程进程。可以使用OS API根据进程所属的逻辑层而有所不同。如果它们是运行在ARA之上的AAs，那么它们应该只使用PSE51。如果一个进程是功能集群之一，它可以自由使用任何可用的操作系统接口。
AA进程不能直接使用IPC，只能通过ARA进行通信。其他进程可以通过IPC或任何其他可用的OS功能相互交互。
基于库或基于服务的功能集群的实现
上图AP架构逻辑视图中，功能集群可以是自适应平台基础模块，也可以是自适应平台服务。为了与同样是进程的AAs进行交互，它们需要使用IPC。有两种替代设计可以实现这一点。一种是基于库的设计，由功能集群提供的接口库链接到AA，直接调用IPC。另一种是基于服务的设计，流程使用通信管理功能，并有一个服务器代理库链接到AA。代理库调用通信管理接口，协调AA进程和Server进程之间的IPC。注意，它是由实现定义的，AA是否只直接执行IPC与通信管理或混合直接IPC与服务器通过代理库。为功能集群选择设计的一般原则是，如果它只在AP实例中本地使用，那么基于库的设计更合适，因为它更简单，也更高效。如果它以分布式方式从其他AP实例中使用，建议采用基于服务的设计，因为通信管理提供透明的通信，而不考虑客户端AA和服务的位置。自适应平台基础的功能集群是基于库的，自适应平台服务的功能集群是基于服务的。最后，需要注意的是，一个功能集群的实现可以没有进程，而是以库的形式实现，在AA进程的上下文中运行，只要它满足功能集群定义的需求规范和软件规范。在这种情况下，AA和功能集群之间的交互将是常规的过程调用，而不是像前面描述的那样基于IPC。
方法论
下图简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的软件集成入车辆中。
（1）架构设计阶段
① 服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field等通信元素以及数据类型详细说明等；
② 机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服务发现配置等信息；
（2）软件开发阶段
③ 定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集；
④ 定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射；
⑤ 服务实例接口框架源码生成；软件集群源码开发及测试等；
（3）集成与部署阶段
⑥ 软件集群集成 (Integrate Software) ：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息；
⑦ ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置；
09
操作系统
概述
操作系统负责运行时的资源和时间管理。EM负责平台初始化和应用的启动和停止，与操作系统协同工作。
AP没有为高性能的处理器指定操作系统。而是，其定义执行上下文和操作系统接口供AP应用使用。
OSI(操作系统接口)规范包含了ARA中部分应用接口以及AP应用的标准接口。OS本身可以很好地提供其他接口，例如创建进程，这是执行管理启动应用程序所需要的，但是这种类型的接口，不能作为ARA的一部分使用，因为它被定义为依赖于平台实现。
OSI同时提供C和c++接口。对于C程序，应用程序的主要源代码业务逻辑包括在POSIX标准中定义的C函数调用，即在IEEE1003.13[1]中定义的PSE51。在编译过程中，编译器决定来自平台操作系统的哪个C库提供了这些C函数，应用程序的可执行文件应该在运行时被链接。对于c++程序，应用软件组件的源代码包括在c++标准及其标准c++库中定义的函数调用。
调度
操作系统提供多线程和多进程的支持。标准的调度策略是SCHED_FIFO和SCHED_RR，由POSIX标准定义。其他如SCHED_DEADLINE或者任何其他操作系统规定的策略也被允许，但有一些限制，即这些策略可能不能跨不同的AP实现移植。
内存管理
支持多进程的原因之一是实现了不同功能集群和AA之间的自由干扰。操作系统对多进程的支持迫使每个进程处于一个独立的地址空间中，与其他进程隔离和保护。同一个可执行文件的两个实例在不同的地址空间中运行，这样它们在启动时可能共享相同的入口点地址和代码以及数据值，但是数据将在内存中的不同物理页中。
10
执行管理（Execution Management）
概述
EM负责系统执行管理的各个方面，包括系统初始化和应用的启停。EM与操作系统协同工作执行应用的调度。
系统启动
当机器启动时，操作系统会被首先初始化然后EM作为操作系统一个初始进程被启动。然后EM启动自适应平台基础的其他功能集群和平台级应用程序。自适应平台基础启动并运行后，EM将继续启动自适应应用程序。平台级应用程序和自适应应用程序的启动顺序由执行管理基于机器清单和应用程序清单信息决定。
EM的职责
EM负责AP平台和应用执行管理的各个方面，包括
1、平台生命周期管理
EM是自适应平台启动阶段的一部分，负责自适应平台和部署的应用程序的初始化
2、应用生命周期管理
EM负责已部署的应用程序的有序启动和关闭。EM根据机器清单和应用程序清单中的信息确定已部署的应用程序集，并根据声明的应用程序依赖项派生启动/关闭顺序。根据机器状态和功能组状态，部署的应用程序在自适应平台启动时或之后启动，然而，并不期望所有的应用程序都立即开始活动工作，因为许多应用程序将向其他应用程序提供服务，从而等待和侦听传入的服务请求。
执行管理不负责应用程序的运行时调度，因为这是操作系统的责任。但是，执行管理负责操作系统的初始化/配置，使其能够根据执行管理从机器清单和应用程序清单中提取的信息执行必要的运行时调度。
状态管理
状态管理提供了一种机制来定义自适应平台的操作状态。状态管理定义了AUTOSAR自适应平台的操作状态，由EM执行不同状态之间的转移。
EM有四种不同的状态：
Machine State该状态主要用控制机器生命周期(Startup/shutdown/restart)，平台级的进程，和其他基础设施。在每台机器上都必须存在几个强制性的机器状态。其他特定于机器的机器状态可以在机器清单中定义。
Function Group State该状态主要用于单独启动和停止功能一致的用户级应用进程组。它们可以在机器清单中配置。
Process State该状态用于应用程序生命周期管理，并由执行管理内部状态机实现。
Execution State该状态描述了应用程序的内部生命周期，即进程。每个进程必须向执行管理报告应用程序状态更改。
如下图，显示了在状态管理请求了不同功能组状态之后，不同类型状态之间的交互的简化示例。可以看到功能组的状态转移，以及引用此功能组的一个状态的流程和执行状态。
11
通讯管理
概述
通信管理实现了自适应AUTOSAR应用程序之间面向服务的通信，适用于所有级别的通信，如进程内、进程内、机器间。它由潜在生成的服务提供者框架和服务请求者代理以及可选的用于中央代理和配置的通用通信管理器软件组成。
通信管理提供了内置的安全机制，即E2E保护，其可以用于所有级别的对于事件和方法的通信。
面向通信的服务
服务的概念意味着提供给应用程序的功能超出了基本操作软件已经提供的功能。通信管理软件提供了一些机制来提供或使用这些服务，用于机器内部通信和机器间通信。
一个服务包括：
Events
Methods
Fields
通信伙伴之间的通信路径可以在设计时、启动时或运行时建立。该机制的一个重要组件是充当代理实例的Service Registry，它也是Communication Management软件的一部分。
每个提供服务的应用程序都在服务注册中心注册这些服务。要使用服务，应用程序需要通过查询服务注册表来查找所请求的服务，这个过程称为服务发现。服务发现可以发现所有本地和远程的服务实例。服务消费由Proxy（P1…P3）表示，应用可以选择使用哪一个服务实例。
语言绑定和网络绑定
通信管理提供了标准化的方法，即如何将已定义的服务呈现给应用程序实现者(上层，语言绑定)，以及服务数据在网络上的各自表示(下层，网络绑定)。这确保了源代码的可移植性和编译服务在不同平台实现之间的兼容性。
语言绑定，定义了如何通过目标编程语言的特性将服务的方法、事件和字段转换为直接可访问的标识符，性能和类型安全(只要目标语言支持)是主要目标。因此，语言绑定通常是由服务接口定义，源代码生成器实现的。
网络绑定定义了如何将已配置服务的实际数据序列化并绑定到特定的网络。它可以根据Communication Management配置(AUTOSAR元模型的接口定义)来实现，既可以解释生成的特定于服务的配方，也可以直接生成序列化代码本身。
网络绑定的三种方式：
SOME/IP网络绑定
基于Signal的网络绑定
DDS网络绑定
本地服务注册也是网络绑定的一部分。
请注意:语言绑定和网络绑定之间的接口被认为是通信管理软件内部的私有接口。因此，定义该接口的规范目前已超出范围。尽管如此，平台供应商还是被鼓励独立地为他们的软件定义这样的接口，以方便实现其他语言绑定(而不是c++)以及平台实现中的其他网络绑定。
生成c++语言绑定的代理和框架
c++语言绑定的上层接口提供了服务的面向对象的映射。
作为Communication Management软件开发工具的一部分，生成器生成c++类，这些类包含各个服务的字段、事件和方法的类型安全表示。
在服务实现端，这些生成的类被命名为服务提供者框架。在客户端，它们被称为服务请求者代理。对于服务方法，服务请求者代理提供了同步和异步调用的机制。调用者可以同时启动其他活动，当服务器的返回值通过c++标准模板库(std::future)的特殊特性可用时，调用者可以接收结果。
当相应的服务器还不可用时，可以对平台实现进行配置，使生成器创建模拟类，即可轻松开发客户端功能。同样的机制也可以用于对客户机进行单元测试。虽然代理类可以被客户端直接使用，但c++绑定的服务提供者框架只是抽象基类。
服务实现应该从生成的基类派生并实现相应的功能。ara::com的接口还可以为端到端安全通信提供代理和框架。
静态和动态的配置
通信路径的配置可以在设计时、启动时或运行时进行，进一步可分为静态或动态的。
完全静态配置:根本不需要服务发现，因为服务器知道所有的客户端，而客户端也知道服务器。
应用程序代码没有发现:客户机知道服务器，但服务器不知道客户机。事件订阅是应用程序中唯一的动态通信模式。
应用程序中的完整服务发现:在配置时不知道任何通信路径。服务发现的API允许应用程序代码在运行时选择服务实例。
12
持久化管理
概述
持久化管理提供应用在NVM中存储信息的机制。该数据可在启动和点火循环使用。持久化通常被实现为一个库，它运行在自适应应用程序的进程中，具有该进程的权限。
持久化管理库将存储位置标识符作为来自应用程序的参数，以寻址不同的存储位置。可用的存储位置分为两类：
Key-Value Storage
File-Proxy Storage
每个应用可以使用多个存储类型的组合。
对于一个应用，存储的数据总是私有的。使用存储库不能在不同应用间共享数据。这一决定是为了防止在communication Management提供的功能之下出现第二个通信路径。
持久化管理对于存储的数据提供加密方法，确保敏感数据在写入物理设备之前进行加密。
Key-Value存储
键值存储提供了从一个存储位置存储和恢复数据的机制。支持的value类型是基础类型，每个Key-Value数据库的键必须是唯一的字符串，并且由应用程序使用存储库提供的方法定义。
File存储
并不是所有持久存储的数据类型都适合Key-Value机制，因此AP平台还支持File存储机制。File存储提供对一组文件的访问，类似于文件系统的目录。
13
健康管理
概述
健康管理为AP应用在车辆内外提供保护信息交互的机制，包括ECU内外的通信机制。出于此目的，这个机制允许在发生任何损坏时进行错误检测。健康监控是ISO26262(控制流程监控、外部监控设施、看门狗、逻辑监控、时间监控、程序顺序监控)所要求的。
另外，对编码指引提供指导，有利于安全可靠的使用复杂的语言，比如C++。
信息交换的保护
最新的AUTOSAR E2E配置支持所有AUTOSAR AP和CP实例组合之间的安全通信，无论它们是在相同或不同的ecu中。在有用的情况下，将提供使用自适应平台中面向服务的更多功能的机制，以允许安全通信。所提供的功能提供了验证从发布者发送和由订阅者接收的信息在传输期间没有更改的可能性。根据AUTOSAR CP中的E2E机制，在E2E上下文中不提供传输确认和传输安全。
当在发布者和订阅者之间的通信中使用端到端保护时，在发布者的进程中同步调用端到端保护。在订阅者端，在接收订阅者流程中的数据时调用被选中的端到端。
平台健康管理
提供健康管理机制以支持fail-safe应用。包含如下方面
Alive supervision（存活监督）
Deadline supervision（运行时间监督）
Logical supervision（逻辑监督）
Error handing of supervision errors（监督错误的异常处理）
Health Monitoring
C++编程指引
AUTOSAR C++ 14编码指南文档适用的主要应用领域是汽车，但它也可以用于其他在安全相关和关键环境中工作的嵌入式应用。AUTOSAR C++ 14编码准则适用于在32位和64位微控制器上，使用POSIX或类似操作系统，提供高效和完整的c++ 14语言支持的高端嵌入式微控制器。
现有的标准是不完整的，包括旧的c++版本，或者不适用于关键/安全相关的。特别是，MISRA c++:2008不包括c++ 11/14。多个新的语言特性需要分析它们在提供有效实现方面的作用，以及使用每个特性会带来多大的风险。
14
安全措施(Security)
概述
Security服务提供AP平台增强系统的方法，比如安全通信和访问管理系统。
身份和访问管理
我们建议AUTOSAR自适应平台采用身份和访问管理框架，以支持对各个AUTOSAR组件(自适应AUTOSAR应用程序、服务和功能集群)进行身份验证，并引入角色和权限管理功能的概念。使用IAM框架，这些应用程序可以查询基于现有策略的访问控制决策。查询将通过功能集群处理，因为应用程序没有与IAM框架的直接接口。在使用请求时，服务将能够用指定的框架来评估请求者的权限和权利，并相应地实施相应的策略。
这个框架背后的思想是由日益增长的安全需求驱动的，因为AUTOSAR自适应平台需要与它的应用程序建立一个健壮的、定义良好的信任关系。如果攻击者破坏了应用程序，它不应该对自适应平台本身有任何影响，攻击者的能力应该被限制在被破坏的应用程序的能力。这就是为什么应用程序应该只能访问系统资源或触发它们应该执行的操作。IAM框架管理身份和访问权限，可以被视为一种可理解的机制，将应用程序的访问限制在必要的最低限度。
Crypto和Key管理
AUTOSAR自适应平台支持用于通用密码操作和安全密钥管理的API。该API支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。为了减少存储需求，密钥可以存储在加密后端内部，也可以存储在外部，并根据需要导入。
该API旨在支持在单独的组件(如硬件安全模块(HSM))中封装安全敏感的操作和决策。通过将密钥限制到特定的使用(例如，仅解密)，或根据IAM的报告，将密钥的可用性限制到单个应用程序，可以提供对密钥和密钥使用的额外保护。
根据应用程序支持的不同，API还可以用于在处理TLS和SecOC等加密协议时保护会话密钥和中间秘密。
安全架构
Key管理
15
更新和配置管理
概述
AP平台提供一个很重要的能力是通过OTA(over-the-air)升级软件和配置。为此，AP平台提供Update and Configuration Manager(UCM)服务处理软件升级请求。
UCM负责升级，安装，卸载和记录AP平台的软件。它的角色类似于已知的包管理系统，如Linux中的dpkg或YUM，具有额外的功能，以确保以一种安全的方式更新或修改Adaptive Platform上的软件。
软件包处理
除了应用程序和配置数据，每个软件包都包含一个清单，提供元数据，如包名、版本和处理包所需的其他元信息。
软件包的数据内容可以包含一个或多个自适应应用程序，内核或固件更新，或更新的配置和校准数据。
UCM基于提供的元数据和Adaptive Platform软件信息处理软件包。
软件信息报告
UCM提供了服务接口，该接口公开了检索Adaptive Platform软件信息的功能，例如已安装软件的名称和版本。
软件更新的一致性
UCM确保只安装具有所有描述的依赖项的验证包。这样就不会安装不需要的或不合适的软件。UCM提供了一个读取安装结果的界面。如果在更新过程中出现故障，UCM将平台恢复到一个已知的功能状态。可恢复故障的一个例子是由于功率损失而中断的更新过程。
16
时间同步
概述
当需要跨分布式系统的不同事件的相关性时，不同应用程序和/或ECU之间的时间同步(Time Synchronization)是至关重要的，无论是为了能够及时跟踪这些事件，还是为了在准确的时间点触发它们。
由于这个原因，一个时间同步API被提供给应用程序，所以它可以检索与其他实体/ECU同步的时间信息。
时间同步功能是通过系统中不同的“时间基础资源”来提供的。
设计
对于AP平台，下面3种不同的技术应用满足时间同步的需要
CP平台的StbM模块
chrono库（与日期和时间相关的库） – std::chrono (c++ 11)或boost::chrono
POSIX Time 接口
时间同步模块提供类似于CP平台StbM的功能，但带有一个std::chrono启发的API设计。
时间同步模块会考虑以下几个方面
Startup Behavior（启动行为）
Constructor Behavior(构造函数的行为)
Normal Operation（正常操作）
Error Handing（错误处理）
未来会考虑以下几个方面
Shutdown Behavior
Error Classification（异常分类）
Version Check
架构
应用程序将能够访问每个基础时间资源(Time Base Resource)以不同的类进行实现。TBR以资源的形式提供，就像在ara::com设计中提供服务一样，因此它采用了以下ara::com的架构设计模式。
代理:类似于ara::com服务代理框架模式，TS提供了一个资源代理模式，省略了框架部分。
查找:类似于ara::com服务代理查找模式，TS提供了一个资源代理查找模式来提供对tbr的访问。
代理方法:类似于ara::com代理方法模式，TS使用的方法模式也遵循异步的Future模式。
当谈到避免延迟时，这种架构设计显然将时间同步设计置于正面冲突之中，因为后者是由ara::com API的设计模式的异步行为固有地添加进来的。
来源：
https://zhuanlan.zhihu.com/p/643415865
谈思AutoSec10周年年会
交流群
谈思10周年年会将深度挖掘汽车网络安全技术、数据安全合规难点、智能网联安全新挑战，通过实战案例拆解、沉浸式技术演示、圆桌对话，为行业提供更系统的安全解决方案与更精准的资源对接平台。
谈思-汽车出海安全合规（欧洲）
交流群
谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台，以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流，都将通过本平台为您提供持续支持。社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。
谈思-SDV&AIDV技术出海
交流群
诚邀行业同仁加入谈思SDV&AIDV出海技术交流群，聚焦软件定义汽车、AI定义汽车、下一代EEA、智能座舱、智能驾驶、软件架构、域控制器开发、芯片技术、软件工具等核心议题，欢迎大家加群交流探讨~~社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。
end
谈思汽车媒体门户
精品活动推荐
AutoSec系列沙龙
专业社群
部分入群专家来自：
新势力车企：
特斯拉、合众新能源-哪吒、理想、极氪、小米、宾理汽车、极越、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……
外资传统主流车企代表:
大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……
内资传统主流车企：
吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……
全球领先一级供应商：
博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、赢彻科技、潍柴集团、地平线、紫光同芯、字节跳动、……
二级供应商(500+以上)：
Upstream、ETAS、BlackDuck、NXP、TUV、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信大捷安、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……
人员占比
公司类型占比
文章
不要错过哦，这可能是汽车网络安全产业最大的专属社区！
首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：谈思实验室 《AutoSar 架构与概念》