PLC和上位機組態(tài)軟件通訊方式

PLC和上位機組態(tài)軟件不在同一個地方，那PLC如何遠程和上位機通訊呢?，F(xiàn)在物聯(lián)網(wǎng)技術快速發(fā)展，PLC通過互聯(lián)網(wǎng)就能實現(xiàn)和上位機通訊。

PLC的通訊協(xié)議是工業(yè)通訊協(xié)議，不能直接支持互聯(lián)網(wǎng)通訊，那就首先就需要將PLC的通訊協(xié)議轉為可以在互聯(lián)網(wǎng)通訊的協(xié)議，上位機組態(tài)也是支持工業(yè)通訊協(xié)議，因此到了上位機這邊，網(wǎng)絡協(xié)議又要還原為工業(yè)通訊協(xié)議。這就是PLC遠程和上位機組態(tài)通過互聯(lián)網(wǎng)遠程通訊的原理。

互聯(lián)網(wǎng)通訊還有一個問題，就是怎么確定設備地址，局域網(wǎng)是通過IP。互聯(lián)網(wǎng)因為需要通過多過網(wǎng)絡節(jié)點，直接輸入IP是不可能實現(xiàn)的。這就需要一個能聯(lián)通兩邊的技術方案，簡化網(wǎng)絡節(jié)點配置，因此現(xiàn)在基本采用云服務器中轉，采用域名連接技術。

因為工業(yè)4.0的需求，PLC遠程的需求蓬勃發(fā)展，市場上就出現(xiàn)了專門做PLC遠程模塊的廠家。

PLC遠程分兩種技術方式，一種是透傳，一種是協(xié)議轉換。

1：透傳方式

這種方式只是遠程的兩邊利用云服務器為中轉節(jié)點，讓遠程兩邊形成一個網(wǎng)絡通道，利用遠程兩邊設備自帶的協(xié)議通訊，這種模塊簡單來說就是實現(xiàn)一個網(wǎng)線的功能，功能很簡單。

這種方式就需要兩邊設備的協(xié)議要能匹配，比如wincc遠程監(jiān)控1200 plc,就需要用wincc 自帶的1200 plc協(xié)議，第三方不帶協(xié)議的軟件，就很難監(jiān)控，比如程序員用C++，JAVA，PHYSON，LABVIEW開發(fā)的軟件。第三方軟件要監(jiān)控，那就需要程序員還需要破解1200的協(xié)議，在軟件里面做這個協(xié)議的驅動。這就對程序員要求太高了，大部分程序員是不知道PLC的協(xié)議的，因為PLC的協(xié)議每個廠家都不同，也是PLC廠家的設置的一個技術壁壘。所以這種模塊是沒有手機APP，網(wǎng)頁監(jiān)控的，一般也不支持MES系統(tǒng)。

透傳模式還有一個弊端，他這種自身是不過數(shù)據(jù)檢驗的，網(wǎng)絡經過大量節(jié)點，是存在大量干擾的，長時間監(jiān)控是不穩(wěn)定的，而且這種方式對服務器資源占用特別大。服務器上運行的設備多了，基本就很難穩(wěn)定運行。這種方式遠程短時間下載PLC程序或者調試是問題不大，但是長時間不間斷監(jiān)控采集數(shù)據(jù)，基本不穩(wěn)定的，這個技術架構就決定了，這種技術方式不能用于長時間的監(jiān)控。做這種設備的廠家大部分都是做路由器轉行過來的，他們實際不懂PLC的協(xié)議，只熟悉網(wǎng)絡通道配置。

2：協(xié)議轉換模式

協(xié)議轉換模式是前端硬件模塊，內置各種PLC協(xié)議，連接不同的PLC使用不同的協(xié)議。是采用變量映射寄存的方式，將PLC的通訊協(xié)議，轉為互聯(lián)網(wǎng)協(xié)議。這個就要求廠家對PLC有很深的技術研究和積累。

這種方式是以變量為核心,在模塊內部的嵌入是系統(tǒng)，將PLC上傳的數(shù)據(jù)轉為互聯(lián)網(wǎng)通訊方式，將互聯(lián)網(wǎng)下發(fā)的命令轉為PLC可識別的協(xié)議。變量同步在服務器上。遠程端依據(jù)開放的接口和標準的協(xié)議，來服務器交互數(shù)據(jù)。這種轉換后的協(xié)議，標注一般是OPC UA/DA，HTTPS。還有一種是MQTT，MQTT其實是HTTPS的

一種，就是按照固化好的通訊格式，給固定的地址發(fā)送數(shù)據(jù)。這種方式的核心，就是在網(wǎng)絡傳輸?shù)牟辉谑枪I(yè)協(xié)議，可以采用各種網(wǎng)絡數(shù)據(jù)壓縮和加密方法，實現(xiàn)數(shù)據(jù)傳輸，大幅減小數(shù)據(jù)傳輸?shù)牧髁俊＞W(wǎng)絡技術先進的公司，還會采用校驗握手機制，數(shù)據(jù)發(fā)送失敗，還會重發(fā)。這樣就可以保障數(shù)據(jù)穩(wěn)定傳輸，而且這種技術可以很大程度上減輕服務器的負擔，才能確保服務器的穩(wěn)定。

對數(shù)據(jù)壓縮處理，和服務器優(yōu)化這個就考驗模塊生產公司的技術能力。對服務器和網(wǎng)絡數(shù)據(jù)傳輸?shù)墓緝?yōu)化壓縮數(shù)據(jù)傳輸?shù)哪芰透鼜?，處理和傳輸?shù)據(jù)的數(shù)量就更大，速度就更快，且服務器穩(wěn)定性會高很多。這個就是火車自動購票系統(tǒng)為什么最后需要阿里來介入優(yōu)化，以前老是卡死奔潰，這就就是各個廠家對大數(shù)據(jù)服務器技術架構的水平。

目前要實現(xiàn)PLC遠程和上位機通訊，比較好的技術方式就是加第三方的遠程模塊，通過云服務器中轉網(wǎng)絡節(jié)點這種方式成本低，安裝調試時間極短，這種方式經過10多年的發(fā)展，已經非常成熟和可靠。

還有一種PLC遠程和上位機通訊的方式是采用VPN的方式，這種方式是網(wǎng)絡運營商給設備間做一個專網(wǎng)連接，形成類似一個局域網(wǎng)的模式。這種方式，就是成本高，需要每年付專網(wǎng)租賃費給運營商，還要等運營商來配置，費用高，架設時間長，這種方式因為專網(wǎng)只給客戶自己用，穩(wěn)定性和可靠性是高于透傳模式的。

審核編輯：湯梓紅