編輯中未完成，先不要轉載……
工業機器人控制器
如同大腦之於人一樣，控制器也是機器人最重要的元部件，它定義了機器人的功能和行爲。很多學者都對其進行了研究或給出了實現方案，但是針對控制器總體架構的討論較少，而且坐井觀天，與工業生產一線嚴重脫節。本文比較了機械臂和移動機器人兩種工業機器人的控制器方案，對其功能需求和特點進行了分析，並探討開放式控制器的實現方案。
1 軟硬件方案
我們首先考察常見工業機器人控制器的軟硬件方案。
1.1 機械臂
機械臂控制器的發展較早，產品相對成熟，其實現方案見下表。國際一線品牌大多采用X86芯片，並採用實時操作系統構造底層軟件。
| 廠家 | 硬件 | 操作系統 |
|---|---|---|
| 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 | VxWorks 或 Linux（PREEMPT_RT）或 SylixOS |
1.2 移動機器人
移動機器人的控制器屬於較新的方向，AGV、無人機、工程機械等都可歸於此類，最近比較火的無人駕駛也可以認爲是一種移動機器人，其控制系統底層方案見下表。
| 廠家 | 硬件 | 操作系統 | 軟件 | 外部接口 |
|---|---|---|---|---|
| Hesmor | Infineon XC167 | 無 | CoDeSys | CAN |
| Hirschmann | PowerPC | 無 | CoDeSys | CAN |
| EPEC | Infineon C166 | 無 | CoDeSys | CAN |
| NDC | ARM Cortex-A8 | Linux | – | 內置陀螺儀、CAN、WLAN、485 |
| IFM | Infineon TriCore 1796 | 無 | CoDeSys | CAN |
1.3 對比
機械臂的功能要求多，自由度多，而且對運動精度和響應速度的要求較高，比移動機器人一般要高1到2個數量級，因此控制器的計算量大、週期短；移動機器人一般對響應速度要求不高，功能相對簡單，其配置相對較低，而且移動機器人通常採用電池供電，控制器內置，因此對功耗和散熱有要求，其控制器多采用嵌入式芯片。
機械臂一般工作於固定的區域，其控制器通常放置於機箱內，因此防護等級不高，一般是IP20；移動機器人由於需要經常運動，尤其是室外工程機械，要考慮防水防塵，其防護等級較高，一般是IP65。
| 機械臂 | 移動機器人 | |
|---|---|---|
| 控制精度 | 0.01~0.5mm | 1~20mm |
| 控制週期 | 100us~10ms | 10ms~100ms |
| 插補 | 需要 | 不需要 |
| 軌跡規劃 | 需要 | 不需要 |
| 邏輯控制 | 需要 | 需要 |
2 商業控制器
介紹幾種有代表性的商業控制器方案。
2.1 CoDeSys
很多機器人控制軟件都是藉助CoDeSys實現的，那麼CoDeSys是什麼呢？
CoDeSys是德國3S公司推出的一款付費的軟PLC開發軟件，簡單來說，它包括兩部分：Development System和Runtime System。Development System就是用來編程的軟件界面（就像Visual Studio、Eclipse等軟件，也可以稱爲IDE），設計、調試、編譯PLC程序都在IDE中進行，這部分是用戶經常打交道的；程序寫好了以後，就要把它轉移到硬件設備中執行。可是這時生成的PLC程序自己是無法運行的，它還要在一定的軟件環境中才能工作，這個環境就是Runtime System（也叫運行核），這部分是用戶看不到的。二者安裝的位置通常不同，IDE一般安裝在用戶的開發計算機上，Runtime System則位於起控制作用的硬件設備上，程序通過網線或串口線下載到Runtime中運行。
CoDeSys在工業控制領域的應用非常廣泛，上面提到的很多機器人公司都使用了它的產品，例如KEBA、倍福、固高、臺達、廣州啓帆機器人、新時達機器人。3S公司只賣底層軟件，不賣硬件和上層應用程序，應用程序和硬件電路需要由用戶自己設計，3S公司負責將Runtime System移植到客戶的硬件上。Runtime System可以裸跑在硬件上，但一般是運行在操作系統上，配置操作系統也是客戶的工作。如果客戶要求，CoDeSys的IDE可以定製，換成客戶的logo和外觀，這就是爲什麼你會發現不同廠家的開發平臺長得不一樣，但風格又比較相似。當然，用戶也可以使用其它IDE，例如倍福就使用了Visual Studio，而背後的編譯器等內核功能以及函數庫仍然採用CoDeSys的方案。CoDeSys的Runtime具有強大的適應性，支持絕大多數的操作系統和芯片類型。
CoDeSys的IDE部分是免費的，你可以從官網下載體驗。真正收費的是運行系統Runtime System以及一系列的通信、運動控制組件。
CoDeSys採用.Net技術開發，其在設計之初就將功能劃分爲若干組件模塊，例如總線協議棧、可視化界面、運動控制、安全控制等等，用戶可以像搭積木一樣選購必需的模塊搭建自己的系統，最後形成一個定製化的控制軟件平臺。一些初次接觸軟PLC的用戶可能對這部分感到陌生，但其實這種設計方式非常普遍。舉幾個例子，MATLAB Simulink的實時工具箱（Real-Time）就是這樣的工作方式，用戶在Simulink的圖形界面裏通過拖拽設計控制程序，然後下載到真實的硬件中跑，可以在這裏瞭解。還有像倍福也是這樣的使用方式，用戶在TwinCAT IDE裏進行編程，然後下載到倍福的控制器中，控制器裏面其實已經預裝了一個Runtime。西門子的STEP7也是一款IDE，它的PLC中也存在一個配套的Runtime。只不過西門子（包括日系PLC）的系統封閉而保密，外人不知道他的系統架構。
用戶編寫的PLC程序就像我們電腦裏的應用程序，它運行在Runtime System上，而Runtime System又運行在操作系統之上。由於Runtime System位於應用程序和操作系統中間，所以又被稱爲中間件（Middleware）。簡單來說，你可以把中間件看成是由驅動程序、基本的函數庫等等模塊組成的軟件系統。因爲這些程序模塊主要與硬件或者底層軟件打交道，與用戶關係不大，所以被組織成了單獨的一塊。這些軟件呈現給用戶的是函數調用接口，也就是說你只需要會使用就行了，不用操心具體怎麼實現，因爲這些是驅動工程師和算法工程師的活兒。當然，大多數時候你也看不到這部分的具體實現，因爲它們是以編譯後的二進制文件的形式提供給你的，根本無法閱讀，你頂多能看到一些頭文件，其中只是一些函數和變量定義，沒有什麼乾貨。在機器人軟件裏面，處於同樣地位的還有ROS、OROCOS等。
機器人的控制，像數控機牀一樣，對實時性有要求，因此我們選擇的操作系統最好是實時操作系統（RTOS）。遺憾的是，我們經常用的操作系統都不是實時的，例如Windows和Linux。實時操作系統有兩種實現方式：
1. 放棄通用的操作系統，從底層重新開始設計，代表性的有VxWorks、QNX、WinCE、μC/OS、LynxOS等；這種方式的缺點是所有的任務都是實時的，即使任務本身沒有實時的必要，例如網絡訪問、文件系統訪問，因此你得專門開發適用於這種操作系統的應用程序，工作量可能比較大。VxWorks在軍事和工業應用較多，例如被應用於戰鬥機和火箭上。VxWorks留下了一個空白，這就是車載領域，現在這個市場被QNX佔據了。
2. 通過對通用的操作系統打補丁（添加擴展），使其具備實時性，代表性的有Windows RTX、Xenomai、RT Linux、RTAI，這種方式的缺點是，對實時任務的支持（資源）沒有第一種方式多；
考慮到Windows和Linux這兩款操作系統的用戶較多，CoDeSys推出了相應的實時補丁（RTE），爲用戶免去了改造的煩惱。想了解更多的CoDeSys Runtime信息可以閱讀官方的文檔。
CoDeSys runtime如果不安裝在操作系統之上，則需要其自己備有簡單的調度程序。CoDeSys自帶的調度程序比較簡單，有兩種：
1 Embedded Scheduler 這種是簡單的輪詢，一個任務結束前另一個任務不能運行，任務之間不能搶佔，實際上這種方式並不是實時的；
2 Timer Scheduler 爲每個任務分配一個定時器，定時觸發；
CoDeSys給機器人廠家開發控制器帶來了便利，但是依靠CoDeSys這類商業軟件打造自己的控制器產品也存在不少的缺點：
1 底層算法不公開
CoDeSys集成的運動控制組件、總線協議棧都是封裝好的，用戶無法瞭解其內部細節，也無法針對自己的具體需求進行定製優化，只能簡單地調用。用戶只能依附於CoDeSys平臺，難以形成自己的技術。
2 功能有限，難以擴展
現在以機器視覺、人工智能、自動駕駛等爲代表的新技術突飛猛進，而工業控制上的很多技術仍然停留在20年前。以移動機器人中的導航場景爲例，基於視覺或者激光的導航方法需要採集大量的數據並對其進行處理，其中涉及相當多的矩陣計算。而現在PLC只能進行落後的一維數字計算，難以實現複雜的算法。與人工智能圈子喜歡開源的風格正好相反，工業控制圈子相互封閉，誰都不肯開放自家的函數庫，開源函數庫很少，就連最基本的濾波算法、矩陣計算都要自己從頭開始寫。而且，國際標準IEC提供的標準函數太過有限，完全無法適應新的場景，急需擴展。
3 成本高、難以更新
商業軟PLC成本動不動幾十萬，這還不包括各種總線通信庫、運動控制庫、專有函數庫，它們仍需單獨購買，而且需要從售出產品上提成，對於小團隊來說成本難以接受。由於完全依賴CoDeSys，客戶自己產品硬件的升級換代需要重新定製移植，導致成本增加。
GEB Automation也推出了與CoDeSys類似的軟PLC，支持編程、調試、仿真，面向OEM的產品售價9500美元，比CoDeSys好的是一次性付費不再收取單機提成，可以移植到常用的硬件平臺，其IDE基於Eclipse開發。
2.2 菲尼克斯PLCnext
2019年菲尼克斯高調推出了新一代PLC，被稱爲PLCnext技術。PLCnext採用通用的軟硬件，例如ARM處理器和RTLinux操作系統，因此其也可視爲一個軟PLC安裝於標準硬件平臺之上，而PLCnext在中間層仍然採用了KW的軟運行核。PLCnext支持C/C++、IEC 61131-3標準PLC語言、Matlab等編程語言，爲不同用戶開發項目提供了便利。PLCnext底層是一個實時操作系統RTLinux，其上允許客戶運行自己的非實時應用程序，並且提供非實時應用程序於PLC實時程序的數據訪問接口。開放式PLC是未來的潮流，可以看到PLCnext符合這一趨勢，反之如果你用西門子的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公司提供，軟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.1 ROS
ROS的前身最早可以追溯到2007年斯坦福大學的博士生Eric Berger和Keenan Wyrobek的工作，主要開發語言是C++。雖然ROS的名字聽起來是一個機器人操作系統，但其實它不是。ROS是一箇中間件，它安裝在真正的計算機操作系統之上。剛開始，ROS有點像一個大雜燴，包括一些通信用的組件、可視化和仿真組件、座標系管理組件。很多人將ROS描述爲軟件框架，但筆者儘量避免使用這些抽象而又嚇人的名詞，因爲大多數人並不熟悉機器人軟件系統，它容易讓本來就稀裏糊塗的讀者更摸不着頭腦。
ROS提供的功能有：
1 節點定義和節點間的通信方式：節點是一個應用程序模板，用戶將自己的算法代碼添加進去，剩下的交給ROS
2 基本工具：機器人常用的函數庫（運動規劃、SLAM、逆運動學）、可視化工具、數據記錄等機器人開發常用的功能
3 設備驅動：用戶拿到硬件不再需要從零開發，節省時間
ROS在工業界用的並不多，這一點也不奇怪，因爲它在設計之初考慮更多的是通用性和代碼重用能力，不太關心可靠性、實時性等。最開始百度公司在其無人駕駛車輛上使用了ROS作爲平臺，當時的考慮可能是快速完成無人駕駛算法的驗證。隨後，意識到ROS自身的一些問題，百度無人車團隊嘗試對其進行改造。但是，他們最終放棄了轉而選擇重新搭建一套軟件——Apollo Cyber RT。
ROS變得像今天這麼火完全出乎設計者的意料，他們並沒想到ROS會被用在各種各樣的機器人上。中國也有一些人計劃設計自己的機器人軟件系統，例如上海交通大學中國科學院的micROS。
3.2 Orocos
Orocos是一個開源的機器人控制程序開發軟件，由比利時魯汶大學的Herman Bruyninckx及其博士生Peter Soetens開發，編程語言爲C++。 Orocos的介紹文檔偏軟件開發，非程序員不容易讀懂。
Orocos的地位與ROS有些類似，但定位於控制，其位於實時操作系統之上，提供的基本功能包括：生成實時控制程序的工具鏈（編譯器），組件模板、機器人常用基本函數。Orocos替用戶解決了模塊功能和接口定義、模塊間實時通信這些基本功能，藉助這些軟件模塊，用戶可以更快速的開發部署自己的應用軟件。Orocos既關注上層應用層，也關注底層控制層。與ROS相比，Orocos在設計之初就考慮了實時性。在Peter Soetens的博士論文裏，對於實時性的討論佔了很大篇幅。Orocos直接使用了底層操作系統（例如Xenomai）的任務調度模塊，因此Orocos必須安裝在實時操作系統上才能保證實時性。
3.3 Beremiz
Beremiz是一個免費、開源的軟PLC控制系統，由法國人Edouard Tisserant開發，主要開發語言是Python。出於對傳統PLC壁壘森嚴的不滿，Tisserant倡導了開源項目Beremiz，他也是CANfestival的作者。
Beremiz項目始於2005年，雛形只是一個編輯器，隨後其它功能逐漸加入從而形成了一個完整的軟PLC開發環境，其功能特點如下：
1 支持多任務，多任務可配置不同的優先級，任務運行方式可以是週期式或中斷觸發式
2 支持ST、梯形圖等五種標準PLC編程語言
3 提供IEC 61131-3標準規定的基本函數（定時器、比較、數學運算、類型轉換、位操作、字符串等上百個函數）
4 可擴展Modbus、CANopen、EtherCAT總線通訊模塊（需自己移植到所選平臺）
5 支持C和Python語言，用戶可以在PLC中調用C程序或者調用Python程序，也可以在Python中調用C程序
6 支持仿真，但是不支持在線調試
7 具有可視化界面（HMI），變量值可直觀顯示爲圖表
Beremiz的工作方式爲：用戶使用PLC語言編寫應用程序，不管用戶採用ST語言還是梯形圖或者其它PLC語言，Beremiz都將其翻譯成C語言，這是由MatIEC組件完成的。隨後，gcc編譯器將生成的C語言程序與總線通信程序一起編譯鏈接得到二進制目標文件（Linux下是so文件，Windows下則是dll文件）。再之後，二進制目標文件被下載到目標設備上，目標設備上預先安裝了runtime，runtime對目標文件進行調用完成相應的控制功能。
Beremiz的IDE和runtime兩個部分的開發語言都是Python。只要可以運行Python的操作系都可以運行Beremiz，即其可在Windows、Linux、Mac OS等多種操作系統上運行，當然前提必須得有操作系統。Beremiz的任務調度完全依賴於操作系統，這意味着它的實時性受到操作系統的影響很大，因此最好選擇實時操作系統，例如Xenomai、WinCE。
Beremiz衍生出了一些軟件控制方案，例如OpenPLC、KOSMOS，在這些衍生物裏更多的功能插件被加了進來，例如運動控制函數、總線通信函數、配置插件。
選擇Python進行開發是因爲這種語言簡單易用，但是Python在工業控制領域很少使用，因爲它無法提供實時性（受內存分配等因素影響）。即便如此，對Beremiz runtime的實時性進行了分析，並與CoDeSys runtime做了對比，結果表明Beremiz的實時性反而還優於CoDeSys。這可能是由於核心程序被翻譯成C代碼的原因，Python編寫的runtime只是負責調用。這篇文章比較了C和用Python調用C的性能，性能差距並不是特別懸殊。
Beremiz的介紹資料很少，並且其中一部分還是由俄文和法文撰寫的，缺少深入探討內部原理的文獻。
3.4 OpenPLC
OpenPLC是一個免費開源的軟PLC軟件系統，它由Beremiz項目衍生而來，由美國阿拉巴馬大學博士生Thiago Rodrigues Alves開發。
3.5 對比
大多數軟件將任務的調度交給操作系統，這就帶來一個問題：對於通用的操作系統的來說，每個進程基本是相互獨立的，而對於機器人應用，任務間通常是相互依賴的，這就造成了操作系統的調度程序無法用於任務有依賴的任務調度。
4 控制器的開發
機器人控制器開發涉及的專業衆多，需要一個團隊完成。精通控制算法的機器人專業的博士對於軟件開發可能也一竅不通，看到進程、任務調度、mutex這些計算機名詞頭大；訓練有素的軟件工程師對於齊次變換矩陣、旋量這些概念則是一頭霧水；除此以外，項目還需要驅動工程師、硬件工程師，還要有工程師懂總線通信、熟悉工藝。如果想找業務能力紮實的員工，就要承擔高昂的成本，沒有誘惑力的工資是很難留住這些專業人士的。更何況中國的機器人教育其實還是相當落後的，能找到專業能力紮實的員工並不容易。筆者撰寫本文的初衷也是爲了向各方普及基礎知識，剷平知識不對稱的大山。
由於開發機器人控制器成本高而且困難，大部分的廠家會選擇在別人的基礎上開發。
4.1 控制器方案的選擇
單處理器還是多處理器？
早期CPU的計算能力較弱，爲了提高運行速度，不得不採用多CPU方案，一些計算量大的任務被剝離出來獨佔一個CPU。比較有代表性的就是各種控制板卡的方案，例如PMAC、固高。固高的GUC-ECAT控制器單獨設計了一個DSP和一個FPGA來執行插補、軌跡規劃等任務，另一個CPU一般執行非實時的人機交互，編程開發等任務。如果你拆開固高的機器人控制器，就會發現它有兩個計算核心（Intel CPU和 DSP/FPGA），就像遊戲電腦會有獨立的顯卡一樣。當然，多一個核總沒有壞處，比如NI的機器人控制器roboRIO除了有ARM核還帶了一個FPGA，可以想象它的數據採集會比較快。也難怪它被用在了對控制週期和採樣速率要求較高的場合，例如MIT的四足機器人（用的是cRIO-9082）。
隨着CPU核心數量增加和計算能力的提升，單CPU的性能越來越強，因此機器人控制器只使用一個CPU就夠了，所有的實時和非實時任務都運行在這一個CPU上，由操作系統進行調度。
操作系統還是裸跑？
一般認爲操作系統會導致額外的開銷，畢竟上下文切換需要時間，但是半導體技術和軟件技術的進步已經使這個差別非常小了。程序裸跑在硬件上適合比較簡單、邏輯不復雜的應用場合，但是其缺點也是顯而易見的，如果升級或者改變硬件平臺，程序就要重寫。所以現在的機器人（尤其是機械臂、無人駕駛汽車）控制器無一例外都使用了操作系統。
半成品軟件還是軟PLC？
ROS和OROCOS是半成品，它們更適合學術研究，需要用戶對整個系統比較熟悉才能使用，對用戶的編程能力有較高的要求，一般用在產品還沒有定型的階段或者用戶不需要經常變換應用任務的場合。例如無人駕駛可以使用，因爲無人駕駛的整個業務邏輯和任務基本不會有大的變動。正如手機或者汽車行業，廠家不會把電路板或者底盤直接賣給客戶，因爲客戶不會使用。面向終端客戶的產品必須要考慮產品本身的易用性和客戶的能力。所以如果你的產品面向的是沒有研發能力的終端客戶，必須要有規範易用的編程界面和簡潔高效的編程語言，這是ROS或OROCOS這種軟件所不具備的。
而軟PLC自帶IDE，用戶可以直接在IDE中直觀地編寫自己的應用程序。如果自帶的函數不夠用，用戶再去底層實現自己的函數。開發效率更高，使用更友好。因此，現在的機器人控制器都會採用軟PLC的實現方式。
筆者研究生畢業最早接觸的機器人控制器不管看起來還是用起來都像個PLC，這讓我很惱火。因爲PLC是低級的玩意，它的編程語言居然是梯形圖這種看起來像小學生比賽一樣的東西，而且除了一些基本的函數，其它的什麼都沒有，做個矩陣計算什麼的想都別想。
是的，PLC編程簡單而且皮實耐用，這是它設計的目的，但是機器人正在變得越來越不簡單，更多的功能被加入進來，機器視覺、自主導航、運動規劃、多軸運動控制，這些要求控制器提供更強大的支撐，而不僅僅是低端的邏輯控制或者簡單的數值計算。所以，對於機器人控制來說，傳統的硬PLC應該被淘汰了。
我們需要的控制器軟件應該足夠開放，允許用戶隨時調整程序結構、加入新的功能，同時它自身應該提供足夠的底層基礎函數，例如線性代數、數學優化、插值擬合、方程求解、甚至圖像處理、運動控制。在使用方式上，爲了兼顧客戶（不能要求所有客戶都能自己開發高級功能），它還是儘量簡單好，最好與PLC的使用差別不大。
4.2 實時性
開發機器人控制器是個繁重的工作，要明確一系列性能要求，首先就是實時性。
如果問PLC或者機器人控制器與普通計算機的本質區別是什麼，你會如何回答？是PLC更穩定嗎，還是它的抗干擾能力更強、又或者是接口更豐富、或是編程語言更符合工業控制。筆者認爲這些都不是，真正本質的區別在於PLC是實時的，而普通計算機不是實時的。家用電腦的信息處理能力可以輕鬆甩出PLC幾條街（想想你玩大型遊戲或者看高清視頻的計算量），那麼爲什麼工業上還是使用“落後的”PLC呢？答案就是實時性，實時性對於工業機器人來說是必須的（至於服務機器人筆者認爲可以不強求）。一般人很容易錯把“實時性”理解爲計算速度快或者響應延時短，但其實“實時性”表示時間上的“確定性”，例如實時操作系統（RTOS）中的中斷響應或者進程切換的延遲時間一定是在一個時間範圍內，我們常用的操作系統（Windows、Linux）都不是實時操作系統，因爲它們設計的出發點是大吞吐量，不能保證每個事件都在一定範圍內得到處理。再比如，標準以太網的傳輸速度比實時工業以太網（比如EtherCAT）快多了，但是標準以太網卻不是實時的，因爲它同樣不能保證數據在確定的時間內完成傳輸。
以上都是定性的描述，能不能定量說明呢？當然了，確定性肯定是有具體指標的，脫離具體數字分析實時性沒有意義。如果我們將反應時間規定爲1個小時，那麼就連Windows這樣的操作系統也是實時的了，因爲它響應再慢也不會花一個小時。工業上很多場合1個小時顯然是太誇張了，我們至少要縮小到10ms這樣的量級，例如一個控制或插補週期執行時間不能超過1ms，這樣Windows系統肯定滿足不了要求。最近炒的比較火的5G通信技術可以將延時控制在1ms左右，雖然它也不是實時的，但是由於速度足夠快所以也可以用於工業控制領域取代有線通信，這就是爲什麼5G這麼火的原因。
理解實時性不太難，但是影響實時性的因素有哪些呢？這方面討論涉及操作系統原理，各大機器人廠家肯定不會公開自己的測試和試驗結果。評價實時性的主要指標是latency和jitter，jitter受到操作系統調度算法的影響很大，其它的例如系統負載也有影響，調度算法的影響大概是十微妙級的。jitter對機器人性能的影響不容易量化，因爲中間環節有些複雜（底層伺服閉環）。
影響實時性的另一個主要因素是內存分配。動態內存的分配耗時非常不確定，這也是爲什麼很多實時系統都避免採用動態內存。這裏我舉兩個例子：
1. 在PLC中不提供動態數組，只能用定長數組，也就是說使用之前必須先分配好數組長度。這顯然很不方便，例如我們有時在函數調用時傳遞一個數組，而事先並不想考慮數組的大小。這樣一來，我們只好計算好每次傳遞的數組長度，或者設置一個儘量大的數組，顯然這會造成空間的浪費。
2. 如果你有過在MATLAB Simulink中編寫S函數或者用戶自定義函數的經歷，你就會發現，S函數中要求你在使用變量之前必須先進行定義或分配空間，不能像在m文件中一樣不事先定義就賦值（可以看這個MATLAB自帶的例子：Integrate MATLAB Algorithm in Model）。因爲Simulink中的模塊是可以生成C語言並導出到硬件上直接運行的，這意味着它對實時性有要求。一些PLC，例如前面提到的菲尼克斯和倍福，都支持將Simulink中仿真好的控制模型直接生成爲控制程序，而無需重新編程。難怪我們在Simulink中編寫S函數的時候總感覺不像在MATLAB寫程序那麼自由隨意。
4.3 高精度定時器
我們經常提到“實時”，實時需要高精度的時間標準，那麼誰來提供這個高精度的時間呢？答案就是時鐘週期，它是是實時操作系統的心跳（或者脈搏）。週期性採集數據、任務定時切換、延時輸出，這些功能都要求實時操作系統必須要有一個穩定的時鐘週期來作爲整個系統的時間標準。
什麼是時鐘週期呢？時鐘週期依賴一個定時器，它是個函數，其本質是一個計數器。定時器開始預先存儲一個值，每次硬件（例如晶振）產生一個脈衝，就將這個值減一，減到0時再重置爲初始值，同時產生一箇中斷，這個特定的週期性的中斷稱爲“時鐘週期”（Tick，有的也叫“時鐘節拍”、“心跳”或“滴答”）。舉個例子，假如晶振的頻率是72MHz，則時鐘週期（Clock Period）就是1/72M，如果預先存儲的值是72000，那麼時鐘節拍就是1/72M 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.