On Time-Triggered Ethernet in NASA’s Lunar Gateway
Explore the source record for details and available documents.
Ethernet↗
SEARCH · Search NASA
Results for “Time-triggered Ethernet”
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
A Proposed Byzantine Fault-Tolerant Voting Architecture Using Time-Triggered Ethernet
No abstract available
Loveless, Andrew↗
Ethernet for Aerospace Applications - Ethernet Heads for the Skies
One of the goals of aerospace applications is to reduce the cost and complexity of avionic systems. Ethernet is a highly scalable, flexible, and popular protocol. The aerospace market is large, with a forecasted production of over 50,000 turbine-powered aircraft valued at $1.7 trillion between 2012 and 2022. Boeing estimates demand for commercial aircraft by 2033 to total over 36,000 with a value of over $5 trillion. In 2014 US airlines served over 750 million passengers and this is growing over 2% yearly. Electronic fly-by-wire is now used for all airliners and high performance aircraft. Although Ethernet has been widely used for four decades, its use in aerospace applications is just beginning to become common. Ethernet is the universal solution in commercial networks because of its high bandwidths, lower cost, openness, reliability, maintainability, flexibility, and interoperability. However, when Ethernet was designed applications with time-critical, safety relevant and deterministic requirements were not given much consideration. Many aerospace applications use a variety of communication architectures that add cost and complexity. Some of them are SpaceWire, MIL-STD-1553, Avionics Full Duplex Switched Ethernet (AFDX), and Time-Triggered Ethernet (TTE). Aerospace network designers desire to decrease the number of networks to reduce cost and effort while improving scalability, flexibility, openness, maintainability, and reliability. AFDX and TTE are being considered more for critical aerospace systems because they provide redundancy, failover protection, guaranteed timing, and frame priority and are based on Ethernet IEEE 802.3. This paper explores the use of AFDX and TTE for aerospace applications.
Ethernet↗
Gateway Command and Data Handling Network Implementation and Validation
As initial Lunar Gateway modules approach design maturity, the Artemis Network Validation and Integration Lab (ANVIL) has begun demonstrations to validate avionics network dataflows. The flight architecture design includes utilizing Time-Triggered Ethernet (TTE) and layer-3 switching capabilities to enable greater automation and flexibility of critical and best effort traffic. Critical traffic is considered as Time-Triggered (TT), Rate Constrained (RC) and prioritized Best Effort (BE) traffic classes. End systems, such as mission computers, power control, and robotics, use three planes and all traffic classes while other devices interface via Best Effort. Typical best effort devices include video, laptops, wireless access points, and payloads. Other devices have a various hybrid approach of interfaces including alarms, telemetry/logging, and communication units. In the paper, we will present an update of the Gateway network architecture and how the system will operate nominally and during a stack topology reconfiguration. We will also discuss the network risks, and trade-offs of performance, flexibility, and redundancy. Finally, we will show the process for validation, demonstration, and verification approaches to the vehicle network.
Gateway↗
TTEthernet for Integrated Spacecraft Networks
Aerospace projects have traditionally employed federated avionics architectures, in which each computer system is designed to perform one specific function (e.g. navigation). There are obvious downsides to this approach, including excessive weight (from so much computing hardware), and inefficient processor utilization (since modern processors are capable of performing multiple tasks). There has therefore been a push for integrated modular avionics (IMA), in which common computing platforms can be leveraged for different purposes. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and design complexity. However, the application of IMA principles introduces significant challenges, as the data network must accommodate traffic of mixed criticality and performance levels - potentially all related to the same shared computer hardware. Because individual network technologies are rarely so competent, the development of truly integrated network architectures often proves unreasonable. Several different types of networks are utilized - each suited to support a specific vehicle function. Critical functions are typically driven by precise timing loops, requiring networks with strict guarantees regarding message latency (i.e. determinism) and fault-tolerance. Alternatively, non-critical systems generally employ data networks prioritizing flexibility and high performance over reliable operation. Switched Ethernet has seen widespread success filling this role in terrestrial applications. Its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components make it desirable for inclusion in spacecraft platforms. Basic Ethernet configurations have been incorporated into several preexisting aerospace projects, including both the Space Shuttle and International Space Station (ISS). However, classical switched Ethernet cannot provide the high level of network determinism required by real-time spacecraft applications. Even with modern advancements, the uncoordinated (i.e. event-driven) nature of Ethernet communication unavoidably leads to message contention within network switches. The arbitration process used to resolve such conflicts introduces variation in the time it takes for messages to be forwarded. TTEthernet1 introduces decentralized clock synchronization to switched Ethernet, enabling message transmission according to a time-triggered (TT) paradigm. A network planning tool is used to allocate each device a finite amount of time in which it may transmit a frame. Each time slot is repeated sequentially to form a periodic communication schedule that is then loaded onto each TTEthernet device (e.g. switches and end systems). Each network participant references the synchronized time in order to dispatch messages at predetermined instances. This schedule guarantees that no contention exists between time-triggered Ethernet frames in the network switches, therefore eliminating the need for arbitration (and the timing variation it causes). Besides time-triggered messaging, TTEthernet networks may provide two additional traffic classes to support communication of different criticality levels. In the rate-constrained (RC) traffic class, the frame payload size and rate of transmission along each communication channel are limited to predetermined maximums. The network switches can therefore be configured to accommodate the known worst-case traffic pattern, and buffer overflows can be eliminated. The best-effort (BE) traffic class behaves akin to classical Ethernet. No guarantees are provided regarding transmission latency or successful message delivery. TTEthernet coordinates transmission of all three traffic classes over the same physical connections, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. Common computing platforms (e.g. LRUs) can share networking resources in such a way that failures in non-critical systems (using BE or RC communication modes) cannot impact flight-critical functions (using TT communication). Furthermore, TTEthernet hardware (e.g. switches, cabling) can be shared by both TTEthernet and classical Ethernet traffic.
Loveless, Andrew↗
Synchronizing the Cosmos: The Critical Role of Timekeeping Systems in Gateway's Operational Success
This paper explores the critical role of Universal Spacecraft Time (UST) in the operation of National Aeronautics and Space Administration’s (NASA) Lunar Gateway, a central component of the Artemis program aimed at establishing a sustained human presence on the Moon and facilitating future manned missions to Mars. With the Gateway's design incorporating advanced technologies such as Time-Triggered Ethernet (TTE) for network synchronization, the distinction between network time and UST becomes paramount. UST, defined via the Network Time Protocol (NTP), is essential for coordinating the myriad of operations within the Gateway, from life support systems to scientific experiments. Additionally, the paper will define Mission Elapse Time (MET) and network time, delving into their use and applications within the Gateway framework. This examination provides an in-depth analysis of the challenges in space timekeeping, the implementation and management of UST, MET, and network time, and their pivotal roles in ensuring mission success. Through the precise synchronization of the Gateway's operations, these timekeeping systems not only address the unique temporal dynamics of space travel but also enhance operational efficiency and safety. The paper underscores the indispensable nature of precise timekeeping in the broader context of space exploration, highlighting its implications for future missions and the continued advancement of human capabilities beyond Earth.
Gateway↗
On TTEthernet for Integrated Fault-Tolerant Spacecraft Networks
There has recently been a push for adopting integrated modular avionics (IMA) principles in designing spacecraft architectures. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and de- sign complexity. Ethernet technology is attractive for inclusion in more integrated avionic systems due to its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components. Furthermore, Ethernet can be augmented with a variety of quality of service (QoS) enhancements that enable its use for transmitting critical data. TTEthernet introduces a decentralized clock synchronization paradigm enabling the use of time-triggered Ethernet messaging appropriate for hard real-time applications. TTEthernet can also provide two forms of event-driven communication, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. This paper explores the application of TTEthernet technology to future IMA spacecraft architectures as part of the Avionics and Software (A&S) project chartered by NASA's Advanced Exploration Systems (AES) program.
Loveless, Andrew↗
Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous
Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.
Hirsh, Robert L.↗
Gateway Avionics Concept of Operations for Command and Data Handling Architecture
Explore the source record for details and available documents.
Gateway↗
The Integrated Safety-Critical Advanced Avionics Communication and Control (ISAACC) System Concept: Infrastructure for ISHM
Integrated System Health Management (ISHM) architectures for spacecraft will include hard real-time, critical subsystems and soft real-time monitoring subsystems. Interaction between these subsystems will be necessary and an architecture supporting multiple criticality levels will be required. Demonstration hardware for the Integrated Safety-Critical Advanced Avionics Communication & Control (ISAACC) system has been developed at NASA Marshall Space Flight Center. It is a modular system using a commercially available time-triggered protocol, ?Tp/C, that supports hard real-time distributed control systems independent of the data transmission medium. The protocol is implemented in hardware and provides guaranteed low-latency messaging with inherent fault-tolerance and fault-containment. Interoperability between modules and systems of modules using the TTP/C is guaranteed through definition of messages and the precise message schedule implemented by the master-less Time Division Multiple Access (TDMA) communications protocol. "Plug-and-play" capability for sensors and actuators provides automatically configurable modules supporting sensor recalibration and control algorithm re-tuning without software modification. Modular components of controlled physical system(s) critical to control algorithm tuning, such as pumps or valve components in an engine, can be replaced or upgraded as "plug and play" components without modification to the ISAACC module hardware or software. ISAACC modules can communicate with other vehicle subsystems through time-triggered protocols or other communications protocols implemented over Ethernet, MIL-STD- 1553 and RS-485/422. Other communication bus physical layers and protocols can be included as required. In this way, the ISAACC modules can be part of a system-of-systems in a vehicle with multi-tier subsystems of varying criticality. The goal of the ISAACC architecture development is control and monitoring of safety critical systems of a manned spacecraft. These systems include spacecraft navigation and attitude control, propulsion, automated docking, vehicle health management and life support. ISAACC can integrate local critical subsystem health management with subsystems performing long term health monitoring. The ISAACC system and its relationship to ISHM will be presented.
Gwaltney, David A.↗