AUTOSAR中的高速任务调度
AUTOSAR中的高速任务调度
Vector解决了AUTOSAR系统中高速应用任务的调度难题
现代化汽车内部的电气电子（E&E：Electrical and Electronic）功能在数量和复杂度上都增长了；这种新的复杂性驱使汽车制造商及其供应商，组建了AUTOSAR的合作伙伴关系，其目标是在车辆电子控制单元内，定义一个标准化但功能丰富的软件架构。一个常见的误解是，在AUTOSAR系统内不能调度高速应用任务。本文将介绍AUTOSAR操作系统中，用于处理应用程序调度要求的机制，以及怎样对操作系统进行成功的配置，使得软件工程师在AUTOSAR系统内能够继续运行高速任务调度。
AUTOSAR的驱动
近年来，车辆内的电气电子功能在数量和复杂度上都有成倍的增长。这一趋势受到了汽车行业内的众多因素的推动，其中包括基于电气电子的终端用户功能特性的需求增加、ADAS系统的出现和普及、以及对诊断电气电子系统故障和电子控制单元（ECU：Electronic Control Unit）失效越来越高的要求。
最新的汽车功能已经达到如此复杂的程度，使得传统的汽车ECU性能和供应商的开发方法，已经不能满足现代汽车对电气电子架构的要求。在2003年，这种日益增加复杂程度，驱使汽车制造商及其供应商，组建了开放系统架构（AUTOSAR：AUTomotive Open System ARchitecture）的开发伙伴关系；他们的共同目标是定义在车辆ECU内使用的通用和标准化的软件架构，将最终提供必要的软件特性、机制和支持，以满足车辆底层电气电子架构的更高要求。
在AUTOSAR被定义之前，车辆制造商对ECU嵌入式软件的主要关注点，往往局限于网络通信协议栈和诊断。但是通过AUTOSAR，ECU内部的底层软件已经经历了重大的扩展。
AUTOSAR“基础软件”不仅涵盖CAN、LIN、FlexRay、以太网和诊断协议等网络通信领域，现在还包括了系统和看门狗的初始化和状态处理、用于各种存储设备的非易失性存储的软件栈、微控制器外设的抽象驱动层以及操作系统（OS：Operating System）。
来自AUTOSAR“甜品店”增加的处理需求
AUTOSAR标准仍在不断发展和演进以满足最新的车辆电气电子要求——到2014年底，在AUTOSAR基础软件4.2版本发布时，达到了迄今为止最高的复杂程度。定义了超过90种可扩展的嵌入式软件模块，并提供强大的配置工具和代码生成器，以及一系列用于工作流、方法和数据交换格式的更高标准。
当ECU供应商选择在他们的ECU中装配AUTOSAR基础软件时，他们发现自己被提供了一系列功能丰富的作为现成的商品的嵌入式软件模块。冗长的软件开发交付时间，不再是决定是否在ECU中建立更多功能的制约因素，因为包含一个附加的AUTOSAR模块，变成简单的在基础软件配置中勾选一个复选框。软件架构师们发现自己就像是“甜品店里的孩子”，有超过90个软件模块可供挑选。
当然，这里每一个软件模块都有其自身的代价，不仅在用来补偿设计和创建每个模块的开发工作的许可费方面，而且还在处理器的负载方面。每个软件模块都将占用单片机内部珍贵的RAM和ROM资源，同时还有需要被调度和调用的函数，这些函数会耗费宝贵的处理器运行时开销。
AUTOSAR操作系统
特别的，AUTOSAR OS提供了很多的现阶段不存在，甚至未被ECU供应商考虑过的特性。在过去，一个简单的单时钟（single-tick）或超级循环（super-loop）调度程序，就可能足以承载所有的ECU应用程序任务。现在，通过兼容替代为AUTOSAR OS，一组新的操作系统特性，可供软件工程师们立即使用了。
- AUTOSAR OS可扩展性Class 1扩展了OSEK / VDX标准，并增加了调度表
- OS可扩展性Class 2扩展了AUTOSAR OS SC1，增加了时序保护功能
- OS可扩展性Class 3扩展了AUTOSAR OS SC1，增加了内存保护功能
- OS可扩展性Class 4扩展了AUTOSAR OS SC1，并增加了时序和内存保护功能
图1：AUTOSAR OS可扩展性类别
在AUTOSAR操作系统中增加的特性并不是没有带来资源损耗，就像AUTOSAR基础软件中的其他所有模块一样，增加的特性需要微控制器内更多的RAM和ROM资源，同时消耗更多的处理器运行时间开销。这些额外的要求通常需要以更高的ECU处理能力和更大的微控制器内存容量来支持。
随后出现的一个常见的误解是采用AUTOSAR软件架构，将自动要求ECU供应商将内部的微控制器，从16位处理器升级到32位。当然，这不应该是自然的结论，因为采用AUTOSAR OS SC1替换现有的OSEK OS只会产生很小的额外开销，并且还是在启用调度表特性的情况下。
然而，软件工程师现在有了升级操作系统的选项，以同时或分别包含时序和内存保护功能，只需要在请求的基础软件配置中进行简单的选择。与开发这些功能相关的交付时间不再是一种障碍，甚至不再是一种考虑因素，因为操作系统是作为商用现货（COTS：Commercial Off-The-Shelf）组件提供的。
如果所有的AUTOSAR 基础软件模块都以类似的方式处理，那么包含所有新的AUTOSAR功能，在技术上可能会变得微不足道，然而，对处理器负载和内存需求的显著而明显的影响也会立即被观察到。
调度高速应用程序任务
就像有AUTOSAR软件体系结构本来就需要32位处理器的误解一样，也会出现类似的，高速应用程序任务无法在AUTOSAR系统中进行调度的误解。许多典型的汽车应用，特别是在动力总成领域内，需要能够以每100微秒（10 kHz）甚至更快的速率运行的任务。这种具有挑战性的调度需求，对AUTOSAR OS提出了非常高的要求，进而对微控制器的处理负载也提出了要求。
- Cat1中断是AUTOSAR OS所“不支持”的。这意味着安全地进出中断处理程序的代码，不是由AUTOSAR OS生成的，必须以其他方式生成。[1]
- Cat2中断由OS支持的。这意味着OS的代码生成器和库可以以可移植的方式，从硬件中抽象出中断。[1]
Cat2中断被普遍的用于调度基础软件和应用程序级的软件组件的所有任务，当AUTOSAR模块被指定为使用AUTOSAR OS和应用程序编程接口（API：Application Programming Interface）。如果应用程序有特定的高速任务调度要求，软件工程师可以利用AUTOSAR Cat1中断，并使用配置工具将应用程序任务直接挂接到微控制器的中断表中。Cat1中断对于AUTOSAR系统的其余部分基本上是“不可见的”。
Cat1中断提供了一种强大的方式来直接与硬件交互，因此在使用这种中断时必须万分小心和谨慎；其主要优点是中断的延迟非常低，因此可以实现所需的高速任务调度。因为没有AUTOSAR OS提供的正常保护，所以Cat1中断与系统其余部分之间的交互，必须在实施之前经过仔细的考虑。
另一个需要考虑的方面是整个系统的中断优先级的分配。AUTOSAR OS是一个完全的抢占式操作系统，因此AUTOSAR应用程序任务可能会相互中断。不过，允许AUTOSAR任务中断或阻塞高速调度任务是不可接受的，因此需要分配优先级以使得高速任务在系统中具有最高的优先级。
这意味着高速任务可以中断系统中的其他任务，包括AUTOSAR OS，并且AUTOSAR系统中的所有其他的中断，都必须至少比高速任务的优先级低一个优先级，这被称为“系统中断等级”。
图2：AUTOSAR系统内的高速任务调度举例
结论
AUTOSAR标准已经达到了新的高度，但将继续增长和发展，以满足当今最新的汽车E&E要求。对于ECU软件开发人员来说，拥抱AUTOSAR，除了增强了其应用程序功能，往往被认为只是经常带来的进一步的负担。因而通常只在车辆制造商的要求的情况下进行。AUTOSAR架构在动力总成领域的扩张速度比其他领域（如车身和底盘应用）要慢得多，除了所有新的AUTOSAR特性之外，还有一个原因是处理高速任务调度的需求。
然而，AUTOSAR标准已经考虑和解决了处理这些需求的机制，许多AUTOSAR应用程序正在使用OS Cat1中断，成功的运行高速任务调度。通过分析这些系统中的处理器负载，Vector观察到，在许多情况下，仍然可以在实现高速任务调度的同时，运行功能丰富的AUTOSAR基础软件。
但不可避免的，AUTOSAR基础软件和AUTOSAR OS中提供的附加功能，将带来进一步的处理器需求，因此嵌入式软件市场中出现了新的差异化因素。在购买AUTOSAR基础软件作为现成的商品部件时，必须考虑每个新的AUTOSAR模块的可扩展性、可配置性、效率和优化。
是否采用AUTOSAR，仍然是许多ECU供应商的顾虑，这种顾虑还经常由于其可能带来的复杂性而被加强。但是复杂性已经存在于系统内部，来自最终客户的功能需求和支持这些功能所必须的基础E&E架构。AUTOSAR只提供必要的机制和结构，来管理已经存在的复杂性；因此不应将AUTOSAR系统视为一个问题，反而是它提供了问题的解决方案。
图像提供方：Vector Informatik GmbH / Vector GB Ltd.
文献：
[1] Explanation of Interrupt Handling in AUTOSAR, sourced from www.autosar.org on 09/07/2015:www.autosar.org/fileadmin/files/releases/3-2/software-architecture/general/auxiliary/AUTOSAR_InterruptHandling_Explanation.pdf
作者：
Steve Waldron, Vector GB Ltd.
嵌入式软件产品线的本地产品线经理
Tom Dalek, Vector GB Ltd.
嵌入式软件工程师
Alex Ghinet, Vector GB Ltd.
高级嵌入式软件工程师