Figure 1 shows the basic physical structure of a control system implemented via EPICS. The rest of this chapter gives a brief description of EPICS:
Figure 2, above, contains an overview of the IOC software components and their interactions.
Each record type has a fixed set of fields. Some fields are common to all record types and others are specific to particular record types. Every record has a record name and every field has a field name. The first field of every database record holds the record name, which must be unique across all IOCs attached to the same TCP/IP subnet.
A number of data structures are provided so that the database can be accessed efficiently. Most software components, because they access the database via database access routines, do not need to be aware of these structures.
Database Access
With the exception of record and device support, all access to the database is via the channel or database access routines. See Chapter for details.
.Database Scanning
Database scanning is the mechanism for deciding when to process a record.
Four types of scanning are possible: Periodic, Event, I/O Event, and Passive.
The IOC software is designed so that the database access layer knows nothing about the record support layer other than how to call it. The record support layer in turn knows nothing about it's device support layer other than how to call it. Similarly the only thing a device support layer knows about it's associated driver is how to call it. This design allows a particular installation and even a particular IOC within an installation to choose the set of record types, device types, and drivers it wishes to use. The remainder of the IOC system software is unaffected.
Because an Application Developer can develop his own record support, device support, and device drivers. Every record support module must provide a record processing routine. It is this routine that is called by the database scanners. Record processing consists of some combination of the following functions (particular records types may not need all functions):
Database Monitors
The routines described in this section provide a callback mechanism for database
value changes. This allows the caller to be notified when database values change
without constantly polling the database. A mask can be set to specify value changes,
alarm state changes, and/or archive changes.
At the present time only channel access uses database monitors. No other software
should use the database monitors. Because they are of interest only to channel access,
the monitor routines will not be described.
Channel Access
Channel access provides network transparent access to IOC databases. It is based on a client server model. Each IOC provides a channel access server which is willing to establish communication with an arbitrary number of clients. Channel access client services are available on both OPIs and IOCs. A client can communicate with an arbitrary number of servers.
Client Services
The basic channel access client services are:
Search Server
Channel access provides a server which waits for channel access search messages. These are generated when a channel access client (for example when an Operator Interface task starts) searches for the IOCs containing process variables the client uses. This server accepts all search messages, checks if any of the process variables are located in this IOC, and, if any are found, replies to the sender.
Connection Request Server
For each IOC containing process variables it uses, the channel access client issues connection requests. The connection request server accepts the request and establishes a connection to the client. Each such connection is managed by a separate task (actually two tasks). Ca_get and ca_put requests map to dbGetField and dbPutField database access requests. Ca_add_event requests result in database monitors being established. Database access and/or record support routines trigger the monitors via a call to db_post_event.
Connection Management
Channel access provides a connection management service. When a channel access server fails (e.g. it's IOC crashes) the client is notified. and when a client fails (e.g. it's task crashes) the server is notified. When a client fails, the server breaks the connection. When a server crashes, the client automatically re-establishes communication when the server restarts.
OPI Tools
EPICS provides a number of OPI based tools. These can be divided into two groups based on whether or not they use channel access. Channel access tools are real time tools, i.e. they are used to monitor and control IOCs.