介紹

1994 年間,由一群產業界的代表性廠家組成一個團體,現在稱為 OPC 基金會。OPC 基金會以發展出單一的 Client/Server規範為目標,能夠讓各個廠家依循此一規範,去發展能夠在快速與穩定的情況下分享資料的軟體和應用程式,而且如此一來,各個廠家就可以減少因為必須針對不同的設備去開發特有的驅動軟體而付出的加倍心力。
OPC基金會發展出的第一個規範稱為 Data Access Specification 1.0a,在 1996 年初發表。依循此一規範,廠家可以快速地開發Client/Server 版的驅動軟體。

OPC 基金會和 Data Access Specification 的主要目標,是讓廠家能夠減少為他們的設備開發專屬的通訊驅動程式的心力。對許多廠家來說,開發大量的通訊驅動程式的心力,遠超過開發他們為客戶開發的應用系統所花的心力。
採用 OPC 技術,廠家現在能夠將他們的心力,幾乎只要專注在為客戶開發的應用系統上。

Data Access Specification 定義 Client 和 Server 應用程式界面應該如何建立。只要正確地遵循規範,只要某一個工業設備提供有 OPC server,就能為資料的溝通提供必要的連接。
OPC 給予終端使用者的額外好處,是讓他們能夠選擇最好的軟體,以解決應用系統的問題。

過去,如果應用軟體沒有需要的通訊驅動程式,或通訊驅動程式無法正常工作,唯一的解決方式就是試著去找到原廠,或自行開發需要的驅動程式,或是修復既有的驅動程式。而這其中的任一種方式所花費的時間,通常都不短。使用 OPC,終端使用者不會受限於必須去尋求原廠協助。
使用者為使用新的驅動程式或是為改善系統效能,現在可以從許多的 OPC Server 廠商中去做選擇。相同的,應用系統廠家現在可以專注在持續的改進他們的核心產品,而不會有花費無謂心力在設備通訊的需要。
OPC 主要是被設計來從網路伺服器上存取資料,其實,OPC 界面可以被使用在許多種不同的應用系統。在最低層次,它們可以從實體設備取得原始資料進入 SCADA 或 DCS 系統,或是從 SCADA 或 DCS 系統進入應用系統。

這種架構和設計使得能夠建構出一個 OPC 應用架構,它允許單一的 OPC Client 應用程式去存取執行在不同電腦中,由多個不同 OPC 廠商所提供的 OPC Servers 中的資料
OPC 定義兩組界面:OPC Custom Interfaces 和 OPC Automation Interfaces。

OPC 規範定義 COM 界面,而不是實作那些界面。它定義界面的行為,這些界面是設計來預計提供給使用它們的 OPC Client 應用程式用的。
另外,包括架構和被認為是此架構最恰當的界面之描述。像所有 COM 元件的實作一樣,OPC 的架構是一個Client/Server 的模組,OPC Server 組件提供界面給 OPC 物件,並管理這些界面。
在實作一個 OPC Server 時有一些特別的考慮,最主要的考慮是資料經由非共享的通訊路徑傳送至實體設備的頻率。所以,我們希望 OPC Server 將是 Local 或 Remote 的 EXE 執行檔,它包含負責有效率的從實體設備收集資料的程式碼。

OPC Client 應用程式經由指定的 OPC Custom 和 Automation 界面與 OPC Server 通訊。OPC Server 必須實作 Custom 界面,和選擇性地實作 Automation 界面。
此一規範描述 OPC COM 物件和 OPC Server 所實作出來的界面。一個 OPC Client 可以同時連接多個由不同廠家所提供的 OPC Servers。
各個不同的廠家都可以提供 OPC Servers。廠家所提供的程式碼決定每個Server 存取的設備和資料、資料名稱、和 Server 如何存取資料的細節。

從較高的層面來看,OPC Server 是由一些物件所組成:Server、Group、和 Item。OPC Server 物件負責維護有關 Server 的資訊,和作為 OPC Group 物件的容器。OPC Group 物件維護有關自己的資訊,並提供包含和邏輯上的組織 OPC Item 物件。

OPC Groups 提供一個方式,讓 OPC Clients 來組織資料。例如,在一個特別的操作界面或報表中,Group 可能被用來呈現 Items,讓資料能夠被讀和寫。OPC Client 可以設定 OPC Server 提供變動資料給 OPC Client 的速率。

總共有二類的 Groups,Public 和 Local(或Private)。 Public是為了讓多個 Clients 能夠相互分享,Local 是表示與 Client 位於同一機器上的。Public Groups 也有其他選擇性的界面。在一個 Group 之中,OPC Client 可以定義一個或多個 OPC Items。

OPC Items 是 OPC Server 中代表與資料來源的連接。從 Custom interface 的觀點,一個 OPC Item 是不能被 OPC Client 當作物件來存取的。因此,OPC Item 沒有定義外部的界面,所有對 OPC Item 的存取都是透過包含 OPC Item 的 OPC Group 物件。
與每個 OPC Item 相關的是 Value、Quality 和 Time Stamp。Value 是 VARIANT 的型態,Quality 與 Fieldbus 定義的相類似。

請注意,OPC Item 並不是資料來源,它們只是連接至資料來源。例如,在 DCS 系統中 tags 的存在,並不表示 OPC Client 是否在存取它們。OPC Item 應該被簡單地想像成指定資料的位址,而不是實際的資料來源。
OPC 是 OLE for Process Control (OLE = Object Linking and Embedding) 的縮寫,而 OLE 也已被重新架構和重新命名成 ActiveX。

OPC 是由一些全世界的領導性硬體與軟體供應廠家,經與 Microsoft 合作,所共同建立出來的一個工業標準。OPC 是植基於 OLE(現在稱為 ActiveX),COM (Component Object Model) 和 DCOM (Distributed Component Object Model) 技術,且支援所有 32 位元的微軟 Windows 作業系統。

將 DCOM 移植到其它作業系統,就使得它也能整合 Linux 和 Unix 系統。OPC 定義了一組標準界面、屬性和方法,以使用在生產流程控制和自動化軟體應用系統。
在自動化產業常見的情形是,利用來自許多不同的硬體供應商的設備,和來自許多不同軟體供應商的視覺化套裝軟體與生產流程控制軟體,才能組合成一個完整的系統。
在這個系統裡面,不同的軟體組件需要去相互通訊。應用軟體必須與各種 I/O 設備及其他應用程式作通訊。為了讓這些不同的軟體模組來一起工作,對生產系統製造商來說,是很大的一個挑戰。

這些問題的產生是由於資料交換的界面缺乏相容的標準。在過去,廠商都是發展他們自己專屬的硬體與軟體解決方案。所有的生產流程控制與資訊系統,都有它們自己存取資訊的界面。通常一個 I/O 設備的驅動程式,都是由不同的廠商去開發許多次。這樣子就可能在不同客製化開發或是昇級過的驅動程式之間造成無法一起工作的情形。
而且,一個設備也許不能讓不同的軟體同時使用,因為它們必須使用獨立的驅動程式且硬體特性也不支援客制化驅動程式。

在過去,硬體廠商利用提供他們自己的驅動程式的方式,試著去解決一些這類的問題。今天,最新最快的解決方式,是採用標準的 Plug and Play 的軟體技術給生產流程控制與自動化。有了這樣的一個標準,使得不同的套裝軟體輕易地與不同的設備連接和通訊變成可能。此一標準,就是 OPC。
OPC UA 架構是 DCOM 技術的一個演化。OPC 架構原先是被組織成以 Server 應用軟體的形式,蒐集生產設備的資訊並提供給執行在 Windows 平台的 Client 端應用軟體系統來使用的一種解決方案。
現在,由於 Microsoft .NET Framework 的導入,提供了一個軟體環境,支援從 DCOM 演化成以服務為導向的架構。OPC UA 架構是為了以與通訊協定和作業平台均無關的設備通訊方式而提供。

OPC UA 也是被設計來整合 DCOM OPC Server 的資料模式和服務方式。原先的 OPC DA Server 提供存取生產線設備的即時資料;OPC A&E Server 讓 Client 端應用軟體可即時接收到 Evnet/Alarm 的通知。這些 Server 不僅都有自己的定址空間和命名方式,它們也都有各自提供各別的服務。

OPC UA 提供了一個整合性的位址空間和服務模式,這樣一來就可讓一個單一的 OPC UA Server 來整合生產線的即時資料、Alarm/Event、和歷史資料等進入它的位址空間,並且以整合型的服務來存取這些資料。

OPC UA 也為應用系統一致性提供了通訊品質碼 (Quality Code) 的功能。通訊品質碼是被 Server 用來指出資料值好壞的程度,以往這通常是以資料蒐集時的相關參數來訂定,OPC UA 則以較為一致的方式定義了這些品質碼的準則。

OPC 是被設計來確保資料傳輸的穩定性,所有 OPC Server 的主要功能都是用來發佈資料或是事件通知。OPC UA 也提供了讓 OPC Client 能夠快速地偵測和從通訊失敗中回復的機制,而不必苦苦地等待長時間的 timeout。

Please publish modules in offcanvas position.