• 1448查看
  • 0回复

[Autosar] Adaptive Autosar状态管理和平台健康管理需求汇总

[复制链接]


该用户从未签到

发表于 3-6-2024 19:11:02 | 显示全部楼层 |阅读模式

汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师


名词解释

    Machine State:机器状态

    Execution State:程序的执行状态

    StateManagement Internal State:SM的内部状态

    Network Management State:网络管理状态

    Function Group State:控制功能组的生命周期管理

    Function Group:功能组,进程的集合

    Function Cluster:功能卒,需求的集合

    State Management/SM:状态管理

    NM:网络管理

    PHM:平台健康管理

    SE:Supervised Entity监控实体

    Alive Supervision:周期性检查实体的时间限制是否超过最大值和最小值

    Checkpoint:被监控实体的控制流监控点

    Dasiy chaining:链接多个健康监控实体(Feature不再支持)

    Deadline Start/End Checkpoint:截止时间开始监控点、截止时间的结束监控点

    Elementary Supervision Status:alive监控、Deadline监控、Logical监控的综合状态

    Health Channel:提供系统健康状态的信息通道

    Health Monitoring:软件正确的时序和顺序行为的监控

    Health Status:应用的监控状态,电压值,应用状态,RAM监控算法结果

    Logical Supervision:监控程序是否按照程序预定义的顺序执行。

    Elementary Supervision Status:元素级监控状态。

    Global Supervision Status:全局监控状态,由多个元素级监控状态组成。

    Modelled Process:模型化进程,一种存在于arxml文件中的Process元素

    Reporting Process:可以向EM反馈信息的进程

    Non-Reporting Process:不向EM反馈信息的进程

    Self-Terminating Process:自行启动和终止的进程

    Unexpected Self-termination:意外终止

    TriggerIn:Trigger SM内部状态,Trigger 状态组的状态。

    TriggerOut: SM通知ARA状态改变,SM 通知ARA状态组改变。

    TriggerInOut:当FC改变SM内部转态时,FC可以确认其完成这种操作。

前言

SM的含义

SM是AP中的一个功能集群,负责运营状态管理的所有方面,包括处理传入事件、对这些事件/请求进行优先级排序以及设置相应的内部状态。

PHM的含义

PHM监控应用程序的Alive和Deadline以及Logical检查,一旦检测到失效,则通知SM,SM做真正的处理。

Alive的含义

检查实体的时间限制是否超过最大值和最小值。类似于事件看门狗。

Deadline的含义

截止时间开始监控点、截止时间的结束监控点。类似于窗口看门狗。

Logical的含义

监控程序是否按照程序预定义的顺序执行。类似于程序流监控。

前言正文

SM和PHM、EM本身相互交织,互相影响。本文基于23-11版本,进行理解,可能有理解偏差的地方,望指正!!!!!!

SM负责状态管理,管理机器状态类似于ECUM、管理功能组状态。

PHM负责管理程序的健康度即功能安全相关的属性,包括功能组的健康度、环境的健康度。

健康度影响状态,状态触发程序的后处理,后处理又可能触发EM对程序的启停操作。

对于程序与功能组有映射关系,功能组和功能组状态有映射关系,受监控实体状态和功能组的状态有映射关系,功能组状态和全局状态有映射关系。

此处的映射关系可以理解为这是一种函数关系,即y = f(x)。一个x对应有且仅有一个y,这个对应关系就是映射。因此SM、PHM中的映射就是一一对应的关系,不存在一个x对应多个y的情况存在。

SM需求

Adaptive Autosar状态管理和平台健康管理需求汇总w1.jpg

先上一张SM的架构图。SM要和普通Component、Process、EM、PHM、NM、UCM、DM实现交互。

    提供标准化的接口

    支持改变SM内部状态,任何程序可获取SM内部状态。

    当状态变更时,应通知相应的进程。

    SM内部应该内置静态状态切换表。每一个功能组的状态都有actionlist。

    在虚拟化环境中,支持高优先级虚拟机中的SM和低优先级虚拟机环境中的SM通信

    支持数据标定,SM可以将FG设置成固定的FG状态,便于读取标定数据。

    SM动态的建立通信路径,不同FG和SM之间有各自独立的通信路径,SM和FG之间通过动态的通信路径实现控制。

    SM按照系统中最高完整性的需求实施。即要求最高功能安全等级实施,也就是意味着PHM需要监控SM。则SM也需要做Alive/Logical/Deadline,受PHM监控,这样可以实现更高的功能安全需求。

    PHM,DM,UCM,NM需要和SM实现交互。

    Function Group应支持标定,便于deactivate功能组。如果某个功能组未配置,SM不允许请求其变更状态。

    SM统筹管理和仲裁功能组状态变更的请求。

    SM支持4种复位方式:hardReset , keyOffOnReset , softReset , customReset。同时支持快速下电。

    SM应协调恢复行为,SM是一个中心化的功能组件,PHM汇报监控结果以及SM决定是否实施恢复行为。(状态变更,通知安全模块,ECU复位)

    PHM请求重启某个程序,PHM通知SM相关信息,SM作出反应。PHM无法和SM通信,可以实施自己的应对措施。

    UCM功能正常运行时,可请求SM状态变更,同时禁止系统下电,UCM执行完毕之后,可请求SM执行复位操作。

    支持特殊的Function Group State,别名为Machine State,需要和电源模式、系统状态关联。

SM相关示意图

Adaptive Autosar状态管理和平台健康管理需求汇总w2.jpg

SM由EM启动,SM向EM上报执行状态,初始化各种状态。

Adaptive Autosar状态管理和平台健康管理需求汇总w3.jpg

当SM的状态发生切换时,执行actionlist,通知EM对App1执行退出操作,对App2执行启动操作。

Adaptive Autosar状态管理和平台健康管理需求汇总w4.jpg

当由程序触发SM 功能组状态变更时示意图。

Adaptive Autosar状态管理和平台健康管理需求汇总w5.jpg

PHM需求

Adaptive Autosar状态管理和平台健康管理需求汇总w6.jpg

Adaptive Autosar状态管理和平台健康管理需求汇总w7.jpg

Adaptive Autosar状态管理和平台健康管理需求汇总w8.jpg


    当程序运行状态为krunning时,开始alive监控,PHM需要获取程序EM状态。Deadline和Logical监控可以在程序状态变成krunning之前开始执行。

    EM和PHM的时间基准应该相同,PHM收到EM关于程序退出的信息之后,PHM停止该程序相关的所有内部监控。

    对于自退出程序的监控的处理,PHM也需要获取相应的程序运行状态。EM通知PHM程序的状态。

    PHM发现监控失败,则通知SM实施恢复处理/后处理。

    PHM支持自定义的健康管理(例如RAM test, ROM test, kernel status, voltage monitoring),并提供相应的通道实现数据传输,此通道称之为Health Channel。

    Health Channel初始化时有初值,若无初值,则PHM表示其为未定义。

    一个Health Channel由Name、ID、初值三个配置信息组成。

    基于Function Group State配置监控模式,不同的Function Group State可以更新监控模式。

    Elementary Supervision Status和Global Supervision Status状态依赖于alive、deadline、Logical结果确定。

    PHM支持配置对错误的反应以及相应的debounce参数。

    对SM的监控失败,则PHM需要触发看门狗复位。

    对EM的监控失败,则PHM需要触发看门狗复位。

    未配置的进程上报checkpoint,需要产生一个信息安全事件。

    PHM支持同个监控实例的多个实体。(同样的软件多次启动,多进程或者多线程)

    PHM支持单个进程或者同个进程多线程的监控,算法需要支持一个线程,多个线程,多进程的调用。

    对同一个程序的实施多个监控实例,支持同一个程序多个实例化

    一个PHM 监控实例的输出等于另外一个实例的输入

    Adaptive Autosar状态管理和平台健康管理需求汇总w9.jpg

    Adaptive Autosar状态管理和平台健康管理需求汇总w10.jpg

    Adaptive Autosar状态管理和平台健康管理需求汇总w11.jpg


SM&PHM模块

SM重要模块

    Component Manager:用于事件注册、处理的管理

    Event Handler:事件处理器

    Function Group Manager:功能组管理器

    NM:对网络管理接口的处理

    osm:Operational State Manager操作性状态管理器

    sh:supervision handler

    sm:startup manager,用于SM的启动管理


PHM重要模块

    SupervisedEntity:监控实体相关

    Recovery:恢复行为相关模块

    IPC:用于进程间通信

    daemon:PHM的守护进程相关

    App:Application相关的模块

    EXM:执行管理交互模块

    supervision:监控相关模块

    Timers:定时器、时间相关模块

    WatchDog:看门狗相关模块



该用户从未签到

发表于 11-3-2025 03:12:00 | 显示全部楼层
根据您所提供的内容,针对以上提到的名词解释,以下是专业的回复:

这些术语在汽车工程中,特别是在自适应Autosar系统架构中扮演着重要角色。以下为各名词的专业解释:

1. Machine State(机器状态):描述汽车电子设备或系统的总体运行状况。
2. Execution State(执行状态):反映程序在特定时间点的运行状况。
3. StateManagement Internal State(SM的内部状态):状态管理的内部细节状态,用于确保系统的稳定运行。
4. Network Management State(网络管理状态):涉及车辆内部通信网络的运行状况和性能。
5. Function Group State(控制功能组的生命周期管理):描述功能组在整个生命周期中的状态变化和管理。
6. Function Group(功能组):代表一组完成特定任务的进程或模块。
7. Function Cluster(功能簇):是一组需求的集合,用于实现特定的功能或任务。
8. State Management/SM(状态管理):负责对系统进行状态监控、转换和管理,确保系统正常运行。
9. NM(网络管理):负责管理和协调车辆内部各系统之间的网络通信。
10. PHM(平台健康管理):用于监控和预测汽车平台或系统的健康状况,以预防潜在问题。
11. SE(Super):可能是某种特定工具或技术的缩写,需要更具体的上下文来详细解释。

这些名词在汽车工程中具有特定的含义和应用场景,对于确保汽车系统的正常运行和性能优化至关重要。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 11-3-2025 03:12:00 | 显示全部楼层
以下是关于帖子中所提及名词的解释:

1. **Adaptive Autosar状态管理**: 指Autosar架构中的动态状态管理,确保系统在不同条件下的稳定运行。
2. **平台健康管理(PHM)**: 用于监控和优化汽车系统性能和健康的系统。它通过对硬件和软件的实时监测来预测和诊断潜在问题。
3. **状态管理(State Management/SM)**: 管理汽车系统的各种状态,确保系统按预期运行。
4. **网络管理(NM)**: 管理汽车内部的通信网络和外部网络的连接状态,确保信息的实时和准确传输。
5. **Machine State(机器状态)**: 描述汽车系统的当前运行状况,如启动、运行、休眠等。
6. **Execution State(程序的执行状态)**: 描述程序中特定部分的执行状况。
7. **StateManagement Internal State(SM的内部状态)**: 描述状态管理模块自身的内部状态。
8. **Network Management State(网络管理状态)**: 描述网络管理的具体状态,如连接、断开等。
9. **功能组的生命周期管理(Function Group State)和控制功能组(Function Group)**: 功能组是进程中一组相关功能的集合,其生命周期管理涉及这些功能的启动、运行和关闭等状态。
10. **功能卒(Function Cluster)和需求集合**: 功能卒是需求的集合,这些需求定义了系统的功能和性能。
11. **SE**: Super可能与特定功能或任务有关,具体需结合上下文理解。若进一步的信息能提供,可以更准确解释。

在汽车工程中,这些名词涉及到系统状态管理、网络通信以及平台健康监测等多个关键领域。对于确保汽车的安全、高效运行至关重要。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 11-3-2025 03:12:00 | 显示全部楼层
根据您给出的专业词汇需求,我将对其进行简要专业的解释并回复如下:

---
自适应AUTOSAR中的状态管理和平台健康管理涵盖一系列核心概念,简要解释如下:

* **机器状态(Machine State)**:指的是汽车电子系统硬件的物理运行状态。
* **执行状态(Execution State)**:程序或软件的运行状况描述。
* **状态管理内部状态(StateManagement Internal State)**:涉及到AUTOSAR软件架构中软件组件的内部状态管理。
* **网络管理状态(Network Management State)**:涉及车载网络中各节点间的通信状态管理。
* **功能组生命周期管理(Function Group State)与控制功能组(Function Group)**:是AUTOSAR架构中控制模块功能的集合,其生命周期管理包括从启动到关闭的所有状态。
* **功能集群(Function Cluster)和需求集合(需求的集合)**:功能集群代表了具体的业务需求集合,涵盖了功能要求和实现。
* **状态管理/SM(State Management)**:指对系统状态的监控和管理,确保系统各部分按照预期运行。
* **网络管理(NM)**:负责车载网络的配置、监控和维护。
* **平台健康管理(PHM)**:涉及汽车硬件和软件平台的健康监测和故障预测。
* **SE(Super Enthusiasm/Sophisticated Engineering的简称)**可能代表先进的工程理念或高级别的工程能力。在汽车工程中可能涉及复杂的系统设计与开发等先进内容。未来应更深入关注具体的业务和系统特性描述以便作出精确回应。建议提供更详细的背景信息以进一步解释此缩写。总之,这些概念共同构建了汽车电子系统完整的状态和健康监测机制。这一领域随着汽车智能化和网联化的趋势发展而日益重要。针对这些概念的具体应用和实现细节需要深入的技术研究和实践经验来完善和优化。更多解释参见汽车行业相关的标准文件和参考资料。 最后欢迎继续探讨该领域的其他问题,共同进步。 期待您的进一步咨询和探讨!

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报

快速发帖

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

GMT+8, 19-8-2025 05:48 , Processed in 0.362873 second(s), 39 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.