據說看了這篇文章就完全搞懂了什麼是OPC（上）

從2000年初以來，咱們就一直在使用OPC軟件互操做性標準，而那些正準備踏入和想要踏入工業自動化領域的人們卻對這些含義感到困惑。

因此在本中，我將系統地爲你梳理OPC知識。

OPC首字母縮寫詞表明什麼？

問一個OPC老手，他們或許會笑，由於他們知道有不少含義！在經典的且程序化的說法是：O LE for P rocess C ontrol（用於過程控制的OLE）。OLE 或對象連接和嵌入是Windows的基本早期構建塊，容許應用程序在它們之間共享複雜的信息。我記得Windows 3.0的第一個演示中，人們將 Excel電子表格嵌入到 Microsoft Word文檔中，以及更新電子表格，打開Word和更新文檔的重要性。原始OPC標準源自該技術和 COM 或 Windows 組件對象模型。

從那之後，咱們會聽到不少其餘的一些定義，可是比較出名的是如今官方OPC基金會所給出的說法是：它的含義是O pen P latform C ommunications（開放平臺通訊）。其實不管它的定義是什麼，其目標保持不變：消除自動化軟件和硬件平臺之間互操做性的障礙，爲用戶提供選擇。

OPC Client（OPC客戶端）和OPC Server(OPC服務器)之間有什麼區別？

OPC客戶端請求數據，有時也想寫入數據。若是容許的話，服務器會響應客戶端的請求並提供數據或接受其寫入。最簡單的形式就是這樣。

能夠將OPC服務器看做是協議轉換器，OPC服務器使用設備的專用協議與設備通訊，而後使用OPC Classic和OPC UA規範定義的標準化格式提供對該數據的訪問。一般狀況下，OPC服務器在OPC客戶端請求讀取或寫入數據以前不會執行任何操做。而某些OPC服務器能夠配置爲即便在沒有客戶端請求的狀況下也能夠從設備輪詢數據。這一般是爲了容許OPC服務器在其內部緩存中就具備當前數據而且在客戶端請求它時就已經準備就緒（可是是以產生可能不須要的通訊流量爲代價。）目前許多OPC服務器爲用戶提供了靈活性，能夠根據應用需求來進行配置。

若是個人控制硬件供應商說他們支持OPC，那麼爲何我還須要OPC服務器？

當硬件供應商表示他們支持OPC時，一般並不意味着他們直接將OPC服務器嵌入到他們的硬件中。他們的意思是他們擁有OPC服務器軟件，該軟件在某個基於Windows的計算機上運行，​​​​該計算機與其硬件對話並使用一個或多個OPC標準公開數據。此外，對於某些硬件供應商，可能須要額外的許可費才能啓用此OPC服務器功能。咱們常常聽到用戶對這一點感到困惑。其實只是爲了在銷售時更好聽一點，纔會說「咱們支持OPC」，因此在此須要澄清一下供應商所說的內容。

如今，一些供應商開始利用多平臺功能，並將OPC UA服務器直接嵌入到他們的PLC中。若是你的 HMI或SCADA軟件支持OPC UA，那麼這可能會很是方便。若是你的客戶端應用程序不支持OPC UA，那麼則可使用OPC網關應用程序來幫助你從OPC UA 鏈接到 DA。

OPC服務器必須在Server類計算機和操做系統上運行嗎？

OPC服務器不須要服務器類硬件或操做系統。有些供應商可能會針對其具體實施要求這樣作，但OPC標準並無規定這一點。OPC服務器軟件一般至關輕巧，能夠輕鬆地與臺式PC上的其餘軟件應用程序共存。你能夠諮詢你的OPC服務器供應商，瞭解你的具體應用要求。（以Software Toolbox的產品爲例，在它的每一個產品網站區域都有一個規格頁面，雖然他們的OPC服務器一般不須要服務器級硬件或操做系統。）

2個OPC服務器如何相互通訊？而2個OPC客戶端又如何相互通訊？

在OPC世界中，一般客戶端是與服務器通訊的。可是好消息是OPC服務器能夠與其餘OPC服務器通訊，OPC客戶端也可使用相同的方式。

爲何兩個OPC服務器須要通訊？你能夠想象一下，你有PLC供應商A和PLC供應商B，而且有一個OPC服務器須要使用兩個不一樣的PLC供應商的特定設備協議與每一個服務器進行通訊。你但願將數據從PLC A移動到PLC B，這意味着2個不一樣的OPC服務器須要相互通訊。你可使用OPC Bridging（OPC橋）軟件應用程序執行此操做。OPC橋接軟件應用程序是OPC客戶端應用程序，能夠鏈接到許多不一樣的OPC服務器，而後容許你映射兩個OPC服務器之間的數據移動，指定方向，數據轉換等。

在OPC客戶端相互通訊的狀況下，最多見的應用是須要交換數據的兩個不一樣的SCADA或HMI軟件應用程序。第一個解決方案是查看HMI或SCADA軟件是否支持OPC服務器接口以及OPC客戶端。許多人都是這樣作的，那麼若是是這樣，那麼問題就解決了兩個客戶端應用程序使用其OPC客戶端接口與彼此的OPC服務器接口進行通訊。若是沒有，而且客戶端純粹是OPC DA，UA或DA和UA客戶端，那麼使用諸如 Cogent DataHub 之類的應用程序也將是解決方案。Cogent DataHub能夠充當OPC服務器，其中包含你定義的標記列表，而且兩個OPC客戶端均可以讀取/寫入這些公共標記。

什麼是 OPC數據質量 和 TImestamps ？

在 OPC 以前，當你的 HMI 或 SCADA 軟件用內置驅動程序讀取數據以前，它要麼獲得數據要麼沒有數據。 若是你沒有獲得數據，你就沒法知道最後一次得到數據是何時。 二者之間沒有差異。

使用OPC服務器，它們能夠緩存或保留從設備讀取的最後一個值。它們還會在緩存中爲數據加時間戳（TImestamps），一般使用OPC服務器從設備讀取值的時間。某些設備存儲上次更改數據的時間戳，並可以使用設備特定的通訊協議將其傳遞給OPC服務器。若是設備支持該設備而且OPC服務器支持它，那麼則可使用設備時間戳。（如：支持該功能的協議的設備時間戳的Software Toolbox產品包括TOP Server DNP，IEC 61850和IEC 60870驅動程序。）

OPC質量是OPC服務器告訴OPC客戶更多關於它們提供價值的一種方式。這樣作的方法是傳遞一個數字以及值和時間戳。在OPC中咱們稱之爲VQT或"Value，Quality，Timestamp"（「價值，質量，時間戳」）。OPC質量編號其實是經過設置字位來肯定的，這會致使產生不一樣的值。值192表示「良好」質量，這意味着OPC服務器最後一次輪詢設備它可以成功獲取數據，所以OPC客戶端能夠信任該值。值爲0表示質量不佳，一般表示OPC服務器與其輪詢的設備之間存在通訊故障。OPC服務器可使用一系列其餘值來表示質量差的緣由，但目前它們並未獲得普遍實施。我以前有發過一篇關於OPC數據質量的文章<<一分鐘告訴你什麼是OPC DA質量代碼>>，感興趣的朋友能夠去看看。

其實最重要的是OPC客戶端應用程序一般能夠配置爲更改它們在操做員屏幕或歷史數據庫中向用戶顯示值的方式，以便人們知道該值不值得信任和不值得信任緣由。

關於OPC UA，OPC DA等相關內容，我會在下一篇文章中繼續詳細講解，未完待續。