Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “hardware and software”

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 775 records · Page 43
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Global Precipitation Measurement (GPM) Safety Inhibit Timeline Tool

The Global Precipitation Measurement (GPM) Observatory is a joint mission under the partnership by National Aeronautics and Space Administration (NASA) and the Japan Aerospace Exploration Agency (JAXA), Japan. The NASA Goddard Space Flight Center (GSFC) has the lead management responsibility for NASA on GPM. The GPM program will measure precipitation on a global basis with sufficient quality, Earth coverage, and sampling to improve prediction of the Earth's climate, weather, and specific components of the global water cycle. As part of the development process, NASA built the spacecraft (built in-house at GSFC) and provided one instrument (GPM Microwave Imager (GMI) developed by Ball Aerospace) JAXA provided the launch vehicle (H2-A by MHI) and provided one instrument (Dual-Frequency Precipitation Radar (DPR) developed by NTSpace). Each instrument developer provided a safety assessment which was incorporated into the NASA GPM Safety Hazard Assessment. Inhibit design was reviewed for hazardous subsystems which included the High Gain Antenna System (HGAS) deployment, solar array deployment, transmitter turn on, propulsion system release, GMI deployment, and DPR radar turn on. The safety inhibits for these listed hazards are controlled by software. GPM developed a "pathfinder" approach for reviewing software that controls the electrical inhibits. This is one of the first GSFC in-house programs that extensively used software controls. The GPM safety team developed a methodology to document software safety as part of the standard hazard report. As part of this process a new tool "safety inhibit time line" was created for management of inhibits and their controls during spacecraft buildup and testing during 1& Tat GSFC and at the Range in Japan. In addition to understanding inhibits and controls during 1& T the tool allows the safety analyst to better communicate with others the changes in inhibit states with each phase of hardware and software testing. The tool was very useful for communicating compliance with safety requirements especially when working with a foreign partner.

Dion, Shirley↗
NASA NTRS2008

The First Development of Human Factors Engineering Requirements for Application to Ground Task Design for a NASA Flight Program

The National Aeronautics and Space Administration has long applied standards-derived human engineering requirements to the development of hardware and software for use by astronauts while in flight. The most important source of these requirements has been NASA-STD-3000. While there have been several ground systems human engineering requirements documents, none has been applicable to the flight system as handled at NASA's launch facility at Kennedy Space Center. At the time of the development of previous human launch systems, there were other considerations that were deemed more important than developing worksites for ground crews; e.g., hardware development schedule and vehicle performance. However, experience with these systems has shown that failure to design for ground tasks has resulted in launch schedule delays, ground operations that are more costly than they might be, and threats to flight safety. As the Agency begins the development of new systems to return humans to the moon, the new Constellation Program is addressing this issue with a new set of human engineering requirements. Among these requirements is a subset that will apply to the design of the flight components and that is intended to assure ground crew success in vehicle assembly and maintenance tasks. These requirements address worksite design for usability and for ground crew safety.

Dischinger, H. Charles, Jr.↗
NASA NTRS2010

BioNet Digital Communications Framework

BioNet v2 is a peer-to-peer middleware that enables digital communication devices to talk to each other. It provides a software development framework, standardized application, network-transparent device integration services, a flexible messaging model, and network communications for distributed applications. BioNet is an implementation of the Constellation Program Command, Control, Communications and Information (C3I) Interoperability specification, given in CxP 70022-01. The system architecture provides the necessary infrastructure for the integration of heterogeneous wired and wireless sensing and control devices into a unified data system with a standardized application interface, providing plug-and-play operation for hardware and software systems. BioNet v2 features a naming schema for mobility and coarse-grained localization information, data normalization within a network-transparent device driver framework, enabling of network communications to non-IP devices, and fine-grained application control of data subscription band width usage. BioNet directly integrates Disruption Tolerant Networking (DTN) as a communications technology, enabling networked communications with assets that are only intermittently connected including orbiting relay satellites and planetary rover vehicles.

Gifford, Kevin↗
NASA NTRS2017

NASA's Space Launch System: Systems Engineering Approach for Affordability and Mission Success

NASA is working toward the first launch of a new, unmatched capability for deep space exploration, with launch readiness planned for 2018. The initial Block 1 configuration of the Space Launch System will more than double the mass and volume to Low Earth Orbit (LEO) of any launch vehicle currently in operation - with a path to evolve to the greatest capability ever developed. The program formally began in 2011. The vehicle successfully passed Preliminary Design Review (PDR) in 2013, Key Decision Point C (KDPC) in 2014 and Critical Design Review (CDR) in October 2015 - nearly 40 years since the last CDR of a NASA human-rated rocket. Every major SLS element has completed components of test and flight hardware. Flight software has completed several development cycles. RS-25 hotfire testing at NASA Stennis Space Center (SSC) has successfully demonstrated the space shuttle-heritage engine can perform to SLS requirements and environments. The five-segment solid rocket booster design has successfully completed two full-size motor firing tests in Utah. Stage and component test facilities at Stennis and NASA Marshall Space Flight Center are nearing completion. Launch and test facilities, as well as transportation and other ground support equipment are largely complete at NASA's Kennedy, Stennis and Marshall field centers. Work is also underway on the more powerful Block 1 B variant with successful completion of the Exploration Upper Stage (EUS) PDR in January 2017. NASA's approach is to develop this heavy lift launch vehicle with limited resources by building on existing subsystem designs and existing hardware where available. The systems engineering and integration (SE&I) of existing and new designs introduces unique challenges and opportunities. The SLS approach was designed with three objectives in mind: 1) Design the vehicle around the capability of existing systems; 2) Reduce work hours for nonhardware/ software activities; 3) Increase the probability of mission success by focusing effort on more critical activities.

Hutt, John J.↗
NASA NTRS2016

Hexapod Robot

The project I am working on at NASA-Johnson Space Center in Houston, TX is a hexapod robot. This project was started by various engineers at the Trick Lab. The goal of this project is to have the hexapod track a yellow ball or possibly another object from left to right and up/down. The purpose is to have it track an object like a real creature. The project will consist of using software and hardware. This project started with a hexapod robot which uses a senor bar to track a yellow ball but with a limited field of vision. The sensor bar acts as the robots "head." Two servos will be added to the hexapod to create flexion and extension of the head. The neck and head servos will have to be programmed to be added to the original memory map of the existing servos. I will be using preexisting code. The main programming language that will be used to add to the preexisting code is C++. The trick modeling and simulation software will also be used in the process to improve its tracking and movement. This project will use a trial and error approach, basically seeing what works and what does not. The first step is to initially understand how the hexapod works. To get a general understanding of how the hexapod maneuvers and plan on how to had a neck and head servo which works with the rest of the body. The second step would be configuring the head and neck servos with the leg servos. During this step, limits will be programmed specifically for the each servo. By doing this, the servo is limited to how far it can rotate both clockwise and counterclockwise and this is to prevent hardware damage. The hexapod will have two modes in which it works in. The first mode will be if the sensor bar does not detect an object. If the object it is programmed to look for is not in its view it will automatically scan from left to right 3 times then up and down once. The second mode will be if the sensor bar does detect the object. In this mode the hexapod will track the object from left to right or up and down. The hexapod will eventually be able to track the object moving its head and body in sync with on another and being able to rotate its body at 360 degrees. This is the plans and possible end results for the hexapod robot I will be working on during my summer internship at NASA Johnson Space Center. Since working on the hexapod project I have gained an increase interest in robotics. I enjoy the process of critical thinking. Also will working on this project I was challenged in a way that made more passionate to strive even more to become an engineer. I've learned that asking questions is an important part of the learning process. Also I learn that much more is accomplished when teamwork is applied.

Begody, Ericka↗
NASA NTRSDate not supplied

Low SWaP Onboard Satellite Navigation, Guidance, and Control Technology

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The first build of autoNGC, providing autonomous navigation for lunar orbiting spacecraft, is targeted for completion by Fall 2024. It provides sensor fusion of multiple measurement types including pseudo-range from a weak signal Global Navigation Satellite Service (GNSS) receiver, 1-way and 2-way direct to Earth (DTE) range and Doppler, bearing and range from optical camera sensed images, and an accelerometer. AutoNGC is also being targeted for future missions that involve small body proximity operations, Sun Earth Libration point orbits, and distributed systems missions (DSMs) including those at outer planets. AutoNGC flight software is being built upon the plug-and-play architecture of the core Flight System (cFS) [Ref. 1]. Figure (Slide 7) shows the message-based software bus layout of various software applications (“apps”) consisting of the standard cFS apps and autoNGC interface apps and libraries. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library [Ref. 2], which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are provided by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app [Ref. 3]. This app processes optical images to extract the bearing angles of the centroid of the imaged body (near or far), the range to the imaged body, and/or of the features on the surface of a body to perform terrain relative navigation (TRN). Measurement of range to the body’s center of mass can also be derived from the detection of the limb. The first build of autoNGC for a lunar orbiting spacecraft is a minimal size, weight, and power (SWaP) hardware design allowing for inclusion into CubeSats and SmallSat-size class buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z [Ref. 4] are utilized for low SWaP while maintaining a high level of performance. Figure (Slide 11) shows the composition of the first autoNGC build. The current enclosure design has dimensions 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. The hardware interfaces are designed for flexibility with a variety of sensor inputs. The achievable navigation performance depends on the sensors utilized, including the onboard clock for 1-way pseudo-range measurements. Analysis using a configuration that consists of weak signal GPS, TRN, and 1-way DTE has shown position and velocity accuracies of 10 meters and 2 cm/s (3-σ ) RSS, respectively, with onboard time knowledge estimated to better than 13 ns (3-σ ), for a spacecraft in a representative 12-hour eccentric lunar orbit. Other measurement types such as x-rays from known pulsars (called XNAV) and cross-links can also be processed in GEONS. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced, even after launch. Goddard is actively seeking partners to collaborate in the development of additional capabilities for autoNGC, including industry, academia, and others across the US Government. Plans are being formulated to make the autoNGC software platform available for use by any US government organization to leverage the non-recurring engineering associated with the development of onboard autonomous NGC 3 capabilities. As advancements in space qualified sensors, microprocessors, and algorithms are made, the autoNGC platform provides a ready starting point for inclusion of these technologies.

C. J. Gramling↗
NASA NTRS2003

Developing Generic Software for Spacecraft Avionics

A proposed approach to the development of software for spacecraft avionics is based partly on a concept of generic software that could be tailored to satisfy requirements for specific missions. The proposed approach would stand in contrast to the conventional approach of first defining avionics requirements for a specific mission, then developing software specific to those requirements. The proposed approach might also be adaptable to programming computers that control and monitor other complex equipment systems that range in scale from automobiles to factories. The concept of a spacecraft avionics functional model (SAFM) is a major element of the proposed approach. An SAFM would be, essentially, a systematic and hierarchical description of the functionality required of the avionics software (and hardware) for a given mission. Although the initial input information used to start the construction of an SAFM would typically amount to a high-level description, the SAFM would thereafter be decomposed to a low level. The resulting low-level version of the model would be used to develop a set of generic requirements that could be expected to include a large fraction of all requirements for a large fraction of all missions. The generic requirements would be used to develop software modules that could be included in, or excluded from, the final flight software to satisfy the requirements of a specific mission.

Smith, Joseph↗
NASA NTRS1996

Software Development Technologies for Reactive, Real-Time, and Hybrid Systems

The research is directed towards the design and implementation of a comprehensive deductive environment for the development of high-assurance systems, especially reactive (concurrent, real-time, and hybrid) systems. Reactive systems maintain an ongoing interaction with their environment, and are among the most difficult to design and verify. The project aims to provide engineers with a wide variety of tools within a single, general, formal framework in which the tools will be most effective. The entire development process is considered, including the construction, transformation, validation, verification, debugging, and maintenance of computer systems. The goal is to automate the process as much as possible and reduce the errors that pervade hardware and software development.

Manna, Zohar↗
NASA NTRSDate not supplied

Towards Gbps Downlinks from Low-Cost Active Phased Arrays

Spacecraft performing science missions use high-directivity antennas to quickly downlink large amounts of collected data. Movement required to keep gimbaled reflector antennas trained on target receivers can impart blockages or vibrations which perturb precision science instruments. Recent manufacturing advances have made Ka-band electronically-steered antenna arrays a cost-effective option to mitigate these challenges, but only if these devices can be proven to deliver comparable quality of service. In this work we present a hardware and software architecture for high-rate links using an active phased array-based terminal in a 1U (10cm cube) form factor. Over-the-air tests in an antenna range characterize two key features of the architecture: high-order (32APSK and above) modulations and dual carriers. We calculate an optimal modulation-dependent input power backoff from array saturation and perform orbital simulations of the link at this operating point. We conclude that reliable links with rates in excess of 1Gbps are possible with current-generation hardware.

Adam Gannon↗
NASA NTRS2012

Spacecraft Avionics Software Development Then and Now: Different but the Same

NASA has always been in the business of balancing new technologies and techniques to achieve human space travel objectives. NASA s historic Software Production Facility (SPF) was developed to serve complex avionics software solutions during an era dominated by mainframes, tape drives, and lower level programming languages. These systems have proven themselves resilient enough to serve the Shuttle Orbiter Avionics life cycle for decades. The SPF and its predecessor the Software Development Lab (SDL) at NASA s Johnson Space Center (JSC) hosted flight software (FSW) engineering, development, simulation, and test. It was active from the beginning of Shuttle Orbiter development in 1972 through the end of the shuttle program in the summer of 2011 almost 40 years. NASA s Kedalion engineering analysis lab is on the forefront of validating and using many contemporary avionics HW/SW development and integration techniques, which represent new paradigms to NASA s heritage culture in avionics software engineering. Kedalion has validated many of the Orion project s HW/SW engineering techniques borrowed from the adjacent commercial aircraft avionics environment, inserting new techniques and skills into the Multi-Purpose Crew Vehicle (MPCV) Orion program. Using contemporary agile techniques, COTS products, early rapid prototyping, in-house expertise and tools, and customer collaboration, NASA has adopted a cost effective paradigm that is currently serving Orion effectively. This paper will explore and contrast differences in technology employed over the years of NASA s space program, due largely to technological advances in hardware and software systems, while acknowledging that the basic software engineering and integration paradigms share many similarities.

Mangieri, Mark L.↗
NASA NTRS1998

X2000 Flight Missions Utilizing Common Modular Components

A software and hardware architecture was developed for the X2000 bus that is modular, scaleable, and upgradable. It will enable the procurement of highly capable, low mass flight systems that can perform the mission set at a low recurring cost for the X2000 bus or components of the bus that are used for each mission

Flight↗
NASA NTRS2007

Automated Detection of Events of Scientific Interest

A report presents a slightly different perspective of the subject matter of Fusing Symbolic and Numerical Diagnostic Computations (NPO-42512), which appears elsewhere in this issue of NASA Tech Briefs. Briefly, the subject matter is the X-2000 Anomaly Detection Language, which is a developmental computing language for fusing two diagnostic computer programs one implementing a numerical analysis method, the other implementing a symbolic analysis method into a unified event-based decision analysis software system for real-time detection of events. In the case of the cited companion NASA Tech Briefs article, the contemplated events that one seeks to detect would be primarily failures or other changes that could adversely affect the safety or success of a spacecraft mission. In the case of the instant report, the events to be detected could also include natural phenomena that could be of scientific interest. Hence, the use of X- 2000 Anomaly Detection Language could contribute to a capability for automated, coordinated use of multiple sensors and sensor-output-data-processing hardware and software to effect opportunistic collection and analysis of scientific data.

James, Mark↗
NASA NTRS2006

Solar Sails

The Solar Sail Propulsion investment area has been one of the three highest priorities within the In-Space Propulsion Technology (ISPT) Project. In the fall of 2003, the NASA Headquarters' Science Mission Directorate provided funding and direction to mature the technology as far as possible through ground research and development from TRL 3 to 6 in three years. A group of experts from government, industry, and academia convened in Huntsville, Alabama to define technology gaps between what was needed for science missions to the inner solar system and the current state of the art in ultra1ightweight materials and gossamer structure design. This activity set the roadmap for development. The centerpiece of the development would be the ground demonstration of scalable solar sail systems including masts, sails, deployment mechanisms, and attitude control hardware and software. In addition, new materials would be subjected to anticipated space environments to quantify effects and assure mission life. Also, because solar sails are huge structures, and it is not feasible to validate the technology by ground test at full scale, a multi-discipline effort was established to develop highly reliable analytical models to serve as mission assurance evidence in future flight program decision-making. Two separate contractor teams were chosen to develop the SSP System Ground Demonstrator (SGD). After a three month conceptual mission/system design phase, the teams developed a ten meter diameter pathfinder set of hardware and subjected it to thermal vacuum tests to compare analytically predicted structural behavior with measured characteristics. This process developed manufacturing and handling techniques and refined the basic design. In 2005, both contractor teams delivered 20 meter, four quadrant sail systems to the largest thermal vacuum chamber in the world in Plum Brook, Ohio, and repeated the tests. Also demonstrated was the deployment and articulation of attitude control mechanisms. In conjunction with these tests, the stowed sails were subjected to launch vibration and ascent vent tests. Other investments studied radiation effects on the solar sail materials, investigated spacecraft charging issues, developed shape measuring techniques and instruments, produced advanced trajectory modeling capabilities, and identified and resolved gossamer structure dynamics issues. Technology validation flight and application to a He1iophysics science mission is on the horizon.

Young, Roy↗
NASA NTRS1993

NASA trend analysis procedures

This publication is primarily intended for use by NASA personnel engaged in managing or implementing trend analysis programs. 'Trend analysis' refers to the observation of current activity in the context of the past in order to infer the expected level of future activity. NASA trend analysis was divided into 5 categories: problem, performance, supportability, programmatic, and reliability. Problem trend analysis uncovers multiple occurrences of historical hardware or software problems or failures in order to focus future corrective action. Performance trend analysis observes changing levels of real-time or historical flight vehicle performance parameters such as temperatures, pressures, and flow rates as compared to specification or 'safe' limits. Supportability trend analysis assesses the adequacy of the spaceflight logistics system; example indicators are repair-turn-around time and parts stockage levels. Programmatic trend analysis uses quantitative indicators to evaluate the 'health' of NASA programs of all types. Finally, reliability trend analysis attempts to evaluate the growth of system reliability based on a decreasing rate of occurrence of hardware problems over time. Procedures for conducting all five types of trend analysis are provided in this publication, prepared through the joint efforts of the NASA Trend Analysis Working Group.

Source record↗
NASA NTRS1990

The Jet Propulsion Laboratory shared control architecture and implementation

A hardware and software environment for shared control of telerobot task execution has been implemented. Modes of task execution range from fully teleoperated to fully autonomous as well as shared where hand controller inputs from the human operator are mixed with autonomous system inputs in real time. The objective of the shared control environment is to aid the telerobot operator during task execution by merging real-time operator control from hand controllers with autonomous control to simplify task execution for the operator. The operator is the principal command source and can assign as much autonomy for a task as desired. The shared control hardware environment consists of two PUMA 560 robots, two 6-axis force reflecting hand controllers, Universal Motor Controllers for each of the robots and hand controllers, a SUN4 computer, and VME chassis containing 68020 processors and input/output boards. The operator interface for shared control, the User Macro Interface (UMI), is a menu driven interface to design a task and assign the levels of teleoperated and autonomous control. The operator also sets up the system monitor which checks safety limits during task execution. Cartesian-space degrees of freedom for teleoperated and/or autonomous control inputs are selected within UMI as well as the weightings for the teleoperation and autonmous inputs. These are then used during task execution to determine the mix of teleoperation and autonomous inputs. Some of the autonomous control primitives available to the user are Joint-Guarded-Move, Cartesian-Guarded-Move, Move-To-Touch, Pin-Insertion/Removal, Door/Crank-Turn, Bolt-Turn, and Slide. The operator can execute a task using pure teleoperation or mix control execution from the autonomous primitives with teleoperated inputs. Presently the shared control environment supports single arm task execution. Work is presently underway to provide the shared control environment for dual arm control. Teleoperation during shared control is only Cartesian space control and no force-reflection is provided. Force-reflecting teleoperation and joint space operator inputs are planned extensions to the environment.

Backes, Paul G.↗
NASA NTRS2011

International Space Station (ISS) Risk Reduction Activities

As the assembly of the ISS nears completion, it is worthwhile to step back and review some of the actions pursued by the Program in recent years to reduce risk and enhance the safety and health of ISS crewmembers, visitors, and space flight participants. While the ISS requirements and initial design were intended to provide the best practicable levels of safety, it is always possible to reduce risk -- given the determination and commitment to do so. The following is a summary of some of the steps taken by the ISS Program Manager, by our International Partners, by hardware and software designers, by operational specialists, and by safety personnel to continuously enhance the safety of the ISS. While decades of work went into developing the ISS requirements, there are many things in a Program like the ISS that can only be learned through actual operational experience. These risk reduction activities can be divided into roughly three categories: (1) Areas that were initially noncompliant which have subsequently been brought into compliance or near compliance (i.e., Micrometeoroid and Orbital Debris [MMOD] protection, acoustics) (2) Areas where initial design requirements were eventually considered inadequate and were subsequently augmented (i.e., Toxicity Level 4 materials, emergency hardware and procedures) (3) Areas where risks were initially underestimated, and have subsequently been addressed through additional mitigation (i.e., Extravehicular Activity [EVA] sharp edges, plasma shock hazards) Due to the hard work and cooperation of many parties working together across the span of nearly a decade, the ISS is now a safer and healthier environment for our crew, in many cases exceeding the risk reduction targets inherent in the intent of the original design. It will provide a safe and stable platform for utilization and discovery.

Fodroci, Michael↗
NASA NTRSDate not supplied

X-57 Traction Power and Command Systems Development

This paper describes the final, as-built design of the X‑57 Maxwell aircraft power and command system architecture that implements the electrified propulsion capability. The development of the traction power, command, and avionics power subsystems proceeded as planned at the initial project critical design review, but improvements to the design were identified following the development of detailed operations concepts and integrated subsystem and system testing. The redundant architecture with A‑side and B‑side buses provided a robust framework for a developmental system that would turn out to have a lower technology readiness than had been assumed upon project formulation. As the project team identified reliability or performance gaps in the electrified propulsion powertrain components and their interactions with the other vehicle systems, the traction power, command, and avionics architectures were modified to accommodate the modified systems. Following the publication of the planned design approach at the critical design review milestone [1], the project team developed the flight hardware and software, integrated the systems, and adjusted the design and qualification activities to address gaps in the components, system architecture, and requirements as the gaps were realized. In addition to inherent challenges in development of these subsystems, the integration of this new technology with adjacent critical systems in an aircraft configuration posed additional challenges that drove design considerations across the subsystem development and the other vehicle systems. Integration complications included electromagnetic compatibility, thermal performance, and tolerance of single-point failures internal and external to the powerplant. Development of a qualification program was required for the new motors, inverters, and batteries, and hardware performance during component qualification fed back into the development process and led lessons learned and redesign of key elements.

distributed propulsion↗
NASA NTRS1990

What can formal methods offer to digital flight control systems design

Formal methods research begins to produce methods which will enable mathematic modeling of the physical behavior of digital hardware and software systems. The development of these methods directly supports the NASA mission of increasing the scope and effectiveness of flight system modeling capabilities. The conventional, continuous mathematics that is used extensively in modeling flight systems is not adequate for accurate modeling of digital systems. Therefore, the current practice of digital flight control system design has not had the benefits of extensive mathematical modeling which are common in other parts of flight system engineering. Formal methods research shows that by using discrete mathematics, very accurate modeling of digital systems is possible. These discrete modeling methods will bring the traditional benefits of modeling to digital hardware and hardware design. Sound reasoning about accurate mathematical models of flight control systems can be an important part of reducing risk of unsafe flight control.

Good, Donald I.↗