The publications outlined below describe some of the solutions that Ingenicomm's engineers have developed to address our customers' unique mission requirements. To request a copy of a particular publication, please email info@ingenicomm.net.
The National Oceanic and Atmospheric Administration (NOAA) Jason Ground System (NJGS) is a consolidated next-generation ground system that will support the simultaneous operation of the OSTM/Jason-2 and Jason-3 ocean surface topography missions. The NJGS will consist of several independent subsystems for spacecraft command and control, telemetry processing, and data archiving and distribution.
The existing NOAA Jason-2 Ground System (J2GS) was designed around the concept of subsystem “strings”, in which two complete sets of subsystems acted in primary and standby roles. For the NJGS, this concept is replaced with subsystem-level redundancy, in which two or more instances of each subsystem independently provide redundant capabilities.
This paper discusses the design elements involved in the provision of a ground system architecture providing redundancy at the subsystem level. The paper focuses on the interaction between primary and standby subsystems and the mechanism through which failover capabilities are provided across the ground system.
The National Aeronautics and Space Administration (NASA) Space Network (SN) consists of a Space Segment, composed of the Tracking and Data Relay Satellite (TDRS) fleet, and a Ground Segment that includes the White Sands Ground Terminal (WSGT), Second TDRS Ground Terminal (STGT) and the Guam Remote Ground Terminal (GRGT). Collectively, the SN Ground Segment is commonly referred to as the White Sands Complex (WSC). Traditional methods of latency and performance measurement across the component links of network have relied on the use of simplified test patterns and basic data formats that are often specific to the instruments providing the measurements. These tests do not often correlate to the operational data normally transferred through the network.
This paper discusses an alternative approach to performance measurement within the Space Network. By embedding and extracting performance metrics directly within simulated data sets that closely resemble operational traffic, performance measurement can be combined with link verification and validation to provide a single, comprehensive set of test and measurement activities.
The National Oceanic and Atmospheric Administration (NOAA) Jason Ground System (NJGS) is a consolidated next-generation ground system that will support the simultaneous operation of the OSTM/Jason-2 and Jason-3 ocean surface topography missions. The NJGS will consist of several independent subsystems for spacecraft command and control, telemetry processing, and data archiving and distribution.
To provide high availability and multi-level resilience against equipment failures, the NJGS will employ a subsystem-level redundancy scheme, in which two or more independent instances of each subsystem provide fully redundant functionality, for the various subsystems within the NJGS. The use of this scheme requires the implementation of several safeguards to ensure that a subsystem failure and the resulting system recovery operations do not result in any loss of operational data.
This paper discusses the key elements of the subsystem-level redundancy scheme and the mechanism through which the NJGS recovers from a subsystem failure. The paper focuses on the potential failure scenarios present in the recovery process, and the technical and procedural safeguards necessary to ensure data integrity across subsystem instances.
The National Oceanic and Atmospheric Administration (NOAA) Jason Ground System (NJGS) is a consolidated next-generation ground system that will support the simultaneous operation of the OSTM/Jason-2 and Jason-3 ocean surface topography missions. The NJGS will consist of several independent subsystems for spacecraft command and control, telemetry processing, and data archiving and distribution.
To provide the additional resources necessary for supporting both missions on a single ground system, NOAA is integrating the communications infrastructure located at its remote station in Barrow, AK, with the communications infrastructure of the primary NOAA Command and Data Acquisition Station (CDAS) at Fairbanks, AK. Together, the two sites will provide a consolidated interface, allowing the NJGS to use the combined resources of both sites as a single integrated earth terminal.
This paper discusses the delivery of mission data between the two sites and through a consolidated interface to the NJGS. The paper focuses on the telemetry-over-IP (TMoIP) gateway infrastructure that provides transport capabilities across the site boundaries, as well as the mechanism through which the sites present a common interface to the other components of the ground system.
The National Oceanic and Atmospheric Administration (NOAA) Jason Ground System (NJGS) is a consolidated next-generation ground system that will support the simultaneous operation of the OSTM/Jason-2 and Jason-3 ocean surface topography missions. The NJGS will consist of several independent subsystems for spacecraft command and control, telemetry processing, and data archiving and distribution, and will provide the other Jason-3 mission partners — the National Aeronautics and Space Administration (NASA), the Centre National d'Etudes Spaciales (CNES), and the European Organisation for the Exploitation of Meteorological Satellites (EUMETSAT) — with access to mission operational data and science products.
To assure high availability and multi-level resilience against equipment failures, the NJGS will employ a subsystem redundancy scheme in which two or more independent instances of each subsystem provide fully redundant functionality. The redundancy mechanism selected for the NJGS is an enhancement of the one used in NOAA's existing Jason-2 Ground System (J2GS); the two approaches differ in that the J2GS provides redundancy among parallel sets of subsystems, whereas the NJGS will allow individual subsystems to be independently replaced.
The J2GS subsystem redundancy implementation imposed a number of limitations on the mission partners. Chief among these was the non-transparency of the subsystem replacement process; following any subsystem failure, all mission partners with access to the failed subsystem would be required to reconfigure their communications interfaces to access its replacement. The need for this explicit change in configuration imposed significant overhead on subsystem failure recovery, since any replacement required a coordinated international effort to complete.
The NJGS subsystem redundancy mechanism removes this constraint on partner interoperability by implementing subsystem replacement in a transparent manner. Multiple instances of externally-accessible NJGS subsystems provide common interfaces to the mission partners, and the integrity of these interfaces is maintained during the change-over from a failed subsystem to its standby counterpart. This method allows subsystem replacement to be completed without requiring any configuration changes on the part of the external mission partners.
This presentation discusses the key elements of the subsystem-level redundancy scheme and the mechanism through which the NJGS recovers from a subsystem failure. The presentation focuses on the implementation of common external interfaces for NJGS subsystems accessed by external partners, and the method by which these interfaces are preserved during subsystem failure recovery.
Space Link Extension (SLE) is a set of recommended standards for mission cross support developed by the Consultative Committee for Space Data Systems (CCSDS). The SLE recommendations define protocols for extending the space link from ground terminals to other facilities deeper within a ground network, allowing distributed access to space link telecommand and telemetry services. The SLE protocols are widely used to provide cross support between sites, programs, and agencies.
In traditional SLE deployments, individual service instances have been manually provisioned well in advance of the commencement of cross support for a particular mission, and hardware and software resources have been allocated to those service instances at the time of provisioning. While valid, this approach requires that dedicated resources be provided for each mission and service instance, and limits an SLE provider’s ability to reallocate resources in real time based on system availability or other factors.
This paper discusses an alternative approach to SLE service provisioning, in which individual service instances are assigned resources from a common resource pool at the time that each service instance is initialized. The paper addresses the key design elements and technical tradeoffs involved in this approach, and discusses the potential benefits with regard to load balancing, equipment reuse, and resiliency against system failure.
Space Link Extension (SLE) is a set of recommended standards for mission cross support developed by the Consultative Committee for Space Data Systems (CCSDS). The SLE recommendations define protocols for extending the space link from ground terminals to other facilities deeper within a ground network, allowing distributed access to space link telecommand and telemetry services. The SLE protocols are widely used to provide cross support between sites, programs, and agencies.
Traditional SLE protocol implementations have been limited in their ability to support high data rates and large numbers of concurrent service instances. Such limited solutions were sufficient to support the needs of spacecraft health and status or older, low-rate science data. More recent missions, however, have required significantly increased data rates on both uplink and downlink paths, necessitating a new approach to SLE implementation.
This paper discusses the design principles involved in implementing the SLE protocols in support of high channel and aggregate mission data rates, with particular focus on the tradeoffs necessary to provide SLE link capability at sustained single-channel rates above 1 Gigabit per second. The paper addresses significant performance bottlenecks in the conventional SLE protocol stack and proposes potential mitigation strategies for them.
XML Telemetric and Command Exchange (XTCE) is a set of recommendations and standard developed by the Object Management Group (OMG) and the Consultative Committee on Space Data Systems (CCSDS). These standards define an XML information model that describes the format, encoding, and data types of telemetry and command data for a system, subsystem or instrument on a satellite or space-based platform.
Custom hardware and software systems are often needed to process telemetry and command information for a new satellite platform. This approach results in elevated mission costs for specialized equipment, software development, and maintenance, and increases the amount of testing needed to manage mission risk. Cost and risk are further increased when integrating satellite platforms from multiple vendors for mission proof-of-concept, deployment delay reduction, or mission redundancy objectives.
This paper discusses an alternative approach to implementing telemetry and command processing, which uses XTCE to describe the telemetry and command information models for each platform. The paper discusses the use of XTCE guidelines to promote reusability of ground system components, as well as key design elements for an XTCE implementation used to process telemetry and command information for a satellite constellation with element members from multiple satellite vendors.
The NASA Space Network (SN), which consists of the geosynchronous Tracking and Data Relay Satellite (TDRS) constellation and its associated ground elements in White Sands and Guam, is a critical national space asset that provides near-continuous, high-bandwidth telemetry, command, and communications services for numerous on-orbit spacecraft and launch vehicles.
The successful operation of the Space Network depends on interoperability between its ground elements and the Mission Operations Center (MOC) of each spacecraft supported by the TDRS constellation. Ensuring this interoperability in the face of new missions, evolving communications needs, and ground system changes and upgrades requires regular verification of every MOC interface. To reduce the cost and complexity of such verification activities, NASA commissioned the development of the External Bearer Interface Test Set (XBIT), which allows MOC interface verification to be performed using a test automation framework.
This paper considers the implementation of the XBIT as a case study of automated ground segment interface verification and validation. The paper discusses the process through which automated test scenarios for MOC interface verification can be defined, as well as the design, implementation, and utilization of the XBIT test automation software and supporting infrastructure.