AUTOSAR笔记：AUTOSAR基础

目录

简介

什么是AUTOSAR？

AUTOSAR(AUTomotive Open System ARchitecture, 汽车开放系统结构) 是汽车电子行业的一系开放式列标准总称.

2003.9由德国汽车制造商、汽车电子供应商共同成立AUTOSAR组织，旨在推动建立该标准.

包括的汽车企业有：
BMW、Bosch、Continental、Toyota等。

包括的芯片厂商有：
英飞凌、NEC、瑞萨等.

解决什么问题？

  • 功能不断提升，E/E（汽车电气/电子）设备复杂度提升
  • 提升产品更改、升级、更新灵活性
  • 提升产线内或跨生产线可度量性
  • 提升E/E系统质量和可靠性
  • 早期设计阶段检查错误

AUTOSAR主要特征

  1. 模块化、可配置性
  • 定义汽车电子控制单元的分层基础软件架构，以便封装硬件依赖
  • 考虑硬件相关和硬件独立的软件模块
  • 实现不同供应商提供的基础软件模块的集成，增加功能重用
  • 功能软件组件可转移性
  • 根据功能部署，实现每个ECU的软件基础设施的资源优化配置
  • 提高E/E架构可扩展性
  1. 标准化接口
  • 标准化不同的API，分离AUTOSAR软件层
  • 便于封装功能软件组件
  • 软件组件的数据类型定义
  • 软件基础设施的基础软件模块接口标准化
  1. 运行时环境RTE
  • 在车辆网络的所有节点之间，提供ECU之间通信
  • 位于功能SWC、基本SW模块之间
  • 连接到AUTOSAR RTE的所有实体，必须符合AUTOSAR规范
  • 可轻松集成客户特定功能的软件模块
  1. 验收测试
  • 标准化测试规范：测试应用程序，总线兼容性相关的基础软件、RTE实现

常用技术

  • 标准化的规范交换格式（e.g. arxml描述文件）
  • 基础软件核
  • MCU抽象
  • RTE（运行时环境）
  • 接口标准化

AUTOSAR软件结构

软件分层、组成

软件组成：

img

  • AUTOSAR Software Component（软件组件，SWC）：包括 应用SWC、执行SWC、传感器SWC
  • Interface（接口）：分为 标准接口、AUTOSAR接口
  • ECU Firmware（ECU固件）：主要包括 复杂设备驱动、ECU抽象
  • Standard Software（标准软件）：主要包括OS、系统服务（Services）、通信（Communication）、MCU抽象

软件分层：

img

  • Application Layer（应用软件层）：包含若干软件组件，软件组件之间通过端口（Port）通信
  • RTE（运行时环境）：应用软件层与基础软件层交互的桥梁，分离软件与硬件
  • Basic Layer（基础软件层）：包含4层
    • Service Layer（服务层）：提供常用服务，如系统服务、存储服务、通信服务
    • ECU Abstract Layer（ECU抽象层）：包括板载设备抽象、存储硬件抽象、通信硬件抽象、I/O硬件抽象
    • MCU Abstract Layer（MCU抽象层，MCAL）：包括MCU驱动、存储驱动、通信驱动、I/O驱动
    • Complex Drivers（复杂驱动）：复杂传感器、执行器的模块，没被标准化

举例说明：

img

层与层之间交互/调用逻辑如下：

1）应用软件层中SWC通过调用Rte_Write()接口，向RTE请求写操作；
2）RTE调用Nvm_Write()接口，向存储服务模块（NVRAM管理器）请求写操作；
3）NVRAM管理器调用MemIf_Write()，向存储硬件抽象模块中的存储抽象接口请求写操作；
4）存储抽象接口调用FeeWrite()，向Flash EEPROM抽象模块请求写操作；
5）Flash EEPROM抽象 调用Fls_Write()，向存储驱动中的内部Flash驱动请求写操作，最终实现写MCU Flash操作.

RTE

img

  • RTE是AUTOSAR核心，实现软硬件分离的重要部分
  • RTE实现虚拟功能总线（VFB）接口
  • 实现SWC之间通信
  • 提供SWC间通信的基础服务
  • 使得SWC能访问OS、通信服务在内的基础服务

SWC

img

  • 概念上位于RTE之上，包括应用SWC、传感器SWC-执行器SWC
  • 系统配置期间可以配置给任何可用的ECU（∵RTE屏蔽了硬件差异）
  • RTE确保SWC可以通信（SWC之间并不直接耦合，由RTE解耦）

可运行实体RE

每个SWC可包含1或多个运行实体（Runnable Entity，RE），RE中封装了相关控制算法，可由RTE触发.

具体来说，RE是由RTE启动的SWC中的一段指令及相关数据集（程序及数据）.

  • RE代表了一个SWC的功能
  • 1个SWC提供1或多个RE
  • 1个RE有一个入口点
  • RTE调用RE，由RTE事件激活

通信

通信接口由一些端口组成.

特点：

  • SWC能和位于同一个ECU上的其他SWC通信
  • SWC能和位于不同ECU上的其他SWC通信
  • SWC能和有端口并位于同一ECU上的基础软件模块通信
  • 通信是静态的（需要事先配置好，非程序动态分配）

端口（Port）根据I/O方向，分为：

  • 需型端口（Require Port，RPort），从其他SWC获取所需数据或所请求操作
  • 供型端口（Provide Port，PPort），对外提供数据或操作
  • 供需端口（Provide and Require Port，PRPort），兼具RPort、PPort特性

端口定义方向，端口接口（Port Interface）定义端口的属性. 常用端口接口：

  • 发送-接收 端口接口（Sender-Receiver Interface，S/R），提供消息传递.
  • 客户-服务 端口接口（Client-Server Interface，C/S），服务端为客户端提供功能调用.

ECU内SWC通信模型：

img

OS中，运行2个任务：A、B. A由RE1、RE2、RE3协作完成，B由RE2、RE4协作完成.
不同RE之间通信，可通过端口完成.

ECU间SWC之间通信：

img

不同ECU上SWC之间通信，也是通过端口来完成.

通信模式

针对发送-接收通信，有2种通信模式：
1）显式的：使用显式的RTE API调用来发送或接收数据元素
2）隐式的：RE被调用前，RTE自动读一个特定的数据元素集合；RE终止后，RTE自动往另外数据元素集合写

系统服务

img

系统服务（Services）为应用和基础软件模块提供基本服务.

系统服务，包含哪些？

  • OS
  • ECU状态管理器
  • BSW调度器
  • WDog管理器

OS

OS基本特征：

  • 静态配置（汽车行业MCU，不用动态分配内存）

  • 能推断实时系统性能（如何进行？包括哪些？）

  • 提供基于优先级的调度策略

  • 提供运行时保护功能（存储、计时等）

  • 可驻留在低端MCU上，不需要其他资源

  • 资源裁剪

对于特殊应用，OS可配置为只包含该应用需要的服务. 因此，OS的资源需求会尽可能的少.

  • 使用其他OS

如果AUTOSAR组件需要在某些专用OS运行，i.e. Win CE、VxWorks、QNX等，应该使用AUTOSAR OS中定义的接口作为OS抽象层（OSAL）.

那些不使用AUTOSAR OS的系统，可通过OS抽象层（OSAL）提供AUTOSAR SWC执行的平台. AUTOSAR OS严格定义了连接到OSAL的接口.

  • 兼容性

AUTOSAR OS核心功能基于OSEK OS => APP向后兼容

  • 新特性

使用AUTOSAR OS引入的一些新特性，需要对已存在的OSEK OS特性的使用有所限制

AUTOSAR OS扩展了一些已存在的特性

function description
GetApplicationID 获取SWC的application ID
GetISRID 获取当前正在执行的中断服务例程ID
CallTrustedFunction 实现可信/非可信环境切换的关键机制, 允许非可信代码安全地调用可信环境中的函数
CheckISRMemoryAccess 验证中断服务程序(ISR)对内存区域的访问权限
CheckTaskMemoryAccess AUTOSAR OS提供的一项内存保护功能,验证任务(Task)对特定内存区域的访问权限
CheckObjectAccess 验证任务或ISR对系统对象（如资源、设备、服务等）的访问权限
CheckObjectOwnership 确认特定任务或应用对系统对象（如资源、设备、内存区域等）的所有权关系
StartScheduleTableRel 基于相对时间启动调度表(Schedule Table) ，是AUTOSAR时间触发系统的核心功能之一
StartScheduleTableAbs 基于绝对时间启动调度表(Schedule Table)，与StartScheduleTableRel不同是基于绝对时间
StopScheduleTable 停止正在运行的调度表(Schedule Table)，与StartScheduleTableRel、StartScheduleTableAbs搭配使用
NextScheduleTable 实现调度表链式执行，当前调度表完成后自动启动下一个关联的调度表，形成执行链
IncrementCounter 手动递增软件计数器(Software Counter) ，属于AUTOSAR时间服务的一部分，常用于没有硬件定时器支持的特殊场景或测试目的
SyncScheduleTable 同步调度表与时间基准，通过调整调度表的相位(phase)来实现多个调度表间的精确时间对齐，是AUTOSAR时间触发架构中实现分布式系统同步的核心机制
SetScheduleTableAsync 异步设置调度表状态，允许非阻塞地配置调度表参数，适用于需要动态调整调度表且不能立即等待操作完成的场景
GetScheduleTableStatus 查询调度表当前运行状态
TerminateApplication 安全终止应用程序，回收应用资源
DisableInterruptSource 禁用特定的中断源
EnableInterruptSource 与DisableInterruptSource配对使用，启用特定的中断源
ProtectionHook 属于内存/资源保护回调机制. 当发生内存访问违规或资源冲突时，操作系统会调用预先注册的钩子(Hook)函数进行处理. 通常用ARXML配置

注：
1）可信函数（Trusted Function）指AUTOSAR架构中具有特殊执行权限和安全保障的函数，通常用于处理安全关键操作或访问受保护资源.

2）CheckObjectAccess与其他保护机制的关系：

graph TB A[CheckObjectAccess] -->|基于| B[任务身份] A -->|控制| C[资源访问] A -->|协同| D[内存保护] A -->|利用| E[加密服务] D --> F[CheckTaskMemoryAccess] E --> G[TrustedFunction]

调度表

调度表（Schedule Table）是AUTOSAR OS中一种时间触发调度机制，它通过预定义的时间序列来精确控制任务、事件和警报的触发时机

调度表链接机制

sequenceDiagram participant S as 调度表A participant OS as AUTOSAR OS participant N as 调度表B S->>OS: 执行完成 OS->>N: 自动启动(通过NextScheduleTable链接) Note right of OS: 维持时间连续性

BSW调度器

BSW调度器是基础软件层的任务调度管理系统，负责协调和执行各种基础软件模块(BSW模块)的周期性主函数(MainFunction).

功能：

  • 将BSW模块的实现嵌入OS上下文
  • 触发BSW模块的主要处理函数
  • 应用BSW模块的数据一致性机制

BSW调度器建立AUTOSAR OS任务体，安排OS任务体内对主处理函数的调用.

BSW调度与调度表区别：

BSW调度器处理基础设施服务，而调度表管理应用层的实时控制逻辑.

二者协同工作关系：

graph TD A[硬件定时器] --> B(BSW调度器) A --> C(OS调度表) B --> D[BSW模块主函数] C --> E[SWC Runnable] D --> F[通信/诊断等服务] E --> G[应用算法执行]

看门狗管理器

看门狗管理器 是BSW中负责监控系统健康状态的核心安全机制，通过硬件看门狗定时器（WDT）确保ECU出现软件故障时能安全恢复.

一种恢复机制.

在触发看门狗硬件的同时，提供了对一些独立应用的生存监控.

img

诊断服务

诊断服务包括：
1）诊断事件管理器
2）功能禁止管理器
3）开发错误跟踪器
4）诊断通信管理器

诊断事件管理器

诊断事件管理器（Dem）负责处理和存储诊断事件（错误）和相关FreezeFrame（冻结帧）数据，提供标准化的故障存储、事件处理和诊断信息服务.

特性：

  • 事件生命周期管理：

    • 故障检测与确认
    • 老化处理（Aging）
    • 故障计数器管理

  • 统一事件存储

    • DTC管理
    • 冻结帧（Free Frame）存储
    • 扩展数据记录

  • 诊断服务支持：

    • 读取DTC服务（0x19）
    • 清除DTC服务（0x14）
    • 读取冻结帧服务（0x19 02）

img

功能禁止管理器

功能禁止管理器（Function Inhibition Manager，FIM）负责动态控制软件功能可用性的安全机制，根据系统状态和诊断结果禁用或启用特定功能.

开发错误跟踪器

开发错误跟踪器(Development Error Tracer，DFT) 主要用于在开发期间跟踪和记录错误.

API参数给出追踪源和错误类型：

  • 错误所在的模块
  • 错误所在的功能
  • 错误类型

接口：

service function description
FIM_Init() 初始化FIM模块
FIM_GetFunctionState() 查询功能状态
FIM_SetFunctionState() 手动设置功能状态
FIM_MainFunction() 主处理函数

诊断通信管理器

诊断通信管理器(Diagnostic Communication Manager，DCM)是负责处理诊断请求和响应的核心组件，实现UDS（ISO 14229）、OBD（ISO 15031）等标准诊断协议的服务层功能.

DCM与PDU（Protocol Data Unit）路由器（Router）之间有一个接口，在通信过程中，DCM从PDU路由器接收诊断消息.
DCM在内部处理、检查诊断消息，并把消息送到AUTOSAR SW组件进一步处理.

DCM在AUTOSAR体系结构中的位置：

graph TD A[DCM] --> B[诊断接口] A --> C[协议处理] A --> D[服务调度] B --> E[PduR] C --> F[UDS协议] C --> G[OBD协议] D --> H[Dem] D --> I[FIM] D --> J[NvM]

通信栈

主要包含：CAN、COM（通信）、FlexRay、LIN

通信栈与PDU Router关系：

img

CAN

AUTOSAR CAN通信栈，实现CAN总线通信功能的基础软件集合，提供从硬件抽象到应用接口的完整通信解决方案.

AUTOSAR CAN分层体系结构如下图（灰色方块）：

img

CAN通信示例：
发送

sequenceDiagram App->>COM: Com_SendSignal() COM->>PduR: PduR_Transmit() PduR->>CanIf: CanIf_Transmit() CanIf->>CanDrv: Can_Write() CanDrv->>HW: 写入CAN控制器

接收

sequenceDiagram HW->>CanDrv: 接收中断 CanDrv->>CanIf: 接收回调 CanIf->>PduR: PduR_RxIndication() PduR->>COM: Com_RxIndication() COM->>App: 触发接收通知

CAN驱动

CAN驱动（CAN driver）是最底层的一部分，为上层执行对硬件的访问和提供硬件无关的API.

特点：

  • 为上层使用者提供统一接口，即CAN接口.
  • 尽可能合理隐藏相关CAN Controller的硬件专用性.

CAN接口

CAN接口（CAN Interface）提供标准化接口，通过ECU的CAN总线系统来支持通信.

特点：

  • 通过统一接口访问1个或多个CAN驱动
  • 仅能用于CAN通信

CAN传输层

CAN传输层（CAN Transport Protocol，TP）位于PDU Router和CAN接口模块之间的模块. 主要作用：分割和合并>8byte的CAN I-PDU（交互协议数据单元）.

CAN传输层提供的服务：

  • 发送方向的数据分割；
  • 接收方向的数据合并
  • 数据流控制
  • 分割期间内的错误检测

CAN收发器驱动

CAN收发器驱动（CAN Transceiver Driver）直接控制CAN收发器硬件的底层驱动模块，负责管理CAN总线的物理层连接和电源状态.

该驱动与所使用CAN Tranceiver强相关，如TJA1042，1043.

目标：

  • 抽象使用CAN收发器设备硬件芯片，向更高层提供硬件无关接口

CAN模块API

sub-module function
CAN驱动 Can_Init
Can_GetVersionInfo
Can_InitController
Can_Write
CAN接口 CanIf_Init
CanIf_InitController
CanIf_Transmit
CanIf_SetControllerMode
CanIf_GetControllerMode
CAN传输层 CanTp_Init
CanTp_Shutdown
CanTp_Transmit
CAN收发器驱动 CanTrcv_Init
CanTrcv_GotoNormalMode
CanTrcv_GetOpMode
CanTrcv_GotoStandByMode
CanTrcv_GotoSleepMode

COM

AUTOSAR COM（Communication）是BSW中负责信号级通信的核心组件，提供应用层与底层通信协议栈之间的信号接口，实现整车网络的信号交换和处理.
位于服务层.

COM管理（COM Manager，ComM）是BSW的一个组件，COM Manager控制的BSW模块与通信相关，而不是与SWC或RE相关.
位于模式管理层.

COM Manager从通信请求者收集总线通信访问请求，并协调总线通信访问请求.

COM Manager目标：

  • 简化总线通信栈的使用，包括总线通信栈的初始化、简化的网络管理（Net Management，NM）处理
  • 协调与多个SWC（同一ECU）无关的总线通信栈（允许信号的发送和接收）的可用性
  • 临时性取消信号的发送，以阻止ECU唤醒通信总线
  • 控制ECU的一个以上的通信总线通道，通过为每个通道实现一种状态机制来实现
  • 提供使ECU保持总线处于“静默通信”模式
  • 通过分配对请求通信模式必需的所有资源来简化资源管理

COM API:

Module Function
COM Com_Init
Com_DeInit
Com_GetStatus
Com_GetVersionInfo
Com_GetConfigurationId
Com_SendSignal
Com_ReceiveSignal
COM Manager ComM_Init
ComM_DeInit
ComM_GetVersionInfo
ComM_GetStatus
ComM_RequestComMode
ComM_GetMaxComMode
ComM_GetRequestedComMode
ComM_GetCurrentComMode

AUTOSAR COM与OSEK COM很相似，不过多了一个COM Manager.

AUTOSAR COM vs OSEK COM：

  1. 相同的功能、服务

1）启动与控制服务

OSEK AUTOSAR
StartCOM
StopCOM
GetCOMApplicationMode
InitMessage
StartPeriodic
StopPeriodic		 Com_Init
Com_DeInit
Com_IpduGroupStart
Com_IpduGroupStop
Com_DisableReceptionDM
Com_EnableReceptionDM
Com_GetStatus
Com_GetConfigurationId
Com_GetVersionInfo

在这部分，AUTOSAR的API更多，功能更强；AUTOSAR的启动与控制服务中包含对I-PDU（交互层协议数据单元）的处理与控制，如Com_IpduGroupStart，Com_IpduGroupStop.

2）通信服务

OSEK AUTOSAR
SendMessage
ReceiveMessage
SendDynamicMessage
ReceiveDynamicMessage
SendZeroMessage
GetMessageStatus
COMErrorGetServiceId
COMError_Name1_Name2		 Com_SendSignal
Com_ReceiveSignal
Com_UpdateShadowSignal
Com_SendSignalGroup
Com_ReceiveSignalGroup
Com_ReceiveShadowSignal
Com_InvalidateSignal
Com_InvalidateShadowSignal
Com_TriggerIPDUSend

OSEK通信服务包含对错误的简单处理，如获得错误服务的id（COMErrorGetServiceId）；
AUTOSAR通信服务包含对I-PDU的处理，如Com_TriggerIPDUSend.

注：IPDU(Interaction Layer Protocol Data Unit，交互层协议数据单元)和AUTOSAR中核心数据传输单元，负责SWC与底层通信协议栈之间传递数据.

3）OSEK通知机制支持服务 与 AUTOSAR回调通知服务

OSEK AUTOSAR
ReadFlag
ResetFlag		 Com_TriggerTransmit
Com_RxIndication
Com_TxConfirmation

这部分差别不大. 针对一些标志的修改、设置，以控制通信的状态和执行的功能.

  1. 不同的功能、服务

1）OSEK为I-PDU提供一类专门服务，称为OSEK间接网络管理，包含2个API：
I_MessageTransfer I-PDU传输指示；I_MessageTimeOut I-PDU传输超时指示.

2）OSEK提供一些例程对通信起扩展作用，包含3个API：
StartCOMExtension扩展通信启动过程的特殊机制，COMCallouts，COMErrorHook.

3）AUTOSAR提供一些调度函数，主要针对消息或信号的接收或发送其到路由、调度的作用，包含3个API：
Com_MainFunctionRx（周期调度）处理所有 接收到的 PDU，Com_MainFunctionTx（周期调度）负责处理 信号的打包和发送（Tx）操作，Com_MainFunctionRouteSignals处理信号路由（Signal Routing）相关的任务.

4）AUTOSAR有一个COM Manager 通信管理模块，AUTOSAR特有，负责对通信进行监控、管理、诊断以及管理涉及通信的ECU状态.

COM Manager部分API：

img

LIN

LIN（Local Interconnect Network,局部互联网络）包括：LIN驱动、LIN接口.

AUTOSAR LIN分层体系结构：

img

  • LIN驱动

LIN驱动是最底层的一部分，执行硬件访问，为上层提供硬件无关API.

一个LIN驱动能支持1个以上通道（同LIN单元）.

  • LIN接口

LIN接口硬件无关，位于上层模块（PDU路由器）和下层模块（LIN驱动）之间.

LIN接口能处理1个以上LIN驱动，1个LIN驱动能支持1个以上通道.

LIN接口提供功能：

1）为每个与ECU连接的LIN总线执行当前选择的调度
2）当上层请求到来时，切换调度表
3）从上层接收帧的传送，并传送数据部分作为适当LIN帧中响应
4）当相应的响应在适当的帧中接收时，为上层提供帧接收通知
5）睡眠和唤醒服务
6）错误处理
7）诊断传输层服务

OSEK AUTOSAR
LIN驱动 Lin_Init
Lin_GetVersionInfo
Lin_GetStatus
Lin_InitChannel
Lin_DeInitChannel
Lin_GoToSleep
Lin_Wakeup
LIN接口 LinIf_Init
LinIf_ChannelInit
LinIf_GetVersionInfo
inIf_Transmit
LinIf_GotoSleep
LinIf_WakeUp
LinTp_Transmit
LinTp_Shutdown

AUTOSAR方法、模型、工具

AUTOSAR方法

在系统开发的某些步骤需要通用的技术方法，称为AUTOSAR方法.

AUTOSAR方法 没有定义角色、责任，不规定要执行哪些活动，不定义整体的时间线，也并不定义迭代怎样和何时执行.

AUTOSAR方法是一个工作产品流（work-product flow），定义“工作产品流”中活动的相互依赖性.

常用到的图形：

img

ECU从设计到构建、集成的典型的过程：

img

可以看出，每个活动都有一个工作产品（.xml）输出.

AUTOSAR模型

AUTOSAR模型是UML2.0一个子集，是UML2.0元模型的简化.

因为UML2中，高度模块化的结构和对类、属性、关联重定义的过度使用，有时很难在用一两幅图展现某个特定方面的同时，又保持清晰可读性. 因此，简化2.0元模型.

AUTOSAR模型与UML区别：

规则 说明
[ATPS-06] AUTOSAR不支持名字空间，所以所有类的名字必须全局唯一
[ATPS-07] 模型中的所有元素都必须是“Public”
[ATPS-08] 模型元素不得使用重定义
[ATPS-11] 类中不得有操作
[ATPS-13] 模板类属性和关联角色不得定义为静态
[ATPS-14] 常规类必须标注属性
[ATPS-15] 属性不得定义为只读
[ATPS-16] 属性定义必须唯一
[ATPS-17] 属性不得派生于另一个属性
[ATPS-25] 聚合只能是组合聚合（实心菱形表示），而不能是共享聚合
[ATPS-27] 不得定义操作属性
[ATPS-28] 《atpType》表示该类描述的是可重用类型
[ATPS-29] 《atpPrototype》表示该类描述了另一个类的用法
[ATPS-30] 关联不得标名
[ATPS-31] 关联只能是二重的
[ATPS-33] 关联只能有一个导向端
[ATPS-34] 《isOfType》表示原型和其定义的类型之间的特殊关系
[ATPS-35] 《isOfType》只能用于从atpPrototype到atpType
[ATPS-37] 《instanceRef》表示源类引用了prototype的一个实例
[ATPS-38] 《instanceRef》总是指向prototype
[ATPS-41] 依赖只能标记为《trace》、《use》和不标记。

例：一个简单模型

img

是不是很像我们平时画的类图？

AUTOSAR工具

AUTOSAR创作工具指所有支持解释、修改、创建用于描述系统的AUTOSAR XML描述（AUTOSAR模型的XML表示）的工具.

这些模型由以下模板产生：

  • SWC模板
  • ECU资源模板
  • AUTOSAR系统模板

img

AUTOSAR Authoring Tools 用于设计、配置和生成符合AUTOSAR标准的汽车软件系统的专业工具链.

必需的4类工具：

  • Behavior Modeling Tools（行为建模工具），定义SWC动态行为的专业工具，它们将算法设计与AUTOSAR架构无缝集成

  • Feature Definition(功能定义)，对ECU功能需求标准化描述的核心机制，建立从整车功能需求到软件实现的桥梁.

  • Graphic Notation（图形化表示法），可视化描述AUTOSAR软件架构和组件交互的标准符号系统.

  • Interoperability（互操作性），提供不同厂商提供的AUTOSAR软件组件和工具能够无缝协同工作的能力

AUTOSAR商用开发、设计工具

目前较大的AUTOSAR商用工具提供商：

  • ETAS：ASPECT系列产品
  • Mentor Graphics：Volcano系列产品
  • Vector：DaVinci系列产品
项目 工具
设计网络体系和通信数据的工具 DaVinci Network Designer CAN & LIN & FlexRay
Volcano Network Architect (VNA)
ASCET-MD
支持将分布式系统的设计自动转化成代码的工具 DaVinci Tool Suite
Real-Time Workshop Embedded Coder
ASCET-SE
ORPHEUS
对网络和ECU仿真和测试的工具 CANoe
Volcano FixBox
CANopen网络的项目管理工具 ProCANopen
Mentor’s Network Management
数据库工具 CANdb++
CANdb++ Admin

ECU从设计到构建、集成的典型过程：

img

posted @ 2025-06-30 20:07  明明1109  阅读(1300)  评论(0)    收藏  举报