GDSS. A Service Oriented Architecture for Mission Operations

Transcription

1 SpaceOps 2006 Conference AIAA GDSS: A Oriented Architecture for Operations Roger S. Thompson, Stewart Hall and Oliver Page SciSys Ltd., Chippenham, Wiltshire SN14 0GB, United Kingdom and Nestor Peccia uropean Space Agency (SA/SOC), Darmstadt D-64293, Germany GOS GDSS SOA Oriented Architecture (SOA) has been employed with significant success in e- commerce and internet-based applications. The paper considers how SOA can be applied to space mission operations initially focusing on ground-based Control, but ultimately considering end-to-end mission operations at system level. SA is currently developing the architecture for the future SA Ground Operations System (GOS) and a number of studies have supported this. The Ground Data System s study has focused on the definition of end-to-end Operations services. This draws upon the approach developed in the context of the CCSDS Spacecraft M&C Working Group. = SA Ground Operations System = Ground Data Systems s = Oriented Architecture H objective of a Oriented Architecture T (SOA) is to achieve loose coupling between interacting software components or agents. In traditional software systems, where components are strongly coupled, the interface between any pair of subsystems is often explicitly defined in terms of the full stack of protocols employed from application down to low-level communications. This leads to closed architectures, in which it is difficult to replace, or re-use, software components from one system to another. In SOA, a backbone of standardised service interfaces is defined in which individual components act either as a provider or consumer of the service. Application level components only communicate with each other through these standard services and may be plugged in to a supporting infrastructure that implements the service interfaces (see Fig. 2). s are also layered, such that specific application-level services are implemented using more generic messaging services, which themselves use an underlying communications protocol. Nomenclature I. Introduction Figure 1. Traditional vs. Oriented Architecture The components of a traditional architecture can be integrated into just one system. With service oriented architecture, many similar systems can be deployed without modification to the components. 1 Copyright 2006 by SciSys Ltd. Published by the, Inc., with permission.

2 Specification of a standard service interface requires: an information model for the service, which defines the data objects exposed at the service interface; and a dynamic model that defines operations that can be performed on those objects and events that report changes in their state. This approach unifies the definition of messages exchanged between service provider and consumer, with the associated configuration [operations preparation] data and logging of history. The potential benefits of the SOA approach, as applied to spacecraft mission operations, include: Plug-and-play interoperability of MCS components Re-use of common infrastructure across multiple systems Independence of core application software from underlying implementation technology platform and communications Scope to evolve a system, by replacing components or changing underlying technologies Reduced mission-specific deployment costs Independence of mission configuration data and history from system implementation Components s Infrastructure Figure 2. Oriented Architecture: Plug-in Components, s and Infrastructure. II. GDSS: Ground Data System s SA is currently developing the architecture for the future SA Ground Operations System (GOS) and a number of studies are supporting this. The Ground Data System s (GDSS) study, being performed by SciSys, is specifically focussed on the definition of end-to-end Operations services. This study draws upon the approach developed in the context of the CCSDS Spacecraft M&C Working Group as outlined in their green book: Operations s Concept. A. Operations Functions The ground segment has been decomposed into systems in CSS-70 and modifications to this have been proposed in the uropean GS Software Technology Harmonisation Reference Architecture. From the perspective of mission operations, the ground segment may be considered to comprise the following systems: GSTS Ground Station Network MCS Control [Operations] System MS xploitation System * GSUS Ground Support System Fig. 3 illustrates the principle application-level functions associated with mission operations and their end-to-end interactions. Functions are grouped into the four principle ground segment systems and, as mission operations are concerned with operation of the space segment, the spacecraft itself. Functions shown with a person symbol typically require a man-machine interface. The lines between functions represent the end-to-end interactions involving the mission operations (MCS) functions that GDSS is principally concerned with. It is these interactions that are supported by mission operations services. The principle MCS application-level functions identified are: Operations [] Planning Flight Dynamics [Performance] Analysis [or valuation] and Reporting On-board Software Management xternal Data Distribution * CSS-70 decomposes the MCS into functionally equivalent OCS and PCS, and functionally distinct MS. For the purposes of this discussion MS is therefore considered distinct from MCS. 2

3 Operator Interaction (status displays and manual control applications) [Ground-based] Operations Automation GSUS: Ground Support System GS Development & Validation MS: xploitation Planning Product Distribution Data Processing MCS: Operations Analysis & Reporting Operations Planning Flight Dynamics Management Operator Interaction GSTS: Ground Station Network Station M&C Spacecraft Ground Automation Spacecraft M&C On-board Automation Station Scheduling Tracking & Ranging Data Acquisition It is important to note that only those functions constituting the applications layer for mission operations are shown. Other functions whose purpose is essentially to support or implement the application level interactions are omitted this includes TM/TC protocol level processing, internal data distribution and data archiving. The first four may be considered off-line functions, while the last two concern on-line operations. These MCS functions support end-to-end interaction with applications residing: On the Spacecraft At the Ground Station, or Ground Station Network Complex Within the MS or an xternal Ground System Within the Ground Support System AOCS Figure 3. Principle nd-to-nd Operations Functions xternal Data Distribution On-board Software B. Operations Information The previous section summarises the Operations functions and the end-to-end interactions that are to be supported by mission operations services. This is a functional view of the system. In order to ensure commonality and re-use, it should not, however, be concluded that there is a one-to-one correspondence between the interfaces between functions [the lines connecting functions in Fig. 3] and services. A service relates to a particular type of interaction, while the interface covers all interactions between any two functions. To move from the identification of interfaces to the identification of services, it is necessary to consider the nature of the information that flows across the interfaces, and what operations can be invoked across those interfaces. This is an information view of the system. When this is analysed, it is found that: The same fundamental type of information flows across multiple interfaces An interface can involve several different fundamental types of information. In fact, the interactions between functions can be reduced to a relatively small set of these fundamental types of information object, which include: 3

4 Monitoring and Control: parameters, actions and alerts Automated Procedures or Functions, Schedules and Planning Requests Time, Position, Orbit and Attitude On-board Software Images [Payload] Data Products and Reports Operator Interactions (notifications, alarms and queries) Data Buffers These fundamental types of information correspond to information or service objects that must be shared by both service provider and service consumer. These service objects are exposed at the service interfaces, i.e. their state is known to both consumer and provider. In order to keep their internal views of a service object in step with each other, consumer and provider must exchange messages. Typically, the service provider will generate event messages to signal a change of state in a service object; while a service Provider Consumer consumer may invoke operations to effect a change in a service object. The Operations s identified correspond closely to the fundamental service objects that have been identified in the information view. Object vents Object Figure 4. Information View: Objects, vents and Operations Object View Operations C. Identification of Operations s Fig. 5 shows the functions previously identified in Fig. 3, linked by coloured lines representing the services. ach service is shown in the manner of a bus the horizontal lines representing the service with consumer functions connected by vertical lines. Provider functions are indicated by the circle on the line connecting them to the service bus. s providing an interface between just two functions are shown as a simple vertical line. The identified Operations s are also listed and described in Table 1. The services themselves have been identified on the basis of common types of information or control exchanged between the functions. It should be noted that the interface between any pair of functions may be supported by multiple services. Another key feature shown in the diagram, is the concept of proxy functions that represent on-board functions within the ground segment. Proxy functions serve a dual purpose: They can be permanently available in the case of intermittent contact with the space segment. This allows them to hold an image of the last known or predicted status of a spacecraft out of contact; to buffer messages to be sent to the spacecraft; and to act as the repository for service history [archived data] within the ground segment. They can encapsulate a legacy, lower communications protocol level or non-standard interface with the spacecraft. In the context of existing SA MCS infrastructure, the bulk of SCOS-2000 functionality (other than its user interfaces) is essentially that of the spacecraft proxy. It should be noted that while the distribution of functions shown in Fig. 5 is representative: it does not reflect all combinations of functional deployment and service usage possible within the architectural framework. Functions, such as Planning or Flight Dynamics could be migrated on-board and associated proxy functions added. Functions can also interact with additional services: e.g. automated Flight Dynamics could support the Schedule xecution service. 4

5 MS GSUS Other Planning Data Processing Development xternal User SRI GDD PRQ FDS RP Analysis & Reporting Operations Planning Management Flight Dynamics xternal Data User OSM MC PX SX TIM OPI AUT Operator Interaction Spacecraft M&C Proxy Spacecraft M&C Operations Automation OB Procedure Proxy OB Procedure xecution OB Schedule Proxy OB Schedule xecution SL-Man Station Scheduling OB Data Product Proxy OB Data Product Storage Proxy Figure 5. GDSS Operations s Table 1. GDSS Operations s LOC Tracking & Ranging ID Name Description MC Core Monitoring & Control Parameters: publish status; set Actions [Commands]: publish status; invoke/send Alerts [vents]: notify; raise AUT Automation Specialisation of MC for automation of proxy functions DPM Data Product Management Data Product [Payload Data File]: directory; transfer FDS Flight Dynamics Orbit/Attitude: determination, propagation, manoeuvre preparation GDD Generic Data Distribution Product: catalogue; order; deliver LOC Location Position: tracking, ranging, onboard positioning OPI Operator Interaction Message/Alarm/Query: notify; operator response OSM Management On-board Software: load; dump PX Procedure xecution Procedure/Function: control; progress reporting PRQ Planning Request Planning Request: request; response RBM Remote Buffer Management Buffer: catalogue; retrieve; clear RP Report Reports: publish; catalogue; retrieve; generate SX Schedule xecution Schedule: distribute; edit; control; progress reporting SRI Software Reference Image On-board Software Image/Patch: distribute TIM Time Time: report; set; correlate; notify Station M&C DPM MCS GSTS Spacecraft 5

6 III. GDSS Structure D. Generic Structure Configure Consumer HCI Displays Other Applications History Lookup ditor Operations Preparation dit Configuration Database Invoke Active Interface Layer History Archive Directory Configure Archive Provider Figure 6. Generic GDSS Operations Structure Publish All GDSS application level or mission operations services share a common service structure. This is illustrated in Fig. 6. People often equate the service interface to the live exchange of information between service provider and service consumer. However, this is only part of the infrastructure required to support the service interface: termed the active service interface in the diagram above. It is a key concept within GDSS that all aspects of the information flowing across the service interface are integrated within the service layer. Other service level interfaces are required for: location via the service directory Distribution and Access to the service configuration Archiving and Retrieval of the service history The service layer involves six main components: The Provider is responsible for supporting the core service functions. The Consumer is a user of the core service functions, and is typically either a Human-Computer Interface, or another software application. The Directory provides holds details of all available services. Providers publish the services they provide within the Directory. Consumers can then look up a required service in the Directory to locate it, before invoking the service directly with the Provider. The Configuration Data specifies the objects and operations that can exist across a specific instance of the service interface, and must be available to both Provider and Consumer if they are to communicate effectively. The ditor enables configuration of the Configuration Data for a given instance of the service. The History [typically held in an Archive] constitutes persistent storage of service events, such that a Consumer can retrieve historical status information pertaining to the service. The service specification does not define the actual implementation of the service provider or consumer. It confines itself to definition of the GDSS Operations (GDSS-MO) service layer that binds them together. Similarly Configuration and History may be implemented using common infrastructure across multiple services. Database and Operations Archive functions can support aggregates of the corresponding data sets for all GDSS-MO services. In order to allow the greatest flexibility in maintenance, access and implementation, however, the data within these aggregated functions should be structured in accordance with the service specifications.. Information Model The service interface is based on a common information model shared by all collaborating elements in the service layer. This defines: the information objects that exist across the service interface 6

7 the operations that can be performed on those objects the events, or messages, that report the current status of those objects ach Operations specification has its own associated set of service object types. These object types, their attributes, operations and associated events, form part of the service specification. For more complex services (e.g. schedule execution) there may be several different types of object, with relationships between them. For any given deployment (or instance) of the service, the actual objects that exist (parameters, commands, procedures, etc.) are specific to the mission concerned. These are defined in the configuration data for the service instance. Two basic types of service object exist: statically instantiated objects, like parameters, that are fully defined in the configuration data. dynamically instantiated objects, like commands or actions, that have a definition in the configuration data, but a new instance of the object is created each time it is invoked. Version Series dit Save Validate Present Future Past Operations Preparation Configuration Data Object Identity Concurrent Sessions (Live + Simulated + Replay) Operations xecution Status Data Object Identity Historical Sessions Operations Analysis History Object Identity 1 n 1 1 Object Definition 1 1 Install Object Definition Definition Update vent 1 n Replay Version 1 n 1 n 1 n Object Definition Object Instance Retrieve O Instantiate Object Instance Instantiation vent 1 1 Replay Retrieve Figure 7. Information Model for a Generic Operations Object Update Object Status Status Update vent Object Status O Operation Replay Retrieve Many mission operations services share the same common basis to their information model. This is illustrated in Fig. 7. For each object there are four principal elements: the unique object identity static object definition information [or characteristics], such as its name, description, arguments, check conditions, etc. details for object instantiation, such as a unique instance ID, time of invocation and argument values dynamic object status information, such as its current execution and verification status. For statically instantiated objects, the object invocation is effectively omitted (it is a null singleton). The figure illustrates the aspects of this information model that apply during three phases of operations. 1. Operations Preparation It is during operations preparation that the set of objects applicable to a given mission context are defined. This corresponds to the identification of object identities and their associated definitions. This is the service configuration data for the associated service instance. This data is typically maintained using a [database] editor forming part of the operations preparation function. This is the service editor for the service. configuration 7

8 data is maintained under configuration control, and each version will contain a set of action definitions. The service configuration data itself must conform to a standard schema that reflects the information model for the service. configuration data may also contain references to the configuration data for other related services (e.g. a procedure definition may reference parameters or actions). To support operations execution, a version of the database is distributed and installed within the mission operations system. 2. Operations xecution At service initialization, service objects are created for each statically defined object in the currently installed version of the service configuration data. Dynamically instantiated objects may also be created, based on the current definition, as a result of specific instantiation operations (e.g. sending a telecommand). The service also defines other operations that can be performed on objects and the events that report their status to a service consumer. Provider and consumer functions will then hold both the current definition and current status of these objects. Note that the effect of an operation is reported as an event, such that it can be observed by all consumers. Where live and simulated data exist concurrently, these are partitioned into different sessions to avoid confusion between them. ach concurrent session has its own definition and status for each parameter. 3. Operations History In addition to being passed across the active service interface, the same events that report object instantiation and status to a service consumer, should be available for subsequent retrieval from history. This allows the same or similar applications to work with both live and historical data. The most coherent way of ensuring that history is correctly correlated to changes in the installed service configuration data, is also to store parameter definition change events in history. History is also partitioned into sessions (of which there may be many more than can be concurrently active). This leads to a logical model of history, which is structured as a tree of events: Session > Object Identity > Object Definition > Object Instance > Object Status History can be accessed in two main ways: Retrieval A block of events relating covering a period of time is extracted in a single transaction. Replay Discrete events are forwarded dynamically to the consumer in accordance with an evolving timeframe. Complex information, such as operations procedures and schedules may themselves comprise a hierarchy of different types of object. For example, a schedule may contain predicted events, planned contacts and planned operational tasks that are themselves broken down into a set of individually schedulable activities. Schedule > vent Contact Task > Activity ach of vent, Contact, Task and Activity has the same structure as a dynamically instantiated object with definition, instance and status. If this approach is adopted systematically, although each GDSS Operations service will have its own specific information classes, it can be seen that a common infrastructure can be devised for: Managing the Static Definitions of those objects (the service configuration data) Storing and Retrieving the Operational History of those objects (the service history) This data handling infrastructure could be applied to all GDSS-MO services that follow the same basic information model. If new services are defined that meet the same information model, then they can use the same infrastructure. Applications can also be developed that use multiple services with ease. A historical data replay session could also apply to multiple services and multiple consumers, allowing integrated and synchronized replay of data (parameter, command and automation history) to provide a complete picture of what was occurring at a point in time. F. Layering A key feature of a service-oriented architecture is that it is built up in layers, starting with basic communications protocols, overlaying these with generic middleware, and ultimately providing specialized domain services. In this way, applications are isolated from the detailed implementation of the service interface, while taking benefit from existing technologies. The individual GDSS-MO services listed in Table 1 are overlaid over a GDSS Common s (GDSS-C) layer that provides a common infrastructure supporting all or multiple GDSS-MO services. 8

9 GDSS-MO Consumer Application GDSS-MO Provider Application GDSS-MO Access Points (SAP) GDSS Operations s (GDSS-MO) GDSS-C Access Point (SAP) CSS-PUS Adapters GDSS Common s (GDSS-C) GDSS-C Adapter Infrastructure/Middleware s Message Transfer: File Transfer Publish/Subscribe; Request/Response Mail Communications s (CCSDS SLS Packet TM/TC; CCSDS SIS (SCPS, CFDP); Internet (TCP/IP, FTP) Figure 8. GDSS Layering The GDSS-C layer will provide support for the following: Common Mechanisms such as the Directory Common Interaction Patterns that isolate underlying Infrastructure/Middleware s, including those for Message xchange, File Transfer and Mail Common Concepts, such as domain and session A benefit of implementing multiple GDSS-MO services over a smaller set of common services, is that it is easier to bind these to different underlying technologies that provide the communications layers of the protocol stack. All that is required is an adapter layer between the common service and the underlying protocol to enable all GDSS- MO services over that technology. Hence the same GDSS-MO service can be implemented over ground-based network technologies and middleware, or even across the space link itself. The GDSS-C common layer acts as the adapter layer between the GDSS-MO services and the underlying infrastructure/middleware implementation. However, in the case of a space-ground link using CSS-PUS, each GDSS-MO service would be directly mapped to the underlying PUS services required to implement it on the space link. The GDSS-MO services themselves provide the plug-and-play interface for applications, allowing them to be integrated and deployed wherever is appropriate for the mission. G. GDSS Common Interaction Patterns A generic structure for all GDSS-MO services has been introduced above. Analysis of these services shows that a limited number of common patterns of interaction can be applied to all currently identified services. These common patterns of interaction address the active service and historical data interfaces in greater detail, and will allow more service capabilities to be provided within the GDSS-C common layer as generic services. The following patterns have currently been identified: Operation Operator Interaction Product Distribution 9

10 The Operation pattern is illustrated in Fig. 9 and discussed in more detail below. The figure shows the constituent service interfaces: active service interfaces are shown in red; service history interfaces in blue. The diamonds represent service events and the hexagons service operations. This pattern applies to the majority of identified GDSS-MO services, including: MC, AUT, FDS, LOC, OSM, PX, PRQ, SX, SRI, TIM. The active service interface can be divided into three components: Observe Interface Control Interface Manage Interface An Observe interface supports the provision of status information to any service consumer, but does not impact the basic operation of the service provider. This is achieved through a flow of status update Configuration Database Consumer Observe Control C Manage M Retrieve Replay Control Replay (Observe) Layer History Archive events relating to the service interface objects. For example, a consumer of the MC Parameter service will first subscribe to a set of parameters. It will then receive a flow of Provider Archive parameter status update events, relating to the subscribed set of parameters. It can be Figure 9. Operation Interaction Pattern regarded as a read only interface. Many service consumers can observe the same information at the same time: a common implementation pattern is that of publish-subscribe. Note that the impact of operations performed through Controller and possibly Manager interfaces will be visible through the Observer interface. A Control interface supports the initiation by a service consumer of operations that are supported by the service provider. For example, a consumer of the MC Parameter service may set the value of a parameter. A consumer of the MC Action service can invoke an Action (e.g. send a telecommand). Controller interfaces are typically one-to-one, and the number of concurrent controller interfaces may be restricted by the service provider: a common implementation pattern is that of request-response. The response may return the result of the operation or, where a new instance of an object (e.g. an Action/Command) has been created, the identity of the object created. A Manage interface typically concerns run-time configuration of the service provision affecting the on-going behaviour of the service provider, also achieved as operations. An example for the MC Parameter service would be to disable parameter validity checking for one or all parameters. These may be regarded as specialist extensions of the Control interface that are either not required or only infrequently required by most service consumers. The service history interfaces allow access to historical data. In principle, it should be possible to access all events that could have been observed live, via the Observe interface. In principle, the service history itself comprises an archive of all the observable events, logged at run-time by the Provider. However, alternative implementations that require re-processing of lower level protocol history on demand to regenerate the events are also possible. Two distinct methods of historical data retrieval are available to the service consumer: Active Replay: reconstruction of the Observe interface for a historical time period, with dynamic replay of a sequence of discrete events, in the context of a historical session. Bulk Retrieval: retrieval of a range of service history events [potentially meeting specified filter criteria] as a single retrieval action. A variation on this is to allow data to be retrieved in successive blocks or pages. Active Replay supports applications, such as status displays (ANDs and Mimics), that have a historical replay view. Bulk Retrieval supports off-line applications, such as Performance valuation and Analysis, and also status displays that show a historical trend or log view (Graphical and Command History displays). Active replay is supported by a Replay Control interface, coupled with a historical copy of the Observe interface. Bulk retrieval works in a transactional way, with a request being followed by the transfer of a block of retrieved data. 10

11 IV. Conclusions By supporting such generic interaction patterns within the GDSS-C common infrastructure layer, not only are GDSS-MO services isolated from the underlying technology, but the individual services that conform to a common pattern become a relatively thin layer. This has a number of key benefits: it reduces the cost of implementing the GDSS service infrastructure, as each high level service is little more than the configuration of the information model for the service. it makes GDSS easily extensible to accommodate new or mission-specific services, as the GDSS-MO application service represents only a thin layer on top of the generic GDSS-C layer. Common configuration data and archiving solutions can be developed that support all GDSS services conforming to a given pattern. 11