模型記錄和中繼資料
本指南說明如何在 Manufacturing Data Engine (MDE) 中建立記錄和中繼資料模型。
記錄會擷取製造程序的事實，例如感應器讀數和事件，而中繼資料則有助於瞭解這些事實的脈絡，並依中繼資料屬性「切分」這些事實。中繼資料也是製造實體原始資料的來源。
如果您使用完整的 MDE 套件 (MDE 搭配 Manufacturing Connect (MC))，可以略過資料模型化部分，因為 MDE 提供可快速上手的套件。不過，如果您要整合其他資料來源，建議您還是閱讀這篇文章。
一般建議
開始建立中繼資料模型之前，請先瞭解下列事項：
- 下游使用者的資料用量需求。包括瞭解他們需要哪些資料，以及打算如何使用這些資料。您可以與下游使用者會面，詢問他們的目標、主要成效指標 (KPI)、用途、分析需求和資料品質標準，藉此瞭解相關資訊。
- 基礎來源資料的實際情況。包括瞭解資料品質、資料結構和資料沿革。您可以與來源系統專家會面，並進行高階資料剖析，藉此達成此目的。
- 技術資料整合規定。這包括瞭解 MDE 需要支援哪些資料整合介面，以及必須遵守哪些技術規定，包括命名慣例。
以下是一些具體做法，可協助您瞭解下游使用者的消耗需求：
- 與下游使用者會面，瞭解他們的目標：
- 他們想透過資料達成什麼目標？
- 他們的 KPI 是什麼？
- 詢問下游使用者他們的用途：
- 他們打算如何使用這些資料？
- 他們想執行哪些報表？
- 他們想執行哪種分析？
- 瞭解下游使用者的數據分析需求：
- 他們需要分析哪種資料？
- 他們需要多久分析一次資料？
- 向下游使用者詢問資料品質標準：
- 他們可接受的資料品質等級為何？
- 需要採取哪些步驟，確保資料符合標準？
以下是您可以採取的一些具體做法，瞭解基礎來源資料的實際情況：
- 與來源系統專家會面：
- 來源系統中的資料品質如何？
- 資料結構為何？
- 什麼是資料歷程？
- 進行高階資料剖析：
- 這有助於找出資料的任何潛在問題，例如遺漏值、重複記錄或無效資料型別。
中繼資料模型
建立中繼資料模型時，您會面臨三個主要問題：
- 哪些中繼資料應視為內嵌中繼資料，哪些應視為雲端中繼資料？
- 如果是雲端中繼資料，要建立哪些 bucket？
- 雲端中繼資料 bucket 的結構定義應為何？
決定要使用嵌入式或雲端中繼資料
決定是否要將某些情境資訊模擬為內嵌中繼資料或雲端中繼資料時，適用的主要決策條件是變更速度。
內嵌中繼資料最適合快速變更的中繼資料。包括交易 ID 或自動遞增計數器等中繼資料。
相較之下，雲端中繼資料最適合用於變更速度較慢的中繼資料，例如資產中繼資料。MDE 會追蹤每個 bucket 的中繼資料執行個體記錄，並將中繼資料寫入支援中繼資料的接收器，例如 BigQuery。這可讓您依自然鍵探索中繼資料執行個體的記錄，同時讓 Looker 等商業智慧 (BI) 工具取得不重複的屬性值清單，而不必遍歷整個記錄資料表。
建立雲端中繼資料 bucket 模型
儲存區會模擬某些情境領域。舉例來說，ISA-95 實作資產階層模型會模擬製造企業的實體資產階層。您應沿著情境網域的邊界，建立中繼資料 bucket 模型。舉例來說，您可以在 asset 值區中建立資產環境模型 (以 ISA-95 實作項目表示)，並在 machine-status 值區中建立機器狀態模型。
此外，您也應考慮是否需要為標記或任意記錄群組提供脈絡資訊。
標記相關中繼資料應選擇標記 bucket，其他類型中繼資料則應選擇記錄 bucket。
一般而言，建議您在同一個 bucket 中建立階層式網域中繼資料模型。舉例來說，雖然可以將標記所屬機器的屬性 (例如機器中安裝的感應器製造商) 建立在兩個不同的值區 (標記值區和機器值區)，但一般來說，最好在單一值區中建立這類階層式關係。
將階層分割成多個獨立維度的主要原因，是為了以不同精細程度將記錄與中繼資料建立關聯。舉例來說，如果您要整合兩個不同的資料來源，其中一個以感應器層級的精細度傳送資料，另一個則以機器層級的精細度傳送資料，就應該將機器專屬資料分別存入各自的 bucket。
設定雲端中繼資料 bucket 結構定義
值區的結構定義會決定值區中允許的中繼資料例項結構。結構定義可提升資料品質，也能讓您定義可用於或必須用於描述特定值區所模擬實體的欄位。您應允許或要求在 bucket 中填入哪些欄位，主要取決於來源提供的資料，以及您選擇的 bucket 母體和記錄連結策略。
如果選擇從邊緣動態填入中繼資料 bucket，定義結構定義時的主要考量因素，應該是來源訊息中中繼資料的可用性。您也應考量資料一致性和擷取容易度。中繼資料 bucket 結構定義越具體，標示為必填的欄位越多，產生的中繼資料例項就越一致。不過，這也會提高剖析器的需求，以解決訊息間的任何結構差異。
另一方面，如果 bucket 結構定義越通用 (例如指定中繼資料屬性可以是任何「物件」，而非定義特定物件屬性)，剖析器中的中繼資料轉換和協調需求就越低。但這可能會導致中繼資料不一致或不符合規定。
設計 bucket 結構定義時，另一個重要考量是 bucket 的精細程度。如果您透過 API 建立中繼資料例項，請確認自然鍵的精細程度或粗略程度，與您預期從邊緣接收的資料一致。舉例來說，如果您從機器層級的邊緣接收狀態事件，但資產值區包含感應器細微程度的執行個體，您就無法將記錄連結至這個值區中的中繼資料執行個體。而是需要包含機器層級精細程度執行個體的水桶。
記錄建模
建立中繼資料模型時，您會面臨兩個重要問題：
- 要建立哪些類型？
- 應如何設定類型？
建模類型
類型會說明語意和結構相似的記錄，這些記錄會儲存在一起，並以一組通用的中繼資料說明，且您想對資料欄位建立通用限制。
因此，類型應以相同的精細程度 (詳細程度) 擷取記錄。通常這表示要圍繞某個製造程序、作業或一組動作來建構型別。舉例來說，您可以為「機器狀態」記錄建立類型，並為「感應器讀數」建立另一種類型
此外，我們也建議您在最細微的層級保存資料，並避免在將資料傳送至 MDE 前預先彙整資料。這樣一來，您就能從原子資料建立任何匯總，享有最大的查詢彈性。
類型設定
設定類型時，請考量下列要點：
- 哪些中繼資料儲存區應說明某類型的記錄？必填或選填？
- 資料欄位的結構定義應為何？
類型中繼資料設定
您可以將中繼資料 bucket 版本與類型建立關聯。將 bucket 版本與型別建立關聯，表示該型別的記錄在執行階段可能會或必須 (視關聯的 required 欄位值而定) 連結至指定 bucket 版本的元資料執行個體。
決定要將哪些值區與類型建立關聯，以及關聯是否應分類為 required，取決於多項考量因素。您應考量資料用戶的脈絡化需求、從邊緣接收的脈絡、資料品質，以及存取原始資料的權限 (如果邊緣資料來源未提供所需脈絡)。
在關聯的中繼資料 bucket 上設定 required 旗標，可提高資料一致性，但您也必須考慮如何處理邊緣無法傳送中繼資料，或尚未建立自然鍵的中繼資料執行個體的情況。在這種情況下，您可以讓 MDE 拒絕郵件，並將其移至死信佇列，也可以在 bucket 中建立一般 Not Available 中繼資料執行個體，以便將記錄連結至該執行個體 (如果無法建立完整脈絡化執行個體的連結)。
設定資料欄位類型
在 DISCRETE_DATA_SERIES 和 CONTINUOUS_DATA_SERIES 上設定資料欄位，即可在資料欄位中取得一致的物件結構。定義資料欄位時，請剖析來源資料，並確保剖析器能夠產生通過定義結構定義驗證的 Proto 記錄。