Search NASA⌕ Search

Engineering topics

Sarrel, Marc A.

Publications and source records attributed to Sarrel, Marc A..

13 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2022

Benefits and Challenges of CCSDS File Delivery Protocol as Applied to Europa Clipper

—This paper describes the use of the Consultative Committee for Space Data Systems (CCSDS) File Delivery Protocol (CFDP) on the Europa Clipper mission for both uplink and downlink of files. It includes an overview of CFDP, the history of why CFDP was chosen, how it benefits mission operations, some of the mission scenarios that stress CFDP, operability aspects, the best practices that Clipper adopted from other missions and some of the technical challenges with implementation, and verification and validation. The benefits to mission operations accrue because CFDP reduces the need for manual management of file transfer, including retransmission of missing data, and deletion of files only after confirmation of receipt by the ground. The challenges occur because CFDP is a round-trip protocol – it requires messages in both directions to complete a file transfer, and because it uses timers to ensure that control messages are resent if needed to prevent transactions from going stale. Any situations where communication is restricted to a single direction, interrupted, reordered, or backlogged can pose a challenge. There are also implementation challenges. Europa Clipper is the first mission at the Jet Propulsion Laboratory (JPL) to adopt class 2, fully acknowledged, CFDP for both uplink and downlink. The implementation needed new software, requirements and operational procedures. The experience of the Applied Physics Laboratory (APL) with CFDP from their previous missions was crucial to success for Europa Clipper. Because CFDP relies on timers and messages travel in both directions, verification and validation (V&V) requires new approaches. For certain scenarios, a live ground system talking to a live flight system with realistic simulated one-way light times, data rates and data outages must be used.

Albers, Joshua↗
NASA NTRS2020

Operability on the Europa Clipper Mission: Challenges and Opportunities

Flight and ground system operability has been a focus area on the Europa Clipper Project since early in its formulation phase. This has given the operations team the opportunity to influence the design, with a goal of increasing overall system operability. This paper presents example operability challenges, opportunities, and solutions arising from the pre-Critical Design Review (CDR) system design. The integrated wing assembly design directly couples a scientific instrument (the REASON sounding radar) to the spacecraft’s power source (solar array wing panels). Impacts to mission operations of this design include: increased slew durations; solar array pointing constraints during inner cruise, Europa flybys, and orbit trim maneuvers; and stray light intrusions into the stellar reference units’ keep out zones. The use of CCSDS File Delivery Protocol (CFDP) Class-2 for reliable downlink of the large volume of Europa Clipper science data is described, along with nominal and off-nominal use cases. The effort to improve post-launch spacecraft visibility by adding a third low-gain antenna to the spacecraft is detailed. The design of the bulk data store has necessitated the implementation of accountable data products (ADPs), accountability identifiers (AIDs), and metadata packets to provide end-to-end science data accountability. To streamline and automate the flight rules generation and checking process, a first order and temporal logic-based solution of expressing flight rules without ambiguity, and whose programmatic implementation can be automated, is proposed. The focus on operability has had a positive influence on Europa Clipper design decisions, although cost, schedule, budget, heritage, and other technical concerns have many times outweighed operability concerns. However, experience to date demonstrates that this approach to operability results in more thorough, balanced consideration of the effect of early design trades and decisions on the operations phase of a mission than seen in many previous missions, and provides operations development insight into prioritizing work to go.

Signorelli, Joel↗
NASA NTRS2016

A Representative Application of a Layered Interface Modeling Pattern

Model-based systems engineering (MBSE) is intended to improve how systems engineering is performed compared with a more traditional document-based approach by effectively using models to analyze, specify, design, and verify systems. The OMG Systems Modeling Language (OMG SysML™) enables the practice of MBSE by providing a robust and expressive language for representing systems.

Shames, Peter M.↗
NASA NTRS2016

Modeling Systems-Of-Systems Interfaces with SysML

Space data systems are inherently complex. They are systems-of-systems, typically composed of spacecraft and mission operations systems (MOS) belonging to one (or more) organizations, and multi-mission communication assets belonging to other organizations. In many cases, the spacecraft contain sub-systems and instruments provided by different organizations, and MOS systems that may be developed and operated by other organizations. The point of greatest leverage in system architecting is at the interfaces. We have developed a set of methods for using SysML to model systems-of-systems and their interfaces. This paper describes how to apply this method to space data systems at a variety of levels of detail, from abstract systems and subsystems down to hardware and software components, including the details of their interfaces and protocol designs.

Shames, Peter M.↗
NASA NTRS2015

A Modeling Pattern for Layered System Interfaces

Communications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi-layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end-to-end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes. This architectural model pattern uses methods described in ISO 42010, Recommended Practice for Architectural Description of Software-intensive Systems and CCSDS 311.0-M-1, Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.

Shames, Peter M.↗
NASA NTRS2014

Review of Ground Systems Development and Operations (GSDO) Tools for Verifying Command and Control Software

The Exploration Systems Development (ESD) Standing Review Board (SRB) requested the NASA Engineering and Safety Center (NESC) conduct an independent review of the plan developed by Ground Systems Development and Operations (GSDO) for identifying models and emulators to create a tool(s) to verify their command and control software. The NESC was requested to identify any issues or weaknesses in the GSDO plan. This document contains the outcome of the NESC review.

Aguilar, Michael L.↗
NASA NTRS2010

Spitzer Mission Operation System Planning for IRAC Warm-Instrument Characterization

This paper will describe how the Spitzer Mission Operations System planned and executed the characterization phase between Spitzer's cryogenic mission and its warm mission. To the largest extend possible, the execution of this phase was done with existing processing and procedures. The modifications that were made were in response to the differences of the characterization phase compared to normal phases before and after. The primary two categories of difference are: unknown date of execution due to uncertainty of knowledge of the date of helium depletion, and the short cycle time for data analysis and re-planning during execution. In addition, all of the planning and design had to be done in parallel with normal operations, and we had to transition smoothly back to normal operations following the transition. This paper will also describe the re-planning we had to do following an anomaly discovered in the first days after helium depletion.

IWIC↗
NASA NTRS2006

Managing the On-Board Data Storage, Acknowledgment and Retransmission System for Spitzer

The Spitzer Space Telescope has a two-phase downlink system. Data are transmitted during one telecom session. Then commands are sent during the next session to delete those data that were received and to retransmit those data that were missed. We must build sequences that are as efficient as possible to make the best use of our finite supply of liquid helium, One way to improve efficiency is to use only the minimum time needed during telecom sessions to transmit the predicted volume of data. But, we must also not fill the onboard storage and must allow enough time margin to retransmit missed data. We describe tools and procedures that allow us to build observatory sequences that are single-fault tolerant in this regard and that allow us to recover quickly and safely from anomalies that affect the receipt or acknowledgment of data.

Spitzer↗
NASA NTRS2006

Spitzer Observatory Operations -- Increasing Efficiency in Mission Operations

This paper explores the how's and why's of the Spitzer Mission Operations System's (MOS) success, efficiency, and affordability in comparison to other observatory-class missions. MOS exploits today's flight, ground, and operations capabilities, embraces automation, and balances both risk and cost. With operational efficiency as the primary goal, MOS maintains a strong control process by translating lessons learned into efficiency improvements, thereby enabling the MOS processes, teams, and procedures to rapidly evolve from concept (through thorough validation) into in-flight implementation. Operational teaming, planning, and execution are designed to enable re-use. Mission changes, unforeseen events, and continuous improvement have often times forced us to learn to fly anew. Collaborative spacecraft operations and remote science and instrument teams have become well integrated, and worked together to improve and optimize each human, machine, and software-system element.

operational efficiency↗
NASA NTRS2006

Managing the On-Board Data Storage, Acknowledgement and Retransmission System for Spitzer

The Spitzer Space Telescope has a two-phase downlink system. Recorded data are transmitted during one telecom session. Then commands are sent during the next session to delete those data that were received on the ground and to retransmit those data that were missed. We must build science sequences that are as efficient as possible to make the best use of our supply of liquid helium. One way to improve efficiency is to use only the minimum time needed during telecom sessions to transmit the predicted volume of data. But, we must also not fill the on-board storage and must allow enough time margin to retransmit missed data. We describe tools and procedures that allow us to build science sequences that are single-fault tolerant in this regard and that allow us to recover quickly and safely from anomalies that affect the receipt or acknowledgment (i.e. deletion) of data.

on-board storage↗