由於其多功能性和製造商的獨立性，OPC UA現在已經在許多不同的工業應用中使用。但是，OPC UA不僅僅是傳統意義上的傳輸協議。相反，OPC UA是用於工業物聯網（IIoT）和工業4.0的，與協議無關的工業框架，其中包含用於與製造商和平臺無關的安全可靠的資訊交換機制，以及語義資訊建模和自我選擇的選項。裝置的描述。OPC UA可以從各個級別的感測器擴充套件到MES / ERP，也可以擴充套件到雲。它包括從一開始就內建的網路安全機制 ， 更多資訊盡在振工鏈 。

為了滿足終端使用者，供應商以及從過程自動化到工廠自動化的整合商對用例的所有要求，2018年11月，OPC基金會建立了現場水平通訊（FLC）計劃，並得到了眾多主要自動化供應商的支援。該計劃的範圍是共同指定和標準化來自不同製造商的控制器和現場裝置的語義，協議和物理介面。

FLC涵蓋的主要用例是控制器到控制器和控制器到裝置，包括對控制器和現場裝置的IIoT連線的支援。與FLC相關的技術工作包括以下主題：

定義“自動化元件”，其功能，介面和行為是過程和工廠自動化中各種應用中使用的不同FLC相容控制器和裝置所共有的功能，介面和行為

定義系統行為和常見功能的序列（例如，引導和連線建立）

l  I / O，運動控制，功能安全性和系統冗餘之類的應用程式配置檔案的協調和標準化

l  線上和離線場景下現場裝置的OPC UA資訊模型的標準化（例如，裝置描述和診斷）

l  對映到下級通訊協議和傳輸物理機制，例如TCP，UDP，乙太網APL / SPE，確定性乙太網（TSN），並將來對映到5G和Wi-Fi 6

l  確保OPC UA配套規範的最佳整合，例如FDI，FDT，PA-DIM，分析儀裝置整合（ADI），模組型別包（MTP）和MDIS（油氣），VDMA泵，UMATI和Spectaris。

FLC互動模型

為了從過程和工廠自動化應用的廣泛領域中的特定和多樣化的應用場景中進行概括，FLC使用了一個抽象的互動模型以及各種“抽象的” OPC UA用例。

控制器代表通常在可程式設計自動化控制器，可程式設計邏輯控制器或分散式控制系統中實現的功能。如今，自動化裝置通常連線到控制器，並且可以像感應式接近開關一樣簡單，也可以像科里奧利流量計或伺服驅動器一樣複雜。Compute的硬體方面從基於Raspberry Pi的資料閘道器擴充套件到雲中的刀鋒伺服器，但更重要的是在這些伺服器上執行的軟體應用程式。控制器和裝置具有許多共同的屬性-術語“自動化元件”用於將功能應用於兩者的情況。

控制器到計算。 無論是儀表板中的管理資訊，長期過程最佳化，預測性裝置級診斷還是數字孿生，在Compute平臺上執行的軟體都是當今的主要創新領域。這些都需要從控制器中提取資訊。OPC UA在當今占主導地位，幾乎每個主要的控制器供應商都直接在其控制器或裝置上提供OPC UA。

控制器到控制器。 工廠所有者和系統整合商正在使用從不同的機器/滑架製造商處購買的機器來組裝複雜的操作。他們可能會發現每個都裝有其他供應商的控制器。這導致需要一種簡單的方法來設定多個供應商之間的控制器之間的通訊。工業自動化行業尚未有效解決此問題，FLC控制器到控制器解決方案將是第一個為所有型別的自動化應用提供涵蓋標準和安全通訊的可互操作的實時解決方案。

控制器到裝置。 在工業自動化領域中，使控制器與I / O模組，驅動器，伺服器，儀器和其他智慧自動化元件的子網進行通訊的傳統現場匯流排方法已廣為人知。但是，當部署融合的IT / OT解決方案或不同的工業自動化技術共享網路時，網路結構和拓撲結構受到限制。FLC計劃將具有達到或超過現有解決方案功能的控制器到裝置的通訊，並將新增IEC 61784規範未完全提供的功能。

裝置到裝置。 透過將多種車間技術的最佳實踐結合在一起，並透過協調終端裝置中使用的應用程式配置檔案，諸如跨多個伺服驅動器的不靈活負載的負載共享之類的應用程式將變得更易於以互操作方式進行部署。

裝置到計算。 控制器通常充當裝置的代理，為這些裝置提供的資訊新增有價值的上下文，並在某些情況下控制對該資訊的訪問。然而，隨著裝置變得越來越複雜，有用變數的數量以及內部和外部測量值的不斷增長，使用控制器作為代理變得越來越不切實際。例如，透過控制器從每個裝置路由4,000個變數不再可伸縮。FLC將定義必要的語義和後設資料，以將來自裝置的資訊上下文化，以在開放式體系結構中的各種基於Compute的軟體應用程式中使用，而不會使控制器成為瓶頸。

計算到計算。 這些應用程式包括通向IT系統的閘道器，雲-雲連線，可互操作的製造運營管理等等。在過去的十年中，現場級通訊計劃將使用並建立在OPC UA在Compute-to-Compute應用程式中取得成功的服務，資訊模型和互操作性的基礎上。在FLC計劃中，預計不需要進一步開發支援Compute-to-Compute應用程式的功能，但是這些應用程式將繼承並受益於在現場一級日益增強的協調性。

FLC系統架構

FLC系統體系結構基於OPC UA框架（IEC 62541），可實現安全，可靠以及與製造商和平臺無關的資訊交換。FLC控制器和裝置一方面支援面向連線的客戶端/伺服器通訊模型，另一方面則支援釋出/訂閱（PubSub）擴充套件。由於對靈活性，效率和確定性有相應的要求，因此OPC UA PubSub對於現場通訊至關重要。FLC還使用OPC UA中指定的安全性機制，該機制尤其支援對要傳輸的資料進行身份驗證，簽名和加密，並且可以用於客戶端-伺服器以及PubSub通訊關係。

FLC指定的擴充套件的核心元素是OPC UA的元模型。這用於為FLC自動化元件指定相應的資訊模型，並透過標準化的OPC UA服務訪問建模的資訊。

由於所有FLC自動化元件（控制器和裝置）都基於OPC UA，因此在所有自動化級別上都可以進行統一的整合通訊，從而支援廣泛的用例，這帶來了全新的可能性，尤其是針對不同的Industry 4.0應用場景和IT / OT融合。

離線工程

離線工程是開發，執行和維護自動化系統的重要元素。當使用者有能力在將系統部署到物理硬體中之前瞭解自動化系統的操作時，一旦物理系統安裝到位，使用者將知道系統將可靠且正確地執行控制功能。使用者將能夠在對物理系統進行更改之前模擬自動化系統的更改和更新，並確保更改將達到使用者的期望並改善系統的效能。在產品和配置描述符的幫助下，相應的配置工具可以訪問裝置描述。但是，規範工作並非“從頭開始，

與FLC相關的建模

與FLC相關的工作的關鍵要素是透過所謂的OPC UA Facets進行功能建模。OPC UA配置檔案表示可以進行原子測試的Facet的集合。完整配置檔案代表裝置的完整功能。

FLC基本方面描述了各種型別的自動化元件（控制器和現場裝置）共有的基本功能，例如裝置標識，基本診斷和連線管理。特定於裝置或功能的方面建立在基本方面上，例如用於功能安全，運動，I / O和儀表。

安全與運動

OPC UA安全性涵蓋了功能安全要求。為此，已經採用了第一個OPC UA安全規範，該規範基於客戶端-伺服器機制，並且是與Profibus使用者組織（PNO）組成的聯合工作組提出的。不久還將有一個擴充套件，描述到PubSub的對映和安全裝置的引數化。OPC UA安全概念的特殊之處在於，即使在正在進行的操作過程中，安全參與者也可以整合到通訊中，而這是常規安全協議所無法實現的。

Motion Facet包含針對各種型別的運動裝置（例如控制元件，標準驅動器，變頻器和伺服驅動器）的運動控制功能的規範。FLC計劃已確定CIP Motion™和Sercos是基於OPC UA Motion的理想解決方案。將使用CIP Motion和Sercos規範，並且可以對其進行更改或擴充套件，以適應FLC系統架構，以支援涵蓋工業4.0和數字化用例的創新，並促進資料建模和實時需求的現代概念。

由OPC指定和標準化的方面可以透過OPC UA配套模型進行補充，例如FDI，FDT，PA-DIM，分析儀裝置整合（ADI），模組型別包（MTP），MDIS（油氣），VDMA泵， UMATI，Spectaris等。此外，可以整合特定於供應商的模型。

通訊

FLC的一個重要方面是為工廠和過程自動化中的廣泛使用案例支援不同的基礎傳輸協議和物理層。為此，引入了服務質量（QoS）建模的概念，它具有將服務靈活地對映到較低階別的通訊協議的可能性。

第一步，FLC支援透過UDP進行的第3層對映和到乙太網TSN的直接第2層對映，二者均可與SPE / APL物理層結合使用。但是，QoS建模還可以輕鬆擴充套件到其他下級傳輸標準，包括無線資料交換，例如5G或Wi-Fi 6。

OPC UA與直接對映到乙太網TSN的組合特別重要。只有這樣，才能透過OPC UA進行確定性的資料傳輸。由FLC指導委員會領導的工作組目前正在制定FLC終端裝置和基礎設施元件的哪些TSN子標準是強制性的，以滿足對效能，靈活性和易用性的特定要求。

在OPC基金會方面，對TSN-IA配置檔案的明確承諾是由IEC / IEEE 60802工作組開發的。其目的是可以透過通用的網路基礎設施傳輸不同的協議和流量型別。這種共存不僅對於IT和OT的融合至關重要，而且在遷移基於常規現場匯流排協議的現有棕地解決方案時也很重要。最後，使用者應該能夠自由決定他們要用新系統替換舊系統或系統元件的速度。

路線圖

儘管 新冠 及其侷限性，但第一個規範版本的工作在最近幾個月取得了良好的進展。基本概念已被廣泛採用，並已納入規範初稿中。第一規範版本的釋出候選版本觸手可及。根據目前的計劃，它應該在第三季度準備就緒。原型設計已經開始驗證規範草案。

預計將於2020年底釋出第一個規範。與此同時，還將成立一個工作組來生成相應的測試規範，然後將其轉換為OPC UA認證工具（CTT）中的相應測試用例。第二步。關於控制器到裝置用例的概念的工作已經開始，這將包含在第二個規範版本中 ， 更多資訊盡在振工鏈 。