蔣笑寒，李 牧，孫思杰，馮逸駿

(1.北京航空航天大學(xué) 中法工程師學(xué)院，北京 100191；2.北京工業(yè)大學(xué) 樊恭烋學(xué)院，北京 100124；3.北京航空航天大學(xué) 宇航學(xué)院，北京 100191)

0 引 言

信息-物理系統(tǒng)(cyber physical systems，CPS)[1]是集成計算、通信與控制于一體的下一代智能系統(tǒng)，目前已廣泛應(yīng)用于各個安全攸關(guān)領(lǐng)域(safety-critical)，為提升智能系統(tǒng)的計算能力、安全性以及可靠性，亟需建立一套能夠用于CPS系統(tǒng)的單節(jié)點多核心分布式實時操作系統(tǒng)。

時間觸發(fā)理論作為一種高確定性的實時理論，已經(jīng)在安全攸關(guān)領(lǐng)域[2,3]有了多年的應(yīng)用。Pont MJ提出時間觸發(fā)原理；Hermann Kopetz等設(shè)計了時間觸發(fā)架構(gòu)，并提出了時間觸發(fā)協(xié)議TTP(time-triggered protocol)；Yan[4]基于傳統(tǒng)TTP協(xié)議設(shè)計了C類時間觸發(fā)協(xié)議TTP/C。在傳統(tǒng)分布式實時操作系統(tǒng)領(lǐng)域，Kane Kim提出了基于NT和Linux的時間觸發(fā)支持的操作系統(tǒng)架構(gòu)；Giotto把時間觸發(fā)架構(gòu)提升到了編程語言的層面。此后，有關(guān)時間觸發(fā)架構(gòu)的研究大量涌現(xiàn)[5,6]。隨著單機內(nèi)計算核心數(shù)目的增多，傳統(tǒng)操作系統(tǒng)會產(chǎn)生嚴重的性能下降，針對此，Andrew Baumann和Paul Barham等提出了Multikernel架構(gòu)。Barrelfish作為開源的Multikernel操作系統(tǒng)，為分布式的多核異構(gòu)系統(tǒng)提供了更高效的操作系統(tǒng)基礎(chǔ)設(shè)施。

本文將時間觸發(fā)架構(gòu)的設(shè)計思想應(yīng)用于以Barrelfish為代表的Multikernel系統(tǒng)中，依靠SMT[7]理論，對Barrelfish的消息進行建模，從而生成滿足所有約束的消息調(diào)度表，設(shè)計和實現(xiàn)時間觸發(fā)的任務(wù)調(diào)度模型、系統(tǒng)通信服務(wù)以及配套的時間觸發(fā)任務(wù)和通信的配置管理工具，形成可用的Multikernel架構(gòu)分布式硬實時系統(tǒng)。

1 基于Barrelfish的時間觸發(fā)實時通信框架設(shè)計

基于Barrelfish的時間觸發(fā)通信框架主要包含運行時和離線兩部分，其中，運行時部分的架構(gòu)如圖1所示。運行時部分負責(zé)支撐Barrelfish在部署及啟動后的時間觸發(fā)實時消息通信。圖1中描述了兩個通過實時交換機相連的SoC節(jié)點，每個SoC節(jié)點共有兩塊通過TTNoC相連的多核CPU。每個多核CPU上需要抽調(diào)出一個單獨的核心以運行時間觸發(fā)實時消息服務(wù)，該消息服務(wù)是一個CPU上所有應(yīng)用程序與其它CPU上的應(yīng)用進行通信的網(wǎng)關(guān)[8]。此外，一些實時應(yīng)用有并行多線程的需要，而Barrelfish本身并不支持同一個進程中的線程在多個CPU核心上運行，缺乏這種并行特性會導(dǎo)致一些消息無法及時生成，使得整個系統(tǒng)不可調(diào)度，因此，該運行時還包含有一個以Group為核心組件的動態(tài)SMP(symmetrical multi-processing)子系統(tǒng)。

圖1 時間觸發(fā)通信框架-運行時部分

消息服務(wù)是整個系統(tǒng)運行時的基礎(chǔ)設(shè)施。該消息服務(wù)在系統(tǒng)啟動時負責(zé)讓系統(tǒng)到達一致狀態(tài)，在系統(tǒng)運行期間，解析時間觸發(fā)消息調(diào)度表，提供消息在SoC內(nèi)部或跨SoC的消息轉(zhuǎn)發(fā)功能，并以API的形式為時間觸發(fā)實時應(yīng)用程序提供通信接口。此外，消息服務(wù)不僅需要在系統(tǒng)運行期間進行各個節(jié)點時間的同步，還需要維護各個節(jié)點的組籍狀態(tài)，在節(jié)點失效時，利用冗余備份機制恢復(fù)系統(tǒng)的可用性。以Group為核心的動態(tài)SMP子系統(tǒng)可以在運行時動態(tài)地改變某一系統(tǒng)分區(qū)的計算能力，提高此分區(qū)的多核并行計算能力，防止過多的分區(qū)和單核有限的計算能力對系統(tǒng)的可調(diào)度性產(chǎn)生影響。

基于Barrelfish的時間觸發(fā)通信框架的離線部分包含一個時間觸發(fā)消息調(diào)度器，在對整個時間觸發(fā)系統(tǒng)完成設(shè)計，得到應(yīng)用程序的消息規(guī)范之后，調(diào)度器可以根據(jù)硬件網(wǎng)絡(luò)約束和應(yīng)用程序約束得到一組滿足系統(tǒng)整體約束的消息調(diào)度表。該消息調(diào)度表規(guī)定了在何時有什么消息從何發(fā)送節(jié)點發(fā)送到哪些接收節(jié)點。運行時中的消息服務(wù)會解析該調(diào)度表，并依據(jù)全局時間基，在調(diào)度表規(guī)定的時間槽執(zhí)行相應(yīng)的消息轉(zhuǎn)發(fā)動作。圖2展示了基于Barrelfish的時間觸發(fā)通信框架的離線和運行時部分的關(guān)系。

圖2 時間觸發(fā)通信框架-離線和運行時部分的關(guān)系

下面分別從消息服務(wù)、動態(tài)SMP子系統(tǒng)和時間觸發(fā)消息調(diào)度器等3個方面展開敘述。

1.1 消息服務(wù)設(shè)計

針對時間觸發(fā)的實時消息通信，本文設(shè)計了一套稱之為MDL(message description list)的領(lǐng)域特定的調(diào)度表格式。靜態(tài)消息調(diào)度器負責(zé)生成MDL，消息服務(wù)通過解析MDL語句，按照MDL描述的調(diào)度時機和要采取的動作進行消息的調(diào)度。消息調(diào)度器在解析MDL的過程中，會保證數(shù)據(jù)幀的完整性和正確性，同時也會保證數(shù)據(jù)傳輸?shù)臅r序正確。

MDL通過全局時間基給出的時間槽為最小時隙單位。MDL設(shè)計了一種多等級的結(jié)構(gòu)：最上層為集群描述符，一個集群描述符可以包含多個節(jié)點描述符，一個節(jié)點描述符又由多個時隙描述符組成。為了保證MDL語言的二進制兼容性，MDL在所有架構(gòu)上都采用小端模式儲存。

為了簡化基本消息服務(wù)的設(shè)計，保證整個系統(tǒng)的一致性，無論是SoC內(nèi)部還是SoC間的消息傳輸皆使用同一套數(shù)據(jù)幀格式。本節(jié)所采用的數(shù)據(jù)幀格式由幀頭和數(shù)據(jù)體構(gòu)成，其結(jié)構(gòu)如圖3所示。

圖3 實時消息幀格式

幀頭主要包含協(xié)議相關(guān)的語義屬性，數(shù)據(jù)校驗位等。數(shù)據(jù)幀的類型由幀頭中的相關(guān)位確定。數(shù)據(jù)幀一共有兩種類型：一種稱為普通幀，搭載用戶數(shù)據(jù)的幀屬于此種類型；第二種幀稱為節(jié)點控制幀，用于節(jié)點間維護在線關(guān)系，同步時鐘等；此外，幀頭中還包括校驗位，為了減少校驗算法帶來的額外開銷，本框架采用CRC校驗法作為消息完整性的檢查算法。

1.2 動態(tài)SMP子系統(tǒng)設(shè)計

Barrelfish無法利用多核并行能力的原因是其CPU Driver與CPU Core的對應(yīng)關(guān)系高度耦合，在目前的實現(xiàn)中，CPU Driver與CPU Core為多對一關(guān)系。SpaceJMP[9]提出把虛擬地址空間當(dāng)作操作系統(tǒng)的一種頭等對象，允許一個進程可以在多個地址空間中快速切換，從而實現(xiàn)共享大段內(nèi)存的目的。這種編程模型可以模擬出傳統(tǒng)的Unix線程，但是由于添加了特殊的編程語言，需要特殊的編譯器。頻繁的切換地址空間對TLB和Cache都不友好，軟硬件兼容性方面都不是非常優(yōu)秀。我們可以通過設(shè)計一種新的消息傳遞基礎(chǔ)設(shè)施，開發(fā)了一種基于任務(wù)派生—合并的并行任務(wù)模型(類似于MapReduce算法)，但由于涉及了大量小任務(wù)的遷移、調(diào)度和同步，這種編程框架本身會產(chǎn)生較大的消息通信開銷和同步等待的開銷，此外，該編程模型只適用于解決分治算法，無法使用常規(guī)并行多線程算法。

為了解決這個問題，本文設(shè)計了一個稱為Group的核心系統(tǒng)組件，其架構(gòu)如圖4所示。

圖4 Barrelfish的Group架構(gòu)

為了減少對已有服務(wù)程序的更改，需要考慮到現(xiàn)有的服務(wù)程序都以線程不安全的方式實現(xiàn)，無法并行執(zhí)行多線程，因此需要提供一種機制，在執(zhí)行線程不安全的服務(wù)程序時，禁用并行的特性，只允許一個CPU Core串行的執(zhí)行程序。本文采用如下方案解決這個問題。當(dāng)Group中包含多個Core時，選取其中一個核心為主核心，負責(zé)Group的合并和拆分以及系統(tǒng)進程的運行；其它的Core則成為成員核心，負責(zé)運行其它的進程。主核心不可以脫離當(dāng)前Group，成員核心則可以自由地附著到其它的核心。

1.3 時間觸發(fā)消息調(diào)度器設(shè)計

本文定義了一個時間觸發(fā)實時網(wǎng)絡(luò)中的所有約束條件。為了簡化約束的書寫，本節(jié)做了如下假定：

(1)整個集群的超周期被劃分為長度相等的時間片，該時間片的長度為全局時間基的時間粒度的整數(shù)倍，稱之為集群超周期。超周期的值可用所有幀的周期的最小公倍數(shù)計算得到。

(2)每個節(jié)點在發(fā)送或者中繼消息時，發(fā)送一個數(shù)據(jù)幀只占用一個時間槽。

(3)對于同一個應(yīng)用發(fā)送的消息，將以相同的路徑到達接收者。

在此基礎(chǔ)上，可以對約束條件進行簡化的表示。本文把約束條件分為硬件約束條件和軟件約束條件兩類進行描述：

(1)硬件約束條件

硬件約束條件中最基礎(chǔ)的是發(fā)送端口獨占約束，即無競爭約束。該條件意味著一個發(fā)送節(jié)點或者一個中繼節(jié)點只有在前一條數(shù)據(jù)幀完全發(fā)送完畢之后，才可以開始發(fā)送下一條數(shù)據(jù)幀。

(2)軟件約束條件

端到端消息傳輸約束描述了應(yīng)用程序要求的數(shù)據(jù)幀端到端傳輸?shù)淖畲髸r延，該最大延遲必須小于應(yīng)用發(fā)送幀的周期。對于多播傳輸，假設(shè)所有的接收者都具有相同的端到端傳輸時延要求。

求解最優(yōu)數(shù)據(jù)虛鏈路時，本文采用以下目標(biāo)函數(shù)

(1)

該目標(biāo)函數(shù)要求整個系統(tǒng)調(diào)度數(shù)據(jù)幀的最大延遲最小，最大數(shù)據(jù)幀延遲越小，總體延遲越小，系統(tǒng)利用率越高。

最優(yōu)解算法在面對較大規(guī)模數(shù)據(jù)集時，無法在可以接受的時間內(nèi)得到一個解[10]，因此本文不采用最優(yōu)解算法，而是使用目前比較成熟的近似算法(如Wang[11]、Lee[12]等)，在多項式時間內(nèi)，求出該問題的近似最優(yōu)解。

2 基于Barrelfish的時間觸發(fā)實時通信框架實現(xiàn)

2.1 消息服務(wù)實現(xiàn)

時間觸發(fā)實時通信框架提供的消息服務(wù)API接口見表1。

表1 Barrelfish實時通信框架操作接口

其中，最核心的功能是消息收發(fā)接口，時間觸發(fā)的實時應(yīng)用程序可以調(diào)用這兩個接口進行消息的收發(fā)。當(dāng)發(fā)送消息時，調(diào)用該接口后，應(yīng)用程序?qū)⒁l(fā)送的消息數(shù)據(jù)會被復(fù)制到相應(yīng)消息通道的緩沖區(qū)內(nèi)，當(dāng)調(diào)度表規(guī)定的消息傳輸時刻到來時，消息服務(wù)會把該消息從緩沖區(qū)中取出，并復(fù)制到目標(biāo)緩沖區(qū)中。當(dāng)接收消息時，調(diào)用該接口后，會根據(jù)調(diào)度表的時刻，等待到消息到來的時刻。在此期間，消息服務(wù)會把要接收的消息從發(fā)送者的緩沖區(qū)復(fù)制到接收者消息通道緩沖區(qū)內(nèi)，當(dāng)時刻到來后，該接口會將消息從消息通道中復(fù)制到應(yīng)用程序的數(shù)據(jù)緩沖區(qū)，供應(yīng)用程序使用，然后喚醒應(yīng)用程序進行后續(xù)的計算操作。

2.2 動態(tài)SMP子系統(tǒng)實現(xiàn)

系統(tǒng)的實現(xiàn)主要可分為兩部分，一方面是對CPU Dri-ver 的更改，將CPU Driver對CPU Core的依賴，更改為對Group的依賴，并將CPU Driver修改為線程安全的實現(xiàn)。另一方面是對libbarrelfish的更改。libbarrelfish把各個系統(tǒng)服務(wù)提供的各項功能整合到了一起，封裝成為易用的API，應(yīng)用程序借助該庫能獲得完備的操作系統(tǒng)功能。

(1)針對CPU Driver的SMP實現(xiàn)

CPU Driver中的數(shù)據(jù)段，根據(jù)數(shù)據(jù)使用者的不同，可分為兩類。一類數(shù)據(jù)代表了CPU Core的狀態(tài)，另一類數(shù)據(jù)則代表了該CPU Driver本身的狀態(tài)。

對于前者，代表CPU Core狀態(tài)的數(shù)據(jù)由Group組件統(tǒng)一管理，Group組件會將這些數(shù)據(jù)項復(fù)制多份，保證每個核心都有相對應(yīng)的唯一的數(shù)據(jù)，并由Group組件為CPU Driver提供相關(guān)的讀取、寫入接口。

對于后者，考慮到需要保護的關(guān)鍵代碼段通常不是很大，可以使用自旋鎖對這部分數(shù)據(jù)進行保護。在多核并行場景下，自旋鎖可以保證核間臨界資源的正確性[13]。自旋鎖與互斥鎖、信號量類似，只是自旋鎖不會引起調(diào)用者阻塞。如果自旋鎖已經(jīng)被其它執(zhí)行體占有，調(diào)用者就一直循環(huán)檢測自旋鎖是否被釋放，是否處于空閑狀態(tài)，這個循環(huán)過程就是自旋。自旋鎖的占有時間非常短，因此調(diào)用者不被阻塞而在那自旋，比上下文切換節(jié)省時間開銷，效率遠高于互斥鎖、信號量。但普通自旋鎖具有隨機占有的特性，這帶來了調(diào)度上的不公平。為了避免這個不公平問題，本文使用了被稱為輪轉(zhuǎn)自旋鎖的技術(shù)，與普通自旋鎖的隨機占有鎖的方式不同，每個核心采用排隊的方式獲取自旋鎖，這樣每個CPU核心都有相同的概率獲得鎖的使用權(quán)。

(2)針對libbarrelfish的SMP實現(xiàn)

本文采用一種稱為代理執(zhí)行的方法來解決libbarrelfish中存在的數(shù)據(jù)競爭問題。這種方法的核心在于，在一個Group中，只允許主核心執(zhí)行Disabled狀態(tài)的Dispatcher。成員核心只允許執(zhí)行用戶創(chuàng)建的線程的代碼和線程調(diào)度器。當(dāng)成員核心上的線程需要切換到Disabled狀態(tài)時，會首先將線程遷移到主核心上，其中，線程的遷移可以利用線程對處理器核心的親和性來完成。

另一個需要改動的點是Barrelfish的消息機制，Barrelfish系統(tǒng)中的LMP消息是基于Upcall實現(xiàn)的，UMP消息則是通過輪詢實現(xiàn)。為了避免在消息處理相關(guān)的代碼中產(chǎn)生數(shù)據(jù)競爭，新的消息機制只允許Group內(nèi)的主核心執(zhí)行相關(guān)的代碼，負責(zé)所有消息的轉(zhuǎn)發(fā)和輪詢。

2.3 時間觸發(fā)消息調(diào)度器實現(xiàn)

本文設(shè)計了兩種實時調(diào)度器，一種是基礎(chǔ)時間觸發(fā)實時消息調(diào)度器，另一種是增量時間觸發(fā)實時消息調(diào)度器。SMT求解器選用微軟的開源求解器Z3，并使用它提供的Python API進行編寫。增量時間觸發(fā)實時消息調(diào)度器會在兩個求解階段間多次切換，并使用Z3提供的回溯功能。

(1)基礎(chǔ)時間觸發(fā)實時消息調(diào)度器實現(xiàn)

基礎(chǔ)求解器的實現(xiàn)較為簡單，在基礎(chǔ)求解器中，會首先把所有數(shù)據(jù)幀的約束條件添加到SMT求解器上下文中，然后調(diào)用SMT求解器的求解函數(shù)，SMT求解器會首先檢查這些約束條件是否具有一致性，若滿足一致性，便可以計算得到本組約束的解。這組解可以通過SMT求解器提供的API函數(shù)得到。

(2)增量時間觸發(fā)實時消息調(diào)度器實現(xiàn)

由于SMT求解器對一次求解的約束條件數(shù)目有所限制，當(dāng)約束規(guī)模較大時，無法將全部約束一次性全部添加到求解器中。為了解決這個問題，本文設(shè)計的增量調(diào)度器不會一次性生成全部的約束條件，而是逐次地將約束條件的子集加入到SMT求解器中并進行多次求解。在每次子集的求解完成之后，會按照這一部分的求解結(jié)果，把數(shù)據(jù)幀的偏移固定下來，作為下一次求解的約束輸入。這樣的方案可能會導(dǎo)致求解器在中間某次求解過程中返回失敗，對于錯誤的處理，本文采用回溯的方法，逐步增大之前的約束子集的數(shù)目。當(dāng)SMT求解器無法在規(guī)定的時間內(nèi)得到一組解，或是約束子集的數(shù)目超過了預(yù)先設(shè)定的閾值，則認為調(diào)度失敗。

增量調(diào)度算法開始時，首先生成這一數(shù)據(jù)幀范圍內(nèi)的約束，并檢查是否存在針對這一部分的可行解。若存在可行解，則從求解器中獲取解，并把這些解保存到本地變量中，作為新的常量約束并用于下一輪的約束。最后，把輸入的幀集合更新為下一輪的集合。

在最壞情況下，回溯過程有可能回溯到數(shù)據(jù)幀序列的第一幀。在這種情況下，增量調(diào)度器等價于基礎(chǔ)調(diào)度器。當(dāng)調(diào)度器沒有能在合理時間內(nèi)得到解時，便會終止求解算法，回溯到前面得到部分解的步驟，并返回當(dāng)前已經(jīng)得到的時間表。調(diào)度算法求解的中斷可采用封裝好的信號中斷函數(shù)。

至此，基于Barrelfish的時間觸發(fā)實時通信框架的設(shè)計與實現(xiàn)已經(jīng)完成。

3 基于Barrelfish的時間觸發(fā)實時通信框架實驗結(jié)果與分析

本文先分別針對如下3個部分做了驗證和測試：消息通信服務(wù)的正確性及其功能實現(xiàn)的完整性、時間觸發(fā)通信消息調(diào)度算法及調(diào)度器的正確性、Barrelfish的動態(tài)SMP子系統(tǒng)的性能，最后對整個框架進行綜合測試。

為了對通信框架和動態(tài)SMP子系統(tǒng)兩部分的結(jié)果進行驗證，本文采用了軟件模擬和真實硬件兩套環(huán)境開展實驗。其中，軟件模擬部分使用QEMU，硬件部分使用NVIDIA Jetson TK1作為實驗平臺。兩者皆以ARM為計算平臺架構(gòu)。具體的硬件參數(shù)見表2。

表2 實驗平臺硬件參數(shù)

對于調(diào)度算法的驗證，本文首先通過一定規(guī)則生成了一個測試集合，然后對調(diào)度算法的性能、正確性和調(diào)度結(jié)果的質(zhì)量做了評測。

(1)消息服務(wù)性能測試

本部分主要測量了時間觸發(fā)通信的延遲，該延遲是SMT調(diào)度表求解的重要參數(shù)。測試時，在系統(tǒng)的兩個核心上分別建立服務(wù)端和客戶端兩個進程，客戶端向服務(wù)端發(fā)送請求后，服務(wù)端立刻返回一條消息。通過消息的往返發(fā)送，可以測量出延遲。本次測試中，每經(jīng)過一萬個消息往返，記錄一次時延，測試結(jié)果如圖5所示。

圖5 Barrelfish實時通信延遲

從圖5中可以看出，SMP通信機制容易受到內(nèi)核調(diào)度器和其它系統(tǒng)進程的影響，消息的時延抖動相對較大，但是依然滿足實時應(yīng)用的要求。對于通過消息轉(zhuǎn)發(fā)服務(wù)收發(fā)的SoC內(nèi)部消息，由于采取了輪詢機制，平均延遲較小，且抖動較小。對于跨SoC的消息，由于目前采用普通TCP/IP網(wǎng)絡(luò)進行測量，抖動比較嚴重。

(2)調(diào)度算法性能測試

本文一共測試了3種網(wǎng)絡(luò)拓撲，分別是星狀網(wǎng)絡(luò)，樹狀網(wǎng)絡(luò)和雪花狀網(wǎng)絡(luò)。針對每種網(wǎng)絡(luò)拓撲，隨機生成一系列的幀集合，并隨機生成一定比例的約束條件(本文使用幀數(shù)的20%作為應(yīng)用級約束)，然后使用求解器進行求解。調(diào)度器求解時間的統(tǒng)計結(jié)果如圖6所示。

圖6 各種網(wǎng)絡(luò)拓撲數(shù)據(jù)幀調(diào)度耗時

(3)動態(tài)SMP子系統(tǒng)測試

動態(tài)SMP子系統(tǒng)本質(zhì)上是實現(xiàn)了共享地址空間的并行方案。共享內(nèi)存實際上是共享部分物理內(nèi)存，而動態(tài)SMP子系統(tǒng)則是共享整個虛擬地址空間，本質(zhì)上來看兩者區(qū)別只是共享空間的大小不同，但是動態(tài)SMP子系統(tǒng)提供了一個更友好的編程接口。為了驗證兩種方案對性能的影響，本文通過矩陣相乘算法，對兩種方法的性能進行了測試。

測試結(jié)果如圖7和圖8所示。

圖7 Qemu中共享內(nèi)存與動態(tài)SMP子系統(tǒng)性能對比

圖8 Jetson TK1中共享內(nèi)存與動態(tài)SMP子系統(tǒng)性能對比

由測試結(jié)果可以看出，共享內(nèi)存方案由于存在通信延遲，其性能比動態(tài)SMP子系統(tǒng)方案要略微差一些。但是兩者都能起到并行執(zhí)行的效果，相比于單核心執(zhí)行，并行執(zhí)行能夠明顯地提高性能。

(4)綜合測試

為了對整個系統(tǒng)進行驗證，本文設(shè)計了如圖9所示的網(wǎng)絡(luò)結(jié)構(gòu)，由于缺乏時間觸發(fā)實時網(wǎng)絡(luò)硬件的支撐，本節(jié)將使用Qemu搭建虛擬網(wǎng)絡(luò)進行模擬驗證。

圖9 綜合實驗組網(wǎng)

網(wǎng)絡(luò)中，每個節(jié)點上運行有X64架構(gòu)的四核心處理器，節(jié)點間通過Qemu虛擬交換機相連。每個節(jié)點內(nèi)部的通信不受限制，相當(dāng)于CPU內(nèi)部的核心間有兩兩相連的通信鏈路，節(jié)點間產(chǎn)生通信時，每個節(jié)點在一個時間槽只能發(fā)出一條消息。每個有依賴應(yīng)用的應(yīng)用，只有在接收到依賴應(yīng)用發(fā)來的消息之后間隔一個時間槽，才可以發(fā)送消息。

本文設(shè)計了如表3所示的綜合實驗應(yīng)用。

表3 綜合實驗應(yīng)用設(shè)計

由表3可知，集群的超周期為24。針對應(yīng)用的周期，調(diào)度器生成了實時調(diào)度表，如圖10所示。

圖10 實時調(diào)度器生成調(diào)度表

調(diào)度表的成功生成表明了基于Barrelfish的時間觸發(fā)實時通信框架的正確性與可行性。

4 結(jié)束語

本文在Barrelfish的基礎(chǔ)上設(shè)計與實現(xiàn)了一套基于時間觸發(fā)機制的實時通信架構(gòu)，該架構(gòu)包括一套獨立的時間觸發(fā)實時消息服務(wù)、接口以及用于時間觸發(fā)實時系統(tǒng)消息調(diào)度的靜態(tài)離線調(diào)度算法和調(diào)度器。該通信架構(gòu)為Multikernel架構(gòu)在分布式CPS實時系統(tǒng)上的應(yīng)用打下了基礎(chǔ)。

該通信架構(gòu)仍有如下地方有待改進：

(1)每個SoC上都需要分出單獨核心運行時間觸發(fā)實時消息服務(wù)，對CPU資源產(chǎn)生了較大浪費。

(2)目前尚未給出綜合消息調(diào)度與任務(wù)調(diào)度的完整解決方案。

(3)當(dāng)前測試所使用的硬件系統(tǒng)規(guī)模較小。