作者 | 郭建上海控安可信軟件創(chuàng)新研究院特聘專家

版塊 | 鑒源論壇 · 觀模

汽車工業(yè)發(fā)展至今，硬件方面如車身材料、發(fā)動(dòng)機(jī)等已無太大升值空間，而汽車電子則有著廣闊的前景。為此各大汽車廠商對(duì)汽車電子的研究都投入了大量的人力財(cái)力。2003 年，汽車開放系統(tǒng)架構(gòu)AUTOSAR（AUTomotive Open SystemArchitecture）由全球汽車制造商、部件供應(yīng)商及其他電子、半導(dǎo)體和軟件系統(tǒng)公司聯(lián)合建立，主要目標(biāo)是為汽車軟件體系架構(gòu)建立一個(gè)開放的、標(biāo)準(zhǔn)化工業(yè)標(biāo)準(zhǔn)，以同時(shí)滿足供應(yīng)商和生產(chǎn)商之間的需求。AUTOSAR 通過控制復(fù)雜度不斷增長的汽車電子體系架構(gòu)，將軟件從硬件中分離開來，允許軟件的重用，從而減少二次開發(fā)和驗(yàn)證的成本。AUTOSAR包括了汽車電子功能劃分、統(tǒng)一軟件架構(gòu)和軟件開發(fā)過程等整套基于汽車電子開發(fā)的方法學(xué)。

CAN、TTCAN、LIN、FlexRay等是可用于汽車內(nèi)部網(wǎng)絡(luò)通信的協(xié)議。在現(xiàn)階段CAN及TTCAN協(xié)議因其穩(wěn)定可靠、結(jié)構(gòu)簡(jiǎn)單、通信靈活等特點(diǎn)而最常被使用?；贏UTOSAR的網(wǎng)絡(luò)協(xié)議規(guī)范已有很多被發(fā)布。如基于AUTOSAR的CAN協(xié)議、基于AUTOSAR的TTCAN協(xié)議等，這些規(guī)范詳細(xì)闡述了在AUTOSAR規(guī)范下該網(wǎng)絡(luò)協(xié)議的驅(qū)動(dòng)及接口規(guī)范，隱藏了底層網(wǎng)絡(luò)通信的細(xì)節(jié)，向上層應(yīng)用軟件提供調(diào)用底層服務(wù)的接口。通過這種方式使軟硬件分離，使上層軟件的開發(fā)更為靈活，對(duì)功能的擴(kuò)充更方便，縮短了開發(fā)周期。

本文針對(duì)AUTOSAR的TTCAN協(xié)議進(jìn)行研究，并用Timed CSP（Timed Communication Sequential Processes）形式化語言對(duì)其進(jìn)行建模，通過LTL（linear temporal logic）及斷言（Assertion）對(duì)TTCAN模型需要滿足的性質(zhì)進(jìn)行描述，運(yùn)用模型檢驗(yàn)工具PAT完成了對(duì)模型的驗(yàn)證。

01 AUTOSAR體系架構(gòu)

AUTOSAR的主要目標(biāo)是為汽車電子創(chuàng)建一個(gè)開放的、標(biāo)準(zhǔn)化的軟件架構(gòu)， 這個(gè)架構(gòu)有利于車輛電子系統(tǒng)軟件的交換與更新，并為高效管理愈來愈復(fù)雜的車輛電子軟件系統(tǒng)提供了一個(gè)基礎(chǔ)。此外，AUTOSAR在確保產(chǎn)品及服務(wù)質(zhì)量的同時(shí)，提高了產(chǎn)品研發(fā)的效率。AUTOSAR定義了設(shè)計(jì)汽車系統(tǒng)的方法和描述它們的軟件的架構(gòu)方式。圖 1 展示了AUTOSAR軟件分層體系架構(gòu)。

圖1?AUTOSAR軟件分層體系架構(gòu)

應(yīng)用層（application layer）

包含了實(shí)現(xiàn)所需功能的軟件組件SWC（SoftWare Component）的規(guī)約，它形成了OEM（Original Equipment Manufacturer）廠商之間的競(jìng)爭(zhēng)基礎(chǔ)。

運(yùn)行時(shí)環(huán)境層 RTE（RunTime Environment）

為應(yīng)用軟件提供了通信服務(wù)，它使 AUTOSAR的軟件組件獨(dú)立于特定的ECU。RTE是虛擬功能總線VFB（Virtual Function Bus）的一個(gè)實(shí)現(xiàn)，不指定用來交換數(shù)據(jù)的通信技術(shù)。因此，AUTOSAR可用LIN、CAN、TTCAN或者FlexRay等多種通信平臺(tái)。用VFB定義軟件組件的數(shù)據(jù)交換可使它們獨(dú)立于底層的硬件平臺(tái)，此外，可以使注意力集中到軟件組件之間的通信而不用關(guān)心數(shù)據(jù)是否在ECU 內(nèi)部或ECU之間傳輸。

基礎(chǔ)軟件層BSW（Basic SoftWare）

由服務(wù)層、ECU抽象層、復(fù)雜驅(qū)動(dòng)層和MCU（Micro Controller Unit）抽象層等子層組成。服務(wù)層處于基礎(chǔ)軟件層的頂層， 包含了操作系統(tǒng)、汽車網(wǎng)絡(luò)通信、管理服務(wù)、內(nèi)存服務(wù)和診斷服務(wù)。ECU 抽象層包含了輸入輸出（I/O）和通信硬件抽象，它使更高的軟件層獨(dú)立于ECU 硬件組件。復(fù)雜驅(qū)動(dòng)層是硬件和 RTE 之間的橋梁，它提供與AUTOSAR無關(guān)的、專用的功能，如設(shè)備驅(qū)動(dòng)等。MCU抽象層處于基礎(chǔ)軟件層的最底層，它包含了直接訪問的微控制器內(nèi)部設(shè)備的驅(qū)動(dòng)和內(nèi)存映射的微控制器外部設(shè)備的驅(qū)動(dòng)。

02 AUTOSAR的TTCAN協(xié)議

基于AUTOSAR的網(wǎng)絡(luò)通信協(xié)議位于體系架構(gòu)的基礎(chǔ)軟件層中，AUTOSAR為其提供接口的規(guī)范。TTCAN協(xié)議在AUTOSAR基礎(chǔ)軟件層的接口，位于通信硬件抽象層和通信服務(wù)層之間，是為上層通信層提供 TTCAN 協(xié)議驅(qū)動(dòng)服務(wù)的接口。圖 2 是AUTOSAR規(guī)范下的 TTCAN協(xié)議層次的架構(gòu)。TTCAN協(xié)議接口模塊是CAN接口模塊的擴(kuò)展，它包含了TTCAN協(xié)議所有與硬件獨(dú)立的任務(wù)。

圖2?AUTOSAR規(guī)范下的TTCAN協(xié)議層次架構(gòu)

TTCAN協(xié)議接口主要完成上層通信層對(duì)控制流和數(shù)據(jù)流的需求，比如：消息傳輸需求、消息傳輸確認(rèn)、消息接收指示、出錯(cuò)通知等。TTCAN協(xié)議接口的一個(gè)典型流程是，接收來自上層通信層的消息請(qǐng)求，通過TTCAN協(xié)議驅(qū)動(dòng)傳輸給 TTCAN協(xié)議控制器完成消息的傳輸，然后向上層通信層返回消息成功傳輸?shù)拇_認(rèn)。TTCAN協(xié)議接口為TTCAN協(xié)議網(wǎng)絡(luò)的控制和服務(wù)提供了訪問低層服務(wù)的通信抽象，通過接口將TTCAN協(xié)議狀態(tài)，管理器的狀態(tài)變化請(qǐng)求推送到底層的TTCAN協(xié)議驅(qū)動(dòng)，然后底層事件再通過接口推送到高層相關(guān)的網(wǎng)絡(luò)管理模塊。

03 基于AUTOSAR的TTCAN協(xié)議的形式化建模與分析

AUTOSAR規(guī)范下TTCAN協(xié)議的抽象主要為三個(gè)層次。一是應(yīng)用層，即軟件組件層，包含了各種軟件組件消息傳輸請(qǐng)求的序列，對(duì)應(yīng)于 TTCAN 協(xié)議的系統(tǒng)矩陣。二是運(yùn)行時(shí)環(huán)境層，對(duì)上層應(yīng)用層隱藏了下層的通信細(xì)節(jié)，實(shí)現(xiàn)虛擬功能總線，是對(duì)TTCAN協(xié)議通信通道的抽象。三是基礎(chǔ)軟件層，即TTCAN通信網(wǎng)絡(luò)所處位置，完成TTCAN協(xié)議基本的通信功能，即節(jié)點(diǎn)消息傳輸、總線仲裁和錯(cuò)誤處理功能。

圖3?基于AUTOSAR的TTCAN協(xié)議抽象

圖3描述了基于AUTOSAR的TTCAN協(xié)議抽象，運(yùn)行時(shí)環(huán)境層可以接收來自于軟件組件的任何數(shù)據(jù)請(qǐng)求，通過內(nèi)部的接口調(diào)用底層基礎(chǔ)軟件的通信功能，完成消息的傳輸。

在AUTOSAR軟件體系架構(gòu)中，位于運(yùn)行時(shí)環(huán)境層之下的基礎(chǔ)軟件層對(duì)于應(yīng)用層來說是不可見的，因此，基礎(chǔ)軟件層可采用不同的通信協(xié)議來完成通信功能?；贏UTOSAR的TTCAN協(xié)議則是在基礎(chǔ)軟件層中采用了TTCAN協(xié)議來進(jìn)行消息的傳輸。

圖4?TTCAN協(xié)議與基于AUTOSAR的TTCAN協(xié)議的關(guān)系

圖4簡(jiǎn)單描述了這兩者之間的關(guān)系。AUTOSAR規(guī)范中定義了一系列TTCAN協(xié)議的接口，通過對(duì)這些接口的實(shí)現(xiàn)完成TTCAN協(xié)議的各種功能。本文主要研究TTCAN協(xié)議中節(jié)點(diǎn)消息傳輸、總線仲裁和錯(cuò)誤處理的功能如何在AUTOSAR規(guī)范下實(shí)現(xiàn)，并可通過定義的接口進(jìn)行調(diào)用，從而完成消息的傳輸。

對(duì)TTCAN協(xié)議和基于AUTOSAR的TTCAN協(xié)議進(jìn)行分析、形式化建模和驗(yàn)證的研究框架如圖 5 所示。該框架主要分為三個(gè)階段：

圖5?基于AUTOSAR的TTCAN協(xié)議建模與分析框架

第一階段對(duì)TTCAN協(xié)議的需求進(jìn)行分析，對(duì)于消息傳輸相關(guān)的四個(gè)主要部分系統(tǒng)矩陣、節(jié)點(diǎn)消息傳輸、總線仲裁及錯(cuò)誤處理進(jìn)行抽象，并分析這四個(gè)部分之間的關(guān)系以及消息的傳輸過程。分別對(duì)這四個(gè)部分進(jìn)行形式化的描述，以Timed CSP建立模型。同時(shí)，在這一階段，分析并提取TTCAN協(xié)議中死鎖、安全性、不變性及公平性等相關(guān)的性質(zhì)，以LTL公式及斷言的形式描述并加以文字注釋說明。

第二階段根據(jù)AUTOSAR軟件體系架構(gòu)和基于AUTOSAR的TTCAN協(xié)議規(guī)范，在TTCAN模型的基礎(chǔ)上，將其遷移至AUTOSAR，這一過程關(guān)鍵之處在于明確TTCAN模型各功能模塊應(yīng)處于AUTOSAR體系結(jié)構(gòu)的哪一層次。然后在分析的基礎(chǔ)上，以Timed CSP建立基于AUTOSAR的TTCAN層次模型，該模型包含了軟件組件、運(yùn)行時(shí)環(huán)境和基礎(chǔ)軟件三個(gè)層次。其中，軟件組件實(shí)現(xiàn)TTCAN協(xié)議模型中系統(tǒng)矩陣的功能，為系統(tǒng)提供消息傳輸請(qǐng)求的列表；運(yùn)行時(shí)環(huán)境為上下層之間的通信提供了虛擬功能總線，包含了多種接口以供上層模塊調(diào)用底層通信服務(wù)，是對(duì)TTCAN協(xié)議模型通信通道的抽象；基礎(chǔ)軟件包含了TTCAN協(xié)議模型中的節(jié)點(diǎn)消息傳輸、總線仲裁和錯(cuò)誤處理模塊，提供消息傳輸?shù)姆?wù)。最后對(duì)模型進(jìn)行性質(zhì)的提取，提取的性質(zhì)不僅需要滿足TTCAN協(xié)議的需求，還要滿足AUTOSAR規(guī)范的需求。

第三階段是模型的實(shí)現(xiàn)和性質(zhì)的驗(yàn)證階段。模型檢測(cè)工具PAT支持并發(fā)實(shí)時(shí)系統(tǒng)建模、模擬以及推理，支持Timed CSP建模語言，同時(shí)也支持LTL公式及斷言描述性質(zhì)。因此，以PAT實(shí)現(xiàn)模型，使模型能得到準(zhǔn)確的描述。建模實(shí)現(xiàn)的同時(shí)，對(duì)前兩個(gè)階段中提取的性質(zhì)在工具PAT中進(jìn)行驗(yàn)證，并對(duì)驗(yàn)證結(jié)果進(jìn)行分析。圖6所示的是在PAT上模型實(shí)現(xiàn)的部分代碼，圖7給出了PAT對(duì)模型的驗(yàn)證結(jié)果。

圖6?模型在PAT中的實(shí)現(xiàn)?圖7?基于AUTOSAR的TTCAN協(xié)議模型性質(zhì)驗(yàn)證結(jié)果

04 小結(jié)

AUTOSAR規(guī)范的提出為高效管理愈來愈復(fù)雜的汽車電子提供了一個(gè)基礎(chǔ)。AUTOSAR通信棧位于運(yùn)行時(shí)環(huán)境（RTE）與微控制器抽象層（MCAL）之間，其簡(jiǎn)化ECU之間的通信服務(wù)，實(shí)現(xiàn)不同類型或速率總線間的數(shù)據(jù)交互，并對(duì)應(yīng)用層隱藏了與總線相關(guān)的協(xié)議和報(bào)文的屬性。本文針對(duì)AUTOSAR 的TTCAN通信協(xié)議進(jìn)行了研究，實(shí)現(xiàn)其形式化建模與分析。

參考文獻(xiàn)：

[1]Specification of Operating System https://www.autosar.org/fileadmin/user_upload /standards/classic/21-11/AUTOSAR_SWS_OS.pdf.

[2] Bunzel S. AUTOSAR - the Standardized Software Architecture.[J]. Informatik Spektrum, 2011, 34(1):79-83.

[3] Barthe G, Pardo A, Schneider G. SEFM: software engineering and formal methods[J]. Software & Systems Modeling, 2015, 14(1):3-4.

[4] 冉欽文，基于AUTOSAR 的汽車電子通訊協(xié)議的研究[D]. 華東師范大學(xué),2015.

[5] ISO 11898- Part4, Road vehicles - Controller area network (CAN) - Part 4: Time triggered communication. 2004.

[6] Skoglund M, Svensson H, Eriksson H, et al. Checking Verification Compliance of Technical Safety Requirements on the AUTOSAR Platform Using Annotated Semi-formal Executable Models[M]//Computer Safety, Reliability, and Security. Springer International Publishing, 2014: 19-26.

[7] Ahmed M. Hamed, M. Watheq El-Kharashi, Ashraf Salem, Mona Safar: A Multicycle Pipelined GCM-Based AUTOSAR Communication ASIP. IEEE Access 10: 46312-46329 (2022).