物聯網的常用幾種協議

最近公司組內要研究這個了 ,有個java大哥又弄個什么低代碼的...可笑至極, 所以就發發總結一下 ,想做物聯網關多支持點協議比什么不好~~ 老生常談啊!! 大伙別噴我主要公司招人太水....

http tcp sqlserver這數據庫什么的都不講了沒意義 ,不發流水賬. 不知道是不是我標題不太違和~~ 反正mqtt lora也說 此篇更偏向工業化~~

---- 以下為一些國家和工業標準的協議 ,還有什么不全的大伙幫忙總結和分享哦 ,不對的請幫忙指

? ? ? ? 正不有要給別人造成誤解 多謝 ==??whaosoft aiot?http://143ai.com?

IEC104

HJ/T212

CJT188

DLT645

BACnet

JTT808

ModBus

OPC

--------------------

## IEC104

IEC104規約是一個廣泛應用于電力、城市軌道交通等行業的國際標準,規約由國際電工委員會制定。IEC104規約把IEC101的應用服務數據單元（ASDU）用網絡規約TCP/IP進行傳輸的標準，該標準為遠動信息的網絡傳輸提供了通信規約依據。采用104規約組合101規約的ASDU的方式后,可很好的保證規約的標準化和通信的可靠性。

##?HJ/T212

HJ/T212是由國家環保行業制定的數據傳輸標準協議，目前廣泛使用的是HJ/T212-2005通信協議，該協議在2005年制定，并于2006年2月1日正式實施。?

《HJT 212-2017 污染源在線監控（監測）系統數據傳輸標準》和《HJT 212-2005 污染源在線監控（監測）系統數據傳輸標準》

?HJ/T212標準不規定數據采集傳輸儀與監控儀器儀表的通訊方式，可以采用RS232、RS485、GPRS、TCP/IP等通信方式。

?HJ/T212通訊協議數據結構中所有的通訊包都是由ACSII碼字符組成(CRC校驗碼除外)。

數據段的字段與其值用“=”連接；在數據區中，同一項目的不同分類值間用“，”來分隔，不同項目之間用“；”來分隔。字段名要區分大小寫，單詞的首個字符為大寫，其他部分為小寫。數據段部分由請求編號QN，總包號PNUM，包號PN0，系統編號ST，命令編號CN，訪問密碼PW，設備唯一標識符MN，是否拆分包及應答標志Flag，指令參數CP等項目組成。

協議包組成 (待完善)

數據段結構組成? (待完善)

## CJT188

CJ/T-188 水表協議

以下為協議說明

? ? 數據發送：?
? ? ? ? FE FE FE FE 68 10 44 33 22 11 00 33 78 01 03 1F 90 00 80 16?
? ? ? ? 說明如下：?
? ? ? ? ? ? FE FE FE FE：協議頭（1-4組）。?
? ? ? ? ? ? 68：幀起始符。?
? ? ? ? ? ? 10：儀表類型，此實例指冷水水表，還可定義為：?
? ? ? ? ? ? ? ? 10：冷水水表?
? ? ? ? ? ? ? ? 11：生活熱水水表?
? ? ? ? ? ? ? ? 12：直飲水水表?
? ? ? ? ? ? ? ? 13：中水水表?
? ? ? ? ? ? ? ? 20：熱量表（記熱量）?
? ? ? ? ? ? ? ? 21：熱量表（記冷量）?
? ? ? ? ? ? ? ? 30：燃氣表?
? ? ? ? ? ? ? ? 40：電度表 ?
? ? ? ? ? ? 44 33 22 11 00：倒序為0011223344（以BCD碼形式看待），表示表號。?
? ? ? ? ? ? 33 78：倒序為7833（以BCD碼形式看待），表示廠家代碼。?
? ? ? ? ? ? 01：控制碼表示讀表計數據，后面跟固定數據域長度、數據標識和序列號。?
? ? ? ? ? ? 03：數據域長度（固定）。 ?
? ? ? ? ? ? 1F 90：數據標識（固定）。?
? ? ? ? ? ? 00：序列號（固定）。?
? ? ? ? ? ? 80：累加和，68+10+44+33+22+11+00+33+78+01+03+1F+90+00=80。?
? ? ? ? ? ? 16；結束符。?

? ? 回復數據：?
? ? ? ? FE FE FE FE 68 10 44 33 22 11 00 33 78 81 16 1F 90 00 ?00 77 66 55 2C 00 77 66 55 2C 31 01 22 11 05 15 20 21 84 08 16?
? ? ? ? 說明如下：?
? ? ? ? ? ? FE FE FE FE：協議頭（1-4組）。?
? ? ? ? ? ? 68：幀起始符。?
? ? ? ? ? ? 10：儀表類型。?
? ? ? ? ? ? 44 33 22 11 00：倒序為0011223344（以BCD碼形式看待），表示表號。?
? ? ? ? ? ? 33 78：倒序為7833（以BCD碼形式看待），表示廠家代碼。?
? ? ? ? ? ? 81：實際為控制碼+80，我們可以簡單認為只有81正確，非81均為異常，不進行解析。?
? ? ? ? ? ? 16：數據域長度，為十進制22，表示后面有22個有效數據。?
? ? ? ? ? ? 1F 90：數據標識（固定）。?
? ? ? ? ? ? 00：序列號（固定）。?
? ? ? ? ? ? ?00 77 66 55 ：倒序為556677.00 （以BCD碼形式看待），表示 累計用量。?
? ? ? ? ? ? 2C ：立方米，其它單位見附1。?
? ? ? ? ? ? ?00 77 66 55 ：倒序為556677.00 （以BCD碼形式看待），表示 本月用量。
? ? ? ? ? ? 2C ：立方米，其它單位見附1。 ?
? ? ? ? ? ? 31 01 22 11 05 15 20：2015-05-11 22:01:31，表示實時時間。
? ? ? ? ? ? 21 84：狀態，兩字節，第1字節定義如下，第2字節由廠家自定義。

?
? ? ? ? ? ? 68：累加和，68+10+44+33+22+11+00+33+78+81+16+1F+90+00+00+77+66+55+2C+00+77+66+55 2C+31+01+22+11+05+15+20+21+84=08。
? ? ? ? ? ? 16；結束符。?
??

## DLT645?

還是一個電能表通訊協議

DLT645是目前使用最多的多功能電能表通信規約，系統傳輸多采用串口通訊。適用于本地系統中多功能電能表的費率裝置與手持單元(HHU)或其它數據終端設備進行點對點的或一主多從的數據交換方式，規定了它們之間的物理連接、通信鏈路及應用技術規范。

07版比97版增加了不少功能項，也有一定的區分，最明顯的區別是信息地址從2個字節變成4個字節長度。具體協議信息，可以參考相關發行文檔，我們用SymLink對其通訊過程作簡單的介紹：

主站發送

68 01 00 00 00 00 00 68 11 04 33 33 3D 33BC 16

01 00 00 00 00 00 為電表物理地址，這里的物理地址實際是：000000000001

從站發送

68 01 00 00 00 00 00 68 91 08 33 33 3D 3333 33 33 33 0C 16

01 00 00 00 00 00 為從站返回的物理地址，和發送的一致

33 33 3D 33 33 33 33 33 代表電度數據，計算的時候每一個數據會減33H

通過通訊報文分析，可以很快的掌握協議通訊的基本信息，通訊過程采取問答式傳輸，主站詢問指令包含電表的物理地址和電度信息地址，從站根據詢問進行應答。

上面協議里面需要設置的一個參數為鏈路地址，一般在電表的前面板上能找到一個較長的數字就是，不足12個長度的，規定前面補A或者0。

準備工作

?

設備連接

& RS485通訊，遠動設備的A端子對應連接SymLink的A端子、遠動設備的B端子對應連接SymLink的B端子。

& 以太網通訊，遠動設備的網口對應連接到同一網段的SymLink LAN口，如果含多臺以太網設備，需要加交換機。

設備配置

參考實際的設備說明書：

a) ? ? ? ? 定義通訊接口參數。串口定義傳輸波特率，數據位，停止位，奇偶檢驗。默認一般為2400、8、偶、1。

b) ? ? ? ? 定義設備物理地址，一般為前面板查看。

c) ? ? ? ? 用廠家提供的測試軟件，或者串口調試工具對設備進行通訊測試。

## BACnet

樓宇自動控制網絡數據通訊協議（即： A Data Communication Protocol for Building Automation and Control Networks，簡稱《BACnet協議》）由美國暖通、空調和制冷工程師協會(ASHRAE ) 組織的 標準項目委員會135P (Standard Project Committee即SPC 135P)歷經八年半時間開發的。

一般樓宇自控設備從功能上講分為兩部分：一部分專門處理設備的控制功能；另一部分專門處理設備的數據通信功能。而BACnet就是要建立一種統一的數據通信標準，使得設備可以互操作。BACnet協議只是規定了設備之間通信的規則，并不涉及實現細節。

BACnet協議模型為：

（1）所有的網絡設備，除基于MS/TP協議的以外，都是完全對等的（peer to peer）；

（2）每個設備都是一個“對象”的實體，每個對象用其“屬性”描述，并提供了在網絡中識別和訪問設備的方法；設備相互通信是通過讀/寫某些設備對象的屬性，以及利用協議提供的“服務”完成；

（3）設備的完善性（Sophistication），即其實現服務請求或理解對象類型種類的能力，由設備的“一致性類別”（Conformance Class）所反映。

1.1 BACnet的體系結構

BACnet是一種針對智能建筑的開放性的網絡協議，遵循OSI模型體系結構，BACnet體系結構層次圖如圖1所示。BACnet協議從硬/軟件實現、數據傳輸速率、系統兼容和網絡應用等幾方面考慮，目前支持五種組合類型的數據鏈路/物理層規范。其中主從/令牌傳遞（MS/TP）協議是專門針對樓宇自控設備設計的數據鏈路規范。BACnet在物理介質上，支持雙絞線、同軸電纜和光纜。在拓撲結構上，支持星型和總線拓撲。

圖1 BACnet體系結構層次圖

BACnet沒有嚴格規定網絡拓撲結構，如圖2所示。其中：網段（Segment）是多個物理網段通過中繼器（R）連接形成的段落區間；網絡是多個網段通過網橋（B）連接而成的，每個網絡都形成一個MAC地址域；BACnet/Internet網絡是將使用不同局域網技術的多個網絡用路由器（RT）互聯起來形成的網際網。

圖2 BACnet網絡結構圖

在BACnet拓撲中設備之間只存在一條邏輯通路，無需廣域網的路由算法；其次，BACnet具有單一的局部地址空間，所以BACnet參照OSI模型制定了簡化的網絡層協議，向應用層提供不確認無連接的數據單元傳送服務。每個BACnet設備都被一個網絡號碼和一個MAC地址唯一確定。

網絡層通過“路由器”實現兩個或多個異類BACnet局域網（不同的數鏈層）的連接，并通過協議報文進行“路由器”的自動配置、路由表維護和擁塞控制。BACnet路由器與每個網絡的連接處稱為一個“端口”。路由表中包含端口的下列項目：端口所連接網絡的ＭＡＣ地址和網絡號；端口可到達網絡的網絡號列表及與這些網絡的連接狀態。圖2中，“1/2RT”是半路由器，由PTP連接形成一個完整的BACnet路由器，即BACnet網際網將廣域網技術向應用層屏蔽。

BACnet應用層即BACnet應用實體，通過API（應用編程接口）為上層應用程序服務，并與對等應用層實體通信。應用實體由兩部分組成：用戶單元和應用服務單元（ASE）。ASE是一組特定內容的應用服務。而用戶單元支持本地API、保存事務處理上下文信息、產生請求ID、記錄ID對應的應用服務響應、維護超時重傳機制所需的計數器以及將設備行為要求映射為對象。

BACnet應用層提供證實和非證實兩種類型的服務。BACnet定義了四種服務原語：請求、指示、響應和證實，它們通過應用層協議數據單元（APDU）傳遞。由于BACnet建立在無連接的通信模式上，所以OSI模型提供端到端服務的傳輸層部分簡化功能也由應用層實現，分別為：可靠的端到端傳輸和差錯校驗；報文分段和流量控制；報文重組和序列控制。

1.2 BACnet的對象、服務和功能組

BACnet采用面向對象技術，借此提供一種表示樓宇自控設備的標準。在BACnet中，對象就是在網絡設備之間傳輸的一組數據結構，網絡設備通過讀取、修改封裝在應用層ＡＰＤＵ中的對象數據結構，實現互操作。BACnet目前定義了18個對象，如圖3所示，每個對象都必須有三個屬性：對象標志符（Object_Identifier）、對象名稱（Object_Name）和對象類型（Object_Type）。其中，對象標志符用來唯一標識對象；BACnet設備可以通過廣播自身包含的某個對象的對象名稱，與包含相關對象的設備建立聯系。BACnet協議要求每個設備都要包含“設備對象”，通過對其屬性的讀取可以讓網絡獲得設備的全部信息。

圖3 BACnet對象

在BACnet中，把對象的方法稱為服務，對象及其屬性提供了對一個樓宇自控設備“網絡可見信息”的抽象描述，而服務提供了如何訪問和操作這些信息的命令和方法。BACnet設備通過在網絡中傳遞服務請求和服務應答報文實現服務。BACnet定義了35種服務，并將其劃分為6個類別：
（1）報警與事件服務（Alarm and Event Services）包含8種服務處理環境狀態的變化，提供了BACnet設備預設的請求值改變通告、請求報警或事件狀態摘要、發送報警或事件通知、收到報警通知確認等方法；
（2）文件訪問服務（File Access Services）包含2種服務，提供讀寫文件的方法，包括上／下載控制程序和數據庫的能力；
（3）對象訪問服務（Object Access Services）包含9種服務，提供了讀、修改和寫屬性值以及增刪對象的方法；
（4）遠程設備管理服務（Remote Device Management Services）包含11種服務，提供對BACnet設備進行維護和故障檢測的工具、方法；
（5）虛擬終端服務（Virtual Terminal Services）包含3種服務，提供了一種面向字符的數據雙向交換機制，使其他具有專有特性的樓宇自控設備成為一個BACnet虛擬終端并使BACnet網絡能對其進行重構；
（6）網絡安全服務（Network Security Services）包含2種服務，提供對等實體驗證、數據源驗證、操作者驗證和數據加密等功能。

BACnet功能組規定了實現特定控制功能所需的對象和服務的組合。BACnet已定義了13個功能組，包括時鐘功能組、事件響應功能組、文件功能組、虛擬終端功能組、設備通信功能組等。

1.3 BACnet設備級別和設備等級說明

在實際的樓宇自動化系統中，沒有必要也不可能所有的設備都支持、包含上述所有的對象和服務。因此，BACnet定義了6個一致性類別（設備級別）。一致性類別的分級編號為1~6，最低級別是類別1。每個類別都規定了設備要實現的最小服務子集，且包含低級別的所有服務。

為了幫助用戶和工程人員確定不同BACnet設備之間的互操作性，需要廠商為每個設備提供標準格式文件以標識設備中己實現的BACnet標準的內容，即文件需包括設備符合BACnet等級的說明。這個文件就是PICS（Proto Implementation Conformance Statement），它包括：
（1）標識廠商和描述設備的基本信息；
（2）設備符合BACnet的級別；
（3）設備所支持的功能組；
（4）設備所支持的基于標準或專有的服務，設備啟動或響應服務請求的能力；
（5）設備所支持的基于標準或專有的對象類型及其屬性描述；
（6）設備支持的數據鏈路技術；
（7）設備支持的分段請求和響應。

2. BACnet的互聯網擴展

目前，BACnet標準使用兩種技術實現與Internet的互聯。第一種技術附件H中稱之為“隧道”技術，并將其設備稱之為分組封裝/拆裝設備，簡稱PAD。其作用就像一個網關/路由器，這在圖2中兩個半路由器連接廣域網形成一個完全的BACnet路由器有所體現。第二種技術附件J中稱之為BACnet/IP，設備直接封裝IP幀／包在BACnet網絡和Internet上傳輸。

PAD將BACnet報文數據封裝在IP協議數據包內傳輸，在目的BACnet網絡解封。因此每個連接Internet的BACnet網絡都要配置PAD網關/路由器。它可以是一個單獨的設備，也可以是某種樓宇控制設備功能的一部分。

ASHPAE于1999年1月正式發布附件并成為美國國家標準。它規范了支持TCP/IP的設備組建BACnet網絡的技術，并稱之為BACnet/IP網絡，簡稱Ｂ/IP，是一個或多個IP子網組成的集合，整體具有單獨的BACnet網絡號。BACnet/IP網絡報文在網絡層是IP包，在傳輸層是UDP數據報，從而實現與Internet的TCP/IP協議的融合。

##???????JT／T808-2011

道路運輸車輛衛星定位系統終端通訊協議

協議東西太多 不貼了啊~~?

====== 以下就是倆種工業物聯網用的協議了

如果有必要還要說一下 PLC Kepserver 及 RS485 232的請留言~

## Modbus

Modbus是一種串行通信協議，是Modicon公司（現在的施耐德電氣 Schneider Electric）于1979年為使用可編程邏輯控制器（PLC）通信而發表。Modbus已經成為工業領域通信協議的業界標準（De facto），并且現在是工業電子設備之間常用的連接方式。

現在一般工業設備都會支持modbus。這個協議比較簡單了可以電腦上模擬一下做實驗.

Modbus協議是一個master/slave架構的協議。有一個節點是master節點，其他使用Modbus協議參與通信的節點是slave節點。每一個slave設備都有一個唯一的地址。在串行和MB+網絡中，只有被指定為主節點的節點可以啟動一個命令（在以太網上，任何一個設備都能發送一個Modbus命令，但是通常也只有一個主節點設備啟動指令）。
一個ModBus命令包含了打算執行的設備的Modbus地址。所有設備都會收到命令，但只有指定位置的設備會執行及回應指令（地址0例外，指定地址0的指令是廣播指令，所有收到指令的設備都會運行，不過不回應指令）。所有的Modbus命令包含了檢查碼，以確定到達的命令沒有被破壞?；镜腗odBus命令能指令一個RTU改變它的寄存器的某個值，控制或者讀取一個I/O端口，以及指揮設備回送一個或者多個其寄存器中的數據。
有許多modems和網關支持Modbus協議，因為Modbus協議很簡單而且容易復制。它們當中一些為這個協議特別設計的。有使用有線、無線通信甚至短消息和GPRS的不同實現。不過設計者需要克服一些包括高延遲和時序的問題。

Modbus RTU通訊協議在數據通訊上采用主從應答的方式進行。只能由主機（PC，HMI等）通過唯一從機地址發起請求，從機（終端設備）根據主機請求進行響應，即半雙工通訊。該協議只允許主機發起請求，從機進行被動響應，因此從機不會主動占用通訊線路造成數據沖突。

類似Modbus RTU協議的主從應答協議還有西門子的PPI、電表常用的DL/T645-2007等協議。

一、協議格式

信息傳輸為異步方式，使用16進制進行通訊，信息幀格式：

地址碼

地址碼是每個通訊信息幀的第一個字節，一般支持1到247，部分設備也支持0地址，用于接收主機的廣播數據，每個從機在總線上地址必須唯一，只有與主機發送的地址碼相符的從機才能響應返回數據。

功能碼

功能碼是每個通訊信息幀的第二個字節。主機發送，通過功能碼告知從機設備應當執行何種操作。

常見的八種功能碼：

數據區

數據區隨功能碼以及數據方向的不同而不同，這些數據可以是“寄存器首地址+讀取寄存器數量”、“寄存器地址+操作數據”、“寄存器首地址+操作寄存數量+數據長度+數據”等不同的組合，在“功能碼分析”詳解不同功能碼的數據區。

Modbus CRC校驗

Modbus RTU協議常用與工業現場對數據傳輸的穩定性和正確性有較高的要求，因此通過CRC校驗保證數據傳輸的正確性和完整性。

二、錯誤反饋

地址與CRC校驗錯誤并不會收到從機的數據反饋，其他錯誤將向主機返回錯誤碼。數據幀的第二位加上0X80表示請求發生錯誤（非法功能碼、非法數據值等），錯誤數據幀如下：

常見錯誤碼如下：

三、通訊信息傳輸過程

通訊命令由主機發送從機時，與主機發送的地址碼相符的從機接收通訊命令，如果CRC校驗無誤，則執行相應的操作，然后把執行結果（數據）返回給主機。返回信息中包含地址碼、功能碼、執行后的數據以及CRC校驗碼。如果地址不匹配或者CRC校驗出錯就不返回任何信息。

四、功能碼分析

功能碼01H：讀線圈

例如：主機要讀取從機地址為01H，起始線圈地址為00H的1個線圈狀態，主機發送：

如果從機寄存器00H線圈閉合，從機返回：

仿真演示：

功能碼05H：寫單個線圈

例如：主機要控制從機地址為01H，線圈地址為0000H的線圈狀態，主機發送：

從機返回與主機請求相同；

仿真演示：

功能碼0FH：寫多個線圈

例如：主機要控制從機地址為01H，起始線圈地址為00H的4個線圈狀態，主機發送：

功能碼0FH操作，從機返回：

仿真演示：

功能碼02H：讀離散輸入

例如：主機要讀取從機地址為01H，起始離散量地址為00H的4個輸入狀態，主機發送：

如果從機首地址00H開始的4離散輸入全部檢測到輸入，從機返回：

仿真演示：

功能碼04H：讀取輸入寄存器

例如：主機要讀取從機地址為01H，起始寄存器地址為02H的1個輸入寄存器數據，主機發送：

如果從機輸入寄存器02H的數據為3344H，從機返回：

仿真演示：

功能碼03H：讀保持寄存器

例如：主機要讀取從機地址為01H，起始寄存器地址為05H的2個保持寄存器數據，主機發送：

如果從機保持寄存器05H、06H的數據為1122H、3344H，從機返回：

仿真演示：

功能碼06H：寫單個保持寄存器

例如：主機寫入9988H的數據給從機地址為01H，寄存器地址為0050H的寄存器，主機發送：

從機返回與主機請求相同；

功能碼10H：寫多個保持寄存器

例如：主機要把數據0005H、2233H保存到從機地址為01H，起始寄存器地址為0020H的2個寄存器中，主機發送：

功能碼10H操作，從機返回：

仿真演示：

## OPC

這個應該是用的最多的了吧, 不過有點麻煩,還要依托于其他軟件

OPC(OLE for Process Control）, 用于過程控制的OLE，是一個工業標準，管理這個標準的國際組織是OPC基金會，OPC基金會現有會員已超過220家。遍布全球，包括世界上所有主要的自動化控制系統、儀器儀表及過程控制系統的公司?；谖④浀腛LE(現在的Active X)、COM （部件對象模型）和DCOM （分布式部件對象模型）技術。OPC包括一整套接口、屬性和方法的標準集，用于過程控制和制造業自動化系統。

通過實現對 OPC 客戶端的支持，SCADA 系統開發人員擺脫了為各種設備支持數百個驅動程序的需要，設備制造商通過添加 OPC 服務器，確信他們的產品可以被任何 SCADA 系統的用戶使用。

OPC 技術包括多個標準，這些標準描述了用于特定目的的一組功能。

現行標準

• OPC DA（數據訪問）是最常見的標準，它描述了一組與 PLC、DCS、HMI、CNC 和其他設備進行實時數據交換的功能。
• OPC HDA（歷史數據訪問）提供對已保存數據和歷史的訪問。
• OPC AE（警報和事件）為各種事件提供按需通知功能：緊急情況、操作員操作、信息消息等。
• OPC Batch提供工藝過程的步驟和配方控制功能。
• OPC DX (Data eXchange)提供通過以太網在 OPC 服務器之間組織數據交換的功能。該標準的主要目的是為來自不同制造商的設備和程序之間的數據交換創建網關。
• OPC 安全定義了組織客戶端對 OPC 服務器數據的訪問權限的功能。
• OPC XML-DA（XML 數據訪問）提供了一種靈活的、規則驅動的格式，用于通過 XML、SOAP 和 HTTP 交換數據。
• OPC 復雜數據是一組針對 OPC DA 和 XML-DA 的附加規范，允許服務器處理復雜數據類型，例如二進制結構和 XML 文檔。
• OPC 命令是一組編程接口，允許 OPC 客戶端和服務器識別、發送和控制在控制器或 I/O 模塊中執行的命令。
• OPC UA（統一架構）是不基于 Microsoft COM 技術的最新規范，它提供了跨平臺兼容性。

最普遍的標準是 OPC DA，但它有一個明顯的缺點。在其發展時，它建立在當時的現代 Windows 技術之上：OLE、ActiveX、COM/DCOM，但此后行業發生了變化，其他操作系統和技術也開始流行。因此，使 OPC 技術獨立于平臺，并在開放的跨平臺技術上開發了 OPC UA（統一架構）標準。

使用 OPC 的地方

通常，OPC 技術用于在控制器和 SCADA 系統之間交換數據，但也可以在過程控制系統的不同級別組織復雜的系統。

OPC 由兩部分組成：OPC 客戶端和 OPC 服務器。OPC 服務器軟件通過現場總線通過設備驅動程序輪詢各種設備。OPC 客戶端軟件通常內置于 SCADA 系統中，旨在從 OPC 服務器接收數據。

在這里，我們可以將 ACS 的幾個級別可視化：

• 較低的級別是現場總線和單獨的控制器
• 中間層是店鋪網絡
• APCS 級別是 SCADA 類型系統的操作級別
• MICS級別是企業資源管理應用、ERP、MES的級別

這些層中的每一層都可以由 OPC 服務器提供服務，將數據提供給更高層的 OPC 客戶端或相鄰設備。

OPC DA 服務器的工作原理

OPC DA 服務器在客戶端程序（通常是 SCADA 系統）和終端設備之間提供數據交換（寫入和讀取）。OPC 中的數據是具有某些屬性的標簽變量。變量可以是 OLE 中允許的任何類型：各種整數和實數類型、布爾值、字符串、日期、數組等。屬性可以是必需的、推薦的或自定義的。

必需的變量屬性：

• 變量的當前值、它的類型和訪問權限（讀和/或寫）。
• 變量的質量取決于超出動態范圍的測量值、數據缺失、通信錯誤和其他參數。通常采用值：好/壞/不確定和附加信息。
• 該時間戳報告時可變收到的給定值的時間。
• OPC 服務器輪詢變量的頻率設置了更新變量值的時間。
• 變量描述，其中包含有關此變量是什么的用戶信息。

此外，可以指定可選屬性，例如：值變化范圍、測量單位和其他自定義參數。

可以使用多種模式從 OPC 服務器讀取數據：

• 同步模式：客戶端向服務器發送請求并等待它的響應。
• 異步模式：客戶端發送請求并立即繼續執行其他任務。處理完請求后，服務器向客戶端發送通知，客戶端獲取提供的數據。
• 訂閱模式：服務器只向客戶端發送發生變化的標簽。為了防止數據的噪聲被誤認為它們的變化，引入了“死區”的概念，它稍微超過了干擾的最大可能幅度。
• 數據刷新模式：客戶端調用所有活動標簽的同時讀取。除了那些被指定為“被動”的標簽外，所有標簽都被稱為主動標簽。標簽的這種劃分通過更新從物理設備接收到的數據來減少處理器的負載。

客戶端從緩沖區或直接從終端設備接收來自 OPC 服務器的數據。從緩沖區讀取速度更快，但其中的數據在讀取時可能已過期。OPC 服務器通過從終端設備請求信息來定期更新數據。

數據以同步或異步模式寫入終端設備，無需中間緩沖。在同步模式下，客戶端寫入數據并等待，直到收到終端設備對命令執行的確認。此過程可能需要很長時間，在此期間客戶端正在等待。異步模式允許客戶端向服務器發送請求并執行其他任務。錄制結束后，服務器會向客戶端發送通知。

OPC UA 標準

OPC UA（統一架構）是工業網絡中數據傳輸的現代標準。它提供設備之間安全可靠的通信，同時獨立于硬件和平臺，允許不同操作系統的設備之間進行通信。

OPC UA 的優勢在于面向對象的信息模型，它允許“查看”數據（以 Web 瀏覽器樣式）和面向服務的架構 (SOA)。如果之前您必須使用多個 OPC 服務器：用于實時數據的 OPC DA、用于歷史的 OPC HDA 和用于事件的 OPC AE，現在所有這些以及更多功能都可以在一個 OPC UA 標準中使用?，F在引入了節點或對象的概念，而不是標簽樹。每個節點包括一個真實對象的變量、方法和其他數據結構。

數據交換現在通過二進制結構和 XML 文檔進行。除了客戶端/服務器模型，發布者/訂閱者模型變得可用。該標準還定義了一種機制來支持冗余（如果一個客戶端變得不可用，那么另一個客戶端會取代它）并在發生故障時快速恢復通信。數據傳輸通過傳輸層 TCP、HTTP/SOAP 或 HTTPS 進行。OPC UA 支持數字證書和加密傳輸數據的能力，而不是 Windows 訪問控制機制。

通過特殊的包裝器和代理模塊實現了與 OPC DA 的向后兼容性。為了通過路由器和防火墻傳輸數據，OPC DA 需要使用???????中間件，而 OPC UA 在沒有這種介質的情況下工作。OPC UA 規范包括幾個部分，描述了服務器和客戶端的操作邏輯。IEC 62541 標準中提供了該規范的詳細版本。

OPC UA 服務器示例

OPC UA 服務器的一個示例是 MOXA 的 MX-AOPC UA Suite。

MX-AOPC UA Suite包括 3 個程序：

• 服務器是用于從 Modbus 設備接收數據的程序
• 查看器是一個查看標簽和服務器狀態的程序（查看器內置于服務器中）
• Logger 用于記錄數據變化的歷史，以及與數據庫和云解決方案的集成

首先，MX-AOPC UA Server 專注于 MOXA I/O 模塊，因為具有 Active Tag 功能，但它也通過 Modbus RTU 和 Modbus TCP 協議支持第三方設備。Active Tag 功能允許您在更改后立即更新通道的狀態，而無需等待來自服務器的命令。

MX-AOPC UA Logger 允許您通過 ODBC 將數據發送到 Microsoft Azure Cloud 和?
Microsoft SQL Server、MySQL、Oracle、Microsoft Office 2003 Access 或 Excel 數據庫。

MX-AOPC UA 通過使用 Basic128Rsa15 密鑰進行加密并使用 X509 證書進行確認來實現數據保護。

使用 OPC 的缺點

使用 OPC 時的常見錯誤包括：

• 過度依賴 OPC 技術
• 在 APCS 中不必要地使用 WEB 技術
• 在遠程機械任務中使用實時協議

假設您已經了解了良好的 OPC 技術，并且正在努力僅用 OPC 替換所有低層協議。但是將 Modbus、Profibus 和任何其他工業協議轉換為 PC 格式將需要額外的時間并浪費計算能力。測試表明，SCADA 系統直接使用工業協議的速度比通過中間 OPC 服務器快兩倍。當然，有些系統不需要實時監控過程，但是在設計自動化過程控制系統時必須考慮到這一點。

缺點還包括設置 OPC 服務器的復雜性以及需要手動輸入數千個標簽。此外，OPC 服務器并不總是免費提供的，大多數情況下您必須為每臺 PC 購買單獨的許可證。

如果系統通過互聯網將數據發送到云端，那么弱加密方案就可能成為潛在的漏洞和黑客攻擊的目標，從而對整個ICS的安全性產生懷疑。

用于實時操作的 OPC UA

OPC UA over TSN旨在支持實時操作，這種 OPC UA 技術可以結合 TSN（時間敏感網絡）技術使用發布者/訂閱者模型（而不是客戶端/服務器模型）。

客戶端/服務器模型在點對點連接的情況下工作正常，但如果有很多設備，則數據更新會出現延遲。發布者/訂閱者模型提供了一對多和多對多的關系。服務器將其數據發送到網絡（發布），每個客戶端都可以接收此數據（訂閱）。

采用 TSN 技術的以太網在服務質量 (QoS) 方面補充了現有的以太網設施，包括帶寬分配、定時、低延遲保證和冗余。數據由各種設備通過以太網以流的形式傳輸。帶有 TSN 的以太網交換機允許您為每個流分配自己的帶寬并確保其實時傳輸。多個流可以組合（稱為網絡融合）并通過同一網絡實時發送。事實證明，如果沒有 TSN 技術，一個以太網網絡只能傳輸一種實時協議，而使用 TSN 則可以傳輸多種實時協議。

OPC UA over TSN 技術的組合允許組織不同制造商生產的設備之間的通信，并確保實時連續接收數據。

OPC 基金會計劃使用 OPC UA 不僅在控制器和 SCADA 系統之間傳輸數據，而且在現場級別從傳感器和物聯網設備到控制器，以及從云中的本地系統傳輸數據。為此，他們計劃將 OPC UA 標準分為 4 個部分，具體取決于設備的性能及其所需的功能。

• Nano Embedded Device Server：適用于最小的傳感器
• 微型嵌入式設備服務器：適用于廉價的 PLC
• 嵌入式UA Server：適用于更強大的PLC和邊界網關
• 標準 UA 服務器：支持所有功能的成熟實現

OPC UA 觀點

可以肯定地說，盡管 OPC DA 標準仍在廣泛使用，但它已不再滿足現代自動化要求。它基于遺留技術，難以配置，不符合現代安全標準。它被現代 OPC UA 標準所取代，具有加密數據和構建從傳感器到云的統一數據傳輸系統的能力。OPC UA 與 TSN 的聯合使用顯著擴展了實時數據傳輸技術的能力。

-- 最后總結啊~ 上面都是墨跡一下概述???????

我們通用使用ua結合中間件-比如kepserver去連某PLC, da好像是只能Windows太久忘了,

當然你也可以直連plc那你就自己解析協議把, 如果不想麻煩拿著點表去裝中間件吧 ,但這些都是要錢的~~ 大伙要想辦法拉 你們明白的, 說到這里每家PLC梯形圖可不是通用的~~ 而且就說kepserver也不是所有plc都支持 好多山寨或垃圾都沒有~~ 還是要自己解析... 說到物聯網關 我想就是支持越多的PLC越好~~ ?當然了觸摸屏那種485的 你可以接線到自己那解析以后或是開關值你就去猜~ ?說到這世面上還有一堆 可以連比如西門子PLC的軟件~~

GitHub - s7connector/s7connector: S7 PLC Connector for java??????? 一個java連西門子的

上圖倆接西門子的~ ?接plc時還要看是接網口還是485 還有更老的 是232(還丟包...)

?

?

?