Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “flow diagrams”

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 19 records

Software Tool Integrating Data Flow Diagrams and Petri Nets

Data Flow Diagram - Petri Net (DFPN) is a software tool for analyzing other software to be developed. The full name of this program reflects its design, which combines the benefit of data-flow diagrams (which are typically favored by software analysts) with the power and precision of Petri-net models, without requiring specialized Petri-net training. (A Petri net is a particular type of directed graph, a description of which would exceed the scope of this article.) DFPN assists a software analyst in drawing and specifying a data-flow diagram, then translates the diagram into a Petri net, then enables graphical tracing of execution paths through the Petri net for verification, by the end user, of the properties of the software to be developed. In comparison with prior means of verifying the properties of software to be developed, DFPN makes verification by the end user more nearly certain, thereby making it easier to identify and correct misconceptions earlier in the development process, when correction is less expensive. After the verification by the end user, DFPN generates a printable system specification in the form of descriptions of processes and data.

Thronesbery, Carroll↗

Information-Systems Data-Flow Diagram

Single form presents clear picture of entire system. Form giving relational review of data flow well suited to information system planning, analysis, engineering, and management. Used to review data flow for developing system or one already in use.

Blosiu, J. O.↗

Rendezvous targeting

Revisions to be included in 'Space Shuttle Guidance, Navigation and Control Design Equations' are reported. Technical changes include: (1) a plane change maneuver was incorporated in the program's logic; (2) in the search for an apsidal crossing, program checks were included to update through intervals of pi in the case of near circular orbits or close proximity to an apsidal point; (3) following an astronaut overwrite of a Lambert maneuver, the state vector was updated to establish a new target vector for use in the powered flight routine; and (4) following the computation of each maneuver, the position vector of the primary vehicle was offset - to help compensate for the effects of the finite maneuver - prior to the update of the state vector to the next maneuver point. Input and output variables, detailed flow diagrams a functional flow diagram, and a description of equations are presented.

Tempelman, W. H.↗

Automating symbolic analysis with CLIPS

Symbolic Analysis is a methodology first applied as an aid in selecting and generating test cases for 'white box' type testing of computer software programs. The feasibility of automating this analysis process has recently been demonstrated through the development of a CLIPS-based prototype tool. Symbolic analysis is based on separating the logic flow diagram of a computer program into its basic elements, and then systematically examining those elements and their relationships to provide a detailed static analysis of the process that those diagrams represent. The basic logic flow diagram elements are flow structure (connections), predicates (decisions), and computations (actions). The symbolic analysis approach supplies a disciplined step-by-step process to identify all executable program paths and produce a truth table that defines the input and output domains for each path identified. The resulting truth table is the tool that allows software test cases to be generated in a comprehensive manner to achieve total program path, input domain, and output domain coverage. Since the manual application of symbolic analysis is extremely labor intensive and is itself error prone, automation of the process is highly desirable. Earlier attempts at automation, utilizing conventional software approaches, had only limited success. This paper briefly describes the automation problems, the symbolic analysis expert's problem solving heuristics, and the implementation of those heuristics as a CLIPS based prototype, and the manual augmentation required. A simple application example is also provided for illustration purposes. The paper concludes with a discussion of implementation experiences, automation limitations, usage experiences, and future development suggestions.

Morris, Keith E.↗

Digital vibration control techniques

Analog vibration control techniques are reviewed and are compared with digital techniques. The advantages of the digital methods over the analog methods are demonstrated. The following topics are covered: (1) methods of computer-controlled random vibration and reverberation acoustic testing; (2) methods of computer-controlled sinewave vibration testing; and (3) methods of computer-controlled shock testing. Basic concepts are stressed rather than specific techniques or equipment. General algorithms are described in the form of block diagrams and flow diagrams. Specific problems and potential problems are discussed. The material is computer sciences oriented but is kept at a level that facilitates an understanding of the basic concepts of computer-controlled induced environmental test systems.

Chapman, P.↗

Seminar on Understanding Digital Control and Analysis in Vibration Test Systems

The advantages of the digital methods over the analog vibration methods are demonstrated. The following topics are covered: (1) methods of computer-controlled random vibration and reverberation acoustic testing, (2) methods of computer-controlled sinewave vibration testing, and (3) methods of computer-controlled shock testing. General algorithms are described in the form of block diagrams and flow diagrams.

Source record↗

Software design specification. Part 2: Orbital Flight Test (OFT) detailed design specification. Volume 3: Applications. Book 2: System management

The functions performed by the systems management (SM) application software are described along with the design employed to accomplish these functions. The operational sequences (OPS) control segments and the cyclic processes they control are defined. The SM specialist function control (SPEC) segments and the display controlled 'on-demand' processes that are invoked by either an OPS or SPEC control segment as a direct result of an item entry to a display are included. Each processing element in the SM application is described including an input/output table and a structured control flow diagram. The flow through the module and other information pertinent to that process and its interfaces to other processes are included.

Source record↗

Identification of large space structures: A state-of-practice report

An outline of this work is presented. It begins with a schematic flow diagram and a logical flow diagram of the identification process for large space structures (LSS). Next, the task is defined by a structure model definition. A matrix polynomial formulation with a node displacement equation and a state variable formulation with node displacement and velocities are outlined. Further outlined is the identification of LSS on orbit; modeling errors and uncertainties; verification and validation of model; and noise, computations, and data collection.

Source record↗

MODIS information, data and control system (MIDACS) level 2 functional requirements

The MODIS Information, Data and Control System (MIDACS) Level 2 Functional Requirements Document establishes the functional requirements for MIDACS and provides a basis for the mutual understanding between the users and the designers of the EosDIS, including the requirements, operating environment, external interfaces, and development plan. In defining the requirements and scope of the system, this document describes how MIDACS will operate as an element of the EOS within the EosDIS environment. This version of the Level 2 Requirements Document follows an earlier release of a preliminary draft version. The sections on functional and performance requirements do not yet fully represent the requirements of the data system needed to achieve the scientific objectives of the MODIS instruments and science teams. Indeed, the team members have not yet been selected and the team has not yet been formed; however, it has been possible to identify many relevant requirements based on the present concept of EosDIS and through interviews and meetings with key members of the scientific community. These requirements have been grouped by functional component of the data system, and by function within each component. These requirements have been merged with the complete set of Level 1 and Level 2 context diagrams, data flow diagrams, and data dictionary.

Han, D.↗

Mars Science Laboratory CHIMRA/IC/DRT Flight Software for Sample Acquisition and Processing

The design methodologies of using sequence diagrams, multi-process functional flow diagrams, and hierarchical state machines were successfully applied in designing three MSL (Mars Science Laboratory) flight software modules responsible for handling actuator motions of the CHIMRA (Collection and Handling for In Situ Martian Rock Analysis), IC (Inlet Covers), and DRT (Dust Removal Tool) mechanisms. The methodologies were essential to specify complex interactions with other modules, support concurrent foreground and background motions, and handle various fault protections. Studying task scenarios with multi-process functional flow diagrams yielded great insight to overall design perspectives. Since the three modules require three different levels of background motion support, the methodologies presented in this paper provide an excellent comparison. All three modules are fully operational in flight.

sample processing↗

Asymmetrical booster ascent guidance and control system design study. Volume 5: Space shuttle powered explicit guidance

An optimum powered explicit guidance algorithm capable of handling all space shuttle exoatospheric maneuvers is presented. The theoretical and practical basis for the currently baselined space shuttle powered flight guidance equations and logic is documented. Detailed flow diagrams for implementing the steering computations for all shuttle phases, including powered return to launch site (RTLS) abort, are also presented. Derivation of the powered RTLS algorithm is provided, as well as detailed flow diagrams for implementing the option. The flow diagrams and equations are compatible with the current powered flight documentation.

Jaggers, R. F.↗

Advanced Platform Systems Technology study. Volume 4: Technology advancement program plan

An overview study of the major technology definition tasks and subtasks along with their interfaces and interrelationships is presented. Although not specifically indicated in the diagram, iterations were required at many steps to finalize the results. The development of the integrated technology advancement plan was initiated by using the results of the previous two tasks, i.e., the trade studies and the preliminary cost and schedule estimates for the selected technologies. Descriptions for the development of each viable technology advancement was drawn from the trade studies. Additionally, a logic flow diagram depicting the steps in developing each technology element was developed along with descriptions for each of the major elements. Next, major elements of the logic flow diagrams were time phased, and that allowed the definition of a technology development schedule that was consistent with the space station program schedule when possible. Schedules show the major milestone including tests required as described in the logic flow diagrams.

Source record↗

Development of the Functional Flow Block Diagram for the J-2X Rocket Engine System

The J-2X program calls for the upgrade of the Apollo-era Rocketdyne J-2 engine to higher power levels, using new materials and manufacturing techniques, and with more restrictive safety and reliability requirements than prior human-rated engines in NASA history. Such requirements demand a comprehensive systems engineering effort to ensure success. Pratt & Whitney Rocketdyne system engineers performed a functional analysis of the engine to establish the functional architecture. J-2X functions were captured in six major operational blocks. Each block was divided into sub-blocks or states. In each sub-block, functions necessary to perform each state were determined. A functional engine schematic consistent with the fidelity of the system model was defined for this analysis. The blocks, sub-blocks, and functions were sequentially numbered to differentiate the states in which the function were performed and to indicate the sequence of events. The Engine System was functionally partitioned, to provide separate and unique functional operators. Establishing unique functional operators as work output of the System Architecture process is novel in Liquid Propulsion Engine design. Each functional operator was described such that its unique functionality was identified. The decomposed functions were then allocated to the functional operators both of which were the inputs to the subsystem or component performance specifications. PWR also used a novel approach to identify and map the engine functional requirements to customer-specified functions. The final result was a comprehensive Functional Flow Block Diagram (FFBD) for the J-2X Engine System, decomposed to the component level and mapped to all functional requirements. This FFBD greatly facilitates component specification development, providing a well-defined trade space for functional trades at the subsystem and component level. It also provides a framework for function-based failure modes and effects analysis (FMEA), and a rigorous baseline for the functional architecture.

White, Thomas↗

Advanced Information Processing System (AIPS) proof-of-concept system functional design I/O network system services

The function design of the Input/Output (I/O) services for the Advanced Information Processing System (AIPS) proof of concept system is described. The data flow diagrams, which show the functional processes in I/O services and the data that flows among them, are contained. A complete list of the data identified on the data flow diagrams and in the process descriptions are provided.

Source record↗

Space shuttle GN and C equation document: Entry and transition guidance

The entry-guidance routine presented is designed to take the orbiter vehicle from entry interface through the critical heating phase of entry down to the start of the approach phase. The material includes: (1) a functional flow diagram, (2) input and output variables, (3) a description of equations, and (4) detailed flow diagrams.

Marcus, F. J.↗