伴随控制技术精进 工业应用开发空间更为宽广
- 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的工业电脑即可，开发与扩充过程相对简易许多。总而言之，随着控制技术日趋精进，使得开发者更易于拓展应用弹性，充满无限想像空间。
