升级评价

控制工程师面临的一个常见问题是,当使用似乎每天都在变化和过时的技术时,如何设计长寿命的系统,通常是10到20年。IT世界经历了40多年的爆炸式增长和变化,硬件、操作系统和应用程序每季度都在升级。

作者:丹尼斯·布兰德,BR&L咨询公司 二三年十月一日

控制工程师面临的一个常见问题是,当使用似乎每天都在变化和过时的技术时,如何设计长寿命的系统,通常是10到20年。

IT世界经历了40多年的爆炸式增长和变化,硬件、操作系统和应用程序每季度都在升级。你很难在今天买到去年甚至上个月买到的相同的It硬件。应用软件每年有一个或两个版本,3年后失去支持。操作系统(os)稍好一些;从首次发布到停止支持大约需要5年的时间。不幸的是,所有这些寿命都比过程控制系统的典型寿命短得多。然而,我们现在更多地依赖于控制系统中的商业现成技术,并被要求支持超出其正常使用寿命的IT系统。

有效地管理自动化系统的生命周期需要查看所有的系统元素。在IT系统中,核心功能通常很难更改,而外围功能则比较容易更改。典型的IT系统具有围绕数据结构和专门应用程序构建的核心功能。当这些元素发生变化时,其影响可能波及整个系统,并且通过新的业务流程、操作过程和应用程序接口,用户通常可以看到这些变化。操作系统、标准应用程序和硬件是典型的外设功能。服务器操作系统的升级(从Microsoft Windows 2000 SP3到Windows 2000 SP4甚至到Windows server 2003)可能是一个小事件,并且硬件的更改通常对用户来说是不可见的。即使是对标准打包应用程序(如文字处理器、电子表格和浏览器)的更改,通常对用户的影响也很小。

在控制应用中,情况往往是相反的。在使用SCADA、PLC或基于pc的控制的应用程序中,硬件、操作系统或打包应用程序的更改通常会产生重大影响,甚至可能导致整个系统失败。对这些核心功能的更改需要对整个系统进行重新测试和验证。但是,对应用程序数据和特殊应用程序(如PLC和SCADA程序)的更改通常对用户来说是不可见的,并且通常需要较少的重新测试。

这意味着用于管理IT系统生命周期的规则在用于管理流程自动化系统的生命周期时需要颠倒过来。硬件和操作系统的变更在自动化系统中比较困难,而在IT系统中比较容易。特定于应用程序的程序和用户界面屏幕的更改在自动化系统中很常见,而在IT系统中则更为困难。为过程自动化IT系统的生命周期管理而建立的组织需要有不同的支持过程、不同的技能集,并且可能是与标准IT支持组织不同的组织。

为不断变化的IT元素提供稳定性,需要识别出在没有重大影响的情况下无法更改的系统,以及识别出在没有轻微影响的情况下可以更改的系统。例如,如果网络基于标准以太网技术,那么它们就是外围设备。基本的网络布线、路由器和网桥通常可以在影响最小和测试有限的情况下进行更新。数据库服务器、文件服务器和打印服务器也可以经常更新,但影响有限。但是,对打包应用程序(如HMI、历史记录、MES和批处理系统)的更改可能会产生重大影响,需要进行大量测试。核心系统应该被放置在一个标准的审查周期中,比如每两年一次,在这个周期中,每个系统都要被审查,生命周期支持风险被确定,并做出保留、升级或替换的决定。非核心系统可以在较短的周期内或在升级可用时进行审查,因为升级不那么严重。核心要素将需要一个更大的以项目为基础的支持组织,而外围系统将主要有反应性的支持组织。在IT世界中创建稳定性和一致性需要关注核心生命周期支持元素,并持续审查和评估生命周期风险。

作者信息
丹尼斯·布兰德(Dennis Brandl)是北卡罗来纳州卡里(Cary)一家专注于制造业IT解决方案的咨询公司BR&L Consulting的总裁;dbrandl@brlconsulting.com