|
|
|
|
EVI's Plant Integrated Computer System (PICS) is a highly flexible set of software components, originally designed to run under Windows NT 4.0 Service Pack 5 (though most components have been upgraded to allow them to work on Windows 2000, Windows XP and Windows 2003 Server as well). While a fully functional PICS may be constructed on a single PC, the software is designed to be distributed across a number of machines to (a) improve reliability and (b) spread the computational load. In PICS terms, all of the computers grouped together comprise "the system," a single PC (and/or a primary/backup pair of PCs) is a "subsystem," and a single PC is typically referred to as a node (or machine).
Overall PICS operation is managed by a task named System Monitor (SysMon). SysMon may run on any PICS subsystem although it typically resides on the subsystem with the most critical components (e.g the static database and the real time data distribution program). Each node runs a Task Monitor (TaskMon), whose function is to communicate with SysMon for system heartbeats, state of heath information, the PICS service directory, task start-up sequencing, and node failover operations. For the paranoid, all nodes also run (as the first application program started by TaskMon) a program named WatchDog that does nothing except monitor the Task Monitor and reboots the node if the Task Monitor appears to have failed.
With PICS III, the central control process (SysMon) has been eliminated. The Task Monitor application (running on every node) coupled with a system configuration compiler is now responsible for handling node failures directly. This decentralized approach allows system to continue operating even when some parts (on other machines) are down. When the data collection is also spread across several different subsystems, this may allow the system to continue processing at least some of the data while other data sources are down.
The PICS Task Monitor provides application programs with the node's current security mask and with a directory of PICS applications available throughout the PICS network. This directory is used by programs to locate services that they may need (e.g. databases, etc.) and also to locate partner programs for backup synchronization (when appropriate).
All of the real time and derived (computed) data points in PICS are described in the static database, which is managed by a program named SDB. The static database services are extended to other nodes through programs named SDServer and SDClient. From an application's viewpoint, SDB appears to be directly available on all PICS nodes. In reality, the SDClient and SDServer insulate the applications from the necessary network communications.
The real time data is collected and redistributed by the real time database (RTDBA) application. RTDBA uses UDP broadcasts to transmit blocks of real time data to all nodes on the PICS network. UDP broadcasts are used for two important reasons: (1) They are very low overhead and consequently quite fast and (2) they should not be routed to any other network in the event that any sort of WAN router is attached to the PICS network. Because UDP messages may, occasionally, be lost, all sources of real time data are programmed (via the static database) to refresh even unchanging values at some minimum frequency (which may vary from point to point).
Data collection is typically accomplished using one form or another of EVI's 8800 data collection unit, although PICS does not actually place any restrictions on data sources (some sites have custom applications that gather data from other external sources and provide it to PICS as well as 8800s). These are embedded, linux-based (formerly DOS-based) PCs containing various interfaces to front-end gear. The current interfaces available include custom EVI hardware, MODACS, AVCO and CPI/RTP and others. The 8800's are designed to run on a private network whose express purpose is data collection. They communicate with two PICS applications that run under Windows: MUX Control (MUXCTL) and MUX Database (MUXSDB).. MUXCTL is the primary controller, dictating when 8800s are to start, stop, pause, etc. MUXSDB provides each 8800 with a specialized copy of the static database, custom tailored to include only that that specific 8800 needs in order to operate. Time synchronization is handled using standard linux services. Real time data collected by MUXCTL from the 8800s is provided directly to RTDBA for distribution throughout PICS.
That essentially covers the basic PICS core. Computed data points may be derived by software running on various PICS subsystems and provided back into the data distribution system, if necessary. End-user displays listen to the data streams and display information as directed. Archiving systems listen to the data streams, record the data, and probably offer some sort of retrieval service that other programs could use, etc.
The PICS installed at PGDP uses the standard core, described above. Most of the 8800s in use at PGDP are currently running embedded linux and custom software to read data from a set of AVCO scanners. One other 8800 pair (in C-310) is running embedded linux and a custom software to read data from a CPI/RTP system. The basic system layout is as follows: (click here for a graphic layout)
There are five 8800 networks at PGDP. The C-331 and C-335 networks each have four pairs of 8800AVs. The C-333 and C-337 networks each have six pairs of 8800AVs. And the C-310 network has one pair of 8800CPIs. The 8800CPI is collecting data in C-310.
The 8800's communicate directly with two PICS applications (MUXCTL and MUXSDB). There should be no other traffic on the data collection network for (a) security and (b) to reserve maximum bandwidth for real time data.
MUXCTL (and therefore, PICS) supports a total of 64 8800's per network. If all 8800's are running A/B nodes for failover, then there may be 32 pairs (for a total of 64).
This network contains the following subsystems: PMUX, PPDRS, PDARSand PBridge.
SDB supports up to 64 concurrent clients. Clients connect directly to SDB only when information not available in the SdbCache is required (such as AlarmLog's need for alarm destinations). Also, clients should connect to SDB, get the information they need, then disconnect as quickly as they are able (all current clients do this). This means that very few (if any) SDB clients are active at any given time.
SDServer supports up to 64 incoming TCP connections from SDClients (or applications emulating SDClient) and at most 32 concurrent client connections from each incoming client. Note that the SDB limit of 64 total clients will be reached long before SDServer's maximum capacity is reached.
SDClient uses the same 32 client limit that SDServer uses for concurrent local clients.
RTDBA and RTClient currently built to support 32 pipes (outgoing RT data stream), 16 queues (incoming RT data stream), and 16 regions (command interface).
RTServer uses a 32bit mask for every RT point to monitor to for changes/delivery to each of the 32 supported network clients. Note that RT data connections from applications do not propigate beyond the local real time agent (unlike SDB connections).
ACB supports up to 50 concurrent users, but, since RTServer only supports 32, that limit will probably win out most of the time.
Recall Display uses one RT client connection for EACH window being displayed.
The PICS API DLL will use one RT connection for EACH subscription created. When a subscription is cancelled (deleted/destroyed) the RT connection resource will be released.
Most other applications (if fact, all that I can remember as of this writing) use a single RT client connection for each instance of the application that is running.
As of this writing, AlarmLog and the static editor(s) are the only applications at USEC that require full SDB access. All other applications are currently able to obtain all of the static data they require from cache.
PGDP's IT server group has a machine (called the PICS Repeater) that runs a single machine, stand-alone PICS to provide WAN access to plant data. The Repeater uses special settings for SDClient and RTClient that enable them to locate and connect to the PBRIDGE subsystem even though their servers are not in the local Task Monitor's service directory. The Repeater offers PICS log in, static, realtime, DARS and PDRS data to all WAN clients at the site.
The PICS Client sofware package, made up of: ACC (PICS Access Control Client), SDClient (Static Data Client), RTClient (Real Time Client), ReDisp (Recall Display), DEU, and PicsViews (PICS DataViews Displayer). Machines running this software package may access PICS through a node configured to offer "bridge" services: ACB (PICS Access Control Bridge), SDServer (Static Data Server) and RTServer (Real Time Server). Access to the DARS Server is optional and would enable ReDisp to perform graph backfills, when available.
|
|
|
|