基于軟總線技術(shù)的艦船操控系統(tǒng)通用軟件架構(gòu)研究

諶興良，孫寒冰，趙 光，但楊文，李海軍

(天津航海儀器研究所九江分部，江西 九江 332007)

0 引 言

艦船操縱控制系統(tǒng)是艦船上用于改變或保持航速、姿態(tài)、航向、深度的自動(dòng)控制系統(tǒng)，是保障艦船生命力和遂行作戰(zhàn)使命的重要關(guān)鍵裝備。該裝備上運(yùn)行的艦船操縱控制軟件系統(tǒng)是典型的分布式多任務(wù)異構(gòu)嵌入式系統(tǒng)，功能涵蓋避碰決策、航路規(guī)劃、航跡控制、航向控制、舵角控制、姿態(tài)控制、推進(jìn)控制以及水下載體特有的深度、潛浮、均衡、懸?？刂频裙δ?，如圖1 所示。作為嵌入式系統(tǒng)具有硬件依賴性，不同型號(hào)設(shè)備的硬件平臺(tái)差異較大，諸如總線形式、硬件驅(qū)動(dòng)、操作系統(tǒng)、通信協(xié)議皆是形態(tài)各異，一般都是專為特定型號(hào)專門設(shè)計(jì)，無(wú)法實(shí)現(xiàn)軟件整體復(fù)用。為了屏蔽底層軟硬件平臺(tái)差異，實(shí)現(xiàn)功能模塊基于數(shù)據(jù)運(yùn)行達(dá)到即插即用的目的，從而最終解決艦船操控系統(tǒng)軟件通用化的問(wèn)題，必須站在頂層設(shè)計(jì)的高度，采用分層及構(gòu)件化框架設(shè)計(jì)思路，開(kāi)展艦船操控系統(tǒng)通用軟件架構(gòu)的設(shè)計(jì)和實(shí)現(xiàn)。

圖1 艦船操控系統(tǒng)軟件功能組成Fig.1 Functional composition of ship maneuvering control system software

張智慧提出了基于分層技術(shù)的嵌入式系統(tǒng)架構(gòu)設(shè)計(jì)思路，重點(diǎn)探討了架構(gòu)分層原則、分層設(shè)計(jì)方法、分層技術(shù)應(yīng)用，對(duì)嵌入式系統(tǒng)架構(gòu)設(shè)計(jì)具有一定的理論指導(dǎo)價(jià)值和方法借鑒意義。曹敬瑜等提出一種適用于嵌入式分布計(jì)算環(huán)境下的高效軟件構(gòu)件化框架。該軟件構(gòu)架基于開(kāi)放服務(wù)網(wǎng)關(guān)倡議(OSGi)標(biāo)準(zhǔn)，通過(guò)加入傳輸抽象層實(shí)現(xiàn)了在多通訊協(xié)議環(huán)境下的應(yīng)用，具有通用性好、穩(wěn)定性高、內(nèi)存占用量少的特點(diǎn)。魏許等采用分層架構(gòu)、抽象工廠的設(shè)計(jì)模式以及配置文件的方法，實(shí)現(xiàn)了多型號(hào)的自動(dòng)化測(cè)試軟件的兼容，解決了軟件的通用性問(wèn)題，對(duì)通用嵌入式軟件架構(gòu)設(shè)計(jì)有重要參考價(jià)值。孫婧等提出了一種基于XML 文件的可配置、易更新的通用測(cè)控程序框架，使用XML 配置文件對(duì)測(cè)控軟件外部接口屬性進(jìn)行描述，實(shí)現(xiàn)了軟件接口代碼的自動(dòng)生成，提高了軟件的開(kāi)發(fā)效率和可靠性。閆瑞東提出了基于軟總線的衛(wèi)星姿控系統(tǒng)軟件體系結(jié)構(gòu)，制定了基于軟總線的各模塊的通訊機(jī)制和數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)了可復(fù)用的軟件體系結(jié)構(gòu)，增強(qiáng)了軟件的靜態(tài)和動(dòng)態(tài)適應(yīng)性，降低了軟件的開(kāi)發(fā)和集成成本。

本文在研究總結(jié)艦船操縱控制系統(tǒng)的業(yè)務(wù)特點(diǎn)后，抽象出了生產(chǎn)者-消費(fèi)者模式的業(yè)務(wù)邏輯模型，創(chuàng)新性地將該設(shè)計(jì)模式與軟總線思想相結(jié)合，提出適用于艦船操縱控制系統(tǒng)的通用軟件架構(gòu)設(shè)計(jì)，實(shí)現(xiàn)了對(duì)艦船操控專業(yè)所有應(yīng)用場(chǎng)景和需求的覆蓋，提高了軟件的整體復(fù)用性。本架構(gòu)設(shè)計(jì)的優(yōu)勢(shì)包括：

1）開(kāi)放的體系結(jié)構(gòu)

在CORBA 規(guī)范中，軟總線負(fù)責(zé)對(duì)各功能模塊進(jìn)行調(diào)度和管理，并規(guī)定了各功能模塊必須滿足相關(guān)接口標(biāo)準(zhǔn)要求才能“連接”到總線上與其他模塊協(xié)同工作。本文的架構(gòu)設(shè)計(jì)僅對(duì)軟總線接口設(shè)計(jì)執(zhí)行了嚴(yán)格的標(biāo)準(zhǔn)要求，但對(duì)功能模塊沒(méi)有任何要求和限制，即功能模塊對(duì)于軟總線不可見(jiàn)，因此軟總線與功能模塊的耦合度較低，這就意味著功能模塊的開(kāi)發(fā)和擴(kuò)展更自由方便，同時(shí)軟總線也具有更廣泛的適用性。

2）易用的訪問(wèn)接口

軟總線向功能模塊提供簡(jiǎn)潔、規(guī)范、高效的數(shù)據(jù)訪問(wèn)接口，功能模塊僅需憑借數(shù)據(jù)對(duì)象名稱即可獲得數(shù)據(jù)對(duì)象的訪問(wèn)服務(wù)，實(shí)現(xiàn)對(duì)數(shù)據(jù)對(duì)象的屬性讀取、數(shù)值更新等操作。

3）可配置的數(shù)據(jù)對(duì)象

軟總線中的數(shù)據(jù)對(duì)象采用專用的信息描述模型，通過(guò)XML 文件實(shí)現(xiàn)描述對(duì)象的最小完備及可配置化定義，提高了軟總線的靈活性和適用性。

4）可容錯(cuò)的并行結(jié)構(gòu)

本架構(gòu)摒棄了多功能模塊聯(lián)合組成系統(tǒng)的串行結(jié)構(gòu)，采用容錯(cuò)能力更強(qiáng)的并行結(jié)構(gòu)，避免了某一功能模塊失效會(huì)造成系統(tǒng)癱瘓的缺陷，提高了系統(tǒng)的魯棒性和可靠性。

1 艦船操控軟件的通用架構(gòu)總體設(shè)計(jì)

1.1 業(yè)務(wù)抽象模型

艦船操控軟件包含的每個(gè)單元功能模塊，都具備處理數(shù)據(jù)和產(chǎn)生數(shù)據(jù)的基本功能。如果將產(chǎn)生數(shù)據(jù)的模塊稱為生產(chǎn)者，處理數(shù)據(jù)的模塊稱為消費(fèi)者，這便是面向過(guò)程的生產(chǎn)者-消費(fèi)者設(shè)計(jì)模式。生產(chǎn)者的職責(zé)是負(fù)責(zé)制造、更新數(shù)據(jù)并放入緩沖區(qū)，消費(fèi)者的職責(zé)是獲取、處理數(shù)據(jù)。生產(chǎn)者和消費(fèi)者彼此之間不是直接通信，而是通過(guò)阻塞隊(duì)列來(lái)進(jìn)行通信。

為了實(shí)現(xiàn)軟件設(shè)計(jì)“高內(nèi)聚低耦合”的目標(biāo)，本文將生產(chǎn)者-消費(fèi)者模式引入嵌入式通用軟件架構(gòu)設(shè)計(jì)中，把功能模塊的業(yè)務(wù)邏輯抽象成“數(shù)據(jù)生產(chǎn)者-數(shù)據(jù)消費(fèi)者-數(shù)據(jù)倉(cāng)庫(kù)”模型，如圖2 所示。

圖2 業(yè)務(wù)抽象模型Fig.2 Business abstract model

基于以上業(yè)務(wù)邏輯抽象模型，將功能模塊視為數(shù)據(jù)生產(chǎn)者和消費(fèi)者的組合，各功能模塊將集合了眾多數(shù)據(jù)對(duì)象的數(shù)據(jù)倉(cāng)庫(kù)作為唯一的對(duì)外通信對(duì)象，于是建立起以數(shù)據(jù)交換為核心的功能模塊交互模型，如圖3所示。

圖3 功能模塊交互模型Fig.3 Interaction model of functional modules

軟總線技術(shù)的概念最早由CORBA 規(guī)范提出，它屬于一種中間件技術(shù)，是虛擬的數(shù)據(jù)信息傳輸線。CORBA 規(guī)范定義了一組標(biāo)準(zhǔn)接口，遵循該規(guī)范所開(kāi)發(fā)出的軟件模塊能夠相互通信，協(xié)作完成預(yù)期的任務(wù)，實(shí)現(xiàn)軟件模塊的“即插即用”。軟總線的技術(shù)優(yōu)勢(shì)恰好與數(shù)據(jù)倉(cāng)庫(kù)的需求相吻合，可以很好屏蔽底層硬件平臺(tái)、操作系統(tǒng)以及網(wǎng)絡(luò)傳輸協(xié)議的異構(gòu)性，降低各模塊之間的耦合性，實(shí)現(xiàn)在不同數(shù)據(jù)標(biāo)準(zhǔn)或格式的異構(gòu)系統(tǒng)之間進(jìn)行高效便捷的數(shù)據(jù)交換。

本文將生產(chǎn)者-消費(fèi)者設(shè)計(jì)模式與軟總線概念深度融合，搭建起艦船操縱控制軟件通用架構(gòu)，如圖4所示。該架構(gòu)提高了應(yīng)用系統(tǒng)的互聯(lián)、互通、互操作能力，大大增強(qiáng)了代碼的靈活性、復(fù)用性。

圖4 艦船操控軟件通用架構(gòu)示意Fig.4 General architecture hint of ship maneuvering control system software

1.2 面向數(shù)據(jù)交換的軟總線接口設(shè)計(jì)

本文所涉及的軟總線核心架構(gòu)主要包括3 部分：軟總線接口、數(shù)據(jù)交換池、通信接口，如圖5 所示。

圖5 軟總線分層結(jié)構(gòu)Fig.5 Hierarchical structure of software bus

1）軟總線接口，是軟總線架構(gòu)設(shè)計(jì)的關(guān)鍵和靈魂。它是提供給上層應(yīng)用功能模塊使用的標(biāo)準(zhǔn)接口類，擁有數(shù)據(jù)對(duì)象的數(shù)值、屬性讀取，數(shù)據(jù)更新通知事件的注冊(cè)、注銷等功能。軟總線接口的作用在于一方面解除了各功能模塊彼此之間的直接聯(lián)系，避免了相互調(diào)用接口導(dǎo)致的相互依賴；另一方面實(shí)現(xiàn)了數(shù)據(jù)的封裝，屏蔽了各種復(fù)雜的底層實(shí)現(xiàn)，為實(shí)現(xiàn)功能模塊即插即用的目標(biāo)提供了條件。

2）數(shù)據(jù)交換池，是存儲(chǔ)數(shù)據(jù)對(duì)象數(shù)據(jù)信息的倉(cāng)庫(kù)。數(shù)據(jù)交換池是在系統(tǒng)初始化時(shí)開(kāi)辟的一段連續(xù)的內(nèi)存區(qū)，存儲(chǔ)所有數(shù)據(jù)對(duì)象的實(shí)時(shí)數(shù)據(jù)。當(dāng)數(shù)據(jù)發(fā)生更新時(shí)新數(shù)據(jù)將覆蓋舊數(shù)據(jù)。觸發(fā)數(shù)據(jù)更新的情況只有2 種：

①功能模塊完成數(shù)據(jù)處理后，將結(jié)果寫入數(shù)據(jù)交換池指定位置；

②通信接口接收到新數(shù)據(jù)后，將新數(shù)據(jù)覆蓋至數(shù)據(jù)幀對(duì)應(yīng)的內(nèi)存空間。

3）通信接口，搭建了網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)設(shè)備互通的橋梁，實(shí)現(xiàn)了節(jié)點(diǎn)之間信息交互和共享。通信接口對(duì)上層應(yīng)用而言屏蔽了底層硬件、通信協(xié)議以及操作系統(tǒng)的差異，隔離了底層硬件和上層編程的關(guān)聯(lián)，使上層應(yīng)用能兼容不同操作系統(tǒng)，從而具有良好的可移植性。

1.3 艦船操控軟件的通用架構(gòu)設(shè)計(jì)

基于以上功能模塊抽象模型和軟總線設(shè)計(jì)，搭建應(yīng)用于艦船操控領(lǐng)域的嵌入式軟件通用架構(gòu)，如圖6所示。該設(shè)計(jì)采用分層架構(gòu)，從底至頂一共分為5 層：物理鏈路層，通信接口層，數(shù)據(jù)分發(fā)層，數(shù)據(jù)交換層，業(yè)務(wù)應(yīng)用層。

圖6 艦船操控軟件通用架構(gòu)分層設(shè)計(jì)Fig.6 Hierarchy design details of ship maneuvering control system software′s general architecture

1）物理鏈路層

物理鏈路層是指為數(shù)據(jù)端設(shè)備提供傳送通路、傳輸數(shù)據(jù)的具有物理形態(tài)的傳輸介質(zhì)和設(shè)備，主要表現(xiàn)為物理形態(tài)的總線或網(wǎng)絡(luò)，例如串口、以太網(wǎng)、CAN 總線、1553B 總線等。

2）通信接口層

通信接口層通過(guò)封裝一組具有統(tǒng)一格式的標(biāo)準(zhǔn)數(shù)據(jù)訪問(wèn)接口，屏蔽了通信硬件及其驅(qū)動(dòng)的差異性，實(shí)現(xiàn)了硬件驅(qū)動(dòng)的無(wú)關(guān)性，解決了節(jié)點(diǎn)設(shè)備之間通信所用的總線類型、接口方式、通信協(xié)議形式復(fù)雜多樣、難以統(tǒng)一的痛點(diǎn)。通信接口層對(duì)上統(tǒng)一了數(shù)據(jù)傳輸接口，對(duì)下封裝了具體總線的通信功能，在整個(gè)框架中起著承上啟下的作用。框架使用XML 配置文件來(lái)描述具體系統(tǒng)的通信通道及配置信息。

3）數(shù)據(jù)分發(fā)層

數(shù)據(jù)分發(fā)層實(shí)現(xiàn)通信數(shù)據(jù)路由、轉(zhuǎn)發(fā)功能，將來(lái)自通信接口層的數(shù)據(jù)作分流處理，如向上傳遞存儲(chǔ)到數(shù)據(jù)交換池，或者向其他通信通道透明轉(zhuǎn)發(fā)或者重新組幀轉(zhuǎn)發(fā)數(shù)據(jù)，或者進(jìn)行數(shù)據(jù)幀過(guò)濾、篩選處理等?？蚣苁褂肵ML 配置文件來(lái)描述具體系統(tǒng)的數(shù)據(jù)分發(fā)器及配置信息。

4）數(shù)據(jù)交換層

數(shù)據(jù)交換層包含數(shù)據(jù)交換池和軟總線對(duì)外接口。數(shù)據(jù)交換池是存儲(chǔ)數(shù)據(jù)對(duì)象的連續(xù)內(nèi)存區(qū)。功能模塊通過(guò)軟總線接口讀取或改寫數(shù)據(jù)對(duì)象對(duì)應(yīng)的數(shù)據(jù)交換池?cái)?shù)據(jù)，通信接口層接收的通信數(shù)據(jù)也會(huì)更新到對(duì)應(yīng)的數(shù)據(jù)交換池內(nèi)存區(qū)中。

5）業(yè)務(wù)應(yīng)用層

業(yè)務(wù)應(yīng)用層是系統(tǒng)所有應(yīng)用功能模塊的集合，涵蓋了執(zhí)行系統(tǒng)任務(wù)的具體功能實(shí)現(xiàn)。因?yàn)椴捎昧塑浛偩€技術(shù)，上層各功能模塊通過(guò)軟總線接口進(jìn)行信息交互，相互之間不可見(jiàn)，彼此基于數(shù)據(jù)而獨(dú)立運(yùn)行。

2 艦船操控軟件的通用架構(gòu)實(shí)現(xiàn)

2.1 系統(tǒng)架構(gòu)分解

軟件架構(gòu)分解作為識(shí)別架構(gòu)元素的有效手段，是建立層次清晰的系統(tǒng)組織結(jié)構(gòu)的前提和關(guān)鍵步驟。根據(jù)業(yè)務(wù)切分和功能分解，可以將艦船操控軟件系統(tǒng)劃分為如圖7 所示的層次結(jié)構(gòu)，主要分為底層數(shù)據(jù)交換包（DataExchange）和應(yīng)用任務(wù)執(zhí)行包(TaskExecute)兩大部分。

圖7 軟件系統(tǒng)架構(gòu)實(shí)現(xiàn)Fig.7 Architecture implementation of software system

2.1.1 底層數(shù)據(jù)交換包

底層數(shù)據(jù)交換包包含了軟總線的所有功能實(shí)現(xiàn)，負(fù)責(zé)讀取系統(tǒng)配置文件、加載子模塊、驅(qū)動(dòng)通信硬件、監(jiān)控設(shè)備狀態(tài)、接收數(shù)據(jù)、緩存數(shù)據(jù)及數(shù)據(jù)自動(dòng)發(fā)送，為TaskExecute 應(yīng)用層提供數(shù)據(jù)訪問(wèn)接口。其作用在于為上層應(yīng)用模塊屏蔽和隔離底層硬件的差異，解除了應(yīng)用層和底層的耦合關(guān)系，使上層應(yīng)用因?yàn)榛跀?shù)據(jù)運(yùn)行而可以專注于系統(tǒng)功能的實(shí)現(xiàn)，為TaskExecute 中各功能模塊的獨(dú)立和通用奠定了基礎(chǔ)。

底層數(shù)據(jù)交換包下的目錄包括驅(qū)動(dòng)(Driver)、數(shù)據(jù)分發(fā)器(Distributor)、數(shù)據(jù)解碼器(Decoder)、數(shù)據(jù)編碼器(Encoder)、配置文件解析器(XmlParser)、幀協(xié)議解析器(ProtocolParser)共6 大類基本框架模塊，如圖8 所示，其目錄結(jié)構(gòu)和具體描述見(jiàn)表1。

表1 底層數(shù)據(jù)交換包的目錄結(jié)構(gòu)Tab.1 Directory structure of data exchange package

圖8 數(shù)據(jù)接收序列圖Fig.8 Sequence diagram of receiving data

2.1.2 應(yīng)用任務(wù)執(zhí)行包

應(yīng)用任務(wù)執(zhí)行包是所有上層應(yīng)用功能模塊的集合，它的實(shí)現(xiàn)要點(diǎn)包括：

1）輸出接口描述需規(guī)范完備。本文采用XML 格式的配置文件來(lái)描述功能模塊的輸出數(shù)據(jù)對(duì)象的屬性；

2）通過(guò)軟總線接口與外界通信。功能模塊調(diào)用統(tǒng)一的軟總線接口來(lái)訪問(wèn)本地或遠(yuǎn)程的其他功能模塊的輸出數(shù)據(jù)；

3）相似功能模塊力求通用化。任務(wù)類型相似的功能模塊經(jīng)過(guò)抽象、封裝可以達(dá)到復(fù)用，如通道表決模 塊、PID 控制模塊等都具有很好的復(fù)用性；

4）專用功能模塊允許定制化。功能模塊的功能與系統(tǒng)要求的具體任務(wù)需求密不可分，需要開(kāi)發(fā)者編寫代碼實(shí)現(xiàn)擴(kuò)展定制，但對(duì)功能模塊的形式未做強(qiáng)制約束，這提高了對(duì)具體功能需求復(fù)雜性的適應(yīng)性。

2.2 系統(tǒng)配置信息描述模型

系統(tǒng)構(gòu)建的可配置化可使系統(tǒng)架構(gòu)擁有良好的擴(kuò)展性和靈活性。實(shí)現(xiàn)系統(tǒng)可配置化的前提是必須抽象出被描述對(duì)象的屬性，建立對(duì)應(yīng)的信息描述結(jié)構(gòu)模型，并且要求該模型能最小完備的刻畫對(duì)象特征。

2.2.1 系統(tǒng)通信協(xié)議描述模型

在實(shí)際系統(tǒng)開(kāi)發(fā)中面對(duì)的通信協(xié)議復(fù)雜多樣，對(duì)數(shù)據(jù)對(duì)象信息采用統(tǒng)一的形式進(jìn)行描述是實(shí)現(xiàn)系統(tǒng)構(gòu)建可配置化的關(guān)鍵。通過(guò)對(duì)數(shù)據(jù)對(duì)象的屬性進(jìn)行抽象，建立了數(shù)據(jù)對(duì)象的信息描述結(jié)構(gòu)。

2.2.2 通信接口配置描述模型

通信接口模塊與硬件平臺(tái)、操作系統(tǒng)、網(wǎng)絡(luò)協(xié)議等息息相關(guān)，以往的開(kāi)發(fā)模式是針對(duì)具體應(yīng)用專門開(kāi)發(fā)，無(wú)法做到支持多種總線類型、協(xié)議格式及軟硬件平臺(tái)。為了實(shí)現(xiàn)對(duì)上述差異因素的兼容，采取固化封裝共用業(yè)務(wù)邏輯、提取配置差異化信息的策略，抽象出了通信接口配置描述模型，具有配置靈活和擴(kuò)展便捷的優(yōu)點(diǎn)。

2.2.3 數(shù)據(jù)分發(fā)器配置描述模型

數(shù)據(jù)分發(fā)器用于描述通信接收數(shù)據(jù)的分發(fā)和路由方式，如上傳給數(shù)據(jù)緩存池、轉(zhuǎn)發(fā)至其他通信通道或數(shù)據(jù)篩選過(guò)濾等。

2.3 軟總線功能模塊設(shè)計(jì)

2.3.1 數(shù)據(jù)接收

通信接口模塊采用了環(huán)形緩沖區(qū)的數(shù)據(jù)結(jié)構(gòu)來(lái)緩存接收的數(shù)據(jù)幀，每個(gè)通信接口對(duì)應(yīng)一個(gè)環(huán)形緩沖區(qū)，保證一個(gè)環(huán)形緩沖區(qū)僅有一個(gè)讀用戶和一個(gè)寫用戶，不需要額外添加互斥保護(hù)機(jī)制就可以確保數(shù)據(jù)的安全性和正確性。用于描述數(shù)據(jù)接收的過(guò)程如圖8所示，接收數(shù)據(jù)的處理流程說(shuō)明如下：

1）通信接口（如CAN1）接收到數(shù)據(jù)，進(jìn)入中斷處理程序；

2）將數(shù)據(jù)幀寫入環(huán)形緩存區(qū)，并向通信接口管理類發(fā)送異步消息；

3）通信接口管理類收到接收數(shù)據(jù)的通知后，從環(huán)形緩存區(qū)讀取數(shù)據(jù)；

4）通信接口管理類將新接收的數(shù)據(jù)傳遞給數(shù)據(jù)分發(fā)管理者；

5）數(shù)據(jù)分發(fā)管理者將數(shù)據(jù)分發(fā)給Distributors.xml中配置的所有分發(fā)器，如通用分發(fā)器和數(shù)據(jù)轉(zhuǎn)發(fā)器；

6）通用分發(fā)器負(fù)責(zé)將數(shù)據(jù)幀拷貝到數(shù)據(jù)交換池內(nèi)指定的內(nèi)存區(qū)域，完成數(shù)據(jù)更新；

7）數(shù)據(jù)轉(zhuǎn)發(fā)器負(fù)責(zé)將數(shù)據(jù)通過(guò)CAN2 接口發(fā)送出去，完成數(shù)據(jù)的轉(zhuǎn)發(fā)。

2.3.2 數(shù)據(jù)發(fā)送

存儲(chǔ)在數(shù)據(jù)交換池內(nèi)的數(shù)據(jù)是經(jīng)過(guò)編碼器編碼處理的，可以在需要的時(shí)候直接發(fā)送。如果在Devices.xml配置文件中指定了發(fā)送頻率，本框架支持?jǐn)?shù)據(jù)幀的自動(dòng)周期發(fā)送功能，用于描述數(shù)據(jù)發(fā)送的過(guò)程如圖9 所示。

圖9 數(shù)據(jù)自動(dòng)發(fā)送序列圖Fig.9 Sequence diagram of sending data automatically

實(shí)現(xiàn)步驟說(shuō)明如下：

1）系統(tǒng)初始化時(shí)，由數(shù)據(jù)幀管理者（CPDOManager）創(chuàng)建定時(shí)器；

2）應(yīng)用層的功能模塊調(diào)用軟總線接口函數(shù)，獲取數(shù)據(jù)幀對(duì)象（CPDO）指針；

3）調(diào)用接口函數(shù)啟動(dòng)數(shù)據(jù)幀對(duì)象的自動(dòng)發(fā)送接口；

4）遍歷指定了自動(dòng)發(fā)送功能的所有數(shù)據(jù)幀。每次定時(shí)器輪轉(zhuǎn)周期到時(shí)，計(jì)算當(dāng)前時(shí)間與上次成功發(fā)送本幀數(shù)據(jù)的時(shí)間間隔；

5）當(dāng)時(shí)間間隔超過(guò)Devices.xml 中配置的發(fā)送時(shí)間間隔時(shí)，則通過(guò)指定通信通道將本數(shù)據(jù)幀發(fā)送出去；否則本次不發(fā)送。

2.3.3 數(shù)據(jù)訪問(wèn)

應(yīng)用層的功能模塊通過(guò)調(diào)用軟總線接口可以非常方便的訪問(wèn)數(shù)據(jù)對(duì)象，讀取實(shí)時(shí)數(shù)值或數(shù)據(jù)屬性。用于描述數(shù)據(jù)訪問(wèn)的過(guò)程如圖10 所示，以訪問(wèn)數(shù)據(jù)對(duì)象“航向”實(shí)時(shí)數(shù)值為例，說(shuō)明具體調(diào)用過(guò)程。

圖10 數(shù)據(jù)訪問(wèn)序列圖Fig.10 Sequence diagram of data access

1）在功能模塊里調(diào)用軟總線接口函數(shù)，獲取“航向”數(shù)據(jù)對(duì)象（CSignal）的指針；

2）獲得“航向”數(shù)據(jù)對(duì)象對(duì)應(yīng)數(shù)據(jù)交換池中的內(nèi)存空間的地址；

3）從數(shù)據(jù)交換池中讀取“航向”的原始數(shù)據(jù)；

4）調(diào)用“航向”數(shù)據(jù)對(duì)象的解碼器將數(shù)據(jù)交換池中的原始數(shù)據(jù)解碼；

5）返回“航向”數(shù)據(jù)對(duì)象的實(shí)時(shí)物理值。

2.4 軟總線跨平臺(tái)設(shè)計(jì)

本通用架構(gòu)的應(yīng)用環(huán)境是面向多操作系統(tǒng)平臺(tái)，要求具有兼容多平臺(tái)的能力，所以需要對(duì)操作系統(tǒng)的主要API 做統(tǒng)一封裝，使得用戶可以基于統(tǒng)一的接口來(lái)開(kāi)發(fā)各種嵌入式應(yīng)用程序，從而實(shí)現(xiàn)這些應(yīng)用程序在不同平臺(tái)上的代碼復(fù)用。本框架主要對(duì)Windows，Linux，VxWorks 操作系統(tǒng)的API 做了統(tǒng)一封裝，形成統(tǒng)一的標(biāo)準(zhǔn)接口。

3 結(jié) 語(yǔ)

本文提出的基于生產(chǎn)者-消費(fèi)者模式和軟總線技術(shù)的艦船操控系統(tǒng)通用軟件架構(gòu)，已經(jīng)成功應(yīng)用到艦船操縱控制系統(tǒng)軟件的開(kāi)發(fā)，反饋結(jié)果表明架構(gòu)具有良好的靈活性、可靠性、跨平臺(tái)性以及較高的運(yùn)行效率，能較好滿足多型號(hào)產(chǎn)品的適用性需求。下一步的工作重點(diǎn)是為了適應(yīng)操作系統(tǒng)國(guó)產(chǎn)化的需要，將開(kāi)展本框架向麒麟、道等國(guó)產(chǎn)操作系統(tǒng)移植的適應(yīng)性工作。