專利名稱：星形半雙工鏈路中從站主動通信方法
星形半雙工鏈路中從站主動通信方法
技術領域：
本發(fā)明涉及移動通信和工業(yè)控制領域，尤其涉及一種星形半雙工鏈路中 從站主動通信方法。
背景技術：
作為計算機技術與移動通信技術的交叉應用，集中監(jiān)控技術在對移動通 信系統(tǒng)的各個分布式工作節(jié)點的監(jiān)控中起到非常關鍵的作用。通常一個集中 監(jiān)控系統(tǒng)包括多個工作端，根據(jù)不同的拓樸結構組成不同的網(wǎng)絡，也就組成 了不同的數(shù)據(jù)鏈路?，F(xiàn)實應用中，集中監(jiān)控的數(shù)據(jù)鏈路結構可以分為兩種，
即點對點鏈路和點對多鏈路，如圖l所示，圖1 (a)中，僅有兩個節(jié)點，即 點對點鏈路；圖1 (b)則為點對多鏈路。如果這些數(shù)據(jù)鏈路是通過半雙工物 理通道(如RS- 485 )連接的，則稱之為半雙工集中監(jiān)控數(shù)據(jù)鏈路結構。
通常，發(fā)送信息和命令的節(jié)點稱為主站，接收信息和命令而發(fā)出響應的 節(jié)點則稱為從站。在集中監(jiān)控系統(tǒng)中只有一個主站，其它皆為從站。監(jiān)控中 心通過主站與從站進行通信。在半雙工集中監(jiān)控數(shù)據(jù)鏈路中，站與站之間的 通信鏈路是一直存在的，中間不需要建立鏈路和拆除鏈路。所有站點都可以 收到通信鏈路上的數(shù)據(jù)包，如果數(shù)據(jù)包的目的地址與本站的地址不同，則丟 棄該數(shù)據(jù)包，否則則做進一步的處理。為了防止數(shù)據(jù)沖突，任一時刻鏈路中 處于數(shù)據(jù)發(fā)送狀態(tài)的站點只能是一個。因此，集中監(jiān)控系統(tǒng)中站與站之間的 數(shù)據(jù)交互只能采取一 問 一答的方式，并且理論上從站不能主動發(fā)起通信請求。
在一些分布式系統(tǒng)中，由于主站與各從站距離較遠，因此需要從從站端 獲取到主站的相關參數(shù)信息，這時，從站與主站主動通信的技術就顯得尤為 重要。

發(fā)明內(nèi)容
本發(fā)明的目的就是要克服上述不足，提供一種從站能主動進行通信實現(xiàn)
交互通信的星形半雙工鏈路中從站主動通信方法。
本發(fā)明的目的是通過如下技術方案實現(xiàn)的 本發(fā)明星形半雙工鏈路中從站主動通信方法，包括如下步驟
1) 、主站定時發(fā)出令牌包在多個從站之間輪詢；
2) 、從站在發(fā)出令牌回應包的同時或之前完成主動命令發(fā)送過程；
3) 、從站向主站發(fā)送令牌回應包。
根據(jù)本發(fā)明的第一實施例所揭示的內(nèi)容，步驟2)中主動命令發(fā)送過程 可包括、如下步驟
I、 從站收到主站的令牌包后，將需發(fā)送的命令包發(fā)送至主站；
II、 主站收到命令包后向該從站發(fā)回命令回應包；
III、 若從站尚需發(fā)送命令包，則繼續(xù)將命令包發(fā)出，然后回到步驟II繼 續(xù)執(zhí)行，否則執(zhí)行步驟IV;
IV、 /人站向主站發(fā)回令"皁回應包。
根據(jù)本發(fā)明的第二實施例所揭示的內(nèi)容，步驟2)中主動命令發(fā)送過程 包括如下步驟
2.1、 從站收到主站的令牌包后，將需發(fā)送的命令包發(fā)送至主站；
2.2、 主站收到命令包后向該從站發(fā)回命令回應包；
2.3、 主站繼續(xù)發(fā)送令牌包至從站，若從站有需發(fā)送的命令包，則重復步 驟2.1)和2.2),否則執(zhí)行步驟2.4);
2.4、 ^人站向主站發(fā)回令jf牟回應包。
根據(jù)本發(fā)明的第三實施例所示揭示的內(nèi)容，步驟2)中主動命令發(fā)送過 程包括如下步驟
a、從站收到主站的令牌包后，將待發(fā)送的命令包與令牌回應包組合生成 組合包并發(fā)送到主站；
命令包向神目應的乂人^占發(fā)出命令回應包。
此外，根據(jù)本發(fā)明第四實施例所揭示的內(nèi)容，為了實現(xiàn)從站與從站之間 的通信，在上述實施例中，主站在收到從站發(fā)來的數(shù)據(jù)包后，辨別其中命令
包的目的地址，并將目的地址為其它從站的命令包轉發(fā)至目的從站，然后等 候該從站回復的命令回應包，并將其作為數(shù)據(jù)包轉發(fā)至發(fā)送該命令包的源從站。
在本發(fā)明中，主站接收所有從站發(fā)出的數(shù)據(jù)包，而從站只處理源站為主 站但目的站為本站的數(shù)據(jù)包，通過此一約束發(fā)揮主站的中心控制的作用。
進一步的，為避免總線沖突，當前站處于等待狀態(tài)時，不允許發(fā)送令牌 或命令包到總線上。
為增強通信流程的可靠性，可設置異常處理機制，即主站和/或從站在發(fā) 送或等待數(shù)據(jù)包之前，預設定時參數(shù)，如果數(shù)據(jù)接收超過該定時參數(shù)，則復 位重新處理相關數(shù)據(jù)。
與現(xiàn)有技術相比，本發(fā)明具備如下優(yōu)點通過應用簡單的技術，在收到 令牌及回應該令牌之間發(fā)送從站的命令包，化被動為主動，解決了從站與主 站以及從站與從站之間的主動通信的問題。


圖1為數(shù)據(jù)鏈路結構原理示意圖，其中(a)為點對點示意圖，(b)則為 點對多示意圖2為本發(fā)明第一實施例從站與主站通信時的原理示意圖3為本發(fā)明所采用的軟件的模型圖4為本發(fā)明第一實施例主站通信機制接收程序流程圖5為本發(fā)明各實施例通用的主站通信機制發(fā)送程序流程圖6為本發(fā)明第一實施例從站通信機制處理流程圖7為本發(fā)明第二實施例從站與主站通信時的原理示意圖8為本發(fā)明第二實施例主站通信機制接收程序流程圖9為本發(fā)明第二實施例從站通信機制處理流程圖10為本發(fā)明第三實施例從站與主站通信時的原理示意圖11為本發(fā)明第三實施例主站通信機制接收程序流程圖12為本發(fā)明第三實施例從站通信機制處理流程圖13為本發(fā)明第四實施例/人站與主站通信時的原理示意圖。
具體實施方式
下面結合附圖和實施例對本發(fā)明作進 一 步的說明
在集中監(jiān)控系統(tǒng)中，主站需要不斷收集從站的參數(shù)，如果從站出現(xiàn)異常， 主站必須立刻向監(jiān)控中心報告。主站收集從站參數(shù)是通過定時向各個從站發(fā) 送詢問命令數(shù)據(jù)包，從站響應詢問數(shù)據(jù)包來實現(xiàn)的。這種幀格式相對固定的 輪詢數(shù)據(jù)包被稱為令牌。令牌的響應數(shù)據(jù)包稱之為令牌回應包。如果是因其 它需要發(fā)出的主動通信數(shù)據(jù)包，稱之為命令，命令的響應數(shù)據(jù)包則稱之為命 令回應包。
請參閱圖2,本發(fā)明星形半雙工鏈路中從站主動通信方法第一實施例的 原理示意圖中，左右兩側分別包括主站和/人站，主站與/人站的通信過程如下
1) 、主站定時發(fā)出令牌包在多個從站之間輪詢；
2) 、從站收到主站的令牌包后，將需發(fā)送的命令包發(fā)送至主站；
3) 、主站收到命令包后向該從站發(fā)回命令回應包；
4) 、若從站尚需發(fā)送命令包，則繼續(xù)將命令包發(fā)出，然后回到步驟3) 繼續(xù)執(zhí)行，否則執(zhí)行步驟5);
5) 、從站向主站發(fā)回令牌回應包。
在上述步驟中，主站接收所有從站發(fā)出的數(shù)據(jù)包，而從站只處理源站為 主站但目的站為本站的數(shù)據(jù)包，通過此一約束發(fā)揮主站的中心控制的作用。
進一步的，為避免總線沖突，當前站處于等待狀態(tài)時，不允許發(fā)送令牌 或命令包到總線上。
為增強通信流程的可靠性，可設置異常處理機制，即主站和/或從站在發(fā) 送或等待數(shù)據(jù)包之前，預設定時參數(shù)，如果數(shù)據(jù)接收超過該定時參數(shù)，則復 位重新處理相關數(shù)據(jù)。
如果從站還有命令需要發(fā)送給主站，則不斷重復上述過程。
請參閱圖3，圖3揭示了實現(xiàn)上述方法的軟件模型，包括總線端口驅(qū)動 模塊，通信機制實現(xiàn)模塊，令牌管理模塊以及應用模塊。該軟件模型應用于 集中監(jiān)控系統(tǒng)中，以下通過圖4至圖6中的流程圖進一步揭示其通信機制的 具體實現(xiàn)。
圖4為主站通信機制接收程序的流程圖。進入主站通信機制接收處理進 程后，不斷檢測是否從總線上收到數(shù)據(jù)包，當接收到數(shù)據(jù)包時，檢測主站是
否處于令牌回應等待狀態(tài)。
如果主站處于令牌回應等待狀態(tài)，則進一步檢查所收到的數(shù)據(jù)包的類型， 若不是從站發(fā)來的命令包，則為令牌回應包，將該令牌回應包交給本站的令
牌管理模塊處理，當處理完畢時，將主站當前狀態(tài)修改為空閑狀態(tài)，并繼續(xù)
檢測總線是否有數(shù)據(jù)包；若所接收到的數(shù)據(jù)包為命令包，則判斷其目的站是 否本主站，如是，將命令包交給本站應用模塊處理，繼續(xù)檢測總線數(shù)據(jù)包， 如不是，則當前數(shù)據(jù)包不可識別，將其丟棄，繼續(xù)偵察總線數(shù)據(jù)包；
如果主站不是處于令牌回應狀態(tài)，則進一步檢查主站是否處于命令回應 等待狀態(tài)，如不是，則表明當前包不可識別，將其丟棄后繼續(xù)檢測總線數(shù)據(jù)， 如主站處于命令回應等待爿大態(tài)，則分纟斤該命令回應包，如果該包是響應本站 的，則將該命令回應包交給本站應用模塊，將主站當前狀態(tài)修改成空閑狀態(tài) 后繼續(xù)檢測總線數(shù)據(jù)，否則，當前包不可識別，將其丟棄，繼續(xù)檢測總線數(shù) 據(jù)。
如此不斷循環(huán)，可保i正主站通信才幾制的正常工作。
圖5中，進一步揭示了主站通信機制發(fā)送程序的流程圖，進入發(fā)送進程 后，不斷檢測是否有數(shù)據(jù)包要發(fā)送到總線上，如果有需要，則調(diào)用總線端口 驅(qū)動將數(shù)據(jù)包發(fā)送，然后，依據(jù)該數(shù)據(jù)包的類型修改不同的狀態(tài)，即，當數(shù) 據(jù)包為令牌包時，修改主站當前狀態(tài)為令牌回應等待狀態(tài)；當數(shù)據(jù)包為命令 時，修改主站當前狀態(tài)為命令回應等待狀態(tài)并記錄等待命令回應的站點為本 站。當上述狀態(tài)信息修改完畢后，繼續(xù)檢測是否需要發(fā)送數(shù)據(jù)包。圖5中的 原理適應于本發(fā)明的各個實施例中。
圖6為從站通信機制處理程序流程圖，該進程不斷檢測總線上的數(shù)據(jù)包， 當收到數(shù)據(jù)包時，檢測本站的狀態(tài)。
若本站處于空閑狀態(tài)時，進一步檢查數(shù)據(jù)包類型，對于命令包，將其交 給本站的應用模塊處理，對于令牌包，則首先確定本站是否有命令包要發(fā)送， 若無，把令牌包交給本站令牌管理模塊進行常規(guī)處理即可，若有，則調(diào)用總 線端口驅(qū)動將命令包發(fā)送，并修改本站當前狀態(tài)為命令回應等待狀態(tài)，繼續(xù)
不斷對總線的數(shù)據(jù)包進行檢測。
若本站非處于空閑狀態(tài)，則進一步檢測本站是否處于命令回應等待狀態(tài)， 如果不是，則表明當前包不可識別，將其丟棄，如果是命令回應等待狀態(tài)， 則還需先確認收到的數(shù)據(jù)包是否為命令回應包，如果不是，同理丟棄，如果
是命令回應包，則將命令回應包交給本站應用模塊處理，然后進一步判斷所 有命令包是否已全部發(fā)送完畢，如是，則不斷調(diào)用總線端口驅(qū)動將待發(fā)送的 命令包發(fā)送，修改本站當前狀態(tài)成命令回應等待狀態(tài)，如此循環(huán)至所有命令
包發(fā)送完畢后，發(fā)送令牌回應包到主站，修改本站當前狀態(tài)為空閑狀態(tài)。繼 續(xù)不斷循環(huán)檢測總線數(shù)據(jù)包。
上述第一實施例技術簡單，解決了從站與主站主動通信的根本性問題， 適宜應用于從站有連續(xù)多個命令包發(fā)送到主站的情況，此時，從站主動通信 的效率接近于主站發(fā)起的通信。
請參閱圖7,本發(fā)明的第二實施例的原理示意圖中，左右兩側分別包括
主站和從站，主站與從站的通信過程如下
1) 、主站定時發(fā)出令牌包在多個從站之間輪詢；
2) 、從站收到主站的令牌包后，將需發(fā)送的命令包發(fā)送至主站； 3 )、主站收到命令包后向該從站發(fā)回命令回應包；
4) 、主站繼續(xù)發(fā)送令牌包至從站，若從站有需發(fā)送的命令包，則重復步 驟2 )和3 )，否則執(zhí)行步驟5 );
5) 、從站向主站發(fā)回令牌回應包，結束從站的主動命令包過程。
同理，在上述步驟中，主站接收所有從站發(fā)出的數(shù)據(jù)包，而從站只處理 源站為主站但目的站為本站的數(shù)據(jù)包，通過此一約束發(fā)揮主站的中心控制的 作用。
進一步的，為避免總線沖突，當前站處于等待狀態(tài)時，不允許發(fā)送令牌 或命令包到總線上。
為增強通信流程的可靠性，可設置異常處理機制，即主站和/或從站在發(fā) 送或等待數(shù)據(jù)包之前，預設定時參數(shù)，如果數(shù)據(jù)接收超過該定時參數(shù)，則復 位重新處理相關數(shù)據(jù)。
如果從站還有命令需要發(fā)送給主站，則不斷重復上述過程。
本實施例使用與第 一 實施例相同的軟件模型。以下結合附圖進一步揭示 其通信機制的具體實現(xiàn)。
圖8為主站通信機制接收程序的流程圖。進入主站通信機制接收處理進 程后，不斷檢測是否從總線上收到數(shù)據(jù)包，當接收到數(shù)據(jù)包時，檢測主站是
否處于令牌回應等待狀態(tài)。
如果主站處于令牌回應等待狀態(tài)，則進一步檢查所收到的數(shù)據(jù)包的類型， 若不是從站發(fā)來的命令包，則為令牌回應包，將該令牌回應包交給本站的令 牌管理模塊處理，當處理完畢時，將主站當前狀態(tài)修改為空閑狀態(tài)，并繼續(xù)
檢測總線是否有數(shù)據(jù)包；若所接收到的數(shù)據(jù)包為命令包，則判斷其目的站是 否本主站，如是，將命令包交給本站應用模塊處理，繼續(xù)檢測總線數(shù)據(jù)包， 如不是，則其目的站為其它從站，修改命令包的源站為本站，調(diào)用總線端口 驅(qū)動將數(shù)據(jù)包發(fā)送，修改主站當前狀態(tài)成命令回應等待狀態(tài)，記錄等待的站 點，繼續(xù)偵察總線數(shù)據(jù)包；
如果主站不是處于令牌回應狀態(tài)，則進一步檢查主站是否處于命令回應 等待狀態(tài)，如不是，則表明當前包不可識別，將其丟棄后繼續(xù)檢測總線數(shù)據(jù)， 如主站處于命令回應等待狀態(tài)，則分析該命令回應包，如果該包是響應本站 的，則將該命令回應包交給本站應用模塊，將主站當前狀態(tài)修改成空閑狀態(tài) 后繼續(xù)檢測總線數(shù)據(jù)，否則，則表明其它從站為等待回應的站點，修改命令 回應包的源站為本站，目標站為等待回應的從站，調(diào)用總線端口驅(qū)動將數(shù)據(jù) 包發(fā)送，將主站當前狀態(tài)修改成空閑狀態(tài)，繼續(xù)偵察總線數(shù)據(jù)包。
如此不斷循環(huán)，可保i正主站通信才幾制的正常工作。
本實施例的發(fā)送程序則與第一實施例圖5所示的發(fā)送程序相同。
圖9為本實施例的從站通信機制處理程序流程圖，該進程不斷檢測總線 上的數(shù)據(jù)包，當收到數(shù)據(jù)包時，檢測本站的狀態(tài)。
若本站處于空閑狀態(tài)時，進一步檢查數(shù)據(jù)包類型，對于命令包，將其交 給本站的應用模塊處理，對于令牌包，則首先確定本站是否有命令包要發(fā)送， 若無，把令牌包交給本站令牌管理模塊進行常規(guī)處理即可，若有，則調(diào)用總 線端口驅(qū)動將命令包發(fā)送，并修改本站當前狀態(tài)為命令回應等待狀態(tài)，繼續(xù) 不斷對總線的數(shù)據(jù)包進行檢測。
若本站非處于空閑狀態(tài)，則進一 步檢測本站是否處于命令回應等待狀態(tài)， 如果不是，則表明當前包不可識別，將其丟棄，如果是命令回應等待狀態(tài)， 則還需先確認收到的數(shù)據(jù)包是否為命令回應包，如果不是，同理丟棄，如果 是命令回應包，則將命令回應包交給本站應用模塊處理，修改本站當前狀態(tài) 為空閑狀態(tài)。繼續(xù)不斷循環(huán)檢測總線數(shù)據(jù)包。
上述有關第二實施例所揭示的技術相對更為簡單，同樣解決了從站與主
站主動通信的4艮本性問題。
以下進一步揭示第三實施例，請參閱圖IO所示的第三實施例的原理示意 圖，圖10中，左右兩側分別包括主站和從站，主站與從站的通信過程如下
1) 、主站定時發(fā)出令牌包在多個從站之間輪詢；
2) 、從站收到主站的令牌包后，將待發(fā)送的命令包與令牌回應包組合生 成組合包并發(fā)送到主站；
3) 、主站將收到的組合包還原分解成令牌回應包和命令包，并響應所述
命令包向相應的從站發(fā)出命令回應包。
同理，在上述步驟中，主站接收所有從站發(fā)出的數(shù)據(jù)包，而從站只處理 源站為主站但目的站為本站的數(shù)據(jù)包，通過此一約束發(fā)揮主站的中心控制的 作用。
進一步的，為避免總線沖突，當前站處于等待狀態(tài)時，不允許發(fā)送令牌 或命令包到總線上。
為增強通信流程的可靠性，可設置異常處理機制，即主站和/或從站在發(fā) 送或等待數(shù)據(jù)包之前，預設定時參數(shù)，如果數(shù)據(jù)接收超過該定時參數(shù)，則復 位重新處理相關數(shù)據(jù)。
如果從站還有命令需要發(fā)送給主站，則不斷重復上述過程。
本實施例使用與第一實施例相同的軟件模型(參見圖3及其相關的描 述)，以下結合附圖進一步揭示其通信機制的具體實現(xiàn)。
圖11為本實施例主站通信機制接收程序的流程圖。進入主站通信機制接 收處理進程后，不斷檢測是否從總線上收到數(shù)據(jù)包，當接收到數(shù)據(jù)包時，檢 測主站是否處于令牌回應等待狀態(tài)。
如果主站處于令牌回應等待狀態(tài)，則進一步檢查所收到的數(shù)據(jù)包的類型，
若不是組合包，則為令牌回應包，將該令牌回應包交給本站的令牌管理模塊
處理，當處理完畢時，將主站當前狀態(tài)修改為空閑狀態(tài)，并繼續(xù)檢測總線是
否有數(shù)據(jù)包；若所接收到的數(shù)據(jù)包為組合包，則把組合包還原分解成令牌回 應包和命令包，同理，令牌回應包交回令牌管理模塊做后續(xù)處理，而對于命
令包則判斷其目的站是否本主站，如是，將命令包交給本站應用模塊處理， 如不是，則修改命令包中的源站為本站，調(diào)用總線端口驅(qū)動將數(shù)據(jù)包發(fā)送，
修改主站當前狀態(tài)成命令回應等待狀態(tài)，記錄等待的站點之后，返回繼續(xù)檢
測總線的數(shù)據(jù)包；
如果主站不是處于令牌回應狀態(tài)，則進一步檢查主站是否處于命令回應 等待狀態(tài)，如不是，則表明當前包不可識別，將其丟棄后繼續(xù)檢測總線數(shù)據(jù)， 如主站處于命令回應等待狀態(tài)，則分析該命令回應包，如果該包是響應本站 的，則將該命令回應包交給本站應用模塊，將主站當前狀態(tài)修改成空閑狀態(tài) 后繼續(xù)檢測總線數(shù)據(jù)，否則，則修改命令回應包的源站為本站，目標站為等 待回應的從站，然后調(diào)用總線端口驅(qū)動將數(shù)據(jù)包發(fā)送，將主站當前狀態(tài)修改 成空閑狀態(tài)后繼續(xù)檢測總線數(shù)據(jù)。
如此不斷循環(huán)，可保證主站通信機制的正常工作。
本實施例的主站發(fā)送程序流程圖與圖5相同，請參閱第一實施例中有關 圖5的描述。
圖12為本實施例從站通信機制處理程序流程圖，該進程不斷檢測總線上 的數(shù)據(jù)包，當收到數(shù)據(jù)包時，檢測本站的狀態(tài)。
若本站處于空閑狀態(tài)時，進一步檢查數(shù)據(jù)包類型，對于命令包，將其交 給本站的應用模塊處理，對于令牌包，則首先確定本站是否有命令包要發(fā)送， 若無，把令牌包交給本站令牌管理模塊進行常規(guī)處理即可，若有，則組合令 牌回應包和本站的命令包，然后調(diào)用總線端口驅(qū)動將組合包發(fā)送，并修改本 站當前狀態(tài)為命令回應等待狀態(tài)，繼續(xù)不斷對總線的數(shù)據(jù)包進行檢測。
若本站非處于空閑狀態(tài)，則進一步檢測本站是否處于命令回應等待狀態(tài)， 如果不是，則表明當前包不可識別，將其丟棄，如果是命令回應等待狀態(tài)， 則還需先確認收到的數(shù)據(jù)包是否為命令回應包，如果不是，同理丟棄，如果 是命令回應包，則將命令回應包交給本站應用模塊處理，然后修改本站當前 狀態(tài)為空閑狀態(tài)。繼續(xù)不斷循環(huán)4企測。
通過上述有關第三實施例的描述，可知，本實施例因為涉及組包與分包 技術的增加，會使技術實現(xiàn)相對于傳統(tǒng)技術具有一定的復雜性，此外，由于 從站主動通信的速度信賴于主站發(fā)給該從站令牌包的頻率，因此，本實施例 的技術宜應用于對從站主動通信速度不太苛刻的情況。
但是，本實施例保證了令牌回應的及時娃，使從站狀態(tài)參數(shù)的收集頻率 不受從站主動通信的影響，因此相對傳統(tǒng)技術而言，整體效率得以保證，更 重要的，本實施例解決了從站與主站主動通信的根本性問題。 有關本發(fā)明第四實施例，請結合圖13,圖13為第四實施例的原理示意 圖，圖13中包括一個主站和從站1、從站2,第四實施例為第二實施例的一
個改型，與第二實施例比較，第四實施進一步揭示了從站與從站之間進行主 動通信的技術方案。具體而言，本實施例是在從站1收到主站發(fā)來的令牌后， 發(fā)送命令包，然后主站將該命令包轉發(fā)給從站2,從站2繼而回發(fā)命令回應 包至主站，主站再將其回發(fā)至從站1,以此一步驟進一步實現(xiàn)從站與從站之 間的通寸言。
相應的，也可在第一實施例和第三實施例的基礎，利用與第四實施例相 同的原理，實現(xiàn)從站與從站之間的通信，概括而言，在上述前三個實施例中， 主站在收到從站發(fā)來的數(shù)據(jù)包后，辨別其中命令包的目的地址，并將目的地 址為其它從站的命令包轉發(fā)至目的從站，然后等候該從站回復的命令回應包， 并將其作為數(shù)據(jù)包轉發(fā)至發(fā)送該命令包的源從站。即可實現(xiàn)從站與從站之間 的主動通信。
綜上所述，本發(fā)明實現(xiàn)了星形半雙工鏈路中從站與主站、從站與從站之 間的主動通信技術方案，克服了傳統(tǒng)技術中的不足，使集中監(jiān)控系統(tǒng)的功能 得以大大增強。
如上所述，盡管參照特定的優(yōu)選實施例已經(jīng)表示和描述了本發(fā)明，但其 不得解釋為對本發(fā)明自身的限制，本領域的技術人員應該明白，在不脫離所 附權利要求定義的本發(fā)明的精神和范圍的前提下，可對其在形式上和細節(jié)上 作出各種變化。所附的權利要求書覆蓋了本發(fā)明精神和范圍內(nèi)的所有這些改 變和^f奮改。
權利要求
1、一種星形半雙工鏈路中從站主動通信方法，其特征在于包括如下步驟1)、主站定時發(fā)出令牌包在多個從站之間輪詢；2)、從站在發(fā)出令牌回應包的同時或之前完成主動命令發(fā)送過程；3)、從站向主站發(fā)送令牌回應包。
2、 根據(jù)權利要求1所述的星形半雙工鏈路中從站主動通信方法，其特 征在于步驟2)中主動命令發(fā)送過程包括如下步驟I、 從站收到主站的令牌包后，將需發(fā)送的命令包發(fā)送至主站；II、 主站收到命令包后向該從站發(fā)回命令回應包；III、 若從站尚需發(fā)送命令包，則繼續(xù)將命令包發(fā)出，然后回到步驟II繼 續(xù)執(zhí)行，否則執(zhí)行步驟IV;IV、 從站向主站發(fā)回令牌回應包。
3、 根據(jù)權利要求1所述的星形半雙工鏈路中從站主動通信方法，其特 征在于步驟2)中主動命令發(fā)送過程包括如下步驟2.1、 從站收到主站的令牌包后，將需發(fā)送的命令包發(fā)送至主站；2.2、 主站收到命令包后向該從站發(fā)回命令回應包；2.3、 主站繼續(xù)發(fā)送令牌包至從站，若從站有需發(fā)送的命令包，則重復步 驟2.1 )和2.2 )，否則執(zhí)行步驟2.4 );2.4、 從站向主站發(fā)回令牌回應包。
4、 根據(jù)權利要求1所述的星形半雙工鏈路中從站主動通信方法，其特 征在于步驟2)中主動命令發(fā)送過程包括如下步驟a、從站收到主站的令牌包后，將待發(fā)送的命令包與令牌回應包組合生成 組合包并發(fā)送到主站； b、主站將收到的組合包還原分解成令牌回應包和命令包，并響應所述 命令包向相應的從站發(fā)出命令回應包。
5、 根據(jù)權利要求2至4所述的星形半雙工鏈路中從站主動通信方法， 其特征在于主站在收到從站發(fā)來的數(shù)據(jù)包后，辨別其中命令包的目的地址，并將目 的地址為其它從站的命令包轉發(fā)至目的從站，然后等候該從站回復的命令回 應包，并將其作為數(shù)據(jù)包轉發(fā)至發(fā)送該命令包的源從站。
6、 根據(jù)權利要求5所述的星形半雙工鏈路中從站主動通信方法，其特 征在于主站接收所有從站發(fā)出的數(shù)據(jù)包，而從站只處理源站為主站但目的 站為本站的數(shù)據(jù)包。
7、 根據(jù)權利要求6所述的星形半雙工鏈路中從站主動通信方法，其特 征在于當前站處于等待狀態(tài)時，不允許發(fā)送令牌或命令包到總線上。
8、 根據(jù)權利要求1至4中任意一項所述的星形半雙工鏈路中從站主動通 信方法，其特征在于主站和/或從站在發(fā)送或等待數(shù)據(jù)包之前，預設定時參 數(shù)，如果數(shù)據(jù)接收超過該定時參數(shù)，則復位重新處理相關數(shù)據(jù)。
9、 根據(jù)權利要求5所述的星形半雙工鏈路中從站主動通信方法，其特征 在于主站和/或從站在發(fā)送或等待數(shù)據(jù)包之前，預設定時參數(shù)，如果數(shù)據(jù)接 收超過該定時參數(shù)，則復位重新處理相關數(shù)據(jù)。
10、 根據(jù)權利要求6或7所述的星形半雙工鏈路中從站主動通信方法， 其特征在于主站和/或從站在發(fā)送或等待數(shù)據(jù)包之前，預設定時參數(shù)，如果 數(shù)據(jù)接收超過該定時參數(shù)，則復位重新處理相關數(shù)據(jù)。
全文摘要
本發(fā)明涉及一種星形半雙工鏈路中從站主動通信方法，包括如下步驟1)主站定時發(fā)出令牌包在多個從站之間輪詢；2)從站在發(fā)出令牌回應包的同時或之前完成主動命令發(fā)送過程；3)從站向主站發(fā)送令牌回應包。與現(xiàn)有技術相比，本發(fā)明具備如下優(yōu)點通過應用簡單的技術，在收到令牌及回應該令牌之間發(fā)送從站的命令包，化被動為主動，解決了從站與主站以及從站與從站之間主動通信的問題。
文檔編號H04L12/44GK101170473SQ20061012307
公開日2008年4月30日 申請日期2006年10月27日 優(yōu)先權日2006年10月27日
發(fā)明者劉大能, 李勝利, 歐曉明, 賴遠萱 申請人:京信通信技術(廣州)有限公司