选择争论一直存在

大家知道EtherCAT是实时现场总线技术，当我们开发一款支持EtherCAT总线的控制器时，实时操作系统的选择不仅对于产品本身是最重要的一部分，而且对产品研发的整个过程也影响深远。

根据EtherCAT主站提供商Acontis公司对全球新客户的情况统计，选择实时Linux系统的客户比重在过去10年逐年增加，Acontis公司2019年所有新客户中采用实时Linux作为控制器操作系统的比例已超过60%。

从近几年的经验中，我们注意到一些客户对实时性的理解存在偏差和误区。此外，对于实时Linux系统的选择，主要是采用Preempt RT还是Xenomai存在大量争论。结合我们在以往项目中的经验以及实时Linux系统专家Jan Altenberg 2015年在Embedded Linux会议上的讲演，我们整理出此文。希望可以帮助大家理解实时性，同时对在Preempt RT和Xenomai之间做出合适的选择提供参考。

 

什么是“实时性”

我们在和客户的交流中注意到，部分工程师会把实时性与执行速度或性能相混淆。Altenberg在讲演中特别强调：实时性与执行速度和性能无关！

无论是实时操作系统还是实时现场总线，实时性的含义不是越快越好，而是在规定的时间内完成任务的确定性(Determinism and Timing Guarantees)。如果我们给实时性下定义，那么实时性就是关于时间的确定性。

实时性的一个重要特点，是在规定的时间段内完成规定的任务。在技术讨论中，有时客户对EtherCAT协议不存在对错误数据自动重传的机制有疑问，很显然是忽略了实时性的这一特性。EtherCAT主站的工作原理，是按时间段（循环周期）发送数据。每个循环周期内的过程数据(Process Data)，只在这个周期内到达从站才有意义，因此EtherCAT在协议层面不会自动在后续周期重新发送之前周期发送失败的过程数据。

在Embedded Linux会议讲演中，Altenberg还表述了一个很有趣的观点，他希望大家忘掉“软实时”（即Soft Real Time的提法），只存在实时和非实时的、确定性和非确定性的区别。能保证确定性，那就是“硬实时”(Hard Real Time)。

Xenomai和Preempt RT实现原理

目前，对实时Linux方案的选择主要在Xenomai和Preempt RT之间。Xenomai是在Linux Kernel外增加独立的微内核的双内核方案，而Preempt RT是标准的单内核实时方案。

Xenomai的实时应用运行在微内核中，而把Linux系统作为微内核的一个低优先级任务。与RTAI不同，Xenomai实时性在用户空间实现。当高优先级的实时应用程序不在微内核运行时，Linux才有可能获得运行时间。下图是以Xenomai为代表的双内核方案的原理图。

图 1 Xenomai双内核方案原理图

Altenberg认为双内核实时方案有几个明显不足。首先，维护工作量大。由于Linux不是直接在硬件上运行，因此Xenomai在维护微内核的同时还需要维护硬件抽象层HAL层，这导致Xenomai的更新速度通常会比主线Linux落后一步。其次，不能使用标准C库。Xenomai实时应用的开发需要特殊的工具和库以及单独的API。

主流的实时Linux方案是基于Preempt RT的单内核方案，通过最大限度地提高Linux内核中的可抢占部分，使Linux本身具备实时性。下图为Premept RT单内核原理图。

图 2 Preempt RT单内核方案原理图

由于大约80%的Preempt RT功能已经融合进Linux主线，因此任何Linux开发者都可以使用Preempt RT的Linux内核组件。Preempt RT不仅仅把Linux变成实时系统，同时提高了Linux的稳定性。Preempt RT被广泛接受并拥有庞大的社区，开发者不需要深入了解Preempt RT，而是使用标准C库开发实时应用。开发者不需要深入了解Preempt RT，而是使用标准C库开发实时应用。Preempt RT就是Linux系统，Preempt RT的实时应用也是Linux的应用。

随着剩下的20%功能逐渐融入Linux主线，未来有可能不需要在Linux安装补丁程序而直接使用Preempt RT。

 

Xenomai和Preempt RT性能对比

实时性能最重要的指标是延时的大小。网上有不少流传很广的文章，表示Xenomai在延迟方面有优势。Altenberg并不认同这种观点，他认为之所以得出这样的结论，是对Preempt RT的错误配置造成的。

为了确切证实，他们的团队分别找了Xenomai和Preempt RT专家，在相同的硬件平台上进行了测试。测试对象是高负载下Xenomai和Preempt RT在延时Latency和抖动Jitter两个方面的表现情况。

Altenberg强调了两点，第一是测试的最坏结果才有意义。另外一点是系统拿到中断后，在用户空间的应用响应延时是对应用最有意义的。

在用户空间的测试结果，Xenomai和Preempt RT最坏延时都在90-95微秒左右。当在Linux系统中只使用单核测试时，Preempt RT最坏的延时只有大约80微秒，结果优于Xenomai。

在Kernel空间延时的测试结果，Xenomai最高延时在30微秒，单核运行Preempt RT的最高延时60微秒。如果使用FIQ快速中断的话，Preempt RT的最坏延时也可达到30微秒，平均延时甚至到达10微秒。

 

专家观点

盟通指出：测试表明，对于开发人员最有意义的用户空间内最坏延时方面，两种实时方案在该性能指标上展示出近乎相同的数据。

但是Preempt RT几乎已经和Linux内核主线合并，从系统的开发和维护角度，Preempt RT的工作量与标准Linux相同。这使Preempt RT与Xenomai相比具备更多优势，例如工程师开发更简单、产品生命周期更长、系统维护工作更容易等。

 

实时系统工业平台，尽在创龙科技

创龙科技很多ARM嵌入式处理器平台已支持Preempt RT与Xenomai实时拓展，主要平台如下。更多型号或细节内容，欢迎与我们联系。

图 3 创龙科技Linux实时系统平台支持列举

版权声明：本文主要内容基于“北京盟通科技有限公司”授权提供的文件，由“创龙科技”进行整理得出。感谢“盟通科技”的慷慨支持，让更多人了解Linux系统的“实时拓展”选择知识。