QIF 導入指南（上）｜手上有 CAD、CMM、量測軟體，就能導入 QIF 嗎？
一、企業導入 QIF 前，先搞懂自己缺的是軟體、介面，還是資料定義
現在多數製造企業的數位化環境，早已不是從零開始。
設計端有 CAD（Computer-Aided Design，電腦輔助設計），製造現場有 MES（Manufacturing Execution System，製造執行系統），品質管理有 QMS（Quality Management System，品質管理系統），量測端則可能配置 CMM（Coordinate Measuring Machine，三次元座標量測機）與各式量測軟體；產品資料與生命週期管理，也可能已經透過 PLM（Product Lifecycle Management，產品生命週期管理）系統進行整合。
既然這些系統都已經存在，企業在開始接觸 QIF（Quality Information Framework，品質資訊框架）時，通常會先遇到一個很實際的問題：
「我們已經有這些軟體和系統了，還需要增加什麼，才能真正使用 QIF？」
但真正需要釐清的，其實是企業現有的「資料流程與系統能力」。
具體來說，至少有三個問題需要先回答：
目前的設計、製造、檢驗與量測資料，是如何在不同系統之間流動的？
現有的 CAD、CMM、量測或品質軟體，是否能夠讀取或產生 QIF 資料？
不同系統之間，是否能使用一致的資料定義，把產品設計、檢驗計畫、量測結果與品質資訊串接起來？
這也帶出理解 QIF 最重要的一個觀念：
QIF 並不是一套企業必須另外安裝的獨立軟體。
QIF 是一套製造品質資訊標準。ISO 23952:2020 定義了 QIF 的資訊模型、資料結構與 XML（Extensible Markup Language，可延伸標記語言）Schema；DMSC（Digital Metrology Standards Consortium，數位計量標準組織）則提供 QIF 3.0 的標準文件、Schema、驗證工具、範例檔與相關實作資源。
因此，企業導入 QIF 時，真正需要思考是：
如何讓現有的系統具備產生、讀取，或轉換符合 QIF 標準資料的能力。
換句話說，QIF 比較接近一種讓不同製造與品質系統能夠交換資訊的共同資料語言。企業真正需要建立的，是這套資料語言與現有系統之間的連接能力。
二、企業到底是在「導入」什麼？
如果把企業裡不同的系統想成各自使用不同語言的部門，QIF 比較接近一套讓這些系統能夠交換資訊的「共同資料語言」。例如：
在設計系統裡，一個零件的孔可能被描述為：「直徑 20 mm」。
到了檢驗系統，它需要被理解成：「這個孔需要檢查直徑」。
量測軟體接收到檢驗要求後，則需要知道：「我要量測這一個孔的直徑。最後，量測系統得到：實際值 20.013 mm」。
品質系統真正需要的資訊，則更完整：「20.013 mm 是哪一個零件、哪一個 Feature（特徵）、哪一個檢驗要求所得到的結果」？
如果每一套系統都使用自己的資料格式，這些資訊在系統之間傳遞時，就可能需要重新輸入、轉換，甚至依靠人工確認。
QIF 的作用，就是提供一套共同的資料模型，讓產品設計、檢驗計畫、量測結果與品質資訊能夠在不同系統之間交換，同時保留資料彼此之間的關聯。
DMSC 將 QIF 定位為支援從產品設計、製造到品質檢驗的 Digital Thread（數位執行緒）標準。(延伸閱讀：數位執行緒（Digital Thread）完整指南｜製造業必讀，提升關鍵戰力)
QIF 3.0 的資料模型涵蓋 MBD（Model-Based Definition，基於模型的定義）、Plans（計畫）、Resources（資源）、Rules（規則）、Results（結果）與 Statistics（統計）等應用範圍。
「現在有哪些品質資料需要被重複建立？這些資料能不能從一個流程直接傳到下一個流程？」
這個問題，才會決定企業第一個導入QIF的流程應該放在哪裡。
接下來，我們會談開始使用 QIF，最低需要哪些條件？可以先從四件事情開始確認。
三、條件一：先找到真正需要串接的資料流
企業不需要因為「QIF 是國際標準」就一次把所有系統都接起來。
比較實際的方式，是先找到一條目前存在資料斷點的流程。
例如：
CAD / MBD → Inspection Planning
設計端已經定義產品的 Feature、Dimension、Tolerance 與 GD&T，但檢驗規劃人員仍需要重新建立檢驗項目。
Inspection Planning → CMM / Measurement Software
檢驗計畫已經存在，但量測程式仍需要重新建立。
CMM / Measurement Software → QMS
量測結果完成後，還需要人工匯入 QMS，或透過 Excel、CSV 等格式進行交換。
Measurement Results → SPC / Quality Analytics
量測結果已經存在，但後續統計分析還需要重新整理資料。
上述流程，都可以是 QIF 延伸的應用方向。
所以第一個 QIF 專案，企業得先認知到：
「哪一段資料流目前最需要被串起來？」
找到這個位置之後，再決定 QIF 應該放在哪一層。
四、條件二：至少要找到一個 QIF 資料出口和一個資料入口
這是評估企業 QIF 導入難度的一個簡單方法。
假設企業希望建立：
CAD → QIF → Inspection Software
那麼首先要分別確認兩端的能力。
CAD 端
需要確認是否可以：
Export QIF（輸出 QIF）
透過 Plug-in（外掛模組）產生 QIF
透過 API（Application Programming Interface，應用程式介面）取得資料，再轉換成 QIF
Inspection Software 端
則需要確認是否可以：
Import QIF（匯入 QIF）
透過 API 接收 QIF 資料
透過 Converter（轉換器）把 QIF 轉成軟體自己的資料格式
如果兩端都原生支援 QIF，架構就相對直接：
CAD
│
│ QIF Export
▼
QIF Data
│
│ QIF Import
▼
Inspection Software
│
▼
CMM但如果其中一端沒有 QIF 能力，也不代表 QIF 專案就無法進行。
可以在中間增加一層轉換：
CAD
│
▼
API
│
▼
QIF Converter
│
▼
QIF
│
▼
Inspection Software這時候，企業需要處理的重點，就會放在：
如何把現有系統裡的資料正確轉換成 QIF 所定義的資料結構。
DMSC 提供 QIF 3.0 Schema、Validation Tools（驗證工具）、Sample QIF Files（QIF 範例檔），以及 C++、C#、Python 等 Source Code Bindings（原始碼繫結），可以作為企業開發 QIF 讀取與產生功能時的基礎資源。
五、條件三：確認 CAD 裡有多少可被 QIF 使用的產品資訊
前面談到的條件，主要是在確認企業是否具備 QIF 的資料交換能力。
但還有一個容易被忽略的問題：
QIF 要交換的，到底只是量測結果，還是連產品定義與品質要求也要一起交換？
這會直接影響企業需要從 CAD 裡準備多少資訊。
很多企業會以為：
我們已經有 3D CAD，應該就可以做 QIF。
但「有 CAD」和「CAD 裡有足夠的工程語意」其實是兩回事。
如果企業只是希望將量測結果從量測軟體傳送到品質系統，那麼不一定需要先建立完整的 Model-Based Definition（MBD，模型為基礎的定義）流程。
但如果企業希望進一步使用 QIF MBD，讓產品定義、特徵、尺寸、公差與品質要求可以被下游系統理解與追溯，就需要確認 CAD 是否已經具備這些工程資訊。
Feature（特徵）
Dimension（尺寸）
Tolerance（公差）
GD&T（Geometric Dimensioning and Tolerancing，幾何尺寸與公差）
Datum（基準）
PMI（Product Manufacturing Information，產品製造資訊）
理想的狀態，不只是電腦「看到一個 3D 模型」，而是能理解：
這裡是一個孔。這個孔的直徑是 20 mm。公差是 ±0.02 mm。這個 Feature 使用哪一個 Datum。
這些具有工程語意的資訊，才有機會進一步被 QIF 與下游品質流程使用。
但這不代表企業要先完成 MBD，才能導入 QIF
這一點需要特別釐清。
QIF 是模組化的資料模型，企業可以依照實際的使用情）選擇需要交換的資料。
例如，如果目前最迫切的需求是：
量測結果 → QMS（Quality Management System，品質管理系統）
那麼企業可以先從 QIF Results（QIF 結果） 開始。
如果需要進一步交換量測計畫，也可以考慮：QIF Plans（QIF 計畫）
只有當企業希望把 CAD 中的產品定義、PMI、特徵與公差等資訊，也納入品質資訊的追溯流程時，才需要進一步處理 QIF MBD。
如果只是先建立量測結果的標準化交換，企業不需要等待完整的 MBD 流程成熟。
可以先從一個明確、範圍較小的 QIF 應用場景開始，再逐步往產品定義、特徵與公差的語意追溯擴展。
五、條件四：CMM 不一定需要「安裝 QIF」
另一個常見問題是：
如果公司要使用 QIF，是不是要在 CMM 上安裝 QIF？
通常不應該這樣理解。
CMM 是實際執行量測的硬體設備。
企業真正需要確認 QIF 能力的，通常是：
CMM 所使用的 Measurement Software（量測軟體）。
因此，應該確認量測軟體是否具備：
能不能讀取 QIF
能不能輸出 QIF Results
是否有 QIF Module（QIF 模組）
是否提供 API
是否可以透過 Converter 轉換
整體架構比較接近：
CMM Hardware
│
▼
Measurement Software
│
│ QIF
▼
QMS / Inspection System / Data PlatformQIF 的重點是描述與交換品質資訊。
它不是一套用來取代 CMM 控制軟體的機台軟體。
六、所以企業到底要「安裝」什麼？
這應該是大家最關心的問題。我們將答案分成三種情況來說明：
情況一：現有軟體原生支援 QIF
這是最簡單的情況。
CAD
│
│ QIF Export
▼
QIF
│
│ QIF Import
▼
Measurement Software
企業可能只需要：
啟用 QIF Module
安裝 QIF Plug-in
升級到支援 QIF 的版本
向軟體供應商取得授權
這種情況通常不需要另外建立大型 QIF 平台。
情況二：軟體沒有原生 QIF，但有 API
這是企業很常遇到的狀況。
CAD
↓
API
↓
QIF Converter
↓
QIF
↓
Measurement Software
這時真正需要處理的是三件事。
1. API
從現有系統取得資料。
2. Mapping（資料對應）
把企業自己的資料欄位對應到 QIF。
3. QIF Generator（QIF 產生器）
把這些資料產生為符合 QIF Schema 的資料。
情況三：兩邊都不支援 QIF
這時才需要考慮比較完整的 QIF Integration（整合）。
例如：
CAD
↓
Custom Converter
↓
QIF
↓
Custom Integration
↓
CMM / Measurement
↓
QIF Results
↓
QMS
這種架構可以做到，但企業需要自行處理：
QIF Schema
Data Mapping
ID（Identifier，識別碼）管理
QIF XML 產生
QIF XML 解析
Validation
Error Handling（錯誤處理）
Version Management（版本管理）
因此，除非企業有明確的整合需求，否則不建議一開始就自行開發完整 QIF 平台。
講到這裡，答案其實就很清楚了。
企業不是要去「安裝 QIF」。
真正要做的是確認：
1. 哪個系統負責輸出 QIF？
例如：
CAD
量測軟體
QMS
其他製造品質系統
2. 哪個系統負責接收 QIF？
例如：
QMS
MES
PLM
量測平台
3. 如果系統沒有原生 QIF，要不要透過 API？
也就是：
既有系統 → API → Converter → QIF
4. 資料交換之後，是否還能保持原本的資料關係？
例如：
Part → Feature → Characteristic → Measurement → Result
這才是企業真正需要確認的事情。
留言