Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software testing”

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 1,549 records · Page 86

TRIDENT Drill Validation at Mars and Lunar Analog Field Sites

Drilling on Earth is typically a human-intensive activity. Drilling on other planets is further complicated by the lack of prior local field surveys of their target area, hence blindly drilling into uncertain target rocks. Field conditions on the Moon or Mars are also different than for shallow drilling on Earth: lower temperatures and pressures, less power available, low masses (hence less weight-on-bit). Given the cost of transport from Earth, no drilling muds or working fluids are likely to be available to carry away cuttings. And impact-gardened regolith and dust vary mechanically and texturally from most terrestrial soils. The Regolith and Ice Drill for Exploration of New Terrains (TRIDENT) is a rotary-percussive 1m-class drill from Honeybee Robotics. It is low-power (rotary and percussive actuators are 200 W each) and lightweight (<20 kg) with the maximum weight on bit limited to 200 N. TRIDENT has been manifested for the Volatiles Investigating Polar Exploration Rover (VIPER) and PRIME-1 lunar south pole missions in 2024, has previously been field tested at a hot, dry analog site in the Atacama Desert, and in lunar conditions in thermal vacuum chamber tests. TRIDENT was also part of the 2019 Icebreaker Mars Discovery proposal, as well as in the Mars Life Explorer concept. During ARADS tests, drill control and fault recovery automation software enabled hands-off operations of a rover-mounted TRIDENT drill. TRIDENT Drill Analog Site Validation: Past TRIDENT tests in thermal vacuum (TVAC) chambers targeted containers of manufactured lunar simulants with added volatiles. 2022 TRIDENT ambient testing at NASA Ames drilled into cemented lunar simulant materials. Low cuttings-permeability led to cuttings buildup, and drill choking and binding was observed. The Atacama analog site in ARADS had desiccated unconsolidated sediments that did not challenge the TRIDENT design. However, lunar polar regolith is expected to be diverse and heterogeneous with varying clast sizes, with abundant impactites and perhaps subsurface ice deposits. Neither the simulants nor Atacama testing had completely covered the TRIDENT-targeted field characteristics, motivating further analog tests prior to the planned lunar missions. To gain more insight into the behavior of the TRIDENT hardware in diverse impactites and subsurface ice, and to verify the software automation in that environment, in August 2023 TRIDENT was brought to Haughton Crater, a field analog site in the Canadian Arctic. In September 2023 the same drill was brought to the Bishop Tuff in southern California to verify whether drilling binding behaviors previously seen in lunar simulant testing would be observed in naturally occurring fine-grained massive layers. The ~22 Ma Haughton Crater impact structure is located at 75 ̊22’ N, 89 ̊41’ W, on northwestern Devon Island, Nunavut, Canada. Numerous deposits of pale-grey crater-fill polymictic impact-melt breccia are found within the crater with a typical thickness reaching ~125 m or greater and covering ~60 km -2 . An approximately 600m-thick permafrost layer is also present with ice typically found within 0.5-0.6m of the surface. The volcanic tableland north of Bishop, CA exposes densely welded tuff laid down during the eruption that created the Long Valley Caldera at approximately 0.76 Ma. Extensional faults and the Owens River gorge expose cross-sections across the plateau. The area is viewed as an analog site for Mars features believed to be of pyroclastic origin. Results: Haughton Crater.Drilling tests were conducted 8-13 August 2023 at a previously undisturbed area separated 5-10 m from past years’ Drill Hill test sites (75.4208, -089.7613). In six days, TRIDENT drilled 8 holes to nearly 1 m depth each, totaling 7.80 m. The active layer/ice boundary was at ~67 cm depth, with a total of approximately 2.4 m drilled into ice or ice-cemented impact breccia. During drilling, five drill fault states were observed and successfully recovered. Holes 23-1, 4 and 7 were drilled under manual control, using Honeybee’s Thorax user interface. Holes 23-5, 6, and 8 were drilled with the Ames IBexec automated drilling control software. TRIDENT was observed to have little difficulty in the thawed uncemented impact breccia above the active layer boundary, but required percussion to make slower headway in the ice-cemented breccia. In Hole 23-7 (Fig.1), drilling slowed down in a massive unit just above the active-layer boundary (perhaps a large rock extending into the ice-cementation?), with only 7cm progress made in 27 minutes of high auger torque and constant percussion, leading to a choking fault and then a binding fault. A similar pattern had been observed in TRIDENT Rio Tinto test data from 2017 [6] as well as in the 2022laboratory tests.Bishop Tuff.A team from NASA Ames and the US Geological Survey deployed the same TRIDENT drill to Bishop Sites 1B and 1C (37.4203, -118.4289; 37.4265, -118.4215) on 13-16 September 2023, on the Bishop Tuff plateau. A third drill site was used 17-18 September 2023(37.4598, -118.3667) in an abandoned pumice mine. Four holes (totaling 2.5m depth) were drilled into the fine-grained, meters-thick tuff units at Sites 1B and 1C, and a further two boreholes (totaling 1.98m depth) were made at the pumice site. Drill behavior in the tuff below 10 cm depth was similar to that seen at 65-74 cm depth in Haughton Hole 23-7 (Fig. 1) and that seen in the 2022 lab simulant drilling. Drill safety torque limits were exceeded multiple times resulting in drill stops downhole. These freezes then required external added torques (with a pipe wrench) to resume rotation, to unstick the drill for withdrawal. To prevent this choking and binding behavior we found that more-frequent cuttings removal was necessary, e.g., reducing the “drill bite” size from the nominal 10 cm to 2 cm per bite --bringing the auger up to the surface more frequently, as seen in Bishop Site 1C Hole 2 (Fig.2). This permitted slow progress without drill binding and without external interventions. Conversely, TRIDENT drilling in the more porous pumice target material showed no cuttings buildup issue, and single bites as large as 40 cm were demonstrated. Discussion: We observed that TRIDENT easily penetrated unconsolidated heterogeneous soils (both above the active layer boundary at Haughton and previously in the Atacama). Cemented or consolidated targets that were cuttings-permeable (icy impact breccia, pumice) required more energy applied and percussion. However, in non-cuttings-permeable targets (welded microporous tuff, cemented simulants, boulder) TRIDENT was observed to be prone to excessive cuttings accumulation leading to choking/binding faults and stalling. The wedge cutting bit, used by TRIDENT in field tests and in its flight versions, pulverizes the target rock and creates fine cuttings that ideally are transported up the auger spirals for removal. In porous, fractured or vesicular target materials (such as at the Bishop pumice site) a significant portion of the cuttings are pushed aside, but for non-fractured, microporous targets the cuttings remain in the borehole and accumulate. Rock powder is relatively incompressible as a working fluid at only 100-200N downward force (TRIDENT limits) and hence eventual drilling progress slows or stops. Our recommended strategy for improving TRIDENT cuttings removal in massive target units with low cuttings-permeability is to reduce TRIDENT bite sizes when encountering these units, from 10cm to as little as 1-2cm, to effectively bail the accumulating cuttings. This approach was demonstrated to reduce choking and allowed slow progress to continue in cuttings-impermeable microporous target units (viz. the Bishop tuff in our September 2023 tests or cemented simulants in 2022 ambient tests).

robotic drilling↗

An Open-Source Framework for Rapid Validation of Scientific ASICs

Spacely is an open-source framework for the post-silicon validation of analog, digital, and mixed-signal ASICs (Application-Specific Integrated Circuits) which maximizes the reuse of hardware and software, reducing the time taken to achieve meaningful test results. Spacely specifically addresses the needs of small, flexible ASIC design teams commonly found in academia or research institutions which benefit most from sharing the overhead of test stand creation between many unique ASIC designs. Spacely is a set of software, firmware, and design practices. It targets two primary hardware platforms (NI-PXI and Caribou) as well as offering extensible support for bench instruments. Spacely provides a high-level Python interface to all test hardware for accessibility, while also giving more sophisticated teams the opportunity to integrate custom test firmware. The design principles of Spacely are presented in brief. Current documentation is available at https://github.com/SpacelyProject/spacely-docs.

Quinn, Adam [Fermilab]↗

An Open-Source Framework for Rapid Validation of Scientific ASICs

Spacely is an open-source framework for the post-silicon validation of analog, digital, and mixed-signal ASICs (Application-Specific Integrated Circuits) which maximizes the reuse of hardware and software, reducing the time taken to achieve meaningful test results. Spacely specifically addresses the needs of small, flexible ASIC design teams commonly found in academia or research institutions which benefit most from sharing the overhead of test stand creation between many unique ASIC designs. Spacely is a set of software, firmware, and design practices. It targets two primary hardware platforms (NI-PXI and Caribou) as well as offering extensible support for bench instruments. Spacely provides a high-level Python interface to all test hardware for accessibility, while also giving more sophisticated teams the opportunity to integrate custom test firmware. The design principles of Spacely are presented, along with a demonstrative example of using Spacely to test a pixel detector readout ASIC.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Man-rated flight software for the F-8 DFBW program

The design, implementation, and verification of the flight control software used in the F-8 DFBW program are discussed. Since the DFBW utilizes an Apollo computer and hardware, the procedures, controls, and basic management techniques employed are based on those developed for the Apollo software system. Program Assembly Control, simulator configuration control, erasable-memory load generation, change procedures and anomaly reporting are discussed. The primary verification tools--the all-digital simulator, the hybrid simulator, and the Iron Bird simulator--are described, as well as the program test plans and their implementation on the various simulators. Failure-effects analysis and the creation of special failure-generating software for testing purposes are described. The quality of the end product is evidenced by the F-8 DFBW flight test program in which 42 flights, totaling 58 hours of flight time, were successfully made without any DFCS inflight software, or hardware, failures.

Bairnsfather, R. R.↗

Pronghorn: A Porous Media Thermal-Hydraulics Core Simulator and its Validation with the SANA Experiments

Pebble bed High Temperature Reactors (HTRs) are characterized by many advantageous design features, such as excellent passive heat removal in accidents, large margins to fuel failure, and online refueling potential. However, a significant challenge in the core modeling of pebble bed reactors is the complex fuel-coolant structure. This paper presents a new porous media simulation code, Pronghorn, that aims to alleviate modeling challenges for pebble bed reactors by providing a fast-running, medium- fidelity core simulator. Pronghorn is intended to accelerate the design and analysis cycle for pebble bed and prismatic HTRs by permitting fast scoping studies and providing boundary conditions for systems-level analysis. Pronghorn is built on the Multiphysics Object-Oriented Simulation Environment (MOOSE) using modern software practices and a thorough testing framework. This paper describes the physical models used in Pronghorn and demonstrates Pronghorn’s capability for modeling gas-cooled pebble bed HTRs by presenting simulation results obtained for the German SANA pebble bed decay heat experiments. Within the limitations of the porous media approximation and existing available closure relationships, Pronghorn predicts the SANA experimental pebble temperatures well, expanding the code’s validation base. A brief code-to-code comparison shows a similar level of accuracy with other porous media simulation tools; this enhances Pronghorn’s advantages of an arbitrary equation of state, unstructured mesh capabilities, compressible flow models, high coupling potential to MOOSE fuels performance and systems-level thermal-hydraulics codes, and modern software design.

42 ENGINEERING↗

Development of a versatile hybrid testing system for seismic experimentation

The hybrid testing method for earthquake engineering was developed to evaluate the seismic performance of civil structural systems. During hybrid testing, part of the structure, called physical substructure, is physically tested using hydraulic loading equipment while the rest of the structure, named numerical substructure, is numerically simulated with a computer model. Thus, hybrid testing allows a complex physical substructure being tested experimentally, while the relatively simple part of the structure is numerically simulated to economically obtain the full structural response. Recently, a versatile hybrid testing system was built at Western Michigan University consisting of a shake table, an actuator/reaction system, and an advanced hybrid testing controller. Such a testing system is capable of conducting various seismic experiments such as displacement-based pseudodynamic substructure testing as well as force-based real time dynamic hybrid testing. Because of its versatility and easy operation at the benchmark scale, the developed testing system is particularly suitable for the development of advanced hybrid testing techniques and, earthquake engineering education/outreach activities. The development of the testing system is described in this article focusing on the hardware and software integrations. A three story shake table hybrid test is presented as an example to demonstrate the system’s capability and feasibility.

42 ENGINEERING↗

Investigating Temperature Uniformity and Accuracy in PV Module Lamination: A Verification Study

This study investigates the temperature uniformity and accuracy of a photovoltaic (PV) module lamination process by addressing inconsistencies identified in 2017 data where irregular temperature changes were observed across setpoints. The 2017 data showed a notable drop in temperature upon bladder initiation, except for the 145 degrees Celsius profile. This inconsistency indicated potential inaccuracies in manual data recording methods. To address this concern, a verification experiment was conducted to evaluate temperature uniformity across the 2014 Bent River SPL2828 laminator platen and within test samples. Thermocouples, paired with Omega data acquisition software, were deployed to measure temperatures at multiple platen locations and within test samples. The experiment compared lamination temperatures of polyethylene-co-vinyl acetate (EVA) encapsulant when paired with solite glass or TPE backsheets. The methodology included verifying temperature uniformity directly on the platen and by using a large glass/EVA/glass sample using multiple thermocouples. Smaller samples were built with glass/EVA/glass and glass/EVA/backsheet configurations with one centered thermocouple to verify and compare sample temperatures. This verification aims to refine lamination temperature profiles, enhance data accuracy and provide insights into optimal process control for uniform module lamination. Ensuring consistent and uniform lamination may improve the accuracy and reliability of research outcomes.

14 SOLAR ENERGY↗

Development of a 32-bit UNIX-based ELAS workstation

A mini/microcomputer UNIX-based image analysis workstation has been designed and is being implemented to use the Earth Resources Laboratory Applications Software (ELAS). The hardware system includes a MASSCOMP 5600 computer, which is a 32-bit UNIX-based system (compatible with AT&T System V and Berkeley 4.2 BSD operating system), a floating point accelerator, a 474-megabyte fixed disk, a tri-density magnetic tape drive, and an 1152 by 910 by 12-plane color graphics/image interface. The software conversion includes reconfiguring the ELAs driver Master Task, recompiling and then testing the converted application modules. This hardware and software configuration is a self-sufficient image analysis workstation which can be used as a stand-alone system, or networked with other compatible workstations.

Spiering, Bruce A.↗

Verifying Correct Functionality of Avionics Subsystems

This project focuses on the testing of the telecommunications interface subsystem of the Multi-Mission System Architecture Platform to ensure proper functionality. The Multi-Mission System Architecture Platform is a set of basic tools designed to be used in future spacecraft. The responsibilities of the telecommunications interface include communication between the spacecraft and ground teams as well as acting as the bus controller for the system. The tests completed include bit wise read\write tests to each register, testing of status bits, and verifying various bus controller activities. Testing is accomplished through the use of software-based simulations run on an electronic design of the system. The tests are written in Verilog Hardware Definition Language and they simulate specific states and conditions in telecommunication interfaces. Upon successful completion, the output is examined to verify that the system responded appropriately.

Meuer, Ben t.↗

Evolution of the Space Shuttle Primary Avionics Software and Avionics for Shuttle Derived Launch Vehicles

As a result of recommendation from the Augustine Panel, the direction for Human Space Flight has been altered from the original plan referred to as Constellation. NASA s Human Exploration Framework Team (HEFT) proposes the use of a Shuttle Derived Heavy Lift Launch Vehicle (SDLV) and an Orion derived spacecraft (salvaged from Constellation) to support a new flexible direction for space exploration. The SDLV must be developed within an environment of a constrained budget and a preferred fast development schedule. Thus, it has been proposed to utilize existing assets from the Shuttle Program to speed development at a lower cost. These existing assets should not only include structures such as external tanks or solid rockets, but also the Flight Software which has traditionally been a "long pole" in new development efforts. The avionics and software for the Space Shuttle was primarily developed in the 70 s and considered state of the art for that time. As one may argue that the existing avionics and flight software may be too outdated to support the new SDLV effort, this is a fallacy if they can be evolved over time into a "modern avionics" platform. The technology may be outdated, but the avionics concepts and flight software algorithms are not. The reuse of existing avionics and software also allows for the reuse of development, verification, and operations facilities. The keyword is evolve in that these assets can support the fast development of such a vehicle, but then be gradually evolved over time towards more modern platforms as budget and schedule permits. The "gold" of the flight software is the "control loop" algorithms of the vehicle. This is the Guidance, Navigation, and Control (GNC) software algorithms. This software is typically the most expensive to develop, test, and verify. Thus, the approach is to preserve the GNC flight software, while first evolving the supporting software (such as Command and Data Handling, Caution and Warning, Telemetry, etc.). This can be accomplished by gradually removing the "support software" from the legacy flight software leaving only the GNC algorithms. The "support software" could be re-developed for modern platforms, while leaving the GNC algorithms to execute on technology compatible with the legacy system. It is also possible to package the GNC algorithms into an emulated version of the original computer (via Field Programmable Gate Arrays or FPGAs), thus becoming a "GNC on a Chip" solution where it could live forever to be embedded in modern avionics platforms.

Ferguson, Roscoe C.↗

Time cycle analysis and simulation of material flow in MOX process layout

The (U,Pu)O{sub 2} MOX fuel is the driver fuel for the upcoming PFBR (Prototype Fast Breeder Reactor). The fuel has around 30% PuO{sub 2}. The presence of high percentages of reprocessed PuO{sub 2} necessitates the design of optimized fuel fabrication process line which will address both production need as well as meet regulatory norms regarding radiological safety criteria. The powder pellet route has highly unbalanced time cycle. This difficulty can be overcome by optimizing process layout in terms of equipment redundancy and scheduling of input powder batches. Different schemes are tested before implementing in the process line with the help of a software. This software simulates the material movement through the optimized process layout. The different material processing schemes have been devised and validity of the schemes are tested with the software. Schemes in which production batches are meeting at any glove box location are considered invalid. A valid scheme ensures adequate spacing between the production batches and at the same time it meets the production target. This software can be further improved by accurately calculating material movement time through glove box train. One important factor is considering material handling time with automation systems in place.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

A data acquisition and storage system for the ion auxiliary propulsion system cyclic thruster test

A nine-track tape drive interfaced to a standard personal computer was used to transport data from a remote test site to the NASA Lewis mainframe computer for analysis. The Cyclic Ground Test of the Ion Auxiliary Propulsion System (IAPS), which successfully achieved its goal of 2557 cycles and 7057 hr of thrusting beam on time generated several megabytes of test data over many months of continuous testing. A flight-like controller and power supply were used to control the thruster and acquire data. Thruster data was converted to RS232 format and transmitted to a personal computer, which stored the raw digital data on the nine-track tape. The tape format was such that with minor modifications, mainframe flight data analysis software could be used to analyze the Cyclic Ground Test data. The personal computer also converted the digital data to engineering units and displayed real time thruster parameters. Hardcopy data was printed at a rate dependent on thruster operating conditions. The tape drive provided a convenient means to transport the data to the mainframe for analysis, and avoided a development effort for new data analysis software for the Cyclic test. This paper describes the data system, interfacing and software requirements.

Hamley, John A.↗

SU-F-BRE-16: VMAT Commissioning and Quality Assurance (QA) of An Elekta Synergy-STM Linac Using ICOM Test HarnessTM

Purpose: To establish a set of tests based on the iCOM software that can be used to commission and perform periodic QA of VMAT delivery on the Elekta Synergy-S, commonly known as the Beam Modulator (BM). Methods: iCOM is used to create and deliver customized treatment fields to characterize the system in terms of 1) MLC positioning accuracy under static and dynamic delivery with full gantry rotation, 2) MLC positioning with known errors, 3) Maximum dose rate, 4) Maximum MLC speed, 5) Maximum gantry speed, 6) Synchronization: gantry speed versus dose rate, and 7) Synchronization: MLC speed versus dose rate. The resulting images were captured on the iView GT and exported in DICOM format to Dosimetry Check™ system for visual and quantitative analysis. For the initial commissioning phase, the system tests described should be supplemented with extensive patient QAs covering all clinically relevant treatment sites. Results: The system performance test suite showed that on our Synergy-S, MLC positioning was accurate under both static and dynamic deliveries. Intentional errors of 1 mm were also easily identified on both static and dynamic picket fence tests. Maximum dose rate was verified with stop watch to be consistently between 475-480 MU/min. Maximum gantry speed and MLC speed were 5.5 degree/s and 2.5 cm/s respectively. After accounting for beam flatness, both synchronization tests, gantry versus dose rate and MLC speed versus dose rate, were successful as the fields were uniform across the strips and there were no obvious cold/hot spots. Conclusion: VMAT commissioning and quality assurance should include machine characterization tests in addition to patient QAs. Elekta iCOM is a valuable tool for the design of customized VMAT field with specific MU, MLC leaf positions, dose rate, and indirect control of MLC and gantry speed at each of its control points.

07 ISOTOPE AND RADIATION SOURCES↗

International Space Station Urine Monitoring System Functional Integration and Science Testing

Exposure to microgravity during human spaceflight needs to be better understood as the human exploration of space requires longer duration missions. It is known that long term exposure to microgravity causes bone loss. Measuring the calcium and other metabolic byproducts in a crew member s urine can evaluate the effectiveness of bone loss countermeasures. The International Space Station (ISS) Urine Monitoring System (UMS) is an automated urine collection device designed to collect urine, separate the urine and air, measure the void volume, and allow for syringe sampling. Accurate measuring and minimal cross-contamination is essential to determine bone loss and the effectiveness of countermeasures. The ISS UMS provides minimal cross-contamination (<0.7 mL urine) and has volume accuracy of 2% between 100 to 1000 mL urine voids. Designed to provide a non-invasive means to collect urine samples from crew members, the ISS UMS operates in-line with the Node 3 Waste and Hygiene Compartment (WHC). The ISS UMS has undergone modifications required to interface with the WHC, including material changes, science algorithm improvements, and software platform revisions. Integrated functional testing was performed to determine the pressure drop, air flow rate, and the maximum amount of fluid capable of being discharged from the UMS to the WHC. This paper will detail the results of the science and the functional integration tests.

Rodriquez, Branelle R.↗

Integration of an expert system into a user interface language demonstration

The need for a User Interface Language (UIL) has been recognized by the Space Station Program Office as a necessary tool to aid in minimizing the cost of software generation by multiple users. Previous history in the Space Shuttle Program has shown that many different areas of software generation, such as operations, integration, testing, etc., have each used a different user command language although the types of operations being performed were similar in many respects. Since the Space Station represents a much more complex software task, a common user command language--a user interface language--is required to support the large spectrum of space station software developers and users. To assist in the selection of an appropriate set of definitions for a UIL, a series of demonstration programs was generated with which to test UIL concepts against specific Space Station scenarios using operators for the astronaut and scientific community. Because of the importance of expert system in the space station, it was decided that an expert system should be embedded in the UIL. This would not only provide insight into the UIL components required but would indicate the effectiveness with which an expert system could function in such an environment.

Stclair, D. C.↗

SEDS1 mission software verification using a signal simulator

The first flight of the Small Expendable Deployer System (SEDS1) is scheduled as the secondary payload of a Delta II in late 1992. The objective of the SEDS1 mission is to collect data to validate the concept of tethered satellite systems and to verify computer simulations used to predict their behavior. A series of tests will be performed to exercise the software modules which make up the Mission Software of the SEDS Data System. These tests will be performed by using a SEDS Signal Simulator to generate signals which will simulate the inputs normally produced by sensors and circuits in the SEDS system. The SEDS Signal Simulator will be used in the debugging and in the formal verification of the SEDS1 Mission Software. The Simulator will not only emulate normal flight conditions but also exercise all modules written to handle anticipated anomalous flight conditions, conditions that would be difficult to reproduce and control with actual SEDS hardware. The simulator will help to expedite software development and to increase the confidence of the users of the Mission Software. With little modification, the Simulator should be useful in the software development of future SEDS flights.

Pierson, William E.↗

Universal computer test stand (recommended computer test requirements)

Techniques are considered which would be used to characterize areospace computers with the space shuttle application as end usage. The system level digital problems which have been encountered and documented are surveyed. From the large cross section of tests, an optimum set is recommended that has a high probability of discovering documented system level digital problems within laboratory environments. Defined is a baseline hardware, software system which is required as a laboratory tool to test aerospace computers. Hardware and software baselines and additions necessary to interface the UTE to aerospace computers for test purposes are outlined.

Source record↗

A Reference Model for Software and System Inspections. White Paper

Software Quality Assurance (SQA) is an important component of the software development process. SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. Typical techniques include: (1) Testing (2) Simulation (3) Model checking (4) Symbolic execution (5) Management reviews (6) Technical reviews (7) Inspections (8) Walk-throughs (9) Audits (10) Analysis (complexity analysis, control flow analysis, algorithmic analysis) (11) Formal method Our work over the last few years has resulted in substantial knowledge about SQA techniques, especially the areas of technical reviews and inspections. But can we apply the same QA techniques to the system development process? If yes, what kind of tailoring do we need before applying them in the system engineering context? If not, what types of QA techniques are actually used at system level? And, is there any room for improvement.) After a brief examination of the system engineering literature (especially focused on NASA and DoD guidance) we found that: (1) System and software development process interact with each other at different phases through development life cycle (2) Reviews are emphasized in both system and software development. (Figl.3). For some reviews (e.g. SRR, PDR, CDR), there are both system versions and software versions. (3) Analysis techniques are emphasized (e.g. Fault Tree Analysis, Preliminary Hazard Analysis) and some details are given about how to apply them. (4) Reviews are expected to use the outputs of the analysis techniques. In other words, these particular analyses are usually conducted in preparation for (before) reviews. The goal of our work is to explore the interaction between the Quality Assurance (QA) techniques at the system level and the software level.

He, Lulu↗