虹科分享 | 平衡速度与优先级：为多样化的实时需求打造嵌入式网络（3）——CAN与CANopen的实时能力与局限性

在回顾了选择具有实时能力的嵌入式通信系统的基本要求之后，我们现在将更详细地探讨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的系统的实用建议。

掌握响应时间超过秒的CAN应用

在延迟长达数秒甚至数分钟的应用领域中，设计基于CAN的系统来满足这些响应时间并不是特别具有挑战性。有趣的是，即使是由次优驱动程序或固件负担的设备也可能仍然适用，因为即使次优驱动程序仍将在10到100毫秒内执行。

然而，当使用依赖于非实时操作系统的设备时，挑战并不在于应对通信延迟，而在于保持一致的性能并避免最坏情况下可能的延迟。定期测试和全面监控对于确保这些设备在为无缝CAN通信分配必要资源方面毫不犹豫至关重要。主动遏制任何潜在的系统中断也至关重要。简单而有效的措施，例如确保在活跃通信期间不进行更新或其他资源消耗操作，可以增强系统的响应能力和可靠性。

1）掌握响应时间为100ms的CAN应用
该领域是CAN与CANopen等高层协议协同发挥潜力的真正领域。CANopen PDO（过程数据对象）通信机制为用户提供了灵活的控制，简化了报文内容和触发的配置。这些 PDO 促进节点之间的实时数据交换，优化通信效率。

对于这个响应时间，CAN ID分配和总体总线负载仍然至关重要，但并非绝对如此，因为它们不太可能导致接近100毫秒的延迟。系统架构的设计应使得即使具有最低优先级的消息也能及时访问总线，确保它们在规定的时间范围内传输。当我们探索这个中间立场时，审查潜在的高优先级消息突发变得越来越重要。连续的高优先级传输可能会主导总线，从而给低优先级消息带来延迟的风险。可以采用有效的避免或控制策略（例如限制每个节点在每个时间帧可以传输的内容或同步触发）来减轻这些突发，确保即使在系统扩展时也更加可预测和和谐的总线通信。

虽然许多非实时操作系统仍然可以实现100毫秒响应，但在这种情况下建议倾向于使用RTOS（如果操作系统是必需的，许多简单的IO设备通常不具备操作系统）。使用RTOS自然可以满足100毫秒响应窗口的要求。如果选择非 RTOS，则必须进行严格和扩展的测试，以确保操作系统在所有可想象的操作环境下始终满足所需的响应时间。

在这个100毫秒响应时间框架内，软件和固件要求仍然相对宽松。特定的优化通常是不必要的；即使在高性能环境中被认为次优的驱动程序或堆栈实现（例如，不利用CAN制器硬件功能进行高级过滤和缓冲）也能充分满足该目的。

2）掌握响应时间为10ms的CAN应用
当我们进入10毫秒响应时间区时，对每个系统组件的精度和控制变得至关重要。这是对网络数据流进行详细审查至关重要的地方。
针对硬实时应用进行优化的时间触发网络通常是此类要求苛刻的场景中的首选。CANopen SYNC模式是模拟时间触发通信系统中使用的通信行为的有效方法。通过利用SYNC触发消息，它使特定节点能够在精确的时刻传输其关联的PDO消息，从而为系统通信带来可预测性和一致性。

虽然实时操作系统 (RTOS) 似乎是满足如此严格的时序要求的理想选择，但它也面临着一系列挑战。RTOS提供一系列配置选项，管理这些任务需要仔细协调。在这短短的10毫秒窗口内，该过程涉及传感器发送其当前数据，带有RTOS的控制设备接收和处理该数据，然后对其采取行动。

然而，仅仅使用RTOS并不能保证达到预期的结果。任务优先级和配置必须完全符合系统严格的时序要求。此外，对驱动程序功能、固件和堆栈结构的详细审查也至关重要。需要解决潜在的问题，例如优先级反转（队列中的低优先级消息可能会延迟高优先级消息）。高度优化的驱动程序可以解决优先级反转问题，但这可能会导致传输顺序发生变化。传输序列的变化对于某些高层协议可能会产生问题，需要仔细审查。

3）掌握响应时间为1ms的CAN应用
对于基于CAN的应用来说，冒险进入1ms响应时间领域就相当于踩在协议功能的边缘。这些应用程序真正突破了界限，需要无与伦比的优化水平和对每个细节的关注。

在这个门槛上，传统的方法和工具往往被证明是不够的。即使是一些通常擅长管理实时任务的 RTOS，也可能很难始终遵守这个严格的窗口。这就需要依赖于特定于微控制器的实现，其中大多数任务直接在中断服务例程中处理，绕过RTOS的典型层。

此级别所需的极高精度意味着许多系统配置可能需要进行硬编码，从而可能绕过CANopen等高层协议栈，否则会延迟处理。这还有助于避免配置处理带来的潜在延迟，确保最大程度的可预测性。必须明智地管理网络上传输的每个组件、消息和字节。

考虑到严格的要求，如果您的应用需要1ms响应时间，那么明智的做法是检查CAN之外的其他通信解决方案是否更适合您的需求，因为CAN应用于这个领域需要在开发时间、测试和优化方面投入大量精力。

总结

本文强调了CAN协议在各种响应时间要求中的适应性和功能，对于响应时间超过秒的应用程序，不太强调精确计时，并且有关CAN ID使用、采用的高层协议或所选操作系统的决策通常对性能的影响不太明显。

然而，当我们达到100毫秒和10毫秒的更严格的时间限制时，系统设计考虑因素变得最重要。其中包括总线总负载、消息优先级以及CANopen SYNC模式等功能的战略使用。在要求严格的1毫秒响应时间域中运行时，系统的每个元素都需要仔细关注，甚至可能会促使重新评估所选的网络系统。

总之，了解应用需求、CAN固有优势以及相关时间限制之间的平衡至关重要。正是这些知识使 CAN 系统设计人员能够在不同的时间场景中做出明智的决策。

在本系列的下一篇也是最后一篇文章中，我们将深入探讨技术细节，研究 CANopen 源代码解决方案（例如Micro CANopen Plus）可用的配置和优化选项。我们将提供有关如何利用 CANopen固有优势来满足广泛的实时应用需求的实用见解。最后一部分将为读者提供切实可行的指南，帮助他们优化现实世界中的CANopen实施，以实现最短的处理时间。