衛(wèi)軍，吳長水

（201620 上海市 上海工程技術(shù)大學(xué)）

0 引言

汽車開放系統(tǒng)架構(gòu)（AUTOSAR）出現(xiàn)的目的是降低汽車軟件開發(fā)成本，如今，此架構(gòu)已運行在歐洲大多數(shù)汽車的軟件上。AUTOSAR 是用于汽車軟件開發(fā)的標(biāo)準(zhǔn)化軟件平臺。圖1 所示的AUTOSAR 架構(gòu)有4 層基本架構(gòu)，分別為應(yīng)用軟件層、運行時環(huán)境、基礎(chǔ)軟件層和微控制器層，每一層通常都包含數(shù)十個用于各種功能的模塊。操作系統(tǒng)在這些AUTOSAR 模塊中起著至關(guān)重要的作用。AUTOSAR 操作系統(tǒng)是一種基于優(yōu)先級的實時操作系統(tǒng)（RTOS），它是其他所有AUTOSAR 軟件模塊和應(yīng)用程序的基石[1]。此外，它還支持內(nèi)存保護和定時保護等功能安全機制。由于汽車軟件運行需要高度的可靠性和安全性，因此汽車軟件上運行的AUTOSAR OS 的測試是非常重要的工作。通常情況下，OS 會在運行中不停地進行上下文切換和中斷處理，所以針對RTOS 展開的測試很困難。

圖1 AUTOSAR 架構(gòu)示意圖Fig.1 AUTOSAR architecture schematic

AUTOSAR 操作系統(tǒng)規(guī)范針對具有硬實時性的深度嵌入式系統(tǒng)約束。在此類系統(tǒng)中，任何可能與系統(tǒng)實時需求沖突的不確定行為都不允許出現(xiàn)。因此，AUTOSAR 規(guī)范將AUTOSAR OS 定義為靜態(tài)操作系統(tǒng)，這意味著系統(tǒng)對象不允許動態(tài)創(chuàng)建系統(tǒng)布局，也就是說包括每個單獨的OS 對象與其運行機制必須在系統(tǒng)啟動運行之前都確定[2]。

本文的AUTOSAR 架構(gòu)下實時操作系統(tǒng)的驗證工作是圍繞多核微處理器AURIX TC277 平臺展開的，該微控制器由英飛凌公司開發(fā)，主要用于汽車和工業(yè)控制系統(tǒng)。

1 EB 公司AutoCore 工具簡介

AutoCore 是EB 公司推出的針對車用ECU 的、符合AUTOSAR 架構(gòu)的軟件實現(xiàn)工具。該軟件提供了用于在多總線網(wǎng)絡(luò)環(huán)境（包括FlexRay，CAN 和LIN）中運行復(fù)雜控制策略的基礎(chǔ)架構(gòu)。這些模塊已開發(fā)出許多用于汽車微控制器（通過與半導(dǎo)體供應(yīng)商合作）的高質(zhì)量車用軟件代碼，并在多個目標(biāo)系統(tǒng)上進行了充分地測試。

EB AutoCore 適合各種汽車軟件應(yīng)用場合，通常是同時進行多個項目或高度重視軟件重用的項目，例如車身、底盤和動力總成領(lǐng)域等，需要CAN，LIN 和網(wǎng)關(guān)功能的ECU 軟件的開發(fā)，以及符合AUTOSAR 標(biāo)準(zhǔn)的軟件的項目。EB AutoCore提供了高度完整的AUTOSAR 標(biāo)準(zhǔn)核心、高質(zhì)量和高成熟度的功能靜態(tài)代碼代碼、操作系統(tǒng)（OS）、錯誤處理和模式管理功能，而且具有可靠的AUTOSAR 運行時環(huán)境（RTE），以及符合ASPICE 標(biāo)準(zhǔn)的開發(fā)流程[3]。該工具同時適用于主流硬件供應(yīng)商的16 位和32 位處理器,例如NXP、英飛凌、瑞薩和意法半導(dǎo)體等。

2 OS 任務(wù)搭建

通常上電后，AURIX TriCore 從0xa0000020地址開始執(zhí)行啟動代碼。使用匯編語言編寫的啟動代碼會禁用中斷，并調(diào)用特殊的C 語言循環(huán)OS_InitSp()和OS_InitCsaList()來初始化堆棧指針，在完成這一步之前芯片無法調(diào)用普通的C 函數(shù)。最后，代碼跳轉(zhuǎn)至BoardStart()函數(shù)。C 語言函數(shù)BoardStart()負(fù)責(zé)用于設(shè)置CPU 時鐘頻率和數(shù)個核心特殊功能寄存器，尤其是ISP（中斷堆棧指針）寄存器必須設(shè)置為正確的工作值。最后，BoardStart()函數(shù)調(diào)用main()函數(shù)。main()函數(shù)必須由用戶自行編寫，所有用于特定系統(tǒng)的初始化的過程在main()中完成，尤其應(yīng)保證所有可產(chǎn)生中斷的外圍模塊必須在main()中將其控制寄存器設(shè)置為工作值，否則 AutoCore OS 無法初始化中斷服務(wù)而導(dǎo)致OS 對象后續(xù)工作異常[4]。

在多核系統(tǒng)中，由AutoCore OS 管理的其他核使用StartCore()系統(tǒng)服務(wù)函數(shù)進行核的啟動，之后依次開始執(zhí)行各自的main()函數(shù)。然后，應(yīng)用程序調(diào)用系統(tǒng)服務(wù)StartOS()，該服務(wù)將啟動AutoCore OS 內(nèi)核，在正常情況下，將進入系統(tǒng)工作循環(huán)且不退出。自啟動任務(wù)和OS 警報啟動后，硬件計時器和中斷服務(wù)請求寄存器被初始化，應(yīng)用程序.data 和.bss 初始化區(qū)域，并用填充值（通常為0xeb）填充所有堆棧。最后，調(diào)用StartupHook 函數(shù)（如果已配置，否則跳過）。當(dāng)StartOS()完成時，將運行優(yōu)先級最高的活動任務(wù)。

至此，AutoCore OS 完成啟動（如圖2 所示），配置好的OS 對象將依次開始工作。

圖2 多核操作系統(tǒng)啟動流程示意Fig.2 Multi-core operating system startup process diagram

如圖3 所示，本文為驗證OS 功能，設(shè)置了以下OS 對象：

圖3 構(gòu)建的驗證OS Task 示意圖Fig.3 Schematic diagram of built verification OS Task

（1）5 個任務(wù)：初始化任務(wù)、1 個Loop 循環(huán)、1 個Cyclic 循環(huán)、Task_St1、Task_St2；

（2）2 個OS 警報：AlarmActCyclic 和SysCounterIncrementer；

（3）1 個軟件計數(shù)器；

（4）1 個硬件計數(shù)器；

（5）1 個調(diào)度表；

（6）1 個OS 資源Res_CounterVar；

（7）以上所有對象都分配到的2 個應(yīng)用程序APP1 和APP2。

自啟動任務(wù)InitTask 激活Cyclic 警報AlarmActCyclic 并切換到Loop 循環(huán)任務(wù)。此任務(wù)執(zhí)行一個無窮循環(huán)，該循環(huán)連續(xù)獲取并釋放資源Res_CounterVar。自啟動的OS 警報SysCounterIncrementer 使軟件計數(shù)器遞增，該計數(shù)器與OS 警報AlarmActCyclic 相連。

在AlarmActCyclic 出現(xiàn)OS 警報事件時，將激活Cyclic 任務(wù)，其優(yōu)先級為高于Loop 循環(huán)任務(wù)的優(yōu)先級。Cyclic 循環(huán)激活后，Res_CounterVar資源不再被占用時，Loop 循環(huán)任務(wù)將被中斷，Cyclic 任務(wù)循環(huán)開始運行。

在Cyclic 循環(huán)任務(wù)中，特定的輸出模塊將輸出累加的一個變量用于觀測，且連接配置到評估板LED 燈用于觀測驗證。計數(shù)器的時間單位具有固定大小，以便每秒激活一次Cyclic 循環(huán)任務(wù)。與上述行為并行地，OS 啟動調(diào)度表。此任務(wù)表有兩個溢出點，分別對應(yīng)任務(wù)Task_St1 和Task_St2。兩項任務(wù)均已配置具有比Loop 任務(wù)更高的優(yōu)先級，因此，Loop 任務(wù)將一再被中斷。

為方便觀測OS 實際運行情況，這里設(shè)置了多個觀測LED 燈。4 個LED 指示燈用于在循環(huán)任務(wù)中觀測遞增的計數(shù)變量的值。第5 個LED指示是否已使用資源Res_CounterVar。以上配置的OS 程序如果可以正常運行，則計數(shù)器LED 指示燈按規(guī)律遞增閃爍，而占用資源指示LED 燈也將按一定周期閃爍。

3 集成編譯以及下載觀測

配置完成OS 模塊的任務(wù)和必要設(shè)置之后，在AutoCore 界面點擊生成按鈕，排除錯誤和警告后，再點擊Build，整個工程將會生成配置文件[5]，存放于如圖4 所示的指定文件夾內(nèi)。這些配置文件包括了標(biāo)準(zhǔn)的.c 文件和.h 文件，我們在AutoCore 中完成的各項設(shè)置將以C 代碼的形式蘊含在這些配置文件內(nèi)。下一步將進行集成編譯工作。

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

集成編譯的目的是將應(yīng)用層代碼、配置生成文件以及AutoCore 提供的靜態(tài)代碼（例如OS krenel 以及各模塊的基礎(chǔ)源碼）按照一定的編譯規(guī)則集中編譯，歷經(jīng)預(yù)編譯、編譯、匯編和鏈接等過程后，生成可執(zhí)行文件。由于AUTOSAR 規(guī)定了3 種不同的配置參數(shù)編譯方式，分為預(yù)編譯配置參數(shù)、鏈接時配置參數(shù)和編譯后配置參數(shù)，因此編譯規(guī)則的制定應(yīng)當(dāng)提前考量這3 種參數(shù)的存在[6]。AutoCore 已經(jīng)根據(jù)用戶配置，制定好了不同的集中編譯的規(guī)則，完成配置后直接按照EB 推薦的編譯方式，使用命令行調(diào)用編譯器執(zhí)行編譯命令即可。這里使用了HighTec 提供的GCC 編譯器進行編譯。

在沒有配置沖突和用戶代碼不合理的情況下，編譯將順利生成elf 文件。

之后，將elf 文件在Tasking 中構(gòu)建可執(zhí)行文件工程，基于這個過程，通過與TC277 開發(fā)板連接進行調(diào)試和觀測工作。圖5 為正在運行OS 任務(wù)的開發(fā)板。

圖5 開發(fā)板連接與LED 燈展示Fig.5 Development board connected with LED light display

點擊燒寫按鈕，.elf 文件將燒寫進入開發(fā)板，Tasking 界面進入調(diào)試頁面，點擊開始運行。此時可以觀測LED 燈和環(huán)境變量task_St1_counter、task_St2_counter 的值來檢測OS 的任務(wù)是否按照預(yù)期在執(zhí)行。

首先，使用斷點檢查循環(huán)任務(wù)是否運行，在loop 內(nèi)打斷點，觀測得到程序停在斷點處。則證明OS 運行正常；再檢查cyclic_counters 計數(shù)器的值，發(fā)現(xiàn)該變量每秒增加1 次；再觀測變量task_St1_counter 和task_St2_counter 的 值。由 于二者構(gòu)建在同一調(diào)度表中，且后者周期是前者的兩倍，在觀測窗口觀測到二者始終在遞增且前者的值為后者的2 倍，說明程序按照期望運行；觀察LED 燈的狀態(tài)，前4 個LED 在按各自設(shè)定的周期翻轉(zhuǎn)閃爍，第5 個代表資源Res_CounterVar占用的LED 指示燈也按照邏輯關(guān)系周期閃爍。

4 結(jié)論

基于EB 公司提供的AUTOCORE 工具，主要驗證其OS 模塊的基本功能，完成了ACG 7 版本的完整配置流程：從可用模塊的導(dǎo)入，到主要模塊的配置和排錯，再到應(yīng)用層代碼的適配、配置文件的生成以及調(diào)用目標(biāo)編譯器（使用了GCC和Tasking 兩種編譯器）進行集成編譯、生成可執(zhí)行文件并通過IDE 下載到評估板。經(jīng)驗證，EB 提供的ACG7 OS 模塊完整、可靠，運行穩(wěn)定。