Epicure Software Release Note 151.1
The Analysis and Design of the Epicure Gateway
David M. Kline
Abstract:
The Epicure control system provides a unidirectional path for clients
to acquire data and set the parameters of devices residing within the CAMAC
instrumentation.
The incorporation of ARCnet communications on the Epicure front ends
suggests that a bidirectional path can exist between the Epicure control
system and the EADnet.
With a bidirectional path, services and data supported by Epicure and EADnet
are accessible from either direction.
The Epicure Gateway is the agent primarily responsible for implementing
transparent access between entities within the Epicure control system and
ones residing on EADnet.
The initial implementation of the Gateway will be employed by the Radiation
Safety Group to acquire and monitor device data from the Epicure control system.
Future releases will incorporate enhancements which provide accessibility
to other services supported by various networks and protocols.
This paper will focus on the analysis and design of the Epicure Gateway and the
services which are supported for clients.
Overview
The Epicure Gateway provides transparent connectivity and accessibility
to available services and data, respectively, between entities residing
in the Epicure control system and the EADnet network.
The Gateway executes within the context of Digital's OpenVMS operating system
on an Epicure data acquisition front end.
Requests for connection to services supported by each network are received by
the Gateway and processed accordingly.
The Gateway responds to requests by establishing a virtual circuit between the
two entities which acts as the medium for communicating additional requests and
data transmissions.
Entities, also referred to as clients, request a connection to a particular
service that is provided by the products specific to Epicure, such as data
acquisition and database accesses, or ones specific to EADNet, such as a
request for module configuration.
This is accomplished by the client calling the connect Application Programming
Interface (API) routine.
The Gateway establishes the connection to the service by creating a virtual
link by which the client can call and access data supported by the service.
The link is terminated either by the client explicitly calling the disconnect
API routine, or through an exception due to abnormal termination of the service.
The Gateway implements communication between EADnet and Epicure through an
ARCnet module located on VMEbus.
The module is comprised of the SMC COM20020 ARCnet integrated circuit, and
other support circuitry which generates an interrupt to the Epicure front
end when a message is received from EADnet.
The interrupt is routed through the TURBOchannel interface and activates
the TURBOchannel Connect-to-Interrupt (TCI) driver.
The TCI driver dispatches the interrupt, given the vector from VMEbus, to the
process that attached to it during system initialization.
The control and data registers of the COM20020 are accessible through
VMEbus address space to perform the required actions which control and
process ARCnet messages.
The primary responsibility of the Gateway is to manage virtual circuits and
support communication between clients requesting connections from EADnet and
Epicure sources.
The Gateway uses the TURBOchannel-to-VME system services [4] to
communicate with the VMEbus hardware.
This is accomplished by mapping the control and data registers supported by the
COM20020 into the virtual address space of the process
.
The Gateway attaches to the interrupt vector associated with the ARCnet module
in order to receive messages from EADnet.
Furthermore, TVI services are called which establish a connection with a VMEbus
common memory queue in order to interface with the standard data acquisition
mechanisms.
In order to communicate with other sources residing on DECnet, the Gateway
establishes itself as a network object making it eligible for multiple
inbound connections and requests from OpenVMS clients.
Gateway services
The Gateway supports the standard EADnet services and extends them by
including services supported by the Epicure control system.
Standard EADnet services include the Network Task Identifiers (NTI) which are
described in [3].
Ones supported by the Epicure control system include data acquisition,
database, alarm, event, name, Controls Universal Bridge (CUB), and network
services.
Future extensions to the Gateway might include ones which support TCP/IP
protocols, such as telnet, ftp, and Remote Procedure Calls (RPC).
In addition to the aforementioned Epicure services, the Gateway supports
the establishment and management of virtual circuits.
Virtual circuits represent the connectivity of a client/server relationship
between entities existing in the Epicure control system and EADnet.
Below further discusses the services which are supported by the Gateway.
EADnet Service
Since the Gateway exists within EADnet, it supports the standard EADnet
services as outlined in [3].
However, since these services were implemented typically for EADnet residents,
they are not necessarily applicable to the Gateway in all instances.
Therefore, the Gateway implements only the ones deemed appropriate.
The following describes the NTIs supported by the Gateway and is based on
the text in [3].
- Send Configuration:
- Information pertaining to the Gateway is returned to
the caller and conforms to the format suggested by [3][p.5].
- Echo Message:
- The Gateway returns the received message to the caller.
- Accept Message:
- The received message is accepted by the Gateway, however,
no further processing is performed. Messages of this type are primarily used
for generating EADnet maps.
Virtual Circuits
A Virtual Circuit (VC) is the primary element that provides the means for
communication between entities resident on Epicure and EADnet.
Consequently, one must be established before any communication can occur
between a client and service.
The Gateway Application Programming Interface (API) provides routines that
are used by clients and services to establish connections among themselves to
implement their defined responsibilities.
The primary responsibilities of the API are to establish a VC between a client
and a service, support message passing across various protocol stacks, and
to consistently terminate a VC under normal and abnormal circumstances.
A client requests a connection to a remote service from a particular
destination by calling the connect API routine.
The connect routine formats a message, given the requested NTI, and transmits
it to the appropriate network and destination.
The recipient processes the message and determines whether it supports the
request.
If the NTI is not supported, a response message is sent rejecting the request
and the connect routine returns a condition code to the caller.
The caller can respond through an exception, or retry by sending the request
to another destination.
Another option for the caller, is to send the exception message to the event
service (see below).
If the service is supported by the given destination, a success response
is returned to the Gateway where the necessary resources are allocated to
establish a VC between the entities.
After the establishment of the VC, the client is allowed to access any of the
routines or data supported by the service.
The VC is disconnected either by the client explicitly calling the disconnect
API routine, or automatically if an exception occurs, such as VC timeout.
The Gateway establishes an activity timer on the VC.
The purpose of the timer is to monitor the number of accesses by the client and
to determine whether the client, or service, has terminated abnormally.
In the event of a timeout, the Gateway communicates the condition to the entity
that is still connected, and relinquishes any resources which have been
allocated.
If the Gateway was terminated because of abnormal conditions, such as power
failure, a message is sent to all connected entities indicating the state.
Data Acquisition Service
The Gateway supports the Data Acquisition (DA) service for clients using the
normal data acquisition channels of the Epicure control system.
The client establishes a connection with the DA service, given the defined NTI,
and requests data from Epicure devices residing on the CAMAC network
.
The request includes a list of device names, represented in ASCII, and the
frequency, represented as an Frequency Time Descriptor (FTD) [2], by
which to acquire their data.
The Gateway receives the list and initiates data acquisition on behalf of the
client using the standard data acquisition UTI (da_ calls).
The return data acquisition is packetized and transmitted to the caller at
the specified FTD.
The packet includes the return status from the da_ call and the readback of
the device.
If however, the device does not exist, the appropriate condition code is
returned with zero data.
Furthermore, if all devices do not exist, the list is rejected and returned to
the caller for appropriate action.
The service is terminated by either the caller explicitly calling the
disconnect API routine, or automatically by the expiration of the activity
timer placed on the VC.
Database Service
The Gateway supports a Database (DB) service to clients for accessing
information pertaining to both data acquisition and non-data acquisition
devices residing in the Epicure control system.
The Gateway performs activities identical to the DA service in terms of
establishing and terminating a connection to the service, and returning the
data acquired from the database calls.
The services differ however, with the calling mechanism employed to obtain the
device information.
The Gateway calls the database UTI routines (db_) to retrieve device
information on behalf of the client.
After a client establishes a connection with the DB service, it can request
any information about devices as defined in [1].
When the data returns from the corresponding database calls, it is packetized
and returned to the client.
Alarm Service
The Alarm Service (AS) is available to acquire information regarding pending
or current alarm information.
Alarm information can only be read from the service, alarm sets are not
accessible but might be included as a future enhancement to the Gateway.
Connect and disconnect activities are identical with other services, however,
the Gateway employs the Alarm Monitoring Services (AMS) UTI to acquire device
alarm information.
The client establishes a connection with the AS service and requests
information about device alarms.
The Gateway executes the AMS call and returns the corresponding data to the
client.
Event Service
The Gateway supports an Event Service (ES) that allows clients to communicate
exceptions to upper levels of the Epicure control system.
The processing associated with establishing a connection and disconnecting
to the ES service is handled similar to the other services available.
Once connected to the service, clients send the exception message and wait
for a confirmation that the message was received.
The received message contains only a returned status verifying that the
exception was successfully transferred to the event handler located on the
Epicure front end.
Name Service
The Name Service is primarily used by clients to collect device names and
access information required for data acquisition and device verification.
The service is derived from the DB service and returns only addressing
information pertaining to the device, primarily for constructing a network
database of device node numbers which reside on EADnet.
The client establishes a connection and requests the translation of the
device name.
The return data includes a status indicating the condition of the request, and
the addressing information of the device, such as node or subnode number.
Disconnecting from the service is accomplished by the same means as with the
other available services.
CUB Service
The CUB Service (CS) is an autonomous agent which periodically monitors the
operating system version numbers and condition of remote CUB systems
[5].
Remote CUB systems connect to the CS to request information about the current
version of the OS, and request automatic downloads.
When a CUB system boots, it connects to the CS and requests the current version
number.
If the versions are identical, no further processing is performed; however, if
they differ, the CUB system requests a download of the operating system.
The CUB system then disconnects from the service and periodically reconnects to
verify its version.
Similarly, when updates occur to the operating systems, the CS can be employed
to distribute the changes to the remote CUB system.
Network Service
The Gateway implements a Network Service (NS) that allows clients to connect
with other network objects, or execute other applications, residing on remote
systems employing DECnet.
The client establishes two connections, one with the Gateway and the other with
the remote object.
The Gateway is responsible for employing the appropriate mechanism to connect
with the remote object on the other destination, and terminating the link.
This service can be primarily used by EADnet to startup remote monitoring
applications, downloading facilities, or databases.
Gateway Implementation
The implementation language of the Epicure Gateway will either be VAX C or DEC
C++.
The later can be used as a measuring tool indicating the involvement required
with migrating Epicure subsystems to an object-oriented programming language.
Standard Epicure routines will be used to implement the individual services
that were referred to earlier.
These include EADnet, data acquisition, database, alarm, event, name, and
network services.
The Gateway begins by calling the required Epicure UTI routines in order to
establish connections for the services that will be implemented.
The Server Network Services (sns_) are used to establish the Gateway as
eligible for connect requests to available services and provides a pathway for
message passing between entities existing on DECnet or EADnet.
Furthermore, clients can establish connections with other remote objects and
services, and execute remote applications from other nodes existing on DECnet
throughout the laboratory.
Each service employs its own input queue.
The SNS API serves as a main input queue to the Gateway process.
When a message is received from any of the sources, the message is entered
into the Gateway input queue and are executed in a sequential order.
The message is then dispatched to the appropriate service queue given the NTI.
The Alarm Monitoring Services (ams_) are incorporated to implement the Alarm
Service as described in the previous section.
The Gateway employs the AMS routines to connect with the Alarm Server process
and access device alarm information.
The TVI services [4] are called to establish a connection with the
common memory queue ``Gateway'' for interfacing with the Data Acquisition
Server (DAS) process.
The DAS interface provides applications with the ability to collect data from
remote EADnet residents by means of the standard data acquisition mechanisms.
To illustrate, EADnet devices can be accessed from PAGE, or monitored by the
Epicure Alarm System.
The TVI services are employed to notify the Gateway of incoming messages from
the VMEbus module.
When a message is received by the VMEbus module, the vector associated with a
particular VAX device is activated.
The VAX device notifies the Gateway that a message has arrived and is ready to
be readout from the VMEbus module.
In addition, the VAX device queues a user mode Asynchronous System Trap (AST)
to the Gateway, thereby asserting a software interrupt.
The AST routine activates and is responsible for clearing the interrupt in the
VMEbus module and reading out the data from the COM20020.
The Gateway responds to events by employing the Epicure Event Priority Queue
(epeq_) routines to synchronize and serialize external and internal events
which occur from VMEbus, DAS, DECnet, or internal processing, respectively.
In addition, a forking mechanism is employed to defer the processing of events
to lower priority routines.
When an event occurs from either of the sources listed above, the corresponding
AST routine is activated.
The AST routine performs minimal operations, such as clearing interrupt bits and
copying data, and enters the event into the queue deferring the processing.
By deferring, or forking, the processing to a lower priority, subsequent AST
routines can execute which makes the Gateway more responsive to external
events.
Because of availability of commercial products employing ARCnet interfaces,
such as PLCs (Allen Bradley) and distributed IO clusters (Opto-22), the
Gateway can incorporate a service that communicates and integrates them into
the Epicure control system for adjustments and data acquisition. This type
of functionality would be included as a future enhancement to the Gateway.
Conclusion
This concludes the analysis and design of the Epicure Gateway. Subsequent
releases of this paper represent incremental refinements to the final
implementation.
References
- 1
- [Db_inc] ``Epicure Database User Include File''.
Epicure include file.
- 2
- [Ftd_inc] ``Frequency Time Descriptor User Include
Files''. Epicure include file.
- 3
- [Kuplic] Mike Kuplic. ``EADnet NTIs and Data Types''.
Epicure Hardware Release #42, April, 1995
- 4
- [Tvi] David Kline. ``VMS System Services for TVI Support''.
Epicure Software Release #137, May, 1995.
- 5
- [Cub] David Kline. ``Object-Oriented Analysis and Design for
Real-Time Systems''. Epicure Software Release #148, August, 1995.
Keywords: EPICURE, ARCNET, GATEWAY
Distribution:
Normal
Security, Privacy, Legal
rwest@fsus04.fnal.gov