要想理解这两者之间的争论，就一定要明确这两种平台之间的根本性差异。例如，DCS体系结构源自一种完整的系统方法，其焦点在于基于网络实现分布式控制，协助作业人员监视并操控工厂中的任何一个区域。通过高性能的确定性网络实现一致、同步并且完整的过程数据正是DCS体系结构的核心。
另一方面，PLC体系结构聚焦于灵活快速的本地控制，PLC技术最近的发展为其增加了过程控制能力。当PLC和HMI软件集成在一起时，其最终形态看起来与DCS十分类似，但是这仍旧是一种自建(DIY)的实现方法，意味着工程师必须亲力亲为实现系统的每一个环节。对于控制来说这种方法更加灵活，但是DIY通常意味着在组网和性能上更大的技术风险，其导致的成本增加会在后期慢慢体现。
以前，相对于PLC系统来说，DCS通常更加昂贵，而且与今天面临的状况不同，当年很多工厂对生产速度、产量、废物排放、安全性和遵循法规上的需求并不高。正是因为这样，基于PLC的系统才获得了发展，因为它们能够提供更低的固定资产投资，同时提供的功能也足够用。但是随着时代的变迁，在全球市场范围DCS系统的价格不断降低，制造企业对其需求也随之上升。因此，在投建新自动化项目时，很多控制系统工程师、维护经理和工厂经理开始重新审视DCS和PLC控制系统两者的优劣。
在评价DCS和基于PLC架构的自建分布式控制系统时，有几个要点需要注意。
网络性能
优良的网络性能始于合理的网络设计，而合理的网络设计依赖于对每一个网络节点的通讯行为和用来承载网络信息的协议的详尽了解。主要的过程自动化供应商已经注意到这种需求，他们提供最优的方案，使用户可以为控制系统选择最优的网络设计。而DIY方案的应用工程师可能需要首先完成特定网络拓扑结构的搭建。
网络设计和安装完成之后，下一步就是测试网络性能到底如何。对于不同的数据采集量、警报、历史信息、对等网络信息和随时可能发生的备份作业，同样的网络拓扑结构的性能可能具有很大的差异，这需要依靠全面的最优拓扑结构测试才能够得出结论。
假设用户已经完成了网络的设计和安装，工厂达到了最大生产能力，一切都按照预期运行，那么此时需要面临的挑战就是如何维持这种平稳的网络作业状态。
一种解决方案是在项目之初就安装容错以太网(FTE)，这是一种使用并不昂贵的成品组件实现冗余工业以太网的组网技术，这种技术能够提供高可用性。FTE还能够提供足够的网络诊断，实现对过程控制网络的持续关注，可以作为DCS的一部分。
而且，工厂必须在补丁和更新被载入生产系统之前对其进行功能和性能的测评。有经验的网络工程师深知网络上的每一台设备都必须正常工作，才能构成一个健康的网络整体，正所谓一条臭鱼腥了一锅汤。
控制性能
良好的过程控制是建立在可靠和可重复的控制策略上的。过程控制器作为经典DCS体系结构的一部分，在作业方法上比PLC具有更多选择。PLC的运行速度相对来说更快，而过程控制器的强项在于可重复性，这意味着控制策略的运行周期是固定的——运行的过快或者过慢都是不能接受的。在每一个运转周期内实现可重复的控制，有助于工厂实现可重复的质量、生产率和作业结果。
运行周期并非唯一差别，其他系统服务也将优先解决控制器的配置，例如，如果控制器产生的报警会对控制任务产生影响，那么这些报警就会被屏蔽，当过程扰动渐趋平稳时，再恢复这些警报。为了有效实现这种警报管理机制，必须能够与控制产生警报的时间紧密配合，那些用来收集、存储和报告这些警报的报警子系统和事件子系统也是如此。老话重提，系统的作业方法是DCS的核心。
HMI图形
HMI软件包供应商通常都会吹嘘操作员设计图形界面是如何的容易。但是不管图形界面设计的多么令人印象深刻，它都不能为工厂带来直接的经济效益。设想一下过程控制环境无需建立图形界面，因为它们已经内置了图形界面，这是多么惬意的一件事。
但是随着时代的变迁，在全球市场范围内DCS系统的价格不断降低，制造企业对其需求也随之上升。
如果系统控制功能和作业环境整合在一起，那么支撑过程工厂运转的90%的功能都可以标准化。一些DCS平台能够提供上百种标准面板、分组显示和状态显示，这不仅对于安全有效的工厂作业非常重要，关键这些功能是现成的。
控制算法
面向对象的功能模块主要用于指定用户功能的属性。通过创建具有完整参数功能的功能模块，用户可以开发并对控制策略实现精准调整，无需重新设计控制功能，所有必需的功能都经过备案可选。应用工程师仅需将模块集成到所需的控制配置中即可，十分容易。无需编程的自动备案控制器配置使DCS体系结构对于工程师的使用和故障排查来说十分高效。
让我们以一个常用的过程控制功能——PID模块为例。使用DCS全球数据模型，可以通过配置界面获得PID功能模块的全部信息，此界面的各种算法已经通过验证，可以按需选择。HMI中的报警、趋势分析和历史数据功能所需的参数可以在一个站点轻松完成获取和配置，无需再对HMI配置进行更改。
应用软件
在一套自动化系统20~30年的服役期内，考虑用户需要对系统进行扩展、更改或者为系统增加新技术的频次是很重要的。
“如果系统控制功能和作业环境整合在一起，那么支撑过程工厂运转的90%的功能都可以标准化。”
对于DIY系统来说，要想找到工厂运行所需的所有应用程序，只需要翻翻PLC和HMI供应商的选型手册然后下订单即可，随后就可以获得授权、DVD安装盘、下载内容和其他一系列有用的资料。但是，如果只需要选择一种型号代码就可以立即收到所需的整套系统岂不是更加便利么？一个授权文件可以用于所有支撑过程工厂运行的控件、数据备份、趋势分析对象、业务集成软件和工厂运行中所需要的图形。DCS体系结构能够确保所有的控制应用程序都被正确加载，版本正确且经过兼容性测试。
数据管理
当DIY的DCS系统被拼凑起来后，各种不同的数据模型将会产生多种代表同样信息的数据。当这些个体被组装成一个系统之后，这些不同种类的数据模型必须同步并且受到维护，对于应用工程师和系统管理员来说，完成这项工作是一个不小的负担。
而对于DCS体系结构来说，通用的数据模型能覆盖整套系统。因此，一个数据源可以为系统任何位置的任何一个应用程序或者服务提供数据。这个问题的关键并不在于数据库的数量，而在于单一的数据模型，不管数据组件在何处，它都可以被体系下的任何一个组件所使用，而且数据组件无需复制。综合的数据模型并不一定意味着仅使用一个数据库，但是它肯定意味着对于任何数据组件来说都具有同一个去处。
批量自动化
DCS体系结构的综合特性长久以来一直是批量自动化工程的上佳之选。相比于其他类型的自动化，批量要求在相位、单位、配方、公式和其他要素上做到精细的配合。即使经典DCS体系结构在提供完整的解决方案时也面临着不小挑战，因为批量环境中的组件实在过于多样化。正是基于此种原因，很多批量自动化工程都选择将多种解决方案混合成一种解决方案。
不管怎样，批量数据模型已经不像从前那样令人心生畏惧了，批量自动化解决方案的各种不同的信息现在使用单一的DCS数据模型就可以采集完成。例如，批量管理和执行所需的所有组件都运行于过程控制器上，或者在要求耐用性的场合这些组件都运行于冗余控制器上。这意味着没必要非得使用一台PC作为批量服务器。因为所有的批量组件都运行于控制器上，批量执行更加快速，循环时间得以缩短，产量提升。而且，对于各种报警、安保和显示功能，操作人员只需要学习一种作业环境即可，误操作的可能性也更低。从工程和维护的观点来看，这种方法的优势在于仅需学习并支持一种工具即可控制工程网版权所有，事半功倍。
开放式连通性
今天的过程工厂很少选择单一品牌的控制器。这就是为什么经典DCS体系结构也能够将第三方设备以同样的数据模型引入的原因。这意味着操作人员能够以一种统一的风格浏览来自于不同厂家的控制器的信息。
控制解决方案是否能够将企业解决方案无缝融入控制层也是一个重要的考虑方面。因为信息富集型应用通常都是如需则急需，所以对制造执行系统(MES)、资产管理系统、报表软件、统计过程控制(SPC)、停机跟踪或者其他企业层解决方案进行提前考虑是很重要的。
仿真技术
控制策略在应用到实际的过程之前必须经过彻底的“排查”。由于过程控制关注可重复性，所以能够将控制策略直接运行于仿真环境而无需更改，这一点是十分必要的。过程控制中的计时是很必要的，仿真器必须能够可靠地重现过程执行的计时。
“由于过程控制关注可重复性，所以能够将控制策略直接运行于仿真环境而无需更改，这一点是十分必要的。”
基于此种原因，DCS供应商都提供先进的仿真器技术，在工厂整个生命周期内帮助改善性能。有多种仿真选择，从离线的稳态设计仿真、控制核查和操作员培训到在线控制和优化、性能监控和作业计划仿真。
过程历史数据
彻底的过程改进依赖于优良的过程数据，这意味着历史数据的收集必须与工厂自动化系统的功能协调一致，不会妨碍更加紧急的控制要求。但是，如果出于某种原因必须中断历史数据收集，那么之后必须能够恢复历史数据，因为不完整的历史数据是不能接受的。工厂需要一种可靠的解决方案以获取历史数据，并将这些数据用于趋势和质量分析。
基于此种目的，大多数现有的DCS平台现在都具有耐用的内置过程历史数据功能，工程师和工厂管理人员可以藉此在单一站点完成对整体作业性能的分析。冗余数据收集机制还能保证在主历史数据收集器失效时迅速切换至辅助历史数据收集器。
做出决定
当然，每一家工厂对自动化和控制都有其独一无二的要求，实际上不管是DCS还是PLC都能满足每一家工厂的需求，落实到具体的应用和作业需求时，必须仔细考虑，然后再决定哪一种技术更适合自己的过程控制。当前对于DCS的需求正在上升，即使对于规模较小的应用也是如此。对上文讨论的内容略加思索，操作人员和工程师就能对DCS和PLC的能力有一个初步的认识，并在两者之间做选择的时候能够更加深入地考量。