Architectures for Fleet Management B. L. Kizzort Harris Corporation, Melbourne, Florida, USA. Abstract With the increasing reliance on space systems for communications, the number of multi-satellite, multimission operators, in both the government and commercial sectors, is also increasing. To prevent the operations and maintenance costs from increasing linearly, or worse, with the number of satellites, operators are attempting to consolidate operations and maintenance across the satellite fleet. Different satellite generations and buses complicate this fleet view, and different ground control systems have differing capabilities in a fleet management environment. This paper examines the architectures of existing satellite fleet control centers, comparing capability, scalability, and maintainability. The paper then takes the lessons learned forward to propose architectural requirements for a future fleet management system and related satellite industry standards. Introduction Satellite fleet management is the control of multiple spacecraft from a single control system. Typically in the past, each satellite has been monitored and controlled by a dedicated control system. For multisatellite operators, this results in a proliferation of satellite control systems (SCS s). If the satellites are acquired over time or are acquired from different vendors, the differences in the SCS s increase the complexity of operations staffing, training, and ground system sustainment. There are two types of satellite fleets, multi-mission and multi-satellite/single-mission, although this differentiation can blur as the fleet ages. Commercial examples of multi-satellite/single-mission fleets are the Iridium and the Globalstar systems. Government or multi-government examples are the Global Positioning System (GPS) and the planned Galileo navigational system. Initially, all of the satellites in the multi-satellite fleet are similar, since they use the same satellite bus and payload. However, due to software uploads or satellite replacement, the satellites in these fleets will also tend to vary over time. The GPS system is nearing launch of its fourth generation of satellites, built by three different vendors, requiring the ground control system to accommodate significant variation in the satellites. The multimission fleet is exemplified by the National Aeronautics and Space Administration (NASA), National Oceanic and Atmospheric Administration (NOAA), and European Space Agency (ESA) earth-observing Montreal, Canada May 17 21 2004 1 of 8
satellites. Many telecommunications organizations are also operating different satellites with different payloads from one or more satellite vendors. Benefits from a Fleet Perspective Fleet management can be accomplished using multiple SCS s hosted in the same control center, but there are drawbacks to this approach. Variation in the SCS s and the satellites increases training and staffing requirements and reduces the flexibility of staffing. Computer equipment typically has a much shorter lifetime than a satellite mission, so the operations staff may need to be retrained on new ground systems as upgrades are completed. Controlling a fleet of satellites from a single unified system can provide many benefits to organizations with more than one satellite, and these benefits are supported by specific key elements of a fleet control system. Fleet Overview Consolidation of status data on to a single display or set of displays allows one operator to monitor the operation of many satellites 1,2, without jeopardizing the health and safety of the satellites, This operator s role is to monitor operations and assist in manual special operations, rather than to manually conduct routine operations. This decreases the number of operators required to staff an around-the-clock operations center. Fleet Data Model Data is named, collected, and managed as a fleet, providing separate namespaces for each satellite, but allowing similar satellites to reuse display and procedure definitions without creating multiple copies and versions. Derived data can be calculated from a single satellite or across satellites for use in reports and displays. Consistent User Interface Common displays and tools used across multiple satellites reduces the training requirements for operations and results in more flexible staffing. Shared Analysis Tools Historical data can be accessed and analyzed across satellites with common tools for easier performance analysis and management reporting. Unified Automation Tools A single procedure language allows automation of routine operations across the fleet that can be managed consistently by operations staff and eliminates the need for multiple experts on satellite-vendor-specific procedure languages. Automated operations can be planned and tested by experts offline during normal working hours. 1 Global schedule A schedule of operations for all satellites and facilities provides a unified schedule for operations staff as well as the opportunity to share ground facilities and equipment across satellites. 1 For example, a single steerable antenna with associated RF and baseband equipment can provide a backup interface and second ranging station for multiple satellites. Two Architectures for Fleet Management Montreal, Canada May 17 21 2004 2 of 8
Two architectures have emerged for fleet control systems to provide these benefits. The first is a system of systems (SOS) approach that maintains a single satellite control system for each of the satellites under control and applies a fleet integration software layer that provides the fleet perspective 2,3, as illustrated in Figure 1. This approach has been used by at least one telecommunications provider and has been proposed as an approach for Galileo. 3 Figure 1 System of Systems Approach Fleet Control View Fleet Integration Software Control View Control View Control View Control System Control System Control System The fleet integration software provides the integrated view of the system to fleet operators and spacecraft engineers. In some cases, all monitoring and control functions are performed at the fleet level, without directly using the individual SCS displays and procedures. In other cases, the fleet view is provided for the supervisory level, but automated and manual operations are carried out using the satellite-specific SCS. There are several advantages to this approach: It allows a progressive migration to fleet operations from individual SCS s. It allows automated operations using the tested procedures (if any) provided by the satellite vendor. Montreal, Canada May 17 21 2004 3 of 8
Because the SCS systems are independent, they can typically be stopped, modified, and restarted without affecting other satellites under control, assuming the fleet integration software is written to prevent deadlocks. The difficulty with this approach is the complexity of the fleet integration software layer. The greater the variation in the underlying SCS s is, the greater the complexity of the integration layer will be. The integration software layer is dependent not only on each SCS, but on each SCS version, creating complexity for system upgrades. In some cases, the underlying technology of a new SCS may make it impossible to bridge without impacting the interfaces to existing SCS s. The fleet data model must be implemented completely in the integration layer, since the underlying SCS software contains no structures for multiple satellites. To fully achieve the benefits of a fleet management system with the SOS approach, many of the functions that exist in the underlying SCS s will be duplicated and eventually obsoleted by the integration layer, including displays, data archival, procedure language, etc. Equipment sparing and systems maintenance personnel will have to be trained for all of the underlying computer system types. Another drawback to this approach is that each underlying SCS system must be maintained at least through the associated satellite lifetime. Since the typical telecommunications satellite lifetime is about 3 times the obsolescence lifecycle of computer systems, several upgrades may take place during the life of the satellite and may affect the integration software layer. In the worst case, the SCS may become unsupported. Because of this possibility, the connection layer protocol between the integration layer and each SCS should be based on highly interoperable standards supported at the operating system (OS) level, e.g. TCP/IP, since an SCS may be stranded on a particular equipment and OS version without the ability to upgrade other 3 rd party packages. Multi-Satellite Control System The second architectural approach to fleet management uses a control system that is inherently a multisatellite control system (MSCS), i.e. it contains the data models and internal architecture to support the key elements of fleet management. Multi-satellite capability has been demonstrated in some commercial off-the-shelf products, such as OS/COMET from Harris Corporation, and in some custom ground control systems, such as the control system for the Globalstar constellation. An important requirement for an MSCS is that it is easily adaptable to new satellite bus types. This is an important requirement for multi-mission fleets and frequently becomes a requirement for a long-term, multi-satellite/single mission fleet. Figure 2 illustrates the internal layering necessary to provide a consistent fleet-wide toolset for monitoring and control with adaptation for different satellite buses. Much of the adaptation can be data-driven, with definitions of telemetry items, telemetry packets, telecommand formats, and telecommand parameters controlling the telemetry and telecommand processing. A capability for software adaptation is also frequently necessary to handle different ground equipment Montreal, Canada May 17 21 2004 4 of 8
interfaces and ground-space protocol differences. This adaptability requirement is satisfied in the SOS approach by interfacing the fleet integration layer to an individual SCS. Figure 2 Multi-Satellite Control System CMD TLM CMD TLM CMD TLM CMD TLM Gnd/Space Protocol Gnd/Space Protocol Gnd/Space Protocol Gnd/Space Protocol 376 601 702 1300 Another key requirement for the MSCS is the independence of satellite control sessions, so that satellite processing can be stopped, restarted with changes, or added without affecting any other satellites. This requirement is normally met within the SOS approach by careful development of the integration layer to prevent deadlocks or side effects between SCS interfaces. Scalability is also a significant concern for fleet management systems. As the number of satellites in the fleet increases, the number of workstations and servers involved in management of the fleet increases. By design, software processes running on these workstations and servers must coordinate activities for the fleet, so the number of software process interconnections between workstations and servers can increase exponentially for a fleet management system. The internal architecture of the control system should provide proven scalability for the size of the fleet anticipated. Even though the SOS approach avoids this interconnection problem for the independent SCS s, it does require proven scalability for the fleet integration software layer. Montreal, Canada May 17 21 2004 5 of 8
Sharing Ground Equipment One advantage for a fleet management approach is the possibility of sharing of equipment and operations staff across the fleet. There are several different models for the sharing of ground equipment, including dedicated strings, cross-strapped arrays of equipment, and remote linked equipment. These ground equipment models are illustrated in Figure 3. The illustration is simplified, since there are usually multiple pieces of equipment involved in satellite monitoring and control, e.g. modulators, demodulators, encryptors, decryptors, amplifiers, etc. It is meant to convey how the equipment is allocated for control. Figure 3 Ground Equipment Models Dedicated Switched Matrix Remote Link ACU RF RF ACU ACU X RF ACU ACU RF RF ACU RF X WAN It is more difficult to share equipment in the SOS approach, because the underlying SCS s are typically developed for dedicated equipment of a specific type. Sharing of equipment is possible if the SCS s are capable of allocating, configuring, and releasing ground equipment through automated procedures. Sharing is also possible through manual reconfiguration of equipment, as long as the equipment types are supported by the SCS s. Coordination of equipment allocation and release must be done manually or through the fleet integration layer. With an MSCS, the coordination can be built into the automation procedures, but the MSCS must support the ground equipment model(s) chosen. Clear Sustainment Plan A clear sustainment plan for a fleet management system is as critical or possibly more critical than for a single SCS. Since the rate of change in Commercial-Off-The-Shelf (COTS) hardware and operating systems has accelerated in the last decade, most of the new systems being built today will be running on obsolete hardware and software in three years, unless the systems are updated throughout the system life. Five years after a system baseline is frozen, no off-the-shelf replacements will be available for the hardware unless the maintenance team procures and stores its own spares, simply because the lifetimes of the systems being built are exceeding the commercial lifetimes of the components being used to build Montreal, Canada May 17 21 2004 6 of 8
them. This is a fact that systems planners, designers, and procurers must consider and an issue that is becoming more critical due to the rapid pace of technology advancement. Future Fleet Management Architectures It is likely that both the SOS and the MSCS approaches to fleet management will continue to be used into the future, but the MSCS approach reduces complexity and duplication of software. If satellite vendors move towards some of the emerging standards for satellite definition and automation languages, the difficulty of migrating a satellite to a fleet management system will be greatly reduced. Support for these emerging standards depends on the cooperation of satellite purchasers, the satellite vendors, and the satellite ground equipment and software suppliers to define and support the standards. Other features that are currently experimental and have only been incorporated for very specific applications will probably be incorporated into product offerings: Flexible security definitions that allow selective protection and segregation of satellite data and satellite control for multi-mission facilities. This is particularly useful for operators that control spacecraft for multiple customers and may have multiple backup facilities for subsets of the fleet. Remote monitoring capabilities that provide secure and complete access to real-time and historical data. This allows more flexible support from satellite experts in a highly automated or lights-out control system. Given the pervasiveness of broadband Internet connections, this is likely to involve Secure Socket Layer (SSL) connections or other secure Web protocols. A self-describing data archive is an important component for interchangeability and analysis of data. Migration between systems is frequently hampered by lack of access to previously stored data and analysis tools that operate on standardized formats can provide more cost-effective analysis capabilities than special purpose tools for proprietary data formats. Related Industry Standards There are some established and emerging standards that support fleet management as well as reduce the cost of deploying single satellite systems. Some of the CCSDS standards for protocols that are already providing COTS choices in ground equipment are: Telemetry, CCSDS 131-133 Telecommanding, CCSDS 231-232 The CCSDS standard for Space Link Extension (CCSDS 910-912) could also allow similar choices in selecting and using leased ground equipment facilities. Montreal, Canada May 17 21 2004 7 of 8
Other CCSDS standard for file delivery (CCSDS 727.0-B-2) and Internet Protocol (IP) services could change the way that satellites are controlled and monitored, however adoption by the satellite vendors is likely to be slow due to the expense of developing new onboard control software. The Object Management Group (OMG) Space Domain Task Force (SDTF) has adopted an XML-based standard for telecommand and telemetry definitions that would allow ground system vendors and satellite vendors to use a common database format. The SDTF has also released a request for proposals for a telecommand and telemetry access standard that would provide standardized access to real-time telemetry and telecommanding. [1] F.Lecouat, J.M.Dussauze, P.Grandjean, Operations Unification & Automation: Application on a Satellite Fleet, Proceedings of SpaceOps 2002, Houston, Texas, USA, October 2002. [2] J.Coleman, REACH: Real-time Data Awareness in Multi-spacecraft Missions, Proceedings of SpaceOps 2002, Houston, Texas, USA, October 2002. [3] R.Messaros, C.Lannes, J.Stjernevi, H.Kubr, SCOS-2000 Multisat: The Multi-Satellite Extension of a Mission Controls System, Proceedings of SpaceOps 2002, Houston, Texas, USA, October 2002. Montreal, Canada May 17 21 2004 8 of 8