[american institute of aeronautics and astronautics 20th aiaa international communication satellite...

1 American Institute of Aeronautics and Astronautics

SPACE-BASED INSTRUMENT CONTROL USING INTERNET TECHNOLOGIES

Copyright © 2002 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.

Eric J. Knoblock* Vijay K. Konangi* Marc A. Seibert** Kul B. Bhasin**

*Department of Electrical and Computer Engineering

Cleveland State University Cleveland, Ohio 44115

**NASA Glenn Research Center

21000 Brookpark Road Cleveland, Ohio 44135

ABSTRACT

The design and development of a Local Area Network consisting of instruments and sensors for the emulation of a space-based system is presented. The instrument LAN and associated hardware and software can be used to emulate the onboard LAN of a typical space-based system such as a spacecraft or a Mars rover. In either case, the LAN, which consists of both fixed and mobile sensors, is designed using Controller Area Network technology as the bus architecture. Using a standard Internet web browser, the state of the sensors on the LAN can be observed and actuators can be controlled over an IP-based network. Upon completion of a single-node instrument LAN, this research will be extended to emulate a cluster or formation of distributed spacecraft each with its own onboard instruments and sensors. This allows the evaluation of space-based systems that utilize commercially available hardware and software as well as standard Internet technologies.

INTRODUCTION Objectives and Goals The goal of this research is to emulate a space-based system by which onboard sensors, instruments and actuators can be observed and controlled over an IP-based network. This is accomplished by the development of a Local Area Network (LAN) consisting of fixed and mobile sensors and instruments connected by both wire and wireless protocols using Controller Area Network (CAN) technology as the bus architecture.1 The processor for this system connects to an IP backbone network, which connects to the Internet. As a result, authorized users or operators can perform command of onboard systems and actuators as well as obtain the state of the sensors on the LAN through a standard web interface. The development of an IP-enabled system with an onboard network of sensors and instruments enables the emulation of a variety of space-based and terrestrial-based scenarios. Primarily, the system is used to emulate a futuristic spacecraft, which incorporates IP and standard Internet technologies in its communications infrastructure. For the emulation of a

spacecraft, the instrument LAN represents the network of sensors, instruments, and actuators used to obtain scientific data as well as performing specific tasks or duties in the space environment. In addition to a spacecraft scenario, the system could be used to emulate other space-based scenarios such as sensors on a Mars rover, where multiple rovers could communicate with each other as well as with a Mars orbiter. The system can also be used to emulate a variety of terrestrial-based systems, which could be modified to suit experiments in NASA’s Earth Science and Aerospace Enterprises. For example, multiple roving sensors could be coordinated for aerospace engine and vehicle inspections, and small satellite experiments for earth observation could be developed faster and cheaper by using this common architecture. Technological Benefits The incorporation of IP and Internet technologies into NASA’s space-based communications architecture allows NASA missions to transition from a vertically organized communications infrastructure to a horizontally organized infrastructure.2 In a vertically organized infrastructure, the communication assets are designed to fulfill the requirements of a specific mission, and any change in the mission would result in a necessary change in the communication assets. In a horizontally organized infrastructure, however, the communications assets are designed to fulfill the requirements of almost any mission, and therefore, little to no change in the assets is required. To make the transition from a vertically organized to a horizontally organized communications infrastructure, NASA missions can take advantage of Internet technologies since the Internet is horizontal in structure due to its flexibility and diverse set of open-interoperability standards.3 In addition to making a transition from vertically organized to horizontally organized communications infrastructure, the incorporation of IP and Internet technologies into NASA missions provides a variety of other benefits. First, the incorporation of IP allows the infusion of commercially developed technology, and as a result, NASA can take advantage of the enormous

20th AIAA International Communication Satellite Systems Conference and Exhibit12-15 May 2002, Montreal, Quebec Canada

AIAA 2002-1959

Copyright © 2002 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.


amount of research and development invested annually in the development of commercial Internet technology.4

Also, the incorporation of IP into NASA’s space communication systems facilitates on-demand access to the space system by a terrestrial user, since a standard Internet web browser could be used as the user interface. Moreover, the use of IP in the space segment facilitates the manner in which commands and data can be exchanged on the network since Internet technologies allow the seamless interoperability of heterogeneous systems and architectures. This project embeds commercially available network hardware and software as well as standard Internet protocols to emulate a typical space-mission scenario. In an attempt to emulate a space system, this project has included parameters that a typical mission would include such as high-bandwidth data link involving large volumes of return data. Additionally, command and control must be included in a space-mission scenario; therefore, the capability to send commands and perform control of a robotic vehicle is included in the project. As a result, we can test the capacity of COTS network hardware and software for a typical space-mission scenario.

SINGLE-NODE INSTRUMENT LAN Bus Architectures The incorporation of IP into the onboard processor of a spacecraft could potentially allow the seamless interoperability and connectivity between all spacecraft subsystems and instruments as well as other spacecraft in a cluster or formation. Whereas typical modern spacecraft utilize a serial bus architecture based on the military standard 1553 or 1773 architectures, futuristic spacecraft could potentially incorporate industry standard bus architectures such as IEEE 1394, Ethernet, or CAN.5,6 Of these three industry standard architectures, CAN was used for this stage of the research, although future work may incorporate IEEE 1394 as the bus architecture. CAN was used for this preliminary phase of the research since the technology was readily available, which facilitates the rapid development of the initial architectural elements of the overall system. Future work will attempt to emulate the space-based system in a more realistic manner by incorporating a higher-bandwidth bus architecture more suitable for future space missions, such as IEEE 1394. Spacewire is another potential candidate; although, it is currently not a standardized architecture, and lacks commercial availability. System Overview The development of an IP-accessible Local Area Network consisting of fixed and mobile sensors will be accomplished in two stages. First, a single-node or

single-system instrument LAN will be developed to emulate a space-based system such as a spacecraft. Upon completion of the single-node system, the project will be extended to emulate a collection of space-based systems such as a cluster or formation of spacecraft. The single-node system is outlined in figure 1.

Figure 1-Single-Node Instrument LAN

The system shown in figure 1 consists of a hardwired CAN bus with three nodes. One CAN node is a notebook PC which is used to emulate the onboard processor of a space-based system, and also functions as an interface between the instrument LAN and the IP network. The PC allows the terrestrial user to obtain access to the state of the sensors on the LAN and to perform command and control of the robotic vehicle. The PC interfaces with the CAN bus through the RS-232 serial port. Another CAN node is a battery charging station which, in addition to allowing the robotic vehicle to recharge its battery, provides the instrument LAN with information concerning the charging status of the vehicle. The charging status includes information such as whether the robot is in the station, whether the robot is charging its battery, and the current state of the charging cycle. The last CAN node is an RF transceiver, which functions as an interface between the bus and the robotic vehicle. The RF transceiver operates in the unlicensed ISM band (2.4 GHz) and receives information concerning the operational status of the robotic vehicle. Additionally, the RF transceiver broadcasts an echo of CAN bus activity, which effectively allows the transfer of command and control information from the bus to the robot. The robotic vehicle is equipped with a chassis-mounted video camera, which transmits a video signal over a 900 MHz wireless link. The video receiver demodulates the signal and passes the video information to a video capture device. The capture device, which can interface with the PC through either the USB port or the PCMCIA card slot, digitizes the video signal and passes the information to the PC. The PC can utilize either proprietary or custom-designed


Java software to enable the streaming of video to the user over the network. Single-Node System Details The details of the hardware and software used in the single-node system are shown graphically in figure 2, where the PC and the CAN bus represent the space-based system and the web browser represents the terrestrial-based system, and both systems are linked through an IP-based network. The diagram illustrates four software subsystems within the onboard processor of the space-based system. Since a typical spacecraft possesses limited onboard resources, this configuration may only prove useful for near-earth spacecraft or space systems which utilize high-bandwidth and low-delay communication links. However, for the operation of spacecraft or space-based systems at greater distances, such as Mars and beyond, the limited onboard resources and high-latency communication links may require the terrestrial-based user to access the space-based system through a ground-based proxy server. Consequently, some of the onboard functionality may need to be transferred from the space system to the proxy, and the terrestrial user could then access the space-based system through the proxy rather than directly to the spacecraft. Since the research presented in this paper is a preliminary demonstration of IP-based instrument control for a space-based system, the deep-space configuration will be investigated in future phases of this project.

Figure 2-Single-Node System Details

The space system and the terrestrial system follow the client-server paradigm, where the space system functions as the server and the terrestrial system is the client. The client-server interaction begins when a user attempts to obtain access to a web page residing on the space system web server. The server responds by transferring the requested HTML document as well as the Java applet code to the web browser on the terrestrial system. The web browser displays the HTML document and loads the Java Virtual Machine

(JVM) which is required in order to execute the requested Java applets. For this system, the web page contains three Java applets which begin execution upon loading of the JVM and attempt to establish communication with the data communication software residing on the space system. The data communication software on the space system is comprised of four subsystems: a command and control subsystem, data server, command server, and video software. The command and control subsystem provides an interface between the command and data servers and the instrument LAN. The command server receives command information from the command applet, which is executing on the terrestrial system web browser. The command server forwards the command information to the command and control subsystem which forwards the information to the instrument bus through the serial port. The robotic vehicle receives the command information from the 2.4 GHz transceiver which effectively provides a wireless echo of the CAN bus activity. The data server receives sensor data from the instrument bus and forwards that data over the IP network to the data applet running on the terrestrial system web browser. The data applet displays the sensor values in graphical format. The video software receives video information from the video capture device and streams the video to the video applet, which displays the video on the web browser.

Figure 3-Single-Node System Webpage

A screen capture of the web interface, which allows a user to obtain sensor data and perform control of the robotic vehicle, is shown in figure 3. As mentioned earlier, the web interface consists of three Java applets: one for the display of video, one for the exchange of telemetry data, and one for the sending of control directives to the robotic vehicle. The video applet displays video from the robotic vehicle. The command applet accepts command information from the user, which in this case, consists of directional commands to the robot in order to control its position, and the data


applet displays sensor data such as the distance to an obstacle, or the direction to the charging station.

Single-Node System Conclusions This research attempts to develop a technology roadmap that enables future NASA missions to incorporate commercially available Internet technologies into its space-ground communications infrastructure. The incorporation of Internet technologies allows NASA missions to transition from a vertically organized to a horizontally organized communications infrastructure since the Internet is horizontal in structure. The development of a Local Area Network consisting of fixed and mobile sensors that can be observed and controlled over an IP network is demonstrated by this research. The system can be used to emulate a space-based system such as a satellite or a terrestrial-based system such as a network of roving sensors designed for aerospace engine inspection. The results of this research demonstrate the ability to observe the state of sensors on an instrument LAN as well as the ability to perform command and control of a robotic vehicle using standard Internet technologies.

DISTRIBUTED SPACECRAFT COMMUNICATIONS

Overview The concept of a distributed spacecraft platform involves the coordinated operation of multiple space assets whose collective faculties result in a system capable of complex multi-sensor tasks while exhibiting a reduction in cost and an enhancement in overall system robustness, scalability and flexibility.7 Distributed spacecraft systems are advantageous over single-satellite counterparts in that an autonomous network of spatially disbursed spacecraft can perform functions beyond the capabilities of a single-spacecraft system such as multi-point observation, co-observation, and enhanced deep space interferometry.8 The array of recently conceived scientific missions that rely on multi-point observation and distributed functionality have provided the motivation for the development of distributed spacecraft systems. There exist two subsets of distributed spacecraft systems: clusters or constellations of spacecraft and formation flying systems. A cluster or constellation consists of two or more spacecraft operating in a coordinated manner to achieve a scientific mission goal. A formation flying system also consists of two or more spacecraft operating to achieve a scientific mission goal; however, formation flying systems require the preservation of the relative distances and 3D spatial

relationships between spacecraft throughout the duration of the mission.9

Figure 4-Formation Flying Satellite System

As mentioned, distributed spacecraft systems exhibit enhanced mission capabilities with a reduction in cost and an enhancement in overall system robustness, scalability, and flexibility. Whereas a distributed spacecraft system can accomplish complex multi-sensor missions with increased capability, a single satellite system may exhibit a greater susceptibility to failure and prove too complex and costly to implement.8,10

Distributed satellite systems also exhibit the ability to perform higher resolution imagery and interferometry with an improvement in system robustness and fault-tolerance.11 Figure 4 illustrates a typical formation flying satellite system. System Requirements A distributed spacecraft system must exhibit flexibility, scalability, robustness, and demonstrate a gradual and graceful loss of capability in the presence of system faults. Additionally, clusters or formations of spacecraft must be capable of some level of onboard autonomy and utilize an interspacecraft communication architecture that supports the necessary exchange of science, command, telemetry, and navigation data in order to allow the system to perform in a unified and coordinated manner. Distributed spacecraft systems must maintain formation geometry and orientation to within specified tolerance levels, perform fault detection, isolation and resolution (FDIR), and plan and schedule tasks and activities in order to accomplish mission goals.10 In an effort to maximize efficiency and cost effectiveness, the associated ground system must interact with the cluster or formation as if it were a unified system, rather than a collection of individual space systems. Interspacecraft Communication Requirements The interspacecraft communications system is the underlying infrastructure upon which the system


exchanges command, control, navigation, telemetry, and science data between other spacecraft within the cluster or formation or the associated terrestrial system. This exchange of information is necessary for the cluster or formation to maintain formation geometry, to coordinate tasks and duties, to recover from node failure, to adapt to node entry, and to relay scientific, telemetry or command data to other spacecraft, clusters, or terrestrial sites. The information exchanged between space systems may include spacecraft and instrument telemetry data, which are characterized by relatively low data rates and low volumes of data. Additionally, spacecraft instrument data, which is characterized by higher data rates and volumes, may need to be transferred from spacecraft to spacecraft or terrestrial system. Finally, interspacecraft range and range rate, operational status messages, and instrument calibration information can be exchanged as well. In all cases, the data rate requirements and link utilization will depend on the specifics of the mission requirements.9 The requirements for a distributed spacecraft system differ from that of a single spacecraft system in various ways. For example, the overall system capacity must be capable of supporting a scalable number of spacecraft since nodes may enter or egress the cluster depending on mission goals. Further, the system must be capable of handling self-jamming issues and other forms of radio frequency (RF) interference while providing full-duplex communication with multiple spacecraft within the cluster or formation. Lastly, the system must utilize components and electronics suitable for prolonged use in the space environment. To support the interspacecraft communications requirements for distributed spacecraft systems, three canonical architectures can be devised.7 The centralized approach provides simplicity but lacks scalability in that the entry of additional spacecraft would place an increasing load on the central ship. Also, the centralized approach lacks robustness because a fault in the central spacecraft could cause a mission failure, unless the system is designed to allow another spacecraft to assume the duties of the central spacecraft. The fully-distributed approach provides an effective method for exchanging data between spacecraft in the cluster or formation, although the system lacks scalability as additional spacecraft will require an increasing number of crosslinks. The hierarchically-distributed approach provides an effective method of exchanging data between spacecraft without sacrificing scalability and robustness. Protocol Issues One of the necessary goals to achieve an autonomous cluster or formation of distributed spacecraft is to

increase the onboard processing capabilities of each individual spacecraft and to implement an effective crosslink communication architecture to allow the timely and efficient exchange of commands and data between nodes in the cluster or formation. This increase in onboard functionality and the development of an effective crosslink communication architecture lead to the utilization of a layered protocol architecture similar to the Open Systems Interconnect (OSI) model. A range of protocols and protocol architectures may be appropriate for distributed spacecraft missions. The most appropriate choice of protocol or protocol architecture depends on the mission specifications and requirements. Depending on the mission, some distributed spacecraft systems may require the ability to communicate with some or all of the spacecraft in the cluster. This can be accomplished with broadcast or multicast protocols. Further, some information exchanged between nodes in the cluster or formation may require guaranteed delivery. Also, since spacecraft may enter or leave the cluster or formation, some form of ad-hoc routing may be required to allow member spacecraft to route data to other member spacecraft. The following paragraphs provide an overview of various protocol architectures and their potential applicability to distributed spacecraft missions. Upper Layer Protocols As mentioned, the individual mission requirements will drive the need for particular protocols to satisfy those requirements. A particularly attractive option is the Internet Protocol (IP) suite, which provides a mature and open layered protocol architecture with a multitude of commercial support.9 Also, the IP suite allows seamless interoperability between heterogeneous systems and architectures, and its widespread use allows the reduction of ground system implementation costs. On the other hand, the Transmission Control Protocol (TCP) from the IP suite is notoriously sensitive to time delays, and its flow control algorithms assume that all packet loss is due to congestion rather than corruption, the latter of which is more common in the space environment. One potential alternative to TCP is the use of the User Datagram Protocol (UDP) as the transport protocol. UDP is a connectionless protocol which does not implement any form of flow and congestion control and consequently may prove more efficient in the space environment. If UDP is used, end-to-end flow and congestion control have to be incorporated into the application. The Consultative Committee for Space Data Systems (CCSDS) is an international organization of space agencies and industrial associates interested in developing standard data handling techniques to support space research, including space science


and applications.12 The advantages of using CCSDS protocols are their maturity and interoperability with other foreign space and ground networks.9 Whereas protocols within the IP suite, such as TCP, may prove inefficient in the space environment, protocols developed by CCSDS are designed specifically for use in space. The Space Communications Protocol Suite (SCPS) is a layered protocol architecture similar to the IP suite but is designed to operate more efficiently in the space environment. Lower Layer Protocols As with the higher layer protocols, the choice of appropriate lower layer protocols for a space mission depends on the specifics of the mission requirements. One potential candidate for a lower layer protocol for a distributed spacecraft mission is X.25 over LAP-B, which offers wide commercial support and many years of engineering knowledge.13 The disadvantage of using X.25 over LAP-B is that these protocols were designed for terrestrial communications networks and therefore cannot easily compensate for the high delays, high error-rates and intermittency of contact associated with space links. The IEEE 802.11 wireless LAN protocol is another potential lower layer protocol. The advantages of this protocol are its wide commercial support, IP interoperability, and high data rates (up to 11 Mbps for 802.11b and 54 Mbps for 802.11a). The disadvantages of IEEE 802.11 are its limited signal range and lack of space qualification. Incorporating a directional antenna and increasing the transmitter output power may increase signal range, but the increased propagation delay associated with the longer signal path could disrupt the timing mechanisms of the medium access control (MAC) protocol resulting in decreased throughput. The CCSDS Proximity-1 protocol is an ideal protocol for short-range interspacecraft links and possesses the ability to encapsulate CCSDS frames, which promotes interoperability with other space and ground systems.13

Conversely, the Proximity-1 protocol is not yet a standardized architecture and lacks commercial support. Companies such as NEC and Philips have devised a wireless form of the IEEE 1394 (or Firewire) standard, but currently wireless 1394 has not been standardized. Also, wireless 1394 lacks space qualification and preliminary implementations have proven to be extremely range-limited (on the order of 10 meters). On the other hand, utilizing wireless IEEE 1394 as the interspacecraft communication protocol would allow relatively high data rates (approximately 100 Mbps) and seamless interoperability between a spacecraft’s

onboard-wired 1394 network and the onboard 1394 networks of other member spacecraft within the cluster or formation. This would greatly facilitate the exchange of information between spacecraft subsystems and consequently enhance overall mission performance. Physical Layer The development of a cluster or formation of spacecraft with distributed functionality poses some unique physical layer complexities not apparent in a single-spacecraft mission. Solutions to issues such as multiple-access methods, directional versus omni directional signal propagation, and transmitter power adaptation to reduce signal interference all must be investigated within the context of mission requirements. Another physical layer issue to investigate is the use of optical communication systems versus the use of RF communication systems. Whereas the use of RF communication offers relatively lower data rates for a given transmitter power and a higher probability of intercept, RF systems are widely used in most space systems, and an RF system provides a less complex mechanism for acquisition and tracking. Optical communication systems, conversely, offer higher data rates for a given output power and a lower probability of intercept, but an optical system requires a more complex mechanism of acquisition and tracking and may introduce additional delays in converting optical signals to electrical signals. Also, the use of optical systems in space is a relatively new concept.13 Multi-Node System Overview The general overview of the next stage of this research is illustrated in figure 5 where all systems together can be used to emulate a cluster or formation of spacecraft, each with its own hardware, software, and instrumentation. All spacecraft emulators will be linked through an inter-connection network which allows the exchange of scientific data, navigation data, as well as command and control information in order to perform specific tasks. As in the single-system setup, the space-based system incorporates IP into its communications architecture to facilitate interoperability with other space systems as well as the terrestrial segment. The multi-node system may also link to an ad-hoc network of mobile sensor platforms. This ad-hoc network can emulate a collection of Mars rovers.


Figure 5-Multi-Node System Overview

CONCLUSIONS The design and development of a Local Area Network consisting of instruments and sensors for the emulation of a space-based system was presented. The instrument LAN and associated hardware and software can be used to emulate the onboard LAN of a typical space-based system such as a spacecraft or a Mars rover. In either case, the LAN, which consists of both fixed and mobile sensors, was designed using Controller Area Network technology as the bus architecture. Using a standard Internet web browser, the state of the sensors on the LAN can be observed and actuators can be controlled over an IP-based network. This research will be extended to emulate a cluster or formation of distributed spacecraft each with its own onboard instruments and sensors. The requirements for interspacecraft communications and the associated issues with the upper and lower layer protocols were identified. An architecture for a multi-node system, which enables the evaluation of space-based systems that utilize commercially available hardware and software as well as standard Internet technologies, was presented.

ACKNOWLEDGEMENTS This research was supported by the Space Communications in CICT Program at NASA Glenn Research Center. Thanks to Mr. Jeffrey Hayden for his valuable insights, and to Mr. Michael Krasowski and Mr. Lawrence Greer from the Optical Instrumentation Branch of the NASA Glenn Research Center for their development of the instrument bus and robotic vehicle. Dr. Thomas Wallett helped with various aspects of the single-node system.

REFERENCES [1] Controller Area Network standard, ISO 11898 [2] J. L. Hayden, “Spacecraft/Ground Architectures using Internet Protocols to Facilitate Autonomous

Mission Operations,” Proceedings IEEE Aerospace Conference, 2000. [3] K.B. Bhasin and J. L. Hayden, “Space Internet Architectures and Technologies for NASA Enterprises,” Proceedings IEEE Aerospace Conference, Vol. 2, pp. 931-942, 2001. [4] E. Criscuolo, K. Hogie, and R. Parise, “Transport Protocols and Applications for Internet Use in Space,” Proceedings IEEE Aerospace Conference, Vol. 2, pp. 951-962, 2001. [5] K. Hogie, E. Criscuolo, and R. Parise, “Link and Routing Issues for Internet Protocols in Space,” Proceedings IEEE Aerospace Conference, Vol.2, pp. 963-976, 2001. [6] E.J. Knoblock, V.K. Konangi, and K.B. Bhasin, “Local Area Network for Space-based Instrument Control,” Proceedings IEEE Aerospace Conference, 2002. [7] P. Stadter, W. Devereux, R. Denissen, D. Duven, M.Asher, “Interspacecraft Communications for Formation Flying,” NASA/ESTO Study Report, January 8, 1999. [8] P. Stadter, T Kusterer, R. DeBolt, P. Clark, A. Chacos, J. Bristow, J. Leitner, “Navigation Validation Using the Distributed Spacecraft Modeling and Simulation Testbed,” Proceedings IEEE Aerospace Conference, Vol. 2, pp. 597-608, 2001. [9] S. Talabac, “Intersatellite Communications: Considerations for Distributed Observing Systems and Mission Operations,” 4th International Symposium: Reducing the Cost of Spacecraft Ground Systems and Operations, 7th Annual Workshop: Reducing the Cost of Space Operations, Johns Hopkins University, April 24-27, 2001. [10] P. Zetocha and M. Brito, “Development of a Testbed for Distributed Satellite Command and Control,” Proceedings IEEE Aerospace Conference, Vol. 2, pp. 609-614, 2001. [11] J. Leitner, “A Hardware-in-the-Loop Testbed for Spacecraft Formation Flying Applications,” Proceedings IEEE Aerospace Conference, Vol. 2, pp. 615-620, 2001. [12] http://www.ccsds.org [13] K. Kusza, M. Paluszek, “Intersatellite Links: Lower Layer Protocols for Autonomous


Constellations,” http://ipinspace.gsfc.nasa.gov, November 11, 2000.

[american institute of aeronautics and astronautics 20th aiaa international communication satellite...

Documents