在 AUTOSAR Adaptive Platform（AP）中，同一个机器上可以同时运行多个功能组（Function Groups），即使是在单核CPU环境下。其调度机制与进程调度既相似又存在关键差异，具体实现如下：
功能组并行运行原理
graph TBOS[Linux/Adaptive OS] -->|调度| EM[执行管理EM]EM -->|进程控制| FG1[功能组A]EM -->|进程控制| FG2[功能组B]EM -->|进程控制| FG3[功能组C]subgraph FG1P1[进程1] -->|状态机| SM1[SM库]endsubgraph FG2P2[进程2] --> LT[LT库]endsubgraph FG3P3[进程3] -->|业务逻辑| Append
- 功能组本质：逻辑进程集合（非物理隔离）
- 并行基础：多个功能组的进程可在同一OS中并发运行
单核CPU下的调度机制
1. 层级化调度架构
- 第一层：OS调度器
基于标准Linux调度策略（如CFS）分配CPU时间片给所有进程 - 第二层：EM调度器
执行管理（EM）通过功能组状态控制进程启停
2. 关键调度策略对比
| 维度 | 传统进程调度 | AP功能组调度 |
|---|---|---|
| 调度单位 | 进程/线程 | 功能组状态约束下的进程 |
| 决策依据 | CPU优先级/时间片 | 功能组状态 + 进程依赖关系 |
| 启停控制 | OS直接管理 | EM按FG状态启停进程 |
| 实时性保障 | 依赖PREEMPT_RT补丁 | 通过ARA::OSAL抽象层实现确定性响应 |
3. 单核调度流程示例
功能组状态对调度的核心影响
1. 状态驱动的进程启停
| 功能组状态 | 进程控制规则 | 单核CPU资源分配效果 |
|---|---|---|
| Running | 启动所有关联进程 | 进程参与OS时间片竞争 |
| Standby | 仅保留监控进程 | 仅占用≤2% CPU |
| Off | 终止所有进程 | 释放100% CPU |
2. 状态切换的调度影响
// EM内部状态处理伪代码
void HandleFGStateChange(FG_ID id, State new_state) {// 1. 停止不符合新状态的进程foreach (Process p in GetProcesses(id)) {if (!IsAllowedInState(p, new_state)) {StopProcess(p); // 发送SIGTERM}}// 2. 启动需要运行的进程foreach (Process p in GetStartList(id, new_state)) {if (!IsRunning(p)) StartProcess(p); // 通过fork/exec}// 3. 更新进程调度参数ApplySchedulingPolicy(id, new_state); // 调整优先级/亲和性
}
单核环境下的优化技术
1. 进程优先级分层
- 通过
sched_setscheduler()设置 SCHED_FIFO 优先级 - 示例：
PHM监控进程>刹车控制进程>信息娱乐进程
2. 状态感知的CPU节流
# EM的CPU调控逻辑
def adjust_cpu_usage(current_state):if current_state == "Emergency":set_cpu_boost(True) # 关闭节能模式elif current_state == "Standby":set_cpu_freq(600MHz) # 降频节电
3. 进程组调度（Cgroups）
# 为每个功能组创建cgroup
cgcreate -g cpu:/FG_Powertrain
echo 200000 > /sys/fs/cgroup/FG_Powertrain/cpu.rt_period_us
echo 50000 > /sys/fs/cgroup/FG_Powertrain/cpu.rt_runtime_us
与进程调度的本质区别
| 特性 | 传统进程调度 | AP功能组调度 |
|---|---|---|
| 控制目标 | 最大化CPU利用率 | 满足功能组状态约束 |
| 启停时机 | 进程主动创建/退出 | EM按FG状态强制启停 |
| 依赖管理 | 无内置依赖解析 | 跨进程依赖图处理 |
| 实时性保障 | 依赖OS实时扩展 | 通过ARA::OSAL抽象硬实时 |
📌 关键结论：
功能组调度是在进程调度之上添加的状态感知层，通过EM作为“智能调度中介”，将功能组状态语义转化为具体的进程启停和资源分配策略。
典型单核调度场景：车辆启动过程
gantttitle 单核CPU时间线（单位：ms）dateFormat XaxisFormat %Lsection 功能组状态Bootloader ： 0, 50EM启动 ： 50, 80PowerTrain_Running ： 80, 200Cockpit_Standby ： 100, 200section 进程CPU占用内核初始化 ： 0, 50EM进程 ： 50, 200EngineCtrl进程 ： 80, 200 : 30%DisplayCtrl进程 ： 100, 120 : 5% (启动后休眠)
- 0-50ms：Bootloader运行（独占CPU）
- 50ms：EM启动，检测FG状态
- 80ms：激活PowerTrain组Running状态 → 启动引擎控制进程（占30% CPU）
- 100ms：激活Cockpit组Standby状态 → 短暂启动显示进程后休眠
此时单核CPU总利用率：
EM(15%) + EngineCtrl(30%) + DisplayCtrl(5%) = 50%
剩余50% CPU用于其他后台任务
总结
- 功能组可并行运行：通过进程并发实现，与CPU核心数无关
- 单核调度本质：
- OS层：标准Linux调度器分配时间片
- EM层：按功能组状态启停进程 + 调整调度参数
- 关键优势：
- 状态驱动调度：
Running状态进程获资源，Standby状态进程休眠 - 安全隔离：关键进程可设置高优先级（SCHED_FIFO）
- 资源优化：通过状态切换动态调节CPU占用
- 状态驱动调度：
最终实现效果：即使在单核ARM Cortex-A53（800MHz）上，AP平台也能同时管理10+功能组，确保刹车控制（50Hz实时任务）与导航系统（非实时任务）协同运行，满足ASIL-B安全要求。
——前世今生)
