0 前言

　　隨著數控系統的不斷發展，控制周期越來越短，控制精度越來越高，控制算法越來越復雜，要同時運行的功能模塊也越來越多，這都對當前普遍采用的單核處理器平臺提出了嚴峻的挑戰。要在單核平臺上提高現有數控系統的性能或者集成更多的應用，主要可以從以下方面考慮:一是采用更高性能的單核處理器，二是優化現有數控系統的軟件架構，三是從各個細節上著手優化具體的代碼和算法。但是這幾種方法都面臨著各種不同的困難。比如第一種方法，一般情況下性能或主頻的提升往往伴隨著功耗和發熱的增加，而數控系統的特點決定了其功耗不能太高，用于散熱裝置的空間有限，在這些約束下單核處理器的性能提升是有限的，因此這種方法有一定的局限性。

　　本文主要采用雙核處理器平臺以解決前述問題。使用雙核處理器只需額外增加少量硬件和軟件設計工作，即可使系統性能有很大的提升，一些專門針對雙核處理器設計的軟件的性能提升甚至能接近兩倍。本文基于該平臺，借鑒開源EMC2數控系統的軟件設計，研究了雙核平臺上的數控軟件設計方案，并提出在類似平臺上進行數控軟件設計和優化的一般方法(同樣適用于有超過兩個核心的多核處理器)。

1 雙核處理器的硬件結構

　　1.1 緩存結構

　　高速緩存(這里只考慮L2 Cache)是衡量處理器圖中處理器有兩個核心Core0和Corel，每個核心有各自的L2 Cache，兩個核心之間通過總線接口連接到前端總線。兩個核心可以同時各執行一個任務，當兩邊緩存需要保持一致性時則通過前端總線進行通信。程序運行時的局部性好壞會影響緩存命中率，因此應該把重要的實時任務安排到一個固定的核心上，并防止其他無關任務擠占對應的緩存，這樣可以提高實時任務運行速度和實時性。

圖1 獨立緩存結構的CPU

　　1.2 中斷管理

　　中斷處理會對程序的運行速度和實時性產生影響。高頻率外部中斷會不停地打斷正常的程序執行流，如果中斷處理程序也比較耗時，就可能會導致實時任務在運行過程中不斷被打斷和推遲，超過要求的時間限度。目前在中斷管理上普遍采用可編程中斷控制器，可以通過編程的方式控制每個核心上的中斷響應，比如可以在某個核心上開啟或者關閉某個中斷。這樣就可以在運行重要實時任務的核心上關閉無關的中斷，避免了實時任務被頻繁打斷，保證了任務的性能和實時性。

2 雙核平臺需要的軟件支持

　　2.1 操作系統支持

　　要發揮雙核處理器的性能優勢，需要操作系統的密切配合。數控系統設計中應用較多的實時系統有RTAI、RTLinux和Vxworks等，這些系統提供的實時控制功能大同小異，本文采用的系統平臺是RTcore(前身是RTLinux Pro)。

　　RTCore是一款硬實時系統，采用了雙內核H1結構。實時內核運行在最底層，直接管理時鐘和硬件中斷。實時任務運行在實時內核層，而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和MOTl0N模塊中實際執行實時控制任務的是若干個實時線程。當實時模塊加載入RTCore時，會創建實時線程，這些實時線程按照規定的周期進行循環，每次循環中執行一些操作然后休眠。PLc中有兩個低優先級實時線程，TaskThread用來執行用在RTCore中創建實時線程之前可以設置運行該線程的核心，同時采用處理器預留技術把該核心預留給實時應用，這樣就可以把實時和非實時部分隔離到不同的核心上。

圖3 實時與非實時分開處理的架構

　　4.3 關于任務的可調度性問題

　　采用線程綁定和處理器預留技術可以直接把模塊按照實時和非實時分配到兩個核心上運行，但是具體實現上還有一些需要深入考慮的問題。比如多個周期性實時線程能否在單個核心上合理調度?如果能合理調度的話，這兩個核心上的負載分配如何?前一個問題就是任務的可調度性問題，后面一個就是負載均衡問題。

　　針對實時任務的可調度性問題，目前應用最廣泛的是速率單調(簡稱RM)算法，該算法適用于可搶占靜態優先級周期性實時任務的調度。理想的RM算法模型基于一系列假設，而本文所采用的數控系統實現從一定程度上滿足這些假設條件，因此可以直接使用RM算法對可調度性進行判定。

　　RM算法的可調度性判定公式為：

　　其中n為周期線程的數目，Ci是線程i的周期內最大運行時間，Ti是線程i的周期。只要某核心上所有的實時線程滿足上面的條件，就是可調度的。本文采用的數控軟件在某種參數配置下的線程時間如下。

　　如果把這三個實時線程都放到同一個核心上，用RM算法判定結果是U=0.6215<0.7798，滿足可調度性條件，所有實時線程可以按照預定的時間要求運行，這時該核心的負載約為62.15％。下面是該數控系統在另外一種參數配置下的線程時間。

　　判定結果是U=0.816>0.7798，因而是不可調度的，這意味著在這種參數配置下，如果所有線程都安排到同個核心上，則線程無法按照預定的時間要求運行，低優先級實時線程可能出現不同程度的延遲，可能會影響到數控機床的正常運行。

　　4.4 不可調度情況下的線程重分配

　　在表2所示情況下，線程無法合理調度，這時可以考慮減少這個核心上的實時線程數，多出的實時線程分配到另外一個核心Core0上。那么選擇哪幾個線程與Linux共享Core0呢?這里要重點考慮兩個問題：一是線程的重要性和優先級，二是線程交互的情況。首先，應盡量保證最重要的線程在專用核心corel上運行，一般來說循環周期短、優先級高的線程相對比較重要，比如emcmotTask線程，因而不應該把該線程移到Core0上。其次，考慮線程交互情況，互相之間存在頻繁數據通信的幾個線程應該盡量放到同一個核心上，比如PLCThread和emcmotTask線程之間共享大量數據，則把這兩個線程一起放在Corel上，而把TaskThread放到Core0上。這種情況下的線程安排如圖4。

圖4另外一種線程分配

　　這樣安排完之后還要再次進行測算，保證各核心上的實時線程滿足調度要求。Core0上只有Task．Thread這一個實時線程，一定可以調度。而Corel上，U=0.7135<0.8284，滿足可調度性條件，因而這種安排是合理的。

　　4.5 負載均衡

　　假設所有實時線程按照圖3的方案分配到Corel上，對于表3所示的線程時間，計算出u=0.7265<0.7798，滿足可調度性條件，但是該核心負載比較高；而core0上只有Linux，負載比較低。從負載均衡的角度考慮，可以把一些低優先級和實時性要求相對較低的實時線程(比如TaskThread)放到core0上，使兩個核心上的負載更均衡一些。另外，如果各核心負載都比較低，并且緩存失效和線程調度等造成的時間消耗遠小于實時線程運行時間的話，也可以考慮直接采用RTCore默認線程分配策略，即由調度器動態地在兩個核心上調度線程運行，線程與核心沒有固定的對應關系。

5 雙核平臺上的中斷管理

　　在運行RTCore系統的雙核平臺上，中斷管理比較靈活，用戶可以根據需要對中斷進行精細的控制，比如單獨為每個中斷設置處理器親和性。設計實時數控系統時，要區分實時和非實時中斷。實時中斷是直接與數控系統相關的中斷，必須馬上予以處理；而其他的則是非實時中斷，比如IDE接口、網卡和串口等占用的中斷，不必馬上處理。注冊了實時中斷后，每當產生這中斷，處理器立即停止正在執行的任何實時和非實時代碼，轉而執行對應的實時中斷處理程序；而如果產生的是非實時中斷，則RTCore只是簡單地做一個標記，表明產生了一個需要由Linux來處理的中斷請求，等處理器在空閑時間運行Linux時，存在于Linux內核中的中斷處理程序才真正處理這個請求。

　　一般情況下實時中斷處理程序和數控實時線程之間存在著頻繁的數據通信。這時可以使實時中斷請求指向實時專用核心，而其他非實時中斷則指向另外一個核心。這樣做有一個前提，即實時中斷處理不能導致實時線程過度延期。通常情況下中斷處理時間遠遠小于應用程序運行時間，因而可以忽略其影響。但是如果實時中斷頻率比較高，處理時間又比較長，就必須考慮中斷對實時線程的影響。通常外部中斷的產生具有一定的隨機性，在此可以進行一些簡化，認為實時中斷是一個周期性中斷。這樣就會有中斷周期和周期內最大處理時間，可以把該中斷處理程序看成一個周期性實時線程，然后采用RM算法判定其可調度性。比如表4的例子，U=0.495<0.7798，因此把該中斷指向實時專用核心是可以的。

6 總結

　　設計基于雙核處理器平臺的數控軟件架構時要考慮的問題主要包括緩存局部性、任務可調度性、負載均衡和中斷管理。在線程分派方面，

　　(1)如果線程的實時性要求不高，線程調度等導致的延遲不會影響實時性的話，可以采用內核默認的自由調度方案。

　　(2)從性能和實時性方面考慮，可以直接把實時線程和非實時線程分派到不同核心上。

　　(3)經RM算法判定實時線程無法在一個核心上合理調度的話，取出若干個重要性和實時性要求較低的實時線程放到非實時線程所在核心上。

　　(4)在各核心上實時線程滿足可調度性要求的前提下，從負載均衡方面考慮，也可以取出若干個重要性和實時性要求較低的實時線程放到非實時線程所在核心上。

　　在中斷管理方面，要根據中斷的實時性要求以及與實時線程的交互關系，把中斷請求指向不同的核心。在實際應用中，要綜合考慮線程的實時性要求、線程交互、調度器損耗和中斷干擾等因素，結合本文提出的方法，對數控軟件架構進行設計，以充分利用雙核處理器平臺的性能優勢。