基于OPC技術的運載火箭地面設備測控系統架構研究

鄭國昆 蘇 娟 吳齊才 楊之江

(北京航天發射技術研究所 北京 100076)

0 引 言

運載火箭地面設備(以下簡稱地面設備)在運載火箭測試發射過程中，主要完成加注、供氣、瞄準、垂直度調整、加泄連接器脫落和擺桿控制等各個功能的射前準備工作。目前地面設備各分系統均已實現測控流程的電氣化，但各分系統僅在內部形成了測控流程的自動化體系，系統的交互少，各分系統間的測控系統技術水平參差不齊、標準不一，接口匹配設計復雜、兼容性差；各分系統測試數據分散，難以全面了解各系統測試狀態，上級指揮自動化程度低、發射決策效率低下，導致了測試發射準備周期長；各分系統測試設備重復配套，不利于研制成本的控制。

地面設備在運載火箭系統中屬于可重復使用的系統，隨著我國航天器高密度發射的常態化，對地面設備也提出了新的要求：1) 提升地面設備測控系統的通用性，避免各分系統單獨設計測控系統帶來的差異性問題以及各分系統內部接口不一致導致的兼容性問題；2) 提升地面設備測試的自動化程度，地面設備歷來是火箭系統中自動化程度相對低下的部分，靠人工完成的測試項目較多，實現測試流程自動化和判讀數據實時化，對節約人力，實現無人值守，縮短發射準備周期有重要意義，以避免高密度發射帶來的周期被迫縮短問題；3) 提高數據處理能力，實現試驗數據現場分析處理歸檔入庫，方便測試人員進行數據判讀、歷史數據查詢等。

在傳統的控制系統中，不同硬件控制設備之間的數據交互一般依靠不同的驅動程序實現，但硬件設備廠商提供的驅動程序功能相對固定，不滿足軟件設計人員的不同需求，當系統功能需求超過硬件設備廠商提供的驅動程序功能范圍時，軟件設計中就必須進行設備驅動程序設計環節，大大增加了軟件的復雜度，降低了系統的可維護性和可靠性。

OPC(Object Linking and Embedding for Process Control)技術的出現為此問題的解決提供了契機。OPC是基于過程控制的對象鏈接和嵌入(Object Linking and Embedding，OLE)技術[1]，是基于微軟公司的COM(部件對象模型)和DCOM(分布式部件對象模型)技術制定的自動化領域信息通信接口應用技術。基于OPC技術，可使硬件設備廠商之間具備了一套通用的依據和標準，由硬件設備廠商提供OPC服務器程序，軟件設計中僅需在滿足OPC規范的情況下，即可與不同的硬件設備進行數據交互，這樣就掃除了不同軟件和硬件之間的通信障礙，并且從根本上解決了軟件設計中必須為不同設備開發驅動程序的問題。同時，不同軟件之間由于數據接口不匹配帶來的通信問題也可通過OPC技術解決，為實現不同的系統及模塊間協調運行提供了可能[2-4]。

1 OPC技術規范及技術背景

1.1 OPC規范概述

OPC技術是在微軟公司的COM和DCOM基礎上發展的，因此具備面對對象的特征，OPC規范是包含了一系列的屬性和方法的集合，由OPC基金會進行發布和維護，作為全世界硬件設備廠商的研發規范。OPC規范主要包含實時數據存取規范(Data Access，DA)、報警與事件處理規范、歷史數據處理規范、批量數據過程規范、數據安全規范和數據交換規范等一系列規范。其中OPC DA規范是OPC規范的基礎，基于OPC DA規范的實時數據，其余的規范才得以建立發展[5-9]。

OPC DA規范有別于一般傳統的數據交互方式，其可使上位機與現場硬件設備在相互之間的通信規則未知的情況下還可以正常進行數據交互。OPC DA規范采用COM技術典型的C/S模式，一個OPC客戶端可以連接到一個或多個OPC DA服務器，一個OPC DA服務器可以與一個或多個客戶端相連接。其典型的結構模型如圖1所示。理論上OPC DA服務器可以和所有的硬件設備或實時數據源連接，因此使上位機軟件不需要為特定的硬件設備開發驅動程序。

圖1 OPC C/S模式典型架構圖

PC服務器是基于OPC規范的控制系統的重要組成部分，其主要功能是為對應設備提供符合OPC規范的接口和數據通信機制。OPC規范中要求硬件設備廠商必須提供符合規范的OPC服務器，以保證任何符合OPC規范的OPC客戶端均可實現對其的訪問和數據交互。同時，OPC規范要求所有的軟件廠商必須提供符合規范的OPC客戶端，以保證客戶端可訪問任何符合規范的OPC服務器，并與其進行數據交互。

OPC服務器內部結構由服務器(Server)對象、組(Group)對象和項(Item)對象組成，其中：Server對象維護自身信息和Group對象鏈表；Group對象維護自身信息和Item對象鏈表；Item對象內部維護自身信息，主要包括訪問權限、激活狀態、數據類型、數據值等。Server對象和Group對象為標準COM組件，提供標準接口，Item對象不提供客戶端接口，可自定義或派生于COM。這樣OPC服務器就可將對硬件設備的訪問封裝在內部，而只為OPC客戶端提供訪問接口，OPC客戶端僅需明確接口即可調用相應的服務完成功能，無須考慮訪問硬件設備這一復雜過程。OPC服務器內部結構如圖2所示。

圖2 OPC 服務器內部結構

圖3為OPC服務器和OPC客戶端數據流向圖。客戶端通過接口函數與服務器進行數據交互，客戶端用戶界面可實現對服務器端的操作；服務器通過驅動程序與硬件設備數據源進行數據交互，Server地址空間起保存具體數據源的作用，對象接口部分是客戶端和服務器進行數據傳遞的唯一途徑，服務器的用戶界面并非必須存在，一般只用作監測服務器運行狀態和客戶端數量等。

圖3 OPC 服務器和客戶端數據流向

1.2 地面設備測控系統常用架構

隨著我國航天運載火箭的發展，地面設備測控系統也經歷了從無到有，由簡入繁的過程，本文以包含3個分系統的地面設備測控系統為例，介紹地面設備測控系統的常用架構。

1) 分系統獨立的集成式測控系統：該系統架構原理圖如圖4所示，3個分系統獨立設計，互相之間沒有數據交互。分系統的內部采用上位機+系統測控單元的常用架構模式。系統測控單元是系統架構的核心，一般根據系統功能和性能需求選取PLC、單片機和實時控制器等硬件設備，控制執行器件(電機、電磁閥等)完成系統的規定動作，通過傳感器采集系統的各項參數和狀態。上位機運行用戶界面以完成監測和控制，與系統測控單元進行數據交互，顯示系統的參數和狀態，并完成數據處理和存儲等功能。此種系統架構下，數據交互必須通過驅動程序執行，而不同的分系統的具體的硬件設備和廠商均不同，導致不同分系統的數據交互需要的驅動程序不一致，軟件開發難度大，系統通用性和可維護性差，并且各分系統獨立運行，時間難以統一也是一大難題。發射測試過程中，各分系統會產生大量的數據，由于各分系統數據獨立處理和存儲，當分系統工作存在測試流程上的邏輯性時，數據后處理和分析的工作量也相當巨大。

2) 地面設備集成測控系統：系統架構原理圖如圖5所示，在系統架構1)的基礎上，增加指揮控制單元和數據處理單元。指揮控制單元和數據處理單元可以與各分系統的上位機進行數據交互，指揮控制單元負責發射測試過程的指揮調度協調功能，提升發射測試過程的指揮調度自動化，數據處理單元負責將測試過程中各分系統產生的數據進行實時處理和存儲，并在此基礎上，為實現全系統的數據實時監測判讀提供了條件。但是，此種系統仍然以系統架構1)為基礎，沒有脫離分系統獨立的拓撲結構，并且與系統測控單元的數據交互仍然需要單獨設計，很難做到接口一致。

圖5 集成式測控系統架構

2 系統架構設計

為解決地面設備各分系統測控單元選型不一，設備接口不一致等問題，本文提出一種基于OPC技術的地面設備測控系統架構，如圖6所示。系統架構采取分層式架構設計，分為現場設備層、OPC服務器層、OPC客戶端層和系統應用層。

圖6 基于OPC技術的地面設備測控系統架構

1) 現場設備層。仍以3個分系統為例，包括各分系統的測控單元、執行器件和傳感器，分系統1與分系統2的測控單元選型相同的情況下，二者可共用相同驅動程序接口，但分系統3的測控單元與其余分系統不同，因此驅動程序接口不一致。

2) OPC服務器層。分系統1與分系統2的驅動程序相同，因此二者共用同一OPC DA服務器，分系統3使用不同的OPC DA服務器，兩個OPC DA服務器可以依據OPC 數據交換規范進行數據交互，數據交互過程由OPC數據交換服務器實現。這樣在OPC服務器層即可實現數據交互，當某一分系統存在造成多個分系統的人員和設備安全風險的故障時，可通過OPC數據交換服務器使其余分系統得知，并應急處理，提升了應急處理信息的傳遞速率。在OPC DA服務器的基礎上，依據OPC報警與事件處理規范建立OPC報警處理(AE)服務器，用于對實時數據采集后進行簡單的判斷和相應。依據OPC歷史數據處理規范建立OPC歷史數據處理(HDA)服務器，用于OPC服務器層對實時數據進行趨勢等分析。最后，OPC服務器層依據OPC規范，向OPC客戶端提供接口以供調用。

3) OPC客戶端層。包含OPC DA、OPC AE、OPC HDA客戶端，可通過客戶端調用接口完成與各自服務器的數據交互，并且在客戶端層設置OPC服務器配置工具，用于對OPC服務器層包含的服務器進行配置，作為系統擴充和更改時使用。

4) 系統應用層。系統應用層的主要作用是提供面向用戶的用戶界面、實時數據處理和存儲，測試數據中心將地面設備過程中的所有測試數據進行實時處理，按照預先設定好的處理方法進行處理，完成后進行數據庫操作，并將數據提供給需要的模塊。分系統1-分系統3用戶界面為各分系統人員進行測試操作、監測和控制的人機界面接口。地面設備指揮控制用戶界面實現發射測試過程的指揮調度協調功能，提升發射測試過程的指揮調度自動化，使各分系統按照測試流程順序執行動作。數據瀏覽用戶界面基于實時測試數據中心和歷史數據庫建立，用于在發射測試過程中及發射后進行數據瀏覽、數據報表、數據判讀及數據導出等功能的實現。在測試發射的不同階段，對地面設備的技術狀態要求不一，因此應用層配置工具主要完成測試流程配置、指令配置、參數配置和用戶界面配置等功能。

圖6所示的系統架構中，現場設備層和OPC服務器層之間的數據交互需要硬件設備的驅動程序支持。基于OPC規范，硬件設備廠商在為其硬件設備開發OPC服務器時，已經將驅動程序一并包含并提供，因此不需要系統軟件設計人員再重復開發，軟件設計人員僅需依據OPC服務器提供的接口進行相應的客戶端開發即可實現與所有的硬件設備的數據交互，最大限度保證了設計通用性，無論哪個分系統，對于OPC客戶端而言，接口均一致，保證了客戶端及系統應用層軟件的通用性。

本文提出的系統架構中，分系統作為地面設備測控系統的一部分嵌入到系統架構中，利用應用層配置工具可進行測試流程配置，可快速完成不同分系統的測試流程界面的配置，免去大量測試流程調整的工作。

在測控系統內部出現故障時，采取對OPC服務器進行配置的方式，對地面設備測控系統架構進行在線重構，保證系統除故障點外的其余部分不受故障影響，可繼續完成測試流程，提升了系統的容錯能力和可維護性。實時數據和歷史數據均統一維護在實時數據中心和歷史數據庫中，保證數據的完整性及數據采集格式的統一，便于進行數據判讀和報表分析等工作。

3 結 語

本文首先提出當前運載火箭地面設備測控系統的需求，分析OPC技術規范的原理和優勢，其次在概括了當前地面設備測控系統的常用架構的弊端的基礎上，提出了基于OPC技術的運載火箭地面設備測控系統架構，介紹其組成，并重點描述了各虛擬層的功能，最后著重分析了提出的系統架構相對于常用架構在工作量、可維護性和擴充能力方面的優勢。基于OPC技術的運載火箭地面設備測控系統，可大大減少系統軟件設計的工作量，使之更集中于系統功能的實現而非底層驅動的實現上，可提高系統的擴充能力和容錯能力，其數據維護的方式更為合理，為后續數據判讀智能化、測試流程全自動化發展奠定了基礎，為實現運載火箭加注發射測試過程無人值守提供了可行的思路。