开放系统可靠性
停机时间是操作人员最不希望他们的控制系统经历的事情，特别是在系统利用率和/或成品价值很高的情况下。工艺设备和相关控制的良好可靠性和安全性几乎是每个控制工程师的买家清单上的首要问题，其次是预算限制和快速安装并使系统运行的需求。
|
停机时间是操作人员最不希望他们的控制系统经历的事情，特别是在系统利用率和/或成品价值很高的情况下。
工艺设备和相关控制的良好可靠性和安全性几乎是每个控制工程师的买家清单上的首要问题，其次是预算限制和快速安装并使系统运行的需求。
许多控制工程师认为“开放系统”至少是成本问题的部分答案，但开放系统是否比专有或封闭系统具有更高的安全性或可用性风险?
大多数人都明白，购买价格不应该是选择系统的唯一标准，但在决策过程中很少考虑系统可靠性和可用性，以产生可接受的计划外停机量的硬数字。更少的人会给出生产损失、能源和原材料浪费、安全和环境后果、客户影响等相关成本的确切数字。
为了避免以后的意外，应该评估开放和专有的控制系统，以确保每个人都了解系统故障导致的计划外停机的来源、可能性和后果。
开放系统的承诺
距离我们第一次听说“开放系统”已经有20多年了。早期的演示展示了使用标准网络与计算机系统和人机界面(HMI)控制台连接的各种制造商的工业控制器。每一件设备都包含标准化的连接器、通信协议和机载智能，以处理设备识别和数据需求。当连接和供电时，一台新设备将自动识别自己，并开始与其他连接的设备共享数据。
其承诺是控制工程师将把大部分时间花在流程改进上，而很少花时间担心系统及其通信需求。其承诺是一个高度灵活的控制系统环境，其中可以选择、部署和使用“最佳品种”产品。在这些有远见的演讲中，没有人解释控制工程师需要理解操作系统的细微差别、动态链接库(dll)，以及如何使多个通信协议共享同一条线路。
尽管有更早的尝试，但大多数人都认为，开放系统的第一个重大推动来自20世纪80年代通用汽车的MAP(制造自动化协议)努力。他们花了数不清的时间来定义协议，然后进行了大量的教育工作。运营公司致信设备制造商表示，未来只有支持MAP的供应商系统才会被考虑，这引发了一场风潮。这一愿景即将成为现实。
不幸的是，通信标准演变成了“人人皆有”的协议，变得相当复杂。事实上，底层软件变得如此复杂，它通常需要两倍于它应该支持的控制器软件的计算能力和几倍于它应该支持的控制器软件的内存，即使在计算能力达到这种水平时，数据速率也很少超过每秒500个变量——与简单串行总线的性能相同。
软件的复杂性带来了更高的系统故障率和无法解释的计算机崩溃。一些被追踪到未定义的(专有的)消息内容，另一些则无法追踪，也从未解释过。一个复杂的通信机制就是不起作用，即使是在“开放”的名义下。
到20世纪90年代初，“开放”的目标似乎再次得到了满足——至少这是广告大战所暗示的。
大多数主要的DCS(分布式控制系统)和PLC(可编程逻辑控制器)供应商都将开放作为主要的系统属性。虽然该产品离理想的愿景还很远，但控制设备供应商实际上已经开始兑现一些承诺。采用以太网技术和事实上的TCP/IP标准，第三方操作站实际与一些DCS和plc连接。但同样，奇怪的、不可重复的、意外的系统故障出现了，通常是在初始启动很久之后。当这类问题出现时;哪个供应商对此负责?指责变得明目张张，控制工程师开始意识到他们确实需要学习关于操作系统的细微差别，dll，以及如何使多个通信协议共享同一条线路。在少数情况下，这种愿景变成了噩梦。
开放系统的方法
即使在今天，整个开放系统的愿景仍然难以捉摸，不同的团体正在追求两种根本不同的方法。
一种方法涉及到“开源”的概念和采用事实上的来自个人计算机(PC)环境的标准，使用微软或开源Linux操作系统。它利用在微软或Linux基础上构建的低成本或免费软件与商用pc一起提供最终的低购买成本解决方案。
第二种方法是现场总线方法，该方法围绕一台设备或一个操作单元建立边界，并在边界内建立标准化的通信协议——与最初的MAP概念大致相同。
尽管现场总线战争持续了数年(小规模冲突仍然存在)，不同派系都在推动各自版本的协议，但有两个版本在市场上获得了广泛的接受——profibus和FOUNDATION现场总线。两者都具有广泛的功能，包括数据传输、编程支持和网络管理。两者都拥有广泛且不断增长的认证可用产品。
虽然每个组织的方法各不相同，但认证测试可以帮助用户在同一现场总线网络上自信地选择和安装不同制造商的产品，减少以前开放式解决方案尝试的不确定性和指责。
开放系统的可靠性和安全性
开放系统产品开始显示出前景。但是这样的系统足够可靠和安全吗?可靠性被定义为“在一段时间内成功完成预期功能的概率”，所有硬件和软件故障的来源都包括在内。
当考虑开放系统中所有可能的故障时，出现暂时无法解释的问题就不足为奇了。从可靠性和安全性的角度来看，开放系统的世界与专有DCS/PLC系统的世界完全不同。与私有世界相比，事情更灵活、更复杂，而且相对不受控制，至少在确保所有部分和谐工作(认证的一个目标)方面是这样。
系统故障通常发生在一些意想不到的输入进入系统时。胭脂输入可以被认为是软件系统上的“压力”。该软件对这种压力做出不失败反应的能力代表了它的“实力”。(参见“是什么使软件可靠?””栏)。为了使软件强大，开发人员必须花大量时间考虑所有可能出错的地方，然后采取措施防止错误的发生。这是很困难的，因为大多数软件开发人员在考虑如何在预期的输入条件下工作时都有足够的麻烦。在许多情况下，未预料到的输入条件会导致未预料到的输出响应。有些事情会发生，比如写入内存中的错误位置，或者启动一系列事件，从而导致计算机崩溃、清除内存，甚至传输错误的输出。
在单供应商专有系统中，通信协议是由一个团队，甚至可能是一个人设计的。明确定义了操作站和控制器之间交互所需的特定消息。尽管不太可能发送坏消息，但错误检查例程知道传入的消息是什么，并拒绝其他任何消息。从设备驱动程序到消息处理程序的所有软件都是由一个设计团队根据单一的功能规范编写和理解的。在这样的环境中，构建“强大的”软件相对简单。
尽管如此，还是发生了许多软件故障，但是当这种情况发生时，谁应该对此负责是很清楚的，而这些故障就变成了开发人员的责任。在专有的DCS/PLC环境中，一个设计团队对可靠和安全的系统运行负有明确的责任。这在开放系统环境中既不可能也不可能。
在开放环境中，更有可能通信意外数据。通用通信协议变得更加复杂，使得软件开发人员更难过滤意外的数据消息。一个设计团队甚至不太可能理解整个设计，当失败发生时，谁应该负责是非常模糊的。结果，系统被重新启动，故障事件未被报告，控制和自动化系统变得不那么可靠。
进入开源的PC环境，就有了更多的灵活性而且更多麻烦的机会。在这种控制较少的环境中，不同公司开发的动态链接库通常是不兼容的，而且安装过程并不总是足够优雅，不能防止一个公司覆盖另一个公司。(请参阅“Linux如何处理开放系统”和“DLL地狱最终实现”边栏。)
为不同国家编写的操作系统版本并不总是反应一致。当美国版本的操作系统中的输入“1.000”(数字1有四个有效数字)被欧洲版本的操作系统解释为1000时，会发生什么?如果在软件设计中没有考虑到语言依赖会发生什么?
当许多团队努力工作以提高他们生产的软件的质量时，独立的软件质量审计已经表明，许多组织仍然在一个称为“混乱”的水平上生产软件。审计显示，软件开发人员通常不了解软件安全和可靠性技术，尽管许多开发人员擅长他们所做的工作，但可变性是相当大的。仅这一点就会带来控制系统故障的风险。
放弃开放系统?
开放系统的不安全操作或停机风险是否太大?有了这些潜在的麻烦，我们难道不应该放弃开放系统的想法吗?当然不是;总有一天，好处会是惊人的。但在那之前，要小心行事。了解这些设备在哪里可以安全使用。了解停机时间的成本并考虑整个生命周期的成本。考虑获取每个供应商的软件质量、安全性和可靠性程序的详细信息，如果无法获得这些信息，买家应该小心。
不允许在执行控制的地方使用通用的人事计算机，以避免复杂性。不要安装任何不必要的东西，没有游戏，没有办公工具，没有飞行模拟器。请在所有软硬件安装完成后，再进行系统测试。当升级或安装新的硬件或软件时，重新测试所有内容。
开放系统的承诺总有一天会实现，而且这一承诺可以在不牺牲安全性或可靠性的情况下实现。最终，越来越多的开发人员将进行系统和软件危害分析，以确定潜在的问题。系统开发人员和集成商将对软件和系统设计进行故障模式和影响分析。标准接口将包括消息过滤和错误检查，其级别足以用于流程控制。
是的，控制工程师花时间改进制造过程的日子正在到来。在那一天到来之前，请提出问题，并应用常识来确定在哪里以及如何部署开放系统。
欲知更多信息，请圈200，在线，www.globalelove.com/freeinfo或访问www.exida.com．对于软件供应商，请访问www.globalelove.com/buyersguide。
| 作者信息 |
| William Goble博士是Exida.com的联合创始人兼总裁。 |
Linux如何处理开放
基于微软的软件的优点和缺点公开出现，并经常在互联网上传播;Linux的优点和缺点(尤其是缺点)很难定位。
这种差异的部分原因可能是一些用户将微软巨头与隔壁隔间的“Linux家伙”进行比较时的感觉。
Control.com最近宣布开放控制实验室(Westborough, Mass.)，由Peter Wurmsdobler博士领导，他是公认的实时Linux专家。
Control.com自2000年初就参与了LinuxPLC (PuffinPLC)项目，提供了一个关于开源操作系统(如Linux)如何被认为是高可用性控制和自动化系统的可行候选的观点。
CE:由于不同应用程序加载了不兼容的动态链接库模块，导致了操作系统故障。请解释在Linux中如何处理类似的不兼容问题。
Wurmsdobler博士:例如，在Linux中，Microsoft动态链接库的内容被划分为几个层和优先级空间。首先，与硬件有关的所有内容都变成了一个模块，可以直接编译到Linux内核中，也可以单独编译为可动态加载的内核模块。每个模块和内核都包含版本控制号。如果试图加载一个不兼容的模块(即，一个需要内核不支持的函数调用的模块)，或者存在版本不匹配，则模块插入将被内核拒绝。
其次，用户空间库还包含版本控制，并放置在由动态链接/加载器访问的预定义目录中。当应用程序启动时，将验证库函数调用。如果发生不匹配或缺少函数调用，则应用程序将中止。
Linux的一个显著优点是，相同库函数的多个版本可以存在，而不会造成应用程序混淆。这可以通过应用程序设置的指向实际使用的库函数的符号链接指针来实现。
CE:微软Windows使用标准化的错误处理对话框通知用户出现问题。在开源环境中，错误消息是如何标准化的，错误代码库由谁保管?
Wurmsdobler博士:系统和库调用的标准错误消息定义为头文件中的数字，这些数字被转换为POSIX(可移植操作系统接口)兼容的文本，并可用于任意数量的目的地，包括终端、打印机和文件。
这种方法与微软Windows操作系统有很大不同，后者将操作系统和用户界面结合在一起。
Linux方法似乎非常适合于控制应用程序，例如可能运行在没有窗口系统的LinuxPLC中，并且提供了更大的灵活性，因为错误消息可以定向到另一个网络连接的设备，在那里系统工程师能够跟踪错误的根本原因。
CE:控制系统故障是由于商业上可用的操作系统为不同的世界区域“个性化”而导致的。例如，对数字中的逗号和句点的不同解释，或者不同的度量单位，都可以追溯到系统故障的根本原因。在Linux世界中如何识别、处理和/或避免类似的问题?
Wurmsdobler博士: Linux是从国际上开发的UNIX发展而来的，因此语言和数字参数问题在UNIX开发早期就得到了解决。今天，Linux试图保持对国际和开放标准的兼容，特别是POSIX。
在应用程序方面，大多数期望数字的Linux应用程序将在应用程序层实现这种区别。
CE:在开源环境中，如何验证软件的质量?
Wurmsdobler博士:对于封闭的软件开发环境，也可以提出这个问题。拥有文档化的软件开发过程和/或“拥有”所有软件开发人员并不能确保软件的质量。
开发过程可能是有缺陷的，或者更有可能的是，开发人员没有很好地理解或完全遵循这个过程——通常是由于市场营销驱动的时间限制。
在开源世界中，一个人开始一个项目来解决特定的用户需求。开发社区通常会接管项目的一部分，提出建议和改进，并自我监控和评估产生的结果。大多数情况下，这允许原始用户继续参与解决方案的演进，这是一个更加自然的过程。
有关LinuxPLC项目或开放控制实验室计划的更多信息，请在线访问
戴夫·哈罗德，资深editordharrold@cahners.com
什么使软件可靠?
在可靠性工程界有一个直接适用的概念，称为应力-强度概念，即当一些“应力”大于相关的“强度”时，所有的故障都发生了。
应力-强度的概念出现在整个机械和土木工程界，应力是一种机械力，强度是结构抵抗这种力的能力。
电子硬件暴露在多种物理和环境应力下，包括热、湿度、化学物质、冲击、振动、电涌、静电放电、无线电波等。
操作压力包括不正确的输入命令、不正确的维护程序、错误的校准、不正确的接地等。
这些压力如何适用于软件，以及什么东西可以对基于软件的系统施加压力?
软件压力例子
某工业操作站的控制台已正常工作两年。在新操作员的第一个班次中，控制台停止更新屏幕，并且不响应后续的操作员命令。
该设备被下电并成功重新启动，没有硬件故障。
这款游戏机已经投入了400多台，运行时间超过800万小时，游戏机制造商很难相信这样一款成熟的产品会出现软件故障。
尽管存在疑问，主机制造商还是指示软件和硬件产品开发团队进行彻底的根本原因分析。
其中一名制造商测试工程师访问了客户现场，并面试了新操作员。在访问期间，工程师说:“这家伙键盘打得很快。”
这条信息使制造商开发团队能够追踪到问题的根源，即操作员在警报沉默键后32毫秒内按了警报确认键，导致内存写入问题，然后导致处理器锁定。
在另一个例子中，计算机在收到网络通信消息后停止工作。测试和分析最终显示，该消息来自操作系统不兼容的设备。当发送设备使用正确的“帧”格式时，接收设备的操作系统使用不同的数据格式。由于接收计算机没有检查兼容的数据格式，帧内的数据位被错误地解释。这种情况导致计算机在几秒钟内就瘫痪了。
还有许多其他软件故障的例子。大多数可以追溯到一些被认为不太可能、罕见甚至不可能的事件的组合。
就像硬件一样，当压力大于强度时，软件故障就会产生。软件系统的强度是几个因素的函数，包括当前软件故障(人为设计错误，“bug”)的数量，软件错误检查的数量，以及进行的数据验证。
软件系统压力是由处理器处理的输入、时序和存储数据的组合。输入和输入时间可能是其他计算机系统、操作员或两者的功能。
DLL地狱终于被驱除了
根据从微软(华盛顿州雷德蒙德)网站获得的信息，微软Windows操作系统的第一大脆弱性来源，通常被称为DLL地狱，已经在Windows 2000专业版中被驱除。
动态链接库(dll)出现在Microsoft Windows的早期版本中，其目标是共享尽可能多的资源，同时保存宝贵的磁盘和内存空间。
如今，磁盘空间和内存相对便宜，dll的使用和好处变得不那么有意义。
微软的解决方案是Windows文件保护(WPF)，这是一种保护关键系统文件的两部分机制。
第一种WPF机制使用数字签名加密技术，该技术验证系统文件的来源，并在试图修改关键的系统文件时向WPF发出警报。
第二个WPF机制是系统文件检查器，这是一个管理文件版本目录的工具。如果编目文件丢失或损坏，WPF将重命名受影响的编目文件，并从Dllcache文件夹检索缓存的版本。如果缓存的版本不可用，WPF会请求替换副本。
不幸的是，显然没有办法将这些功能添加到现有的Windows 95/98和NT安装中，因此升级到Windows 2000 Professional是唯一的解决方案。然而，对于一些开发人员来说，管理组件安装的新规则的实现可能还很遥远，这可能会产生一类新的关键文件管理问题。
您是否具有本内容中提到的主题的经验和专业知识?你应该考虑为我们的CFE媒体编辑团队做出贡献，并获得你和你的公司应得的认可。点击在这里开始这个过程。
