AUTOSAR Adaptive【一】平台功能架构

AUTOSAR Adaptive【一】平台功能架构

序言

基于AUTOSAR的软件产品生产是一套包括分析、设计、开发、部署在内的复杂工作流程。为了将这一系列工作细化任务、明确分工,并有利于敏捷开发,AUTOSAR需要一种用于主要开发步骤的通用技术方法,即AUTOSAR方法学。
Adaptive平台的方法论作为Classsic平台的扩展,引入了新的概念:
Adaptive平台是一个面向服务的软件架构(SOA),面向服务的通信统一使用服务接口(ServiceInterface)来定义。服务接口由事件(Events)、方法(Methods)和字段(Fields)组成。
与Classsic平台相比, Adaptive平台软件的实例是在进程(Process)的上下文中执行。
Adaptive平台新引入了“机器”(Machine)的概念。“机器”是虚拟化的ECU,一个可以部署软件的实体。它可以是真实存在的处理器,也可以是一个虚拟机, Adaptive软件运行在特定的“机器”上。

1、平台功能架构

不多废话再介绍堆理论了直接看图:
在这里插入图片描述
下面先简单说明每个组件即可

2、执行管理(Execution Management)

EM是一个软件组件,用于平台的生命周期管理和进程的生命周期管理,包括平台的初始化、启动和关闭应用程序等。提供以下特性

  • 进程生命周期管理
  • MachineState和功能组状态管理
  • PHM交互重启进程
  • 资源(CPU及RAM)限制功能
  • 支持启动参数配置,环境变量配置,调度策略配置

在这里插入图片描述

3、状态管理(State Management)

SM主要用于接收App的状态变更请求,仲裁后通过EM控制对应功能组中的进程进行启动和停止。SM还会将状态变更通知订阅了此状态的App。App也可以通过订阅接口随时查询状态。提供以下特性

  • 功能组和功能组状态配置
  • 功能组状态切换
  • 状态管理服务接口

在这里插入图片描述

4、通信管理(Communication Management)

CM模块提供用于板间,板内通讯,以及提供E2E的安全传输机制和TLS加密传输,以及S2S信号转服务的通信机制等。
常见有someip协议,dds协议,ipc等。可参考someip专栏和dds专栏。

针对不同的协议提供统一的服务接口封装,服务接口与协议绑定分离,实现通信协议与服务接口的解耦合,满足应用层与基础软件层交互接口的标准化要求。

通信管理——E2E保护

E2E是AUTOSAR提出的一种针对点对点(End-to-End,E2E)的安全通信机制。
它主要用于在运行时保护数据交换,以防通信链路上出现故障。使用E2E通信保护机制,可以保证ECU之间以及ECU内部不同核之间,不同SWC之间的数据安全通信,可以在运行时检测和处理底层软件和硬件层中的故障。它可以满足高达ASIL D级的安全通信。

在这里插入图片描述

通信管理——TLS/DTLS加密传输

TLS建立流程:
在这里插入图片描述
DTLS建立流程:
在这里插入图片描述

5、持久化存储(Persistency)

持久化存储应用程序和其它功能集群提供了一种信息存储机制,可以将信息存储在自适应平台机器上的非易失性存储器中,并提供访问非易失性存储器的标准接口。
可用的存储位置分为两类:键值存储与文件代理存储,键值存储可在一个存储位置存储和检索多个键值对,而文件存储可以允许应用程序创建多个文件(访问器)的文件系统目录,接近传统的文件系统访问。每个应用程序都可以使用多种这些存储类型的组合。
在这里插入图片描述

6、网络管理(Network Management)

AUTOSAR NM基于分散的网络管理策略,这意味着每个网络节点仅根据通信系统内接收和/或发送的NM消息独立执行活动。AUTOSAR NM算法基于周期性NM消息,群集中的所有节点都通过多播消息来接收它们。
NM消息的接收指示发送节点要保持NM群集处于唤醒状态。如果任何节点准备好进入睡眠模式,它将停止发送NM消息,但是只要接收到来自其他节点的NM消息,它将推迟过渡到睡眠模式。最后,如果由于不再接收NM消息而经过了专用计时器,则每个节点都将执行到睡眠模式的转换。
如果NM群集中的任何节点需要总线通信,它可以通过启动传输NM消息来使NM群集保持唤醒状态。

与传统网络管理同睡同醒的逻辑不同,局部网络管理根据不同的电子电气EE功能在整个网络内划分出多个虚拟的局部网络,各个局部网络间可以实现单独的休眠唤醒功能,互不影响。
在这里插入图片描述

7、健康管理(Health Management)

健康管理模块负责监控用户程序的执行情况,他提供以下监视功能:

  • Alive监控:检查被监控的实体的运行次数不是太频繁且不是太少,即在配置的循环周期内,被监控实体的实际执行次数应该在配置的最小次数和最大次数之间。
    例如:6秒内,应用应该报告1-9次
  • Deadline监控:检查被监控实体中,开始检查点到结束检查点的执行时间在配置的最小时间和最大时间范围内。程序应该在一定时间内,一次执行完成,不能循环执行。
    例如:程序流A到B,应在3-5秒内执行完成
  • Logical监控:检查用户应用在执行期间的控制流是否与设计的控制流相匹配。
    例如:程序流是否按预设值的监测点A->C->D->F顺序来执行
  • 健康通道监控:用户应用本身检查判断健康状态(如:温度,电压),报告给健康管理模块,健康管理模块将报告的健康状态和用户配置的健康状态进行比较。检查健康状态是否有效。
  • 重启恢复机制:异常产生时, PHM和WDGM会根据用户预设执行相应的恢复动作。

8、记录与跟踪( Logging and Tracing )

记录与跟踪模块用于记录程序运行的日志。

LT支持三种模式记录日志:

  • FILE模式:表示将日志存储到文件中;此选项明确规范用于开发、集成和原型设计,不适合生产;
  • CONSOLE模式:表示将日志打印到终端;由于终端可能不可见,因此EM将其日志重定向到临时文件中;
  • NETWORK模式:表示将日志发送到3490端口,以便日志客户端软件监听此端口,远程获取日志。

9、更新与配置模块(Update and Config Management)

AUTOSAR自适应平台宣称的目标之一是具备通过空中更新(OTA)灵活地更新软件及其配置的能力。为了支持Adaptive Platform上软件的更改,更新和配置管理模块(UCM)提供了处理软件更新请求的Adaptive Platform服务。

10、诊断管理(Diagnosis Management)

车辆诊断的实现基于ISO 14229-1(UDS)和ISO 13400-2(DoIP)的ISO 14229-5(UDSonIP)。与Classic平台诊断管理不用之处是,Apaptive平台支持的传输层是DoIP,物理层是以太网。

DOIP:是一种车辆发现协议,旨在与诊断基础架构(诊断Client,生产/车间测试仪)进行车外通信。该协议不但使传输大量数据的时间更短(用于软件刷新和参数下载),而且使得远程的直接诊断成为可能。

诊断故障管理:主要负责对控制器故障的管理,包括冻结帧的存储,故障状态的管理,老化管理等。

诊断通信管理:主要负责实现诊断通信服务,包括会话的切换,DTC和DID的读取,物流信息的写入,I/O的控制,诊断功能及网络通信的启停控制等通信的交互及会话管理。

11、时间同步(Time Synchronization)

当需要跨分布式系统的不同用户实例之间的关联时,需要将不同应用程序或ECU的时间进行同步,以便能够及时跟踪此类事件或在准确的时间点触发它们。 TS的用途是将车载网络中各个节点的时钟进行同步,因为各个节点的时钟都是互相独立运行的,而有些应用需要各个节点步调一致地执行。
因此,AUTOSAR为应用程序提供了时间同步API,因此它可以检索与其他实体/ ECU同步的时间信息。然后,通过不同的时间基( Time Base Resource ) 提供时间同步功能,这些时间基通过预构建配置存在于系统中。AUTOSAR时间同步采用gPTP协议,该协议位于OSI模型的层2之上,可以依赖于以太网传输。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

起风就扬帆

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值