Unified Namespace 如何解決企業數據混亂？架構原理與導入效益說明

嗯...今天要來聊一個...一個最近很紅，但很多人都搞錯方向的東西。就是 Unified Namespace，簡稱 UNS。

很多人一聽到這個，就馬上想到 MQTT，覺得這就是一個 IT 的技術問題。但說真的...如果只把它當成 MQTT，那就...那就把事情看得太淺了。這完全劃錯重點了。

我自己是覺得，這個概念的根，其實比你想的深得多。它不是什麼全新的發明，反而...嗯...更像是一種把舊智慧重新組合起來的方法。一部分來自 IT 世界的 Namespace，這個搞程式的應該不陌生；另一部分，其實是我們機械、資產管理領域喊了幾十年的東西，像是什麼 Asset Hierarchy 啊、資產分類之類的。

重點一句話：UNS 就是讓整個公司用「同一個名字」叫「同一個東西」啦。

聽起來很廢話對不對？但這件事超級、超級重要。你想想看，你口袋裡的身分證、健保卡、駕照...上面的名字、生日、身分證字號，是不是都一模一樣？

那如果，你去醫院掛號，健保卡是一個名字；你去監理站，駕照是另一個名字；你去報稅，戶政資料又是第三個名字...這會發生什麼事？根本天下大亂，你根本無法證明「你就是你」。

好，現在把這個場景搬到工廠裡。一台泵浦，在你的 ERP 系統裡，可能叫「A廠區冷卻水泵浦」；然後在維修系統（EAM/CMMS）裡，它的名字變成「P-101」；結果到了產線的 MES 系統，它又被叫做「冷卻站一號機」。

你看，這不就跟剛剛那個身分錯亂的例子一模一樣嗎？三個系統在講同一個鬼東西，卻用了三個完全不同的名字。電腦很笨的，你沒告訴它，它怎麼會知道這三個是指同一個東西？

這就是現在一堆企業面臨的「資訊孤島」，根本上的混亂來源。然後我們還想在這堆混亂上面蓋 AI、蓋大數據分析...這不是開玩笑嗎？地基都沒打好，蓋什麼高樓大廈。

這東西到底是怎麼來的？拆開來看就懂了

所以說，UNS 不是一個新發明，它更像是一個...嗯...一個「指導原則」或是一個「框架」。它告訴我們，應該怎麼把現實世界的東西，好好地「翻譯」成數位世界能懂的語言。我們可以把它拆成幾個部分來看。

第一部分：IT 領域的「Namespace（命名空間）」

這個概念其實是從寫程式那邊借來的。在軟體開發裡，為了避免不同人寫的 function 或 class 名字打架，就會用 Namespace 把它們隔開來。比如說，A 團隊可以有一個 `calculate()`，B 團隊也可以有一個 `calculate()`，只要它們在不同的 Namespace 底下，就不會衝突。

在資料庫裡面，這個概念也存在很久了。像是 Oracle 文件裡就有提到，他們用 schema 來定義物件的「所有權」，而 namespace 則是對這些物件進行「分類」的方式。簡單講，就是把一堆桌子、椅子、櫃子...先分門別類，貼上標籤，這樣才好管理。

所以，Namespace 的核心精神就是：有組織、有分類、避免混亂。這在 IT 領域是幾十年來的基本功。

第二部分：資產管理界的「Asset Hierarchy（資產層級）」

再來，我們把鏡頭拉到工廠或是一些重資產的產業。其實，像 ISO 55000 這種資產管理標準，早就強調「資產層級」（Asset Hierarchy）的重要性了。這到底是什麼？

白話文就是，把公司的所有資產，從大到小，像樹狀圖一樣排好。例如：國家 → 城市 → 廠區 → 產線 → 設備 → 子系統 → 零件。這樣一層一層地，建立起它們之間的關係。

為什麼要做這件事？因為這樣你才能做有效的生命週期管理、風險評估、還有成本分析啊。沒有這個層級結構，所有東西都是一盤散沙。

然後呢，還有更細的標準，像是 ISO 14224 或 IEC 81346，它們就在教你怎麼做「資產分類」跟「參考命名系統」。

• ISO 14224：這比較偏石油、天然氣產業，它教你怎麼收集設備的可靠度跟維修數據，重點是統一數據的格式跟品質。
• IEC 81346：這個就更通用了，它提供一套規則，教你怎麼幫工業系統裡的所有東西（從功能、位置、產品類型等不同角度）取一個不會搞混的名字。它強調一個「統一的參考命名系統」。

說到這個，我就想到... 這跟台灣很多中小企業的現況反差很大。國際標準講得很理想，要統一命名。但現實是，像在台灣很多工廠，可能 ERP 是鼎新或 SAP，MES 是自己廠內 IT 寫的，然後機台又是德國、日本、美國來的...光是設備本身的命名規則就全都不一樣，這就很頭痛。

所以你看，IT 的人和工廠的人，其實幾十年來都在用各自的方式，試圖解決「把東西整理好」這個問題。只是一個在數位世界，一個在物理世界。

ISA-95 自動化金字塔，清楚地呈現了從實體設備到企業系統的層級關係。" width="800" height="480" loading="lazy" decoding="async" style="max-width:95%;height:auto;cursor:pointer" class="no_autoresize">

第三部分：把這兩件事串起來的 ISA-95

那...誰來當中間的橋樑呢？我覺得 ISA-95（就是那個自動化金字塔模型）就扮演了這個角色。

很多人只把 ISA-95 當成一個分層模型，Level 0 是實體設備，Level 1 是感測器/PLC，Level 2 是 SCADA/HMI，Level 3 是 MES，Level 4/5 是 ERP...這樣。沒錯，但它不只是一個分層圖。

它其實是一個超棒的「資料模型」。它不只定義了層級，還定義了每一層之間應該交換什麼資訊、設備跟設備之間的關係是什麼。它等於是幫我們畫好了一張地圖，告訴你，一個工廠的數據，應該要怎麼從最底層的感測器，一路往上傳到 ERP，而且在傳遞的過程中，保有它的「脈絡」（Context）。

所以，你有沒有發現？

這些標準，不管是 IT 的、還是 OT 的，其實都在引導我們做同一件事：建立一個基於實體資產的 Namespace。把現實世界的東西，用一種有結構、有邏輯的方式，轉成數位格式，讓各種系統都能看懂、都能用。

這真的沒有捷徑，你必須要用一個有結構、有邏輯的順序來做這件事。

所以，導入前後到底差在哪？

講了這麼多理論，我們來點實際的。一個公司，有沒有搞 UNS，差別到底在哪裡？我自己是覺得，看下面這個表就很有感覺了。

你看這個表，是不是就很有感了。這根本不是技術問題，這完全是管理問題，是溝通問題。電腦本身是很笨的，是我們把它搞得更笨。

所以別再只盯著 MQTT 了

這就要回到一開始講的。很多人，包含一些很有名的顧問，像是 Walker Reynolds，他一直在推廣這個概念。為什麼？因為他看到了問題的核心。

UNS 的靈魂在於那個「U」，Unified，統一。而實現這個統一的「工具」，常常會用到 MQTT，因為 MQTT 的 Broker/Topic 架構天生就適合拿來實現這種層級式的命名空間。但 MQTT 只是個工具，就像你蓋房子需要錘子，但錘子本身不是房子。

你就算用了最牛的 MQTT Broker，如果一開始沒有把上面說的 Asset Hierarchy、命名規則想清楚，你蓋出來的也只是一個...嗯...比較快的垃圾場而已。資料流動很快，但裡面還是一堆垃圾。

所以真正的挑戰是：

1. 坐下來開會：把 IT、OT、維修、財務...所有部門的人全部抓來，攤開所有系統，好好地把每個重要資產的「統一名字」給定下來。這步最難，最花時間，也最政治。
2. 建立模型：根據 ISA-95 和你們公司的實際狀況，把這個命名規則模型化。例如 `企業/廠區/區域/產線/設備/測點`。
3. 動手執行：然後才是在你的 SCADA、MES、ERP...想辦法把資料發布到這個統一的命名空間下。這時候，MQTT 才上場。

你真的準備好談 AI 了嗎？

老實說，每次聽到有人說要在工廠導入 AI，做預測性維護、做數位分身...我心裡第一個問題都是：「你們家的 UNS 搞定了嗎？」

如果連一個泵浦在公司內部都有好幾種名字，那 AI 要怎麼學習？它看到的數據根本是分裂的。一個來自 ERP 的成本數據，一個來自 EAM 的維修紀錄，一個來自 MES 的運轉時數...AI 要怎麼知道這些數據其實都跟「同一台泵浦」有關？

解決這些更根本的、聽起來很無聊的「存在性」問題，比追逐最新的 AI 模型重要多了。先把地基打穩，不然上面蓋什麼，遲早都會垮掉。

所以，下次再有人跟你談工業 4.0 或數位轉型...或許可以先問問他：

「那，我們公司的『統一命名空間』是什麼？」

看看他怎麼回答。