Epicure Software Release Note 151.1<P> <b> The Analysis and Design of the Epicure Gateway</b>

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