基于AUTOSAR 操作系统的任务搭建及验证

卫军，吴长水

（201620 上海市 上海工程技术大学）

0 引言

汽车开放系统架构（AUTOSAR）出现的目的是降低汽车软件开发成本，如今，此架构已运行在欧洲大多数汽车的软件上。AUTOSAR 是用于汽车软件开发的标准化软件平台。图1 所示的AUTOSAR 架构有4 层基本架构，分别为应用软件层、运行时环境、基础软件层和微控制器层，每一层通常都包含数十个用于各种功能的模块。操作系统在这些AUTOSAR 模块中起着至关重要的作用。AUTOSAR 操作系统是一种基于优先级的实时操作系统（RTOS），它是其他所有AUTOSAR 软件模块和应用程序的基石[1]。此外，它还支持内存保护和定时保护等功能安全机制。由于汽车软件运行需要高度的可靠性和安全性，因此汽车软件上运行的AUTOSAR OS 的测试是非常重要的工作。通常情况下，OS 会在运行中不停地进行上下文切换和中断处理，所以针对RTOS 展开的测试很困难。

图1 AUTOSAR 架构示意图Fig.1 AUTOSAR architecture schematic

AUTOSAR 操作系统规范针对具有硬实时性的深度嵌入式系统约束。在此类系统中，任何可能与系统实时需求冲突的不确定行为都不允许出现。因此，AUTOSAR 规范将AUTOSAR OS 定义为静态操作系统，这意味着系统对象不允许动态创建系统布局，也就是说包括每个单独的OS 对象与其运行机制必须在系统启动运行之前都确定[2]。

本文的AUTOSAR 架构下实时操作系统的验证工作是围绕多核微处理器AURIX TC277 平台展开的，该微控制器由英飞凌公司开发，主要用于汽车和工业控制系统。

1 EB 公司AutoCore 工具简介

AutoCore 是EB 公司推出的针对车用ECU 的、符合AUTOSAR 架构的软件实现工具。该软件提供了用于在多总线网络环境（包括FlexRay，CAN 和LIN）中运行复杂控制策略的基础架构。这些模块已开发出许多用于汽车微控制器（通过与半导体供应商合作）的高质量车用软件代码，并在多个目标系统上进行了充分地测试。

EB AutoCore 适合各种汽车软件应用场合，通常是同时进行多个项目或高度重视软件重用的项目，例如车身、底盘和动力总成领域等，需要CAN，LIN 和网关功能的ECU 软件的开发，以及符合AUTOSAR 标准的软件的项目。EB AutoCore提供了高度完整的AUTOSAR 标准核心、高质量和高成熟度的功能静态代码代码、操作系统（OS）、错误处理和模式管理功能，而且具有可靠的AUTOSAR 运行时环境（RTE），以及符合ASPICE 标准的开发流程[3]。该工具同时适用于主流硬件供应商的16 位和32 位处理器,例如NXP、英飞凌、瑞萨和意法半导体等。

2 OS 任务搭建

通常上电后，AURIX TriCore 从0xa0000020地址开始执行启动代码。使用汇编语言编写的启动代码会禁用中断，并调用特殊的C 语言循环OS_InitSp()和OS_InitCsaList()来初始化堆栈指针，在完成这一步之前芯片无法调用普通的C 函数。最后，代码跳转至BoardStart()函数。C 语言函数BoardStart()负责用于设置CPU 时钟频率和数个核心特殊功能寄存器，尤其是ISP（中断堆栈指针）寄存器必须设置为正确的工作值。最后，BoardStart()函数调用main()函数。main()函数必须由用户自行编写，所有用于特定系统的初始化的过程在main()中完成，尤其应保证所有可产生中断的外围模块必须在main()中将其控制寄存器设置为工作值，否则 AutoCore OS 无法初始化中断服务而导致OS 对象后续工作异常[4]。

在多核系统中，由AutoCore OS 管理的其他核使用StartCore()系统服务函数进行核的启动，之后依次开始执行各自的main()函数。然后，应用程序调用系统服务StartOS()，该服务将启动AutoCore OS 内核，在正常情况下，将进入系统工作循环且不退出。自启动任务和OS 警报启动后，硬件计时器和中断服务请求寄存器被初始化，应用程序.data 和.bss 初始化区域，并用填充值（通常为0xeb）填充所有堆栈。最后，调用StartupHook 函数（如果已配置，否则跳过）。当StartOS()完成时，将运行优先级最高的活动任务。

至此，AutoCore OS 完成启动（如图2 所示），配置好的OS 对象将依次开始工作。

图2 多核操作系统启动流程示意Fig.2 Multi-core operating system startup process diagram

如图3 所示，本文为验证OS 功能，设置了以下OS 对象：

图3 构建的验证OS Task 示意图Fig.3 Schematic diagram of built verification OS Task

（1）5 个任务：初始化任务、1 个Loop 循环、1 个Cyclic 循环、Task_St1、Task_St2；

（2）2 个OS 警报：AlarmActCyclic 和SysCounterIncrementer；

（3）1 个软件计数器；

（4）1 个硬件计数器；

（5）1 个调度表；

（6）1 个OS 资源Res_CounterVar；

（7）以上所有对象都分配到的2 个应用程序APP1 和APP2。

自启动任务InitTask 激活Cyclic 警报AlarmActCyclic 并切换到Loop 循环任务。此任务执行一个无穷循环，该循环连续获取并释放资源Res_CounterVar。自启动的OS 警报SysCounterIncrementer 使软件计数器递增，该计数器与OS 警报AlarmActCyclic 相连。

在AlarmActCyclic 出现OS 警报事件时，将激活Cyclic 任务，其优先级为高于Loop 循环任务的优先级。Cyclic 循环激活后，Res_CounterVar资源不再被占用时，Loop 循环任务将被中断，Cyclic 任务循环开始运行。

在Cyclic 循环任务中，特定的输出模块将输出累加的一个变量用于观测，且连接配置到评估板LED 灯用于观测验证。计数器的时间单位具有固定大小，以便每秒激活一次Cyclic 循环任务。与上述行为并行地，OS 启动调度表。此任务表有两个溢出点，分别对应任务Task_St1 和Task_St2。两项任务均已配置具有比Loop 任务更高的优先级，因此，Loop 任务将一再被中断。

为方便观测OS 实际运行情况，这里设置了多个观测LED 灯。4 个LED 指示灯用于在循环任务中观测递增的计数变量的值。第5 个LED指示是否已使用资源Res_CounterVar。以上配置的OS 程序如果可以正常运行，则计数器LED 指示灯按规律递增闪烁，而占用资源指示LED 灯也将按一定周期闪烁。

3 集成编译以及下载观测

配置完成OS 模块的任务和必要设置之后，在AutoCore 界面点击生成按钮，排除错误和警告后，再点击Build，整个工程将会生成配置文件[5]，存放于如图4 所示的指定文件夹内。这些配置文件包括了标准的.c 文件和.h 文件，我们在AutoCore 中完成的各项设置将以C 代码的形式蕴含在这些配置文件内。下一步将进行集成编译工作。

图4 Build 生成的配置文件Fig.4 Configuration file generated by Build

集成编译的目的是将应用层代码、配置生成文件以及AutoCore 提供的静态代码（例如OS krenel 以及各模块的基础源码）按照一定的编译规则集中编译，历经预编译、编译、汇编和链接等过程后，生成可执行文件。由于AUTOSAR 规定了3 种不同的配置参数编译方式，分为预编译配置参数、链接时配置参数和编译后配置参数，因此编译规则的制定应当提前考量这3 种参数的存在[6]。AutoCore 已经根据用户配置，制定好了不同的集中编译的规则，完成配置后直接按照EB 推荐的编译方式，使用命令行调用编译器执行编译命令即可。这里使用了HighTec 提供的GCC 编译器进行编译。

在没有配置冲突和用户代码不合理的情况下，编译将顺利生成elf 文件。

之后，将elf 文件在Tasking 中构建可执行文件工程，基于这个过程，通过与TC277 开发板连接进行调试和观测工作。图5 为正在运行OS 任务的开发板。

图5 开发板连接与LED 灯展示Fig.5 Development board connected with LED light display

点击烧写按钮，.elf 文件将烧写进入开发板，Tasking 界面进入调试页面，点击开始运行。此时可以观测LED 灯和环境变量task_St1_counter、task_St2_counter 的值来检测OS 的任务是否按照预期在执行。

首先，使用断点检查循环任务是否运行，在loop 内打断点，观测得到程序停在断点处。则证明OS 运行正常；再检查cyclic_counters 计数器的值，发现该变量每秒增加1 次；再观测变量task_St1_counter 和task_St2_counter 的 值。由 于二者构建在同一调度表中，且后者周期是前者的两倍，在观测窗口观测到二者始终在递增且前者的值为后者的2 倍，说明程序按照期望运行；观察LED 灯的状态，前4 个LED 在按各自设定的周期翻转闪烁，第5 个代表资源Res_CounterVar占用的LED 指示灯也按照逻辑关系周期闪烁。

4 结论

基于EB 公司提供的AUTOCORE 工具，主要验证其OS 模块的基本功能，完成了ACG 7 版本的完整配置流程：从可用模块的导入，到主要模块的配置和排错，再到应用层代码的适配、配置文件的生成以及调用目标编译器（使用了GCC和Tasking 两种编译器）进行集成编译、生成可执行文件并通过IDE 下载到评估板。经验证，EB 提供的ACG7 OS 模块完整、可靠，运行稳定。