組播， 英文原文為Multicast， 也有人把它譯為多播， 是IP網(wǎng)絡(luò)中三種通訊方式之一(其它兩種為廣播-Broadcast， 點到點通訊也叫單播-Unicast)。 在工業(yè)現(xiàn)場總線工業(yè)以太網(wǎng)化的應(yīng)用環(huán)境下， 組播技術(shù)是目前*為常用的一種保證同屬于一個通訊主站下的多個通訊從站之間能較為實時的收到來自該主站的同一信息， 即每個從站收到該信息的時刻比較一致。 
組播技術(shù)主要是依靠將某一組播地址(包含了多個目的地址)作為信息的目的地址， 并使用*高效的傳輸策略: 信息在每條網(wǎng)絡(luò)鏈路上只需傳遞一次，只有在鏈路分叉的時，該信息才會被復(fù)制。那么組播技術(shù)是如何管理由多個目的地址組成的組播組的呢? 以下這些常見的組播技術(shù)協(xié)議都有相關(guān)的規(guī)定: 互聯(lián)網(wǎng)組管理協(xié)議(IGMP)， 協(xié)議無關(guān)組播(PIM)， 距離矢量組播路由協(xié)議(DVMRP)， 組播OSPF(MOSPF)， 組播BGP(MBGP)， 組播源發(fā)現(xiàn)協(xié)議(MSDP)和組播監(jiān)聽器發(fā)現(xiàn)(MLD)。 由于篇幅的關(guān)系， 本人首先介紹IGMP - Internet Group Management Protocol即因特網(wǎng)組管理協(xié)議， 因為這是目前幾乎所有的工業(yè)以太網(wǎng)交換產(chǎn)品均支持的組播技術(shù)， 也是*為常用的組播技術(shù)。
因特網(wǎng)組管理協(xié)議被用在IP主機和它們即時相鄰組播代理之間，用以支持臨時組播組地址的分配和組播組成員的添加刪除。IP組播定義為一個去往"(目的)主機群"的IP數(shù)據(jù)報(packet)的傳輸，有零個或多個主機組成的"主機群"通過單個IP目的地址標識。一個組播數(shù)據(jù)報被投遞給它的目的主機群的所有成員，具有和常規(guī)單路傳送IP數(shù)據(jù)報同樣的"盡力地(best effort-UDP)"安全性，那就是說該數(shù)據(jù)報不保證達到目的地組的所有成員，或者不和其他數(shù)據(jù)報具有相同的順序。主機組的成員數(shù)是動態(tài)的；也就是說，主機隨時可以參加和離開組。 沒有對主機組中的成員的數(shù)目或地點加以限制，但是成員**于那些擁有專用的存取鍵的主機。一個主機可能同時是多個組的成員。一個主機即時不是一個組的成員也可以給它發(fā)送數(shù)據(jù)報。主機組可能**性或暫時性的。**性組具有一個眾所周知的，官方分配的IP地址。它是地址，非該組的成員，也就是說**性；任何時間，一個**性組也許有許多成員，甚至可能有零個成員。 另一方面，臨時性的組，當應(yīng)一個主機的請求創(chuàng)建時被動態(tài)地指派一個地址。當它的成員跌至零，臨時性的組要解散時，它的地址可以重新分配。臨時組的創(chuàng)建和組員身份信息的維護是“組播代理”（存在于因特網(wǎng)網(wǎng)關(guān)或其他專用的主機內(nèi)的實體）的職責。至少有一個組播代理直接與每個支持IP多點廣播的IP網(wǎng)絡(luò)或子網(wǎng)相連。主機通過用鄰機代理交換報文來請求新建一個組、加入或離開現(xiàn)有組。組播代理還擔負多點播送IP數(shù)據(jù)報的互連網(wǎng)絡(luò)運送工作。發(fā)送一個多點播送IP數(shù)據(jù)報時，主機將它傳送到一個局域網(wǎng)組播地址那里，哪些地址標識目的地主機組的所有鄰機成員。如果該組具有在其他網(wǎng)絡(luò)的成員，組播代理成為本地組播的輔助接收器并且通過因特網(wǎng)網(wǎng)關(guān)系統(tǒng)中繼該數(shù)據(jù)報給其他網(wǎng)絡(luò)上的代理。*后，另一個網(wǎng)絡(luò)上的代理將數(shù)據(jù)報作為一個本地的組播傳送給他們自己目的組的鄰機成員。
目前市面上的絕大多數(shù)用于現(xiàn)場的工業(yè)以太網(wǎng)交換設(shè)備為二層交換設(shè)備，即不支持三層技術(shù)如剛才提到的組播技術(shù)。所有這些工業(yè)以太網(wǎng)交換機采用IGMP snooping的技術(shù)-通過動態(tài)地配置二層端口的方法來抑制組播**的泛濫，這樣才能保證組播**僅被轉(zhuǎn)發(fā)給那些與IP組播設(shè)備相關(guān)聯(lián)的端口。正如其名稱的含義，IGMP snooping需要工業(yè)以太網(wǎng)交換機去打探在主機和三層設(shè)備之間的IGMP傳輸意圖并記錄組播組及其成員的端口。當工業(yè)以太網(wǎng)交換機收到來自某一主機的IGMP報告欲加入某一特定的組播組的報告時，該交換機會在其轉(zhuǎn)發(fā)表項中加入該主機所連接的端口號；當工業(yè)以太網(wǎng)交換機收到來自某一主機的欲離開某一特定組播組的報告時，它將其連接的交換機端口號從這一表項中刪除。交換機也會定時地刪除它的組播組成員表項，如果它沒有從組播客戶端收到IGMP組播成員報告。網(wǎng)絡(luò)中的三層交換設(shè)備如三層交換機或路由器等會定期地送出IGMP通用問詢給所有的VLAN(虛擬局域網(wǎng))。一旦工業(yè)以太網(wǎng)交換機上的IGMP snooping功能被打開，該交換機將基于MAC組播組為所連接設(shè)備的加入請求來響應(yīng)三層交換設(shè)備的詢問，并為每個VLAN、每個MAC組播組在其轉(zhuǎn)發(fā)表項中創(chuàng)建相應(yīng)的表項。
由于篇幅的原因，對IGMP的介紹先到此結(jié)束。歡迎各位專家指正。

工業(yè)控制網(wǎng)絡(luò)對網(wǎng)絡(luò)的實時性要求很高，不僅要求傳輸速度快，數(shù)據(jù)傳輸還要具有確定性。以太網(wǎng)的通信存在不確定性，不能滿足實時性要求，成為以太網(wǎng)應(yīng)用于工業(yè)控制領(lǐng)域的主要障礙。本設(shè)計實現(xiàn)的實時以太網(wǎng)[2]就是網(wǎng)絡(luò)中每個節(jié)點的通信被嚴格地限定在規(guī)定時間內(nèi)，確保在同一網(wǎng)段內(nèi)同時只有一臺在發(fā)送數(shù)據(jù)。

1. 前言

　　工業(yè)控制網(wǎng)絡(luò)是一種特定應(yīng)用的網(wǎng)絡(luò)，和商業(yè)信息網(wǎng)絡(luò)相比，它具有自身的要求和特點，其中非常重要的一點就是實時性要求高，不僅要求傳輸速度快，還要求響應(yīng)快，并且數(shù)據(jù)傳輸要具有確定性。以太網(wǎng)的通信調(diào)度方式——帶有沖突檢測的載波偵聽多路訪問機制（CSMA/CD），是一種非確定性的通信調(diào)度方式。網(wǎng)絡(luò)每個節(jié)點要通過競爭來取得信息的發(fā)送權(quán)：節(jié)點監(jiān)聽信道，只有發(fā)現(xiàn)信道空閑時才能發(fā)送信息。信息開始發(fā)送后，還需要檢查是否發(fā)生碰撞，如發(fā)生碰撞，則需等待，等待的時間取決于“二進制指數(shù)退避算法”得出的隨機延遲[1][4]，這種隨機延遲為工業(yè)通信的數(shù)據(jù)傳輸增加了難以避免的不確定性。

2. 系統(tǒng)模型

　　本設(shè)計通過在以太網(wǎng)MAC層之上增加確定性調(diào)度層，上層采用了EPA[3]（Ethernet of Plant Automation）協(xié)議的數(shù)據(jù)封裝格式，因此使數(shù)據(jù)包的類型判斷和調(diào)度發(fā)送時間的獲取成為可能。EPA 是一種基于工業(yè)以太網(wǎng)的現(xiàn)場總線標準，是在控制系統(tǒng)與現(xiàn)場測量、控制裝置之間，以及現(xiàn)場測量、執(zhí)行機構(gòu)之間進行通信的分布式數(shù)字控制系統(tǒng)。這樣對所有的上層數(shù)據(jù)包在整個實時網(wǎng)段范圍內(nèi)進行數(shù)據(jù)包統(tǒng)一調(diào)度發(fā)送，從而避免碰撞現(xiàn)象的發(fā)生并確保數(shù)據(jù)傳輸?shù)拇_定性要求。通信模型如圖 1所示： 

圖1 實時以太網(wǎng)通信模型

3. 系統(tǒng)設(shè)計

　　本設(shè)計是在嵌入式平臺下實現(xiàn)的，利用ARM7處理器和Cs8900網(wǎng)絡(luò)接口芯片搭建的硬件平臺進行開發(fā)，在同一網(wǎng)段中，每一個運行的設(shè)備等同于一個網(wǎng)絡(luò)節(jié)點。

　　上層采用EPA協(xié)議封裝，分實時數(shù)據(jù)和非實時數(shù)據(jù)進行發(fā)送和接收。實時數(shù)據(jù)到達后，通過實時通信服務(wù)接口向下遞交，對數(shù)據(jù)進行緩存處理，等待調(diào)度發(fā)送。下一個發(fā)送周期到來后，將用新的實時數(shù)據(jù)更新相應(yīng)緩沖區(qū);非實時通信服務(wù)通過OS中提供的BSD接口來提供，但是為了實現(xiàn)確定性的調(diào)度，非實時數(shù)據(jù)包穿越TCP/IP協(xié)議棧到達數(shù)據(jù)鏈路層時，不允許直接調(diào)用硬件驅(qū)動接口進行數(shù)據(jù)包收發(fā)操作，而是通過一個虛擬的驅(qū)動接口將數(shù)據(jù)包放入相應(yīng)的發(fā)送和接收隊列。修改原E-NIC的驅(qū)動接口，使其成為虛擬驅(qū)動接口，無法直接將數(shù)據(jù)遞交給硬件驅(qū)動，而是入非周期隊列。對硬件網(wǎng)卡的收發(fā)操作在硬件驅(qū)動接口中實現(xiàn)。設(shè)計圖如圖2：

圖2 以太網(wǎng)確定性調(diào)度設(shè)計圖

　　確定性調(diào)度層負責何時調(diào)用硬件驅(qū)動接口收發(fā)數(shù)據(jù)幀。當確定性調(diào)度層收到數(shù)據(jù)幀時，根據(jù)以太網(wǎng)幀首部的type字段來區(qū)分實時數(shù)據(jù)幀和非實時數(shù)據(jù)幀。若是實時數(shù)據(jù)幀，將用收到的實時數(shù)據(jù)更新相應(yīng)緩沖區(qū);若是非實時數(shù)據(jù)，則將其放入相應(yīng)的接收隊列并通過任務(wù)通信機制通知上層協(xié)議棧數(shù)據(jù)幀到達事件。確定性調(diào)度層的調(diào)度表由調(diào)度算法生成。

4. 主要模塊描述

　　實時通信服務(wù)接口、虛擬驅(qū)動接口、時鐘同步服務(wù)和實時調(diào)度算法為本設(shè)計的四個主要模塊。

　　4.1 實時通信服務(wù)接口

　　實時通信服務(wù)接口負責為上層應(yīng)用（協(xié)議）提供周期性實時消息的實時通信服務(wù)。

　　周期性實時消息的發(fā)送和接收采用緩沖機制，即為本節(jié)點在運行過程中要發(fā)送的每個周期性實時消息在內(nèi)存中定義相應(yīng)的緩沖區(qū)，每當上層應(yīng)用通過實時通信服務(wù)接口發(fā)送新的消息時，即用該新消息值更新其對應(yīng)緩沖區(qū)中的舊消息值;為本節(jié)點在運行過程中要接收的每個周期性實時消息在內(nèi)存中定義相應(yīng)的緩沖，每當上層應(yīng)用通過實時通信服務(wù)接口接收新的消息時，則將對應(yīng)緩沖區(qū)中的消息值返回。節(jié)點在運行過程中將要發(fā)送的每個周期性實時消息必須要有與其對應(yīng)的已知的目標地址（包括目標MAC地址-用于識別節(jié)點，端口號-用于識別實時消息所對應(yīng)的緩沖區(qū)元素）。

　　實時通信服務(wù)接口要提供以下接口函數(shù)：

　?。?）RtAppInterface（）

　　創(chuàng)建實時接口函數(shù)，用于實時周期性消息的發(fā)送和接收。

　?。?）RtMapping（）

　　將由RtAppInterface（）函數(shù)創(chuàng)建的接口進程映射到特定的地址（MAC，端口號（即緩沖元素的索引））。

　?。?）RtSend（）

　　使用已創(chuàng)建和映射完畢的實時接口進程進行實時消息的發(fā)送。

　?。?）RtRecv（）

　　使用已創(chuàng)建和綁定完畢的實時接口進程進行實時消息的接收。

　　4.2 虛擬驅(qū)動接口

　　虛擬驅(qū)動接口負責為上層TCP/UDP/IP協(xié)議棧提供一套虛擬的驅(qū)動程序接口，該接口必須與上層協(xié)議棧所使用的原硬件驅(qū)動接口一致，但需改變該接口中的具體函數(shù)實現(xiàn)，使得虛擬驅(qū)動接口所對應(yīng)的具體函數(shù)無法直接實現(xiàn)對硬件的控制（如打開，關(guān)閉設(shè)備，收發(fā)數(shù)據(jù)包等）。必須確保用虛擬驅(qū)動接口替換原硬件驅(qū)動接口后，從TCP/IP協(xié)議棧使用驅(qū)動接口的角度來看，和使用原硬件接口一樣，即用虛擬驅(qū)動接口替換原硬件驅(qū)動接口的改動對于上層協(xié)議棧的使用而言必須是透明的。對上層協(xié)議棧發(fā)下來的數(shù)據(jù)包以FIFO的順序緩存到消息隊列，何時調(diào)用硬件驅(qū)動接口發(fā)送這些數(shù)據(jù)包由確定性調(diào)度層決定。

　　虛擬驅(qū)動接口提供的主要函數(shù)：

　?。?）RtVirtualIn（ ）

　　接收IP層的發(fā)送數(shù)據(jù)包，根據(jù)數(shù)據(jù)包類型確定轉(zhuǎn)存入隊列還是向下遞交。

　　（2）RtVirtualOut（ ）

　　調(diào)用驅(qū)動層的發(fā)送函數(shù)發(fā)送數(shù)據(jù)，接收發(fā)送返回信息。

　?。?）RtVirtualPacketType（）

　　取對應(yīng)字段，判斷到來包類型（EPA類型字段 以太網(wǎng)類型字段）。

　　4.3 時鐘同步

　　在實時網(wǎng)段內(nèi)，時鐘同步是非常關(guān)鍵的，因為實時網(wǎng)段內(nèi)各節(jié)點上的任務(wù)運行和消息發(fā)送都是基于時間基準的，特別是總線上的消息調(diào)度，為了避免碰撞，消息間必須留出足夠的間隙來容納節(jié)點間的同步誤差。為了**時鐘同步精度，應(yīng)把時鐘同步功能放在協(xié)議棧中盡可能靠近硬件的位置。本系統(tǒng)中時鐘同步功能由確定性調(diào)度層來提供。時鐘同步協(xié)議采用IEEE 1588協(xié)議[6]。

　　在實時網(wǎng)段內(nèi)選定一節(jié)點作為主時鐘，主時鐘定期發(fā)布時鐘同步消息，時鐘同步消息作為主時鐘節(jié)點上的周期性消息。由于時鐘同步消息在調(diào)度好的同步窗口中發(fā)送，可以保證時鐘消息的發(fā)送獨立于當前網(wǎng)絡(luò)負載而無碰撞的發(fā)送，因而時鐘消息從發(fā)布節(jié)點到各個接收節(jié)點的延遲對各個接收節(jié)點而言為一常量。

　　4.4實時調(diào)度算法

　　本設(shè)計采用的算法根據(jù)RM和EDF算法改進而成的[7]，每個基本周期開始時動態(tài)生成此基本調(diào)度單位（ESU）的調(diào)度時間表。整個鏈路時間由連續(xù)等長的基本調(diào)度單位（ESU）組成，通常ESU為實時網(wǎng)段內(nèi)所有周期性實時消息的周期的*大公約數(shù)HCF。每個ESU被分成周期性實時消息窗口（PW）和非周期性消息窗口（AW），如圖3所示。PW中的調(diào)度根據(jù)事先由周期性實時消息調(diào)度算法生成的調(diào)度表來進行，調(diào)度表的長度為所有周期性實時消息的周期的*小公倍數(shù)LCM，調(diào)度表中與各個節(jié)點相關(guān)的部分被存放在各個節(jié)點中，各節(jié)點根據(jù)調(diào)度表中規(guī)定的時刻，以宏周期為循環(huán)單位周而復(fù)始的執(zhí)行周期性實時消息的發(fā)送動作。在AW中，數(shù)據(jù)采用優(yōu)先級隊列節(jié)點輪詢的方式發(fā)送。按照非周期數(shù)據(jù)實時要求將非周期數(shù)據(jù)劃分為i個優(yōu)先級，每個優(yōu)先級在節(jié)點中維護一個非周期優(yōu)先級隊列，因此每個節(jié)點中的非實時優(yōu)先級隊列為i個。發(fā)送時采用節(jié)點輪詢的方式按優(yōu)先級從高到低的順序進行發(fā)送，每次被輪詢節(jié)點將指定優(yōu)先級隊列中的數(shù)據(jù)全部發(fā)送。

圖3 基本周期內(nèi)數(shù)據(jù)發(fā)送窗口

5.結(jié)論

　　本系統(tǒng)所實現(xiàn)的實時以太網(wǎng)可以完成網(wǎng)段內(nèi)數(shù)據(jù)的調(diào)度發(fā)送，基于本設(shè)計的實時以太網(wǎng)完全可以應(yīng)用于一般的過程控制工業(yè)領(lǐng)域。通過改進原型系統(tǒng)的時鐘同步機制等來可以進一步**系統(tǒng)的實時性以及時鐘精度，基于本設(shè)計的實時以太網(wǎng)改進的目標是把時鐘精度**到微秒級，進而應(yīng)用于時間精度要求較高的工業(yè)領(lǐng)域，如運動控制等。