plc外文文献翻译---工业控制系统和协同控制系统-plc设计(编辑修改稿)

plc外文文献翻译---工业控制系统和协同控制系统-plc设计(编辑修改稿)内容摘要：

ric properties are typically specified throughout a plete control system (see namespaces). 2 Sequence/ State programs Sequence programs can run on any processor in a control system. The runtime environment depends on the relevance of the code for the control system. Programs fulfilling watchdog functions have to run on the frontend processor directly. Sequence programs for plicated startup and shutdown procedures could be run on a workstation as well. The basic functionality of a state machine can be even implemented in IEC 61131. Code generators can produce „C‟ code which can be piled for the runtime environment. 3 Supported Hardware The support for field buses and Ether based I/O is a basic functionality for SCADA type systems it is mercially available from any SCADA system on the market. The integration of specific hardware with specific drivers and data conversion is the hard part in a mercial environment. Open API‟s or scripting support sometimes help to integrate custom hardware. If these tools are not provided for the control system it is difficult – if not impossible to integrate custom hardware. New industrial standards like OPC allow the munication with OPC aware devices and the munication between control systems. One boundary condition for this kind of functionality is the underlying operating system. In the case of OPC it is bound to DCOM which is a Microsoft standard. UNIX based control systems have a hard time to get connected. Only control systems supporting multiple platforms can play a major role in a heterogeneous environments. As a result the limited support for custom or specialized hardware may give reason for the development of a new control system. Display and Operation Besides the frontend system the operator interfaces play a major role for the acceptance of a control system. SCADA tools e with a homogeneous look and feel throughout their set of tools. Toolkits implemented in a collaboration might vary because the individual tools were developed by different teams. 1 Graphic 6 Synoptic displays are the advertising sign for any control system. Commercial synoptic displays e with a rich functionality and lots of special features. Starting to make use of all these features one will find out that all individual properties of the graphic objects must be specified individually. Since SCADA systems must be generic they cannot foresee that an input channel does not only consist of a value but also consists of properties like display ranges and alarm values. Defining all of these properties again and again can be a pretty boring job. Some systems allow to generate prototypes of graphic objects. These prototype or template graphics are plex and need a specialist to generate them. DCS or custom synoptic display programs can make use of the mon set of properties each I/O point provides. This predefined naming scheme will fill in all standard property values and thus only require to enter the record – or device name into the configuration tool. A clear advantage for control systems with a notion of I/O objects rather than I/O points. 2 Alarming Alarms are good candidates to distinguish between different control system architectures. Those systems which have I/O object implemented also provide alarm checking on the frontend puter. Those systems which only know about I/O points have to add alarm checking into the I/O processing. While the I/O object approach allows to implement alarm checking in the native programming language of the frontend system, I/O point oriented systems typically have to implement this functionality in their native scripting language. This is typically less efficient and error prone because all properties must be individually configured. This leads to a flood of properties. Not only the error states for each I/O point wind up to be individual I/O points but also the alarm limits and the alarm severity of each limit must be defined as I/O points if it is desired to be able to change their values during runtime. Besides this impact on the configuration side the processing and forwarding of alarms makes the difference between SCADA and DCS systems. Since SCADA systems inherently do not „know‟ about alarms, each alarm state must be polled either directly from the client application or in advanced cases from an event manager which will forward alarm states to the clients. In any case a lot of overhead for „just‟ checking alarm limits. DCS system again have the advantage that clients can either register themselves for alarm states und thus get the information forwarded or are configured to send alarmchanges to certain destinations spread around the control system. The latter case is only possible for systems which in total are configured with all the nodes taking part in the controls work. 3 Trending and Archiving Trending has bee an important business in control systems architectures. Trends are necessary to trace error conditions or for post mortem and performance analysis of the controlled plant. Besides some custom 7 implementations which are capable to store the data of plete control objects, most of the trending tools archive scalar data. Additional features like conditional trending or correlation plots make up the difference between individual implementations. 4 Programming Interfaces With respect to open programming interfaces PLC‟s and DCS systems have a mon strategy. They are running reliably because there‟s no way to integrate custom code which could interfere with the internal processing. As a consequence the customer has to order „specials‟ which are extremely expensive – or forget about it and use the system as a black box. Since SCADA systems by definition must be able to municate with a variety of I/O subsystems they already have some bu。