Adaptive Autosar执行管理需求汇总

myhomer

前言

执行管理是AP的一个功能组件，负责平台初始化和应用的启动、停止，它基于一个或者多个manifest文件执行上述动作，比如说可执行程序何时启动以及在哪启动。

执行管理本意是代替Linux系统中的init进程或者systemd相关功能，是系统起来之后用户空间的第一个进程。

实际上，无论是开源的AP代码、商业版本的AP代码或者自研的AP代码，很少看到执行管理作为用户空间第一个进程存在而设计。

EM/执行管理是Adaptive Autosar基础的三大模块之一，这三个模块高内聚高耦合。我们先盘点一下执行管理模块的相关需求。

名词解释

EM:执行管理

Modelled Process:和描述文件有关联的进程

Reporting Process：向EM报告状态的进程

Non-Reporting Process:不期望向EM报告状态的进程

Companion Process:由于Non-Reporting Process不报告状态，但是其它程序依赖这个程序，因此采用companion process代替Non-reporting Process报告状态

Self-Terminating Process:运行程序自行终止并且退出码为Success的进程

Unexpected Termination:退出码不是Success

Execution Dependency：程序退出或者启动的依赖。（特指顺序依赖）

Deterministic Execution Client：确定性执行管理客户端

AP标准下的执行管理需求汇总

程序（组）属性相关需求

优先级、权限相关设置

调度相关策略

资源分配相关属性：RAM、CPU使用率、工作文件夹、内存资源监控

程序ID

无子进程

程序入参、环境变量

一个进程属于一个进程组

程序启动停止相关需求

同一个实例可多次启动

实例在启动前进行完整性和授权性校验

程序应按顺序启动

程序应按顺序退出

支持程序重启

执行管理接口相关需求

退出时应通知其他程序状态变更

报告自身的资源消耗

报告自身的程序状态（初始化、运行、关闭）

执行管理调度策略相关需求

外部触发运行（周期性触发或者事件触发）

周期性运行

确定性冗余执行（软件锁步）

时间触发运行

执行管理错误处理相关需求

异常退出时记录日志，设置进程组状态

AP EM内部模块一览

执行管理内部需要和状态管理等其他AP模块联动，此外由于QNX和Linux的系统差异，需要对不同的操作系统平台进行功能抽象。相关的内部模块如下：

Application Launcher\Worker

Execution Manager

Machine State Manager

Process State Client

Process State Notifier

State Client

Execution Client

Config Loader

Function Group Manager

Function Group accessor

Function Group channel

Function Group client

Function Group Controller

AraLog

Printf Log

System Log

Platform 抽象

执行管理相关模块需要解析配置，完成功能组的关联、程序状态的控制，对外需要连接各种State Manager、控制Machine的各种配置。相关的信息需要日志存储，由于不同的开发阶段有不同的需求体现，因此执行管理配置了多个日志功能。

部分系统/库函数调用一览

如果想自己实现一套执行管理的功能，并且可以在不同的平台下均可正常运行。那么，系统调用必须清楚。下面让我们看一下QNX和Linux平台下的部分系统调用。

QNX平台部分系统/库函数调用

chdir

getcwd

posix_spawnattr_init

posix_spawnattr_getxflags

posix_spawnattr_setxflags

posix_spawnattr_setrunmask

posix_spawnattr_setcred

posix_spawnattr_settypeid

posix_spawnattr_setschedparam

posix_spawnattr_setschedpolicy

posix_spawnattr_setpgroup

posix_spawn

posix_spawn_file_actions_destroy

posix_spawn_file_actions_init

posix_spawn_file_actions_addclose

sched_getscheduler

sched_getparam

setrlimit

getrlimit

schedctl

APS_INIT_DATA

pthread_attr_init

pthread_attr_create

pthread_attr_destroy

pthread_attr_setnamenp

pthread_join

Linux平台部分系统/库函数调用

setgid

setuid

setpgid

sched_getaffinity

sched_setaffinity

chdir

execv函数族

access

fork

setrlimit

从上述两个平台的接口可知，这两个平台的接口还是有部分不兼容的，虽然同是POSIX平台，但是不是完全使用的标准POSIX接口。

因此，在研发阶段，一定对平台相关的接口进行抽象，以便于实现跨平台。

loohoolinda

关于Adaptive Autosar执行管理需求汇总的前言：

执行管理作为Adaptive Autosar平台的重要组成部分，肩负着平台初始化和应用启动、停止的关键任务。此功能基于manifest文件，精细控制应用的行为，如启动时序和位置。

执行管理在设计理念上类似于Linux系统中的init进程或systemd功能，作为系统启动后的首个用户空间进程，担负着系统资源管理和调度的核心职责。然而，在实际应用中，无论是开源、商业还是自研的AP代码，执行管理并不常作为用户空间第一个进程存在。

考虑到执行管理模块（EM）与Adaptive Autosar其他基础模块的高内聚高耦合特性，我们需要详细梳理和汇总执行管理模块的相关需求。

接下来，我将对执行管理的相关名词进行解释和阐述，以便我们更深入地理解和讨论其需求和功能。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

zy_wawj

关于Adaptive Autosar执行管理需求汇总

执行管理作为AP的核心组件，主要职能在于平台的初始化和应用的启动、停止。此管理基于manifest文件，精准控制应用的启动顺序、位置及时机。其设计理念在于替代传统Linux系统中的init进程或systemd功能，成为系统启动后的首个用户空间进程。

尽管执行管理在理论上有此定位，但在实际中，无论是开源、商业还是自研的AP代码，执行管理并不常作为用户空间的首个进程。考虑到EM与执行管理是Adaptive Autosar的三大核心模块之一，且这些模块间存在高内聚高耦合的特性，现对执行管理模块的需求进行如下汇总：

1. 需求描述：执行管理需要实现精准的平台初始化及应用的启动、停止控制。
2. 需求依据：基于manifest文件，实现应用的启动顺序、位置及时机的控制。
3. 特别说明：需考虑与其他模块的协同工作，确保系统整体的稳定性和效率。

后续我们将详细梳理并讨论这些需求的具体实现方式和可能遇到的问题。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]