RELIABILITY PREDICTION FOR ARMY VEHICLE

Army vehicles are complex due to various on-board mission critical communication devices. The Army cannot afford unreliable software to interact between the devices. The Army vehicle software’s reliability is influenced by multiple factors during or prior to its development. Using complex statistical and mathematical models, software’s reliability can be predicted, but it is dependent on the accuracy and context of the historical software failure data. The cost of developing such complex models does not yield a good return on investment. The data collection process to use these models is very difficult and time consuming. In this paper, we propose reliability metrics based on the current software development and design process factors. We also propose a fuzzy logic based software reliability prediction algorithm using the proposed reliability metrics. INTRODUCTION Software reliability is one of the growing challenges for the on-board devices in an Army‟s combat vehicle (CV). During combat missions, soldiers perform complex operations using the devices. Each device has its own software and we refer to it as Army vehicle software (AVS). Combat command and control, and vehicle management are some examples of AVS. An AVS performs its intended functions when needed. This allows defending against the enemy threats and protecting the soldiers. Therefore, AVS reliability is a key factor for successful missions. An AVS is considered reliable when it exhibits all its designed features with no defects at all times when it is operated in multiple predefined environments and conditions. We use the term AVS reliability to refer to a probability of defect-free condition for a given AVS. As the probability of defects increases, the AVS reliability decreases. Normally, testing reveals software defects and the developers correct them before it is used in practice. This process assures that the software is reliable when it is used in a combat mission. However, fixing the defects after they are found during testing is costly; it is always better to apply efficient techniques during early development phases and avoid future defects in the software. For early development phases, researchers have proposed several complex mathematical and statistical techniques to predict the probability of future defects in the software. These techniques require skilled resources to use them. The Army tends to react to a dynamic situation and they need easy to understand software reliability prediction techniques. Multiple factors during a software development process influences AVS reliability. The Army pays considerable attention to predict AVS reliability using easy to understand techniques. The AVS reliability measures software quality. Ensuring AVS reliability is absolutely essential [1]. Software architects develop IT architecture documents (ITAD) during early design phases of an AVS development project. ITAD reflect how the software will be implemented and tested. Therefore, ITAD captures necessary details for a successful software development project. We can investigate ITAD and formulate reliability metrics and then use them to develop AVS reliability prediction techniques. In this paper, we propose the following: 1. Deriving AVS reliability metrics from ITAD. 2. AVS reliability prediction algorithm using fuzzy logic and the derived AVS reliability metrics. Our research is in its initial stages. In this paper, we introduce our approach and an initial solution to predict AVS reliability. We describe the proposed solution in this paper using an example dataset that we developed to introduce the concept. We are in the process of validating our work for a practical AVS development project. RELATED WORK Most of the architecture related predictions surveyed in [2] are dependent on the software structure or the type of modeling languages used. Proceedings of the 2011 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS) Software reliability prediction for Army vehicle. UNCLASSIFIED: Dist A. Approved for public release Page 2 of 9 Mohanta et al. provide an approach in [3] to derive design metrics and use them in a Bayesian Belief Network to predict software reliability. In this approach, the prediction accuracy depends on the accuracy of how well the design metrics are derived. In many cases, it is overkill and restrictive. Wang et al. recommend a state model framework in [4] using software architecture as a basis for reliability prediction. In this approach, designers create a Unified Modeling Language (UML) state model for individual components of a software program and then solve a Markov Chain process problem to predict reliability. Although this is a good approach, dissecting the UML architecture to identify its structure to evaluate future problems is cumbersome and error prone. It also has a dependency on the type of architecture style used to document software architecture. Goseva-Popstojanova et al. propose a prediction method [5] using component interaction within software architectures. This method is based on analytical approaches using control graphs. Possible execution paths within software programs are also used to predict reliability. Identifying and analyzing the architecture construct is time consuming and complex. It also depends on the style used to develop software architectures. Gokhale et al. provide a framework for predicting software reliability [6] using composite models built from individual architecture components and their failure behavior. A prediction using this method is accurate only when one understands all the component interfaces and their failure behaviors. The model used in this approach is too analytical and it is very hard to collect data and process it to predict reliability. Nagappan et al. provide a list of metrics [7] for early software tests and reliability early warning. But most of the metrics are derived after the software and test cases are written. So, the early prediction here only serves to predict reliability before the software is fielded and used in practice. Smidts et al. recommend a fault tree based Bayesian quantification framework [8] to evaluate software reliability using software functional architectures which represent both functional and non-functional requirements. This framework concentrates on studying or experimenting with software which is already developed. This cannot be used for early predictions. Kong et al. provide a cause and effect Graphing Analysis [9] approach for early software reliability prediction by identifying errors in the software requirements specification (SRS) document. Every SRS document is written differently, and this method does not provide any techniques to identify defects in terms of incompleteness, inconsistencies, ambiguities, and redundancies in each software requirement. Yacoub et al. propose a scenario based reliability analysis [10] technique for component-based software using the pathbased approach introduced in [5]. This approach models component interactions using a component-dependency graph. This technique is too analytical and the complexity grows as the number of components within the software increases. Furthermore the data collection process is cumbersome. AVS RELIABILITY METRICS ITAD captures the information required to transform user requirements into tangible implementation. Some ITAD are pure text documents and some are built using modeling languages such as UML. ITAD describes requirements realization without providing low level implementation details. The developers use ITAD for developing specific solution designs. At any point of time during a software development project, any person with ordinary computer skill can take a snapshot of information from ITAD and derive fault handling (F) mechanisms, data handling (D), interoperability (I), and configurability (C) details documented in the ITAD. AVS project managers can use the derived „D‟, „I‟, „C‟, and „F‟ values as metrics at any phase of an AVS development project and then use them to predict AVS reliability. Project managers can rectify issues and predict reliability again to determine if the reliability has improved. We describe how to derive AVS reliability metrics using ITAD information in next few sections. Data handling (D) We can quantify data handling to represent the understanding of the required data and its characteristics, and the test cases planned for them. Using this, we can determine the impact of „D‟ on AVS reliability. As the „D‟ value calculated from (1) increases, the AVS reliability decreases.