Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “auditing”

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 289 records · Page 16

Security Data Warehouse Application

The Security Data Warehouse (SDW) is used to aggregate and correlate all JSC IT security data. This includes IT asset inventory such as operating systems and patch levels, users, user logins, remote access dial-in and VPN, and vulnerability tracking and reporting. The correlation of this data allows for an integrated understanding of current security issues and systems by providing this data in a format that associates it to an individual host. The cornerstone of the SDW is its unique host-mapping algorithm that has undergone extensive field tests, and provides a high degree of accuracy. The algorithm comprises two parts. The first part employs fuzzy logic to derive a best-guess host assignment using incomplete sensor data. The second part is logic to identify and correct errors in the database, based on subsequent, more complete data. Host records are automatically split or merged, as appropriate. The process had to be refined and thoroughly tested before the SDW deployment was feasible. Complexity was increased by adding the dimension of time. The SDW correlates all data with its relationship to time. This lends support to forensic investigations, audits, and overall situational awareness. Another important feature of the SDW architecture is that all of the underlying complexities of the data model and host-mapping algorithm are encapsulated in an easy-to-use and understandable Perl language Application Programming Interface (API). This allows the SDW to be quickly augmented with additional sensors using minimal coding and testing. It also supports rapid generation of ad hoc reports and integration with other information systems.

Vernon, Lynn R.↗

Multimodal information Management: Evaluation of Auditory and Haptic Cues for NextGen Communication Displays

Auditory communication displays within the NextGen data link system may use multiple synthetic speech messages replacing traditional ATC and company communications. The design of an interface for selecting amongst multiple incoming messages can impact both performance (time to select, audit and release a message) and preference. Two design factors were evaluated: physical pressure-sensitive switches versus flat panel "virtual switches", and the presence or absence of auditory feedback from switch contact. Performance with stimuli using physical switches was 1.2 s faster than virtual switches (2.0 s vs. 3.2 s); auditory feedback provided a 0.54 s performance advantage (2.33 s vs. 2.87 s). There was no interaction between these variables. Preference data were highly correlated with performance.

Begault, Durand R.↗

Configuration Management Process Assessment Strategy

Purpose: To propose a strategy for assessing the development and effectiveness of configuration management systems within Programs, Projects, and Design Activities performed by technical organizations and their supporting development contractors. Scope: Various entities CM Systems will be assessed dependent on Project Scope (DDT&E), Support Services and Acquisition Agreements. Approach: Model based structured against assessing organizations CM requirements including best practices maturity criteria. The model is tailored to the entity being assessed dependent on their CM system. The assessment approach provides objective feedback to Engineering and Project Management of the observed CM system maturity state versus the ideal state of the configuration management processes and outcomes(system). center dot Identifies strengths and risks versus audit gotcha's (findings/observations). center dot Used "recursively and iteratively" throughout program lifecycle at select points of need. (Typical assessments timing is Post PDR/Post CDR) center dot Ideal state criteria and maturity targets are reviewed with the assessed entity prior to an assessment (Tailoring) and is dependent on the assessed phase of the CM system. center dot Supports exit success criteria for Preliminary and Critical Design Reviews. center dot Gives a comprehensive CM system assessment which ultimately supports configuration verification activities.*

Henry, Thad↗

Analysis of Space Station Centrifuge Rotor Bearing Systems: A Case Study

A team of NASA bearing and lubrication experts was assembled to assess the risk for the rolling-element bearings used in the International Space Station (ISS) centrifuge rotor (CR) to seize or otherwise fail to survive for the required 10-year life. The CR was designed by the Japan Aerospace Exploration Agency and their subcontractor, NEC Toshiba Space Systems, Ltd. (NTSpace). The NASA team performed a design audit for the most critical rolling-element bearing systems and reviewed the lubricant selected. There is uncertainty regarding the ability of the Braycote 601 grease (Castrol Limited) to reliably provide the 10-year continuous life required without relubrication of the system. The fatigue life of the Rotor Shaft Assembly (RSA) spring loaded face-to-face mount at a 99-percent probability of survival (L1 life) for the ball bearing set was estimated at 700 million hours and the single ball bearing (Row 3) at 58 million hours. These lives satisfy the mission requirements for fatigue. Rolling-element seizure tests on the RSA and fluid slip joint bearings were found unlikely to stop the centrifuge, which can cause damage to the ISS structure. The spin motor encoder duplex angular-contact ball bearings have a hard preload and a large number of small balls have the highest risk of failure. These bearings were not tested for seizure even though they are less tolerant to debris or internal clearance reductions.

Poplawski, Joseph V.↗

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗

IT Security Support for the Spaceport Command Control System Development

My job title is IT Security support for the Spaceport Command & Control System Development. As a cyber‐security analyst it is my job to ensure NASA's information stays safe from cyber threats, such as, viruses, malware and denial-of-service attacks by establishing and enforcing system access controls. Security is very important in the world of technology and it is used everywhere from personal computers to giant networks ran by Government agencies worldwide. Without constant monitoring analysis, businesses, public organizations and government agencies are vulnerable to potential harmful infiltration of their computer information system. It is my responsibility to ensure authorized access by examining improper access, reporting violations, revoke access, monitor information request by new programming and recommend improvements. My department oversees the Launch Control System and networks. An audit will be conducted for the LCS based on compliance with the Federal Information Security Management Act (FISMA) and The National Institute of Standards and Technology (NIST). I recently finished analyzing the SANS top 20 critical controls to give cost effective recommendations on various software and hardware products for compliance. Upon my completion of this internship, I will have successfully completed my duties as well as gain knowledge that will be helpful to my career in the future as a Cyber Security Analyst.

IT Security↗

Cassini Mission Sequence Subsystem (MSS)

This paper describes my work with the Cassini Mission Sequence Subsystem (MSS) team during the summer of 2011. It gives some background on the motivation for this project and describes the expected benefit to the Cassini program. It then introduces the two tasks that I worked on - an automatic system auditing tool and a series of corrections to the Cassini Sequence Generator (SEQ_GEN) - and the specific objectives these tasks were to accomplish. Next, it details the approach I took to meet these objectives and the results of this approach, followed by a discussion of how the outcome of the project compares with my initial expectations. The paper concludes with a summary of my experience working on this project, lists what the next steps are, and acknowledges the help of my Cassini colleagues.

solstice mission↗

Technology Infusion Challenges from a Decision Support Perspective

In a restricted science budget environment and increasingly numerous required technology developments, the technology investment decisions within NASA are objectively more and more difficult to make such that the end results are satisfying the technical objectives and all the organizational constraints. Under these conditions it is rationally desirable to build an investment portfolio, which has the highest possible technology infusion rate. Arguably the path to infusion is subject to many influencing factors, but here only the challenges associated with the very initial stages are addressed: defining the needs and the subsequent investment decision-support process. It is conceivable that decision consistency and possibly its quality suffer when the decision-making process has limited or no traceability. This paper presents a structured decision-support framework aiming to provide traceable, auditable, infusion- driven recommendations towards a selection process in which these recommendations are used as reference points in further discussions among stakeholders. In this framework addressing well-defined requirements, different measures of success can be defined based on traceability to specific selection criteria. As a direct result, even by using simplified decision models the likelihood of infusion can be probed and consequently improved.

Adumitroaie, V.↗

Early Operations Flight Correlation of the Lunar Laser Communications Demonstration (LLCD) on the Lunar Atmosphere and Dust Environment Explorer (LADEE)

The Lunar Atmosphere and Dust Environment Explorer (LADEE) mission launched on September 7, 2013 with a one month cruise before lunar insertion. The LADEE spacecraft is a power limited, octagonal, composite bus structure with solar panels on all eight sides with four vertical segments per side and 2 panels dedicated to instruments. One of these panels has the Lunar Laser Communications Demonstration (LLCD), which represents a furthering of the laser communications technology demonstration proved out by the Lunar Reconnaissance Orbiter (LRO). LLCD increases the bandwidth of communication to and from the moon with less mass and power than LROs technology demonstrator. The LLCD Modem and Controller boxes are mounted to an internal cruciform composite panel and have no dedicated radiator. The thermal design relies on power cycling of the boxes and radiation of waste heat to the inside of the panels, which then reject the heat when facing cold space. The LADEE mission includes a slow roll and numerous attitudes to accommodate the challenging thermal requirements for all the instruments on board. During the cruise phase, the internal Modem and Controller avionics for LLCD were warmer than predicted by more than modeling uncertainty would suggest. This caused concern that if the boxes were considerably warmer than expected while off, they would also be warmer when operating and could limit the operational time when in lunar orbit. The thermal group at Goddard Space Flight Center evaluated the models and design for these critical avionics for LLCD. Upon receipt of the spacecraft models and audit was performed and data was collected from the flight telemetry to perform a sanity check of the models and to correlate to flight where possible. This paper describes the efforts to correlate the model to flight data and to predict the thermal performance when in lunar orbit and presents some lessons learned.

LADEE↗

Radio Frequency Identification for Space Habitat Inventory and Stowage Allocation Management

To date, the most extensive space-based inventory management operation has been the International Space Station (ISS). Approximately 20,000 items are tracked with the Inventory Management System (IMS) software application that requires both flight and ground crews to update the database daily. This audit process is manually intensive and laborious, requiring the crew to open cargo transfer bags (CTBs), then Ziplock bags therein, to retrieve individual items. This inventory process contributes greatly to the time allocated for general crew tasks.

Wagner, Carole Y.↗

The Use of UML for Software Requirements Expression and Management

It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.

model-based engineering↗

NASA Human Spaceflight Scenarios - Do All Our Models Still Say No?

Historically, NASA human spaceflight planning has included healthy doses of life cycle cost analysis. Planners put projects and their cost estimates in a budget context. Estimated costs became expected budgets. Regardless, real budgets rarely matched expectations. So plans would come and go as NASA canceled projects. New projects would arise and the cycle would begin again. Repeatedly, NASA schedule and performance ambitions come up against costs growing at double-digit rates while budgets barely rise a couple of percent a year. Significant skepticism greets proposed NASA programs at birth, as cost estimates for new projects are traditionally very high, and worse, far off the mark for those carried forward. In this environment the current "capability driven framework" for NASA human spaceflight evolved, where long term life cycle cost analysis are even viewed as possibly counter-productive. Here, a space exploration project, for example the Space Launch System, focuses on immediate goals. A life cycle is that of a project, not a program, and for only that span of time to a near term milestone like a first test launch. Unfortunately, attempting to avoid some pitfalls in long-term life cycle cost analysis breeds others. Government audits have noted that limiting the scope of cost analysis "does not provide the transparency necessary to assess long-term affordability" making it difficult to understand if NASA "is progressing in a cost-effective and affordable manner." Even in this short-term framework, NASA realizes the importance of long-term considerations, that it must "maximize the efficiency and sustainability of the Exploration Systems development programs", that this is "critical to free resources for re-investment...such as other required deep space exploration capabilities." Assuming the value of long-term life cycle cost analysis, where due diligence meets reconnaissance, and accepting past shortcomings, the work here approaches life cycle cost analysis for human spaceflight differently. 1) If costs have traditionally been so high that adding them up is discouraging, are there any new facts on the ground offering paths to significantly lower costs? 2) If NASA's spaceflight budget and process is an over-arching constraint, with its planning limitations favoring short-term outlooks, is there a way to step outside the budget box? 3) If life cycle answers have historically been too uncertain to be useful, is there a process where stakeholders gain valuable insights merely from emphasizing a common understanding around questions? We analyze the potential life cycle cost of assorted NASA human spaceflight architectures - an architecture as a sum of individual systems, working together. With the prior questions of high costs, limited budgets and uncertainties in mind, public private partnerships are central in these architectures. The cost data for current commercial public private partnerships is encouraging, as are cost estimates for future partnership approaches beyond low Earth orbit. Private capital, directly or indirectly, an ingredient of public private partnerships, may be a significant factor in finding a path around the limits of the NASA spaceflight budget. Also, understanding and reviewing the pros, cons and uncertainties of assorted architectures can assist in developing a common understanding around key questions as important if not more so than the numbers and answers. Lastly, a scenario planning technique is briefly explored that can mature a common understanding about the agencies situation at hand and how diverse stakeholders can go forward together. Scenario planning, rather than focusing on answers, places emphasis on stakeholders developing a common understanding about the future. Putting aside costs, this is especially true of questions about sustainability and growth, results, benefits and expectations. While efficiency exercises or analysis look to reduce resources in one place to apply them elsewhere, moving around slices in a pie, scenario planning can get at the heart of the matter, growing the pie, transforming it, and making the pieces relevant. Especially important is the question of sustainability for different scenarios in the broad sense of the word - not just the narrow ability to survive or continue, but also the ability to adapt, prosper and grow.

space systems life cycle costs↗

Commercial Off-The-Shelf (COTS) Parts Risk and Reliability User and Application Guide

All COTS parts are not created equal. Because they are not created equal, the notion that one can force the commercial industry to follow a set of military specifications and standards, along with the certifications, audits and qualification commitments that go with them, is unrealistic for the sale of a few parts. The part technologies that are Defense Logistics Agency (DLA) certified or Military Specification (MS) qualified, are several generations behind the state-of-the-art high-performance parts that are required for the compact, higher performing systems for the next generation of spacecraft and instruments. The majority of the part suppliers are focused on the portion of the market that is producing high-tech commercial products and systems. To that end, in order to compete in the high performance and leading edge advanced technological systems, an alternative approach to risk assessment and reliability prediction must be considered.

White, Mark↗

Agency Agreements Process Champion Support Intern

This document will provide information on the 2018 Spring semester NIFS Intern who represented the Office of Chief Financial Officer (OCFO) as a Reimbursable Accountant at Kennedy Space Center (KSC). This intern supported the Agency Agreements Process Champions and Team Lead, Susan Kroskey, Sandy Massey and Mecca Murphy, with major initiatives to advance the KSC OCFO's vision of creating and innovating healthy financial management practices that maximize the value of resources entrusted to NASA. These initiatives include, but are not limited to: updating the Agency Guidance and NASA Procedural Guidance 9090.1 Agreements, implementing a new budget structure to be utilized across all centers, submitting a Call Request (CRQ) to enhance non-federal customer reporting, initiating a discussion to incorporate a 3-year funding program for NASA agreements, and undertaking the Office of Inspector General (OIG) Audit. In support of these initiatives, this intern identified technical methods to enhance and reduce the workload of financial processes for reimbursable and non-reimbursable agreements, prepared reports in support of accounting functions, and performed administrative work and miscellaneous technical tasks in support of the OCFO as requested. In conclusion of the internship, the intern will become knowledgeable on reimbursable accounting, reimbursable policy, types of reimbursable agreements, the agreements process, estimated pricing reports, and the roles and responsibilities of the Financial Accounting and Financial Services offices.

Process Champion↗

Quality Assurance Surveillance Tool Designed for SLS EM-1 Certificate of Flight Readiness

Exploration Mission-1 (EM-1) is an uncrewed mission that is launching on the Space Launch System (SLS) Block 1 vehicle. This is a critical flight test for the agency's human deep space exploration goals. Exploration Ground Systems (EGS) Quality (SA-F2) is responsible for providing Quality Assurance Surveillance Plans (QASPs) for NASA contracts and facilities. A QASP assures products and services are provided to EGS in accordance with the contract requirements. In order to encapsulate the multiple KSC Safety and Mission Assurance surveillance and audit activities that need to be accomplished specifically for EM-1 Certificate of Flight Reediness (CoFR), a QASP tool needed to be implemented. This tool would be able to intuitively track Work Authorization Documents (WADs) under development by Test Operations Support Contract (TOSC), reviewed and accepted WADs, Government Mandatory Inspection Points (GMIPs), Nonconformances (NCs), Material Review Board (MRB) Status, Corrective Actions, Alterations, Deviations, and Waivers for flight hardware and Ground Support Equipment (GSE). This would help ensure that all SLS EM-1 flight hardware and related GSE surveillances and requirements are being recognized and completed with zero constraints identified for the mission.

Morris, Patrick↗

Architecture Modeling on the Europa Project

In 2015 NASA chartered a partnership between the Jet Propulsion Laboratory (JPL) and the Johns Hopkins Applied Physics Laboratory (APL) to begin planning a mission to study the Jovian moon Europa. The project has adopted a Model-Based Systems Engineering (MBSE) approach to its architecting process since its early formulation, developing certain modeling practices and tools as needed, with the expectation that this process would result in a more consistent and verifiable architecture than with a more traditional document-based approach. A sound architecture is essential to provide the rationale for requirements on the system design, and to define the trade space of acceptable design points within which technical and programmatic concerns as well as project objectives can be addressed. This paper provides an overview of the framework used by the Europa project to describe the mission architecture and discusses how a system model was instrumental in providing a single-source-of-truth for this description. Several key modeling patterns to represent the architecture are presented, along with audit methods to ensure the consistency and the correctness of the model. Finally, the benefits and challenges of using a model-based approach to generate traditional requirements documents and other gate products are assessed.

Dubos, Gregory F.↗

Exposing Hidden Parts of the SE Process: MBSE Patterns and Tools for Tracking and Traceability

An interesting benefit of applying Model-Based Systems Engineering (MBSE) is that the rigor and coordination intrinsic to MBSE forces us to apply Systems Engineering to our own traditional activities, processes, and products, which results in richer, more expressive models, more powerful reasoning, and a clearer and more effective Systems Engineering (SE) process. Our MBSE frameworks and languages contain semantic richness sufficient to describe our systems at any particular point in time, often with an emphasis on the description of the system at major milestones. This is unarguably a real asset. However, when we apply MBSE in service of missions that are in development, rapidly evolving, of a larger scale, and where interpersonal communication is a critical part of the design process, we discover that our frameworks and languages are still not quite rich enough to enable us to ask the kinds of questions and get the kinds of answers we want in order to address the concerns of day to day work. This paper will discuss some patterns and tools we have developed to help address some of the not-always-explicit SE concerns that we have identified through our MBSE work. Particularly, this paper will discuss flexible yet practical methods for defining and capturing maturity, workflow, and agreement traceability within our system models, extensible ways to perform and track model audits, and ways to report and interact with this knowledge in the context of MBSE applied to support NASA’s Europa Project.

Jackson, Maddalena↗

Exposing Hidden Parts of the SE Process: MBSE Patterns and Tools for Tracking and Traceability

An interesting benefit of applying Model-Based Systems Engineering (MBSE) is that the rigor and coordination intrinsic to MBSE forces us to apply Systems Engineering to our own traditional activities, processes, and products, which results in richer, more expressive models, more powerful reasoning, and a clearer and more effective Systems Engineering (SE) process. Our MBSE frameworks and languages contain semantic richness sufficient to describe our systems at any particular point in time, often with an emphasis on the description of the system at major milestones. This is unarguably a real asset. However, when we apply MBSE in service of missions that are in development, rapidly evolving, of a larger scale, and where interpersonal communication is a critical part of the design process, we discover that our frameworks and languages are still not quite rich enough to enable us to ask the kinds of questions and get the kinds of answers we want in order to address the concerns of day to day work. This paper will discuss some patterns and tools we have developed to help address some of the not-always-explicit SE concerns that we have identified through our MBSE work. Particularly, this paper will discuss flexible yet practical methods for defining and capturing maturity, workflow, and agreement traceability within our system models, extensible ways to perform and track model audits, and ways to report and interact with this knowledge in the context of MBSE applied to support NASA’s Europa Project

Jackson, Maddalena↗