Search

Exposure of the engine valve to high temperatures led to the degradation of the valve material due to microstructural instability and deteriorating mechanical properties. Performance enhancement and alteration in microstructures can be attained through the powder metallurgy route which is a viable method to produce near net shape components. In this current study, the development of austenitic stainless steel (21-4N) through the powder metallurgy route as an alternate material for engine valves was investigated. Mechanical alloying was carried out for the pre-alloyed mixtures and consolidated using vacuum hot pressing. Sintering parameters were fixed at 1200 °C, 50 MPa and at a vacuum level of 10-3 Torr. A scanning electron microscope was used to analyze the morphology of the milled powders. Densities for the hot pressed powders were compared with theoretical densities and found to be around 98–99%. Observations regarding grain size, the presence of austenitic grain, heterogeneous distribution of metal carbides and analysis of chemical composition along the metal matrix were determined using both optical and electron microscopes. X-ray diffraction was carried out for both the consolidated and powder samples. The hot pressed samples exhibited a hardness value of 410 ± 10 Hv. An isothermal compression test for the sintered samples was carried out at a temperature of 650 °C and strain rate of 0.001 s−1. It is showed that the compressive strength of 1380 MPa. An analysis between the room temperature yield strength obtained from hardness measurement and the strengthening mechanism based on the microstructure was conducted. Grain size, dislocation and solid solution are the major strengthening mechanisms which strengthen the material. Overall, the development of valve steel material through the powder metallurgy route exhibited improved metallurgical and mechanical properties in comparison to the corresponding cast product.

The present article investigates the fabrication of oxide dispersion strengthened (ODS) ferritic stainless steel (FSS). Three different ODS alloys with three different Al contents were fabricated, where the presence of Al-based oxides play a crucial role in determining the size of the oxide particles. Due to Ostwald ripening, the samples with Al show coarser oxide particles compared to the alloy without Al, which hampers the density of the fabricated samples and, hence, have reduced hardness levels. The present results suggest that the composition of the oxide present in ODS plays a crucial role in determining the properties of these samples.

In this research, Powder Metallurgy (P/M) of Duplex Stainless Steels (DSS) of different compositions were prepared through pre-alloyed powders and elemental powders with and without addition of copper. The powder mix was developed by pot mill for 12 h to obtain the homogeneous mixture of pre-alloyed powder with elemental compositions. Cylindrical green compacts with the dimensions of 30 mm diameter and 12 mm height were compacted through universal testing machine at a pressure level of 560 ± 10 MPa. These green compacts were sintered at 1350 °C for 2 h in hydrogen and argon atmospheres. Some of the sintered stainless steel preforms were solution treated at 1050 °C followed by water quenching. The sintered as well as solution treated samples were analysed by metallography examination, Scanning Electron Microscopy and evaluation of mechanical properties. Ferrite content of sintered and solution treated DSS were measured by Fischer Ferritoscope. It is inferred that the hydrogen sintered DSS depicted better density (94% theoretical density) and tensile strength (695 MPa) than the argon sintered steels. Similarly the microstructure of solution treated DSS revealed existence of more volume of ferrite grains than its sintered condition. Solution treated hydrogen sintered DSS A (50 wt% 316L + 50 wt% 430L) exhibited higher tensile strength of 716 MPa and elongation of 17%, which are 10–13% increment than the sintered stainless steels.

Many systems make use of concurrent tasks, however it is often difficult to test concurrent design. Therefore, many test cases are simplified and do not fully test all concurrency aspects of the system. We encountered this problem when analyzing test cases for concurrent flight software at NASA. To address this problem, we developed and evaluated a model based testing (MBT) technique for testing of concurrent systems. Using MBT, the tester creates a model, which is based on the requirements of the system under test (SUT), and lets the computer generate innumerable test cases automatically from the model. We evaluate the effectiveness of the technique using Microsoft's Spec Explorer MBT tool. We apply the technique on NASA's Core Flight Software (cFS) software bus module API, which is based on a concurrent publisher-subscriber architecture style and is a safety-critical system. We describe how we created a test automation architecture for testing concurrent inter-task communication as carried out by the software bus. We also investigate the type of issues the technique for testing of concurrent systems can find as well as what degree of code coverage it can achieve.

There are many technical challenges in ensuring high life-time quality of NASA's systems. Some of NASA's software-related challenges could potentially be addressed by the many powerful technologies that are being developed in software research laboratories. However, most such research technologies do not make the transition from the research lab to the software lab because research infusion and technology transfer is difficult. For example, there must be evidence that the technology works in the practitioner's particular domain, and there must be a potential for great improvements and enhanced competitive edge for the practitioner, for such infusion to take place. NASA IV&V's Research Infusion initiative strives to facilitate such infusion. In 2006, a research infusion project involving Johns Hopkins University Applied Physics Laboratory (JHU/APL) and the Fraunhofer Center for Experimental Software Engineering Maryland, was successfully completed infusing Fraunhofer's s oftware architecture visualization and evaluation (SAVE) tool. The infusion project helped improve JHU/APL's software architecture and produced evidence that SAVE is applicable to software architecture problems in the aerospace domain, spawning a series of related research infusion projects. The project also led to the discovery of other needs that could not be addressed by current technologies and, therefore, spawned the research and development of a new technology that will be ready for infusion in the future. This paper describes the SAVE technology followed by a description of the infusion of SAVE at JHU/APL and the other projects that followed, as well as the newly started Dynamic SAVE research and development project. Lessons learned related to various aspects of research infusion conclude the paper.

We compare manual testing without any automation performed by a tester at a software company with model-based testing (MBT) performed by a tester at a research center. The system under test (SUT), of which two different versions were tested by each of the two testers, is a professionally developed web-based data collection system that now is in use. The two testers tested the same versions, had identical testing goals (to detect defects), had access to the same resources, but used different processes (i.e. manual without any automation vs. model-based with automatic test case generation and automatic test case execution). The testers did not interact with each other. We compare the effectiveness (issues found) and efficiency (effort spent) of the two approaches. The results show, for example, that manual testing required less preparation time and that its test coverage was somewhat uneven. In contrast, MBT required more preparation time, was more systematic, and detected more issues. While the manual approach detected more inconsistencies between specified and actual text labels, MBT detected more functional issues. This is reflected in the severity score summary which was about 60% higher for MBT than Manual.

We are in the process of evaluating the feasibility of using model-based testing (MBT) to test systems. In this paper we discuss the feasibility of testing the software bus of NASA's Goddard Mission Service Evolution Center (GMSEC) using MBT. GMSEC has a flexible architecture making testing a difficult task. The idea is to use one model to test GMSEC for behavioral consistency among multiple programming language APIs and multiple middleware wrappers. Since a new testing approach must be evaluated in the light of the effort it takes to become productive, we measure and discuss costs and benefits. The study demonstrates that it is feasible to use MBT for a system like GMSEC based on the fact that the tester was able to use MBT to detect new issues in GMSEC, which is an already tested system.

We present a case study that evaluates the applicability and effectiveness of model-based testing in detecting bugs in real-world, mission-critical systems. NASA's Operating System ion Layer (OSAL) is the subject system of this paper. The OSAL is a reusable framework that wraps several operating systems (OS) and is used extensively in NASA's flight software missions. We developed a suite of behavioral models, represented as hierarchical finite state machines (FSMs), of the core file system API and generated a large number of test cases automatically. We then automatically executed these test cases against the OSAL. The results show that the OSAL is a high quality product. Naturally, due to the systematic and rigorous nature of MBT, we detected a few previously unknown “corner-case” bugs and issues, which escaped traditional manual testing and code reviews. We discuss the MBT architecture, the detected bugs, the code coverage of generated tests, as well as threats to validity of the study.

New research is underway at the FDA to investigate the benefits of integrating architecture analysis into safety evaluations of medical-device software. Due to the complexity in setting up testing environments for such software, the FDA is unable to conduct large-scale safety testing, instead, it must rely on other techniques to build an argument for whether the software is safe or not. The architecture analysis approach, formalized using relational algebra, is based on reconstructing abstract, yet precise, architectural views from source code to help build such arguments about safety. This paper discusses the use of the formal approach to analyze the Computer-Assisted Resuscitation Algorithm (CARA) software, which controls an infusion pump designed to provide automated assistance for transfusing blood. The results suggest that a) architecture analysis offers many insights related to software quality in general and testability (i.e., the ease of testing) and its impact on safety in particular, and b) architectural analysis results can be used to help configure static analysis tools to improve their performance for verifying safety properties.

Architectural styles impose constraints on both the topology and the interaction behavior of involved parties. In this paper, we propose an approach for analyzing implemented systems based on the publisher subscriber architectural style. From the style definition, we derive a set of reusable questions and show that some of them can be answered statically whereas others are best answered using dynamic analysis. The paper explains how the results of static analysis can be used to orchestrate dynamic analysis. The proposed method was successfully applied on the NASA’s Goddard Mission Services Evolution Center (GMSEC) software product line. The results show that the GMSEC has a) a novel reusable vendor-independent middleware abstraction layer that allows the NASA’s missions to configure the middleware of interest without changing the publishers’ or subscribers’ source code, and b) a high-priority bug due to behavioral discrepancies, which were eluded during testing and code reviews, among different implementations of the same APIs for different vendors.

This paper presents an analysis of the unit testing approach developed and used by the Core Flight Software (CFS) product line team at the NASA GSFC. The goal of the analysis is to understand, review, and recommend strategies for improving the existing unit testing infrastructure as well as to capture lessons learned and best practices that can be used by other product line teams for their unit testing. The CFS unit testing framework is designed and implemented as a set of variation points, and thus testing support is built into the product line architecture. The analysis found that the CFS unit testing approach has many practical and good solutions that are worth considering when deciding how to design the testing architecture for a product line, which are documented in this paper along with some suggested improvements.

In this paper, we report on our experiences with architecture compliance checking - the process of checking whether the planned or specified software architecture is obeyed by the running system - of an OSGi-based, dynamically evolving application in the office domain. To that end, we first show how to dynamically instrument a running system in the context of OSGi in order to collect run-time traces. Second, we explain how to bridge the abstraction gap between run-time traces and software architectures, through the construction of hierarchical Colored Petri nets (CP-nets). In addition, we demonstrate how to design reusable hierarchical CP-nets. In an industry example, we were able to extract views that helped us to identify a number of architecturally relevant issues (e.g., architectural style violations, behavior violations) that would not have been detected otherwise, and could have caused serious problems like system malfunctioning or unauthorized access to sensitive data. Finally, we package valuable experiences and lessons learned from this endeavor.

How to introduce software product line engineering (PLE) in the presence of existing stand-alone similar systems remains a challenging question for many organizations. This paper reports on a reverse engineering approach to understanding the organizational aspects during the product line planning phase. The organizational aspects include domain expert identification, understanding the organization?s development or team structure, and predicting the existing product architecture using the organization?s architecture. In addition, this paper highlights how the source code change history log provides valuable data for various product line related activities, such as scoping, architecture evaluation, reengineering towards product line and project management in the product line context. The proposed approach is validated by means of the engine control systems of Hitachi. The results show that change history can be used to identify experts of the system or components, among other things.

Engine Control Systems (ECS) for automobiles have many variants for many manufactures and several markets. To improve their development efficiency, exploiting ECS commonalities and predicting their variability are mandatory. The concept of software product line engineering meets this ECS business background. However, we should carefully investigate the expected technical, economical, and organizational effects of introducing the strategy into existing products. Thereafter, a strategy will be derived systematically and realize the desired benefits.This paper reports an experience with the up-front investigation performed for Hitachi's ECS. We focus on the approach to plan the migration of the existing family of individual systems into a future product line. The approach assesses potential ways of merging software from existing variants and eventually defines a procedure for performing the migration. To get a high quality strategy, we integrate the approach of software measurement, the expertise of software architects, and reverse engineering techniques.

The decision of an organization to introduce product line engineering depends on a sound and careful analysis of risks and return on investment. The latter is computed by an economic model, which relies on high quality input and must reflect the envisioned migration strategy sufficiently. To facilitate risk analysis, this paper applies Monte-Carlo simulation to an existing product line economic model. Additionally, the model is extended by the support of product line generations that is, considering the degeneration of product line infrastructures and taking reinvestment into an existing product line into account. The practical application of the model is demonstrated by an industrial case study.

Engine Control Systems (ECS) for automobiles have numerous variants for many manufactures and different markets. To improve development efficiency, exploiting ECS commonalities and predicting their variability are mandatory. The concept of software product line engineering meets the business background of ECS. However, we should carefully investigate the expected technical, economical, and organizational effects of introducing this strategy into existing products.This paper explains an approach for assessing the potential of merging existing embedded software into a product line approach. The definition of an economically useful product line approach requires two things: analyzing return on investment (ROI) expectations of a product line and understanding the effort required for building reusable assets. We did a clone analysis to provide the basis for effort estimation for merge potential assessment of existing variants. We also report on a case study with ECS. We package the lessons learned and open issues that arose during the case study.

To establish software reuse successfully in the long run, it is crucial for providers of reusable components to continuously react on problems or future trends arising around their component. In practice, however, many providers of reusable components are not able to do so due to insufficient feedback and details from reusers. Additionally, they often have too little knowledge on system context and constraints that may lead to major deficits of the reusable component especially with respect to non-functional aspects. This paper presents an approach for systematically engineering performance of reusable components that has been validated in an industrial context.