基于CAN總線系統(tǒng)的時間動態(tài)：CAN與CANopen的實時能力與局限性

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

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

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

1

CAN的實時能力

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

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

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

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

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

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

1

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

2

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

3

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

2

掌握基于CAN總線系統(tǒng)的時間動態(tài)

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

傳輸延遲的大致數(shù)據(jù)

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

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

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

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

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

對于這個響應時間，CAN ID分配和總體總線負載仍然至關重要，但并非絕對如此，因為它們不太可能導致接近100毫秒的延遲。系統(tǒng)架構(gòu)的設計應使得即使具有最低優(yōu)先級的消息也能及時訪問總線，確保它們在規(guī)定的時間范圍內(nèi)傳輸。當我們探索這個中間立場時，審查潛在的高優(yōu)先級消息突發(fā)變得越來越重要。連續(xù)的高優(yōu)先級傳輸可能會主導總線，從而給低優(yōu)先級消息帶來延遲的風險?？梢圆捎糜行У谋苊饣蚩刂撇呗裕ɡ缦拗泼總€節(jié)點在每個時間幀可以傳輸?shù)膬?nèi)容或同步觸發(fā)）來減輕這些突發(fā)，確保即使在系統(tǒng)擴展時也更加可預測和和諧的總線通信。

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

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

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

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

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

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

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

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

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

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

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

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

/ 小結(jié)/

Conclusion

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

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

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

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