作者 |郭建上?？匕部尚跑浖?chuàng)新研究院特聘專家

版塊 |鑒源論壇 · 觀模

汽車工業(yè)發(fā)展至今，硬件方面如車身材料、發(fā)動機等已無太大升值空間，而汽車電子則有著廣闊的前景。為此各大汽車廠商對汽車電子的研究都投入了大量的人力財力。2003 年，汽車開放系統(tǒng)架構(gòu)AUTOSAR（AUTomotive Open SystemArchitecture）由全球汽車制造商、部件供應(yīng)商及其他電子、半導(dǎo)體和軟件系統(tǒng)公司聯(lián)合建立，主要目標(biāo)是為汽車軟件體系架構(gòu)建立一個開放的、標(biāo)準(zhǔn)化工業(yè)標(biāo)準(zhǔn)，以同時滿足供應(yīng)商和生產(chǎn)商之間的需求。AUTOSAR 通過控制復(fù)雜度不斷增長的汽車電子體系架構(gòu)，將軟件從硬件中分離開來，允許軟件的重用，從而減少二次開發(fā)和驗證的成本。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)簡單、通信靈活等特點而最常被使用?；贏UTOSAR的網(wǎng)絡(luò)協(xié)議規(guī)范已有很多被發(fā)布。如基于AUTOSAR的CAN協(xié)議、基于AUTOSAR的TTCAN協(xié)議等，這些規(guī)范詳細(xì)闡述了在AUTOSAR規(guī)范下該網(wǎng)絡(luò)協(xié)議的驅(qū)動及接口規(guī)范，隱藏了底層網(wǎng)絡(luò)通信的細(xì)節(jié)，向上層應(yīng)用軟件提供調(diào)用底層服務(wù)的接口。通過這種方式使軟硬件分離，使上層軟件的開發(fā)更為靈活，對功能的擴充更方便，縮短了開發(fā)周期。

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

01AUTOSAR體系架構(gòu)

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

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

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

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

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

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

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

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

02AUTOSAR的TTCAN協(xié)議

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

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

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

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

AUTOSAR規(guī)范下TTCAN協(xié)議的抽象主要為三個層次。

一是應(yīng)用層

，即軟件組件層，包含了各種軟件組件消息傳輸請求的序列，對應(yīng)于 TTCAN 協(xié)議的系統(tǒng)矩陣。

二是運行時環(huán)境層

，對上層應(yīng)用層隱藏了下層的通信細(xì)節(jié)，實現(xiàn)虛擬功能總線，是對TTCAN協(xié)議通信通道的抽象。

三是基礎(chǔ)軟件層

，即TTCAN通信網(wǎng)絡(luò)所處位置，完成TTCAN協(xié)議基本的通信功能，即節(jié)點消息傳輸、總線仲裁和錯誤處理功能。

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

圖3描述了基于AUTOSAR的TTCAN協(xié)議抽象，運行時環(huán)境層可以接收來自于軟件組件的任何數(shù)據(jù)請求，通過內(nèi)部的接口調(diào)用底層基礎(chǔ)軟件的通信功能，完成消息的傳輸。在AUTOSAR軟件體系架構(gòu)中，位于運行時環(huán)境層之下的基礎(chǔ)軟件層對于應(yīng)用層來說是不可見的，因此，基礎(chǔ)軟件層可采用不同的通信協(xié)議來完成通信功能?；贏UTOSAR的TTCAN協(xié)議則是在基礎(chǔ)軟件層中采用了TTCAN協(xié)議來進行消息的傳輸。

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

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

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

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

第一階段

對TTCAN協(xié)議的需求進行分析，對于消息傳輸相關(guān)的四個主要部分系統(tǒng)矩陣、節(jié)點消息傳輸、總線仲裁及錯誤處理進行抽象，并分析這四個部分之間的關(guān)系以及消息的傳輸過程。分別對這四個部分進行形式化的描述，以Timed CSP建立模型。同時，在這一階段，分析并提取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層次模型，該模型包含了軟件組件、運行時環(huán)境和基礎(chǔ)軟件三個層次。其中，軟件組件實現(xiàn)TTCAN協(xié)議模型中系統(tǒng)矩陣的功能，為系統(tǒng)提供消息傳輸請求的列表；運行時環(huán)境為上下層之間的通信提供了虛擬功能總線，包含了多種接口以供上層模塊調(diào)用底層通信服務(wù)，是對TTCAN協(xié)議模型通信通道的抽象；基礎(chǔ)軟件包含了TTCAN協(xié)議模型中的節(jié)點消息傳輸、總線仲裁和錯誤處理模塊，提供消息傳輸?shù)姆?wù)。最后對模型進行性質(zhì)的提取，提取的性質(zhì)不僅需要滿足TTCAN協(xié)議的需求，還要滿足AUTOSAR規(guī)范的需求。

第三階段

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

圖6模型在PAT中的實現(xiàn)

圖7基于AUTOSAR的TTCAN協(xié)議模型性質(zhì)驗證結(jié)果

04小結(jié)

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

審核編輯黃昊宇