【AUTOSAR】V知-AUTOSAR快速入门

目录

ECU软件分类

基础软件 BSW

  • 类似windows/Linux的操作系统

应用软件 ASW or application

  • 在基础软件之上，并通过基础软件和硬件交互
  • 控制ECU运行的功能

RTE (run time environment)

  • 作为 BSW 和 ASW 交互的桥梁，为 软硬件解耦 提供了可能
  • RTE 实现了软件组件之间、基础软件之间、软件组件与基础软件之间的通信
    • RTE封装了基础软件层的通信和服务
    • 为应用层软件组件提供了标准化的基础软件和通信接口
    • 使得应用层可以通过RTE接口函数调用基础软件的服务
  • RTE 抽象了ECU之间的通信
    • RTE通过使用标准化的接口，将其统一为软件组件之间的通信
    • 由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现

AUTOSAR

ECU开发标准化的必要性

  • 汽车开发的标准化：
    • 除了诊断和标定，其他都不太统一；
  • ECU开发没有统一标准，迁移困难

AUTOSAR的不同含义

  • AUTOSAR开发搭档：
    • development partnership
    • AUTOmotive Open System ARchitecture开发搭档
    • 一种用于汽车电子系统的开放式架构，允许不同厂商的硬件和软件组件相互兼容和互操作
    • 由汽车制造商和主要供应商成立工作组，为ECU软件开发一套标准规范
  • AUTOSAR规范和软件:
    • 规范首发于2005年，首项目于2006
    • AUTOSAR也指符合规范的软件，eg.AUTOSAR Classic 4.3
  • AUTOSAR方法论:
    • 定义了过程(开发流程)、工具、(工具使用的)文件格式
    • AUTOSAR文件格式：AUTOSAR XML，简称ARXML

AUTOSAR软件结构

分层结构

  • 整个AUTOSAR都是基础软件，是堆栈的结合体
  • 每个区域都可以细分为模块，每个模块都定义了功能和接口
    • 即AUTOSAR的关注点分离
  • AUTOSAR Classic Platform有超过100个模块

AUTOSAR版本：

  • 4.4后，从X.Y变为A-B，A年份，B月份
  • AUTOSAR Classic Platform / AUTOSAR Adaptive Platform

AUTOSAR方法论简化版

  • AUTOSAR做什了么：
    • 定义 功能 及 交互
    • 描述每个功能所需的SWC (software component 软件组件)
    • 将 SWC 分配给 ECUs，并描述网络如何将它们连接起来
      • 系统描述(system description)
  • 即：定义软件组件，分配给ECU，添加网络
    • 每个软件组件只与RTE通信
    • 所有的数据共享都通过RTE实现
    • 从而拥有可移植的应用程序。
  • 小结为：
    • AUTOSAR向下实现了ECU的软硬件解耦
    • 通过无数接口连接ECU，构建一个标准化RTE环境，让ECU数据在这一层共享
    • 开发者只需要描述应用，就能实现新功能的开发

AUTOSAR Adaptive platform

嵌入式软件工程的运行方式：

  • 在ECU内部，以软件形式存在的功能或任务按照预定的调度表周期性运行
    • 这意味着，任务task 按照 调度表schedule 周期性运行
  • IO: 当任务运行时，检查相关输入，并根据输入控制输出。
  • deadline：任务必须在规定时间内执行
    • 任务调度表和截止时间通常以 ms毫秒 为单位
    • 电机：微秒us 为单位
    • 任一项任务超时，将导致所有任务超时
  • 硬实时：hard real-time
    • 通过可预测的执行来满足严格时间限制的需求
    • 硬实时行为：意味着没有任务可以错过deadline
    • AUTOSAR可用来帮助实现 硬实时
      • 此外需要做的：调度表和高效编程等，以确保满足deadline

ACES:

  • 自动驾驶，互联(物联网)，电气化(新能源)，共享(共享汽车和共享数据)
  • OTA是互联、共享的一部分

HCP与ACES:

  • HCP是高性能计算平台，为汽车提供ACES功能
  • HCP软件运行在POSIX环境，如linux
  • 运行AUTOSAR CP的ECU
    • AUTOSAR CP提供硬实时行为
    • ACES处于更上一层，通过动态的面向服务的通信提供其他功能

AUTOSAR两种平台

  • 简称为AUTOSAR CP/AP

不同功能需求：

  • AP：为满足未来汽车所需的ACES功能需求提供算力
  • CP：将继续存在于汽车中，以满足ACES功能以外的硬实时需求。

不同的操作系统状态：

  • AP：依赖POSIX操作系统
  • CP：本身包含操作系统

不同的应用程序运行状态：

  • AP：应用程序作为独立进程运行
    • 可以动态加载/卸载，动态安装/删除，无需重启
    • 可以单独对每个应用程序做任何事
  • CP：必须完全停止所有应用程序 (软件)
    • 例如传统的ECU软件更新 (FBL)，
    • 所有应用程序全部停止后，Bootloader接管权限并刷写

不同的base和语言

  • AP：
    • 基于面向服务的通信 和 面向对象的语言(C++)
    • 为应用程序访问提供ARA
    • 允许使用高级功能库，如ACES所需的目标识别
  • CP:
    • 基于信号/服务的通信 和 面向过程的语言(C)

不同的运行时：RTE和ARA

  • CP：应用程序运行在RTE之上
  • AP：
    • 定义了API，应用程序通过API访问HCP中的功能集群以及AP服务
    • API和AP服务：为应用程序提供AUTOSAR运行时（ARA）
    • ARA由可以访问功能集群的API和Adaptive平台服务组成

不同的platform：

  • CP：定义了超过100个模块，包括行为，彼此交互通信等
  • AP：只规定了API

功能平台和功能集群 functional platform/cluster

  • 功能集群：一组相关的功能
    • 例如访问网络数据（收发数据）
    • 在本地保存和检索数据（persistence）
    • 当出现问题时执行内部记录（日志logging）
  • 平台服务：
    • 提供一种标准化的方式来访问AUTOSAR AP提供的功能

参考链接

END

posted @ 2025-07-18 14:44  anliux  阅读(325)  评论(0)    收藏  举报