Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data prioritization”

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.

At least 55 records · Page 3

Geolab in NASA's First Generation Pressurized Excursion Module: Operational Concepts

We are building a prototype laboratory for preliminary examination of geological samples to be integrated into a first generation Habitat Demonstration Unit-1/Pressurized Excursion Module (HDU1-PEM) in 2010. The laboratory GeoLab will be equipped with a glovebox for handling samples, and a suite of instruments for collecting preliminary data to help characterize those samples. The GeoLab and the HDU1-PEM will be tested for the first time as part of the 2010 Desert Research and Technology Studies (DRATS), NASAs annual field exercise designed to test analog mission technologies. The HDU1-PEM and GeoLab will participate in joint operations in northern Arizona with two Lunar Electric Rovers (LER) and the DRATS science team. Historically, science participation in DRATS exercises has supported the technology demonstrations with geological traverse activities that are consistent with preliminary concepts for lunar surface science Extravehicular Activities (EVAs). Next years HDU1-PEM demonstration is a starting point to guide the development of requirements for the Lunar Surface Systems Program and test initial operational concepts for an early lunar excursion habitat that would follow geological traverses along with the LER. For the GeoLab, these objectives are specifically applied to enable future geological surface science activities. The goal of our GeoLab is to enhance geological science returns with the infrastructure that supports preliminary examination, early analytical characterization of key samples, insight into special considerations for curation, and data for prioritization of lunar samples for return to Earth.

Evans, C. A.↗

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↗

Autonomous Ocean World Exploration: Advancement of a Virtual Testbed

The search for life (extinct or extant) and potentially habitable bodies in our solar system and beyond is one of the 12 priority science questions outlined in the National Acadamies’ 2022 decadal survey [5]. Extraterrestrial destinations containing liquid water present an opportunity to search for life as we know it, and in recent years an increasing number of such locations have been discovered within our solar system. Several Jovian moons—Europa, Ganymede, and Callisto [10]—and the Saturnian moons Enceladus [8] and Titan [9] are known or suspected to harbor massive subsurface oceans. Of these "ocean worlds", Europa is the focus of at least one planned NASA orbiter mission, Europa Clipper [4], and an early lander mission concept, the Europa Lander [2, 3]. Whereas most robotic missions to the Moon and Mars (e.g. orbiters, rovers, landers) to date have had ground controllers on Earth tightly involved in mission operations, missions to more distant worlds will require a high degree of onboard autonomy due to long communication lags and blackouts, harsh environments (radiation, cold), and more limited battery and hardware life. The past decade has seen great advances in both AI technologies and computing scalability and performance that offer promising solutions for spacecraft autonomy and motivate the software system and research programs described in this paper. The Ocean Worlds Autonomy Testbed for Exploration, Research, and Simulation (OceanWATERS) [1], which has been in development at the NASA Ames Research Center since 2018, is a virtual environment for testing lander autonomy solutions. It is built on the Robot Operating System (ROS), runs on consumer-grade Linux workstations, and was released as open source in 2020. OceanWATERS provides a physical and visual simulation of a prototypical lander in a Europa-like environment (Figure 1). The lander was modeled after requirements and specifications made in JPL’s Europa Lander Study of 2016 [3]. Simulated lander systems include stereo cameras and spotlights mounted on an antenna mast that pans and tilts, a 6 degrees of freedom (DoF) robotic arm with a force-torque sensor and two interchangeable end effectors, and a battery pack power system. The environment consists of multiple terrain models including a highly detailed model sourced from the FROST dataset [11], simulation of surrounding planetary bodies based on an ephemeris model, and lighting from the sun with associated surface illumination, reflectance, and shadows. Operations supported by OceanWATERS include panoramic and directed imaging of the environment and lander workspace, Cartesian and joint-level arm commanding, grinding of the terrain surface (e.g. digging a trench), and scooping of ground material (Figure 2) which can be discarded or collected as science samples in a receptacle that can be emptied (science operations themselves are not simulated). These operations are realized as ROS Actions and are complimented by a wide selection of telemetry that is continually produced by each lander subsystem. The power system model is driven by the open-source Generic Software Architecture for Prognostics (GSAP) [11] that predicts the battery’s remaining useful life and other characteristics. As a testbed for high-level autonomy, OceanWATERS provides an execution framework based on PLEXIL [12], an open-source plan specification language and execution engine developed largely at Ames. NASA's initial development of OceanWATERS, as well the Ocean Worlds Lander Autonomy Testbed (OWLAT) [6], a complimentary physical testbed developed at JPL, was the first step in a plan for realizing candidate onboard autonomy solutions for such planetary landers. In 2020 NASA solicited applications for its Autonomous Robotics Research for Ocean Worlds (ARROW) program, and in 2021 the similar Concepts for Ocean worlds Life Detection Technology (COLDTech) program. Collectively six research teams, based in universities and companies across the United States, were awarded grants to develop and demonstrate autonomy solutions on OceanWATERS and OWLAT. These 1–2-year projects have now finished or are nearing completion, and a wide variety of autonomy challenges in ocean world surface missions were addressed. Prototyped and demonstrated solutions have included autonomous discovery, response and adaptation to system faults and unexpected environmental events, world model synthesis through perception, plan synthesis using learned models, methods to optimize sample target selection and prioritize science data transmission, extension of PLEXIL for stochastic decision-making, and an integration of a model of JPL’s mission-ready COLDArm [7]. Technologies used in these projects include many forms of machine learning, causal reasoning, automated planning, Markov decision processes, formal methods, and other advanced techniques. A more detailed summary of the ARROW and COLDTech projects is given herein. OceanWATERS has had significant enhancements since its open-source release in 2020. Many of its new features were driven or shaped by feedback from the ARROW and COLDTech teams and requirements of their projects. In support of enabling autonomous adaptation to spacecraft faults (a specific capability solicited by both programs), a fault injection and detection framework was developed that supports a wide and growing range of fault types such as locked joints, image loss, and battery failures. The power system model was completed and integrated into the simulator, starting as a single-cell battery model and later upgraded to a multi-cell model with associated faults such as cell disconnection. Arm/terrain interaction was improved by adding a force-torque sensor and associated faults, and an analytic dig force model based on the Balovnev bucket force equations. Environment fidelity was increased by modeling terrain deformation resulting from digging and scooping; visual improvements were made in textures, lighting, and shadows. To facilitate interoperation with OWLAT, a unified command and telemetry interface between the testbeds was developed at the ROS level, along with a PLEXIL interface. The number of lander operations was greatly expanded (e.g. with Cartesian-based arm and antenna movement), and a framework was designed for users to build their own lander actions. A GUI for PLEXIL plan selection was created (Figure 3), and an expansive set of plans were added, such as those that illustrate patterns for fault handling. This paper provides a self-contained high-level description of OceanWATERS, focusing on more detailed coverage of the aforementioned enhancements. It provides a high-level summary of the projects undertaken by participants in the ARROW and COLDTech programs and how these efforts have helped shape OceanWATERS. Finally, potential future work and directions for the testbed are listed, as likely informed by the recent planetary science decadal survey [5].

K Michael Dalal↗

Advanced Materials for the Lunar Surface: Multiscale Computational Design of Refractory Alloys and Carbides

Emerging operational environments, such as the lunar surface, present novel challenges for NASA and drive the need for advanced materials in applications like fission surface power systems. To address these demands, computational materials science is rapidly evolving to augment or replace costly and hazardous empirical testing. Although materials selection at NASA remains predominantly experimentally driven, advanced simulation methodologies are being steadily integrated into the engineering lifecycle. This work details the application of multiscale simulation techniques—including first-principles calculations, CALPHAD, dislocation dynamics, and molecular dynamics—at NASA's Ames Research Center to evaluate advanced materials for extreme environments. First, we present contributions to the Space Nuclear Propulsion Project. Be-cause propellant channel coatings in nuclear thermal rockets must withstand high-pressure, high-temperature hydro-gen, optimizing these materials is critical. First-principles calculations were employed to establish a rigorous quantitative and qualitative understanding of the behavior of the refractory carbides ZrC, NbC, and their mixtures in high-enthalpy hydrogen environments. This necessitated the generation of high-fidelity thermodynamic models for both stoichiometric and carbon-depleted carbides, both with and without the presence of hydrogen. Furthermore, we highlight efforts under the Refractory Alloy Additive Manufacturing Build Optimization (RAAMBO) project, where existing and novel alloy compositions were assessed for additive manufacturing printability and subsequent performance in applications such as heat pipes and rocket nozzle extensions. This was accomplished through a comprehensive multiscale simulation framework that bridged the gap from the nanometer to the millimeter scale. Across both initiatives, rigorous validation against empirical data was prioritized. By systematically employing a verified and validated computational frame-work, we demonstrate how simulation effectively supports multidisciplinary engineering efforts, builds project-wide confidence, and drives critical materials development.

computational materials↗

A study of TRIGLYCINE SULFATE (TGS) crystals from the International Microgravity Laboratory Mission (IML-1)

Preliminary evaluation of the data was made during the hologram processing procedure. A few representative holograms were selected and reconstructed in the HGS; photographs of sample particle images were made to illustrate the resolution of all three particle sizes. Based on these evaluations slight modifications were requested in the hologram processing procedure to optimize the hologram exposure in the vicinity of the crystal. Preliminary looks at the data showed that we are able to see and track all three sizes of particles throughout the chamber. Because of the vast amount of data available in the holograms, it was recommended that we produce a detailed data reduction plan with prioritization on the different types of data which can be extracted from the holograms.

Lal, R. B.↗

Data Management for Mars Exploration Rovers

Data Management for the Mars Exploration Rovers (MER) project is a comprehensive system addressing the needs of development, test, and operations phases of the mission. During development of flight software, including the science software, the data management system can be simulated using any POSIX file system. During testing, the on-board file system can be bit compared with files on the ground to verify proper behavior and end-to-end data flows. During mission operations, end-to-end accountability of data products is supported, from science observation concept to data products within the permanent ground repository. Automated and human-in-the-loop ground tools allow decisions regarding retransmitting, re-prioritizing, and deleting data products to be made using higher level information than is available to a protocol-stack approach such as the CCSDS File Delivery Protocol (CFDP).

Mars missions↗

Data management

The following tasks were prioritized: software acquisition management plan; space station flight data system architectural study; space station user data system interface; automation of software development process; automation of software testing; distributed data base management; ADA (automated data acquisition) evaluation and transition and planning; network operating system software; fault tolerant computer validation methodology for onboard data management system; systems integration; artificial intelligence/expert systems; space station data network concept; space station standard interface protocols; space station data networks systems; integrated software development facility; and language trade studies.

Love, G.↗

Onboard autonomy on the Three Corner Sat mission

In 2003, the student-built three satellite constellation Three Corner Sat (3CS) Mission will demonstrate onboard autonomy including: science data validation and prioritization, mission re-planning, and robust execution. Future observations will be planned onboard based on the quality of aquired science, available memory and power, and anticipated downlinks. These capabilities will allow 3CS to aquire additional science data if resources are available and to return only the highest quality science data.

Planning scheduling autonomy↗

Comparative Modeling Studies of Boreal Water and Carbon Balance

The coordination of the modeling and field efforts for an Intensive Field Campaign (IFC) may resemble the chicken and egg dilemma. This session's theme advocates that early and proactive involvement by modeling teams can produce a scientific and operational benefit for the IFC and Experiment. This talk will provide some examples and suggestions originating from the NASA funded IFC's of the FIFE First ISLSCP (International Satellite Land Surface Climatology Project) Field Experiment, Oregon Transect Ecosystem Research (OTTER) and predominately Boreal Ecosystem-Atmosphere Study (BOREAS) Experiments. In February 1994 and prior to the final selection of the BOREAS study sites, a group of funded BOREAS investigators agreed to run their models with data for five community types representing the proposed tower flux sites. All participating models were given identical initial values and boundary conditions and driven with identical climate data. The objectives of the intercomparison exercise were: 1) compare simulation results of participating terrestrial, hydrological, and atmospheric models over selected time frames; 2) learn about model behavior and sensitivity to estimated boreal site and vegetation definitions; 3) prioritize BOREAS field data collection efforts supporting modeling studies; 4) identify individual model deficiencies as early as possible. Out of these objectives evolved some important coordination and science issues for the BOREAS Experiment that can be generalized to IFCs and long term archiving of the data. Some problems are acceptable because they are endemic to maintaining fair and open competition prior to the peer review process. Others are logistical and addressable through application of planning, management, and information sciences. This investigator has identified one source of measurement and model incompatibility that is manifest in the IFC scaling approach. Although intuitively obvious, scaling problems are already more formally defined in the Geography literature. An example of the scaling problem will be demonstrated with Vegetation/Ecosystem Mapping and Analysis Project (VEMAP) and OTTER data.

Coughlan, J.↗

Space Physics Cosmic & Heliospheric Data Evaluation Panel Report

This Cosmic and Heliospheric (C&H) Data Evaluation Panel was charged with the task of identifying and prioritizing important C&H data sets. It was requested to provide C&H community input to the Space Physics Division for a program of revitalizing data holdings. Details and recommendations are provided. Highest C&H priority is assigned to Voyager, Pioneer, Helios, IMP-8, and ISEE-3 data.

Cosmic Heliospheric Data Archive Preservation Spac↗

Geographic science team

The rational for using remote sensing in land use/land cover, geomorphology, and cartography applications is stated as well as potential uses in each of these areas. The next step to be perfected is indicated. Spatial and spectral resolution requirements for photointerpretations and/or multispectral pattern recognition of geomorphic elements and of cultural surface cover are listed. Requirements for photographic/analog or digital photogrammetry from spaceborne multispectral linear array sensors are included. A prioritized summary of data gaps in the geographic sciences is included.

Bryant, N.↗

Smart Cameras for Remote Science Survey

Communication with remote exploration spacecraft is often intermittent and bandwidth is highly constrained. Future missions could use onboard science data understanding to prioritize downlink of critical features [1], draft summary maps of visited terrain [2], or identify targets of opportunity for followup measurements [3]. We describe a generic approach to classify geologic surfaces for autonomous science operations, suitable for parallelized implementations in FPGA hardware. We map these surfaces with texture channels - distinctive numerical signatures that differentiate properties such as roughness, pavement coatings, regolith characteristics, sedimentary fabrics and differential outcrop weathering. This work describes our basic image analysis approach and reports an initial performance evaluation using surface images from the Mars Exploration Rovers. Future work will incorporate these methods into camera hardware for real-time processing.

robotics↗

Data Needs for Stellar Atmosphere and Spectrum Modeling

The main data need for stellar atmosphere and spectrum modeling remains atomic and molecular transition data, particularly energy levels and transition cross-sections. We emphasize that data is needed for bound-free (b - f) as well as bound-bound (b - b), and collisional as well as radiative transitions. Data is now needed for polyatomic molecules as well as atoms, ions, and diatomic molecules. In addition, data for the formation of, and extinction due to, liquid and solid phase dust grains is needed. A prioritization of species and data types is presented, and gives emphasis to Fe group elements, and elements important for the investigation of nucleosynthesis and Galactic chemical evolution, such as the -elements and n-capture elements. Special data needs for topical problems in the modeling of cool stars and brown dwarfs are described.

Short, C. I.↗

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗

Advanced Communication Architectures and Technologies for Missions to the Outer Planets

Missions to the outer planets would be considerably enhanced by the implementation of a future space communication infrastructure that utilizes relay stations placed at strategic locations in the solar system. These relay stations would operate autonomously and handle remote mission command and data traffic on a prioritized demand access basis. Such a system would enhance communications from that of the current direct communications between the planet and Earth. The system would also provide high rate data communications to outer planet missions, clear communications paths during times when the sun occults the mission spacecraft as viewed from Earth, and navigational "lighthouses" for missions utilizing onboard autonomous operations. Additional information is contained in the original extended abstract.

Bhasin, K.↗

Prioritized LT Codes

The original Luby Transform (LT) coding scheme is extended to account for data transmissions where some information symbols in a message block are more important than others. Prioritized LT codes provide unequal error protection (UEP) of data on an erasure channel by modifying the original LT encoder. The prioritized algorithm improves high-priority data protection without penalizing low-priority data recovery. Moreover, low-latency decoding is also obtained for high-priority data due to fast encoding. Prioritized LT codes only require a slight change in the original encoding algorithm, and no changes at all at the decoder. Hence, with a small complexity increase in the LT encoder, an improved UEP and low-decoding latency performance for high-priority data can be achieved. LT encoding partitions a data stream into fixed-sized message blocks each with a constant number of information symbols. To generate a code symbol from the information symbols in a message, the Robust-Soliton probability distribution is first applied in order to determine the number of information symbols to be used to compute the code symbol. Then, the specific information symbols are chosen uniform randomly from the message block. Finally, the selected information symbols are XORed to form the code symbol. The Prioritized LT code construction includes an additional restriction that code symbols formed by a relatively small number of XORed information symbols select some of these information symbols from the pool of high-priority data. Once high-priority data are fully covered, encoding continues with the conventional LT approach where code symbols are generated by selecting information symbols from the entire message block including all different priorities. Therefore, if code symbols derived from high-priority data experience an unusual high number of erasures, Prioritized LT codes can still reliably recover both high- and low-priority data. This hybrid approach decides not only "how to encode" but also "what to encode" to achieve UEP. Another advantage of the priority encoding process is that the majority of high-priority data can be decoded sooner since only a small number of code symbols are required to reconstruct high-priority data. This approach increases the likelihood that high-priority data is decoded first over low-priority data. The Prioritized LT code scheme achieves an improvement in high-priority data decoding performance as well as overall information recovery without penalizing the decoding of low-priority data, assuming high-priority data is no more than half of a message block. The cost is in the additional complexity required in the encoder. If extra computation resource is available at the transmitter, image, voice, and video transmission quality in terrestrial and space communications can benefit from accurate use of redundancy in protecting data with varying priorities.

Woo, Simon S.↗

Obtaining and Using Planetary Spatial Data into the Future: The Role of the Mapping and Planetary Spatial Infrastructure Team (MAPSIT)

Planetary spatial data, which include any remote sensing data or derived products with sufficient positional information such that they can be projected onto a planetary body, continue to rapidly increase in volume and complexity. These data are the hard-earned fruits of decades of planetary exploration, and are the end result of mission planning and execution. Maintaining these data using accessible formats and standards for all scientists has been necessary for the success of past, present, and future planetary missions. The Mapping and Planetary Spatial Infrastructure Team (MAPSIT) is a group of planetary community members tasked by NASA Headquarters to work with the planetary science community to identify and prioritize their planetary spatial data needs to help determine the best pathways for new data acquisition, usable product derivation, and tools/capability development that supports NASA's planetary science missions.

Radebaugh, J.↗

Autonomous, Context-Sensitive, Task Management Systems and Decision Support Tools II: Contextual Constraints and Information Sources

Recent advances in artificial intelligence, machine learning, data mining and sensor technology have resulted in the availability of a vast amount of digital data and information and the development of advanced automated reasoners. This creates the opportunity for the development of a robust dynamic task manager and decision support tool that is context sensitive and integrates information from a wide array of on-board and off aircraft sourcesa tool that monitors systems and the overall flight situation, anticipates information needs, prioritizes tasks appropriately, keeps pilots well informed, and is nimble and able to adapt to changing circumstances. This is the second of two companion reports exploring issues associated with autonomous, context-sensitive, task management and decision support tools. In the first report, we explored fundamental issues associated with the development of such a system. In this report, we extend this work to focus on two critical aspects of these systems: 1) the constraints and conditions that drive the dynamic prioritization and presentation of data and information to the pilots, and 2) specific data and information to be accessed, monitored, integrated, and displayed in such a system.

context-sensitive↗