基于双核处理器平台的数控系统软件架构设计*

郑玉虎，王 品，陆小虎

(1.中国科学院大学，北京 100039;2.中国科学院 沈阳计算技术研究所，沈阳 110168;3.沈阳高精数控技术有限公司，沈阳 110168)

0 前言

随着数控系统的不断发展，控制周期越来越短，控制精度越来越高，控制算法越来越复杂，要同时运行的功能模块也越来越多，这都对当前普遍采用的单核处理器平台提出了严峻的挑战。要在单核平台上提高现有数控系统的性能或者集成更多的应用，主要可以从以下方面考虑：一是采用更高性能的单核处理器，二是优化现有数控系统的软件架构，三是从各个细节上着手优化具体的代码和算法。但是这几种方法都面临着各种不同的困难。比如第一种方法，一般情况下性能或主频的提升往往伴随着功耗和发热的增加，而数控系统的特点决定了其功耗不能太高，用于散热装置的空间有限，在这些约束下单核处理器的性能提升是有限的，因此这种方法有一定的局限性。

本文主要采用双核处理器平台以解决前述问题。使用双核处理器只需额外增加少量硬件和软件设计工作，即可使系统性能有很大的提升，一些专门针对双核处理器设计的软件的性能提升甚至能接近两倍。本文基于该平台，借鉴开源EMC2数控系统的软件设计，研究了双核平台上的数控软件设计方案，并提出在类似平台上进行数控软件设计和优化的一般方法(同样适用于有超过两个核心的多核处理器)。

1 双核处理器的硬件结构

1.1 缓存结构

高速缓存(这里只考虑L2 Cache)是衡量处理器性能的一个极其重要的指标，其容量大小以及采用的架构对处理器性能有很大的影响。根据与核心的对应关系以及缓存间的通信方式，可以分为共享缓存和独立缓存，图1显示了本文所采用的基于独立缓存的双核处理器的结构。

图1 独立缓存结构的CPU

图中处理器有两个核心Core0和Core1，每个核心有各自的L2 Cache，两个核心之间通过总线接口连接到前端总线。两个核心可以同时各执行一个任务，当两边缓存需要保持一致性时则通过前端总线进行通信。程序运行时的局部性好坏会影响缓存命中率［7］，因此应该把重要的实时任务安排到一个固定的核心上，并防止其他无关任务挤占对应的缓存，这样可以提高实时任务运行速度和实时性。

1.2 中断管理

中断处理会对程序的运行速度和实时性产生影响。高频率外部中断会不停地打断正常的程序执行流，如果中断处理程序也比较耗时，就可能会导致实时任务在运行过程中不断被打断和推迟，超过要求的时间限度。目前在中断管理上普遍采用可编程中断控制器，可以通过编程的方式控制每个核心上的中断响应，比如可以在某个核心上开启或者关闭某个中断。这样就可以在运行重要实时任务的核心上关闭无关的中断，避免了实时任务被频繁打断，保证了任务的性能和实时性。

2 双核平台需要的软件支持

2.1 操作系统支持

要发挥双核处理器的性能优势，需要操作系统的密切配合。数控系统设计中应用较多的实时系统有RTAI、RTLinux和VxWorks等，这些系统提供的实时控制功能大同小异，本文采用的系统平台是RTCore(前身是RTLinux Pro)。

RTCore是一款硬实时系统，采用了“双内核”［9］结构。实时内核运行在最底层，直接管理时钟和硬件中断。实时任务运行在实时内核层，而Linux作为一个最低优先级任务运行，只有当前没有实时任务需要占用处理器时，才会调度Linux系统运行。RTCore支持SMP对称多处理平台，提供了丰富的实时进程调度、进程通信和中断管理等功能，可以满足在双核处理器平台上设计数控系统的需求。

2.2 应用程序的支持

仅有硬件和操作系统的支持还不够，要充分利用多核平台的性能优势，还需要应用程序本身的支持。在这方面可以采用的方法主要是多线程编程，把原来由一个线程串行处理的工作交由多个线程并行处理，可以大幅度提高处理速度。

除了多线程技术，多核处理器上的软件开发还有一些其他需要考虑的问题。比如对实时性有要求的应用，可以采用线程-处理器绑定、处理器预留和中断屏蔽等技术，提高应用的性能和实时性。

3 单核平台上的数控软件架构

3.1 EMC2数控软件架构

EMC2开放数控系统的软件架构主要由四个功能模块组成(图2)。其中运动控制器(MOTION)完成轴的插补和伺服控制，对响应时间要求很高，作为一个硬实时任务运行;PLC控制离散IO，也作为硬实时任务运行;任务控制器(TASK)和人机操作界面(HMI)则完成对系统整体运行的操作和控制，作为非实时任务运行。

图2 EMC2软件架构

在运行RTCore系统的单核处理器上，任意时刻只有一个线程在CPU上运行，RTCore会按照设定的调度策略优先调度上述两个实时模块运行，当所有实时模块的时间片消耗完而被内核中断或者完成一个周期循环并主动放弃处理器进入休眠以后，实时内核会调度Linux运行非实时线程。

3.2 单核平台上存在的问题

在基于单核处理器的数控系统中，当实时模块数量增加，或者单个实时模块CPU占用时间过长，或者出现高频率中断，都可能会导致各种问题。比如CPU占用率过高，多个周期实时线程无法合理调度，这将导致某些实时任务尚未完成就被迫让出处理器，或者某些任务长时间占用处理器而影响其他实时任务的执行，实时性和可靠性受到影响。

同样，对于运行于Linux中的非实时任务，当加入的监控、调试等数控实用程序增多时，这些任务要共享分配给Linux的CPU时间，可能会出现严重的延时执行问题，比如人机界面反应迟钝、Linux中断处理过度延时或丢失数据等问题。

通过采用双核处理器，可以把负载按照一定的要求均衡地分布到两个核心上，避免负载增大导致的实时性和可靠性问题。

4 双核平台上的数控软件线程模型

PLC和MOTION模块中实际执行实时控制任务的是若干个实时线程。当实时模块加载入RTCore时，会创建实时线程，这些实时线程按照规定的周期进行循环，每次循环中执行一些操作然后休眠。PLC中有两个低优先级实时线程，TaskThread用来执行用户逻辑程序，PLCThread用来刷新IO。MOTION模块中有一个高优先级实时线程emcmotTask，用来执行插补和轨迹规划等任务。下面主要从缓存局部性、任务可调度性和负载均衡的角度研究双核平台上数控系统软件的线程模型。

4.1 直接转到双核平台上运行

几乎不用做太大改动就可以直接把原有的单核平台上的软件代码拿到双核平台上运行。在这种情况下，RTCore会采用默认的调度策略在两个核心上调度所有的实时任务运行，当所有的实时任务运行完毕或者进入休眠状态时才调度Linux运行。任务和核心之间是随机分配的关系。但是这样就无法充分利用缓存局部性特点，不能充分发挥双核处理器的性能优势。

4.2 实时和非实时任务分派到不同核心上

可以直接把实时和非实时任务分开各占用一个核心(图3)。在这种分派下，MOTION和PLC中的实时线程一直在Core1上运行，而非实时模块和Linux中其他进程则在Core0上运行。这样Core1的缓存中存放的始终是实时线程的代码和数据，因Linux被分派到Core1上而导致的缓存失效次数大大减少了，同时由于实时调度器的开销减小了，因而实时任务的调度延迟也缩短了。另一方面，Core0大部分处理时间分配给Linux，加快了Linux进程的运行速度，缩短了响应时间。这也意味着可以往Linux中添加更多的应用程序，而不会导致性能下降。

图3 实时与非实时分开处理的架构

在RTCore中创建实时线程之前可以设置运行该线程的核心，同时采用处理器预留技术把该核心预留给实时应用，这样就可以把实时和非实时部分隔离到不同的核心上。

4.3 关于任务的可调度性问题

采用线程绑定和处理器预留技术可以直接把模块按照实时和非实时分配到两个核心上运行，但是具体实现上还有一些需要深入考虑的问题。比如多个周期性实时线程能否在单个核心上合理调度?如果能合理调度的话，这两个核心上的负载分配如何?前一个问题就是任务的可调度性问题，后面一个就是负载均衡问题。

针对实时任务的可调度性问题，目前应用最广泛的是速率单调(简称RM)算法［1］，该算法适用于可抢占静态优先级周期性实时任务的调度。理想的RM算法模型基于一系列假设，而本文所采用的数控系统实现从一定程度上满足这些假设条件，因此可以直接使用RM算法对可调度性进行判定。

RM算法的可调度性判定公式为：

其中n为周期线程的数目，Ci是线程i的周期内最大运行时间，Ti是线程i的周期。只要某核心上所有的实时线程满足上面的条件，就是可调度的。本文采用的数控软件在某种参数配置下的线程时间如下。

表1 线程参数1

如果把这三个实时线程都放到同一个核心上，用RM算法判定结果是U=0.6215＜0.7798，满足可调度性条件，所有实时线程可以按照预定的时间要求运行，这时该核心的负载约为62.15%。下面是该数控系统在另外一种参数配置下的线程时间。

表2 线程参数2

判定结果是U=0.816＞0.7798，因而是不可调度的，这意味着在这种参数配置下，如果所有线程都安排到同个核心上，则线程无法按照预定的时间要求运行，低优先级实时线程可能出现不同程度的延迟，可能会影响到数控机床的正常运行。

4.4 不可调度情况下的线程重分配

在表2所示情况下，线程无法合理调度，这时可以考虑减少这个核心上的实时线程数，多出的实时线程分配到另外一个核心Core0上。那么选择哪几个线程与Linux共享Core0呢?这里要重点考虑两个问题：一是线程的重要性和优先级，二是线程交互的情况。首先，应尽量保证最重要的线程在专用核心Core1上运行，一般来说循环周期短、优先级高的线程相对比较重要，比如emcmotTask线程，因而不应该把该线程移到Core0上。其次，考虑线程交互情况，互相之间存在频繁数据通信的几个线程应该尽量放到同一个核心上，比如PLCThread和emcmotTask线程之间共享大量数据，则把这两个线程一起放在Core1上，而把TaskThread放到Core0上。这种情况下的线程安排如图4。

图4 另外一种线程分配

这样安排完之后还要再次进行测算，保证各核心上的实时线程满足调度要求。Core0上只有Task-Thread这一个实时线程，一定可以调度。而Core1上，U=0.7135＜0.8284，满足可调度性条件，因而这种安排是合理的。

4.5 负载均衡

假设所有实时线程按照图3的方案分配到Core1上，对于表3所示的线程时间，计算出 U=0.7265＜0.7798，满足可调度性条件，但是该核心负载比较高;而Core0上只有Linux，负载比较低。从负载均衡的角度考虑，可以把一些低优先级和实时性要求相对较低的实时线程(比如TaskThread)放到Core0上，使两个核心上的负载更均衡一些。

表3 线程参数3

另外，如果各核心负载都比较低，并且缓存失效和线程调度等造成的时间消耗远小于实时线程运行时间的话，也可以考虑直接采用RTCore默认线程分配策略，即由调度器动态地在两个核心上调度线程运行，线程与核心没有固定的对应关系。

5 双核平台上的中断管理

在运行RTCore系统的双核平台上，中断管理比较灵活，用户可以根据需要对中断进行精细的控制，比如单独为每个中断设置处理器亲和性。设计实时数控系统时，要区分实时和非实时中断。实时中断是直接与数控系统相关的中断，必须马上予以处理;而其他的则是非实时中断，比如IDE接口、网卡和串口等占用的中断，不必马上处理。注册了实时中断后，每当产生这个中断，处理器立即停止正在执行的任何实时和非实时代码，转而执行对应的实时中断处理程序;而如果产生的是非实时中断，则RTCore只是简单地做一个标记，表明产生了一个需要由Linux来处理的中断请求，等处理器在空闲时间运行Linux时，存在于Linux内核中的中断处理程序才真正处理这个请求。

一般情况下实时中断处理程序和数控实时线程之间存在着频繁的数据通信。这时可以使实时中断请求指向实时专用核心，而其他非实时中断则指向另外一个核心。这样做有一个前提，即实时中断处理不能导致实时线程过度延期。通常情况下中断处理时间远远小于应用程序运行时间，因而可以忽略其影响。但是如果实时中断频率比较高，处理时间又比较长，就必须考虑中断对实时线程的影响。通常外部中断的产生具有一定的随机性，在此可以进行一些简化，认为实时中断是一个周期性中断。这样就会有中断周期和周期内最大处理时间，可以把该中断处理程序看成一个周期性实时线程，然后采用RM算法判定其可调度性。比如表4的例子，U=0.495＜0.7798，因此把该中断指向实时专用核心是可以的。

表4 带中断的线程参数

6 总结

设计基于双核处理器平台的数控软件架构时要考虑的问题主要包括缓存局部性、任务可调度性、负载均衡和中断管理。在线程分派方面，

(1)如果线程的实时性要求不高，线程调度等导致的延迟不会影响实时性的话，可以采用内核默认的自由调度方案。

(2)从性能和实时性方面考虑，可以直接把实时线程和非实时线程分派到不同核心上。

(3)经RM算法判定实时线程无法在一个核心上合理调度的话，取出若干个重要性和实时性要求较低的实时线程放到非实时线程所在核心上。

(4)在各核心上实时线程满足可调度性要求的前提下，从负载均衡方面考虑，也可以取出若干个重要性和实时性要求较低的实时线程放到非实时线程所在核心上。

在中断管理方面，要根据中断的实时性要求以及与实时线程的交互关系，把中断请求指向不同的核心。

在实际应用中，要综合考虑线程的实时性要求、线程交互、调度器损耗和中断干扰等因素，结合本文提出的方法，对数控软件架构进行设计，以充分利用双核处理器平台的性能优势。

［1］王永吉，陈秋萍.单调速率及其扩展算法的可调度性判定［J］.软件学报，2004，15(6)：799－813.

［2］吴文江，张杰，等.基于RTLinux的数控系统进程间通信方式的研究［J］.小型微型计算机系统，2007，28(5)：952 －955.

［3］郭晋峰，吴寒，等.基于RTLinux SMP功能的数控系统的实现［J］.制造技术与机床，2001，12(12)：14－15.

［4］Daniel P.B.，Marco C.深入理解 Linux内核［M］.北京：中国电力出版社，2007.

［5］David R.Butenhof.POSIX多线程程序设计［M］.北京：中国电力出版社，2003.

［6］史步海，林景山.开放式电动折弯机数控系统的研究与设计［J］.组合机床与自动化加工技术，2010(12)：61－64.

［7］袁良，张云泉.基于横向局部性的多核计算模型［J］.计算机科学，2012，39(7)：1 －6.

［8］陈芳园，张冬松，等.多核实时线程间干扰分析及WCET估值［J］.电子学报，2012，40(7)：1372－1377.

［9］Victor Y，Cort D.RTLinux/RTCore dual kernel real-time operating system［DB/OL］.http：//tornasol.datsi.fi.upm.es/ciclope-old/doc/rtos/cache/doc/rtlpro.pdf，1999.

［10］Burchard A.，Liebeherr J.New strategies for assigning realtime tasks to mutltiprocessor systems［J］.IEEE Trans.on Computers，1995，44(12)：1429 －1442.