opc協議

Ⅰ OPC協議和TCP/IP協議的區別和聯系是什麼

TCP/IP協議只是網路層的協議，OPC協議是應用層的數據協議，把自動化採集數據以一定格式傳輸給客戶端，在網路的底層傳輸過程是基於TCP/IP協議得以進行的。

OPC協議：OPC是一種利用微軟的COM/DCOM技術來達成自動化控制的協定，採用典型的C/S模式，針對硬體設備的驅動程序由硬體廠商完成，提供統一OPC介面標準的Server程序，軟體廠商只需按照OPC標准介面編寫Client程序就訪問Server程序進行讀寫，即可實現與硬體設備的通信。

TCP/IP協議：TCP/IP協議又名網路通訊協議，是Internet最基本的協議、Internet國際互聯網路的基礎，由網路層的IP協議和傳輸層的TCP協議組成。TCP/IP 定義了電子設備如何連入網際網路，以及數據如何在它們之間傳輸的標准。協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的協議來完成自己的需求。通俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求重新傳輸，直到所有數據安全正確地傳輸到目的地。而IP是給網際網路的每一台聯網設備規定一個地址。

拓展資料

協議，網路協議的簡稱，網路協議是通信計算機雙方必須共同遵從的一組約定。如怎麼樣建立連接、怎麼樣互相識別等。只有遵守這個約定，計算機之間才能相互通信交流。它的三要素是：語法、語義、時序。

為了使數據在網路上從源到達目的，網路通信的參與方必須遵循相同的規則，這套規則稱為協議（protocol），它最終體現為在網路上傳輸的數據包的格式。

協議往往分成幾個層次進行定義，分層定義是為了使某一層協議的改變不影響其他層次的協議。

Ⅱ 什麼是opc通訊

OPC全稱是Object Linking and Embedding（OLE） for Process Control，它的出現為基於Windows的應用程序和現場過程式控制制應用建立了橋梁。

在過去，為了存取現場設備的數據信息，每一個應用軟體開發商都需要編寫專用的介面函數。由於現場設備的種類繁多，且產品的不斷升級，往往給用戶和軟體開發商帶來了巨大的工作負擔。

通常這樣也不能滿足工作的實際需要，系統集成商和開發商急切需要一種具有高效性、可靠性、開放性、可互操作性的即插即用的設備驅動程序。

在這種情況下，OPC標准應運而生。OPC標准以微軟公司的OLE技術為基礎，它的制定是通過提供一套標準的OLE/COM介面完成的，在OPC技術中使用的是OLE 2技術，OLE標准允許多台微機之間交換文檔、圖形等對象。

(2)opc協議擴展閱讀

OPC是世界上最受歡迎的基於標準的數據通信方法。它旨在解決自動化行業中的最大的挑戰：如何擺脫傳統的基於特製驅動器的通信方式，在不同設備、控制器、和/或應用程序之間實現通訊。

OPC之所以能夠成功地創造真正獨立於供應商的通訊是因為，OPC從雙方提取了數據發送設備（例如PLC）和數據接收端（例如HMI）的執行細節，因此可以在它們之間進行數據交換而不需要了解彼此的本地通信協議和內部數據組織形式。

這與特製驅動器的要求滿足只針對於通信方兩端的編寫方法形成了鮮明的對比。OPC可以代表為一個位於數據發送端和數據接收端之間的「提取」界面，這個界面允許在數據發送端和數據接收端之間交換數據而不需要對對方有任何了解。

OPC的「設備細節提取」是通過運用兩個稱為OPC客戶端和OPC伺服器的OPC構件得以實現的。其中每一個構件將在以下章節予以描述。需要注意的是，數據發送端和數據接收端能夠彼此通過OPC進行通訊並不意味著它們各自的本地協議就不需要了，或者是被OPC取代了。

相反，這些本地協議和/或介面仍然存在，但只是與兩個OPC構件的其中某一個通訊。然後，OPC構件之間進行數據交換，從而結束數據傳遞。數據也可以從應用程序端被傳輸至設備，而不需要彼此直接聯系。

Ⅲ 西門子PLC怎麼通過OPC進行通信

OPC server是軟體，一般是在組態軟體中。比如：wincc、組態王什麼之類的。
建議你購買組態軟體直接連上就能用了。

Ⅳ 如何將TCP/IP協議解析轉換為OPC協議

TCP/IP協議抄與OPC協議是完全不同的兩個概念，TCP協議是乙太網通訊協議，OPC是工業數據採集伺服器協議，OPC服務通過COM+技術實現的，實現不同電腦，不同進程間的數據共享的一種技術標准。OPC伺服器在與工業控制前端設備通訊時，既可以使用TCP協議在乙太網上通訊，也能通過串口通訊。OPC就像是一個黑匣子，不必關心它怎樣進行數據通訊，只要按照OPC提供的方法，共享OPC採集的數據即可。也就是說，只要架設好了OPC伺服器，TCP與OPC的轉換就完成了，你只需要對OPC獲取數據即可。OPC伺服器端，有很多現成的產品，只要完成OPC的通訊以及變數設定即可。

Ⅳ OPC是通信協議嗎

OPC(OLE for Process Control, 用於過程式控制制的OLE)是一個工業標准，管理這個標准國際組織是OPC基金會，OPC基金會現有會員已超過220家。遍布全球，包括世界上所有主要的自動化控制系統、儀器儀表及過程式控制制系統的公司。
基於微軟的OLE(現在的Active X)、COM (部件對象模型)和DCOM (分布式部件對象模型)技術。OPC包括一整套介面、屬性和方法的標准集，用於過程式控制制和製造業自動化系統。
OPC全稱是OLE for Process Control，它的出現為基於Windows的應用程序和現場過程式控制制應用建立了橋梁。在過去，為了存取現場設備的數據信息，每一個應用軟體開發商都需要編寫專用的介面函數。由於現場設備的種類繁多，且產品的不斷升級，往往給用戶和軟體開發商帶來了巨大的工作負擔。通常這樣也不能滿足工作的實際需要，系統集成商和開發商急切需要一種具有高效性、可靠性、開放性、可互操作性的即插即用的設備驅動程序。在這種情況下，OPC標准應運而生。OPC標准以微軟公司的OLE技術為基礎，它的制定是通過提供一套標準的OLE/COM介面完成的，在OPC技術中使用的是OLE 2技術，OLE標准允許多台微機之間交換文檔、圖形等對象。
COM是Component Object Model的縮寫，是所有OLE機制的基礎。COM是一種為了實現與編程語言無關的對象而制定的標准，該標准將Windows下的對象定義為獨立單元，可不受程序限制地訪問這些單元。這種標准可以使兩個應用程序通過對象化介面通訊，而不需要知道對方是如何創建的。例如，用戶可以使用C++語言創建一個Windows對象，它支持一個介面，通過該介面，用戶可以訪問該對象提供的各種功能，用戶可以使用Visual Basic，C，Pascal，Smalltalk或其它語言編寫對象訪問程序。在Windows NT4.0操作系統下，COM規范擴展到可訪問本機以外的其它對象，一個應用程序所使用的對象可分布在網路上，COM的這個擴展被稱為DCOM（Distributed COM）。
通過DCOM技術和OPC標准，完全可以創建一個開放的、可互操作的控制系統軟體。OPC採用客戶/伺服器模式，把開發訪問介面的任務放在硬體生產廠家或第三方廠家，以OPC伺服器的形式提供給用戶，解決了軟、硬體廠商的矛盾，完成了系統的集成，提高了系統的開放性和可互操作性。
OPC伺服器通常支持兩種類型的訪問介面，它們分別為不同的編程語言環境提供訪問機制。這兩種介面是：自動化介面（Automation interface）；自定義介面（Custom interface）。自動化介面通常是為基於腳本編程語言而定義的標准介面，可以使用VisualBasic、Delphi、PowerBuilder等編程語言開發OPC伺服器的客戶應用。而自定義介面是專門為C++等高級編程語言而制定的標准介面。OPC現已成為工業界系統互聯的預設方案，為工業監控編程帶來了便利，用戶不用為通訊協議的難題而苦惱。任何一家自動化軟體解決方案的提供者，如果它不能全方位地支持OPC，則必將被歷史所淘汰。

Ⅵ OPC協議指的是什麼

OPC全稱來是OLE for Process Control，它的出現為基於自Windows的應用程序和現場過程式控制制應用建立了橋梁。在過去，為了存取現場設備的數據信息，每一個應用軟體開發商都需要編寫專用的介面函數。由於現場設備的種類繁多，且產品的不斷升級，往往給用戶和軟體開發商帶來了巨大的工作負擔。通常這樣也不能滿足工作的實際需要，系統集成商和開發商急切需要一種具有高效性、可靠性、開放性、可互操作性的即插即用的設備驅動程序。在這種情況下，OPC標准應運而生。OPC標准以微軟公司的OLE技術為基礎，它的制定是通過提供一套標準的OLE/COM介面完成的，在OPC技術中使用的是OLE 2技術，OLE標准允許多台微機之間交換文檔、圖形等對象。

Ⅶ OPC通信協議怎麼解析抓包抓出了一些OPC協議傳輸的數據，想對其進行分析，不知道怎麼分析，求解釋

OPC協議是公開的，基金會有鏈接庫提供。從報文分析很復雜，搞出來也沒用。

Ⅷ OPC協議指的是什麼

首先聲明，是zz的，我對原文的觀點是：分布式系統的規范不是那麼容易搞出來的。所以OPC-DA暫時是不可替代的，OPC-XMLDA是跨防火牆的新技術，但是實時性差一點。這篇文章的出處是另一篇批評opc的文章的評論。（原文的鏈接是http://blog.cechinamag.com/sup_zoux/9284/message.aspx#3648，被評論的文章標題是OPC——資本和崇洋豢養的病態協議）zz文章如下：

樓主似乎對OPC相當的熟悉，但似乎又不是很懂OPC。

首先OPC是一種協議，OPC協議里只是定義了介面，OPC的不好是由於他建立在了DCOM的基礎之上，大多數的詬病來源於DCOM本身而不是OPC協議本身，至少這篇文章對OPC的不滿也幾乎都來源於DCOM。那麼樓主更應該罵微軟，或是OPC基金會妥協與微軟，而不是OPC協議本身。樓主是希望把OPC協議制定成為像modbus之類的協議，還是提出要建立一套分布式框架替代DCOM呢。這兩者完全不是一個層面上的東西。如果是前者，我勸樓主應該站在更高的層次上，而不是盲目的准備去做無用功，如果是後者本人倒是頗感興趣，本人才疏學淺，分布式框架只知道DCOM 、Cobra 、JMI、.Net Remoting、SOAP。其中JMI和.Net Remoting目前還是依賴於平台，而Cobra則是看起來很美，SOAP像是以後的發展方向，目前OPC 3.0協議已經是基於SOAP的了，性能問題導致他還不能大規模推廣。

第二，OPC協議存在也有不少年頭了，站在現在的觀點對一個陳舊的東西妄加批評似乎有點過分和小肚雞腸。就像我們不能現在說DDE是一種多麼簡陋的IPC技術啊，畢竟他是一個時代的產物，在OPC產生的年代，windows上的主流技術難道不是DCOM嗎，除非一開始就脫離微軟。

第三，「資本和崇洋豢養」這個詞顯得樓主太過於憤青，如果說用OPC就是「資本和崇洋豢養」，那麼我們絕大多數用電腦的人都是「資本和崇洋豢養」，因為我們用的windows、linux、unix、solaris都是洋人給我們的，假如有一天真的有一種真正好的替代OPC的協議產生我第一個支持，如果目前還沒有出來，還是希望樓主遵循「多談些問題，少談些主義」的原則，真正的能夠為中國的自動化協議做些貢獻。

最後送給樓主一句話，「師夷長技以治夷」，治夷之前是師夷而不是鄙夷

原文如下：

OPC——資本和崇洋豢養的病態協議

雖然目前大部分的廠商均支持OPC協議，並將其視為開放的標准。我曾長期從事實時資料庫研發，並對OPC協議有深入研究。到目前為止，除了悲哀，只有一席不得不說的話。OPC真的很先進么？對於過去還一直靠編寫串口協議研發非標產品的一些同仁來說，似乎剛剛感受到其帶來的優點，為了接項目而編寫一些OPC介面等等，也許感覺其神秘而高不可攀。其實，OPC就是基於微軟DCOM技術的一套介面定義而已，在其設計的時候並沒有考慮諸多工控必須的硬體條件因素，僅僅是將微軟DCOM技術原封不動地搬到了工控領域而已。這幾年，每年都有一些同仁公司聯系SUPCON SOFT，希望能夠獲得解決OPC介面的問題，作為OPC基金會的首批會員和國內OPC基金會的倡導者，SUPCON對OPC十分了解，擁有大量可以開發OPC介面的程序員。但這並不意味著SUPCON會承接這些介面問題的服務。作為一個企業，其專業性在於提供自己專業的產品和核心價值所在的服務，而非其它。但這也從另一個側面看出國人對OPC介面的誤解和盲從。OPC真的很美么？從其應用至今，OPC帶來的痛大過其帶來的利益。DCOM是一套依賴微軟技術極深的服務，僅一個OPC,就限制了目前工控領域操作系統的多樣性。這也沒什麼，如果處於愛國，中國還真沒有可圈可點的操作系統。但OPC的問題是在太多了：

※安全性配置復雜：對於對操作系統並不專業的工控人員，OPC的安全性配置已經過於專業和復雜了。這導致了好多實例中，OPC都不是通過系統啟動後自激活的，而是需要有互動式用戶去登錄，這給系統帶來了極大的不安全性。即每次系統重啟都可能需要人為干預。雖然經過合理的DCOM配置可以避免，但不幸的是大部分工控從業同仁對此並不掌握；

※遠程激活困難：如果兩台計算機不再一個帶有強烈微軟技術特色的「域」里的時候，遠程激活OPC就是一個噩夢，在很多項目上，僅這個配置就另很多工程人員痛心疾首。知道大部分項目中不同域之間的激活是怎麼做到的嗎？呵呵，好多同仁選擇了兩台機器通過相同的用戶名和密碼登錄來破壞安全性；另一些掌握一些編程技術的同仁則通過在一台計算機中保存另一台計算機的用戶名和密碼；這些安全因患之所以不能排除，原因就是該死的OPC協議，這個吸附在微軟的DCOM技術上的毒瘤；

※開發復雜：雖然筆者對DCOM技術掌握得較為熟練，但至今還能回憶起年輕時學習DCOM編程的黑暗日子，DCOM是一種經過一段時間痛苦，然後頓悟，發現原來所有寫DCOM教材的人都在故弄玄虛，人為增加復雜度。同時,DCOM的內存管理和調用技術，往往需要較多經驗，使本來容易的通訊開發，變得焦灼不堪。所以才有目前很多業界同仁委託其它公司開發OPC介面的事情；

※跨平台困難：連跨微軟的多個操作系統，都會有些小問題，能在Linux和UNIX上使用OPC的人，更是寥寥；我至今只是聞名，未嘗親見這類高人；

那麼為什麼這么一個詬病甚多的協議會成為今天普遍接的標准呢？原因有二，一是時機，二是資本。當工業乙太網時代還出於鴻蒙初開，各大自動化廠商還在為未來的匯流排爭論得喋喋不休得時候，微軟，這個操作系統的廠商，利用一種基於自己操作系統的分布式技術，在DCOM彷彿能夠解決一切分布式問題的喪失理智的時代，推出了一種民不見經傳的OLE for Process Control，沒有引起任何一個自動化廠商的足夠重視，而正是因為這種低調的入場，加上各大自動化廠商慣常的保守和對工業乙太網技術發展前景的短視，OPC成長了起來。誰會將一個操作系統的廠商作為競爭對手呢？所以，OPC的開始是比較順暢的。另一個強有力的吹鼓手是微軟，他並沒有鼓吹OPC無所不能，但它過分地鼓吹了DCOM，最終這種資本運作帶來了浮躁，大家索性都不再研究其他開放的工業乙太網傳輸協議了，OPC就是萬能靈丹。歷史再不斷重演，今天的我們，又要被IBM等廠商所謂的SOA和Web2.0技術蒙住雙眼。

另一個原因，就是崇洋，曾幾何時，洋東西好得不得了，我還記得當時曾經定義一個內部的基於TCP數據傳輸協議，就有保守派在我耳邊喋喋不休：協議這東西都是國外大公司制定得，如何如何神奇，如何如何專業，總之，中國人連制定一個企業的TCP傳輸協議的能力都沒有了。不過最終證明，不但能夠制定，只要對工業數據傳輸得需求把握得好，中國人可以制定出一樣優秀得開放數據傳輸協議。但問題似乎總是出現：你制定了，誰擁護啊？你制定了，好吧，雖然是開放式協議，為啥是你A公司制定，不是我B公司制定？國人的問題多得不得了。中國目前也出了十多家有一定規模的自動化廠商，有沒有成立一個多個企業的標准委員會，討論一下國有開放標准？沒有！這就是現實。我們不還以被美國儀器儀表協會承認而自豪么？我們不還為了能夠達到歐洲標准而欣慰么？所以，在這樣的土壤上，本土的種子難得開花結果。

其實，最適合工業使用的乙太網數據交互協議，絕對不是OPC，而應該是一種基於TCP/IP的，平台無關傳輸協議。這種協議得制定，只要兼顧了實時值、歷史值、主動變化通知，考慮了批量數據讀寫和並發連接，考慮了不同設備處理速度得不同，就會變得即魯棒又實用。而我們國人完全有能力制定自己的開放協議！

我深深的知道，問題雖然明顯，但明天早晨，我仍然必須接受這個洋品牌和洋標准充斥的世界。OPC雖然不好，但未來5年恐怕還會被趨之若騖。我的力量雖有限，但有幸的是我在一家民族自動化企業就職，還可以一點點地身體力行以盡綿薄，希望國內業界同仁達成共識，有朝一日，可以共同推動由中國人制定的開放工業乙太網實時數據傳輸標准，到那個時候，這個自動化的行業，才能因開放的標准而變得簡單高效，四通八達。就脫離微軟。

Ⅸ 如何將modbus轉換成OPC協議

將modbus轉換成OPC協議的兩種方法如下：
第一：你可以用MatrikonOPC Genie 產品，不需要軟體編程就可以實現版。
第二種：軟體編程。現在很多做權OPC軟體的廠家都有提供一種SDK，大家在這個平台上可以做自己想要的OPC伺服器。

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

Modbus是由Modicon在1979年發明的，是全球第一個真正用於工業現場的匯流排協議。
ModBus網路是一個工業通信系統，由帶智能終端的可編程序控制器和計算機通過公用線路或局部專用線路連接而成。其系統結構既包括硬體、亦包括軟體。它可應用於各種數據採集和過程監控。

Ⅹ 我是mes方，如何通過opc協議獲取數據，需要具備哪些條件，對方是dcs系統

RS232和HSMS應該都可以，現在大多數設備都支持網路協議的傳輸了