電輔車 HMI 不只是顯示器：啟動方式、通訊協定、取電路徑與控制器整合都會影響系統運作
很多人看到電輔車 HMI / Display / 儀表時，第一個直覺是：
它只是顯示速度、電量、助力段位的螢幕。
但從系統工程角度來看，HMI 不只是顯示器。
它可能同時涉及電源規格、系統喚醒、CAN / UART 通訊、BLE 模組、參數設定、錯誤碼顯示、防水耐候、外部取電，以及控制器、BMS、電池組之間的整合邏輯。
如果只把 HMI 當成一個可以任意替換的配件，就很容易忽略背後真正的系統風險。
接頭看起來一樣，不代表 pin definition 一樣。
同樣是 CAN，不代表 CAN matrix 相同。
同樣是 UART，也不代表 protocol 相容。
HMI 可以點亮，也不代表控制器、電池與整車系統已經正確完成啟動與通訊。
HMI 上多一個 USB 充電孔，也不只是多一個便利功能，而是多了一條取電路徑與一個可能進水的開口。
所以，HMI 不是單純螢幕，而是使用者與整車電控系統之間的重要入口。
什麼是HMI ？
在電輔車上，HMI 常被稱為儀表、顯示器或 Display。
一般使用者最容易看到的是：
速度顯示
電量顯示
助力段位
里程資訊
燈號狀態
錯誤碼提示
開關機按鍵
這些都是 HMI 的表層功能。
但在實際系統整合中，HMI 可能還牽涉到更深層的系統設計，例如：
系統如何被喚醒
控制器如何接收使用者指令
速度限制如何設定
助力段位如何切換
輪徑資料是否正確
錯誤碼如何被顯示
電量資料來自哪裡
是否支援 CAN 或 UART
是否內建 BLE 模組
是否可以讀取或寫入參數
是否有外部充電孔
額外取電是否被納入系統監測
防水耐候是否足以支撐長期戶外使用
因此，HMI 的價值不只在於畫面漂亮或按鍵好不好按，而在於它是否能被正確放進整車電控系統中。
對品牌商、車廠、租賃車隊或系統整合商來說，HMI 是一個看似簡單、但實際上很容易造成整合風險的零件。
HMI 是使用者與電控系統之間的操作介面
電輔車的控制核心通常不在 HMI 本身，而是在控制器、BMS、電池組與韌體邏輯之間。
但使用者每天接觸最多的，往往是 HMI。
使用者透過 HMI 開關機、切換助力、查看速度、判斷電量、讀取錯誤碼，甚至在某些系統中調整參數。
這代表 HMI 其實扮演兩個角色：
第一，它是使用者介面。
第二，它也是系統資訊的入口與出口。
如果 HMI 與控制器、BMS 或電池組之間的資料邏輯沒有對齊，就可能出現一些看似小問題、實際上很麻煩的狀況。
例如：
儀表顯示電量不準。
助力段位切換後輸出感不一致。
速度顯示與實際速度不同。
錯誤碼顯示與控制器定義不同。
HMI 可以亮，但控制器沒有被正確喚醒。
HMI 可以操作，但參數寫入後系統反應異常。
HMI 額外供電給外部設備，但耗電沒有被系統正確計算。
所以，HMI 的整合不能只看顯示功能，而要確認它與整套電控系統的關係。
HMI 規格常見關鍵字：36V/48V、CAN/UART 與 BLE 模組
在電輔車系統中，HMI 常見的規格差異不只在外觀、尺寸或顯示內容。
實際整合時，至少要確認三個層次：電壓規格、通訊方式、附加功能模組。
第一，是電壓規格。
常見的 HMI 可能支援 36V、48V，或標示為寬電壓輸入。這代表 HMI 內部電源設計、耐壓範圍、啟動方式與保護條件可能不同。
即使接頭外觀看起來相同，也不能假設 36V 與 48V 系統可以直接互換。
第二，是通訊方式。
常見的 HMI 可能採用 CAN 或 UART。這兩者不是單純線材不同，而是整個資料交換方式不同。
CAN 通常比較適合系統化資料交換、狀態回報與多節點整合。UART 則常見於較簡化的點對點通訊架構。
但真正要注意的是：
同樣是 CAN，不代表 CAN matrix 相同。
同樣是 UART，也不代表 protocol 相容。
通訊介面只是第一層，協定內容才是整合關鍵。
第三，是附加功能模組。
現在越來越多 HMI 內部也加入 BLE 模組，讓手機 App 可以讀取狀態、調整部分設定、查看資訊或延伸使用者介面。
這讓 HMI 不再只是車上的顯示器，而可能變成手機、控制器、電池與後端服務之間的資料入口。
因此，評估 HMI 時不能只問：
這顆螢幕能不能亮？
接頭能不能插？
畫面有沒有顯示速度？
更重要的是要確認：
這顆 HMI 支援幾伏系統？
啟動方式是 Vbat、低壓輔助電源，還是特定 wake-up 訊號？
通訊方式是 CAN 還是 UART？
協定內容是否與控制器一致？
是否有 BLE？
BLE 是直接連 HMI，還是透過 HMI 轉接控制器資料？
哪些參數可以讀取？
哪些參數可以寫入？
是否會影響限速、輪徑、助力段位或錯誤碼顯示？
這些條件如果沒有先確認，就可能出現「螢幕點得亮，但系統不能正常工作」的情況。
HMI 的電源與喚醒邏輯，會影響控制器與電池設計
很多人會以為，只要 HMI 接頭一樣，或同樣是 CAN / UART，就可以直接替換。
但在實際系統整合中，HMI 的電源與喚醒邏輯是一個很容易被忽略、卻非常關鍵的差異。
有些 HMI 可能透過 Vbat 主電池電壓 進行喚醒或開機。
有些 HMI 則可能需要 低壓輔助電源、電池端 wake-up 訊號，或特定控制線完成系統啟動。
12V 只是其中一種可能的低壓喚醒例子，並不代表所有系統都使用相同電壓或相同邏輯。
這些差異不只是 HMI 內部硬體設計不同而已，也可能牽涉到控制器與電池端的設計。
例如：
Vbat、低壓輔助電源與 wake-up 訊號，是不同的系統啟動邏輯
HMI 的啟動方式，不能只用「能不能開機」來判斷。
不同系統可能採用不同上電邏輯。
有些系統由 HMI 接收主電池電壓後啟動。
有些系統需要電池先提供低壓輔助電源。
有些系統需要 HMI 發出 wake-up 訊號後，控制器或電池才開始供電。
也有些系統的 HMI、控制器、BMS 之間需要特定上電順序或通訊握手。
這代表 HMI 的啟動方式，不只是 HMI 本身的差異，而是整車電控架構的一部分。
如果從一種啟動方式改成另一種啟動方式，控制器可能需要硬體修正，電池端也可能需要提供對應的電源或喚醒邏輯。
這也是為什麼在 HMI 整合中，最危險的誤判之一，就是把「接頭看起來一樣」誤認為「系統邏輯一樣」。
接頭外觀相同，不代表線序相同。
通訊線存在，不代表協定相同。
HMI 可以點亮，不代表控制器已經正確啟動。
控制器能上電，也不代表電池與 HMI 的喚醒邏輯完全一致。
在確認電源來源、喚醒方式、pin definition 與通訊協定之前，不建議直接替換 HMI。
更重要的是要先確認：
這顆 HMI 的電源從哪裡來？
它用什麼方式喚醒系統？
控制器硬體是否支援？
電池端是否需要配合？
pin definition 是否完全一致？
開機順序是否符合整車邏輯？
這些問題如果沒有先釐清，後續再做韌體調整、參數設定或騎乘測試，都可能建立在錯誤的系統假設上。
控制器 wake-up circuit 是否支援該啟動方式。
低壓電源是由電池、控制器還是其他模組提供。
電池是否需要先被喚醒，才能提供 HMI 所需電源。
HMI 開機後是否會反向喚醒控制器。
控制器是否需要額外硬體修正。
線束與 connector pin definition 是否一致。
開機順序是否符合系統設計。
HMI、電池、控制器之間是否有明確責任邊界。
如果這些條件沒有先確認，只是把不同啟動邏輯的 HMI 直接接上，就可能出現無法開機、控制器無法喚醒、電池沒有輸出、通訊無反應，甚至因接線錯誤造成元件損壞的風險。
所以在 HMI 整合前，不能只問「是不是 CAN」或「是不是 UART」，也不能只看接頭是否相同。
不同 HMI 不能只看接頭相同就直接替換
HMI 整合中最常見的誤判，是只看接頭外觀。
接頭一樣，不代表線序一樣。
線序一樣，不代表電壓規格一樣。
電壓一樣，不代表喚醒邏輯一樣。
同樣是 CAN，不代表 CAN matrix 一樣。
同樣是 UART，不代表 protocol 一樣。
HMI 可以點亮，不代表整車系統可以正常運作。
真正要確認的是整套條件：
電源輸入範圍
Vbat 或低壓喚醒方式
wake-up 訊號定義
CAN / UART 通訊內容
pin definition
輪徑與速度資料來源
助力段位定義
錯誤碼對應
電量資料來源
是否有 BLE 與 App 資料轉接
是否有 USB / Type-A / Type-C 外部取電
外部取電是否被納入 SOC 與電流監測
參數是否可讀寫
控制器是否接受該 HMI 的操作邏輯
控制器端是否有足夠保護設計
如果這些沒有確認，就直接更換 HMI，風險不只是不能顯示，而是可能造成系統不能啟動、輸出異常、錯誤碼誤判、電量判斷失準，甚至元件損壞。
因此，HMI 的整合應該被視為系統整合的一部分，而不是單純配件更換。
CAN、UART，不同的通訊方式 ，決定 HMI 能反應系統多少即時資訊
HMI 與控制器之間的通訊方式，常見有 CAN 與 UART。
這兩種通訊方式在系統設計上有不同特性。
CAN 通常比較適合多節點、狀態回報、錯誤診斷與較完整的系統資料交換。
UART 則常見於較簡化的點對點通訊架構，整合方式相對直接，但資料結構與功能範圍依各家協定而定。
但對系統整合來說，真正重要的不是只看 CAN 或 UART，而是協定內容。
需要確認的包含：
HMI 傳送哪些指令給控制器？
控制器回傳哪些狀態給 HMI？
助力段位如何定義？
速度資訊由誰計算？
電量資訊由誰提供？
錯誤碼定義是否一致？
輪徑、限速、電壓、燈號設定是否可由 HMI 調整？
參數是只讀，還是可以寫入控制器？
如果協定內容不一致，HMI 可能可以開機，也可以顯示部分資訊，但整車行為仍然可能不正確。
例如：
助力段位顯示正常，但控制器輸出沒有對應變化。
速度顯示正常，但限速邏輯錯誤。
電量有顯示，但演算法與 BMS 或控制器不一致。
錯誤碼有跳出，但維修端無法正確解讀。
HMI 寫入參數，但控制器不接受或解讀錯誤。
所以，HMI 整合不是只接線，而是必須確認通訊協定與系統資料邏輯。
HMI 常見失效問題：長期戶外使用的風險
HMI 會直接面對風吹、日曬、雨水、濕氣、溫差、震動與紫外線。
從外觀上看，HMI 只是小型顯示器，但它實際上是一個長期暴露在戶外環境中的電子模組。
常見的 HMI 防護設計包含：
外殼超音波壓合
螺絲鎖固加密封圈
線材出線處防水膠
內部灌膠或 PCBA 塗膠
按鍵區域防水膜
連接器防水設計
這些設計可以提高耐候性，但不代表 HMI 就能完全避免水氣入侵。
如果仔細看許多 HMI 規格書上的 IP 防塵防水等級，就不難理解：HMI 的防水能力通常有條件限制，並不等於長期浸水、長期高濕、長期曝曬後仍然完全不會失效。
尤其在戶外長期使用後，紫外線會讓塑膠外殼、按鍵膠膜、密封材料與線材外皮逐漸老化。水氣則可能從按鍵、接縫、出線口或連接器位置慢慢進入。
當水氣進入 HMI 內部後，真正的風險不是只有螢幕不亮，而是可能造成：
按鍵誤觸發
顯示異常
通訊異常
電源線短路
wake-up 線異常導通
CAN / UART 訊號被干擾
低壓電源與訊號線短路
透過喚醒線或供電線逆向影響控制器
這也是 HMI 失效最麻煩的地方：
它不一定只是 HMI 自己壞掉，有時候會沿著電源、訊號或 wake-up 路徑，把風險帶回控制器端。
HMI 上的 USB / Type-A / Type-C 充電孔，有機會增加防水與售後風險
有些 HMI 會額外加入 USB Type-A、Type-C 或其他充電孔，讓使用者可以替手機、燈具或其他小型裝置供電。
這類設計從使用者角度來看很方便，但從戶外可靠性角度來看，它其實會增加防水與失效風險。
原因很直接：
只要 HMI 外殼多了一個開孔，防水設計就多了一個弱點。
即使充電孔有橡膠塞、防水蓋或密封結構，也不代表長期風吹日曬、紫外線老化、反覆插拔、雨水殘留與濕氣累積後，仍能維持原本的防護效果。
尤其 USB Type-A 這類接口，本身就不是為長期戶外高濕、雨水、泥沙與震動環境而設計。當它被整合到 HMI 上時，就需要更嚴格評估：
防水蓋是否會老化。
橡膠塞是否容易鬆脫。
使用者是否會忘記蓋回。
插孔內是否容易積水。
金屬端子是否容易氧化。
充電輸出短路時是否有保護。
水氣是否可能沿著插孔進入 HMI 內部。
異常電流是否可能反向影響控制器或低壓供電路徑。
所以，HMI 上增加充電孔，不只是多一個便利功能，也代表防水、耐候、電源保護與售後風險都要重新評估。
USB / Type-A / Type-C 充電孔不是不能做，而是不能只把它當成賣點。它會把 HMI 從單純顯示模組，變成帶外部供電接口的戶外電子模組。
對戶外電輔車系統來說，每多一個外部接口，就多一個可靠性風險點。便利性與防水耐候之間必須取捨。
從 HMI 額外取電，有機率會影響系統電流與能耗判斷
HMI 上的 USB / Type-A / Type-C 充電孔，不只是防水問題，也是一條額外的能量出口。
有些使用者可能會透過 HMI 充手機、燈具、行車記錄器或其他小型裝置。從使用者角度來看，這很方便；但從整車電控系統角度來看，這不是零成本功能。
因為電輔車系統對輸出電流、電池電量、能耗與保護邊界通常需要非常精細地監測與計算。
尤其是具備 BMS、控制器通訊、SOC 估算或車隊管理功能的系統，每一條額外取電路徑都會影響整體能量流向的判斷。
如果使用者從 HMI 上額外取電，系統就必須回答幾個問題：
這一路電流是否有被控制器或 BMS 正確量測？
這個耗電是否有被納入 SOC 計算？
這個負載是來自電池端、控制器端，還是 HMI 內部降壓模組？
當外部裝置短路或過載時，保護邏輯由誰負責？
低壓輸出是否會影響 HMI 本身供電穩定？
是否會影響控制器喚醒、待機耗電或休眠邏輯？
當車輛關機後，這個接口是否仍可能持續耗電？
這些問題如果沒有定義清楚，USB 充電孔就不只是「多一個方便功能」，而是變成一條額外的能量出口。
為什麼額外取電有機會影響整體系統？
電輔車的電池電量顯示，不應該只看電壓。
較完整的系統通常會搭配電流量測、電壓追蹤、溫度條件、負載狀態與 BMS 資料來估算 SOC。
如果 HMI 上的外部充電接口所消耗的電流沒有被正確納入量測，系統就可能出現判斷落差。
例如：
使用者從 HMI USB 孔替手機充電，電池實際有耗電。
但如果這一路耗電沒有被 BMS 或控制器正確統計，儀表顯示的剩餘電量可能會與實際狀態產生差異。
在輕量使用情境下，這個差異可能不明顯。
但在長時間待機、車隊營運、租賃車、高頻使用或低電量狀態下，這種額外耗電就可能變成管理問題。
更麻煩的是，如果 USB 輸出口發生短路或過載，系統必須能清楚判斷：
這是 HMI 問題？
低壓供電問題？
控制器問題？
電池端保護問題？
還是外部裝置造成的異常？
如果責任邊界不清楚，售後診斷就會變得困難。
所以，HMI 上的外部取電功能應該被納入整車電源架構、SOC 計算、保護設計與售後責任邊界，而不是只當作便利功能。
對電輔車系統來說，每一條電流路徑都應該被定義、被保護、被管理。
水氣短路為什麼可能反向影響控制器？
HMI 通常不是孤立存在，它會透過線束與控制器、電池或其他模組連接。
如果 HMI 內部因水氣入侵產生短路，短路位置可能不只發生在 HMI 自己的電源與地之間，也可能發生在：
Vbat 與訊號線之間
低壓電源與通訊線之間
wake-up 線與電源線之間
按鍵線與電源線之間
CAN / UART 線與其他電源線之間
燈號控制線與電源線之間
USB 充電輸出與 HMI 內部電路之間
這時候要看整套系統的喚醒方式與電路保護設計。
如果某些 HMI 是透過 Vbat、低壓輔助電源或特定 wake-up 訊號來啟動系統，那麼 HMI 內部短路後，異常電壓或異常電流就可能經由這些路徑回到控制器。
輕微情況可能造成控制器無法開機、誤喚醒、通訊異常或錯誤碼。
嚴重情況則可能造成控制器輸入保護電路、低壓電源電路、通訊收發器或 wake-up circuit 損壞。
所以在 HMI 整合中，不能只確認「HMI 會不會亮」或「通訊有沒有資料」。還要評估：
如果 HMI 進水短路，控制器端是否有足夠保護？
如果 wake-up 線異常導通，系統會不會誤啟動？
如果 Vbat 跑到訊號線，控制器端是否能承受？
如果低壓電源短路，是否會拖垮控制器或電池端供電？
如果 USB 輸出短路，保護責任由誰承擔？
這些才是量產與售後真正會遇到的問題。
HMI 的發展趨勢：從顯示器走向上層控制介面
在許多電輔車成套系統中，HMI 的角色已經不只是顯示速度、電量與助力段位。
越來越多 HMI 開始往「上層控制介面」的方向發展。
也就是使用者、組車端或經銷商可以直接透過儀表調整許多系統參數，例如：
速度限制
輪徑設定
電壓系統選項
助力段位
輸出模式
燈號設定
部分錯誤碼查詢
進階參數設定
這種架構在許多成套購買的電輔車系統中很常見。
它的優點是導入快、調整方便、使用者介面直覺，也比較容易形成標準套件銷售。
對某些市場來說，這是合理的設計選擇。
但從另一個角度來看，當 HMI 擁有太多參數控制權時，整車系統的主導權會逐漸從控制器轉移到 HMI。
這代表控制器、HMI、電池與感測器之間的參數邏輯必須高度綁定。
一旦更換不同品牌或不同協定的 HMI，就可能出現參數不相容、設定無法寫入、錯誤碼不一致、助力段位異常，甚至系統無法正常啟動的問題。
上控型 HMI 的優點與風險
上控型 HMI 並不是錯誤設計。
它有明確優點：
調整方便。
操作直覺。
組車導入快速。
經銷端容易做基本設定。
使用者可以直接看到更多資訊。
標準套件銷售比較容易。
但它也有需要管理的風險。
第一，HMI 與控制器容易高度綁定。
如果大量參數都透過 HMI 管理，HMI 就不再只是顯示器，而是系統控制的一部分。未來 HMI 停產、改版、缺料或客戶想換外觀時，整套系統可能都要重新驗證。
第二，系統主導權可能分散。
如果速度限制、助力段位、輸出模式與部分保護設定都能從 HMI 端調整，系統安全邊界就必須嚴格管理。否則不同 HMI 設定可能造成不同車輛行為。
第三，售後診斷可能變複雜。
當車輛異常時，維修端要判斷問題來自 HMI 設定、控制器邏輯、BMS 限制、電池狀態、通訊異常，還是使用者操作。這會增加售後判斷成本。
第四，合規與量產一致性需要更高管理。
如果終端或經銷端可以調整太多深層參數，對品牌商與車廠來說，就必須有更嚴格的權限管理與版本控管。
因此，上控型 HMI 適合某些場景，但不一定適合所有 B2B 量產、車隊營運或合規要求較高的應用。
燕築實業的設計取向：控制器主導，HMI 以顯示與資訊轉接為主
Veloroof 的系統設計取向，並不是讓 HMI 掌握整套系統的核心控制權，而是以控制器作為主要判斷與控制核心。
在這樣的架構下，HMI 的角色比較接近：
顯示速度、電量與系統狀態。
提供基本操作介面。
傳遞必要的使用者輸入。
顯示錯誤碼或狀態資訊。
作為資訊轉接或 by-pass 介面。
真正的系統主導權，仍然保留在控制器端。
例如：
速度限制
保護邏輯
輸出策略
馬達控制
安全邊界
核心韌體判斷
這些關鍵邏輯應該由控制器端統一管理。
這樣設計的目的不是讓 HMI 變得不重要，而是讓 HMI 回到更清楚的位置：
HMI 是操作與顯示介面，不是整套系統安全邊界的唯一管理者。
系統設計邏輯不把核心控制權完全交給 HMI
採取控制器主導架構，主要是基於幾個實務考量。
第一，降低 HMI 綁定風險。
如果系統過度依賴某一家 HMI 的參數邏輯，未來一旦 HMI 停產、缺料、改版或客戶想更換外觀，整套系統都可能被迫重新調整。
控制器主導的架構，可以降低這種供應鏈與版本綁定風險。
第二，提高 HMI 選擇彈性。
不同客戶可能偏好不同外觀、不同尺寸、不同品牌或不同操作邏輯的 HMI。
若核心控制邏輯集中在控制器端，只要確認電源規格、wake-up 邏輯、CAN / UART 協定、pin definition 與顯示資料需求，就比較有機會導入不同 HMI。
第三，維持系統控制一致性。
速度限制、保護邏輯、輸出策略、馬達控制與安全邊界，最好由控制器端統一管理。
這樣可以避免不同 HMI 寫入不同參數，造成同一套車在不同儀表下出現不一致行為。
第四，降低售後判斷複雜度。
如果 HMI 掌握太多參數，一旦車輛出現問題，維修端必須同時判斷是 HMI 設定、控制器邏輯、BMS 限制、通訊異常，還是電池狀態。
控制器主導的架構，可以讓診斷邏輯更集中。
第五，更適合 B2B 系統整合。
對品牌商、車廠、租賃車隊或特殊應用車輛來說，最重要的不是讓終端使用者任意調整深層參數，而是讓系統邏輯穩定、可控、可維護、可診斷、可量產管理。
HMI 可以是操作介面，但不應該讓整套系統的安全邊界完全依賴 HMI。
HMI 是系統入口，不只是配件
電輔車 HMI 不只是顯示速度與電量的螢幕。
它可能涉及電壓規格、喚醒邏輯、CAN / UART 通訊、BLE 模組、助力段位、限速設定、錯誤碼顯示、參數讀寫、防水耐候與外部取電。
市場上 HMI 的發展正在從單純顯示走向上層控制介面。這種方向有它的優點，尤其是在成套系統、快速導入與使用者調整上非常方便。
但對 B2B 電輔車系統整合來說，控制權不一定越往 HMI 放越好。
如果整套系統的安全邊界、輸出策略與保護邏輯過度依賴 HMI，就可能造成 HMI 綁定、版本管理困難、售後診斷複雜與系統一致性降低。
同時，HMI 也是長期暴露在戶外的電子模組。紫外線、水氣、USB 充電孔、外部取電與短路風險，都可能讓 HMI 從單純顯示問題，變成整車系統可靠性問題。
Veloroof 的設計取向，是控制器主導，HMI 主要負責顯示、操作與資訊轉接。
這樣的架構有助於提高 HMI 相容彈性、維持控制邏輯一致性，並讓整車系統更容易被管理、維護與診斷。
HMI 不是不能有控制功能，也不是不能增加 USB 或 BLE 等便利功能，而是必須先釐清：
整套系統的主導權應該放在哪裡？
每一條電流路徑是否被監測？
每一個外部接口是否被保護？
每一個失效風險是否被納入系統設計？
這才是 HMI 從顯示器走向系統介面時，真正需要思考的核心問題。
電輔車 HMI、控制器、BMS 與系統整合支援
Veloroof 燕築實業專注於電輔車控制器、BMS、電池組與系統整合，協助品牌商、車廠與特殊應用車輛開發更穩定、可管理、可維護的電控系統。
我們可協助討論：
電輔車 HMI 與控制器整合
36V / 48V 系統匹配
Vbat、低壓輔助電源與 wake-up 邏輯
CAN / UART 通訊協定整合
BLE 與手機 App 資料入口
HMI pin definition 與線束確認
助力段位、速度、輪徑與錯誤碼定義
控制器主導架構下的 HMI 顯示與資訊轉接
HMI 外部取電與低壓供電路徑評估
HMI 防水耐候與失效風險評估
量產前系統驗證與整合確認
如果您正在開發電輔車、e-cargo bike、租賃車隊或特殊應用車輛，並需要 HMI、控制器、BMS、電池組與整車電控系統整合支援，歡迎與我們聯繫討論。
Q1：電輔車 HMI 可以隨便更換嗎？
不建議直接更換。
即使接頭外觀看起來相同，也需要確認電壓規格、pin definition、喚醒邏輯、CAN / UART 通訊協定、錯誤碼定義與參數讀寫方式是否一致。
HMI 可以點亮，不代表整車系統可以正常工作。
Q2：HMI 會影響速度或助力嗎？
會，取決於系統架構。
在某些上控型 HMI 架構中，HMI 可能可以調整速度限制、輪徑、助力段位或輸出模式。
在 Veloroof 的設計取向中，核心控制邏輯仍以控制器為主，HMI 主要負責顯示、基本操作與資訊轉接。這樣可以維持系統一致性與安全邊界。
Q3：同樣是 CAN HMI，就一定可以相容嗎？
不一定。
CAN 只是通訊方式，真正關鍵是 CAN matrix 與資料定義。不同品牌或不同系統的 CAN HMI，即使通訊介面相同，資料格式、ID 定義、錯誤碼、助力段位與狀態回報也可能不同。
所以不能只看到 CAN 就判斷相容。
Q4：UART HMI 和 CAN HMI 有什麼差異？
一般來說，CAN 較適合多節點、狀態回報、錯誤診斷與較完整的系統資料交換。UART 則常見於較簡化的點對點通訊架構。
但實際功能仍取決於各家協定內容。不是 CAN 就一定比較完整，也不是 UART 就一定簡單。重點仍是 HMI 與控制器之間的 protocol 是否一致。
Q5：HMI 內建 BLE 代表什麼？
HMI 內建 BLE 代表它可能成為手機 App 與整車系統之間的資料入口。
BLE 可能用來查看狀態、讀取資料、調整部分設定或延伸使用者介面。但需要確認 BLE 是直接連 HMI，還是透過 HMI 轉接控制器資料，以及哪些資料可以讀取或寫入。
Q6：為什麼燕築實業設計系統的時候不把所有控制權都放在 HMI？
因為對 B2B 系統整合來說，最重要的是系統穩定性、一致性、可維護性與安全邊界。
如果 HMI 掌握太多核心控制參數，未來更換 HMI、處理售後、維持合規速度限制與管理版本時，風險會提高。
Veloroof 採取控制器主導架構，是為了讓系統控制邏輯更集中，也讓不同 HMI 有較高機會被整合。
Q7：HMI 進水只會造成儀表故障嗎？
不一定。
HMI 進水後可能造成顯示異常、按鍵誤動作、通訊異常或電源短路。若短路發生在電源線、wake-up 線或通訊線附近，異常電壓或電流也可能反向影響控制器端。
因此，HMI 的防水耐候、IP 等級、線束設計與控制器端保護，都應該被納入系統整合評估。