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

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

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

1

CAN的實(shí)時能力

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

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

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

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

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

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

1

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

2

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

3

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

2

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

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

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

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

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

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

掌握響應(yīng)時間為100ms的CAN應(yīng)用

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

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

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

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

掌握響應(yīng)時間為10ms的CAN應(yīng)用

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

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

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

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

掌握響應(yīng)時間為1ms的CAN應(yīng)用

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

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

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

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

/ 小結(jié)/

Conclusion

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

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

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

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