E/E 架構設計與 MBSE 解決方案：RFLP 建模、需求追溯與混合架構整合
多數團隊的開發流程，是為「設計階段就完全已知的封閉系統」設計的。但現在的車輛架構是混合的：一部分仍然是訊號導向、靜態、封閉的；另一部分是服務導向、動態、開放的，執行期還會有新的參與者加入。用舊流程管新架構，第一個失控的地方就是變更——改一個需求，沒有人說得清有哪些設計與測試會受影響。歐特莫夫的角色不是把一套建模方法整包搬給您，而是先看您現有的資產放在哪裡，再決定方法要做到多重——方法選得太重，團隊會放棄使用，那比沒有導入更糟。
01 我們的技術方法
- 依團隊實際需要裁剪建模方法，而不是一律走完整四層
- 建立單一的架構資料庫，避免出現第二個真實來源
- 把追溯關係交給工具維護，包含到測試規格的那一段
- 在架構階段就處理變體，而不是每個變體各自維護
03 技術難點
為什麼架構要「建模」，而不是「寫文件」？
一輛車大約有一百到兩百個車輛功能，每個功能都由感測器、執行器，以及一或多個運算節點（ECU、區域控制器、高效能運算平台、後端）共同實現。用文件描述這種規模的關聯是做得到的，但改一個地方就得人工追出所有受影響的文件——漏掉的那一份，就是後面的問題來源。建模的做法是把需求、功能、邏輯與物理架構放進同一個資料庫，關聯由工具維護。RFLP 就是這四層的縮寫（需求、功能、邏輯、物理）；它不是規定四層都要做，而是一個可以依實際需要裁剪的框架。
混合架構才是現在的真實情況
訊號導向與服務導向必須共存
訊號導向的子架構是靜態、封閉的，設計階段就完全已知；服務導向的部分是動態、開放的，執行期還可以新增、更新或移除參與者。真正的難處不在各自實作，而在兩者交界處的介面怎麼定義、由誰維護——這一段沒講清楚，整合階段就會卡住。
四個視角，但不一定四層都要做
需求、功能、邏輯、物理四個視角各自回答不同的問題。實務上可以裁剪成只做邏輯與物理，甚至只做物理；選哪一種取決於團隊規模與稽核要求，不是層數越多越好。順帶一提，軟體的物理視角與硬體的物理視角並不是同一件事，這一點很常被混在一起。
追溯要分垂直與水平兩種
垂直追溯串起 RFLP 各層之間的關係；水平追溯把架構元素連到測試規格。稽核時被問到的通常是後者——「這條需求由哪一個測試驗證」。只做垂直追溯的專案，往往在這個問題上答不出來。
變體是設計範圍，不是後期加工
設計對象是產品家族而不是單一車型。變體與選項在架構階段就用特性模型描述清楚，後續才不會演變成每個變體各自維護一份設計。這件事越晚處理，回頭整併的成本越高。
歐特莫夫的技術服務流程
MBSE 導入最常見的失敗不是工具不好用，而是方法選得太重、團隊放棄使用。這四個階段刻意從「裁剪」開始。
現況盤點與方法裁剪
盤點現有的需求、架構與測試資產各自放在哪裡、由誰維護，再決定要走完整四層還是裁剪版本。產出是一份方法定義，明確寫出哪些關聯必須建立、哪些不必——這比直接開始建模重要得多。
資料庫建立與外部整合
建立單一的架構資料庫，並與既有的 PLM 與需求管理工具串接，例如以標準交換格式定期匯入利益相關者需求。這一步的原則是不製造第二個真實來源；兩份都能改的資料，最後兩份都不可信。
建模與追溯落地
依裁剪後的方法建模，並把追溯關係實際建起來。我們會協助定義「什麼情況下必須建立追溯」，否則追溯很快會變成填表工作——工程師填了但不相信，稽核也看不出意義。
變更管理與狀態度量
以儀表板檢視變更的影響範圍與完成度，讓架構的狀態隨時可看，而不是等到里程碑前才盤點一次。變更管理能不能運作，是判斷 MBSE 導入成功與否最直接的指標。