机器人控制器架构

编辑中未完成，禁止转载……

机器人控制器架构

2019-6-8 [email protected] 　　

　　控制器是机器人最重要的元部件，很多学者都对其进行了分析并给出了实现方案 $^{[1,2,3]}$，但是针对控制器总体架构的讨论较少，而且与工业生产一线严重脱节。本文比较了机械臂和移动机器人两种机器人的控制器方案，对其功能需求和特点进行了分析，并给出实现控制器的方案。

　 　　机械臂控制器　　　　　　　　　　　　　　　　　　　 　移动机器人控制器 　　

　　以上分类的依据是机器人类型，目前市面上更多的控制器产品是通用型运动控制器，即控制各种非标设备运动的，例如数控机床、激光切割机等大大小小的自动化设备。

通用运动控制器产品 　　

1　控制器软硬件方案

　　我们先从总体上看看现有工业机器人控制器的软硬件方案，后面再进行深入讨论。

1.1　机械臂类

  机械臂类的控制器发展较早，相对成熟，先来看看现有的控制系统底层方案。

厂家	硬件	操作系统
ABB	x86	VxWorks
KUKA	x86	VxWorks+Windows（VxWin）
KEBA	x86	VxWorks
B&R	x86	Windows 10/B&R Linux 9
固高	x86	Windows CE
MUJIN	x86	–
纳博特	x86	RT-Linux

1.2　移动机器人类

　　移动机器人的控制器属于较新的方向，工业移动机器人有AGV、无人机、无人驾驶车辆、工程机械等形式，控制系统底层方案如下：

厂家	硬件	操作系统	软件
Hesmor	Infineon XC167	无	CoDeSys
Hirschmann	PowerPC	–	CoDeSys
EPEC	Infineon C166	无	CoDeSys
NDC	ARM	RT-Linux	softPLC
IFM	Infineon TriCore 1796	无	CoDeSys

1.3　对比

　　机械臂对精度和运动稳定性的要求较高，因此计算量大、周期短，比移动机器人一般要高1到2个量级。移动机器人一般对同步精度要求不高，其配置相对较低。
　　机械臂一般工作于固定的区域，其控制器通常放置于机箱内，因此防护等级不高，一般是IP20。
　　移动机器人由于需要经常运动，尤其是室外工程机械，要考虑防水防尘，其防护等级较高，一般是IP67。

	机械臂	移动机器人
控制精度	0.01~0.2mm	0.5~20mm
控制周期	100us~1ms	10ms~100ms
插补	需要	不需要
轨迹规划	需要	不需要
逻辑控制	需要	需要

2　商业控制方案

2.1　CoDeSys

　　你会发现，很多的机器人控制软件都是借助CoDeSys实现的，那么什么是CoDeSys呢？
　　CoDeSys是3S公司推出的一款付费的软PLC开发软件，简单来说，它包括两部分：Development System和Runtime System。Development System就是用来编程的软件界面（就像Visual Studio、Eclipse等软件，也可以称为IDE），设计、调试、编译PLC程序都在IDE中进行，这部分是用户经常打交道的；PLC程序写好了以后，就要把它转移到硬件设备中运行。可是这时生成的PLC程序自己是无法运行的，它还要在一定的软件环境中才能工作，这个环境就是Runtime System，这部分是用户看不到的。二者安装的位置通常不同，IDE一般安装在开发电脑上，Runtime System则位于起控制作用的硬件设备上，二者一般使用网线连接，程序通过网线或串口线下载到Runtime中运行。

　　

　　CoDeSys在国内知名度不是特别高，但是在欧洲久负盛名，尤其在工业控制领域。我们上面提到的很多机器人公司都使用了它的产品，例如KEBA、倍福、固高，还有几乎所有的移动机器人控制器厂家。设计CoDeSys的3S公司只卖软件，不卖硬件。硬件电路需要由用户自己设计，3S公司负责将Runtime System移植到客户的硬件上。Runtime System可以裸跑在硬件上，但一般是运行在操作系统上，配置操作系统也是客户的工作。如果客户要求，CoDeSys的IDE可以定制，换成客户的logo和外观，这就是为什么你会发现不同厂家的开发平台长得不一样，但风格又比较相似。当然，用户也可以使用其它IDE，例如倍福就使用了微软的Visual Studio，而背后的编译器等内核以及函数库仍然采用CoDeSys的方案。CoDeSys的Runtime具有强大的适应性，支持绝大多数的操作系统和硬件芯片架构。

　　CoDeSys的IDE部分是免费的，你可以从其官网下载体验体验。真正收费的是运行系统Runtime System。

　　CoDeSys采用.Net技术开发。CoDeSys在设计之初就将功能划分为若干组件模块，例如总线协议栈、可视化界面、运动控制、安全控制等等，用户可以像搭积木一样选购必需的模块搭建自己的系统，最后形成一个定制化的控制软件平台。一些初次接触软PLC的用户可能对这部分感到陌生，但其实这种设计方式非常普遍。举几个例子，MATLAB Simulink的实时工具箱（Real-Time）就是这样的工作方式，用户在Simulink的图形界面里通过拖拽设计控制程序，然后下载到真实的硬件中跑，可以在这里了解。还有像倍福也是这样的使用方式，用户在TwinCAT IDE里进行编程，然后下载到倍福的控制器中，控制器里面其实已经预装了一个Runtime。西门子的STEP7也是一款IDE，它的PLC中也存在一个配套的Runtime。
　　用户编写的PLC程序就像我们电脑里的应用程序，它运行在Runtime System上，而Runtime System又运行在操作系统之上。Runtime System位于应用程序和操作系统之间，所以可以被称为中间件（Middleware）。在机器人软件里面，处于同样地位的还有ROS、OROCOS等。
　　机器人的控制，像数控机床一样，对实时性有要求，因此我们选择的操作系统最好是实时操作系统（RTOS）。遗憾的是，我们经常用的操作系统都不是实时的，例如Windows和Linux。实时操作系统有两种实现方式：
　　1. 放弃通用的操作系统，从底层重新开始设计，代表性的有VxWorks、QNX、WinCE、μC/OS、LynxOS等；这种方式的缺点是所有的任务都是实时的，即使任务本身没有实时的必要，例如网络访问、文件系统访问，因此你得专门开发适用于这种操作系统的应用程序，工作量可能比较大。
　　2. 通过对通用的操作系统打补丁（添加扩展），使其具备实时性，代表性的有Windows RTX、Xenomai、RT Linux、RTAI，这种方式的缺点是，对实时任务的支持（资源）没有第一种方式多；
　　考虑到Windows和Linux这两款操作系统的用户较多，CoDeSys推出了相应的实时补丁（RTE），为用户免去了改造的烦恼。想了解更多的CoDeSys Runtime信息可以阅读官方的文档 $[1][2]$。
　　CoDeSys runtime如果不安装在操作系统之上，则需要其自己备有简单的调度程序。CoDeSys自带的调度程序比较简单，有两种 $^{[5]}$：
　　1　Embedded Scheduler 这种是简单的轮询，一个任务结束前另一个任务不能运行，任务之间不能抢占，实际上这种方式并不是实时的；
　　2　Timer Scheduler 为每个任务分配一个定时器，定时触发；
　　CoDeSys给我们开发控制器带来了便利，省去了从零开始的麻烦，但是依靠CoDeSys这类商业软件开发自己的控制器产品也存在不少的缺点：
　　1 底层算法不公开
　　CoDeSys集成的运动控制组件、总线协议栈都是封装好的，用户无法了解其内部细节，也无法针对自己的具体需求进行定制优化，只能简单地调用。用户只能依附于CoDeSys平台，难以形成自己的核心技术。
　　2 功能有限，难以扩展
　　现在以机器视觉、人工智能、自动驾驶等为代表的新技术突飞猛进，而工业控制上的很多技术仍然停留在20年前。以移动机器人中的导航场景为例，基于视觉或者激光的导航方法需要采集大量的数据并对其进行处理，其中涉及相当多的矩阵计算。而现在PLC只能进行落后的一维数字计算，难以实现复杂的算法。与人工智能圈子喜欢开源的风格正好相反，工业控制圈子相互封闭，谁都不肯开放自家的函数库，开源函数库很少，就连最基本的滤波算法、矩阵计算都要自己从头开始写。而且，国际标准提供的基本函数太过有限，完全无法适应新的场景，急需扩展。
　　3 难以更新
　　由于完全依赖CoDeSys，客户自己产品硬件的升级换代需要重新定制移植，导致成本增加。

2.2　菲尼克斯PLCnext

　　菲尼克斯推出了新一代开放式PLC，被称为PLCnext技术。PLCnext采用通用的软硬件，例如ARM处理器和RTLinux操作系统，因此其也可视为一个软PLC安装于标准硬件平台之上。菲尼克斯收购了KW公司，KW与3S公司一样也是软PLC的供应商，所以菲尼克斯推出开放式PLC并不奇怪。PLCnext支持C/C++、IEC 61131-3标准PLC语言、Matlab等编程语言，为不同用户开发项目提供了便利。其底层是一个实时操作系统RTLinux，软PLC的runtime运行于实时系统之上，同时还允许客户运行自己的非实时应用程序，并且提供非实时应用程序于PLC实时程序的数据访问接口。开放式PLC是未来的潮流，而如果你选择西门子的PLC，想做一点扩展那绝对是连门都没有。

　

　　菲尼克斯PLCnext的核心技术体现在两个方面：任务执行管理器（ESM）和全局数据管理器（GDS）。菲尼克斯为ESM和GDS申请了专利。
　　任务执行管理器确保不同优先级的任务按照正确的优先级和时序运行，并保证低优先级的任务被抢占时数据的一致性。下图是一个简单的例子，其中有两个任务（上面一行是任务1，下面一行是任务2），任务1每5ms运行一次，它的优先级比任务2高，所以在任务2运行过程中会被任务1抢占。

　　全局数据管理器负责任务间的通信，也就是交互数据。除了任务之间，每个任务内部可能有不同语言编写的函数模块，它们之间也需要交互数据。全局数据管理保证所有的数据在交换过程中的一致性。同样是上面的例子，任务2从被抢占恢复后，数据应该与被抢占前是一样的（即绿色箭头所示的变量5和8），如果不一样就会出现所谓的“数据不一致”现象，对于实时系统这一般是不允许的。全局数据管理器的作用就是负责数据交换的一致性。

2.3　KEBA

　　KEBA的编程和控制软件全部建立在CoDeSys软PLC之上，CoDeSys为KEBA提供了基本的编辑、编译、调试等功能。CoDeSys本身与机器人相关的功能很少，因此机器人涉及的功能和函数是由KEBA开发的，以库的形式在CoDeSys中调用。为了保证实时性，控制器里的CoDeSys Runtime安装在了VxWorks之上。

　　

2.4　KUKA

　　KUKA的控制器称为KR C4，其同样采用了软PLC的方案。该方案由KW公司提供 $^{[4]}$，软PLC由IDE部分（被称为Multiprog）和Runtime（被称为ProConOS）组成。ProConOS由C#开发。ProConOS Runtime同样运行在VxWorks之上，它们安装在控制器硬件中，其硬件采用了Intel双核CPU。

　　

3　开源控制软件

　　目前存在一些开源的控制系统方案，例如ROS、Orocos、OpenRTM、Beremiz、OpenPLC、XBotCore、ArmarX、ORCA、AMiRo-OS。
　　PLCopen定义了伺服和运动控制的一些标准，包括编程语言、运动控制基础函数块（Function Block）、输入输出接口的参数等 $^{[3]}$，但是并没有给出具体的实现代码细节，这个是由各个厂家提供的。
　　
3.1　ROS

　　ROS的前身最早可以追溯到2007年斯坦福大学的博士生Eric Berger和Keenan Wyrobek的工作。虽然ROS的名字听起来像一个机器人操作系统，但严格来说它不是。ROS是一个中间件，它安装在真正的计算机操作系统之上。ROS的开发语言主要是C++。经常有人将ROS描述为软件框架或者软件平台，但笔者尽量避免使用这些抽象而且吓人的名词，因为大多数人并不熟悉机器人软件系统，它容易让本来就稀里糊涂的读者更摸不着头脑。
　　ROS提供的功能有：
　　1　节点定义和节点间的通信方式：节点只是一个模板，用户只需要将自己的算法代码添加进去，剩下的交给ROS
　　2　基本工具：机器人常用的函数库（运动规划、SLAM、逆运动学）、可视化工具、数据记录等机器人开发常用的功能
　　3　设备驱动：用户拿到硬件不再需要从零开发，节省时间
　　ROS在工业界用的并不多，这一点也不奇怪，因为它在设计之初考虑更多的是通用性和代码重用能力，不太关心可靠性、实时性等。最开始百度公司在其无人驾驶车辆上使用了ROS作为平台，当时的考虑可能是快速完成无人驾驶算法的验证。随后，意识到ROS自身的一些问题，百度无人车团队尝试对其进行改造。但是，他们最终放弃了转而选择重新搭建一套软件系统——Apollo Cyber RT。
　　ROS变得像今天这么火完全出乎设计者的意料，他们并没想到ROS会被用在各种领域的机器人。中国也有一些人计划设计自己的机器人软件系统，例如上海交通大学、北京翼辉信息技术有限公司。

3.2　Orocos

　　Orocos是一个开源的机器人实时控制软件开发系统，由比利时鲁汶大学的Herman Bruyninckx及其博士生Peter Soetens开发，编程语言为C++。 Orocos的介绍文档不全而且过于专业，缺少软件开发经验的人员很难读懂。
　　Orocos位于实时操作系统之上，提供的基本功能包括：生成实时控制程序的工具链（编译器），组件模板、机器人常用基本函数。Orocos替用户解决了模块功能和接口定义、模块间实时通信这些基本功能，借助这些软件模块，用户可以更快速的开发部署自己的应用软件。与ROS相比，Orocos在设计之初就考虑了实时性。Orocos既关注上层应用层，也关注底层控制层。在Peter Soetens的博士论文 $^{[4]}$里，对于实时性的讨论占了很大篇幅。Orocos直接使用了底层操作系统（例如Xenomai）的任务调度模块，因此Orocos必须安装在实时操作系统上才能保证实时性。

3.3　Beremiz

　　Beremiz是一个免费、开源的软PLC系统，由法国人Edouard Tisserant开发 $^{[4]}$。

　　Beremiz项目开始于2005年，最初只是一个编辑器，随后逐渐加入其它功能形成了一个完整的软PLC开发环境，其功能特点如下：
　　1　支持多任务，多任务可配置不同的优先级，任务运行方式可以是周期式或中断触发式
　　2　支持ST、梯形图等五种标准PLC编程语言
　　3　提供IEC 61131-3标准规定的基本函数（定时器、比较、数学运算、类型转换、位操作、字符串等上百个函数）
　　4　可扩展Modbus、CANopen、EtherCAT总线通讯模块（需自己移植到所选平台）
　　5　可采用C和Python编写函数和程序块
　　6　支持仿真
　　7　变量值可直观显示为图表
　　8　具有可视化界面（HMI）
　　Beremiz的组成和工作方式为：用户使用PLC语言编写应用程序，不管用户采用ST语言还是梯形图或者其它PLC语言，Beremiz都将其翻译成C语言，这是由MatIEC组件完成的。随后，gcc编译器将生成的C语言程序与总线通信程序一起编译链接得到二进制目标文件（Linux下是so文件，Windows下则是dll文件）。再之后，二进制目标文件被下载到目标设备上，目标设备上预先安装了runtime，runtime对目标文件进行调用完成相应的控制功能。

　　Beremiz的IDE和runtime两个部分的开发语言都是Python。只要可以运行Python的操作系都可以运行OpenPLC，即其可在Windows、Linux、Mac OS等多种操作系统上运行，当然前提必须得有操作系统。OpenPLC的任务调度完全依赖于操作系统，这意味着它的实时性受到操作系统的影响很大，因此最好选择实时操作系统，例如Xenomai、WinCE。
　　Beremiz的资料不多，可以参考 ${[6][7][8][9]}$。Beremiz衍生出了一些软件控制方案，例如OpenPLC、KOSMOS，在这些衍生物里更多的功能插件被加了进来，例如运动控制函数、总线通信函数、配置插件。
　　选择Python进行开发是因为这种语言简单易用，但是Python在工业控制领域很少使用，因为它无法提供实时性（受内存分配等因素影响）。即便如此， ${[10]}$对Beremiz runtime的实时性进行了分析，并与CoDeSys runtime做了对比，结果表明Beremiz的实时性反而还优于CoDeSys。这可能是由于核心程序被翻译成C代码的原因，Python编写的runtime只是负责调用。这篇文章比较了C和用Python调用C的性能，性能差距并不是特别悬殊。
　　Beremiz的介绍资料不多，并且其中一部分还是由俄文和法文。

3.4　OpenPLC

　　OpenPLC是一个免费开源的软PLC软件系统，由美国阿拉巴马大学博士生Thiago Rodrigues Alves开发 $^{[4]}$。OpenPLC修改自Beremiz项目。

3.5　对比

　　大多数软件将任务的调度交给操作系统，这就带来一个问题：对于通用的操作系统的来说，每个进程基本是相互独立的，而对于机器人应用，任务间通常是相互依赖的，这就造成了操作系统的调度程序无法用于任务有依赖的任务调度。

4　控制器的开发

　　开发机器人控制器涉及的专业较多，因此更像兵团作战，而非单兵作战。即便是精通控制算法的机器人专业的博士对于软件开发可能也一窍不通，看到进程、任务调度、软件框架这些计算机名词头也大；而训练有素的软件工程师对于齐次变换矩阵、旋量、插补这些概念则是大眼瞪小眼；除此以外，项目还需要驱动工程师、硬件工程师，还要有工程师懂总线通信、熟悉工艺应用。如果想找业务能力扎实的员工，就要承担高昂的成本，没有诱惑力的工资是很难留住这些专业人士的。更何况中国的机器人教育其实还是相当落后的，能找到专业能力扎实的员工并不容易。
　　由于开发机器人控制器成本高而且困难，大部分的厂家会选择在别人的基础上开发。

4.1　控制器方案的选择

　　单CPU还是多CPU？
　　早期CPU的计算能力较弱，为了提高运行速度，不得不采用多CPU方案，一些计算量大的任务被剥离出来独占一个CPU。比较有代表性的就是各种控制板卡的方案，例如PMAC、固高。固高的GUC-ECAT控制器单独设计了一个DSP和一个FPGA来执行插补、轨迹规划等任务，另一个CPU一般执行非实时的人机交互，编程开发等任务。如果你拆开固高的机器人控制器，就会发现它有两个核心（TI DSP和Intel CPU），就像游戏电脑会有独立的显卡一样。当然，多一个核总没有坏处，比如NI的机器人控制器roboRIO除了有ARM核还带了一个FPGA，可以想象它的数据采集会比较快。也难怪它被用在了对控制和采样速率要求较高的场合，例如MIT的四足机器人（用的是NI cRIO-9082）。

　　随着CPU计算能力的提升，单CPU方案的性能越来越强，因此以后的机器人控制器一般只使用一个CPU就够了，所有的实时和非实时任务都运行在这一个CPU上，由操作系统进行调度。
　　操作系统还是裸跑？
　　一般认为操作系统会导致额外的开销，毕竟上下文切换需要时间，但是半导体技术和软件技术的进步已经使这个差别非常小了。程序裸跑在硬件上适合比较简单、逻辑不复杂的应用场合，但是其缺点也是显而易见的，如果升级或者改变硬件平台，程序就要重写。所以现在的机器人（尤其是机械臂、无人驾驶汽车）控制器无一例外都使用了操作系统。
　　半成品软件还是软PLC？
　　ROS和OROCOS是半成品，它们更适合学术研究，需要用户对整个系统比较熟悉才能使用，对用户的编程能力有较高的要求，一般用在产品还没有定型的阶段或者用户不需要经常变换应用任务的场合。例如无人驾驶就可以用，因为无人驾驶的整个业务逻辑和任务基本不会有大的变动。
　　而软PLC自带IDE，用户可以直接在IDE中直观地编写自己的应用程序。如果自带的函数不够用，用户再去底层实现自己的函数。开发效率更高，使用更友好。因此，现在的机器人控制器都会采用软PLC的实现方式。
　　笔者研究生毕业最早接触的机器人控制器不管看起来还是用起来都像个PLC，这让我很恼火。因为PLC是低级的玩意，它的编程语言居然是梯形图这种看起来像小学生比赛一样的东西，而且除了一些基本的函数，其它的什么都没有，做个矩阵计算什么的想都别想。我想PLC应该是给刚从技校毕业的中专生准备的，它完全配不上我，我需要的更高级的东西。
　　是的，PLC编程简单而且皮实耐用，这是它设计的目的，但是机器人正在变得越来越不简单，更多的功能被加入进来，机器视觉、自主导航、运动规划、多轴运动控制，这些要求控制器提供更强大的支撑，而不仅仅是原始的逻辑逻辑控制或者简单的数值计算。所以，对于机器人控制来说，传统PLC应该被淘汰了。
　　我们需要的控制器软件应该足够开放，允许用户随时调整程序结构、加入新的功能，同时它自身应该提供足够的底层基础函数，例如线性代数、数学优化、插值拟合、方程求解、甚至图像处理、运动控制。在使用方式上，为了兼顾客户（不能要求所有客户都能自己开发高级功能），它还是尽量简单好，最好与PLC的使用差别不大。

4.2　实时性

　　开发机器人控制器是个繁重的工作，要明确一系列性能要求，首先就是实时性。
　　实时性对于工业机器人来说一般是必须的，对于服务或娱乐机器人则未必。一般人很容易错把“实时性”理解为处理或者响应速度快，但其实“实时性”表示时间上的“确定性”，例如实时操作系统（RTOS）中的中断响应或者进程切换的延迟时间一定是在一个时间范围内，我们常用的操作系统（Windows、Linux）都不是实时操作系统，因为它们设计的出发点是吞吐量，不能保证每个事件都在一定范围内得到处理。这并不难理解，虽然Windows不是实时的，但是也不至于那么不确定，一般慢个几十毫秒人根本感觉不到。再比如，标准以太网的传输速度比实时工业以太网（比如EtherCAT）快多了，但是标准以太网却不是实时的，因为它同样不能保证数据在给定的时间内完成传输。
　　理解实时性不太难，但是影响实时性的因素有哪些呢？这方面讨论涉及操作系统和计算机硬件原理，各大机器人厂家肯定不会公开自己的测试和试验结果。一个评价实时性的指标是jitter，jitter受到操作系统调度算法的影响很大，其它的例如系统负载也有影响，调度算法的影响大概是十微妙级的。jitter对机器人性能的影响不容易量化，因为中间环节有些复杂（底层伺服闭环）。

4.3　高精度定时器

　　我们经常提到“实时”，实时需要高精度的时间标准，那么谁来提供这个高精度的时间呢？答案就是时钟周期，它是是实时操作系统的心跳（或者脉搏）。周期性采集数据、任务定时切换、延时输出，这些功能都要求实时操作系统必须要有一个稳定的时钟周期来作为整个系统的时间标准。
　　什么是时钟周期呢？时钟周期依赖一个定时器，它是个函数，其本质是一个计数器。定时器开始预先存储一个值，每次硬件（例如晶振）产生一个脉冲，就将这个值减一，减到0时再重置为初始值，同时产生一个中断，这个特定的周期性的中断称为“时钟周期”（Tick，有的也叫“时钟节拍”、“心跳”或“滴答”）。举个例子，假如晶振的频率是72MHz，则时钟周期（Clock Period）就是1/72M，如果预先存储的值是72000，那么时钟节拍就是1/72M $\times$ 72000= 0.001s，也就说1ms产生一个中断，此时控制器无法分辨低于1ms的时间间隔。

5　参考资料
　　　　
[1]　机器人控制器的现状及展望，范永，谭民，机器人，1999.
[2]　开放式机器人控制器综述，孙斌，杨汝请，机器人，2001.
[3]　Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography，Ayssam Elkady，Journal of Robotics，2012.
https://zhuanlan.zhihu.com/p/28052497
[4]　CODESYS Control V3 Manual, Document Version 19.0.
[5]　CODESYS Control V3 Migration and Adaptation, Document Version 4.0.
[6]　Robots Count on Software，KW-Software.
[6]　https://www.plcopen.org/technical-activities/motion-control
[7]　A Software Framework for Real-Time and Distributed Robot and Machine Control，Peter Soetens，Ph.D. thesis，2016.
[8]　An Open Source IEC 61131-3 Integrated Development Environment，Edouard Tisserant，IEEE，2007.
[9]　OPC UA support for Beremiz softPLC，Martim Afonso，2018.
[10]　An Open-source Development Environment for Industrial Automation with EtherCAT and PLCopen Motion Control，I. Kim，IEEE ETFA，2013.
[11]　Conception and Implementation of a Secure Engineering and Key Exchange Mechanism for the Open Source PLC Beremiz using a Test Driven Approach，M A Rahman，2016.
[12]　Can We Use Beremiz Real-time Engine for Robot Programmable Logic Controller，S Chu，CACS，2015.
[13]　OpenPLC - A fully open source controller An open source platform for PLC research，https://motion.control.com/thread/1464718978
[14]　OpenPLC: An Open Source Alternative to Automation，Thiago Rodrigues Alves，IEEE Global Humanitarian Technology Conference，2014.
[15]　工业机器人控制器开放性、实时性分析方法以及单处理器模式下的实现，博士学位论文，谈世哲，2002.
[16]　Bare-Metal, RTOS, or Linux? Optimize Real-Time Performance with Altera SoCs，Chee Nouk Phoon，2014.
[17]　Real-time Operating System Timing Jitter and its Impact on Motor Control，F. M. Proctor，SPIE，2001.