The International Space Station (ISS) is a bold, world-scale, long-term commitment to space flight and basic science research in space. The product of a consortium of worldwide companies will yield significant benefits to its partners. These benefits include experience gained through working in partnership with other nations on a mutually prestigious program, advancement in world science and technology, and the reduction of risk and cost to any one nation in its design and construction.
The first node and functional cargo block will be launched in mid-1998 by the NASA shuttle and the Russian proton rockets. From mid-1998 to beyond the year 2002, other hardware elements will be launched and integrated. Node 1 is the first of two nodes that provides the structural building blocks to link the pressurized modules together.
A critical component of the ISS, the Space Station Multiplexer De-Multiplexer—Functional Equivalent Unit (SSMDM FEU), performs critical data acquisition, acquiring data to determine the functionality and the health of the overall space station and to control research modules. Various companies from all over the world are building station components that interface to the SSMDM FEU.
To test this unit, all major space-station sensors and effectors had to be simulated. A sensor and effector simulator (SES) was required to permit timely test of the SSMDM FEU and integrate other segments of the station module.
Requirements Overview
The SES must simulate up to several hundred precision I/O functions. These include the simulation of temperature sensors, pressure transducers, relay closures, actuators for valves, and simulated load cells.
A real-time simulation computer that models how the station behaves in space determines the values of these simulated signals. Using these values, the SES provides the simulated signals to the SSMDM FEU in real time, updating all precision channels 40 times per second.
The critical requirements are:
Up to 300 precision I/O channels capable of being varied on the fly. The stimulus for the I/O channels is provided by programmable isolated 20 mA current sources with microamp resolutions and high accuracies, programmable isolated 10 mV to 32 V voltage sources with resolutions and accuracies of better than 0.1%, and passive power loads and switches with A/D read-back on all channels.
All I/O channels must support an update rate of >40 Hz for all channels simultaneously, with all channels having a guaranteed response time from the instance the simulation computer specifies the new value.
All signals must be isolated from the SSMDM FEU for low noise and protection of the UUT. A noise requirement of <10 mV and minimum crosstalk among channels, using cables to the UUT of up to 15 meters, make this more difficult.Delivery of the system must be in a short period of time.
Operating System
The SES must support simultaneous update of all channels at a >40-Hz rate. This has to be done with deterministic timing performance in response to a real-time channel data stream via a small computer system interface (SCSI) bus, a requirement dictated by compatibility to existing equipment.
The selection of the operating system (OS) proved to be most challenging. Compatibility to existing equipment severely limited the choice of hardware and OS platforms. The prospect of encountering driver and timing problems was a major concern.
To address these concerns, a test-bed VXI system was set up to evaluate the timing performance of the hardware and OS platforms. This system was based on a Pentium PC with a PCI bus, an MXI-2/VXI interface, and a VXIbus chassis.
The first choice was to stay with common industry OS platforms supported on the PC, such as MS-DOS, Windows 95, and Windows NT. To conduct the test, candidate VXI modules and SCSI cards were chosen. A set of custom drivers for each card, optimized for speed, was written for each OS being benchmarked.
The goal was to choose the OS on its capability to support consistent timing and maximize overall performance while minimizing schedule risk. To optimize performance and ensure consistent timing characteristics between each of the tests, custom drivers were written in C/C++ for each OS. Also, the update and latency times per OS for each of the candidate VXI modules were benchmarked using a custom program that provided a simulated command stream with a variable update rate.
We concluded that MS-DOS fulfilled the specific needs of this system. Although more modern and much better able to support powerful GUIs, the Windows-95/NT OSs are multitasking and not designed for real-time applications. We needed performance and simplicity to ensure low risk in delivery and minimize development cost.
System Hardware
Using MS-DOS, the simplest of the OSs, we found that only a limited range of VXI modules even came close to supporting our goal of a 40-Hz update rate over the required number of channels. Those that did supported register-based data throughput.
We found message-based throughput rates to be as much as 100 to 1,000 times slower. Only those VXI modules that passed this level were retained for the remaining OS benchmark tests.
After the OS was chosen, the next step was to evaluate the hardware in a full-up configuration including SCSI and to optimize driver design. Manufacturer-provided drivers were not used in their entirety because they were not optimized for speed. During this process, many timing issues had to be resolved, culminating in a tightly integrated hardware and software solution.
Since the final SES architecture integrated the SCSI with the VXI controller hardware, all SCSI command parsing and interpretation had to be woven into the real-time VXI command processor. This posed significant challenges, both in terms of performance and lack of support for SCSI target development, because most SCSI tools are oriented toward use of SCSI as a master.
To optimize manufacturing and maintenance costs, the packaging design of the system needed careful consideration. Due to the high channel count, the need for low noise and crosstalk, maintenance considerations, and overall customer requirements, conventional design approaches proved inadequate. For example, since the UUT is a very expensive spacecraft component, protective networks were required for all of the channels.
Specific channels required termination networks and other treatment prior to being routed to SES instrument resources. As a result, a standardized module was designed to accommodate signal termination requirements while correctly mapping I/O signal nets to the instruments. Then, a common harness design could be used, allowing any module to be easily removed for repair or replacement. The use of VXI Technology’s VMIP family of products reduced the system by two to three VXIbus cardcages, eliminating the need for additional external cabling and cost.
System Software
The SES software was written in C/C++ and provided real-time operation, a menu-based GUI system, self-test, and comprehensive, full wraparound self-test functions. During operation, the SES is continually monitored for status, and detected failure modes are indicated immediately.
To support comprehensive self-test, a self-test adapter was built into the SES rack. When this is attached to the SES I/O and the full self-test is invoked from the SES program menu, all SES I/O is tested and validated.
One feature of the VXI Technology’s programmable resistance module was a built-in switched bus. This significantly supported self-test by saving considerable switching resources and associated cabling. By paralleling this bus across all of the channels, a DMM can access all of the programmable resistors without any external switching.
Testing and Validation Challenges
One challenge in test and validation was to simulate the system that interfaces with the SES. This system, the MATE-3, produces a real-time SCSI command stream that represents the simulation data that the SES must generate.
This simulation data is the result of mathematical models of the space station computed in real time by the MATE-3. Since this system was unavailable during SES development, a work-around solution was required. This was comprised of a SCSI command simulator programmed to mimic the host output commands of the MATE-3 while supporting validation and acceptance test processes.
Conclusion
Product availability was evaluated for VME, PC, and VXI platforms. VXI was selected because large channel counts were needed, and products that provided the accuracies, isolation, and communications speeds needed for real-time simulation were available from several manufacturers. The PCI platform would not easily integrate such large channel counts, and VME did not offer any high-performance programmable resistors or high-density, isolated, voltage/current sources with the accuracies needed.
The VXIbus platform, not typically known for real-time simulation, became a powerful tool in this application. Several SES testers were built and delivered in a very short time frame; and today, these simulators are fielded in several locations, including Cape Canaveral.
About the Authors
William Elder is a founder and president of Maxsys Technologies. He has more than 25 years of engineering and management experience, has lectured on instrument design, and has authored numerous technical papers. Mr. Elder is an honors graduate of the University of California with a B.S.E.E. degree. Maxsys Technologies, 19211 E. Deere Ave., Suite 100, Santa Ana, CA 92705, (714) 833-8834.
Paul Dhillon is executive vice president of VXI Technology. He has been involved in VXI test and measurement since the introduction of the VXI standard in 1987. Mr. Dhillon earned a bachelor’s degree from Kingston University, U.K. VXI Technology, 17912 Mitchell, Irvine, CA 92614, (714) 955-3041.
Copyright 1997 Nelson Publishing Inc.
December 1997