|
|
|
|
A typical (but fairly simple) PICS is designed to operate in the configuration show below:
PICS is designed as a distributed system, but that doesn't necessarily mean that many computers are required. In fact, an entire PICS may be configured and operated on a single machine, if necessary. A few of the applications expect to be co-located (on the same node), but in general most applications will run just fine on any node in a multi-machine system, too. There are three primary branches in the system software: control, data, and end-user applications.
The control applications are responsible for starting up the critical system components (and any other, non-critical components, too) in the correct order so that no program attempts to load before the services it uses are available. The control apps also monitor applications that are running so that a node may be restarted in the event of an application failure. When failover support is available, the control apps switch over to the backup node prior to shutting down and restarting a failed node, so that the system may continue to operate. The primary control applications are Task Monitor (TaskMon) and WatchDog. When WAN access is included, the Access Control Bridge (ACB) and Access Control Client (ACC) are also members of this group.
The data applications are responsible for creation, maintenance, and distribution of both the "static" and real time databases. Additionally, the static database components are also responsible for maintaining synchronization between a primary and its backup (when failover is available). Both databases have delivery paths that go all the way from the master database node(s) to the front end gear (8800s) in one direction and to the end-users' desktops in the other. The 8800 software is included as one of the data applications because it is responsible for acquiring real time data values from the real world and providing them to PICS. The primary data applications are the Static Database family (SDB, SDServer and SDRemote), the Real Time Database family (RTDBA, RTServer and RTClient) and the 8800 Service software (MUX Control, MUX SDB, 8800av and 8800cpi). Sites that have computed (derived) data points would also have various COMPUTE applications included in this group.
Everything that isn't included as either a Control or a Data Application is, by default, an end-user application. Typically these are data formatting programs that interact with users to determine what data the user wishes to see and how to format it, then produces the display (or printed report). The archivers are included here because they are primarily a post-processing function (when related to real time data). At USEC/PGDP, the end-user applications include DEU, Recall Display (ReDisp), PicsViews, AlarmLog, PicsRPG, DARS and PDRS.
This is a short document intended to introduce the reader to an overview of the architecture of PICS applications. The architecture discussed covers most, but not all, applications. Most notably, some of the core applications do not fit this model, in whole or in part. The diagram below shows the relationships between the PICS application code layer, the support objects, and the PICS system layer. Please be aware that this is more in the nature of an overview and does not contain any details of the protocols or methodology discussed.
For simplicity's sake, communication mechanisms that are invoked automatically by a support object are generally not shown. Objects appearing in red automatically create a thread to process requests from the application. In effect, this allows the object to appear to be running concurrently with the application. While this makes many operations easier, it also creates a requirement for PICS application developers to be familiar with the operation of Win32 threads and how different threads may interact with each other. In some cases, PICS applications may communicate directly with an object, in other cases, one or more interfaces must be used and in a couple, both methods are supported. The following sections will describe each of the interfaces in terms relative to the major service objects (shown in the diagram).
The heart of the PICS system is the real time database. Although actually made up of a set of programs (RTDB, RTRemote, RTServer, RTClient, RTBridge, RTDBDDE, RTPipe, and RTAS) the PICS real time data server programs (RTDB, RTRemote, and RTClient) all offer the exact same interface to all client applications. In fact, without cheating (bypassing standard and/or documented methods), there is no way (and should never be a need) for a PICS application to determine which of these three applications it is accessing.
The real time agent provides a facility for distributing significant change records to PICS applications through a subscription mechanism. PICS applications use the IPCAPI to create an IPC Pipe object (to receive the real time data) and an IPC Region object (to send commands and receive results). When the IPC objects have been prepared, the application builds a subscription request in the IPC region object and posts a message to the real time agent indicating that a command requires attention. The real time agent processes the command and places the result in the IPC region, posting a message to the client indicating the result of the command. Because of the way subscription commands are processed, and their relationship to the real time database itself, applications will frequently receive some significant change records in their IPC Pipe before receiving a successful command result. Applications should be constructed to expect this behavior.
Because the real time agent will typically be at a higher priority than general applications, applications should ensure that the IPC Pipe being created will be large enough to contain at least one change record for each subscribed point. When subscribing to all points (using the special ALL_POINTS symbol), the pipe should be able to hold a copy of the entire real time data stream. If this is not done, then the application may lose some data during startup, and/or during a system event that generates a large volume of data.
Applications may be notified of incoming real time data in two different ways: by Windows message or by a callback function.
The advantage to this method is that your application will be processing incoming real time data messages in the main thread of your process. Since most processes will only have one thread, this makes accessing your real time data structures quite safe.
The disadvantage to this method is that Windows messages actually generate a fair amount of overhead. So a heavily loaded system will be that much more heavily loaded by applications processing incoming real time data through Windows messages.
The advantage to this method is efficiency. The callback function will be called directly by the IPCAPI library thread whenever it is awakened by the partner process with data in your pipe. The disadvantage is that since the callback is actually being called from the IPCAPI's internal thread procedure, you must ensure that whatever processing you do within the callback function does not conflict with any operations that your main program (itself, a different thread). If you choose to use a synchronization object (such as a Critical Section), be careful to follow instructions for safe use of such objects. If not, then be very sure that conflicts cannot arise or your application will behave erratically and experience intermittent problems that are very difficult to diagnose.
Win32 implements shared memory sections through the use of memory mapped file objects. The real time database agent will create a shared memory section for the real time database that may be mapped by applications. The real time agent does not expect any applications to be writing to the section (applications should map the section for reading only) and does not offer any synchronization objects for external applications to use. This interface was implemented for use of PICS debugging tools, and generally should not be used by applications.
PICS includes two static database agent applications: SDB and SDClient. From an application's point of view, both are exactly the same. Internally, SDB has physical access to the database files themselves and SDClient uses TCP to communicate with SDServer, who acts as a proxy client for remote applications. SDB cannot determine if a request comes from a local or remote client (because all of that is hidden in the SDServer/SDClient interface), and applications cannot determine if they are using the "real" SDB for the same reason.
SDB creates and maintains a cache of the most commonly used static database tables and fields. This cache is saved as a file and mapped in memory for use by PICS applications directly or thorough the SDB cache API. The cache is transmitted to all nodes by the SDServer to SDClient TCP interface and updates to it are transferred using IP-multicast. The cache allows applications to almost always get the static data needed without any interprocess or intercomputer communication. Besides containing a large portion of each point's data, it contains some common configuration settings from the registry such as the local time zone to be used for display of all system data. A SDBCAPI exist to simplify access to the cache for end applications.
The static database services are provided entirely through the use of IPC Regions. These regions implement a query-response protocol between two processes. The creator of the IPC Region places a query into it and notifices the partner. The partner reads the query, replaces it with a response, and informs the creator. At any time, either participant may close the region informing the other, but normally it is the creator that initiates the close. Static data agents have a query language which not only retirieve the database records, but allow the user to create cursors and filters for efficiently selecting desired records in a table and trimming the reocord to only the desired fields. The query language also allows the user to update many fields in the static database.
The SDBAPI library provides a higher level of abstraction for static database clients. To do this, it creates an internal thread to wait for responses from the static data agent, optionally calling an application-defined callback function periodically while waiting. This structure allows application developers to make a single [blocking] function call to perform a static database operation directly inline with the program execution flow. This is a departure from the IPCAPI Interface, which requires applications to wait for a reply from the agent (which will be received as a Windows message) in a rather inelegant way.
However, this feature comes with a price: namely the fact that there is another thread in applications using this interface offers one more place for unsafe thread programming to creep into your project. On the other hand, if the callback function isn't used, then this API is one of the safer offered by PICS. (A natural result of SDBAPI's being the newest of all interfaces.)
Some applications offer limited features through the Windows messaging service. For example the real time agent will be periodically broadcasting registered messages containing the current values of PICS Time, Plant Mode, and Data Source. Some library functions will broadcast registered Windows messages indicating PICS configuration changes.
Because PICS is a distributed processing system, many applications use TCP/IP (some use UDP/IP) to communicate with partner applications. This may even be done when both applications reside on the same machine in order to retain flexibility to support other configurations. The WinSock DLL creates an internal thread to manage communication with the operating system's networking layers. This thread will not impact PICS applications because no user code is called directly from within the thread. Instead, WinSock functions either block (in the thread) until complete, or return immediately and then send a Windows message to the window that initiate the socket. Each PICS application set that uses TCP/IP (or UDP/IP) has a private internal protocol that is encapsulated within the standard network packets. For details on any specific protocol, see the applications involved.
First, a couple of definitions: PICS nodes may be either trusted or non-trusted. Trusted nodes are connected directly to the PICS LAN and are typically located in areas with physical access control. Non-trusted nodes connect to PICS via the PICS bridge software from outside the PICS LAN. Non-trusted nodes are typically located on the corporate WAN, but may also be located off-site by using Windows NT's Remote Access Services (RAS) to dial in to the PICS (or plant) network.
The Task Monitor Agent is the application responsible for starting the appropriate applications for a node. The TM agent also provides PICS directory services by maintaining a list of known applications and nodes in a shared memory space. A special DLL (TMAPI.DLL) is provided for applications that wish to access the PICS directory and other TM agent services. On trusted nodes, the TM agent is the Task Monitor application (TaskMon) itself. TaskMon communicates with the System Monitor application to configure and startup the node, provide failure notification and recovery, node restarts/reboots, and, of course, task monitoring. On non-trusted nodes, the TM agent is the Access Control Client application (ACC). ACC also provides PICS directory services, however, the directory ACC provides to client applications if affected by the user's access level and the map of services available (configured in the Access Control Bridge application). ACC will typically be configured to automatically activate the required PICS service providers (SDB, RTDB, or their proxies) when the end user starts a PICS application. ACC may also be configured to automatically start some applications, allowing nontrusted nodes to behave similar to trusted nodes (as far as automatic startup, at least). Lastly, like TaskMon, ACC also monitors applications and automatically shuts down PICS services providers that are no longer needed after an application exits.
The EVI function library (EVI32.DLL) contains utility functions that are not specific to the PICS system. For example, routines to display EVI's standard "About" dialog, to draw 3D frames, center windows, etc. are contained in the EVI function library.
The PICS function library (PICS32.DLL) contains utility functions that are specific to the PICS system. For example, PICS time/date translation functions, PICS environment functions, etc. are contained in the PICS function library.
|
|
|
|