Search NASA⌕ Search

Engineering topics

Charles Baker

Publications and source records attributed to Charles Baker.

6 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2019

Constraining the Neutron Star Mass–Radius Relation and Dense Matter Equation of State with NICER. I. The Millisecond Pulsar X-Ray Data Set

We present the set of deep Neutron Star Interior Composition Explorer (NICER) X-ray timing observations of the nearby rotation-powered millisecond pulsars PSRs J0437−4715, J0030+0451, J1231−1411, and J2124−3358, selected as targets for constraining the mass–radius relation of neutron stars and the dense matter equation of state (EoS) via modeling of their pulsed thermal X-ray emission. We describe the instrument, observations, and data processing/reduction procedures, as well as the series of investigations conducted to ensure that the properties of the data sets are suitable for parameter estimation analyses to produce reliable constraints on the neutron star mass–radius relation and the dense matter EoS. We find that the long-term timing and flux behavior and the Fourier domain properties of the event data do not exhibit any anomalies that could adversely affect the intended measurements. From phase-selected spectroscopy, we find that emission from the individual pulse peaks is well described by a single-temperature hydrogen atmosphere spectrum, with the exception of PSR J0437−4715, for which multiple temperatures are required.

Neutron stars↗
NASA NTRSDate not supplied

Lessons Learned in Systems Engineering Availability and Recommendations for Mission Technical Leaders

In spaceflight missions at Goddard Space Flight Center (GSFC), the Mission System Engineer (MSE) is the technical leader of the overall engineering team and also is the Independent Engineering Technical Authority. The responsibility of this role includes the definition of the mission design architecture, concept of operations, and mission requirements, management of risk throughout the development, and verification and validation of the final system performance and function amongst other duties. This responsibility inherently requires time management, enabling focus on a balanced development with appropriate risk. Time is the most valuable resource of the MSE. The system engineer’s availability to interact with the development team (often product or component design leads and technicians, often in different worksites) to discover and mitigate mission risks during development is key to mission success. This paper presents examples from Lunar Reconnaissance Orbiter, Landsat 9, and Neutron star Interior Composition ExploreR (NICER) which represent in-house and out-of-house hardware builds. These examples demonstrate how interactions between the Mission Systems Engineers and other project and partner engineers result in discovery of critical risks, leading to early mitigation with significant cost and performance savings. These three missions would have suffered test failures or on-orbit failures had their MSEs not set aside time to visit engineers and technicians that were working on key pieces of space flight hardware. Availability is more than just time; it is openness to listen to concerns and questions. It begins by building a level of trust in the team that it is safe to ask questions or share concerns without the fear of blame or additional workload. It also requires enabling informal conversations (over lunch, coffee, in the clean room, or at the team members desk, etc.) where key information can be exchanged, and team members may even provide an easy-to-implement mitigation idea for another subsystem. Availability is a highly valuable commodity and completely non-obvious to protect and optimize. The natural tendency of engineers is to keep themselves busy with solving problems that they know about. This paper is encouraging MSEs to resist this tendency to try and solve all the complex problems themselves and actively devote daily time to learning and solving problems that are found with informal communications with other team members.

Lessons Learned↗
NASA NTRSDate not supplied

How Can We Efficiently Build A Spacecraft That Has Longevity? Experiences From the GSFC Perspective to Inform Lunar Exploration and Science Orbiter’s Architecture

Recent successes in NASA planetary science missions has shown that long-lived missions can yield significant science return. These missions, despite their longevity, were not planned to operate beyond their deign life. For example, the Lunar Reconnaissance Orbiter has a design life of 2-3 years, and yet we are entering its 14th year on orbit. Spacecraft longevity in practice has been related to: 1) mission class; 2) did we test it long enough and resolve all the anomalies to be beyond the early failure curve; 3) consumables budgets, and 4) how components are de-signed and tested. Mission class has been perceived as one of the primary ways to drive longevity. But higher mission class is a significant cost and mission driver. Parts selection only from the limited military standard parts and extensive parts qualification adds to development time and cost. Largely redundant (often erroneously interpreted as fully redundant) adds to launch mass and increases testing complexity (which may reduce the amount of testing in the nominal con-figuration). Lower Risk Posture (reflected in a higher mission class) drives significant additional processes and quality assurance analyses. Higher mission class also drives significantly greater sparing and life testing costs. This discussion focuses on whether this is indeed the best way to achieve longevity efficiently or whether there are more efficient ways to achieve longevity. Empirical evidence shows that lower mission classes that implement effective risk reduction and selective redundancy generally results in long life at a lower Spacecraft bus cost. By evaluating redundancy careful-ly, spacecraft cost can be lowered which can enable a more capable payload. Risk of the mission is highly dependent on the complexity of the mission and is only loosely dependent on Class of Mission. High complexity missions can have many single point failures and require the development of new technology, while lower class mission can have lower risk by baselining or incorporating: (selective) redundancy, fault-tolerant design, design for minimum risk, ability to reset, and/or design for graceful degradation. The team met with Goddard Space Flight Center Space Systems Mission Operations leaders to discuss which avionics have proven in flight to be the most reliable and which have had lifetime issues. The paper proposes a list of components to focus on for redundancy for a long-lived lunar mission. Reliability numbers are presented for both single string and dual string missions. The history of life-time performance versus planned mission life according to mission class is presented. A mission with well thought out selective redundancy and effective on the ground test program, can be expected to last well beyond its mission lifetime and provided enhanced return for the community. This approach minimizes project expenditures that do not retire significant risk and allows the project to focus risk mitigation efforts on those risks that will have a significant likelihood of threatening mission success. This is aided by keeping the amount of technology maturation and mission complexity low, while focusing effort on ensuring all component stress-ing parameters well within the bounds of their capabilities.

Lessons Learned↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer's Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer’s Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗