Spacecraft Database Standardization: An OMG Initiative
2002, SpaceOps 2002 Conference
https://doi.org/10.2514/6.2002-T5-05…
10 pages
1 file
Sign up for access to the world's latest research
Abstract
In July 2001, the Space Domain Task Force of the Object Management Group (OMG) issued a Request for Proposal (RFP) on Telemetric and Command Data Specification. This RFP solicited proposals that define telemetry and commanding data specifications in support of all phases of the satellite, payload, and ground segment lifecycle: system design, development, test, validation, and mission operations. In fact, telemetry and commanding data design is still often performed multiple times in multiple formats by multiple contractors during the lifecycle of the satellite, well before the satellite is ever deployed for mission operations. Standardisation of telemetry and commanding data descriptions for spacecraft health and safety monitoring, as well as payload interfaces, will reduce the cost of these implementations and decrease the development schedule, integration, and test of the satellite and its component systems. A common, adaptable specification can also be used to support multiple heterogeneous missions, facilitating interoperability among ground control systems, simulators, testing facilities, etc.
Related papers
Springer eBooks, 2013
The concept of developing a Handbook on Satellite Applications is based on the concept that all of the commercial and practical applications of space have many elements in common. In fact very similar power systems, spacecraft platforms, stabilization and positioning systems, and tracking, telemetry, and command systems are used for the various types of application satellites. It is the payloads
SpaceOps 2016 Conference, 2016
The increasing trend within operations at EUMETSAT is towards combining resources used across different satellite programs where possible into Multi-Mission Elements (MMEs). While the spacecraft and their directly related operations by nature are program specific, where possible an MME is used to provide services. The MME concept can apply to a particular infrastructure, software, team of people, or a complete facility comprising a hardware and software solution along with a maintenance team. Examples within EUMETSAT include Archive and User Services, Dissemination, Performance Monitoring and Infrastructure components. Multi-mission elements bring mainly advantages to agencies, although they can require higher initial effort. Additionally a new program may have requirements which conflict with the existing core design. The transition to Multi-Mission, especially in agencies where space programs are already in an advanced state, might require higher effort, especially with regard to software and hardware development, maintenance and associated costs. Nevertheless, the latter are reduced in the long term, when one common platform is used instead of one per mission. MMEs can be specified in a service to be provided to future Satellite programs, drawing on experience and lessons learnt with the aim of avoiding the reinvention of the wheel. Multi mission also means consistency across programs of user interfaces (e.g. web-based services). Training efforts and costs are much lower, especially considering that employees often migrate between missions: in this way they are already familiar with most of the systems and will only need dedicated training for specific mission activities. A specific example of an MME which is currently undergoing an evolution at EUMETSAT will be the focus of this paper: the Performance Reporting Evolution Project (PREP).This will provide enhanced and automated reporting to the Operations Teams including specific Key Performance Indicators (KPI) for Management. The aim of the PREP is to upgrade and integrate the hardware and applications into a enterprise solution, which can easily provide similar services to new programs. The PREP will take well established MME tools that are used for near-real time operational monitoring, and evolve them into a solution that can also be used to create reports on the EUMETSAT KPIs in Key Reporting Areas, namely completeness, timeliness and quality of disseminated meteorological imagery and products. By building a modular hardware and software solution based around a core service with plug in components for individual missions, flexibility is ensured. Through this, many of the potential challenges listed above can be overcome. Space programs and their collaboration with external agencies are in continuous growth. Together with the benefits of MMEs within the agency itself, the importance of a common interface with external partners has become very relevant. In fact, agencies (public and private) are moving towards a higher international collaboration which start mission-specific, but tends to expand. MMEs help to
I NTROD UCTlO N lnteroperability of space data systems is of great concern to Space Agencies because sharing or reusing interoperable resources among multiple projects and multiple Agencies can reduce the cost of developing and operating space data systems. However, an on-going problem is that each space data system often has a different architecture and therefore the elements of one system cannot be easily used by other systems.
Synthesis of Embedded Software, 2010
… Control and Data …, 1999
Spacecraft ground control data systems are by necessity sophisticated and complex. One of the challenges for system designers is to understand and incorporate the needs of the users so that their systems are easy to use and minimize user errors. User-...
Three persistent common problems in satellite ground control software are obsolescence, lack of desired features and flexibilities, and endless software bug fixing. The obsolescence problem occurs when computer and ground equipment hardware become obsolete usually after only one third into the satellite mission lifetime. The software needs to be updated to accommodate changes on the hardware side, requiring significant work of satellite operators to test, verify, and validate these software updates. Trying to help solve these problems, an OPM model and guidelines for developing satellite ground control software have been proposed. The system makes use of a database-driven application and concepts of object-process orientation and modularity. In the new proposed framework, instead of coding each software function separately, the common base functions will be coded, and combining them in various ways will provide the different required functions. The formation and combination of these base functions will be governed by the main code, definitions, and database parameters. These design principles will make sure that the new software framework would provide satellite operators with the flexibility to create new features, and enable software developer to find bugs quicker and fix them more effectively.
Relation, 2008
The Reference Architecture for Space Information Management (RASIM) suggests the separation of the data model from software components to promote the development of flexible information management systems. RASIM allows the data model to evolve independently from the software components and results in a robust implementation that remains viable as the domain changes. However, the development and management of data models within RASIM are difficult and time consuming tasks involving the choice of a notation, the capture of the model, its validation for consistency, and the export of the model for implementation. Current limitations to this approach include the lack of ability to capture comprehensive domain knowledge, the loss of significant modeling information during implementation, the lack of model visualization and documentation capabilities, and exports being limited to one or two schema types. The advent of the Semantic Web and its demand for sophisticated data models has addressed this situation by providing a new level of data model management in the form of ontology tools. In this paper we describe the use of a representative ontology tool to capture and manage a data model for a space information system. The resulting ontology is implementation independent. Novel on-line visualization and documentation capabilities are available automatically, and the ability to export to various schemas can be added through tool plug-ins. In addition, the ingestion of data instances into the ontology allows validation of the ontology and results in a domain knowledge base. Semantic browsers are easily configured for the knowledge base. For example the export of the knowledge base to RDF/XML and RDFS/XML and the use of open source metadata browsers provide ready-made user interfaces that support both text-and facet-based search. This paper will present the Planetary Data System (PDS) data model as a use case and describe the import of the data model into an ontology tool. We will also describe the current effort to provide interoperability with the European Space Agency (ESA)/Planetary Science Archive (PSA) which is critically dependent on a common data model.
AIAA SPACE 2015 Conference and Exposition, 2015
The OpenOrbiter project is a campus-wide effort at the University of North Dakota to design and build a low-cost CubeSat-class satellite. The intent is to create a publicallyavailable framework that allows a spacecraft to be built with a parts cost of less than USD $5,000 (excluding mission payload-specific costs). This paper focuses on OpenOrbiter's software system methodology and implementation. Current work seeks to create a generalized framework that other CubeSat developers can use directly or alter to suit their mission needs. It discusses OpenOrbiter's overall design goals with an emphasis on software design. The software architecture is divided into three main components: operating software, ground station software and payload software. Each component is discussed along with the requirement for efficient and effective communication between the components. A communication standard that fulfills these goals is discussed herein. The paper also discusses several challenges encountered and their resolution, including the creation of heuristics to optimally schedule tasks, handling the uncertainty that is inevitable in satellite operations, defining useful standards for all components of the software, communicating between components effectively and testing software to ensure proper operation in an orbital environment. Then, the current state of each software component and its implementation is presented. Finally, the significance of OpenOrbiter is discussed and plans for future work are presented.
2022
This paper aims to present a comprehensive survey on information integration (II) in space informatics. With an ever-increasing scale and dynamics of complex space systems, II has become essential in dealing with the complexity, changes, dynamics, and uncertainties of space systems. The applications of space II (SII) require addressing some distinctive functional requirements (FRs) of heterogeneity, networking, communication, security, latency, and resilience; while limited works are available to examine recent advances of SII thoroughly. This survey helps to gain the understanding of the state of the art of SII in sense that (1) technical drivers for SII are discussed and classified; (2) existing works in space system development are analyzed in terms of their contributions to space economy, divisions, activities, and missions; (3) enabling space information technologies are explored at aspects of sensing, communication, networking, data analysis, and system integration; (4) the importance of first-time right (FTR) for implementation of a space system is emphasized, the limitations of digital twin (DT-I) as technological enablers are discussed, and a concept digital-triad (DT-II) is introduced as an information platform to overcome these limitations with a list of fundamental design principles; (5) the research challenges and opportunities are discussed to promote SII and advance space informatics in future.
Space Technology Conference and Exposition, 1999
The rising frequency of NASA mission launches has highlighted the need for improvements leading to faster delivery of mission software without sacrificing reliability. In April 1998 Jet Propulsion Laboratory (JPL) initiated the Mission Data System (MDS) project to rethink the mission software lifecycle⎯from early mission design to mission operation⎯and make changes to improve software architecture and software development processes. As a result, MDS has defined a unified flight, ground, and test data system architecture for space missions based on objectoriented design, component architecture, and domainspecific frameworks. This paper describes several architectural themes shaping the MDS design and how they help meet objectives for faster, better, cheaper mission software.

Loading Preview
Sorry, preview is currently unavailable. You can download the paper by clicking the button above.
References (10)
- Space Domain Task Force, http://space.omg.org
- Space Domain reference Architecture, http://cgi.omg.org/cgi-bin/doc?space/
- Monitor/Control Data Access, http://cgi.omg.org/cgi-bin/doc?space/02-01-04
- Telemetric and Command Data Specification, Space RFP-1, 20 Aug 2001, Space/01-04-01
- CCSDS Packet Telemetry, CCSDS 102.0-B-4
- CCSDS Telecommand, CCSDS 203.0-B-1
- W3C Recommendation -Extensible Markup Language (XML) 1.0 (Second Edition, 6 October 2000), http://www.w3.org/TR/REC-xml
- W3C Recommendation -XML Schema Part 0: Primer (2 May 2001), http://www.w3.org/TR/xmlschema-0/
- W3C Recommendation -XML Schema Part 1: Structures (2 May 2001), http://www.w3.org/TR/xmlschema-1/
- W3C Recommendation -XML Schema Part 2: Datatypes (2 May 2001), http://www.w3.org/TR/xmlschema-2/