分配策略_基于AUTOSAR的任务分配策略

随着汽车电子应用程序对处理器性能需求的不断提高,现代汽车电子系统中的电子控制单元(ECU)已升级为多核结构.

多核结构处理器

在系统级设计中,汽车电子应用程序由若干构件(SWC)组成. 每个构件实现了应用程序的某一特定功能. 若干构件通过相互协作共同实现应用程序的具体行为. 然而,在ECU设计中, 操作系统调度的对象却是任务(Task). 因此,在进行ECU配置时,须将构件内的可运行实体(Runnable entity)映射到具体任务中,以供操作系统调度执行,这个过程被称为"可运行实体到任务的映射"。

一种较为简单的映射方法是将每个可运行实体单独封装为一个任务, 简称方法１。 但是如此大量的任务会使得系统被频繁调度,增加系统的调度开销。

另一种较为实用的方法是将拥有相同周期的可运行实体映射为一个任务,简称方法２。然而,该方法忽略了可运行实体之间的依赖关系和数据通信,且缺乏在映射过程中对任务实时性的分析。在实际中,可运行实体到任务映射主要根据AUTOSAR标准中关于任务生成的规范,依靠软件工程师的丰富经验来手动完成. 目前的自动映射方法(如方法１和方法２)还不能很好地满足汽车电子系统对实时性的需求。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

有没有更优化更有效的方法来分配任务呢？思考研究一下:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

在AUTOSAR架构中, 汽车电子应用软件由构件(Software Component)组成. 构件的具体行为依靠可运行实体以及可运行实体之间的相互协作来实现. 通常情况下, 一个构件包含一个或多个可运行实体(Runnable Entity). 可运行实体是一段用于实现一个简单算法或某一特定功能的程序代码.

可运行实体之间的通信一般分为构件内部的通信和构件之间的通信. 位于同一构件的可运行实体可以共享构件内部的变量, 而位于不同构件之间的可运行实体则只能通过端口通信. 一般而言, 每个构件存在若干个端口(Port), 这些端口或用于数据通信, 或用于功能调用. 用于发送数据或提供服务的端口被称为P-Port,而用于接收数据或请求服务的端口被称为R-Port.

构件之间的通信关系

上图中有两个SWCs, c1 and c2. c1里面有3个runnables, c2里面有3个runables. 其中a和b分别为构件c1和c2的内部变量, r1和r2共享数据a, r4和r5共享数据b.

再举个ACC自动巡航的例子：

ACC: 自动巡航系统 Automotive adaptive cruise control system

汽车电子巡航控制系统主要由６个构件组成, 分别为传感器数据收集、目标对象选择、自由巡航控制、跟踪控制与加速仲裁、巡航控制与ACC状态机以及巡航控制和ACC车辆观测器. 根据这６个构件的功能和通信拓扑结构构建了39个可运行实体、3个触发关系、7个构件间的数据通信和23个构件内的共享数据,如上所示。

接下来就是正题了，如何把这些runnables分配到具体处理器可以调度的task里面去呢？

RTE触发事件呈现出周期性,但由于任务抢占、任务阻塞等原因而有着明显的抖动.因此,由这些RTE事件所触发的可运行实体也存在着明显的抖动, 即抖动会从以上一个可运行实体传递到下一个运行实体.

可运行实体的执行顺序

很容易理解：将不同周期的可运行实体映射到一个任务内,将会使任务被频繁调度.

a是正常触发执行，b为被阻塞后，会明显存在抖动现象。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

我们的目标是：

1. 减少抖动时间
2. 减少阻塞时间
3. 减少调度频繁度
4. 减少数据通信量

对于目标1

具有触发关系的任务将会被合并到一个任务中,从而消除触发调用带来的任务抖动。

对于目标2

将两个存在共享变量的可运行实体映射到一个任务中,那么这个共享变量就成为了任务的内部变量. 在任务内部,可运行实体顺序执行,从而避免了阻塞。

对于目标3

一般而言,顺序触发的可运行实体都具有相同的周期. 将其映射到一个任务之后,任务的周期不变. 在任务每一次调度中都会将其中的可运行实体顺序执行一遍, 而非单独调度每个可运行实体,从而减少了系统调度的频率.

对于目标4

如果可运行实体之间的数据通信在任务内部进行,那么系统的通信开销将会减少.

当然也可以数学建模，通过IPL(整数线性规划)来自动优化分配策略，过程比较数学，这里就不展开了，有兴趣的可以自己搜索相关论文来了解学习。