An OSI Based Architecture
for Tracking Station Automation

Abstract

The flexibility and robustness of a monitor and control (M&C) system are a direct result of the underlying inter-processor communications architecture. A new architecture for M&C at the Deep Space Communications Complexes (DSCCs) has been developed based on the Manufacturing Message Specification (MMS) process control standard of the Open System Interconnection (OSI) suite of protocols. This architecture has been tested both in a laboratory environment and under operational conditions at the Deep Space Network (DSN) experimental station (DSS-13).

The DSS-13 experience in the application of OSI standards to support M&C has been extremely successful. MMS meets the functional needs of the station and provides a level of flexibility and responsiveness previously unknown in that environment. The architecture is robust enough to meet current operational needs and flexible enough to provide a migration path for new subsystems. This paper will describe the architecture of the DSS-13 M&C system, discuss how MMS was used and the requirements this imposed on other parts of the system, and provide results from systems and operational testing at DSS-13.

I. Introduction

In 1989, the Advanced Systems Office initiated a research effort to examine the application of the International Standards Organization's (ISO) Open Systems Interconnect (OSI) protocols in the Deep Space Network (DSN). The initial study presented an overall OSI architecture for the DSN [Reference 1]. It also presented the results of a prototype effort focussed on the monitor and control requirements for the Deep Space Communications Complexes. In this report, we describe an OSI based pilot Station Monitor and Control system developed and installed at the Deep Space Station-13 facility located at the Goldstone Deep Space Communications Complex (GDSCC).

A. Overview of the DSN Venus Facility, DSS-13

The DSN operates the DSS-13 facility at the Goldstone Deep Space Communication Complex (GDSCC) as a research site to conduct experiments in new tracking techniques, communication technologies and instrumentation. In response to expanding demands on station resources generated by the new 34-meter Beam Waveguide Antenna, the Advanced Systems Program Office initiated the development of a monitor and control system based on OSI protocols. As an experimental facility, the DSS-13 site is constantly changing. New instrumentation is moved to the station and tested on a weekly basis. The procedures to support observations or spacecraft activities change daily. However, DSS-13 is also used to routinely for radio astronomy observations and the High Resolution Microwave Survey (HRMS). A monitor and control system to operate the DSS-13 facility must have the flexibility to support the constantly changing conditions at the station, while providing reliable support for operational experiments.

B. OSI Based Monitor and Control Architecture

The OSI based monitor and control architecture enables operation of DSS-13 through a single operator workstation. Station resources are subdivided into functional units called subsystems. Each subsystem is operated using a computer. OSI protocols are used to link the operator workstation and the various station subsystem computers across a Local Area Network (LAN). Commercial software packages based on the OSI Manufacturing Message Specification (MMS) protocol were employed to support all interprocessor communications. A commercial Supervisory Control and Data Acquisition (SCADA) software package was incorporated to support most of the operator interface functions through a graphical user interface (GUI). The extensive application of commercial software packages made it possible to build and install the system in one year at substantial cost savings.

There are two aspects to the OSI based monitor and control architecture. The first is the communications architecture which employs all seven layers specified in the OSI Basic Reference Model. The second aspect involves the structure of the program (or programs) that run on each of the station computers. This structure is called the software architecture and is tightly coupled to the computer hardware, the operating system and the computer language employed. The software architecture for the Station Monitor and Control workstation is discussed in Section II. This discussion is limited to those components used to integrate the commercial products into a working system. The software architecture of the subsystems is discussed in Section III.

The key element in the application of Manufacturing Message Specification is the abstract model called the Virtual Manufacturing Device (VMD). The VMD model is used to describe the externally visible characteristics of a real device. Software modules which manipulate a real device are called VMD objects. These objects can be manipulated using MMS services such as context management, variable access, domain management, semaphore management and event management services. State changes detected in the real device and defined in the VMD model can trigger MMS services. For the implementation at DSS-13, a minimum of effort was required to make the subsystems appear as VMDs.

C. Basic requirements for DSS-13 Station Monitor and Control

The basic requirements for Station Monitor and Control were derived from the DSN Mark-IVa functional requirements [Reference 2]. These are:

(1) Allocation of station resources to provide assignment of subsystems in support of a station activities. At DSS-13, the MMS context management services are used to support allocation of station resources.

(2) Support data files are received at monitor and control and redistributed to subsystems as required. At DSS-13, the MMS file management services support the distribution of predict files.

(3) Operator directives entered on the monitor and control system support the configuration and operation of subsystems. At DSS-13, configuration and operational control of subsystems is affected using the MMS variable write service.

(4) Subsystem health and performance is displayed on monitor and control. At DSS-13, subsystem health and performance data is obtained using the MMS variable read and information report services. The monitor and control system provides graphical displays of subsystem performance data.

(5) Subsystem event or alarm conditions are generated and reported to monitor and control. At DSS-13, the subsystem health and performance data obtained using MMS variable read and information report services, is used to generate alarms and events on the monitor and control workstation.

(6) Monitor data is exchanged between Monitor and Control and the active subsystems based on negotiated interface agreements. At DSS-13, the MMS variable services provide support for the exchange of monitor data.

To support the constantly changing environment at DSS-13, the following requirements were added:

· The Station Monitor and Control system must support the addition of new subsystems without modification to the software.

· The Station Monitor and Control system must support changes to displays and construction of new displays without new software deliveries.

D. Station Monitor and Control Plans and Schedule

The Station Monitor and Control (SMC) development effort began in October, 1991 in preparation for the Ka Band Link Experiment (KaBLE) scheduled for January, 1993. The Ka Band Link Experiment is a package on board the Mars Observer spacecraft designed to test the Ka Band telemetry performance. The plan called for the installation of a monitor and control computer, monitor and control software and a Local Area Network (LAN) to provide communications to all of the station subsystems (see Figure 1). The initial plans called for six subsystems to be modified for operation across the LAN and through Station Monitor and Control. The subsystems included:

· the Local Control Display (LCD) for the antenna control subsystem,

· the Weather Station (WX),

· the Microwave Controller (UWC),

· the Advanced Receiver - II (ARX-II),

· the Telemetry Processor - 13 (TP-13),

· and the KaBLE Data Handling Terminal (DHT).

The subsystems were already under development and no major modifications could be imposed that would impact their development effort. Consequently, product selection criteria required support for subsystems based on the Intel 80x86 computer platform and DOS operating system.

E. Unexpected Additions

In January, 1992, the antenna subsystem team began a development effort to replace the Local Control Display (LCD) and the Antenna Control System (ACS) with a single computer system. The antenna team had determined that enhancement of the LCD/ACS system to meet new functional requirements warranted a new subsystem architecture. The new Antenna Monitor and Control (AMC) subsystem was not instigated by the monitor and control integration project. The Antenna Team specified a DOS based 80386 computer imposing no new requirements for Station Monitor and Control.

In March, 1992, the development effort on the KaBLE Data Handling Terminal was impaired by limitations of the DOS operating system. In response, Station Data Recorder was designed and developed to collect data from all of the subsystems. The Station Data Recorder was built to pass data to the KaBLE Data Handling Terminal through a serial interface.

In June, 1992, the High Resolution Microwave Survey (HRMS) encountered problems with control of the antenna through the Antenna Control System (ACS). A HRMS gateway was proposed and developed in two months to provide communications between the HRMS equipment and the new AMC. Also in June, a Programmable Oscillator was added to the station. The software was added to the Station Data Recorder to operate the Programmable Oscillator from Station Monitor and Control.

Figure 1. Configuration of the DSS-13 Local Area Network.

II. Station Monitor and Control

The Station Monitor and Control system was initially implemented on a Intel 80386, 33 MHz computer running the Interactive Unix 2.2.1 operating system. The computer platform was provided to the project and selection of software components was governed by the platform. The selection of the Unix operating system was made to provide a flexible multi-tasking environment. The platform and operating system directed the selection of the specific MMS/OSI software package. In addition, the platform and operating system led to the selection of a Supervisory Control and Data Acquisition (SCADA) software package called Dexterity. The Dexterity product met all of the basic requirements to support the operator interface and provided an Application Program Interface (API) to support software development. The software development effort was limited to providing a link between Dexterity and the MMS network services.

A. Subsystem Software Architecture

The basic components of the software can be seen in Figure 2. The User Programs and Dexterity Program Interface (DPI) represent the Dexterity product. The following elements were developed to support the MMS/OSI network:

The MMS-Dexterity Network Server (the dexd.x daemon) provides all of the network services for Station Monitor and Control. The network server is a program that runs concurrent to Dexterity under the Unix operating system and by Unix convention is called a daemon. The dexd.x daemon supports the initiation and conclusion of connections, the MMS file transfer and MMS variable services. In all variable services, the dexd.x daemon performs a mapping between Dexterity database elements and their corresponding MMS variables. The daemon updates the Dexterity database in response to MMS variable read confirmations and information report indications. The daemon extracts Dexterity database elements and performs MMS variable write services in response to operator actions.

The Dexterity Interface Program (dexdif.x) is used to initiate the MMS-Dexterity Network server to take action. The dexdif.x program is initiated when the operator uses the mouse or keyboard to trigger some network action. For example: to connect to a subsystem, to read subsystem status variables, to write subsystem configuration variables.

The MMS-Dexterity Timer Program (the dexd.timer.x daemon) runs concurrent to the network server and provides a heartbeat to initiate polling of subsystem status data using MMS variable read services.

Figure 2. Schmatic diagram of the monitor and control architecture.

B. The MMS-Dexterity Network Server

The key and most complex element in the software architecture is the MMS-Dexterity Network Server. The network server is started simultaneously with the Dexterity product and is table driven so changes to the network can be accommodated without changing the network software. The network server operates in three stages: initialization, operation and termination.

The initialization process sets up the environment to operate the network and interface to the Dexterity Database in a series of steps.

(1) The process begins by reading a table which identifies all of the subsystems on the network. This table contains all of the OSI addressing information necessary to communicate with another MMS network node. An example can be seen in Figure 3.

(2) Next, the network server reads a set of files which identify all of the variables subject to MMS variable access services. The files are organized by subsystem and are designated with a file extension "mms" (example "subsystem.mms"). The file contains the list of named variables (VAR_NAME) and their type specification (VAR_TYPE). Data structures are managed as MMS special types. The variable type definition (VAR_TYPE_DEF) and Type Definition Language (TDL) are used to establish these special MMS variables.

		VAR_NAME: power
		VAR_TYPE: power_type
		VAR_TYPE_DEF: power_type
		TDL: "{Short, Long, Float, Float, Float, Float}"

(3) The network server reads a second set of files which identify the individual variables subject to MMS services. Again, the files are organized by subsystem and are designated with a file extension "dex" (example, "subsystem.dex"). The files provide a text string for each subsystem network variable specified by name, by length in bytes, and by byte offset into it's associated data structure (where appropriate).

(4) The network server must map the subsystem variables into the Dexterity database. To accomplish this job, the network server reads a file called "vardef.txt" that contains the Dexterity database definitions. This file is generated by the Dexterity product to support configuration management. The monitor and control team took advantage of the variable "DESCRIPTION" field in the "vardef.txt" file to associate individual subsystem variables with its companion Dexterity database element.

(5) The final step in the initialization process establishes a connection between the Dexterity database and the network server. This is accomplished by using the DPI connect service.

The files processed in steps 2, 3 and 4 provide the mapping between the subsystem variables managed over the network and the Dexterity database elements. A detailed mapping of these files is shown in Figure 4.

Figure 3. OSI network configuration file.

Figure 4. Mapping of MMS definition files.

Once initialized, the MMS-Dexterity Network Server is ready to support all of the network communication services required to operate the complex from Station Monitor and Control. Station personal operate the complex through a graphical user interface (GUI) managed by the Dexterity software. The Dexterity software supports operator actions through the keyboard or a mouse. The Dexterity database services the user screens. In addition, the Dexterity product provides a set of tools to build and manage the GUI screens. The basic operation of the station is accomplished as follows.

(1) Station resources are allocated to support station activities by establishing a connection between Station Monitor and Control and the selected subsystem. Resources are released by concluding the connection. The process of establishing and releasing a connection is accomplished using the mouse.

(2) On connection, the configuration and status of a subsystem is read by, or reported to Station Monitor and Control using the MMS variable read service or information report service. Changes in subsystem status and performance are echoed on Station Monitor and Control using the same MMS services.

(3) Operators control a subsystem by entering configuration parameters through the GUI into the Dexterity database. The operator action triggers the Dexterity Interface Program to execute. The Dexterity Interface Program passes the selected parameters to the Dexterity Network Server. The Network Server extracts the selected data from the Dexterity database and writes the data across the network to the subsystem.

(4) Support data files are received by Station Monitor and Control from JPL across the NASA Science Internet. Operators distribute support files to individual subsystems using the MMS file transfer services. The operator uses a Dexterity screen to enter the file name to be transferred, the destination file name and the destination subsystem.

(5) Events and alarms are supported in two different ways. Both methods combine the MMS information_report service with the Dexterity alarm service. In the first method, the subsystem is programmed to report data based on changing conditions. The subsystem software engineer can report on change, report on critical condition and/or report on return to nominal condition. The Dexterity database is then configured to alarm the operator when a reported data element goes outside its limits. In the second method, the subsystem is programmed to report a text message to Station Monitor and Control. The conditions that warrant a text message are left to the discretion of the subsystem software engineer. The text message is sent to Station Monitor and Control using the MMS information_report service. The Dexterity database is configured to display these text messages as events or alarms as a function of the message type.

The termination of the Network Server is a relatively simple process. Typically, the operator will disconnect (or conclude) from all subsystems prior to shutting down Dexerity. However, if connections are still established the Network Server will disconnect prior to termination. The last step is disconnection from the Dexterity database.

III. Subsystems

A. Subsystem Architecture

The subsystem software architecture was driven by the selection Intel 80x86 based computers and the DOS operating system. Personal computers and the DOS operating system are frequently used by experimental subsystems because they are inexpensive and simple to program. DOS is a "single user" operating system and supports execution of only one program at a time. The subsystem program is structured to establish the subsystem configuration and status on execution, and to run in a continuous loop until an operator interruption triggers termination. All subsystems were developed using the Microsoft C compiler. The pseudo-code below is an example of this architecture:

	main()
	{
		set up subsystem environment;
		while( not interrupted by operator )
		{
			monitor subsystem operations;
			execute subsystem commands;
		}
		set subsystem in safe shut down conditions;
		exit;
	}

	main()
	{
		dsn_init_mms(); /* routine called to set up the network
					environment*/
		set up subsystem environment;
		while( not interrupted by operator )
		{
		      monitor subsystem operations;
		      execute subsystem commands;
		      dsn_comm_server();    /* routine called to check for
						   network messages */
		}
		set subsystem in safe shut down conditions;
		dsn_terminate_mms();  /* routine called to terminate the
					     network environment	*/
		exit;
	}

A package of software was developed to provide the MMS services required to support the operation of each subsystem across the LAN. The services are summarized below.

Setting Up the MMS Environment

The dsn_init_mms() routine is called to establish the network environment to support MMS communications. The initial channel configuration and subsystem network variables are established as a part of this process.

The dsn_terminate_mms() routine is called to close down the network environment prior to program termination.

The dsn_comm_service() routine is called by a subsystem periodically to process incoming network messages. The implementation of this routine is highly dependent on the operating environment, computer hardware, operating system, network hardware and drivers.

Context Management Services

The routine dsn_init_chan() is used by a client subsystem to initiate communications with a server. The initiate routine issues a message to the target server subsystem indicating that a client is attempting to establish a relationship. The server subsystem will respond with a positive or negative message depending upon conditions. A positive response is generated when the server subsystem has the client's address information in its Data Information Base (DIB) and the resources (an open channel) available to support communications. A negative response is generated if the server subsystem does not have resources available or if the client's address is not in the server's DIB. The server subsystem response provides the conformation to the client to conduct communications or that communications is not possible.

The routine dsn_conclude() is used by a client subsystem to close an association with a server subsystem. The conclude message generates a conclude_indication at the server susbsystem. The server subsystem will respond with a positive or negative conclude message depending upon conditions. If all of the client requests for communications are complete, the server subsystem will respond with a positive confirmation and release the channel resource. However, if there are outstanding requests that the server as not yet responded to, the server subsystem will issue a negative response. The server subsystem response provides confirmation to the client that the association has been closed or remains open pending outstanding responses to previous client requests.

The routine dsn_listen() is used by a server subsystem to open a communication resource. The communication resources for each subsystem, commonly referred to as channels are established when the subsystem initiates operation. A subsystem that operates as a server will allocate listen channels for clients to establish communications. The dsn_listen() routine is provided to permit a subsystem to allocate additional channels as server channels while operating. The dsn_stop_listen() is used to close a channel in the listen mode.

The routine dsn_abort() is used by a client to terminate a client-server association without regard for pending requests. This service is intended for use under special conditions and not to be used in place of the dsn_conclude() service.

File Management Services

The routine dsn_copy_file() is used by a client subsystem to copy a file from a server subsystem.

The routine dsn_send_file() is used by a client subsystem to invoke the MMS obtain file service in which a server subsystem copies a file from a client subsystem.

The routine dsn_delete_file() is used by a client subsystem to delete a file from a server subsystem.

Variable Services

The routine create_dsn_mms_types() is used to establish a variable as a network object. Subsystem implementors use this routine to register variables that will be managed across the network, with the subsystem network software. The registration process identifies the address of the variable, its type and size to the subsystem network software.

The routine reg_write_var_indic_func() is used to identify a function to be called by the server, when a specific named variable is written across the network. For example, a server subsystem could have a physical switch that is set according to the value of a named variable. By design, the switch must be reset to its new condition on change of the named variable. The server subsystem software engineer can write a function that affects the physical change of the switch and use the reg_write_var_indic_func() routine to associate the function with the named variable. When the write_indication is received for the associated named variable, the function is called.

The routine reg_write_var_confr_func() is used to identify a function to be called by the client, when a specific named variable is written across the network and the write confirmation is received by the client. Extending the example above, a client could have a sequence of actions to perform that are dependent of the server subsystem switch position. The client subsystem software engineer can write a function that affects action that can only occur after the switch reset has been affected. The client function can be associated with the named variable write confirmation using the reg_write_var_confr_func() routine. When the write_confirmation is received for the associated named variable, the function is called.

The routine reg_read_var_indic_func() is used to identify a function to be called by the server, when a specific named variable is read across the network. For example, the status of some element of a server subsystem is reflected by a named variable. The subsystem software engineer can write a function to update the status and associate that function with the specific named variable using the reg_read_var_indic_func() routine. When the read indication is received, the function will be called and the read response will reflect the latest status.

The reg_read_var_confr_func() is used to identify a function to be called by the client, when a specific named variable is read across the network and the confirmation is received by the client. Extending the example above, the client subsystem software engineer will write a function to take action on the status returned by the server subsystem. That function is associated with the specific named variable using the reg_read_var_confr_func() routine. When the read confirmation is received by the client, the function is called.

The reg_info_report_func() is used to identify a function to be called by the client, when a specific named variable is reported by the server using the dsn_send_info_rpt() service.

The dsn_write_var() routine is used by a client subsystem to write a named variable to a server subsystem.

The dsn_read_var() routine is used by a client subsystem to read a named variable from a server subsystem.

The dsn_send_info_rpt() routine is used by a server subsystem to report a named variable to a client subsystem.

The dsn_send_event_msg() routine is used to send a text message to monitor and control in support of the operations personnel. The service provides a time tag, the category of message and an eighty character text string. The category of message is derived from the same event message specification created for Mark-IVa, prompt, progress, deviation, warning, alarm and critical alarm.

IV. Conclusions

The Station Monitor and Control system has been operating on a daily basis at DSS-13 since December, 1992. The operation personnel have developed an extensive knowledge and understanding of the system. The station personnel perform routine configuration management, develop new tools and new screens as conditions change.

The implementation of DSS-13 Monitor and Control has demonstrated that the OSI/MMS protocols can be used to support spacecraft tracking station automation. The MMS services meet the functional requirements for interprocessor communications in the DSN tracking stations. The integration of a commercial monitor and control package with an MMS network server has created a powerful, flexible tool to support the constantly changing requirements at DSS-13. Most of the cost savings derived from the MMS/OSI approach comes from the application of commercial products. The software developed in this activity to support the MMS network services on Station Monitor and Control is less than 20,000 lines of code. The commercial software products represent more than 750,000 lines of code. The functional capabilities provided through the combination of these two technologies offer great potential for cost savings.

LANs and Protocols

The system installed at DSS-13 incorporates two different MMS products running over three different OSI stacks. Two interoperability problems were discovered in the MMS products. One product failed to interpret floating point variables contained in data structures as originally delivered. Once the problem was identified, the company provided a fix in 48 hours. A second problem was detected with the encoding of double precision floating point variables contained in data structures. It took several days to isolate the problem. Once isolated, the two companies identified the specific issues involved and the problem was fixed in two weeks.

The selection of the token bus (ISO 8802-4) LAN technology was a matter of convenience. The initial prototype work for this research effort was conducted using a token bus LAN. This direction was taken because General Motors originally specified token bus technology for its factory automation effort and commercial MMS products were readily available. The first ethernet based MMS products for DOS based systems emerged just at the start of the DSS-13 implementation. Given the limited schedule for the project, we choose to stay with the token bus LAN for the first phase. We have now installed an ethernet to token bus bridge to support the transition to an ethernet based LAN.

Based on the experience at DSS-13, we are examining several other MMS services to enhance the present system. The MMS variable list services offer greater flexibility to the management of data on the subsystems. A client can define a named variable list (define_named_variable_list) on a server subsystem based on the client's requirements. The client can then perform an MMS read_named_variable_list to access a large number of variables with a single transaction. The client can delete the named variable list before ending the session.

The modification of subsystem software developed as a stand-alone DOS application proved to be relatively simple. The first subsystem adapted for MMS support was the Advanced Receiver. The modifications required about four weeks, with the work distributed over a period of four months. The second receiver required only a week. However, the limitations imposed by the DOS operating system are severe. DOS is limited to 640 Kbytes of operating memory. The basic monitor and control MMS services require about 250 Kbytes of executable space. Consequently, subsystem software based on the DOS operating system are severely limited in size. In addition, DOS is a single task, single thread operating system. Applications must be designed to support processing of monitor and control network messages without disruption to the subsystem services. Both of these problems warrent the selection of a more robust operating system. MMS products are available for operating systems like Unix, VMS, QNX and OS/2.

Application Enablers

Dexterity is one product that is representative of a class of products called Application Enablers. Dexterity met or exceeded all of the functional requirements for Station Monitor and Control, however two limitations were discovered in the development effort. First, the Dexterity database supports four types of variables: short integers, long integers, single precision floating values and character strings. There are a number of data elements at the station that require a double precision floating point values that are not supported. A work-around was developed to support double precision values, however future implementations should specify support for doubles. Second, the Dexterity Application Programming Interface (API) provides access to the Dexterity database one element (variable) at a time. This approach limits the performance of the Dexterity product. An API that provides for multiple elements to be entered into the database with a single call, would be more efficient.

The software architecture of commercial application enabler products varies from product to product. Though most of these products provide many of the same functions and services, each product has its own forte. Most packages are built for multi-tasking operating systems. Some packages establish a database in shared memory or global memory space. Some products simply pass data to each task that requires the data. Some products store configuration information is discrete files and others store their configuration information in a single file.

A detailed analysis of the software architecture for Application Enablers is beyond the scope of this article. The selection of a particular Application Enabler must be based on the functional requirements of the system. For example, if the database must be dynamically reconfigured, a product that employs a shared memory database may not be a good choice. The selection of a package to meet a specific set of requirements demands careful consideration.

V. Future Directions

Work continues at DSS-13 with the implementation of Station Monitor and Control on a Sun Sparc Workstation. In addition, work is underway to provide full automation of the station based on other research efforts conducted at JPL.

Research on the application of OSI protocols is also continuing. A commercial package based on the X.400 and X.500 standards will be installed in 1994 to examine support of operational messaging services. In 1995, Common Management Information Protocol and Services will be investigated for application in Network Management.

Acknowledgements:

The authors wish to thank the operations personnel at DSS-13 for the evolvement and support of this activity: Jerry Crook, Ron Littlefair, Gordon McKeiver and Chuck Goodson. The effort has contributed substantially to the success to the Station Monitor and Control system. In addition, the authors wish to thank Lyle Skjvere for his special efforts in support of this research. Finally, the authors wish to thank Denise Patrishkoff of System Integration Specialists Company for her support and technical expertise. denise@sisconet.com

References:

[1] W. Randy Heuser, "An OSI Architecture for the Deep Space Network", TDA Progress Report 42-109, Jet Propulsion Laboratory, Pasadena, CA, March 30, 1992.