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

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

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

1

CAN的實(shí)時(shí)能力

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

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

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

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

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

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

1

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

2

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

3

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

2

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

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

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

表中還顯示了潛在的傳輸延遲，并且取決于許多因素。因此，這只是針對(duì)特定用例的粗略估計(jì)，您需要根據(jù)自己的用例進(jìn)行調(diào)整。第一行顯示如果總線當(dāng)前正在使用（仲裁已經(jīng)開始，發(fā)送器來(lái)不及加入），即使是最高優(yōu)先級(jí)也會(huì)有延遲。傳輸必須等待，直到當(dāng)前幀完成。第二行顯示仲裁延遲——如果有其他設(shè)備也嘗試傳輸幀，我們需要等待多長(zhǎng)時(shí)間？此處，我們顯示了當(dāng)前待傳輸?shù)?個(gè)其他幀的延遲，如果使用節(jié)流機(jī)制來(lái)防止back-2-back傳輸，則這些幀具有更高的優(yōu)先級(jí)，后面跟著一行進(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í)行通常是微不足道的。潛在的延遲來(lái)自于該MCU上“發(fā)生的其他事情”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/ 小結(jié)/

Conclusion

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

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

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

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