前言
2004年，CiA（CAN in Automation） 307檔「海事電子設備框架 Framework for maritime electronics」[1] 首次提出在關鍵任務應用中使用兩條CAN匯流排電纜的標準。然而，該標準僅適用於經典的CANopen，目前已被撤銷。基於CiA 307檔的原始理論，誕生了一個新的標準，稱為雙模組冗餘（DMR, Dual-modular Redundancy）。 DMR不僅適用於CAN網路和CAN FD網路，還可用於實現需要安全關鍵、任務關鍵和高可用性通訊的CAN設備和CAN網路。 DMR的設計獨立於任何特定的應用層（如CANopen、CANopen FD、J1939等）。
概述
如文獻[2]所述，一個設計的高可用性（HA）整合系統應具備足夠的冗餘和隔離，以防止單一故障導致基本功能或多個主要功能喪失。此外，任何整合控制或監控系統的網路應能透過設計達到單點故障容錯，確保單一故障不影響整體運作。這要求網路及其必要元件與電纜必須具備充分的冗餘。
因此，用於HA應用（如航空電子設備、海事等領域）的CAN網路，必須至少具備兩個獨立的CAN介面，每個介面分別驅動物理上相互分離的CAN線路。
在冗余CAN網路中的單一故障定義如下：
- CAN匯流排的單次中斷
- CAN收發器的單次故障
- CAN控制器（包括匯流排關閉狀態）的單次故障
（應用程式內部故障，例如CANopen應用中的心跳事件，不視為CAN網路故障。）
基於上述要求，支援冗餘通訊的CAN設備應具備兩個CAN節點（見下圖）。每個CAN節點包含數據連結層（DLL）、物理編碼子層（PCS）及物理介質附屬子層（PMA）。請注意，這兩個CAN節點在某些配置上（例如位元速率）是共用的。
圖1：具有DMR功能的CAN介面
DMR功能的目的是在應用程式與發送端CAN節點間複製數據包，以及對同一CAN介面上兩個CAN節點接收到的數據包進行去重處理。這意味著兩條CAN匯流排上的通訊內容必須完全一致。
CAN線路命名
CAN介面連接兩條電纜，一條連接所有設備的首個CAN節點，稱為默認CAN線路（DCL）；另一條連接第二個CAN節點，稱為冗餘CAN線路（RCL）。這些名稱源於原始CiA 307標準，且在系統安裝期間必須確保正確連接。
圖2：冗余CAN網路中的報文
在接收時，DMR功能僅會將選定的一條線路上的CAN數據包轉發給應用程式，該線路稱為活動CAN線路（ACL）。預設情況下，在系統初始化時，默認CAN線路（DCL）即為ACL，而另一條則為被動CAN線路（PCL）。
圖2展示了一個由CAN設備1到3組成的用於產生通訊流量的冗餘CAN網路示例。由於DMR內部的執行時間問題或網路上的幀重傳問題，不能保證所有CAN報文都以相同順序發送到兩條CAN線路上。DMR功能的任務就是處理這種順序不一致的情況。
DMR功能原理
如前所述，DMR功能（見圖3）的目的是對發送端CAN介面的兩個CAN節點之間複製要發送的數據包，以及對接收端CAN介面的兩個CAN節點所接收的數據包進行去重處理。CAN節點硬體抽象層（HAL）採用郵箱模型進行硬體抽象，一個郵箱通常具有唯一的方向，要麼是接收，要麼是發送。
圖3：DMR功能
DMR功能為每個郵箱提供一個計數器和一個計時器，並在DCL或RCL上成功發送/接收時分別增加或減少該計數器。郵箱計時器到達超時值後，計數器應回到0，以確保DCL與RCL上的傳輸次數保持平衡。
同時，DMR流程會檢查每個CAN節點的實際DLL狀態，例如匯流排關閉等狀態，也會針對偏差限制或超時值過期產生DMR事件。計數器偏差和郵箱超時等限值均可配置。
DMR故障檢測
DMR故障檢測在DMR操作中定期執行，透過計算郵箱計數器與偏差限制的差值，確保兩個CAN節點發送或接收的消息數量相同。由於CAN錯誤幀或執行時間問題，計數器在特定時間點可能不平衡（非0）。
圖4：故障檢測
若郵箱計數器不大於偏差限制但仍不平衡，則會檢查DCL和RCL的郵箱超時值是否到期，並據此判定是哪一條線路出現故障。
例如，圖5展示了CAN線路DCL在設備DEV3處發生單次中斷的情況。 設備DEV3在郵箱超時後，發現報文未能透過ACL（DCL）發送成功，便切換到RCL；其他設備則根據接收計數器的差值來判斷故障。
圖5：故障情況示例
同時，DMR功能會同步第2層驅動程式的FIFO緩衝區，並在故障線路上刪除任何待處理報文。DMR本身並不發送警報事件，若需對外通知故障則由應用層自行實作。
DMR狀態機
DMR功能具有內置的狀態機，透過DMR處理演算法控制，如圖6所示。
圖6：DMR狀態機
在冗餘啟動狀態下，DCL和RCL皆可正常工作；在冗餘被動狀態下，雖然雙線路可傳輸，但接收時會檢測到故障；在冗餘禁用狀態下，只有單一線路可用。
當網路斷開時，兩個CAN介面皆不運作。DMR狀態機有助於錯誤診斷，能區分接收與發送時的故障情況。以下表所示為圖5示例中各設備的狀態：
| 設備 | DMR 狀態 |
|---|---|
| DEV1 | 冗餘被動 |
| DEV2 | 冗餘被動 |
| DEV3 | 冗餘禁用 |
表1：圖5示例中的DMR狀態
各設備可透過上層協定將此資訊轉發給網路控制應用程式，以協助查找故障。
DMR連接服務
DMR連接服務的目的是檢查錯誤接線（DCL連接到RCL），並支援故障恢復。為此，每條CAN線路使用唯一的CAN識別字（見圖7），這兩個CAN識別字僅供DMR功能使用。
圖7：DMR連接服務
DMR連接服務的CAN-ID由本地應用程式配置，不應干擾應用層通訊協定。透過不同CAN-ID可檢查DCL與RCL是否皆已連接，但由於報文中無源位址（DLC=0），準確檢測故障來源相當困難，因此只提供「好」與「壞」報文數量給應用層判斷。
故障恢復
DMR的一個重要功能是自動故障恢復，如圖8所示。在故障恢復操作中，系統會先插入2秒延遲以嘗試恢復斷線，然後切換CAN線路到運行狀態並傳輸DMR連接服務。
圖8：DMR故障恢復
由於DMR連接服務的CAN-ID由網路層發送，可防止對上層協議造成干擾；當傳輸成功後，DMR狀態便會更新，若原故障線路已恢復，則可重新加入冗餘。
DMR測試
為驗證DMR功能，我們制定了DMR測試計畫並使用圖9所示的測試設置。測試過程中，於F1至F10標記處施加故障條件。
圖9：DMR測試設置示意圖
| 標記 | 操作條件 | 故障條件 |
|---|---|---|
| F1 .. F8 | CAN 匯流排連接 | CAN 匯流排斷開 |
| F9 .. F10 | 終端電阻可用 | CAN 線路短路 |
表2：測試設置的故障條件
測試期間，CAN網路串列傳輸速率為125 kBit/s，平均匯流排負載為85%。以下以「RCL啟動失敗」為範例：
POWER ON DUT
@SubTest 01
VerifyNmtState($dut)
IF NMT STATE $dut != OPERATIONAL THEN ERROR
示例1：RCL啟動失敗
表3：RCL啟動故障的驗收標準
基於新的CiA 701標準，DMR功能已在不同平臺上完成測試與驗證，未來將針對CANopen CC與CANopen FD進行適配，並透過物件字典中的標準化數據元素存取DMR參數。
