面向对象技术在开放式数控中的应用

数控（NC，Numerical Control）是一种用数字化的信息（数字、字母和符号）对某一工作过程（如加工、测量、装配等）进行可编程的自动控制技术。

数控系统（Numerical Control System）是实现数控技术相关功能的软硬件集成的系统，是数控技术的载体。

数控机床（Numerical Control Machine Tools）是采用数字控制技术对机床的加工过程进行自动控制的一类机床。它是数控技术的一个典型应用。

计算机数控系统（CNC, Computer Numerical Control）是以计算机为核心的数控系统。

图1-1 CNC结构图

1.2       数控的发展简史

世界上第一台电子计算机ENIAC(埃尼阿克)于1946年在美国宾夕法尼亚大学诞生，此后人们逐渐开始研究计算机技术在机床上的应用。时隔6年后的1952年,在美国的麻省理工学院(MIT) 诞生了世界上第一台数控机床。又是时隔6年后的1958年，我国第一台数控机床（代号101）在清华航空馆诞生。

从1970 年小型计算机用于数控起,数控技术进入了计算机数控(CNC) 阶段, 1974 年微处理器用于数控，20 世纪90 年代随着PC的普及，基于PC的数控开始得到迅速发展[2]。从此，大量计算机学科的技术被逐渐应用到数控上来，CNC技术迎来了一个前所未有的时代。

1.3       开放式数控的引入

经过近半个世纪的发展,数控技术在各种制造领域中大显身手，诞生了具有各行各业鲜明特色的一系列数控设备。其中最典型的是应用于装备制造领域的数控机床——各种数控车、铣、磨以及复合加工中心甚至机械手臂和机器人等，还有各种线切割机床、电火花加工机床等。另外，用于其他行业的如高档印刷机、注塑机、纺织机、绣花机、雕刻机以及各种医疗器械等。这些装备的诞生是信息时代的显著特征，它们极大地促进了生产力的发展。随着世界经济一体化进程的加快以及企业在全球范围内竞争的加剧,产品的形状和结构不断复杂化[2]，产品更新换代速度加快，市场对制造系统的柔性、复合加工性及其加工功能的要求越来越高，对加工质量和加工速度的要求也日益苛刻。另外，随着计算机网络技术的普及，企业制造信息共享也日渐提到日程上来。

但是传统的数控系统目前而言仍是各个数控生产厂商所生产的专用设备，从最上层的控制器软硬件，到伺服、电机等驱动设备，甚至工业总线，电气连接方式等都是自成一体，不同厂商间的产品基本不具有互换性。而数控的核心技术——数控软件的结构更是专机专用，既无可移植性，也缺乏定制性和可扩充性。这样造成机床制造商对控制器供应商的依赖性很大。对于一些小型的专用领域的数控系统而言，这可能影响不大，然而对于一些希望在控制系统中加入自己加工经验，整合企业内不同的控制器平台甚至进行企业级信息集成及管理的厂商来说，传统的CNC是远远不够的，各控制器厂商的接口不统一，各种平台无法集成，统一到企业级的信息平台上来也是困难重重。

于是市场呼唤一种面向各领域生产厂商的制造系统，能够将各领域的专业技术和各厂商的专有技术融入其上，并能方便地根据通用的数控平台进行裁减和定制，打造符合自己加工需求的制造系统。而信息时代的到来，计算机技术在数控机床上的应用，促使传统的数控机床在其影响下逐渐发生了变化，从而诞生了一个新的概念——即模块化、可配置、可互联互通的开放式数控系统。

目前数控系统的市场向两个方向发展，一个是向低成本高可靠性的专用数控发展，其功能单一，任务简单，技术路线一部分沿传统的PLC发展，目前其高端形式为PAC，另一部分是发展专用数控系统；另一个方向则是借助于PC技术实现的开放式数控系统，由于结合了现代的计算机软件技术，因此具有广阔的研究前景。

1.4 开放式数控系统概述

IEEE(国际电气电子工程师协会)关于开放式数控系统的定义是：开放式系统能够有效地运行于不同厂商的平台之上，可以与其他应用系统相互操作，并提供具有一致风格的用户交互界面[9]。

开放式数控系统研究的主要目的是解决变化繁杂的需求与控制系统专一固定的框架之间的矛盾,从而建立一个统一的可重构的系统工具平台,极大地增强数控系统的柔性和适应性[2]。开放式数控系统由系统制造商完成，机床生产商集成实施，最终用户使用。那么这三者之间互相联系又都有各自的特长和专注领域：系统制造商专注于设计制造结构化、模块化更好的开放式系统，并努力提高系统本身的性能，致力于提供一个良好的制造平台；机床生产商提供面向用户的生产方案并进行系统集成，解决某一领域的通用问题；而最终用户则更关注于具体工艺方面的要求和实现细节，需要通过系统提供的配置功能或者二次开发功能，能够方便地将自己的独有技术及加工方法揉合到加工平台上去。

一个开放式的数控系统它应该达到以下几方面要求：

(1) 开放式控制系统的硬件和软件都是柔性的，硬件的基本配置应该可以改变，而软件绝大多数的参数配置开放给用户，系统基本组成模块也可以互换；

(2) 开放式结构系统的软硬件必须真正“即插即用”。如果产品功能的增删和改动必须由系统制造商来解决，那就不是真正的开放；

(3) 控制器的软硬件模块都必须是标准化的，第三方不但应该能在此基础上参与其中某部分硬件和软件的开发，还需要能够加入新的标准功能模块来扩展系统功能；

(4) 一个开放式控制系统能在系统的级别上同其他符合标准的应用系统协同工作。

1.5 本文的组织结构

本文首先介绍了开放式数控的引入背景，介绍及分析了当前国内外开放式数控的发展现状，提出了我国开放式数控的发展方向。然后具体介绍作者在开发iComac数控系统的过程中所使用的面向对象方法，最后评测分析了该软件的功能和性能。本论文的总体结构如下，

第1章主要内容是介绍了数控的一些基本概念及开放式数控的引入背景。

第2章主要是国内外开放式数控的发展现状介绍与分析。介绍了国外目前比较大的几种开放式标准，包括了美国的OMAC计划、欧洲的OSACA计划和日本的OSEC。然后介绍了我国在开放式数控方面的国家标准GB/T 18759.1-2002。在本章的最后对我国开放式数控的发展提出了自己看法和建议。

第3章介绍了作者在开发开放式数控系统中所用到的面向对象技术以及采用该技术提出的软件系统体系结构。首先讲述了软件体系结构的重要性及与开放式数控的关系。其次开始详细讲解了各个时期基于面向对象技术的iComac软件体系结构。再次，展示了iComac的最终软件体系结构，并就其开放性和速度及实时性等问题进行了分析，说明了基于PC架构的开放式数控软件的平台优势。然后从未来面向对象技术发展的方向对未来开放式数控软件的发展进行了分析并提出了看法。最后，对体系结构探索过程进行了反思，分析了探索过程中的得与失。

第4章主要介绍了面向对象技术在数控系统的核心子系统运动控制系统中的应用。首先，提出了运动控制系统对于开放式要解决的主要问题。其次，运用面向对象分析技术从具体的需求入手，结合数控本身的特点设计了运动控制系统的基本模型。再次，提到了设计模式为软件开发带来的重要作用。最后，对运动控制系统组件的开放性进行了分析，得出了其符合开放式标准的结论。

第5章通过实际上机床测试的方式验证该系统。首先，介绍实验的环境。其次，给出实验结果并根据实验结果进行分析。最后，对实验可能产生的误差进行分析。

第6章是总结和展望，主要是对全文工作的总结，以及目前正在进行的工作，下一步需要研究的重点和将来工作的展望。

第二章 开放式数控发展现状

2.1 国外发展现状

开放式控制系统的概念出现于上世纪80年代后期。早在1989年，美国政府为了减少大型制造设备(数控机床、加工中心等)对日本控制器(FANUC，OMRON)的依赖性，就成立了“国家制造科学中心”，开始了名为“下一代控制NGC(Next Generation Controller)”的计划，并成立了“美国国家制造科学中心（NCMS）”，目标是开发能用于CAD/CAM和多传感器信息集成的商业化机床控制环境软件平台[3]。该计划研究的结果就形成了有助于工业运动控制器产品标准化的开放式系统结构标准规范NGC-SOSAS(Specification for an Open System Architecture Standard)。其后各个国家相继开始了这方面的研究，制定开放式控制系统平台的标准和进行实际开发，而其中影响较大的有美国的OMAC、 欧洲的OSACA和日本的OSEC等计划。

2.1.1 OMAC计划

美国的汽车工业为解决自身发展过程中碰到的一系列问题,同时发挥美国在计算机科学方面的领先优势,由克莱斯勒、福特和通用三大汽车公司于1994年开始了一项名为“开放式、模块化体系结构控制器OMAC(Open Modular Architecture Controllers)”的计划。该计划的目标是降低控制系统的投资成本和维护费用，缩短产品开发周期，提高机床利用率，提供软硬件模块的“即插即用”和高效的控制器重构机制，简化新技术到原有系统的集成，从而使系统易于更新换代，尽快跟上新技术的发展，并适应需求的变化[4]。该计划的目的是向控制系统开发商等上游厂商提出控制器用户尤其是汽车制造业的需求，以便上游厂商在更好地理解用户的需求后生产出更能满足其要求的产品。

由于OMAC计划由控制器的用户发起而不是开发商，而开发商都有自己固定的一系列产品，更新换代并不是他们迫切的需求，所以OMAC的产品化、实用化步伐不可能很快。事实上美国工业界认为OMAC是一种概念，而不是一种控制器或标准。OMAC自身也意识到这一问题，它目前正逐步与OSACA等进行联合[4]。

2.1.2 OSACA计划

为了提高欧洲机床生产商和控制器开发商在世界市场上的竞争力，欧共体国家的22家控制器开发商、机床生产商、控制系统集成商和科研机构于1990年联合发起制定了联合研究计划OSACA (Open System Architecture for Control Within Automation),其目的是制定一个独立于硬件开发商的能适用于大多数工业控制器的开放式体系结构规范，以提高控制系统的柔性，减少用户OEM制造过程中的培训、开发和维护费用[3]。

OSACA计划分三个阶段进行：

l        第一阶段OSACA-Ⅰ从1992年5月正式纳入欧盟ESPRIT-Ⅲ项目计划开始到1994年，完成了OSACA规范和应用指南的制定。

l        第二阶段OSACA-Ⅱ（ESPRIT 9115）于1996年4月结束，主要完成依照OSACA规范为其系统平台开发标准、通用的软件模块和通用的OSACA系统平台，建立一个五轴制造系统环境，用以调试、验证、扩展前一阶段的各种规范。

l        第三阶段为IDAS OSACA（Information Dissemination and Awareness Action）于1997年1月开始，计划历时18个月，推广OSACA思想及前期工作的技术成果。同时为了建立一个国际性的标准，而与日、美的相关机构进行接触。

 

OSACA的目标之一，是使自己成为自动化领域的通用国际标准，故开始它就将研究范围涵盖了整个自动化领域，并投入了巨大的人力、物力[4]。

图2-1 OSACA体系结构图[8]

OSACA控制系统分为上下两层：应用软件层和系统平台层。

应用软件层为控制系统的业务逻辑层，不同行业不同功能的控制系统会设计出不同的控制逻辑。该层采用独立模块AO(Architecture Object),访问系统平台层的OSACA-API,这样就实现了业务逻辑的平台无关性。

系统平台包括系统硬件、OSACA-API (Application Programming Interface)和系统软件。

系统硬件包括控制器硬件的主板、I/O模块及AD/DA通讯模块等电子部件；

OSACA-API是系统平台层为应用软件层提供的标准访问接口，它是AO访问系统平台的唯一途径。API接口为各种业务逻辑对象提供了在所有平台上的统一接口，隐藏了系统平台层内部的具体实现，实现了应用软件独立于硬件和操作系统的特性。用户针对于标准统一的系统平台层，可以任意选购不同供应商提供的功能模块，根据自己的需要定制控制系统，也可以根据需要增添或减少某些功能模块以改变系统功能；

系统软件包括操作系统、配置系统、通讯系统和驱动程序等。配置系统提供一个称为CRS模块提供动态配置功能；通讯系统又由信息传输系统、应用服务系统和通讯对象管理器三部分组成[5]。信息传输系统与操作系统和通讯协议相关，OSACA跨平台特点正是通过信息传输系统实现的。应用服务系统实现内部和外部数据的传输管理任务，与操作系统和通讯协议无关。通讯对象管理器提供的接口是OSACA-API接口的一部分，它通过提供标准的通讯对象实现统一的信息交换方式。

图2-2 OSACA通讯系统[8]

OSACA在上世纪90年代提出的系统结构模型在当时来讲是非常先进的，它由一批软件系统架构专家和搞控制器的专家合作，采用了80年代计算机科学刚刚兴起的面向对象技术设计的体系结构。然而其从制定标准到推广这长达8年的时间，同时代计算机领域的专业公司像微软、IBM等将面向对象技术及基于该技术衍生出来的中间件、组件技术发展得更为完善和先进，OSACA中的软件技术标准搞出来以后就落后于这些已经成形的行业标准。加上后来西门子等重量级企业合作者的退出，OSACA标准并没有被实际广泛应用。

然而，OSACA的意义影响是深远的，它在全世界的推广也给了工控界一个清晰的信号——开放式控制的时代就要到来。从此，世界各国对开放式的研究如火如荼般深入开展起来。而中国的开放式控制器标准化则在很大程度上借鉴了OSACA的成果，它也帮助中国的控制器厂商和有关机构了解了开放式这一理念，对我们今天的开发工作仍然具有很高的借鉴意义。

2.1.3 OSEC

日本的“控制器开放系统环境OSEC(Open System Environment for Controller)”是于1994 年由东芝机器公司、丰田机器厂和Mazak公司三家机床制造商和日本IBM、三菱电子及SML信息系统公司联合提出的。其目的是建立一个国际性的工厂自动化（FA）控制设备标准[4]。OSEC以日本国际机器人和工厂自动化研究中心（IROFA）所提出的CNC系统参考模型为基础，提出了一个开放式的体系结构并实现了满足用户通过系统配置对制造系统进行定制的功能、最小化费用要求和应用先进控制算法及基于PC 的标准化人机界面的要求[2]。

2.2 国内发展现状

从“九五”期间开始，在国家有关单位的支持下，由航天数控和华中数控牵头，多家研究单位联合承担了有关开放式控制器的研究。与此同时，对开放式数控系统的相关标准的研究制订也同期展开，由中国机械工业联合会提出，挂靠在北京机床研究所的全国工业机械电气系统标准化技术委员会专门成立了“开放式数控系统（ONC）国家标准制订委员会”，从事我国开放式数控系统的标准研究及制订。

“十五”期间，经多家研究单位合作研究、起草，制定了GB/T18759.1－2002 《机械电气设备　开放式数控系统　第1部分：总则》。该标准规定了开放式控制器的功能特征、系统基本体系结构和通信接口。此后，在国家科技部“863计划”的支持下，又进一步对开放式数控系统的体系结构技术标准进行了研究和制订，在2006年制定了 GB/T18759.2－2006《机械电气设备　开放式数控系统　第2部分：体系结构》国家标准，规定了开放式数控系统的基本体系结构，定义了体系结构中各个功能组件及其主要功能模块。开放式数控系统体系结构技术标准的研究与制订，对我国开放式控制器的研究提出了指导性意见，但要在业界得到广泛认同尚需一定时日。

目前，国内对开放式控制器研究的意义有高度的认同，对开放式控制器的主要矛盾也有了较深刻的认识，但是由于长期以来我国国内数控工业产品市场占有率低，缺乏一些大型的控制器开发商和用户，其开放式的需求在很大程度上并不是十分急迫，而国内既精通数控技术本身同时又精通计算机软硬体系结构的复合型人才少之又少。目前掌握了现代计算机软件技术的绝大多数都是年轻人，其中的大部分人才都投身到IT领域，即使有少量做数控的软件人才也都过于年轻，对于系统体系结构和数控本身矛盾了解不深，所以国内的开放式标准的制定在短期内难以取得非常好的成果。然而标准的制定为我国对于开放式数控的进一步研究、开发开放式数控系统和制订相应的标准打下了良好的基础。

2.2.1 开放式数控国家标准

开放式数控系统ONC (Open Numerical Control System)：

指应用软件构筑于遵循公开性、可扩展性、兼容性原则的系统平台之上的数控系统，使应用软件具备可移植性、互操作性和人机界面的一致性。[1]

国家标准总则中说明，ONC系统的开放程度可分为以下三个层次:

第一层: 具有可配置功能、开放的人机界面的通信接口及协议。

第二层: 控制装置在明确固定的拓扑结构下允许替换、增加NC核心中的特定模块以满足用户的特殊要求。

第三层: 拓扑结构完全可变的“全开放”的控制装置。

2.2.2 开放式数控体系结构国家标准

图2-3 ONC系统的基本体系结构框图[1]

2.3 当前开放式数控发展分析

据统计，2003 年，全球自动化行业的控制系统市场大约为每年100 亿美元左右，其中99%被传统的不开放系统所占据[6]。从目前的控制器市场状况可以看出，较大的控制器制造商（Siemens、GE-Fanuc、ROCKWELL、日本横河等）都有已经成熟的产品，并且在市场上正处于盈利时期，既使他们认识到开放式系统是未来发展的趋势之一并且有利可图，但这些厂商出于市场产品战略的考虑，不可能很快转入开放式控制系统的研发中，而会采取循序渐进的改良措施，对原有的系统加上一些接口实现局部的互连和通信，尽量向开放方向靠近，但要做到真正意义上的开放还有很长的路要走。

所以，我们从以上分析可以看出，在开放式系统发展的初级阶段，国外的各大控制系统制造商会迎合发展趋势，以其目前的产品为基础，推出一些半开放式的控制系统，而不会很快推出完全开放的系统。这对于我国开放式数控的发展来说是一个机会，国内的控制器厂商完全可以利用这个时间差来开拓自己的市场，大力发展具有完全独立自主知识产权的开放式数控，在开放式市场大展拳脚而不必背负沉重的历史包袱。

正是在这样的背景下，北京凯奇数控从2001年开始组建数控研发团队，开始了开放式数控的探索和研发工作。本人有幸从团队建立伊始便参与了这样一件在中国工业界具有划时代历史意义的开创性工作。我们边学习数控知识和计算机知识，边探索和研究数控的解决方案。从整个系统体系结构的设计、软硬件平台的选择、数控原型机的开发甚至参与制定国家开放式标准，我们都努力地进行了各种探索和尝试。经过五年多的奋斗，我们完成了“十五”期间的重大课题——开放式数控，实现了三座标铣床的现场加工和高速高精度测试以及卧铣加工中心的五座标功能。我们在数控软件的设计和开发中，本着开放性原则，借鉴OSACA和国家开放式标准的体系结构，采用面向对象技术完成了该软件。下面几章我将重点介绍我们在该软件中所采用的面向对象技术。

2.4 本章小节

本章主要介绍国内外目前开放式数控发展的现状，并分析了今后发展的趋势。首先，从介绍国外著名的几种开放式标准入手，重点介绍了欧洲的OSACA计划，因为它在作者所在的团队开发开放式数控软件的过程中起到了很大的借鉴作用。其次提到了我国开放式数控发展的情况，以及对当前情况及问题的分析，提出了长期发展的观点。然后又介绍了我国制定的开放式标准与体系结构。最后对当前开放式数控的发展情况进行了分析，指出了国外控制器厂商目前的发展情况并提出了国内控制器厂商应借此时机大力发展国内具有独立自主知识产权的开放式数控的观点。

第三章 开放式数控软件iComac

3.1 软件体系结构与开放式数控

软件体系结构由构成软件系统的构件描述、反映这些构件的相互作用、指导构件集成的模式以及这些模式的约束等内容组合而成，从而形成了软件系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了软件设计的基本原理框架。

软件体系结构是当今软件工程领域中一个重要的研究内容，尤其在设计大规模的复杂软件系统时，设计良好的体系结构已经成为提高软件生产率和解决软件维护问题最有效的途径。研究软件体系结构的首要问题是如何建模。针对规模日益庞杂的应用软件，体系结构研究的首要目标是提高实际应用系统的开放性和集成性，同时兼顾效率。

软件系统的开放性，包括数据的开放性、功能的开放性和系统的可扩充性。是否具备良好的开放性基本取决于软件的体系结构。那么对于开放式数控软件而言，其数据开放性具体表现在系统参数配置、加工参数、工艺参数及其所控制对象如伺服、电机、机床及其附属配套设备参数的开放性；功能开放性表现在用户可以根据需要任意增添、减少或修改其中某个功能模块，如替换控制算法功能等；系统的可扩充性表现在一个开放式的控制系统应能够支持第三方功能模块，并能够与其它系统实现方便的对接。

软件系统的集成性，是指通过一致的信息描述手段和处理机制将各功能子系统统一到同一个集成环境，集成性的好坏也基本取决于软件的体系结构。现代的数控软件中，集成了许多功能，譬如：运动控制系统、通讯系统、数据处理系统、人机界面、PLC系统等等，如何将这么多复杂的功能模块集成到一起，选择一种合适的集成方式也是软件体系结构设计的根本任务。

软件系统的效率，通常包括系统运行的效率和应用开发的效率。运行效率是系统运行时的时空复杂度，而应用开发的效率指开发的难易程度和执行效率。效率大部分取决于体系结构，也与系统的具体实现有关。对于数控这种实时性的控制系统而言，执行效率是其重要指标，而开发效率则是保障该控制软件能够快速成功投入市场的重要先决条件。

开放的体系结构使得子功能构件的集成易于实现，同时也必然提高应用开发的效率；集成和高效反过来又有利于更好地达到开放的目的。

3.2 基于面向对象技术的软件体系结构探索

针对应用软件系统的开放性，曾先后出现了许多类系统模型，代表了应用软件技术与产业发展的不同阶段。各阶段中有代表性的系统模型依次为：以数据为中心的系统模型、以执行为中心的系统模型、面向对象的系统模型和基于总线的系统模型。

从上世纪80年代起，人们在开发软件的长期实践过程中，借助于模拟人类解决问题的方法，用对象分解取代功能分解，从而产生了面向对象技术，它为人们提供了一种新的认知和表示世界的思想和方法，在此基础上提出了面向对象的计算机程序设计语言、面向对象的软件设计方法、面向对象的数据库等等。同时面向对象技术为软件工业实现工程化提供了强有力的支持，正是面向对象技术造就了组件、构件、中间件等概念，解决了软件系统的可操作性、可扩展性、语言独立性和跨平台的操作能力，形成了面向对象的体系结构。这种面向对象的体系结构完全符合开放式的要求，并且面向对象技术发展到今天已经是计算机科学领域极为成熟的一种方法，所以采用面向对象技术来搭建开放式控制系统平台是目前最佳的选择。基于这一系列的技术，我们一步步地提出了今天的开放式数控软件体系结构模型。下面从我们刚开始认识研究对象起，逐一讲述我们在开发过程中如何一步步建立起最终模型的。

3.2.1 面向对象的系统模型

 

图3-1 iComac面向对象系统示意模型

图3-1是我们最早开发的面向对象的体系结构模型，其中，iComac模块中封装的是能为用户界面对象(GUI)和所有应用对象所共享的数据及相应的操作；用户界面对象中封装的是用户界面数据及相应的操作；应用对象中封装的是应用数据及相应的操作。所有这些对象通过相互间的通讯协调来完成指定的功能。从系统构成的角度来说，这种模型的结构是无中心的，应用系统由各对象实体构成，各对象实体具有平等的地位。这样一种系统模型的主要优点在于，数据和功能的合理封装降低了由于数据和功能的集中管理所带来的通讯上的开销和操作上的复杂性。

但是随着开发的深入，系统功能的增多，以对象为中心封装的类模块越来越多，类本身虽然提供了封装性、多态性和继承性，但也暴露出一些问题和不足：

1、      为了支持面向对象技术和保持控制软件运行的高效性，我们选用了C++开发语言，那么我们所有的类编码都需要用该语言来实现，所以其开放性只是针对于类层面，并且要依赖于开发语言本身，对于开发人员或者第三方开发人员来讲，需要了解系统的类结构和对开发语言掌握得很清楚；

2、      由于对象之间的联系是一种点对点的直接联系，当系统中对象数目增加时，通讯链接数将以平方级激增；同时，为支持通讯，每个对象都要维护一个与其它所有发生关系的对象的通讯接口，这部分信息的重复不但严重损害了系统的效率，而且为保证接口的一致性还造成了开发和维护的困难；

3、      对象的接口没有一致的标准，造成向系统中扩充对象时的随意与不规范，不利于系统的维护以及对象的复用；

4、      由于功能模块封装粒度为类层面，各功能类间耦合度很大，往往牵一发而动全身。大量的类图，也造成了系统模型和结构概念的不清晰。

所以，这种原始的面向对象的体系结构难以形成标准和开发规范，不能完全达到软件重用的可移植性和互操作性的要求，更不能实现所谓的“即插即用”的功能。后来，我们着手于用将面向对象思想与组件编程思想相接合发展起来的基于对象的组件体系结构技术来解决这个问题。

3.2.2 基于对象的组件体系结构模型

20世纪60年代末到80年代初，结构化的模块式软件开发思想占主导地位，当时的组件的含义是指一些定义良好的方法包或功能模块。80年代起，面向对象的软件开发思想迅速发展起来，这时的软件组件的含义就是类库。类虽然提供了封装性、多态性和继承性，但需要依赖于具体的编程语言，耦合度高，且需要用户对类库的结构和宿主语言有较深入的了解，因此，不能完全达到软件重用的可移植性和互操作性要求。90年代后，组件的内涵进一步加强，聚合性、独立性和重用性进一步提高。基于对象的组件体系结构中的组件是一种定义良好的、独立的、可重用的二进制代码，每个组件提供一种特定的系统功能，可插入到各种软件中，它可以是封装好的单个类、功能模块、软件框架甚至整个独立的软件系统等。

借鉴于基于对象的组件体系结构我们设计了新的开放式数控体系结构模型：

图3-2 iComac基于对象的组件体系结构示意图

 

这个模型里的各个模块是我们按照系统功能封装的各种组件，这样带来了以下几种优点：

1、      组件有严格的封装性，类之间的耦合性被局限在组件内部，外界仅通过接口访问组件，组件的构成粒度大小自由，便于实现各种大小不同功能的模块。譬如CMDL Compiler组件，对外仅仅提供输入加工程序接口和输出编译后程序接口，其内部实现的复杂逻辑都封装在该组件内部，系统的其它部分是看不到这些逻辑的；

2、      组件之间是基于二进制标准统一在一起的，组件间的通讯建立在二进制代码层上，这样保持了各组件间的编程语言独立性。GUI组件内部可以用C++来实现也可以用java、delphi等等各种语言；

3、      根据组件内部实现的逻辑复杂程度，可以从不同侧面通过组件接口透露出更多更复杂的功能，而不是固定的唯一的外部特性。Channel组件提供单通道的数据交换功能，它与GUI、PLC和插补器、执行器等都发生关系，但是不同组件通过接口调用Channel组件内部数据时，会带进来调用者的相关信息，组件内部根据这些信息区分对待给予的数据类型及响应优先级等，表现出多面性的特征。

 

另外，专业的软件提供厂商提供了许多基于经典面向对象技术的组件模型技术，诸如SUN公司的EJB(Enterprise Java Beans)，微软公司的COM（Component Objiect Module，对象组件模型）/DCOM（Distributed COM，分布式对象组件模型）以及OMG（Object Management Group，对象管理组织）的 CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）等技术，为软件体系结构设计和大型应用软件开发给予了强有力的支持。

随着数控软件原型的开发完成，软件的测试成了工作的重心。然而，由于软件所运行的控制器硬件体系及结构不尽相同，控制器与底层驱动设备通讯协议及通讯方式的不同，导致了我们软件中相关模块的程序逻辑大量改动。另外，由于该软件是直接基于Windows CE操作系统开发的，各组件中直接调用了大量的windows API函数甚至直接对硬件地址的访问，那么一旦我们更换硬件解决方案或者更换操作系统，必然导致现有的系统大量的代码重写。为了解决这些问题，我们继续探索软件解决方案，结果找到了中间件技术，新一轮的体系结构重构开始了。

3.2.3 基于中间件技术的系统模型

中间件技术是在上世纪末计算机技术逐步进入以网络为中心的新时期发展起来的。随着网络技术的发展，分布式系统的应用日益广泛，在这样的环境中，无论硬件平台还是软件平台都不可能做到统一。大规模的应用软件通常要求在软、硬件各不相同的分布式网络上运行，由此出现了不同硬件平台、不同网络环境、不同数据库之间的互操作。为了更好地开发和应用能够运行在这种异构平台上的软件，迫切需要一种基于标准的、独立于计算机硬件及操作系统的开发和运行环境，中间件(Middleware)技术应运而生。

中间件是软件中介于在应用层和网络层之间的一个功能层次，使应用系统独立于由异构的操作系统、硬件平台与通信协议组成的底层环境。

从20世纪90年代至今，由于系统应用特别是互联网应用和应用软件的越来越复杂，中间件软件的品种也越来越丰富。目前市场上受关注的中间件大致分为两大类：一类是底层中间件，用于支撑单个应用系统或解决单一类的问题，包括交易中间件（TPM）、应用服务器（WAS）、消息中间件（MOM）、数据访问中间件（UDA）等；另一类是高层中间件，更多的用于系统整合，包括企业应用集成中间件（EAI suites）、工作流中间件（Workflow）、门户中间件（Portal）等，它们通常会与多个应用系统打交道，在系统中的层次较高，并大多基于前一类的底层中间件运行。

借鉴于目前的中间件技术和分析了数控系统的需求，我们对数控系统软件提出了三类中间件：基于应用服务器技术的NCVM(Numerical Control Virtual Machine 数控虚拟机)、基于消息中间件技术的消息中心MsgCenter和基于数据访问中间件技术的数据中心系统DataCenter。

图3-3 基于中间件技术的开放式数控模型

l            NCVM位于操作系统之上，负责提供上层数控软件的系统调用API，将操作系统提供的API以及硬件操作等进行包装，提供了一个数控软件运行的平台；

l            MsgCenter提供系统软件内部各组件以及与系统外通讯的功能，它屏蔽了特定的进程间或者组件间的通讯方法以及与外部系统的通讯协议，实现了消息汇集、管理、解释、分发等功能；

l            DataCenter提供了系统软件内部数据交换的功能，组件间的共享数据、全局数据及用户自定义的数据内容都记录在该系统中。同时提供了数据读写注册机制，保证了实时运动控制不受干扰的情况下，数据能够正确共享。即实现了一个带管理功能的实时数据库的作用。

 

对系统做了这样的重新设计后，我们对系统体系结构进行了新一轮的重构。把所有组件中与系统API有关系的函数调用全部改为调用NCVM的API，所有对硬件层的操作都改为调用NCVM内部封装的硬件操作函数来实现；所有组件间的通讯接口全部改为与MsgCenter发生关系，进一步减少了组件间维护多份通讯接口的系统开销。系统外界通讯通过MsgCenter进行隔离，然后解释成相应的系统调用；系统中所有组件的数据输出和读入接口都仅与DataCenter发生关系，保证了数据目的地和来源地的一致性。通过这次重构，所有的数控应用层软件模块都实现了真正的开放性，只要该模块接口符合系统软件层接口调用规范，则可以很方便地以二进制代码段的形式插入到该系统中来。这样，系统模型就越来越接近于开放式数控的基本特性了。

目前系统虽然实现了组件化插入和应用软件层的良好隔离，但并不是十分完美。就是我们在系统软件层提供的组件插槽是分类的，并且功能固定，也就是说GUI组件只能插入GUI插槽，其定义的接口规范与其它组件如运动控制组件接口并不一致，这虽然在一定程度上提高了组件识别效率，但对于扩展性和支持第三方组件的开放性要求还有一定差距。于是我们又继续研究了一种新型的体系结构——基于总线的系统模型。

3.2.4 基于总线的系统模型

随着以面向对象为基础的组件和中间件技术的逐渐成熟，应用软件系统的建模又引入了新的思想，产生了基于总线的系统模型。组件、中间件是继面向对象技术之后发展起来的新的软件工程技术，是面向对象技术的延伸。而基于总线的系统模型仍然是一种面向对象的结构，但系统中的对象都是按照统一规范、统一接口设计的模块，为了建立更大更复杂的系统，这种模型定义了一种高效的总线结构，使这些定义良好的软件模块(组件)之间能以一个公共的接口互相连接，做到即插即用，无缝集成。这种模型的系统中，组件间的通讯链接数是线性的，并且由于各组件接口规范的一致性，通讯的复杂度大大下降，也提高了组件的互操作性。

根据组件在系统中功能的不同分为两个层次：核心组件和应用组件。相对于核心组件来说，应用组件所要求的系统服务要少得多，通讯接口比较单一，请求服务的频度也较低。相应地，总线也可以分为核心总线和应用总线，从而形成双总线结构。在这种总线结构中，核心组件和应用组件之间仍然保持良好的互操作性，但应用总线屏蔽了应用组件的一部分服务请求，减少了核心总线上的流量，从而提高了应用软件系统核心的效率。

后来我们发现OSACA的体系结构实际就是定义了一种基于单总线的系统模型，它把应用软件定义为接口统一的组件，而在系统软件层最上层即API层做为它的应用总线，如下图所示：

AO组件

系统软件层

图3-4 OSACA体系结构图

OSACA系统软件层内部的OS、Configuration、Communication构成了核心组件与应用总线API构成了应用软件系统的原型和框架，在此基础上与各应用组件集成。

通常在分布式环境中，更为理想的模型是，应用组件不是直接连结到应用总线(Broker)上，而是通过一个软件代理(Agent)间接地连在总线上。这样Agent一方面代理应用组件的复杂通讯过程，使应用组件更专注于功能的实现；另一方面将适应不同应用需求的组件内部的异构数据转换成同构数据，以保证Broker上通讯语言的统一。由此可见，在基于总线的系统模型中，Broker与Agent构成了介于应用组件(客户)与核心系统(服务器)之间的中间件。这种代理技术的具体实现在Erich Gamma等人于1995年所著的《Design Patterns – Elements of Reusable Object-Oriented Software》一书中所提出的Proxy模式有详细讲述。而OSACA模型中并未加入此类设计，因为设计模式技术在90年代末才开始流行，而OSACA模型在1996年就已经完成。

基于总线的系统模型对于开放式的支持已经近乎完美，然而这样的系统模型也势必带来了开发量的加大，系统的软件实现变得更加复杂。所以在我们实施项目的最后并未完全按照这种总线模型的结构再次重构系统，只是在应用程序内部有类似的实现。譬如：对于算法库的调用，我们在运动控制系统中做了一个算法总线，符合算法模块接口的组件能够即时识别并在界面上提供给用户选择；在PLC系统中做了一个元件库的接入总线，能够识别用户新加入的元件库。这些都是轻量级的专用总线，系统复杂度维护在一定范围内。

下面具体讲一下我们最终实现的系统模型，并对其进行分析。

3.3 iComac开放式数控软件体系结构模型

图3-5 iComac开放式数控软件结构模型

3.3.1 模型说明

iComac的系统模型从总体上分为三层：硬件层、系统软件层和应用软件层。

硬件层主要由基于PC的控制器硬件组成，包括CPU主板、AD/DA模块、I/O模块、定时中断模块等组成。它们构成了软件系统的直接运行平台；

系统软件层由操作系统、配置系统、数控虚拟机(NCVM)、数据中心(DataCenter)、消息中心(MsgCenter)和封装的API组成。操作系统为嵌入式操作系统，将根据硬件特性定制，所有软件的执行基于操作系统之上；配置系统为数控软件的引导模块，它会为数控系统启动一个最小系统，然后根据配置清单加载相应的核心组件和应用组件。系统核心组件为NCVM、DataCenter和MsgCenter，分别提供系统调用、数据处理及通讯任务。在每个系统核心组件和配置系统中，都有一个接口层，他们共同组成了系统软件的最顶层iComac-API，它为应用软件提供最基本的数控系统调用接口；

应用软件层由大量的应用组件构成。在该层，我们提供了一些基本功能组件，如运动控制、软PLC、GUI及GUI配置组件。这些组件属于出厂的基本配置，用户既可以用其它相同功能的组件替换掉，也可以在其上进行二次开发等。对于运动控制，内嵌了运动控制逻辑和基于总线结构的算法组件库等。软PLC内嵌了梯图编译器、基于总线结构的元器件库等。GUI配置用来定制界面的内容、层次、逻辑、组合等内容，用户可以基于该模块进行可视化的界面定制二次开发。

3.3.2 模型分析

一、        开放性

开放性是开放式数控软件的首要目标。根据IEEE关于开放式数控系统的定义，首先要能够有效地运行于不同厂商的平台之上。这里所谓的平台就是指硬件层，因为每个控制器厂商都有独特的硬件体系结构，那么开放式数控就应该能够屏蔽这些差异。iComac模型在硬件层之上由操作系统做了第一层隔离，也就是说一些功能丰富及对硬件支持良好的操作系统能够消除部分差异。譬如我们在开发中选择的Windows CE 4操作系统，它的定制平台为Platform Builder 4，该平台内嵌了大量的硬件设备驱动，包括对一系列CPU架构如ARM、x86、MIPS和SHx等提供支持，通用的硬件设备只要在定制平台时选择对应的驱动包即可完成，而对于操作系统之上的用户开发则没有什么影响。那么对于数控上专用的设备，如AD/DA模块和I/O模块等，我们可以采取两种方法：一种是在定制操作系统时，为其开发单独的驱动打包到操作系统中，这样专门的硬件体系对应相应版本的操作系统；另一种是将这些专用硬件的驱动放到相对于操作系统而言的应用层，即我们的NCVM中，这样操作系统只是针对通用平台，而对于硬件差异则体现在NCVM中，NCVM则成了多版本系统。这样呢，所有平台的差异最多出现在系统软件层，对于应用层软件而言根本看不到这些差异。

然后，开放式系统应该可以与其他应用系统相互操作。这一点由NCVM和MsgCenter来合作完成。因为通讯功能任务的解释和消息分发是MsgCenter负责处理，而在iComac模型中，底层的对于操作系统的通讯接口等都由NCVM包装，这样MsgCenter就专注于通讯内容及消息的处理，而不必考虑通讯协议及接口的差异性。所以只要用户基于NCVM开发与其它应用系统通讯组件，则可以很方便地实现这一功能。

最后，开放式系统应提供具有一致风格的用户交互界面。在iComac模型的系统软件层，我们针对于每个核心组件的接口都有一层封装，他们共同构成了系统软件的API层。不管其下的硬件层或系统软件如何改动，这一层接口（即应用软件与系统软件的用户交互界面）是不会变的，这样就能保证应用层软件的通用性和一致性。

二、        速度及实时性等问题

实时性是数控实现控制的前提，计算速度是实现稳定控制的重要条件。在小型的嵌入式设备中，由于嵌入式处理器在计算速度以及内存、外存等存储空间上的限制，嵌入式软件所面临的最大问题就是速度和存储的问题，开发人员很多精力要花费在考虑浮点的计算、内存的合理分配、大文件调度和存储等问题上。然而，基于PC架构的开放式数控软件则在很大程度上回避了这个问题。由于PC架构的工控机一般采用与普通PC性能相当的处理器板卡，如研华的基于PCI/ISA总线的CPU板卡，已经能够支持到像Intel Pentium 4、Celeron D/Celeron等级别的处理器，前端总线频率与支持的内存容量也都与主流的普通PC相差无二。所以在这种硬件平台上运行一个数控用的控制器软件的基本功能应该是绰绰有余。当然，随着开放平台上添加的功能组件的增多，对硬件平台的要求也越来越高，在单CPU架构满足不了实时性要求的情况下，可能要改变硬件体系架构如改为前后台模式等，关于硬件体系结构问题本文章不做讨论。但是在目前iComac架构下，据我们实际上机床实验测算，在基本组件运转正常(1ms定时中断情况下，前台实时绘图、中间实时运动控制计算、底层三轴实时采样及控制数据输出)，实现三通道（三组并行的运动控制）稳定运行，仅仅需要相当于Pentium II 400MHz 左右的单CPU及 64M SDRAM 133MHz内存即可完全满足需要。

而对于实时性，除了硬件满足要求外，需要操作系统提供可靠的实时响应保障。对于数控系统而言，其计算正确与否，不仅取决于计算逻辑是否正确，还取决于计算结果所花费的时间。如果不能满足系统的时间限制，就会出现系统失败的情况。现在主流的嵌入式操作系统如带硬实时的VxWorks/ucOSII等都能满足要求，而以前饱受争议的WinCE操作系统的实时性也在不断加强，Windows CE从3.0版开始就已经支持硬实时，基于200 MHz x86系统的Windows CE在1ms定时周期情况下的平均响应时间为50 µs。而我们使用的WinCE 4.0以上版本在上面的实验条件下，1ms定时中断，多线程嵌套调用，实时线程的实际响应也完全满足实际计算与控制要求。而WinCE现在已经推出了6.0版，其实时性则变得更加可靠。

基于以上分析，我们可以看出，不论从满足开放性的要求来讲，还是针对于数控本身的特性要求而言，iComac的体系结构已经符合开放式数控软件的基本要求，堪称中国的第一代开放式数控软件。

3.4 对未来系统体系结构的展望

对于系统的体系结构设计者而言，不断改进系统结构的设计以增加系统的适应性，保障软件平台的强大生命力是其不断追求的目标。因此，在致力于发展已有模型的基础上，我们应当多关注于目前计算机科学领域的新发展和动向，并思考它将为我们所在的领域带来怎样的影响，是否应该吸收新技术来增强我们的系统。

纵观面向对象技术的发展趋势，我们可以看到，面向对象技术本身在向并发面向对象技术发展，而面向对象的体系结构也在向面向服务的结构发展。

3.4.1 并发面向对象技术

并行计算是未来计算机的发展方向。将面向对象与并行计算相结合的并发面向对象技术是目前计算机科学正在研究的新领域。

现在我们所使用的主流面向对象程序设计语言(如C++)，虽然表现静态特性的类是按照对象特征去封装的，但是对于程序的执行，仍然只是提供了描述程序顺序执行的能力，即使有些语言(如Smalltalk)提供了描述程序并发执行的机制，采用的也往往是一些传统的并发控制技术，并没有从对象模型本身的特点来考虑，从而造成并发与对象模型中一些概念(如封装、继承及自治等)相冲突。

近年来，许多面向对象并发编程的方案被提出，而其中通过外部库提供并发抽象的手段正成为并发面向对象技术中最为重要的方法。它可以在不修改原有顺序面向对象语言，保留原有编程方法的情况下更好地利用面向对象技术中的一些新特性，容易被用户所接受。

为了在面向对象模型中引进并发机制，并发类库的设计必须能与对象模型中一些现有的特性有机结合，为面向对象程序设计语言扩展描述系统并发行为的能力。此外，这种方法一般还需要某种底层特殊软件(运行支撑系统)的支持，并将支撑系统的复杂性全部隐藏在类库中。顺序对象模型由一组被动的对象构成。系统的执行行为是，外界激活其某个对象的某个方法，该方法的执行中向系统中其他对象发送消息，从而激活这些对象的方法的执行。这里的消息发送就是过程调用，即消息发送者必须等到消息接受者的相应方法执行完毕，才能继续执行下去，整个系统只有一个执行线程。在面向对象的并发模型中，可并发执行的基本单位是对象，称为并发对象。与普通对象不同的，并发对象具有自己的控制线索和独立的地址空间，多个并发对象可以并发运行，通过方法(消息传递)请求相互作用。目前构造并发对象的方案也有几种方式，要么采用异步消息，但不利于把握程序执行顺序；要么采用创建对象产生同步消息发送线程，但容易造成死锁。另外，处于并发环境中的对象，随时都会面临环境对其方法的并发调用，所以又必须对方法的并发调用加以同步控制。同步控制的方法又有若干种，也各有利弊，这都是计算机科学所要研究的内容。

那么在我们目前的数控软件中，也存在这个问题。数控系统本身是一个多任务的环境，要保证实时的采样、运动算法计算、控制数据输出等内容，同时还要负责数据量很大的显示任务和一些突发事件的处理。那么我们在系统中采用了操作系统提供的多线程技术，采用顺序并发调用的方式来调用每个对象，组织起每个对象的行为。iComac中的NCVM组件其中就有一部分功能负责管理并发调用，它实际上是一种面向行为的组件。所以目前软件的这种面向对象架构是建立在外在对象的顺序调用基础之上的。当然，我们可以看到，这种并发面向对象技术要解决的问题很多，其实现也更加复杂，所以该技术能否应用在开放式数控上还是一个有待进一步研究的问题。

3.4.2 面向服务体系结构

随着组件技术的不断发展，人们针对一些大型的系统开发出的许多的异质组件，这些异质组件用的开发语言不同，尽管组件是兼容的，但调用方法不同，尤其是在网络应用中，往往当位于防火墙后的组件被定位后，消息却无法通过防火墙。程序员们不得不花费大量的精力和时间来处理它们的不兼容性。即使没有异质组件的兼容问题存在，组件之间仍然需要深度的互相了解。比如要想使用一个声明组件（claim component），除了知道数据传输协议和数据报文格式以外，还必须知道它的准确位置，并且还要很清楚地了解有关其接口的一切，以便应对接口变化。而这些组件都有网络编址接口，访问者有可能很多，从而形成了一种很大程度的依赖关系。因此在企业应用中，往往因为功能得不到满足，或者程序修改起来工作量巨大而不得不重新开发新的软件，造成一些已有的技术不能充分利用。在这种情况下，人们提出了面向服务的体系结构SOA（Service Oriented Architecture）。

面向服务的体系结构是在原有的应用组件功能之上再做一层封装，称为服务层，应用程序功能作为服务提供给终端用户应用程序或其他服务，向企业提供业务解决方案，这样基于服务的系统架构就无须考虑应用组件层面的运行平台或开发语言等方面的问题，服务实现的过程对于服务请求者来说是透明的。

基于这种思想，考虑我们的数控软件，即在开放式数控模型的应用软件层之上再封装一层，构成更大的功能模块，即一种特定功能的服务。譬如：机床中的换刀功能，是数控软件中的一个大的基本功能，它要由运动控制系统和PLC系统协作完成，但是各种机床刀库不同，具体实现换刀的方法和程序实现也不同，包括可能会出现不同语言编写的组件，这些都表现在应用组件层，所以组成的换刀功能调用也不尽相同。如果仅仅是单机应用可能只需在调用者组件这个层次稍作修改即可，但如果该数控软件集成到分布式网络环境中，对于远程控制系统而言，换刀功能的调用接口不统一，会造成很大麻烦。所以，SOA的结构是对更高一层应用的封装。在今后的网络化制造和无人工厂技术等发展起来以后则是大势所趋了。

3.5 对体系结构探索的反思

面向对象方法的关键在于它的分析方法和人对现实世界事物的分析方法是一致的，所以如果分析者对现实世界的认识很不够，面向对象方法模拟出来的业务模型就不够准确，那么现实世界的一些规律也不会方便准确地在所开发的系统中得以体现。

为了发现对象和类，面向对象设计人员需要清楚地了解所要设计的对象，仔细分析系统需求，找出其中最重要的对象和其责任。当重要的对象被发现后，通过一组互相关联的模型详细表示类之间的关系和对象的行为，然后才能一步步建立面向对象的模型。这是面向对象设计初期最重要的任务。那么在建立对象以及描述关系及行为的时候需要依据一定的基本准则，软件工程学上已经对此作出了概括。

基本原则是行为所依据的法则和规范。无论什么方法学从知识工程角度来说，都是运用软件工程方法学基本原则的规则、策略及工具的集合。其中抽象原则是最重要的，它给出软件工程问题求解全过程的最基本原则，其他原则是对抽象原则的补充。

指导如何抽象的基本原则大体上可以分为体系规范原则和模块规范原则两类。前者是规范整体解题思路及解的验证，包括形式化原则、分割原则、层次原则、概念完整性原则、完备性原则。这些原则在面向对象方法问题上表现为对象模型 (对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)，“关系”抽象较多依据此类原则；后者则是与子问题有关的原则，包括隐蔽原则、局部化原则、逻辑独立性原则。这些原则正是面向对象中设计模式技术所研究的对象，“对象”抽象较多依据这些原则。而对象抽象与关系抽象原则是一样的，都是从高级到低级、从逻辑到物理，逐级细分，每一级抽象都重复对象建模 (对象识别)→动态建模(事件识别)→功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现。

纵观我们这几年基于面向对象系统体系结构的构建过程来看，我们一次次的改进模型，一次次的重构，无非也就是在不同级别层次上重复着上面这些步骤。即使将来的模型改动也同样是在更高层面上依据这些原则进行再抽象。那么有人会觉得为什么不一下子就设计一个很先进很完美的体系结构呢，尤其是我们前几年摸索过的模型技术，在计算机领域已经成型好多年了，而我们却又一次次的重复开发，这究竟是为了什么？

软件工程之所以称为工程，就说明工程的实施就不单单是个技术问题，它包括工程实施过程中所设计到的人财物等等各个方面。我们的工作之所以走了这样的一条曲折之路，我认为有以下两个方面的原因：

一方面，开发人员的成长问题。我们的开发人员都从刚毕业的大学生开始，第一次真正进入工业领域进行软件开发。不论是计算机技术还是对所研究对象都了解不深。所以，大家对面向对象的技术有一个由浅到深的过程，还有对实际物理对象的认知过程，也就是说做数控软件的开发不像做普通应用软件譬如说做个聊天软件，大家对对象行为都有所了解，不需要很深的行业背景。而数控软件的开发难点在于它的学科综合性，刚毕业就对两方面知识都有很深了解的人几乎是没有的。而从业多年的人也顶多是对其中一方面较为精通，另一方面有所了解。除了我们做的iComac，国内迄今还没有哪个公司完完整整得从头研究和开发过全套的开放式数控软件，所以这方面的人才十分缺乏，许多理论知识我们必须从头摸索。然而这一次次的重构从培养数控人才来讲未必不是一件好事，他让我们更加清楚地认识到如何用更先进的技术手段来解决实际应用领域像数控这样复杂的系统解决方案。有些弯路走得还是非常值得，有些事情不亲自去做是不会明白其中道理的。

另一方面，开发成本和效率的问题。无论是用什么方法学开发软件，交给用户的都应该是满足用户当前需求的软件。用户在短期内不会发现开发者使用先进方法学给他们带来的益处，不能理解到软件的长期质量（包括维护成本低和生存周期长）给用户带来的好处才是根本的，倒是开发者本身由于大大减轻了开发负担而最先受益。但作为一个有长期发展眼光的企业来讲，又不能只顾眼前利益。所以在开发的时间、成本、人力等等方面都有所考虑和权衡。我们从iComac模型的演变可以看出，一种模型比一种模型更先进，但是我们必须看到，先进的同时带来了工程的更加复杂。一座摩天大楼是比筒子楼要舒服很多，但也带来了巨大的资金投入和时间成本，并且需要更优秀的建筑师和更高级的施工人员才能完成。工业用软件，稳定可靠是其根本，只有成熟的软件技术在被充分论证后应用到工业上来，能为用户带来巨大的经济效益，才能被用户所广泛接受。所以，对于公司行为的研发而言，是否能够长期稳定地提供成熟的产品和技术支持，是其能否良好发展的基本条件。产品的研发是要本着实用的原则，而不是一味地追求高精尖的技术，尤其是在工业领域。所以，产品的开发是一个技术与市场权衡的产物，脱离任何一方都是不现实的。

虽然我们在这些年的开发中走了些弯路，但我们的团队从中领悟了许多东西，从软件技术到数控知识，从计算机领域到工业领域，从技术本身到项目管理甚至企业管理。为打造中国独立自主的开放式数控软件迈出了具有实质性意义的一步。

3.6 本章小节

本章主要通过介绍iComac开放式数控软件在体系结构方面探索的过程，讲述了iComac在各个阶段采用的各种层次的软件体系结构，并分析了其优缺点。首先讲述了软件体系结构的重要性及与开放式数控的关系。其次开始详细讲解了各个时期基于面向对象技术的iComac软件体系结构，包括原始面向对象的系统模型、基于对象的组件体系结构模型、基于中间件技术的系统模型和基于总线的系统模型。再次，展示了iComac的最终软件体系结构，并就其开放性和速度及实时性等问题进行了分析，说明了基于PC架构的开放式数控软件的平台优势。然后从未来面向对象技术发展的方向——并发面向对象技术和面向服务体系结构方面对未来开放式数控软件的发展进行了分析并提出了看法。最后，对体系结构探索过程进行了反思，分析了探索过程中的得与失。本章是体系规范探索内容，下一章我将详细介绍一下模块规范探索——面向对象技术在开放式运动控制系统中的具体应用。

第四章 开放式运动控制系统

4.1 运动控制系统概述

在数控软件中，运动控制系统MCS(Motion Control System)一直是软件的核心部分。不论是基于PC的数控软件，还是运动控制卡上内嵌的控制软件，都少不了MC模块。该模块里融合了数控的最精华部分，是各门学科的综合理论知识的汇总体。下面简单介绍一下运动控制模块中最重要的几大部分：

4.1.1 运动轨迹控制算法——插补

所谓“插补”就是指对一条已知起点和终点的曲线进行数据点密化，协调几个独立的坐标运动配合成一条曲线运动。插补的任务就是根据进给速度的要求，在一段零件轮廓的起点和终点之间，计算出若干个中间点的坐标值。CNC系统中具有的插补功能有直线插补功能、圆弧插补功能、抛物线插补功能以及螺旋线插补功能等，越高档的数控支持的插补功能越多。当然，在开放式数控中，插补功能将作为可插入组件形式存在，所以系统的能力随插入组件的不同而不同。直线和圆弧插补功能采用的插补算法一般为脉冲增量插补算法和数字增量插补（数据采样插补）算法。对于步进电机的开环控制系统而言，一般采用前者；而闭环系统一般采用数字增量插补算法。所以，插补是数控系统中运动控制数据产生的核心部分，它的正确性、效率与支持的插补功能将直接影响到整个系统的稳定性和决定系统的功能和性能。

图4-1 插补轨迹示意图

4.1.2 自动控制理论

自动控制，是指在无人直接参与的情况下，利用控制装置（控制器）使被控对象(如生产过程中的位移、速度、温度，电力系统中电压、电流、功率等物理量或某些化合物的成分等)，依照预定的规律进行运动或变化。这种能对被控制对象的工作状态进行控制的系统称为自动控制系统。它一般由控制装置和被控对象组成。数控系统的控制装置一般由专用的或者基于PC的控制器和单轴控制器（如伺服、变频器等）组成，被控对象就是驱动部件（如电机等）。

数控软件中的自控理论主要是在已知控制系统结构和参数的基础上，求取系统的各项性能指标，并找出这些性能指标与系统参数间的关系，这就是自动控制系统的分析。而在给定对象特性的基础上，按照控制系统的应具备的性能指标要求，寻求能够全面满足这些性能指标要求的控制方案并合理确定控制器的参数，则是控制系统设计的任务。自动控制理论是对自动控制系统进行分析和设计的一般性理论，它是指导整个控制系统设计的理论依据，其合理性直接影响到整个控制系统的稳定性等方面。

一个控制系统一般可分解为被控环节、控制器环节和反馈环节三个部分，其中被控部分和反馈部分一般是根据实际对象而建立的模型，不可变的，因此根据要求对控制器进行设计是控制系统设计的主要任务。同时需要指出，由于系统设计的目的也是对系统性能的校正，因此控制器（又称补偿器或调节器）的设计有时又称控制系统的校正。

图4-2 闭环控制系统

 

一般的控制系统均可大体表示为如图4－1的形式。未校正前，系统不一定能达到理想的控制要求，因此有必要根据希望的性能要求进行重新设计。在进行系统设计时，要对控制系统结构进行选择。对单输入、单输出系统，一般有四种结构可供选择：前馈校正、串联校正、反馈校正和复合校正。串联校正比较经济，易于实现，且设计简单，在实际应用中大多采用此校正方法。典型的校正方法有超前校正、滞后校正、滞后－超前校正和PID校正等。

在数控系统中，控制系统结构的选择往往在整个系统设计时已经确定，数控上最常见的也就是这种串联校正方式。但是，对于开放式数控而言，软件平台不应该固化控制方式，具体的控制方案也是包含在运动控制系统的一个组件之中的。当然，现代的数控已经大部分将控制理论的东西放到伺服软件中完成，从控制理论上来说，伺服也是控制器的一部分。不过对基于PC的数控软件而言可能就仅仅做一个开环系统输出控制数据即可，不需要任何控制理论的东西，但对于开放式数控，为了适应整个系统设计或者外部硬件体系的改动，仍然需要设计能够插入该控制组件的接口。

4.1.3 运动控制逻辑

运动控制系统的作用是把来自上层的加工文件或者加工指令，沿着符合运动学规律的轨迹微分成指令周期级的微小位移量，然后在自动控制理论的调整下输出给接收方。这个过程要受运动控制逻辑的协调，保证正确的模块在正确的时间做正确的事情。但是运动控制逻辑不是理工科上的哪一门学科，它更像是逻辑学或者行为学，因为它与具体的对象行为有关，也与用户提出的操作需求有关，它研究的是这些行为和操作对控制系统造成的影响以及如何处理它们之间的关系。一台最普通的数控冲床的运动控制逻辑与一台带五轴联动的车铣复合加工中心的运动控制逻辑在复杂程度上有着很大的差别。一般的数控都具有自动加工、手动加工、MDI等功能，稍微高级一点的可能有测量功能、自动中的手动补偿功能甚至仿型功能。那么这些功能在运行时，可能要配合动作，也可能要有互斥操作，甚至有可能根据当前状态来决定配合还是互斥。那么这些功能都是运动控制逻辑要负责研究的对象。

有些人可能认为运动控制逻辑无需做的全面而复杂，其中某些部分可以放到其它组件，譬如说界面中。这在专用数控系统中，如果系统没有大的改动是没有问题。但是在开放式数控中，每个应用组件都是可以替换的，你不可能总是能保证被替换上的组件中包含了你所需要的逻辑，一旦有所遗漏，可能就会造成控制逻辑混乱，后果不可想象。也就是说对于运动控制系统，它不能把自己的安全问题寄托于其它组件的保证之上，它应该自成体系，有了额外的保护它更加安全，没有也能够自我保护，这样才能形成一个完整的运动控制系统。从面向对象的角度来讲，运动控制系统中也应该将其内部的行为逻辑封装到对象之中，才符合面向对象的封装性原则。

4.2 iComac运动控制系统

4.2.1 OOA

数控机床上的数控技术主要是面向工艺的运动控制，这是与普通过程控制的本质不同。既然面向工艺，就要让我们的数控系统的各种运动执行部件在符合运动学规律的前提下，尽最大可能地高速高精度地按照用户的指令所指定的轨迹去运动。普通机床上的轨迹一般都是指所装配刀具的刀尖所运动轨迹，对于激光切割机床就是激光头发出的激光束所运动轨迹，而电加工就是电火花运动轨迹。而这些轨迹是空间轨迹，为了描述其方向，数学上建立了笛卡尔坐标系，那么这些轨迹就可以看作是X－Y－Z空间区域内的矢量线段。所以普通铣床一般三座标居多，靠三个方向的轴向运动来合成空间轨迹。而车床一般都是两轴X－Z，再加主轴的旋转完成轨迹。另外，复杂的五座标甚至更多坐标的机床是靠各组联动轴配合运动走出的轨迹。所以，各轴的运动控制数据是否精准及同步配合高度一致，是决定能否在加工工件上走出理想轨迹的先决条件。

 

这里简单概括一下iComac运动控制系统的需求，大致能够实现以下功能：

1、每采样周期（毫秒级）输出一次控制指令；

2、从外部存储介质中读取加工程序文件实现自动加工功能；

3、MDI、INC、JOG、返参功能；

4、通过接口设置运动控制系统参数功能；

5、主轴控制功能；

6、与PLC配合换刀功能；

7、运动中响应变速、停止功能；

8、自动加工中允许手轮叠加修正加工轨迹功能；

9、多通道运动控制功能；

图4-3 iComac MCS UseCase

运动控制系统的需求是用户透过其上层界面传递过来的，对被控对象实施操作的行为要求。大部分功能都是围绕着让受控对象如何运动而提出的。根据面向对象思想，我们把MCS作为分析对象，那么上面提出的需求分为三大部分：

第一、针对对象行为的需求，如：自动加工、MDI、INC、JOG、换刀、返参、主轴控制等操作；

第二、针对对象属性的需求，如：设置MCS参数；

第三、针对对象本身的需求，如：多通道运动控制功能。

4.2.2 OOD

通过上面的需求分析，结合数控本身的特点，不难看出，我们所要设计的软件的基本对象就是数控的受控对象——轴，它们承载着来自上面的各种运动指令，是运动的实际执行体。我们描述运动轨迹用笛卡尔坐标系来描述，用户编加工程序一般也按照笛卡尔坐标系来编，然而，实际的机床并不都是三座标机床，复杂的机床往往是三座标以上。所以，在这里，我们把轴又分为两种类型——坐标轴和物理轴。坐标轴只有X-Y-Z三个方向，而物理轴是对应机床上具体的运动轴。我们接收和描述运动轨迹以坐标轴描述，而在MCS的插补器中将控制数据按照控制规律分解到各个物理轴上。而这两类轴又具有大致的共性，所以我们将其抽象成一类，这样我们就得到三种对象类——坐标轴类、物理轴类及其公共抽象轴类。

根据需求的第三部分：多通道运动控制功能，我们知道仅仅抽象轴类是远远不够的。通道是配合完成同一动作的一组轴及其相关设备的抽象承载体。那么多通道即是要实现同一控制器下多种动作的同步控制，多个通道的行为可能独立也可能相关。譬如车铣复合系统，为了提高工作效率，对一个加工件同时进行车和铣操作，如果不发生干涉则是两个通道的独立行为，否则就要处理互斥问题。另外多个机器人或机械手臂的协同工作即为多通道配合问题。那么在这个层面上看，通道就是我们要分析的对象，我们把该类对象抽象出来就得到了通道类。通道类是我们运动控制的一般单位，来自上层的运动控制指令像自动手动等，都是发给通道，然后由通道协调所管辖的轴进行配合运动。那么通道中为完成这些动作，就要实现从输入指令分解开始，到多轴插补到输出控制等一系列功能。在iComac的通道内部，我们按照功能，继续按照面向对象思想划分出几大行为对象，这些对象主要构成以下几大功能：

1、编译器(Compiler)——用来处理来自上层的加工指令，包括打开自动加工文件，读入MDI/INC/JOG指令，对这些加工指令进行词法语法检查，然后处理成MCS系统内部所能识别的加工语句；

2、解释器(Interpreter)——将编译器输出的加工语句按照数控标准术语规范进行语义层分析与解释，解释成功将指令数据放入相应的指令对象中并压入指令队列；失败则向上层抛出错误信号及原因。譬如：用户进行G02圆弧操作，给出的坐标值并不能构成圆弧，解释器要将该错误封装成异常对象抛给调用者，然后经由MCS系统抛给上层界面等。如果加工正在进行，解释器要同时产生加工停止语句，保证加工执行到此不发生故障；

3、插补器(Interpolator)——从指令队列中取出解释器送来的指令对象，执行多轴插补算法，具体功能前面概述中已叙述，这里不再赘述；

4、执行器(Executor)——将各轴的插补数据经过闭环反馈算法运算后，输出给各物理轴。执行器本身与闭环反馈算法都以组件形式提供。

另外，为了对通道对象进行管理，特设置了运动控制管理模块，作为通道组件向系统中插入的代理平台。系统结构模型示意图如下：

图4-4 MCS结构模型示意图

4.3 设计模式的运用

4.3.1 设计模式概述

设计模式描述了在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案[7]，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

由于面向对象的初学者可能不会很快地掌握设计的一些原则，比如如何可重用代码，如何让代码更容易被他人理解，如何保证代码可靠性以及如何为了适应未来的变化，在最大程度上保持设计的干净、简单等。那么设计模式提供了一些通用的原则，设计者可以通过分析自己的需求来借鉴或者直接套用某种模式以达到快速开发的目的。设计模式理论的总结使软件开发进一步实现了工程化。

4.3.2 状态模式(State Pattern)

在MCS中，最重要的模式为状态模式。因为不论是通道还是各种轴，它们的状态切换是运动控制过程中频繁进行的，状态判断与选择正确与否直接关系到运动控制逻辑的正确性。并且，针对于控制对象以后可能的状态扩充、修改问题，考虑状态与对象本身行为分离的问题，宜采用状态模式。

我们以最简单的轴的状态切换为例，看一下状态模式的应用:

轴的基本状态目前分为五种：

就绪态    —— 轴处于自锁状态，运动控制数据输出为0；

独立运动态—— 调用为其配置的单轴独立运动算法，进行单轴运动控制；

受控态    —— 本轴控制数据来自于上层，内部不产生控制数据；

返参状态  —— 调用为其配置的返参算法，进行单轴返参；

异常态    —— 内部逻辑运行异常或数据错误跳入该状态；

每一种状态都必须回到就绪态后，才能切换到另一种状态。

轴的基本状态关系图如下：

图4-5 轴状态关系图

根据轴状态图和状态模式，我们设计类图如下：

图4-6 轴与轴状态类图

 

以下是程序的部分代码，以说明模式在程序中的具体应用（粗体字部分为状态模式相关代码）：

1、        轴基类。首先前向声明状态基类，然后在基类中持有一个状态指针，用以保存轴当前状态。另外提供一个状态切换函数，用于切换轴当前状态。

 

class CAxisState; // 声明轴状态基类

class CAxis     // 轴基类声明

{

public:

         CAxis();

         virtual ~CAxis();   

public:

    // 加载单轴算法库

    // pAlgLib库全路径名

    HMODULE LoadAlgLib(LPCTSTR pAlgLib = NULL);

 

    // 选择单轴算法

    void SelectObjAlg(SOLOALG myAlg) {

        m_lpSelectSoloAlg(myAlg);

    };

 

    // 加工停止

    virtual void NCStop();

   

    // 获取加工数据,返回状态值正常输出暂停结束

    virtual int GetData();

   

protected:

    // 切换执行器模式

    void ChangeMode(CAxisState *pAxisState) {

        m_pAxisState = pAxisState;

    };

 

public:

    // 当前指令

    double* m_pCtrlCmd;

 

    // 当前控制对象参数

    AxisConfig* m_pAxisConfig;

protected:

    // 当前模式

    CAxisState *m_pAxisState;

 

    // 单轴算法动态链接库句柄

    HMODULE m_hSAALib;          

};

2、        轴状态基类。包含轴基类头文件，抽象子状态类的公共接口，接口中以轴的指针作为参数指明对哪个轴进行操作。

#include "Axis.h"

class CAxisState  // 控制模式基类

{

public:

      CAxisState();

      virtual ~CAxisState();

public:

    // 获取加工数据

    virtual double GetData(CAxis *pAxis, int & StateFlag) = 0;

 

    // 设置JOG参数

    virtual void SetJOGPara(CAxis *pAxis, int  iDirect  = 1, dINCLen  = 0.01) = 0;

 

    // 加工停止

    virtual void NCStop(CAxis *pAxis) {

        pAxis->m_lpNCStop();

    }

protected:

    void SetAlgPara(CAxis *pAxis, double  dINCLen  = 0.01,iMode  = 1)   {

        pAxis->m_lpSetAlgPara(pAxis->m_pAxisConfig, dINCLen, iMode);

    };

 

    double GetAlgData(CAxis *pAxis, int & StateFlag) {

        return pAxis->m_lpGetAlgData(StateFlag);

    };

};

 

3、        轴状态子类。包含轴状态基类，重载基类纯虚函数。这里受控态使用了单件模式，用于保证该系统中仅存在一份受控态对象。

单件模式需要声明该类构造为私有函数，声明一个该类的静态成员以保存唯一对象。声明一个公有的获取对象指针函数，在该函数中保证对象仅被构造一次。

 

#include "AxisState.h"

class CAxisControlledState : public CAxisState 

{

private:

         CAxisControlledState() {};

         virtual ~CAxisControlledState() {};

   

public:

    // JOG模式对象获取函数

    static CAxisControlledState *Instance();

   

protected:

    // 获取加工数据

    virtual double GetData(CAxis *pAxis, int & StateFlag) {

        return GetAlgData(pAxis, StateFlag);

    };

   

    // 设置JOG参数

    virtual void SetJOGPara(CAxis *pAxis,  iDirect  = 1,  dINCLen  = 0.01);

 

private:

    // JOG模式单件指针

static CAxisControlledState *_instance;

};

 

CAxisControlledState * CAxisControlledState::_instance = 0;

 

CAxisControlledState * CAxisControlledState::Instance()

{

    if(!_instance) {

        _instance = new CAxisControlledState;

    }

    return _instance;

}

4.4 运动控制系统的开放性分析

从MCS结构模型示意图可以看出，它也是由一系列组件组合而成，它的基本组件包括：运动控制管理模块、通道模块、编译器、解释器、插补器和执行器等。

运动控制管理模块又是通道模块的代理组件，它负责通道组件在MCS中的接入，可以让用户很方便地扩展多通道功能；

通道组件又是编译器、解释器、插补器、执行器和各种轴的管理组件，与他们形成了一种组合关系，轴在其中可以通过配置文件等形式进行添加、删除、修改等操作；

编译器负责词法语法检查和文件读取分析等功能，如果规则有所变化，也可以方便地将该组件替换掉；

解释器配备了多种加工文件标准，系统集成商可以根据具体产品识别的加工文件类型不同而为其配备不同的加工文件标准。当然也可以同时识别多种标准；

插补器更是根据具体机床的高中低档不同或者加工用途不同配备不同的插补算法程序。可以让用户通过界面选择本次加工采用某种插补算法，甚至可以做到每段曲线插补算法不同；

执行器中包容了自动控制理论的经典控制算法，也可以方便的替换。这些算法的参数也将通过界面透露给用户，以方便用户调节控制参数；

另外，通过设计模式的使用，即使在组件内部，调整程序逻辑也是一件非常轻松的事情，软件复用技术在这里得到了实际应用。

通过以上分析，我们可以看出，不论从系统整体结构来看，还是从MCS的局部特征来看，其开放性是全方位的。MCS提供统一标准的接口，所以作为应用程序模块不论是插入iComac数控平台，还是插入符合标准API的其它开放式数控平台，都是很容易实现的。所以我们说MCS是一个完全符合开放式标准的AO。

4.5 本章小节

本章主要从iComac的运动控制系统的角度，分析了面向对象技术在开放式应用软件层中的具体应用。首先，概述了运动控制系统的功能作用及主要组成部分，谈到了运动控制中最重要的三种技术：插补、自动控制理论和运动控制逻辑，提出了MCS对于开放式要解决的主要问题。其次，运用面向对象分析技术从具体的需求入手，把需求按照面向对象的组织方式分成三部分。再分别根据这些需求，结合数控本身的特点设计了MCS的基本模型。再次，本章重点提到了设计模式的运用，叙述了它能为软件开发带来的重要作用。然后以状态模式为例，具体讲述了设计模式在详细设计中的应用。并列出了部分具体代码，指明了与状态模式相关的具体实现。最后，通过对MCS模型整体设计和局部设计特征，对本章所提出的运动控制系统组件的开放性进行了分析，得出了其符合开放式标准的结论。

第五章 系统评测结果与分析

5.1 实验环境

从软件工程学的角度来讲，这里的实验为系统最后的集成测试，包括iComac系统的核心组件和基本应用层组件。

由于iComac平台的开放性，所以我们测试其功能与性能时，只需把平台相关模块改造成适合某种具体平台即可。其实现复杂程度正好可以验证系统的开放性。我们分别针对普通PC平台、三座标铣床、五座标卧铣加工中心实现了三套系统。

下面简单介绍一下这三种平台的实验环境和测试内容（实际测试内容和步骤要复杂得多，这里不便一一列举）：

5.1.1 普通PC平台

硬件环境：CPU Pentium 4 1.70GHz，内存DDR333 512MB，可用硬盘空间 > 10G ；

软件环境：Windows XP Professional + sp2操作系统

验证内容：软件的可运行性、核心组件的稳定性、部分主要应用层组件的功能性，验证10个通道并行控制的计算能力

测试方案：

1、观测系统能否正常启动；

2、手动功能(INC/JOG)测试。对比输出结果看是否与期望值相符；

3、MDI功能测试。输入一段加工指令，分析输出结果；

4、自动功能测试。输入文件长度在200K之内的标准G代码加工文件，通过GUI观测是否能够正常加工，然后分析最后结果，看是否符合加工要求及是否与GUI显示结果一致；

测试方法：由于GUI提供了丰富的观测功能，所以这部分测试主要通过观察人机界面显示内容来查看系统的运行情况。某项功能运行完毕，分析从程序内部测试模块打印出的轨迹数据，然后用专门的分析软件绘制成轨迹曲线，计算结果是否符合运动学规律要求。

5.1.2 三座标铣床

硬件环境：

控制器采用基于ISA总线的工业用PC，采用CPU板卡加IO模块，AD/DA板卡方式，CPU PMMX 400MHz，内存SDRAM 128MB，电子盘DOM 64M ；

三台交流模拟伺服、三台伺服电机、一台变频器控制一台大功率主轴电机；

三座标铣床，丝杠传动，3对行程限位开关和零点开关；

软件环境：Windows CE 4.2操作系统

验证内容：软件的可靠性、核心组件的稳定性、已实现应用层组件的功能性，单通道的铣削加工能力

测试方案：

1、用蜡模和铝模模仿加工工件，进行实际切削；

2、观测系统能否正常启动以及启动后能否实现稳定的闭环控制；

3、加工能力测试。重复PC上的各种功能测试，进行实际切削，并仔细观察切削过程中是否出现异常。最后观察工件的切削轨迹，看是否符合工艺要求。

测试方法：实际加工测试，除了通过观察人机界面显示内容来查看系统的运行情况外，还要通过观察走刀、听刀具切削声音、摸驱动部件及机床本身振动等方面来判断系统是否工作正常。当然，这其中可能有硬件设备如伺服、电机、机床等的问题，需加以明辨。

 

5.1.3 五座标卧铣加工中心

硬件环境：

控制器采用基于ISA总线的工业用PC，采用CPU板卡加IO模块，AD/DA板卡方式，CPU PMMX 400MHz，内存SDRAM 128MB，电子盘DOM 64M ；

五台交流模拟伺服、五台伺服电机、一台变频器控制一台大功率主轴电机；

五座标卧铣加工中心，XYZ丝杠传动，AC旋转轴，4对行程限位开关和零点开关；

软件环境：Windows CE 4.2操作系统

验证内容：五座标功能

测试方案：在旋转工作台上放置工件，用刀尖与工件表面一点接触，然后手动走XYZ三个坐标轴，测试五轴的配合跟随特性。

5.2 实验结论及误差分析

首先是开放性的测试。最后统计表明，具化时间的80％左右花费在了解具体机床等工艺细节内容上，只有不到20％的时间用于用户编程实现和组件替换上。而这些时间又随开发人员对具体对象的认知程度和实际编程能力以及对iComac体系结构的熟悉程度有关。

然后在PC机上的测试，测试模块所记录的实际输出数据完全符合控制要求，并且轨迹曲线也符合运动学规律。而对于功能，涉及到具体机床，则要设计很多与GUI和运动执行有关的功能，以符合和方便用户操作。开放式正好提供了这一能力，把这部分功能扩展和完善留给了机床制造商和最终用户来完成，所以我们作为控制器制造商来说就不必过多考虑该方面问题。

三座标铣床的蜡模和铝模工件切削完成。轨迹符合程序描述，但轨迹的光滑度存在一定问题，后来分析主要原因是刀具半径过小，主轴转速过低造成。

五座标功能验证演示了无论三个坐标轴如何运动，刀具如何旋转，刀尖与工件表面接触的一点始终同步跟随，不离不弃，很好得验证了本软件的五座标功能。由于五座标加工程序编制比较复杂，所以迄今仍未进行五座标实际加工实验。

上面的三组测试演示完毕后，iComac开放式数控软件通过了北京市科委组织的专家组验收，符合开放式数控软件的各项要求。该项目历时三年，通过10多位软件开发人员的努力和不断探索，最终得以完成，在中国数控史上具有划时代意义。

5.3 本章小节

本章主要是进行实验的验证和分析。通过三种实验环境，分别验证功能、性能和加工能力等方面。实验过程中通过编制和修改软件组件对具体环境的功能具化，不断验证了作为开放式软件的首要目标——开放性。对于功能的扩展，指出了开放式为机床制造商和最终用户保留了空间。

第六章 总结与展望

6.1 回顾和总结

本人立足于工业领域的开放式数控软件，通过分析开放式数控的特点和计算机技术领域的面向对象技术，将二者有机结合起来，用面向对象的思想来实现开放式数控软件，并为此用了五年多的时间来进行研究和开发工作。并在此期间完成了北京市科委立项的开放式数控软件项目。

面向对象的思想可以应用在系统体系结构设计、软件模块的设计以及具体的程序实现设计，并由此衍生出很多新的概念和技术路线。我跟随技术的发展和研究开放式数控对技术的要求，致力于用面向对象方法来提高数控软件的开放性，力图设计更为良好和易于修改的系统架构，以使该数控软件成为一个良好的平台，符合行业标准，便于系统集成商和最终用户加入自己的功能，使其保持持久的生命力。

同时，作为软件开发人员，我也同样关注于软件的实现。因此也不断研究面向对象技术在软件具体实现方面的技术。从面向对象的各个角度，努力提高软件的可复用性、封装性、可扩展性等等。

虽然我们目前开发的iComac已经符合开放式数控软件的标准，但是仍然有许多问题需要解决。既然是开放式，就不能仅仅自己用就算开放，它需要得到业界的广泛认可和接受，只有该软件有大量的用户在使用，并且有包括第三方开发者在其平台之上开发符合接口定义的第三方组件的时候，这个软件才算是真正的开放了。而距离这一步，我们还很远，这除了从技术上保证平台的更加稳定和良好的扩充性外，国家的支持和企业的商品化运作起到了关键性的作用。因为这是一个互相促进的问题，软件有人用了才能不断改进，不断改进了，问题少了，更好用了，才会被更多的用户所接受。但是目前，在很多方面还存在着问题。

首先，开放式控制系统的标准并未统一，平台问题没有解决。无论是国内国外，各控制器厂商开发的开放式系统平台所采用的体系结构和通信协议并不一致，结果是自成体系，相互之间缺乏兼容性和互换性，因而不同体系的系统软硬件不具备实际的可移植性和互操作性。

其次，各控制系统开发厂商的开发能力参差不齐。好多开发商并未充分利用计算机领域的新技术和新思想，软件开发思想与技术落后，始终处于甚至低于结构化程序设计的水平。没有充分利用面向对象、软件重用等软件工程中的新理论、新技术，无法很方便地实现开放式控制系统。这样，采用高端技术的开发厂商很难将采用低端技术厂商的平台统一到一起，而这些低端技术厂商可能还占据着大部分的市场份额，即使有能力开发也会因为惯性太大而无法转舵。平台不统一就仍然无法实现真正的开放。

此外，开放式产品属于新兴技术，市场占有率很小，因此其产品的升级、更新、修改和维修仍然依赖于生产厂家，各控制器生产商还未来得及提供充足相应的开发工具和环境，让用户很方便地把自己的或任何第三方的思想或产品融入到现有产品地系统中去。所以，开放式的普及需要一段时间去发展。

iComac目前也有上面这些问题。因为我国的开放式数控标准还未制定完毕，没有统一的国标，而我们开发的平台是根据国内外标准自行制定的，目前尚未得到其它厂商的支持和认可。而国内现有的成熟的控制器产品大部分采用的都是很低端的计算机技术，甚至根本就没有控制器软件的核心技术，所以短时期内很难将其统一，形成事实的行业标准。

6.2 对未来的展望

目前国外全力致力于真正开放式系统开发的大部分都是一些新兴的相对较小的公司如美国的OPTO22，SOFTPLC，CONTROLSOFT以及英国的TRANSMITTON等等[6]。因为这些公司没有历史包袱，推出的开放式控制系统也不存在抢自己饭碗的问题，所以他们以开放性为主要宣传的卖点。但工业行业是个相对稳定的行业，开放式数控目前仍处于起步阶段，用户都不愿意拿自己公司的利益来尝试新技术，所以目前开放式数控并未对目前的市场领导者所占据的传统控制系统市场构成威胁，因此，大公司并未在开放式上投入过多精力，而只是对现有市场产品进行维护。

然而，经过若干年的发展，当开放式系统在市场上占到一定份额时，目前市场上的大公司一定会加以重视，很快地推出自己的新一代开放式产品。这样就可以加大用户对开放式系统的接受程度，更快地推进开放式系统的发展。这时，大公司有市场渠道、服务、价格、系统集成经验等方面的优势，小公司有在开放式控制系统方面多年积累的经验优势，二者可以在一定程度上进行同台竞技。

开放式控制系统未来最主要的工作在于软件平台的标准化方面，如何打破各大控制器厂商之间技术和利益的壁垒是最困难的事情。在这一方面，中国的厂商可以利用后工业的优势，选择对自己有利的先进的体系结构和技术路线，然后以传统以来中国产品低价的优势打入市场。然而从另一方面来讲，由于国内的控制器生产厂商都处于初创期，没有足够的资金和精力来使国内各厂商进行合作，所以通过什么样的方式鼓动大家，使大家愿意放开短时间的小利而放眼全球的大市场将是一个很困难的任务。

而对于中国市场，将来开放式控制系统的发展可能有两条道路：

第一、由国家出面，大力扶植目前有市场能力的企业，开发出符合自己国家标准的开放式控制平台。然后以行业行政手段加以推行，如规定必须符合此开放式标准的控制系统才能在国内销售、对生产符合标准的开放式控制系统的厂商提供行业补贴或者给予税收上的优惠等等政策。这样将保证中国自己的开放式数控得以发展，但要注意到与国外标准的兼容性；

第二、国外控制系统的开放式标准成了事实上的行业标准，然后进入中国，最后一统国内的开放式控制系统市场，使中国现有的开放式控制器生产厂商无法再做开放式平台，而只能成为开发第三方组件的技术提供者。

当然，将来市场上也不会只剩下开放式控制系统，因为仍然有相当多的特定领域和行业仅需要专用控制系统就能解决问题，那些在某一领域有专长的控制器厂商仍然能够在市场上占有一席之地。所以，控制系统发展的未来仍将是一个风云变换的时代。至于最后到底孰强孰弱，我们将拭目以待。

参考文献

[1]         GB/T18758.1机械电气设备开放式数控系统第1部分总则[s].中华人民共和国国家标准.

[2]         潘存强 王从鹤 程先华 罗立凤 刘玉文 数控技术的新发展—开放式数控系统 宝钢技术，2006年第４期

[3]         范大鹏　刘钢 郑子文 付永红  方兴未艾的开放式运动控制技术 组合机床与自动化加工技术 1999年第9期

[4]         周祖德　魏仁选　陈幼平 开放式控制系统的现状、趋势与对策 中国机械工程2001年第5期

[5]         王涛 王宇晗 蔡建国 开放式控制系统的研究现状 机械工程师 1999年第10期

[6]         史珺 OpenPLC——可编程控制器的发展趋势 先进制造与自动化科学数据共享网 2007年1月27日

[7]         Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Design Patterns Elements of Reusable Object-Oriented Software 李英军等译 机械工业出版社 2000.9

[8]         OSA-97 OSACA Organization，Internet Location : http://www.osaca.org

[9]         P. Lutz and W. Sperling OSACA - the vendor neutral Control Architecture “Facilitating Deployment of Information and Communications Technologies for Competitive Manufacturing“, Proceedings of the European Conference on Integration in Manufacturing IiM’97 Dresden/Germany, Edited by D. Fichtner, et al., Selbstverlag der TU Dresden 1997, ISBN 3-86005-192-X