在前文中，我們探討了具有實時能力的嵌入式通信系統的基本要求——平衡實時響應、安全性和保障。本篇文章將重點介紹CAN與CANopen的實時能力和局限性。

控制器局域網(CAN)協議是各個行業眾多應用的基礎，每個應用都有其獨特的實時需求。CANopen和J1939等著名示例強調了該協議的多種適應性，以滿足特定需求。值得注意的是，這些應用程序的實時要求并不全面統一。雖然某些應用程序需要以毫秒為單位的反應時間，但許多其他應用程序可以在更寬松的標準下有效運行。物理約束、網絡拓撲和計算任務等因素在形成這些需求方面發揮著至關重要的作用。當我們探索更嚴格的實時約束時，通信配置和代碼處理的復雜性就會增加。然而，當實時要求更加寬松時，它為更簡單、更精簡的系統設計提供了機會，而無需犧牲功能或可靠性。

盡管安全性和保障都得到了解決（通過CANopen Safety和CANcrypt），但目前還沒有提供這兩者的標準化解決方案。CiA用戶組目前擁有多個工作組，負責審查CAN、CAN FD和CAN XL安全通信的各個方面。

1

CAN的實時能力

CAN的實時性與其通信速度密切相關，并進一步受到其基于優先級的仲裁機制的影響。計算CAN幀傳輸時間并不是一項簡單的任務；時間取決于數據字節數及其內容。這種復雜性的出現是因為可以根據幀的數據將填充位添加到幀中。因此，以下確定的值應被視為近似值，提供當前范圍的一般意義。

重要的是要記住，您的最大比特率還取決于布線的物理拓撲，并且根據您的應用，單個控制周期所需的總傳輸可能包括兩條傳輸路徑：一條用于將數據輸入到控制單元，另一條用于從控制單元到輸出。

雖然本文重點關注CAN，但以下大多數注意事項也適用于CAN FD（靈活數據速率）和CAN XL變體。這兩種協議都具有雙比特率機制，進一步增強了它們的數據吞吐能力。然而，在討論與時序相關的動態時，大多數考慮因素主要適用于“標稱比特率”。這一基本比特率本質上確定了仲裁、確認和錯誤信令等控制信息的速度。對于使用CAN FD和CAN XL的用戶來說，了解控制實際數據傳輸的“數據相位比特率”帶來的額外復雜性至關重要。這些系統中的關鍵問題之一是確定長消息可能占用總線的最大持續時間，以及與最長的8字節經典CAN幀相比，該延遲可能要長多少。

CAN的最大速度為1Mbps，允許在一毫秒內交換十多個幀。相反，在125kbps的適度速率下，平均約為每毫秒一幀。除了傳輸時間之外，如果隊列中有更高優先級的通信，信號或幀也可能會出現延遲。簡而言之，最壞情況的傳輸時間是幀本身的傳輸時間與系統中最高優先級流量的最長序列所預期的延遲之和。這假設所有通信都發生在單個CAN總線上。如果信號需要通過網橋或網關轉發，延遲會變得更長，甚至更難以預測。

消息優先級系統可能是一把雙刃劍。然而，有一個解決辦法：通過策略性地限制連續高優先級流量的持續時間，即使具有最低優先級的通信也可以以最小的延遲進行調度。這種方法可確保整個系統的數據交換一致且及時。

單獨觀察CAN（以及FD和XL變體），很明顯原本它不是確定性的。產生高優先級幀的單個設備可能會阻止所有其他設備的通信。為了使CAN具有確定性，我們需要確保受控幀被觸發——何時可以使用哪個CAN ID。要激活CAN的實時功能，請考慮以下設計目標。雖然這些指南可能會根據應用程序的具體情況而有所不同，但它們可以作為可靠的起點：

1

旨在將總體總線負載保持在一個水平，即使是低優先級幀也有足夠的時間訪問總線。雖然確切的閾值可能因應用程序而異，但我最初的建議是保持在75%以下的總線負載（如果通信純粹基于狀態更改，則總線負載會更少）。

2

確保沒有單個節點可以生成連續消息的擴展流。一些驅動程序提供傳輸“節流閥”來限制最大傳輸速率。

3

對于那些需要對傳輸時序和源進行更精細控制的人，請考慮CANopen的SYNC模式。該模式支持觸發消息，提供對傳輸調度的增強控制，允許類似于時間觸發系統所使用的觸發模式。

2

掌握基于CAN總線系統的時間動態

在明確了基于CAN的系統的各種用例及其各自的時間要求之后，將CAN配置與特定時間要求相匹配既是一門藝術，也是一門科學。下表總結了一些需要考慮的主要數據和因素。表的第一部分為您提供了各種比特率下預期的CAN時序和吞吐量的摘要——這全部適用于使用11bit CAN 消息標識符的經典CAN。事實上，即使在較低的比特率下，我們仍然在談論每秒潛在的數千個CAN幀，這一事實永遠不會讓我感到驚訝。通信的空間如此之大，人們可以輕松掌握，通過一些關于如何使用所有這些“空間”的明確定義的參數，我們可以很好地設計具有實時能力的系統。

傳輸延遲的大致數據

表中還顯示了潛在的傳輸延遲，并且取決于許多因素。因此，這只是針對特定用例的粗略估計，您需要根據自己的用例進行調整。第一行顯示如果總線當前正在使用（仲裁已經開始，發送器來不及加入），即使是最高優先級也會有延遲。傳輸必須等待，直到當前幀完成。第二行顯示仲裁延遲——如果有其他設備也嘗試傳輸幀，我們需要等待多長時間？此處，我們顯示了當前待傳輸的5個其他幀的延遲，如果使用節流機制來防止back-2-back傳輸，則這些幀具有更高的優先級，后面跟著一行進一步的延遲。在本文中，我們將進一步討論如果您的應用中顯示的延遲總和不可接受，可以采取哪些措施。

表的最后一部分顯示了在處理CAN通信的設備上執行各種代碼所導致的潛在處理延遲。這里我們假設使用具有集成CAN接口的現代32位MCU，運行速度為80Mhz或更快。在這種環境中，與處理CAN幀直接相關的代碼執行通常是微不足道的。潛在的延遲來自于該MCU上“發生的其他事情”。

將這些知識轉化為現實世界的系統性能需要可行的策略和考慮因素。以本系列文章第一部分中建立的基準（秒、100毫秒、10毫秒和1毫秒）為例，讓我們回顧一下優化基于CAN的系統的實用建議。

掌握響應時間為100ms的CAN應用

該領域是CAN與CANopen等高層協議協同發揮潛力的真正領域。CANopen PDO（過程數據對象）通信機制為用戶提供了靈活的控制，簡化了報文內容和觸發的配置。這些 PDO 促進節點之間的實時數據交換，優化通信效率。

對于這個響應時間，CAN ID分配和總體總線負載仍然至關重要，但并非絕對如此，因為它們不太可能導致接近100毫秒的延遲。系統架構的設計應使得即使具有最低優先級的消息也能及時訪問總線，確保它們在規定的時間范圍內傳輸。當我們探索這個中間立場時，審查潛在的高優先級消息突發變得越來越重要。連續的高優先級傳輸可能會主導總線，從而給低優先級消息帶來延遲的風險。可以采用有效的避免或控制策略（例如限制每個節點在每個時間幀可以傳輸的內容或同步觸發）來減輕這些突發，確保即使在系統擴展時也更加可預測和和諧的總線通信。

雖然許多非實時操作系統仍然可以實現100毫秒響應，但在這種情況下建議傾向于使用RTOS（如果操作系統是必需的，許多簡單的IO設備通常不具備操作系統）。使用RTOS自然可以滿足100毫秒響應窗口的要求。如果選擇非RTOS，則必須進行嚴格和擴展的測試，以確保操作系統在所有可想象的操作環境下始終滿足所需的響應時間。

在這個100毫秒響應時間框架內，軟件和固件要求仍然相對寬松。特定的優化通常是不必要的；即使在高性能環境中被認為次優的驅動程序或堆棧實現（例如，不利用CAN制器硬件功能進行高級過濾和緩沖）也能充分滿足該目的。

掌握響應時間為10ms的CAN應用

當我們進入10毫秒響應時間區時，對每個系統組件的精度和控制變得至關重要。這是對網絡數據流進行詳細審查至關重要的地方。

針對硬實時應用進行優化的時間觸發網絡通常是此類要求苛刻的場景中的首選。CANopen SYNC模式是模擬時間觸發通信系統中使用的通信行為的有效方法。通過利用SYNC觸發消息，它使特定節點能夠在精確的時刻傳輸其關聯的PDO消息，從而為系統通信帶來可預測性和一致性。

雖然實時操作系統 (RTOS) 似乎是滿足如此嚴格的時序要求的理想選擇，但它也面臨著一系列挑戰。RTOS提供一系列配置選項，管理這些任務需要仔細協調。在這短短的10毫秒窗口內，該過程涉及傳感器發送其當前數據，帶有RTOS的控制設備接收和處理該數據，然后對其采取行動。

然而，僅僅使用RTOS并不能保證達到預期的結果。任務優先級和配置必須完全符合系統嚴格的時序要求。此外，對驅動程序功能、固件和堆棧結構的詳細審查也至關重要。需要解決潛在的問題，例如優先級反轉（隊列中的低優先級消息可能會延遲高優先級消息）。高度優化的驅動程序可以解決優先級反轉問題，但這可能會導致傳輸順序發生變化。傳輸序列的變化對于某些高層協議可能會產生問題，需要仔細審查。

掌握響應時間為1ms的CAN應用

對于基于CAN的應用來說，冒險進入1ms響應時間領域就相當于踩在協議功能的邊緣。這些應用程序真正突破了界限，需要無與倫比的優化水平和對每個細節的關注。

在這個門檻上，傳統的方法和工具往往被證明是不夠的。即使是一些通常擅長管理實時任務的 RTOS，也可能很難始終遵守這個嚴格的窗口。這就需要依賴于特定于微控制器的實現，其中大多數任務直接在中斷服務例程中處理，繞過RTOS的典型層。

此級別所需的極高精度意味著許多系統配置可能需要進行硬編碼，從而可能繞過CANopen等高層協議棧，否則會延遲處理。這還有助于避免配置處理帶來的潛在延遲，確保最大程度的可預測性。必須明智地管理網絡上傳輸的每個組件、消息和字節。

考慮到嚴格的要求，如果您的應用需要1ms響應時間，那么明智的做法是檢查CAN之外的其他通信解決方案是否更適合您的需求，因為CAN應用于這個領域需要在開發時間、測試和優化方面投入大量精力。

/ 小結/

Conclusion

本文強調了CAN協議在各種響應時間要求中的適應性和功能，對于響應時間超過秒的應用程序，不太強調精確計時，并且有關CAN ID使用、采用的高層協議或所選操作系統的決策通常對性能的影響不太明顯。

然而，當我們達到100毫秒和10毫秒的更嚴格的時間限制時，系統設計考慮因素變得最重要。其中包括總線總負載、消息優先級以及CANopen SYNC模式等功能的戰略使用。在要求嚴格的1毫秒響應時間域中運行時，系統的每個元素都需要仔細關注，甚至可能會促使重新評估所選的網絡系統。

總之，了解應用需求、CAN固有優勢以及相關時間限制之間的平衡至關重要。正是這些知識使 CAN 系統設計人員能夠在不同的時間場景中做出明智的決策。

在本系列的下一篇也是最后一篇文章中，我們將深入探討技術細節，研究 CANopen 源代碼解決方案（例如Micro CANopen Plus）可用的配置和優化選項。我們將提供有關如何利用 CANopen固有優勢來滿足廣泛的實時應用需求的實用見解。最后一部分將為讀者提供切實可行的指南，幫助他們優化現實世界中的CANopen實施，以實現最短的處理時間。