Manufacturing In Deep Space

JET PROPULSION LAB PUTS THE MANUFACTURING MESSAGE SPECIFICATION BACK ON THE MAP, USING IT TO DELIVER PROCESS CONTROL INFORMATION TO THE DEEP SPACE NETWORK

Imagine attempting to locate the position of a spacecraft within 10 meters at a distance of four billion miles. That is precisely the job of NASA's Deep Space Network, whose next generation's test facility is controlled at the core with a local area network using the Manufacturing Message Specification (MMS) protocol.

The Deep Space Network was established in the late 1950s to provide telecommunications to and from spacecraft in deep space. It has always used automation whenever possible to support this mission and can operate today with significantly less human involvement and support than 20 years ago. It has evolved into a distributed computer system with multiple processors located around the antenna site.

As with all LANs, the Deep Space Network program team faces four ongoing challenges

· reducing the cost of software maintenance and support;

· selecting cost effective replacement technologies;

· systematically upgrading individual processors without disrupting system operation; and

· increasing the throughput on the network.

Furthermore, since the Deep Space Network is federally funded, the program team must accomplish its task within the guidelines of U.S. government procurement practices.

Three years ago, Randy Heuser, a member of the technical staff at Jet Propulsion Laboratory (JPL), began a study of OSI protocols to understand their use for interprocessor communication and control applications. It was preferable that OSI work for Deep Space Network, since the OSI architecture had been adopted by the U.S. government as the standard for distributed government computer systems. The Consultative Committee for Space Data Systems (CCSDS) plans to use the protocols wherever possible.

Heuser's primary goal was to define an architecture that would reduce the cost of software development and maintenance. He reviewed all seven OSI layers but focused on the application layer. This layer included the well-known File Transfer, Access and Management (FTAM); Message Handling Systems (MHS); and Virtual Terminal (VT). He went on to study lesser-known application entities: Remote Database Access (RDA) and Job Transfer and Manipulation (JTM). Then he turned to a protocol designed for factories, MMS. This protocol provides a set of services developed from the Manufacturing Automation Protocol (MAP) initiative at General Motors in the early 1980s.

Designed as a process control standard, MMS is aimed at direct interprocessor communications among machines on a factory floor. In a factory environment, an assembly line can be composed of hundreds of machines performing complex, precision tasks all as a coordinated unit. If any element of the assembly line fails to perform, or performs at less than an optimum level, the assembly line as a whole will fail. The interprocessor communication provided by MMS is designed to support this type of environment and has good applications to Deep Space Network operations.

THE DATA OF DEEP SPACE

Deep Space Network operation requires two general categories of data: real-time spacecraft data, which is acquired, recorded, and transmitted back to JPL (the analysis center) to support flight projects; and process control, which supports all aspects of Deep Space Network Operations. This category includes the transmission of support data and network control data. Another way to think about the different types of data is that the real time data communicates between the spacecraft and JPL, while the process control data communicates within the ground station (see Figure 1).

Heuser discovered that real-time spacecraft data could be handled sufficiently by FTAM software to open a client-server relationship with a station data recording subsystem (commonly referred to as a network file server). Therefore, dealing with real-time data became as functionally simple as moving files between workstations on a LAN.

The control information had a different set of operation requirements. It needed to do more than just move data from point to point. Somehow, Heuser sought to incorporate application and equipment control in the information. What he discovered was the functionality of MMS.

Deep Space Network officials liked the results of Heuser's study and were encouraged about using OSI in their control network. The next step was to construct a prototype control system that could prove the capabilities of MMS at the Deep Space Network antenna site in Goldstone, CA.

GOLDSTONE GROUND STATION

The Deep Space Network operates a ground tracking station in Goldstone, CA, slightly southwest of Death Valley. The ground station contains a number of radio wave antennae that listen for spacecraft radio broadcasts (see Figure 1). These are physically distributed across a 20 kilometer square area. The radio signals are received by the antennae and transmitted to a centralized hub that combines the signals, performs error correction if necessary, and sends a single set of data on to JPL. The data transmission takes place over a dedicated T-1 and 56Kbps line.

Figure 1: Deep Space Network operation requires real-time spacecraft data, which is acquired, recorded, and transmitted back to Jet Propulsion Lab (JPL) to support flight projects; and process control, which supports all aspects of Deep Space Network operations. The real-timdata communicates between the spacecraft and JPL, while the process control data communicates between JPL and the ground stations.

At JPL, located some 200 miles south of Goldstone, scientists and program team members analyze the data and take action. Today, the data is communicated over leased lines using proprietary protocols. By using MMS and its OSI protocols, JPL will gain another advantage when the NASA Science internet adds OSI routing support, and the data can be transmitted across this internet. This upgrade is scheduled to by completed before the end of 1992.

The existing installation is being replaced with new antennae using Beam Wave Guide technology to enable them to track the upcoming Mars Observer and Search for Extra Terrestrial intelligence (SETI) programs. Heuser knew this upgrade process would be the ideal time to incorporate OSI and MMS. Each antenna can include up to a dozen controllers for antenna positioning, receiver pointing, microwave switching, and spectrum analysis. By linking these controllers with an OSI network, individual processors could be shared, and any new software that had to be developed could take advantage of MMS control.

The processor architecture envisioned is client-server with a single master controller, a Sun Microsystems SPARC system, issuing instructions and gathering data from the slave 286- or 386-based controllers. The controllers are computer systems put together by either NASA engineers or commercial vendors.

Traditionally, upgrades to the controller system have been expensive, because of the specialized cost of the hardware, plus the need to extensively rewrite software applications. With the realistic assessment that Uncle Sam's budget is going to get tighter in the coming years, Heuser was ready to bring a distributed architecture to antenna control.

PROTOTYPING THE FUTURE

Heuser and a small team of NASA engineers began work on a prototype ground station control system in early 1991. The system, composed of three processors, made it possible to establish a connection to transfer configuration and operation information files, to issue control commands, and to monitor actions. The human interface was a commercially available Graphical User Interface (GUI) software product from US Data. The GUI already supported direct calls to MMS.

GUI software tools gave the software team a significant head start on application development. In the past, display processing and ;interpretation of command software had to be developed for each processor in the system. With MMS, the team could define the code one time for the master processor. This code could process the information and deliver specific commands to the slave processors over the network without duplicating the code on the slave processor. Since display processing and command interpretation software had traditionally represented 30 to 50 percent of the total software on each processor, this feature alone saved significant development time.

For network capability, the NASA team employed IEEE 802-4 Token Bus networks. They found them to be readily available with support for the OSI protocol stack and MMS. Given the flexibility of OSI, the team knew that applications could be moved to alternative link-layer controllers such as Ethernet or FDDI. Since all networking components were commercially available, competition in the marketplace would select the winning options while lowering the price.

In fact, Heuser was surprised at the broad availability of OSI and specifically MMS implementations. He found that many leading computer companies have versions of the software available or planned for the near future and that many companies that have traditionally provided standalone factory automation equipment are offering network-support software and tools.

MINIMAL LEARNING CURVE

To test the theory that MMS could reduce the software development time, Heuser added team members that had little or no networking application development experience. Neither software engineer had worked with MMS but began working quickly on control applications.

Heuser credits the structure of MMS with aiding in the short learning curve. Most network application interfaces work on a principle similar to Berkeley TCP/IP socket abstractions, where the network is nothing more than a virtual data pipe. The complete interpretation of the data is left to the application above the socket. MMS has a more complete understanding of the data, because data relationships must be more clearly defined (see Table1).

It is estimated that the team may have spent twice the time defining communication rules (or in MMS vocabulary, virtual manufacturing device definitions) that a TCP/IP programmer would spend in developing a client-server application. However, once those rules are established, Heuser and his team spent a fraction of the time developing code. They estimate that their final code is less than 25 percent of the number of lines it would have taken using TCP/IP (see Table 2).

EARTHLY LESSONS

The Deep Space Network control project at JPL teaches developers several lessons about client-server application development. Specifically, an existing tool in MMS can be put to work today, simplifying the development process. Heuser believes that people need to stop thinking of MMS as a factory tool only and begin to view it as a structured programming environment for client-server applications.

Heuser further contends that application developers have a lot to gain by using the LAN to send commands as opposed to data that must be interpreted by the receiving station. And since software on LANs can be created by a diverse number of manufacturers, a tool such as MMS needs to be employed to guarantee interoperability.

Final, Heuser is convinced that MMS directly addresses the concerns of LAN managers, in that it simplifies and shortens software development and maintenance, is scaleable to a variety of processor architectures today and into the future, and increases the theoretical capacity of the LAN because it moves fewer and smaller amounts of data on the network than other protocols.

Many organizations and other governmental agencies agree with Heuser's assessment. Factories around the world are employing MMS as a mechanism for process control. Probably most famous is the Toyota/Lexus plant in Japan. MMS is used extensively to control robots on the factory floor. Its use is one of the reasons credited with bringing the plant on-line in a short period of time. MMS is also used by Nissan in its Infiniti and by General Motors in its Saturn manufacturing plants.

GOLDSTONE GROUND STATION: The Deep Space Network operates a ground tracking station in Goldstone, CA, which contains a number of radio wave antennae that listen for spacecraft radio broadcasts. The radio signals are received by the antennae and transmitted to centralized hub that combines the signals, performs error correction if necessary, and sends a single set of data on to JPL.

Since his team completed the prototype, many people have visited JPL to learn more about MMS and its application to their networks. The U.S. Department of Energy is considering implementing MMS as a standard for its networks. Other NASA departments have reviewed MMS for use in application development aboard the US Space Station. Commercially, numerous utility companies have their own prototype projects underway to test MMS as a load-sharing tool in power-generation control.

It all adds up to a protocol that is too good to waste. Heuser encourages people working with client-server architectures to investigate MMS as a time and money saver. Although originally branded as a factory-only protocol, Heuser says that MMS is not only valid but exceptional at non-factory applications. As this client-server example proves, LAN applications know no limits.

Russ Sharer is a principal at imageMakers, a Santa Barbara, CA, firm that provides marketing consulting services to technology companies.