从19世纪50年代第一台数控系统出现到现代开放式数控系统，期间经历了多次重大变化，但是这些变化都局限在单机的功能和单元技术的革新和升级。设备的联网相关技术进展缓慢。
近年来，出现了不同结构层次的数控系统产品，包括全系统、半成品和核心软件，见下表。例如，德国的ISG公司仅提供数控软件知识产权，由用户自行配置或二次开发形成自己品牌的数控产品。美国国家标准与技术研究院NIST及其他开源组织可提供开源的LinuxCNC数控软件，用户可免费得到其源代码，并可在GNU共享协议下进行开发。德国的PA(Power Automation)公司、倍福(Beckhoff)公司则提供模块化的数控系统平台，由用户自行配置后形成自己品牌的数控产品。美国DeltaTau公司提供PMAC运动控制卡和相关软件，由用户开发组成自己的数控系统等。
下面的表格描述了数控系统互联方式的变化：数控系统的互联方式从最早的串行通信逐步升级为以太网通信。不同类型(品牌)的数控系统的通讯端口、通讯协议千差万别。从表1还可以看出，在不同的时期，不同的阶段，数控系统厂家设计并提供了面向不同应用目标的通讯方式和通讯协议。比如最早期的I/O方式用于和其他设备进行握手和工作协同。在第二阶段的串口通讯时期(其实这个技术目前还有很多国内外厂商正在使用)，主要是由于数控系统内存偏小，在遇到大程序时进行在线的NC文件下载，即最基础的DNC功能，这种方式由于其技术门槛低，简单、易行、低成本而被国内数控厂商所广泛使用，但是这也同时限制了国内数控系统对于网络技术的应用，功能极为有限。第三阶段，类似Fanuc、Siemens等中高端数控系统都配备了以太网接口，比如西门子数控系统提供基于OPC的标准化局域网通讯协议，数据采集和文件传输往标准化靠拢，但是这个阶段的系统设计及网络协议设计依然局限于局域网应用，更多的还是基于传统的DNC设计思想，这个时期的数控系统网络传输相关功能主要针对数据上传和下载(如备份/恢复，NC程序下载和上传，参数设定等)以满足点对点或者局域网的互联应用目标，但在互联网时代到来时上述功能及其协议的形式却又显得有些捉襟见肘。
数控系统互联方式的变化
以1996年发布的OPC协议为例，其最初目的是把PLC特定的协议(如Modbus，Profibus总线等)抽象为标准化的接口，通过以太网向HMI/MES等系统提供标准化的连接通讯支持，这种面向局域网的通信存在如下缺点：平台局限、防火墙穿透困难、OPC无法支持互联网、安全功能弱、数据完整性无法确保。
1、平台局限，跨平台几乎无法实现。OPC基于微软的COM/DCOM技术开发，只能运行于Windows系统，在如今工业控制领域流行的Linux等嵌入式平台上无法支持，并且2002年初微软宣布停止COM技术的研发，OPC的技术基础面临淘汰。
2、防火墙穿透困难，OPC通信在跨越计算机边界时很难完成，用户需要在防火墙中打开很多端口才能够让DCOM通信穿越，这严重影响了整个网络的安全性和可靠性。
3、对Web等互联网应用的支持缺失，OPC无法支持互联网，
4、数据结构支持弱，OPC无法支持类似结构化数据等复杂数据规范。
5、安全功能弱，类似设备认证、数据加密等网络应用中非常重要的安全功能在老式OPC协议中并未设计。
6、数据完整性无法确保，在通信中断或者异常时，OPC协议并无法确保传输数据的准确送达，数据通信常常会因此损坏并无法找回。
针对上述缺点，第四阶段的通讯设计出现了OPC UA和MTConnect等面向互联网应用的协议设计。
OPC UA为OPC基金会在原有OPC协议的基础上进行了扩展和升级，首先解决了操作系统平台的依赖问题，并且对互联网环境下的应用提供了更多的支持。OPC UA通过隧道技术解决了网络安全及防火墙穿透等问题，并支持发布订阅等面向互联网应用的新兴通讯技术，其技术框架如图2所示。
OPC UA架构
MTConnect是由美国机械制造技术协会(AMT)发起，联合美国通用电气等世界领先制造企业制定的开源、免费的机床通信标准，旨在提升来自不同制造商、软件商的制造装备、设备和软件应用之间的互操作性。其技术框架如图3所示。但是，各大数控厂商的系统架构不同，参数、文件命名规范甚至操作系统都不尽相同，想要对数量庞大的数控设备进行统一的规范，并且使得数量庞大的类似ERP、MES等客户端厂商进行统一规范并使得相关应用得以协同工作依然是一个漫漫长征路。
MTConnect协议仅仅针对客户端与设备的通讯进行了约定，但是并未对互联网端的应用及其协调互通接口进行约定，其问题的根本与OPC UA一样，本质上还是基于点对点的通讯问题解决，但是互联网环境下的应用需求不仅仅局限于此。因而MTConnect的协议需要一套云端应用的规范来进行合理的补充，才能够使得数控机床的互联网应用得以真正顺畅实现。