伴隨控制技術精進 工業應用開發空間更為寬廣
- DIGITIMES企劃
-
幾個月前，精密機械研究發展中心發表一項技術研發成果，係運用全軟體控制器搭配CAD Based技術，打造出台灣首見的15軸同步運動雙臂機器人；令人驚艷之餘，也不禁好奇，以軟體來當做自動化控制系統，究竟是怎麼一回事？亟欲探究箇中玄機。
論及自動化控制領域，從以往到現今，讓人最為熟悉的自動化控制系統，不外是三大類，分別是數位訊號控制器(DSC)、可程式邏輯控制器(PLC)，以及PC-Based控制器，其中又以PLC佔比最高；一般而言，PLC比較被定位在中大型或中型應用，擅於滿足離散式的邏輯控制應用需求，只要是講求穩定度且生命週期較長的產品，都很適合採用PLC。
至於PC-based控制器，則因為其開放架構及軟體開發之高彈性，被看好有能力與傳統的PLC一搏，甚至取而代之；儘管就實際發展態勢來看，迄今PC-based控制器仍未能完全取代PLC，但依舊備受期待。
PC-based控制器特別適合用以滿足複雜的控制需求，能夠整合諸如Motion、Vision等眾多設備元件，也可整合較大量的資料，此外與DSC或PLC有著顯著的差異，即是具有更大的彈性，可適時隨著需要而更改設計或擴充，而且支援更廣泛的通訊介面，也相對易於連網，與現今響徹雲霄的工業4.0、物聯網浪潮，可說十分契合。
舉例來說，如果製造企業想在產線增設機台、置入PC-based控制器，僅須拉線便可完成，對於製程運作不會形成太多干擾，既定的生產活動甚至無需停擺，回頭看DSC或PLC，則完全並非如此。無怪乎，現在不管談到CNC工具機、半導體組裝生產、LCD Panel生產與檢測、工廠自動化監控、電力監控等控制應用情境，對於PC-based控制器而言，皆有莫大的發揮空間。
綜觀PC-based控制器內涵，與其他系統類似，箇中都存在著硬體、軟體等兩大架構，在硬體部份，主要由CPU與I/O所構成，以I/O而論，乃是控制器與感測器(Sensor)、致動器(Actuator)之間的輸出入介面，包含類比輸出入、數位輸出入、影像訊號介面、馬達介面等等；至於軟體部份，則以作業系統為軸心，譬如Windows、Linux、VxWork、QNX等，而作業系統之所以重要，在於它足以牽動驅動程式(Driver)、函式庫(Library)、軟體開發工具等等所有軟體元件。
缺乏即時性 為PC-based控制技術的罩門
無論如何，即使PC-based控制器相關技術種類不在少數，但企業的選用原則，仍需取決於應用導向，而非技術導向，以利於順利開發出迎合市場與客戶需求的產品。
既然從表面上看來，PC-based控制器確實有著不小的利基，那麼為何遲遲無形對PLC完全取而代之，掌握絕對的大局？說到這裡，仍有必要再回頭看看PLC與PC-based控制器兩者的技術緣起與特色，探討箇中存在著哪些細微的差異。
以PLC而論，其源起於70年代，早期係以取代繼電器的角色現身，僅側重於順序控制功能，邏輯堪稱簡單，但即便如此，其所展現的高可靠性、低功耗、抗干擾、輕巧體積、直觀的程式設計模式(如梯形圖)等諸多特性，依舊帶給製造產業莫大的震撼與驚艷，很快的就扶搖直上，躍為自動控制領域的當紅炸子雞，特別在於客戶高度關切的可靠性部份，PLC挾著平均無故障率時間間隔(MTBF)長達50萬小時、甚至100萬小時的優異表現，自然能輕易獲得多數客戶的信賴與青睞。
PC-based控制器則擁有強大的運算能力，以及開放標準的系統平台、PCI介面，物美價廉CP值超高的顯示技術，多元化的網路組織能力，也有著豐沛的技術與應用開發人力資源，按理說，由工業電腦、I/O元件、監控裝置、控制網路所集結而成的自動化控制系統，理當不難完勝PLC才是，但它之所以未能成為工業自動化的當然主流，在於存在著一些相對缺點。
罩門之一，即使動用性能頂尖優異的工業電腦，MTBF仍與PLC相去甚遠；罩門之二，PC-based儘管具有愈來愈強大的CPU運算能力，只不過其多工作業系統是非即時的，故而在程式的迴圈週期方面，反倒沒有高效能的PLC來得快。這也正是近幾年Open PLC、可程式自動化控制器(PAC)趁勢崛起的因素所在，因為它們試圖在PLC及PC Based等自動控制系統之間截長補短，找到更理想的平衡點。
採用軟體控制器 省下軸控板建置成本
撇開前面提到的控制系統型態，現在有一種控制技術，也逐漸形成潮流，即是軟體控制器(Soft-Controller)，舉凡ABB、KUKA等機器人大廠，都開始將此運用於機器人系統，作為驅動路徑規劃、運動規劃、運動學解算、插補運算之關鍵運動核心，以期增強產品競爭力。
不少人聽聞軟體控制器，自然而然會有直覺反應，認為它就是一種PC-Based控制器，但實情並非如此。同樣以機器人系統的開發情境為例，假使採用PC-Based控制器，其運動層的控制運算核心其實是裝設於工業電腦裡頭的軸卡，而軸卡的運算能力，來自於數位訊號處理器(DSP)、或微控制器(MCU)等晶片，主要理由在於，此類型運算單元才會具有即時性，反觀工業電腦乃至作業系統平台，相對欠缺的就是即時性，很難達到多軸控制下所需之高精度要求，譬如要在1 ms內完成即時插補運算，即為PC力有未逮之處。
在此前提下，PC(含CPU運算單元)在機器人控制系統當中所扮演的角色，充其量僅是用程式與圖形化人機介面的開發平台而已，至於運動核心，則是由軸卡裡頭的DSP或MCU負責。
因此對於機器人控制系統的開發者而言，如果採用PC-Based控制器，將會無可避免面臨幾個難題，首先由於需要配置MCU或DSP，再加上軸控板，因此將徒增硬體建構成本，基於預算考量，開發者只好儘量選用運算能力僅止於恰到好處的MCU或DSP晶片，並不會太強，容易導致控制器功能在於擴展性上備受限制。
其次，因為運動核心係撰寫於MCU或DSP，所以對應韌體程式碼的寫法，必須遵照MCU或DSP廠商所定義的規則，也容易在功能擴展性方面有所限制，而當開發者想採用新型號的晶片產品，或者更換晶片供應來源之際，就會面臨重大麻煩，只因為整個程式碼都需要重新撰寫，而且少不得還要費時進行測試，難免拖慢Time-to-Market進程。
假設以7軸雙臂機器人為例，開發者需要在其中安裝兩組7軸運動控制卡，且考量兩張軸卡之間必須做到即時同步運算，不容任何差池，所以被迫選用昂貴的高階MCU或DSP晶片，開發出足以同時控制14軸的控制器韌體，以便於滿足14軸運動控制功能，並對外連接14組馬達伺服驅動器，可謂浩大工程。
反觀軟體控制器，則是將PC-Based自動化控制系統當中，原本需要由軸卡上MCU或DSP晶片執行的運算任務，通通拉回PC來處理，再利用即時作業系統(Real-time Operating System；RTOS)來彌補即時性的缺陷；換句話說，奠基於軟體控制器的控制系統，所有的運算、包含運動層的控制運算，全都由工業電腦主機板上的CPU來執行，而CPU則同時運行兩套作業系統，一是諸如Windows等傳統非即時性的作業系統，另一便是RTOS。
顯而易的，倘若開發者採用軟體控制器，由CPU上的RTOS來執行運動控制程式，則相關程式碼的撰寫，就無需MCU或DSP晶片供應商所定義的規範，假使要提升效能，僅需換置內含更高階CPU的工業電腦即可，開發與擴充過程相對簡易許多。總而言之，隨著控制技術日趨精進，使得開發者更易於拓展應用彈性，充滿無限想像空間。
