<pre id="9vxtx"><strike id="9vxtx"><b id="9vxtx"></b></strike></pre>
            <output id="9vxtx"><ruby id="9vxtx"><mark id="9vxtx"></mark></ruby></output>

            <pre id="9vxtx"><ruby id="9vxtx"><b id="9vxtx"></b></ruby></pre><track id="9vxtx"><strike id="9vxtx"><ol id="9vxtx"></ol></strike></track>

            <track id="9vxtx"></track>
            <track id="9vxtx"><ruby id="9vxtx"><ol id="9vxtx"></ol></ruby></track>
            請輸入關鍵字
            07.25 2022年
            第十七屆興業杯獲獎文章
            基于OPC UA的數據合規性研究


            上海東富龍海崴生物科技有限公司

            杜金鋒

             

            摘要:藥物和醫療設備直接影響到公民的個人健康,使得制藥業成為監管最嚴格的領域。法規沒有直接指導如何具體實施數據合規性,但監管機構對任何制造記錄的數據完整性和可靠性提出嚴格的要求。本文研究在制藥行業中使用OPC UA(Unified Architecture)協議滿足數據合規性要求,主要從AKCOA CCEA原則對OPC UA協議進行分析,即可溯源、清晰、同步、原始、準確、完整、一致、可用和安全方面確認該協議在監管要求的數據合規性方面具有顯著優勢,可為制藥過程提供開箱即用的實施方案。

            關鍵詞:OPC UA、數據合規性、AKCOA CCEA

             

             

            引言

            在許多制造領域,為確保達到一定級別的安全和質量標準,政府和其他監督機構都實行監管。制藥業一直是監管最嚴格的領域,這是由于藥物和醫療設備直接影響到公民的個人健康。藥物和醫療器械在現代國家相對安全的主要原因是大部分安全工作是先發制人。不同的監管機構總是會定期對制造設備進行現場檢查,制造者要證明所有監管要求都得到滿足,無法提供足夠的合規性證明可能導致監管干預。通常這種干預以通知的形式來解決制造過程中的問題,在這種情況下,后續檢查可能會更頻繁地進行。

            監管要求的一部分內容涉及數據方面,法規沒有直接指導如何實施數據合規性,但有關數據完整性和可靠性要求制造者保留制造過程中的數據記錄。雖然這些要求聽起來并不難實現,但確保合規程度達到滿足監管機構要求還是一項艱巨的任務。隨著設備復雜性地增加,管理數據并將其保持為可用的格式變得越來越困難。

            監管條例沒有規定具體的實踐要求,但有一些既定做法可以用作滿足監管要求的指導。國際制藥工程協會(ISPE)出版最成熟的指導文獻集,該文檔稱為良好自動化生產實踐指南,專門針對制藥行業的制造。

            使用既定做法對構建合規系統大有裨益,但最終實施的責任始終落在制造過程所有者身上。各種工具可以提供開箱即用的解決方案來幫助滿足監管的數據要求。本文討論在制藥行業中使用OPC UA(Unified Architecture)協議滿足數據合規性要求,主要從數據完整性原則(ALCOA CCEA原則)討論OPC UA協議所提供的優勢,確認該協議完全滿足監管所需的數據合規性要求,為制藥過程提供開箱即用的完整解決方案。

            第二節詳細介紹OPC UA協議的內容,主要包括地址空間、安全、發布訂閱、報警事件和歷史訪問等方面,為第三節數據合規性研究提供理論基礎。

            第三節從ALCOA CCEA原則的各個方面探討OPC UA所提供的解決方案,最終論證其完全滿足監管所需的數據合規性要求,為制藥過程帶來實實在在的利益。

            OPC UA協議

            2.1 歷史背景

            1996年一套面向工業自動化過程控制對象、接口和方法標準的OPC(Object Linking and Embedding for Process Control)協議發布,稱為OPC經典。此協議基于微軟的OLE、COMDCOM技術,包含三個不同部分:用于實時值讀寫的數據訪問(DA)、用于檢索歷史數據的數據訪問(HDA)和用于消息推送的事件和報警(AE)[1]。在此之后,OPC基金會組織成立進一步維持和發展該標準。

            然而在實際應用過程中,發現OPC經典存在一些局限性。例如:DCOM配置和連接問題、嚴重依賴Windows平臺問題和安全性問題。這些問題促使基金會在2006年推出完全取代COM/DCOM技術的新平臺解決方案OPC UA(Unified Architecture),其具有更好的擴展性、安全性和多平臺兼容等優勢。目前OPC UA規范版本是1.04,包含8個核心規范、4個訪問類型規范和2個應用規范。

            2.2 地址空間與安全

            OPC UA中最重要的概念就是地址空間[3],用于描述數據在OPC UA服務器的結構。標準的OPC UA服務器有三個根文件夾:類型、對象和視圖。類型用于定義不同的數據結構,如:對象、變量和引用,用這些數據結構可以定義不同的實例。對象常用于表示系統和部件,也可以表示外部系統連接到設備的數據,還可以表示在服務器上運行的功能、報警和事件。視圖是為了更好的組織數據,使用不同的自定義視圖手段,可以從特定角度為不同客戶端提供服務。

            描繪地址空間的最簡單方法是分層形式,所有節點都組織在根文件夾中。對于僅僅監視數據的系統,下圖1的分層視圖是完全滿足需求。

            from clipboard

            圖1 分層視圖

            OPC UA支持引用來展示更復雜的系統。用類型定義對象結構,無需描述每個實例的語義。許多節點是父類節點或子類節點,可以通過引用連接到非分層系統中。下圖2展示非分層引用的數據結構。

            from clipboard

            圖2 非分層引用視圖

            為了確保通信的兩端都可以相信接收數據來源的真實性,并且傳輸的數據對于竊聽者來說是保密的,OPC UA采用多種安全策略來確保數據訪問,如:數據加密、身份驗證、授權和簽名等[2]。此外,OPC UA通過在處理消息前運行一些安全策略來防止應用程序濫用,最大限度地減少未經授權的請求使用系統資源。

            OPC UA支持兩種類型的身份驗證:用程序和用戶。應用程序身份驗證使用X509證書來指定哪些應用程序可以相互訪問。一個常見的例子:客戶端連接到服務器之前,客戶端證書需要在服務器端允許的證書列表中。OPC UA還支持用戶身份驗證,允許識別個人用戶。用戶身份驗證允許使用第二個重要的安全功能:授權。允許按項目控制服務器的訪問。在重視安全的系統中,不建議所有用戶都能對數據進行完全訪問,可以授予特定用戶細粒度的訪問權限以限制讀取、寫入和執行權限。

            2.3 發布訂閱、報警和事件

            服務器上屬性發生變化時客戶端可自動接收信息。以這種方式監控服務器是通過訂閱完成[9],訂閱將監控項分組以減少發布的請求量。訂閱的整體功能如圖3所示。

            from clipboard

            圖3 訂閱和監控項的整體功能

            訂閱可用于監控任何數據項更改,監控項目的過濾器可用于定義項目哪些變化是有效的。對于最常見的過濾器類型DataChangeFilter,客戶端可以選擇是否對值、時間戳、狀態代碼或某些組合的更改感興趣。通過過濾器后,生成的通知隊列,如果采樣率快于訂閱發布率,則允許將多個更改合并為一次。它還允許在短連接中斷的情況下對有限數量的信息進行排隊。由于定期觸發發布,因此不會立即將更改報告給客戶端。但是,通過在服務器上對發布請求進行排隊并保持較低的發布速率,服務器可以快速發送有關數據變化的信息,而不會因為報告沒有發生任何變化而給通信鏈路造成不必要的負擔。這意味著在實踐中,使用服務器端訂閱可以提供更接近實時的更改通知,而不是通過網絡從客戶端發出持續請求,避免由多個系統共享的網絡而造成不必要的負載。

            警報和事件都可以表示來自服務器任何組件的通知。地址空間中的任何對象都可以被授予EventNotifier屬性,通知客戶端通過訂閱該節點,可以從服務器接收事件。當事件發生時,它被發送到訂閱公開事件的EventNotifier的客戶端。事件包括關于事件來源的信息、可讀的描述以及從01000的嚴重性級別。警報在服務器地址空間上指定為警報對象。這些警報對象使用條件來跟蹤系統或組件的狀態。當達到特定狀態時,服務器向訂閱警報對象的客戶端發送事件,并傳遞有關導致警報條件的信息。

            2.4 歷史訪問

            雖然OPC UA的某些功能允許一定量的數據緩沖,如訂閱;但默認情況下該功能僅有助于訪問當前數據值。對于數據記錄由外部系統記錄的項目已經足夠,但為了促進更可靠數據記錄,OPC UA規范定義了存儲在OPC UA服務器上的數據和事件的歷史訪問(HA)功能。歷史訪問[11]功能允許OPC UA服務器存儲對象、變量、屬性甚至事件的歷史記錄。這些值從OPC UA協議外部存儲,通常存儲在數據庫中以獲取更大的數據集,但托管系統支持存儲任何格式數據,OPC UA規范僅要求存儲與服務器相關的特定數據。OPC UA規范定義了歷史訪問的信息模型,向具有歷史訪問權限的節點添加了附加信息,可用于記錄值的歷史元數據,例如采樣時間。OPC UA客戶端可以使用此信息從某些數據范圍中檢索信息,從而允許在出現連接問題或在滿足某些條件后記錄更有意義的歷史數據。

            數據合規性

            3.1 ALCOA CCEA原則

            數據完整性旨在確保數據得到正確維護,確保這些數據一致準確。數據完整性對于控制和監督制造過程的系統至關重要。

            ALCOA CCEA原則是一組原則的常用縮寫[14],就是對記錄生成、錄入、修改、存儲、檢索、備份、恢復和輸出等數據生命周期內的所有活動的要求。該原則不僅是GMP對數據完整性的要求,也是所有符合性審核對數據完整性的基本要求。原則的內容為:

            1. 可溯源(Attributable)在什么時間,誰創建的數據或誰執行的活動。

            2. 清晰(Legible)是否可以辨識數據和所有活動記錄。

            3. 同步(Contemporaneous)記錄和活動同步。

            4. 原始(Original)書面的打印資料、觀察報告或經核證的副本。

            5. 準確(Accurate)沒有錯誤或修改。

            6. 完整(Complete)包括樣品重新分析相關數據在內的所有數據。

            7. 一致(Consistent)記錄內的所有內容,例如事件的順序,是完全一致按照發生的日期事件先后順序被記錄下來。

            8. 持久(Enduring)不應使用廢紙或便簽做記錄,確保在規定的留檔期限內,數據被完好保存。

            9. 可用(Available)在使用期內,記錄可用于回顧、審計或檢查。

            3.2 可溯源、清晰和同步

            可溯源主要目標是確保對數據所做的任何更改都可歸因于個人或系統。這意味著服務器需要能夠識別用戶并記錄其中發生的操作。OPC UA中的授權服務可用于對數據、事件、方法以及OPC UA服務器中可訪問的任何其他內容的精細訪問。根據OPC UA規范第4部分,授權的責任可能由OPC UA服務器本身或外部授權服務承擔。在這兩種情況下,OPC UA服務器負責執行此授權,因此需要對信息模型進行正確的用戶訪問定義,以限制對駐留在OPC UA服務器上的數據訪問。

            OPC UA規范第6部分還描述應如何實施審計跟蹤。在創建審計跟蹤時,OPC UA提供兩個選項可供選擇。第一個選項是OPC UA應用程序直接將事件記錄到日志文件、數據庫或其他存儲方法中。第二個選項要求OPC UA服務器可以發布審計事件。這是通用事件系統的一個子集,它的工作需要服務器支持發布訂閱事件。在此選項中,OPC UA客戶端可以訂閱這些事件,然后將審計事件記錄到永久記錄系統。

            清晰主要確保數據可被人讀取,并且可用于現在和將來的決策。根據GAMP良好實踐指南,在制造系統中,可以通過數據管理工具進行篩選和排序,以便于比較的方式訪問存檔數據來實現這一點。這一原則的定義在某種程度上是開放式的,因為數據呈現需求取決于數據本身。提供數據分析工具是在OPC UA連接架構之外完成的。這些工具可能包含在OPC UA客戶端軟件中,但它們也可以用于OPC UA系統提供的外部應用程序。在OPC UA客戶端應用程序中實現這些分析工具的優點是:它允許數據瀏覽直接連接到OPC UA服務器,提供實時訪問數據并允許使用OPC UA功能,如歷史訪問。

            實現復雜OPC UA服務器的可讀性的工具是視圖。它們是地址空間的子集,允許服務器托管的數據以不同形式表示。此功能支持相同數據在不同視圖中展示,允許使用與讀取數據的不同需求相匹配的篩選和排序。這些視圖也是用戶訪問控制的一部分,并且可能僅限于某些安全角色,允許對數據進行不同級別的訪問。

            同步是為了正確跟蹤制造系統中的操作,訪問這些操作的日期和時間數據對于建立系統中發生的事件的時間表至關重要。這意味著系統應該在數據捕獲時產生時間戳,并且系統與其他連接的系統時間同步。默認情況下,這些功能通常嵌入在許多電子系統中。定義標準數據類型的OPC UA規范第3部分指出服務器和客戶端之間的所有時間值都是UTC值。在OPC UA中,所有安全協議都需要時間同步。但是,此要求是從安全角度出發的,允許正確的證書管理,而不是數據捕獲的同步。安全策略和實際用例所需的精度可能會有很大差異。OPC UA規范并沒有嚴格規定需要使用什么同步方法,但主要推薦使用網絡時間協議(NTP),在NTP不可行的情況下,OPC UA應用程序可以在ResponseHeaders中使用時間戳OPC UA請求。

            3.3 原始、準確和可用

            原始的目標是保證記錄不被更改以保留數據的真實含義。在電子系統中,這意味著自動收集數據并在其完整上下文中保留原始元數據,例如時間戳。OPC UA服務器存儲接收到的數據以及元數據。但是,這些數據可能會在服務器中發生變化,即使是用戶手動操作也是如此。因此,需要正確使用歷史數據和數據存檔,以保留所有數據的原始記錄。

            準確是指通過對可能導致無效數據的環境影響采取各種對策,可以提高數據準確性。電子系統可以通過對數據輸入進行檢查來驗證是否插入了合理的值來緩解這種情況。OPC UA規范不限制數據格式,但它確實提供了OPC UA應用程序應支持的基本數據類型。OPC UA規范還提供了服務狀態代碼列表,可用于提供有關服務請求的信息。應用程序檢測這些錯誤的方式各不相同,但支持規范提供的列表可確保捕獲最常見的數據輸入錯誤。列出的錯誤代碼僅在技術上驗證數據,例如檢測不兼容的數據類型,但不考慮數據是否合理,給定上下文。同樣適用于針對手動輸入進行的檢查。OPC UA變量元數據包括StatusCode屬性。此屬性可用于指示數據質量是、不確定還是。規范要求客戶端在訪問數據之前檢查此狀態代碼,無論客戶端如何處理該信息。

            完整為了使數據可靠,它需要保留上下文。在電子記錄中,這通常通過元數據實現。元數據可以提供有關數據本身的各種數據,例如創建時間、狀態和類型。該原則沒有定義元數據應該包含什么,而是所有元數據都與數據一起傳輸,以確保在系統之間遷移時所述數據的含義不會改變。由于OPC UA層次結構是基于節點的,因此元數據附加到這些對象的屬性上。這允許所有元數據與其關聯的屬性一起提供,從而確保元數據始終與數據配對。

            3.4 一致和可用

            一致是指完全按照發生的日期事件先后順序被記錄下來。歷史數據的一致性是通過數據附帶的時間戳來實現。數據還應按順序排序,以提高可讀性,使數據分析和發現記錄中的空白更容易。OPC UA將元數據與屬性聯系起來。此元數據包括用于在OPC UA服務器中進行更改的ServerTimeStamps和連接的源系統可用于報告數據更改發生時間的SourceTimeStamps。ServerTimeStamp也可用于方法和事件,允許客戶端查看這些服務上次激活的時間。此元數據可用于構建OPC UA服務器中發生的值更改和操作的時間線。

            可用(Available)數據只有在可訪問時才可用,即使在長期存儲中也是如此。這很重要,以便在需要時進行適當的審計。數據可用性原則還要求數據能夠可靠、自動地備份和恢復。外部數據存儲可用于OPC UA連接到歷史數據功能,以瀏覽地址空間中定義的節點的歷史數據。歷史數據還支持自動創建記錄以進行歸檔。這是由于歷史數據保留數據的固有特性,至少在特定時間段內,這允許歸檔系統使用此功能來緩沖待歸檔的數據。這方面對于確保檔案在記錄到更永久的存儲之前不會因為值發生變化而丟失記錄至關重要。如果系統利用歷史數據進行存檔,則可以將存儲在OPC UA服務器上的所有元數據公開以供完整的存檔數據使用。如完整部分所述,保留所有元數據對于保留數據的含義和上下文很重要,這對于完全理解數據和數據含義很重要。

            3.5 數據安全

            出于多種原因,數據安全很重要。兩個OPC UA應用程序之間的數據流動可以通過不同的措施來保護,包括硬件、軟件甚至基礎設施設計。其中,OPC UA協議只影響軟件安全,其他部分不做評估。即使在安全的物理制造現場,員工對設施和信息的訪問也不同。這是為了防止對資源進行不必要的訪問,最大限度地降低不合格人員與數據和系統交互的風險。這種分離可以保護制造過程免受惡意和意外干擾。數據訪問的控制方式應確保每個人都無法訪問機密數據,并且自動化流程只能由經過培訓的人員控制。訪問控制也應用于可追溯性,允許系統記錄流程可能發生的變化。數據訪問控制基于授予適當的訪問權限,但在傳輸過程中也應保護數據流。當系統聯網時,信息流經許多設備,例如路由器。在更復雜的網絡中,尤其是公共網絡中,數據在傳輸過程中很容易被攔截。任何時候敏感數據從系統傳輸到另一個系統,都需要確保數據在傳輸過程中不會被訪問、更改或損壞。此外,目標系統應該能夠自信地確定接收數據的來源。

            OPC UA標準指定可以為單個節點細化數據訪問。這允許限制對數據的訪問,僅允許某些人員和系統訪問特定的數據或方法。讀取權限可用于保護機密數據。這允許更廣泛的人員和其他系統更容易訪問系統,同時仍然存儲不同機密性的信息。制造過程受到寫入和執行訪問限制的保護,僅允許授權人員和系統對實際過程進行更改。此外,審計跟蹤可用于跟蹤對系統所做更改的來源。在這兩種情況下,基于規范實施訪問控制只能對數據進行適當的保護,而不能保證它。訪問方案需要由系統設計人員設計,并基于影響相關數據連接的實際需求和規定。

            結論

            制藥業一直是監管最嚴格的領域,這是由于藥物和醫療設備直接影響到公民的個人健康。監管要求的一部分內容涉及到數據方面,數據完整性、安全性和可靠性要求制造者必須保留制造過程中的數據。在簡單系統中數據合規性并不難實現,但隨著系統復雜度的增加,管理數據并保存為可用格式需要大量的資源和專業知識。

            監管條例并沒有規定具體的實踐步驟,而國際制藥工程協會(ISPE)出版指導性文集良好自動化生產實踐指南。好在有一些工具可以提供開箱即用的解決方案幫助滿足監管的數據要求。本文開創性討論在制藥行業中使用OPC UA(Unified Architecture)協議滿足數據合規性要求,主要從AKCOA CCEA原則對OPC UA協議進行分析,即可溯源、清晰、同步、原始、準確、完整、一致、可用和安全方面進行分析。OPC UA中的授權服務可針對數據、事件、方法,可精細訪問任何內容;服務器或客戶端可直接將事件記錄到日志文件、數據庫或其他存儲方法中,這樣任何訪問和操作都是可溯源的。OPC UA的視圖、分層結構模型或非分層結構模型為用戶提供清晰的數據分析。時間同步功能完全滿足數據同步的要求。原子性(專業術語,代表數據準確、可靠)則可以通過服務器存儲接收到的數據以及元數據(專業術語,代表數據原始信息)保證。OPC UA應用程序應支持的基本數據類型,還提供服務狀態代碼列表,可用于提供有關服務請求的詳細信息為數據準確提供保證。完整則是因為服務器存儲有關數據本身的各種上下文元數據。一致性通過數據附帶的時間戳來實現,可用性則是依靠OPC UA的歷史訪問功能實現,數據安全則是依靠內置的多種加密協議。最終確認該協議完全滿足監管所需的數據合規性要求,為制藥過程的數據合規性提供開箱即用的完整解決方案,為制藥過程帶來實實在在的利益。

             

            參考文獻

            1. OPC Foundation. OPC Unified Architecture: Part 1: Overview and concepts [J]. 2017.

            2. OPC Foundation. OPC Unified Architecture: Part 2: Security Model [J]. 2017.

            3. OPC Foundation. OPC Unified Architecture: Part 3: Address Space Model[J]. 2017.

            4. OPC Foundation. OPC Unified Architecture: Part 4: Services[J]. 2017.

            5. OPC Foundation. OPC Unified Architecture: Part 5: Information Model[J]. 2017.

            6. OPC Foundation. OPC Unified Architecture: Part 6: Mappings[J]. 2017.

            7. OPC Foundation. OPC Unified Architecture: Part 7: Profiles[J]. 2017.

            8. OPC Foundation. OPC Unified Architecture: Part 8: Data Access[J]. 2017.

            9. OPC Foundation. OPC Unified Architecture: Part 9: Alarms & Conditions[J]. 2017.

            10. OPC Foundation. OPC Unified Architecture: Part 10: Programs[J]. 2017.

            11. OPC Foundation. OPC Unified Architecture: Part 11: Historical Access[J]. 2017.

            12. OPC Foundation. OPC Unified Architecture: Part 12: Discovery and Global Services[J]. 2017.

            13. OPC Foundation. OPC Unified Architecture: Part 13: Aggregates[J]. 2017.

            14. McDowall R D. What’s New with the FDA’s Data Integrity Guidance?[J]. Spectroscopy, 2016, 31: 9.

            15. 徐丸天, 蘇宏業. 基于OPC標準的實時數據庫接口技術與應用研究[J]. 計算機應用研究, 2006, 23(5):3.

            16. 陸會明, 閻志峰. OPC UA服務器地址空間關鍵技術研究與開發[J]. 電力自動化設備, 2010, 30(007):109-113.

            17. 趙宴輝, 聶亞杰, 王永麗,. OPC UA技術綜述[J]. 艦船防化, 2010(2):5.

            18. WolfgangMahnke, Stefan-HelmutLeitner, MatthiasDamm. OPC統一架構[M]. 機械工業出版社, 2012.

            19. 徐志良, 宋志強, 吳曉蓓. 基于OPC技術的上位機監控軟件設計[C]. 首屆信息獲取與處理學術會議論文集. 2003.

             

            友情鏈接
            投訴建議
            姓       名
            電       話
            內       容
            好大好硬好深好爽想要宝贝

                  <pre id="9vxtx"><strike id="9vxtx"><b id="9vxtx"></b></strike></pre>
                      <output id="9vxtx"><ruby id="9vxtx"><mark id="9vxtx"></mark></ruby></output>

                      <pre id="9vxtx"><ruby id="9vxtx"><b id="9vxtx"></b></ruby></pre><track id="9vxtx"><strike id="9vxtx"><ol id="9vxtx"></ol></strike></track>

                      <track id="9vxtx"></track>
                      <track id="9vxtx"><ruby id="9vxtx"><ol id="9vxtx"></ol></ruby></track>