點擊藍(lán)字 關(guān)注我們
前言
Preface
在前文中，我們探討了具有實時能力的嵌入式通信系統(tǒng)的基本要求——平衡實時響應(yīng)、安全性和保障。本篇文章將重點介紹CAN與CANopen的實時能力和局限性。
前文回顧
虹科干貨 | 平衡速度與優(yōu)先級：為多樣化的實時需求打造嵌入式網(wǎng)絡(luò)（1）——選擇正確的實時范圍
虹科干貨 | 平衡速度和優(yōu)先級：為多樣化的實時需求打造嵌入式網(wǎng)絡(luò)（2）——實時通信系統(tǒng)的需求
控制器局域網(wǎng)(CAN)協(xié)議是各個行業(yè)眾多應(yīng)用的基礎(chǔ)，每個應(yīng)用都有其獨特的實時需求。CANopen和J1939等著名示例強調(diào)了該協(xié)議的多種適應(yīng)性，以滿足特定需求。值得注意的是，這些應(yīng)用程序的實時要求并不全面統(tǒng)一。雖然某些應(yīng)用程序需要以毫秒為單位的反應(yīng)時間，但許多其他應(yīng)用程序可以在更寬松的標(biāo)準(zhǔn)下有效運行。物理約束、網(wǎng)絡(luò)拓?fù)浜陀嬎闳蝿?wù)等因素在形成這些需求方面發(fā)揮著至關(guān)重要的作用。當(dāng)我們探索更嚴(yán)格的實時約束時，通信配置和代碼處理的復(fù)雜性就會增加。然而，當(dāng)實時要求更加寬松時，它為更簡單、更精簡的系統(tǒng)設(shè)計提供了機會，而無需犧牲功能或可靠性。
盡管安全性和保障都得到了解決（通過CANopen Safety和CANcrypt），但目前還沒有提供這兩者的標(biāo)準(zhǔn)化解決方案。CiA用戶組目前擁有多個工作組，負(fù)責(zé)審查CAN、CAN FD和CAN XL安全通信的各個方面。
1
CAN的實時能力
CAN的實時性與其通信速度密切相關(guān)，并進(jìn)一步受到其基于優(yōu)先級的仲裁機制的影響。計算CAN幀傳輸時間并不是一項簡單的任務(wù)；時間取決于數(shù)據(jù)字節(jié)數(shù)及其內(nèi)容。這種復(fù)雜性的出現(xiàn)是因為可以根據(jù)幀的數(shù)據(jù)將填充位添加到幀中。因此，以下確定的值應(yīng)被視為近似值，提供當(dāng)前范圍的一般意義。
重要的是要記住，您的最大比特率還取決于布線的物理拓?fù)洌⑶腋鶕?jù)您的應(yīng)用，單個控制周期所需的總傳輸可能包括兩條傳輸路徑：一條用于將數(shù)據(jù)輸入到控制單元，另一條用于從控制單元到輸出。
雖然本文重點關(guān)注CAN，但以下大多數(shù)注意事項也適用于CAN FD（靈活數(shù)據(jù)速率）和CAN XL變體。這兩種協(xié)議都具有雙比特率機制，進(jìn)一步增強了它們的數(shù)據(jù)吞吐能力。然而，在討論與時序相關(guān)的動態(tài)時，大多數(shù)考慮因素主要適用于“標(biāo)稱比特率”。這一基本比特率本質(zhì)上確定了仲裁、確認(rèn)和錯誤信令等控制信息的速度。對于使用CAN FD和CAN XL的用戶來說，了解控制實際數(shù)據(jù)傳輸?shù)摹皵?shù)據(jù)相位比特率”帶來的額外復(fù)雜性至關(guān)重要。這些系統(tǒng)中的關(guān)鍵問題之一是確定長消息可能占用總線的最大持續(xù)時間，以及與最長的8字節(jié)經(jīng)典CAN幀相比，該延遲可能要長多少。
CAN的最大速度為1Mbps，允許在一毫秒內(nèi)交換十多個幀。相反，在125kbps的適度速率下，平均約為每毫秒一幀。除了傳輸時間之外，如果隊列中有更高優(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ù)交換一致且及時。
單獨觀察CAN（以及FD和XL變體），很明顯原本它不是確定性的。產(chǎn)生高優(yōu)先級幀的單個設(shè)備可能會阻止所有其他設(shè)備的通信。為了使CAN具有確定性，我們需要確保受控幀被觸發(fā)——何時可以使用哪個CAN ID。要激活CAN的實時功能，請考慮以下設(shè)計目標(biāo)。雖然這些指南可能會根據(jù)應(yīng)用程序的具體情況而有所不同，但它們可以作為可靠的起點：
1
旨在將總體總線負(fù)載保持在一個水平，即使是低優(yōu)先級幀也有足夠的時間訪問總線。雖然確切的閾值可能因應(yīng)用程序而異，但我最初的建議是保持在75%以下的總線負(fù)載（如果通信純粹基于狀態(tài)更改，則總線負(fù)載會更少）。
2
確保沒有單個節(jié)點可以生成連續(xù)消息的擴展流。一些驅(qū)動程序提供傳輸“節(jié)流閥”來限制最大傳輸速率。
3
對于那些需要對傳輸時序和源進(jìn)行更精細(xì)控制的人，請考慮CANopen的SYNC模式。該模式支持觸發(fā)消息，提供對傳輸調(diào)度的增強控制，允許類似于時間觸發(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。事實上，即使在較低的比特率下，我們?nèi)匀辉谡務(wù)撁棵霛撛诘臄?shù)千個CAN幀，這一事實永遠(yuǎn)不會讓我感到驚訝。通信的空間如此之大，人們可以輕松掌握，通過一些關(guān)于如何使用所有這些“空間”的明確定義的參數(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é)流機制來防止back-2-back傳輸，則這些幀具有更高的優(yōu)先級，后面跟著一行進(jìn)一步的延遲。在本文中，我們將進(jìn)一步討論如果您的應(yīng)用中顯示的延遲總和不可接受，可以采取哪些措施。
表的最后一部分顯示了在處理CAN通信的設(shè)備上執(zhí)行各種代碼所導(dǎo)致的潛在處理延遲。這里我們假設(shè)使用具有集成CAN接口的現(xiàn)代32位MCU，運行速度為80Mhz或更快。在這種環(huán)境中，與處理CAN幀直接相關(guān)的代碼執(zhí)行通常是微不足道的。潛在的延遲來自于該MCU上“發(fā)生的其他事情”。
將這些知識轉(zhuǎn)化為現(xiàn)實世界的系統(tǒng)性能需要可行的策略和考慮因素。以本系列文章第一部分中建立的基準(zhǔn)（秒、100毫秒、10毫秒和1毫秒）為例，讓我們回顧一下優(yōu)化基于CAN的系統(tǒng)的實用建議。
掌握響應(yīng)時間為100ms的CAN應(yīng)用
該領(lǐng)域是CAN與CANopen等高層協(xié)議協(xié)同發(fā)揮潛力的真正領(lǐng)域。CANopen PDO（過程數(shù)據(jù)對象）通信機制為用戶提供了靈活的控制，簡化了報文內(nèi)容和觸發(fā)的配置。這些 PDO 促進(jìn)節(jié)點之間的實時數(shù)據(jù)交換，優(yōu)化通信效率。
對于這個響應(yīng)時間，CAN ID分配和總體總線負(fù)載仍然至關(guā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é)點在每個時間幀可以傳輸?shù)膬?nèi)容或同步觸發(fā)）來減輕這些突發(fā)，確保即使在系統(tǒng)擴展時也更加可預(yù)測和和諧的總線通信。
雖然許多非實時操作系統(tǒng)仍然可以實現(xiàn)100毫秒響應(yīng)，但在這種情況下建議傾向于使用RTOS（如果操作系統(tǒng)是必需的，許多簡單的IO設(shè)備通常不具備操作系統(tǒng)）。使用RTOS自然可以滿足100毫秒響應(yīng)窗口的要求。如果選擇非RTOS，則必須進(jìn)行嚴(yán)格和擴展的測試，以確保操作系統(tǒng)在所有可想象的操作環(huán)境下始終滿足所需的響應(yīng)時間。
在這個100毫秒響應(yīng)時間框架內(nèi)，軟件和固件要求仍然相對寬松。特定的優(yōu)化通常是不必要的；即使在高性能環(huán)境中被認(rèn)為次優(yōu)的驅(qū)動程序或堆棧實現(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)重要的地方。
針對硬實時應(yīng)用進(jìn)行優(yōu)化的時間觸發(fā)網(wǎng)絡(luò)通常是此類要求苛刻的場景中的首選。CANopen SYNC模式是模擬時間觸發(fā)通信系統(tǒng)中使用的通信行為的有效方法。通過利用SYNC觸發(fā)消息，它使特定節(jié)點能夠在精確的時刻傳輸其關(guān)聯(lián)的PDO消息，從而為系統(tǒng)通信帶來可預(yù)測性和一致性。
雖然實時操作系統(tǒng) (RTOS) 似乎是滿足如此嚴(yán)格的時序要求的理想選擇，但它也面臨著一系列挑戰(zhàn)。RTOS提供一系列配置選項，管理這些任務(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)（隊列中的低優(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)的方法和工具往往被證明是不夠的。即使是一些通常擅長管理實時任務(wù)的 RTOS，也可能很難始終遵守這個嚴(yán)格的窗口。這就需要依賴于特定于微控制器的實現(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之外的其他通信解決方案是否更適合您的需求，因為CAN應(yīng)用于這個領(lǐng)域需要在開發(fā)時間、測試和優(yōu)化方面投入大量精力。
/ 小結(jié)?/
Conclusion
本文強調(diào)了CAN協(xié)議在各種響應(yīng)時間要求中的適應(yīng)性和功能，對于響應(yīng)時間超過秒的應(yī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)時間域中運行時，系統(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)化選項。我們將提供有關(guān)如何利用 CANopen固有優(yōu)勢來滿足廣泛的實時應(yīng)用需求的實用見解。最后一部分將為讀者提供切實可行的指南，幫助他們優(yōu)化現(xiàn)實世界中的CANopen實施，以實現(xiàn)最短的處理時間。
虹科是一家在工業(yè)自動化領(lǐng)域，特別是工業(yè)總線通訊行業(yè)經(jīng)驗超過15年的高科技公司。我們始終致力于為行業(yè)客戶提供創(chuàng)新及前端的產(chǎn)品和技術(shù)解決方案，幫助客戶輕松實現(xiàn)工業(yè)連接，為科技社會發(fā)展助力加碼。
推薦閱讀
2023-10-24
2023-10-26
2023-10-12
2023-10-10
2023-01-10
