商业控制器
CoDeSys
很多机器人控制软件都是借助CoDeSys实现的，那么CoDeSys是什么呢？
CoDeSys是德国3S公司推出的一款付费的软PLC开发软件，简单来说，它包括两部分：DevelopmentSystem和Runtime System。DevelopmentSystem就是用来编程的软件界面（就像VisualStudio、Eclipse等软件，也可以称为IDE），设计、调试、编译PLC程序都在IDE中进行，这部分是用户经常打交道的；程序写好了以后，就要把它转移到硬件设备中执行。可是这时生成的PLC程序自己是无法运行的，它还要在一定的软件环境中才能工作，这个环境就是RuntimeSystem（也叫运行核），这部分是用户看不到的。二者安装的位置通常不同，IDE一般安装在用户的开发计算机上，RuntimeSystem则位于起控制作用的硬件设备上，程序通过网线或串口线下载到Runtime中运行。
CoDeSys为什么要分成两部分？Zui主要的原因是CoDeSys主要运行在嵌入式系统中，例如ARM或者DSP芯片。这样的系统资源有限，不可能在其上建立庞大、复杂的开发环境，因而其开发环境和运行环境相互分离。因此，嵌入式软件的开发方式一般是，在宿主机（Host）上建立开发环境，进行应用程序代码的编写和交叉编译，然后宿主机与目标机（Target）建立连接，将应用程序下载到目标机上进行交叉调试，经过调试和优化，Zui后将应用程序固化到目标机中实际运行。当然，随着芯片的性能越来越强大，如果选择资源丰富的芯片，那么CoDeSys的开发环境和运行环境放在一起也没什么问题。我们自己的个人电脑不就是编译和运行程序都能完成吗。
CoDeSys在工业控制领域的应用非常广泛，上面提到的很多机器人公司都使用了它的产品，例如KEBA、倍福、固高、台达、广州启帆机器人、新时达机器人。3S公司只卖底层软件，不卖硬件和上层应用程序，应用程序和硬件电路需要由用户自己设计，3S公司负责将RuntimeSystem移植到客户的硬件上。RuntimeSystem可以裸跑在硬件上，但一般是运行在操作系统上，配置操作系统也是客户的工作。如果客户要求，CoDeSys的IDE可以定制，换成客户的logo和外观，这就是为什么你会发现不同厂家的开发平台长得不一样，但风格又比较相似。当然，用户也可以使用其它IDE，例如倍福就使用了VisualStudio，而背后的编译器等内核功能以及函数库仍然采用CoDeSys的方案。CoDeSys的Runtime具有强大的适应性，支持绝大多数的操作系统和芯片类型。
CoDeSys的IDE部分是免费的，你可以从官网下载体验。真正收费的是运行系统RuntimeSystem以及一系列的通信、运动控制组件。
CoDeSys采用.Net技术开发，其在设计之初就将功能划分为若干组件模块，例如总线协议栈、可视化界面、运动控制、安全控制等等，用户可以像搭积木一样选购必需的模块搭建自己的系统，Zui后形成一个定制化的控制软件平台。一些初次接触软PLC的用户可能对这部分感到陌生，但其实这种设计方式非常普遍。举几个例子，MATLABSimulink的实时工具箱（Real-Time）就是这样的工作方式，用户在Simulink的图形界面里通过拖拽设计控制程序，然后下载到真实的硬件中跑，可以在这里了解。还有像倍福也是这样的使用方式，用户在TwinCATIDE里进行编程，然后下载到倍福的控制器中，控制器里面其实已经预装了一个Runtime。西门子的STEP7也是一款IDE，它的PLC中也存在一个配套的Runtime。只不过西门子（包括日系PLC）的系统封闭而保密，外人不知道他的系统架构。
用户编写的PLC程序就像我们电脑里的应用程序，它运行在Runtime System上，而RuntimeSystem又运行在操作系统之上。由于Runtime System位于应用程序和操作系统中间，所以又被称为中间件（Middleware）。简单来说，你可以把中间件看成是由驱动程序、基本的函数库等等模块组成的软件系统。因为这些程序模块主要与硬件或者底层软件打交道，与用户关系不大，所以被组织成了单独的一块。这些软件呈现给用户的是函数调用接口，也就是说你只需要会使用就行了，不用操心具体怎么实现，因为这些是驱动工程师和算法工程师的活儿。当然，大多数时候你也看不到这部分的具体实现，因为它们是以编译后的二进制文件的形式提供给你的，根本无法阅读，你顶多能看到一些头文件，其中只是一些函数和变量定义，没有什么干货。在机器人软件里面，处于同样地位的还有ROS、OROCOS等。
1、开发层
CODESYS DevelopmentSystem（具有完善的在线编程和离线编程功能）、编译器及其配件组件、可视化界面编程组件等，同时供用户可选的运动控制模块可使其功能更加完整和强大。
IEC 61131-3 编辑器。CODESYS提供了所有IEC61131-3所以定义的五种编程语言：如结构化文本（ST）、顺序功能图（SFC）、功能块图（FBD）、梯形图（LD）和指令表，此外还支持连续功能图（CFC）的编程语言。
编译器：负责将CODESYS中的应用程序转换为机器代码并且优化可编程控制器的性能。当用户输入了错误的应用程序代码时，立刻会接收到编译器发出的语法错误警告及错误信息，让编程人员可以迅速做出相应纠正。用户可以不必改变编程方式，就可以使用不同的基于CODESYS 编程的硬件装置（系统）进行工程开发。
硬件/现场总线配置器：针对不同制造商的硬件设备及不同现场总线协议，该部分负责在CODESYS中对相应参数进行设定。
可视化界面编程：直接在CODESYS 中即可实现可视化编程（人机界面HMI），系统已经集成了可视化编辑器。
运动控制模块：运动控制功能已经集成在CODESYS中，形成了SoftMotion(CNC)软件包。基于PLCopen的工具包可以实现单轴、多轴运动；电子凸轮传动；电子齿轮传动；复杂多轴CNC控制等。
2、通信层
应用开发层和硬件设备层之间的通讯是由CODESYS中的网关服务器来实现的，CODESYS网关服务器中安装了OPC服务器。
CODESYS网关服务器。作用在应用开发层和硬件设备层之间，可以使用TCP/IP协议或通过CAN等总线实现远程访问，是CODESYS开发工具包不可分割的一部分。
CODESYS OPC服务器。对基于CODESYS进行编程的控制器，无需考虑所使用的硬件CPU，已经集成并实现了OPCV2.0规范的多客户端功能，且能同时访问多个控制器。
3、设备层
在使用基于IEC61131-3标准的编程开发工具CODESYS对一个硬件设备进行操作前，硬件供应商必须要在设备层预先安装CODESYS的实时核（CODESYSRuntime）。同时，也可以通过使用CODESYS的可选组件：如CODESYS目标可视化编程模块或网络可视化编程模块来实现功能上的扩展。
4、CODESYS软件架构中各层关系
CODESYS代码执行机制是编译执行，用户在开发层编写完成的IEC程序通过集成的编译器编译为二进制代码，再通过以太网或串口下载至设备层中，Zui终该应用程序中的文件已经被转为二进制代码存放在目标设备中，根据用户设定的执行方式循环执行对应程序。
机器人的控制，像数控机床一样，对实时性有要求，因此我们选择的操作系统zuihao是实时操作系统（RTOS）。遗憾的是，我们经常用的操作系统都不是实时的，例如Windows和Linux。实时操作系统有两种实现方式：
1.放弃通用的操作系统，从底层重新开始设计，代表性的有VxWorks、QNX、WinCE、μC/OS、LynxOS等；这种方式的缺点是所有的任务都是实时的，即使任务本身没有实时的必要，例如网络访问、文件系统访问，因此你得专门开发适用于这种操作系统的应用程序，工作量可能比较大。VxWorks在军事和工业应用较多，例如被应用于战斗机和火箭上。VxWorks留下了一个空白，这就是车载领域，现在这个市场被QNX占据了。
2.通过对通用的操作系统打补丁（添加扩展），使其具备实时性，代表性的有Windows RTX、Xenomai、RTLinux、RTAI，这种方式的缺点是，对实时任务的支持（资源）没有第一种方式多；
考虑到Windows和Linux这两款操作系统的用户较多，CoDeSys推出了相应的实时补丁（RTE），为用户免去了改造的烦恼。想了解更多的CoDeSysRuntime信息可以阅读官方的文档。
CoDeSysruntime如果不安装在操作系统之上，则需要其自己备有简单的调度程序。CoDeSys自带的调度程序比较简单，有两种：
1 Embedded Scheduler这种是简单的轮询，一个任务结束前另一个任务不能运行，任务之间不能抢占，实际上这种方式并不是实时的；
2 Timer Scheduler 为每个任务分配一个定时器，定时触发；
CoDeSys给机器人厂家开发控制器带来了便利，但是依靠CoDeSys这类商业软件打造自己的控制器产品也存在不少的缺点：
1 底层算法不公开
CoDeSys集成的运动控制组件、总线协议栈都是封装好的，用户无法了解其内部细节，也无法针对自己的具体需求进行定制优化，只能简单地调用。用户只能依附于CoDeSys平台，难以形成自己的技术。
2 功能有限，难以扩展
现在以机器视觉、人工智能、自动驾驶等为代表的新技术突飞猛进，而工业控制上的很多技术仍然停留在20年前。以移动机器人中的导航场景为例，基于视觉或者激光的导航方法需要采集大量的数据并对其进行处理，其中涉及相当多的矩阵计算。而现在PLC只能进行落后的一维数字计算，难以实现复杂的算法。与人工智能圈子喜欢开源的风格正好相反，工业控制圈子相互封闭，谁都不肯开放自家的函数库，开源函数库很少，就连Zui基本的滤波算法、矩阵计算都要自己从头开始写。而且，guojibiaozhunIEC提供的标准函数太过有限，完全无法适应新的场景，急需扩展。
3 成本高、难以更新
商业软PLC成本动不动几十万，这还不包括各种总线通信库、运动控制库、可视化库，这些仍需单独购买，而且需要从售出产品上提成，对于小团队来说成本难以接受。由于完全依赖CoDeSys，客户自己产品硬件的升级换代需要重新定制移植，导致成本增加。这让笔者想起来曾经微软给手机打造的操作系统WindowsPhone，微软在移动端是如何一步步作死的呢？其中关键的一条就是向手机厂商收取高额的授权费，可能微软当大爷当惯了，而且更不要脸的是给用户设置障碍，同一款手机系统不能连续升级。
GEBAutomation也推出了与CoDeSys类似的软PLC，支持编程、调试、仿真，面向OEM的产品售价9500美元，比CoDeSys好的是一次性付费不再收取单机提成，可以移植到常用的硬件平台，其IDE基于Eclipse开发。