RELIABILITY MANAGEMENT AND FAILURE MAINTENANCE OF COMPONENT BASED SOFTWARE SYSTEMS R.Chinnaiyan 1, Dr.S.Somasundaram 2

Transcription

1 Address for Correspondence 1 *Assistant Professor, Department of Computer Applications,A.V.C. College of Engineering, Mayiladuthurai, INDIA 2 Assistant Professor, Department of Mathematics, Coimbatore Institute of Technology, Coimbatore, INDIA vijayachinns@gmail.com, somos2005@gmail.com ABSTRACT Research Article RELIABILITY MANAGEMENT AND FAILURE MAINTENANCE OF COMPONENT BASED SOFTWARE SYSTEMS R.Chinnaiyan 1, Dr.S.Somasundaram 2 The software industry has expanded during the past few years and the growth has mainly focused on a growing market and the development of component based software systems. Different designs have emerged and the technical knowledge makes it possible to put component based software off shore. The fast expansion of the software market has also come with some problems. The new designs are not always fully tested, and the designed lifetime of 20 years is typically never achieved until the next generation of software is erected. The extreme conditions and the high loads that software is exposed to makes the coordination of maintenance an interesting issue. How much maintenance is needed? Are there any ways of minimizing the maintenance and yet have a good availability for the software? The technical availability of software is high, around 98%, but this is due to fast and frequent service and not just because of good reliability or maintenance management. The problem area for the proposed work, is focused on the reliability for the components of the component based software system. If the most critical software components for the software system can be identified, it will show in what areas to focus when planning the maintenance for the software system. If the condition of these critical software components can be supervised, the maintenance can be planned even further. Investigations of failure statistics from different sources reveal the reliability performance of the different software components within the software. The failed component is found to be the the most critical as the downtime per failure is high in comparison to the other components in the software. To reduce the risk of a failure, the monitoring of the software component is required. One way of monitoring the performance of the software component is by using a State Monitoring System (SMS). The presented method uses a State Monitoring System for managing reliability and failure maintenance of component based software systems KEYWORDS Software Component, Reliability, Maintenance, Down-Time, SMS 1. INTRODUCTION Component Based Software reliability can be defined as the probability of failure-free operation of all the components of the software package are executing in a specified environment for a specified time. Component- Based Software Engineering (CBSE) is a specialized form of software development for building software from existing by assembling them together in an interoperable manner. Development of highly reliable component based software application is a difficult task, even when high quality, pre-tested, and trusted software components are composed together [14]. As a result, several techniques have emerged to evaluate the reliability of component-based software systems. Systemlevel reliability estimation. Reliability is estimated for the application as a whole. Component-based reliability estimation. The reliability of component based software is managed using the reliability of the individual software components and their interconnection mechanisms. The first approach treats the

2 software system as a unit. This approach is not the most suitable for component-based software system because it not considering the compositional properties of systems, and not accommodating the reliability growth of individual software components. The various restrictions of software system-level approaches for component-based software systems are discussed in [2]. In the second approach, two issues arise. The first is about estimating the reliability of individual software components, and the second is about evaluating the reliability of the software system by combined reliabilities of all software components. This paper deals with the second problem, the analysis of the reliability of a component-based software system as a function of its constituents. The presented method uses a State Monitoring System for managing reliability and failure maintenance of component based software systems. A numerical example is shown with both actual and simulated datasets and the applicability of proposed model is demonstrated through real software failure count data sets. 1.1 State Monitoring System A State Monitoring System, SMS, is a tool for informing about the state of the software components in a component based software system. SMS are used today in many other applications but in the software industry the SMS is relatively new. With SMS a prediction of impending failure is given for each software component, and therefore maintenance and repairs can then be better scheduled. The SMS used today are capable of detecting failures well in time prior to a failure and they are even able to predict which software component inside the software is defective. As a conclusion of this proposed work, it has been found that the failed software component is one of the most critical components that influence the downtime the most. It is also shown that state monitoring systems of today are able to supervise the software components adequately. The theoretical implications of using state based maintenance together with state monitoring systems shows great benefits and the overall conclusion is that the use of SMS is beneficial when it comes to reducing the amount of failures of the component based software and also when it comes to scheduling the preventive maintenance. 2. SOFTWARE RELIABILITY IEEE defines Software Reliability Management as The process of optimizing the reliability of software through a program that emphasizes software error prevention, fault detection and removal, and the use of measurements to maximize reliability in light of project constraints such as resources, schedule and performance. Software reliability is often defined as the probability of failure-free software operation for a specified period of time in a specified environment. Over the past 30 years, many software reliability growth models (SRGM) have been proposed for estimation of reliability growth of products during software development processes. Using these definitions, software reliability is comprised of three activities: 1. Error prevention 2. Fault detection and removal

3 3. Measurements to maximize reliability, specifically measures that support the first two Activities 3. SOFTWARE MAINTENANCE METHODS Maintenance is required for almost all types software system. The type of maintenance that is performed can be defined as either preventive or corrective maintenance. Preventive maintenance is carried out at predetermined intervals or according to prescribed criteria and is intended to reduce the probability of a failure. Corrective maintenance is carried out after a failure and is intended to repair the system. [3] In other words, preventive maintenance is performed before a failure and the corrective is preformed after the failure occurs. Consequently the challenge in planning the maintenance is to decide on when to perform preventive maintenance. Three different methods for maintenance methods are presented in this paper; corrective maintenance and two types of preventive maintenance; scheduled maintenance and state based maintenance. 3.1 Corrective Maintenance Corrective maintenance is defined as [3]: Corrective maintenance - Maintenance carried out after fault recognition and intended to put an item into a state in which it can perform a required function. This type of maintenance is often called repair and is carried out after the failure of a software component. The purpose of the corrective maintenance is to bring the software component back in to a functioning state as soon as possible, either by repairing or replacing the failed software component [2]. To only use corrective maintenance is seldom a good solution. This means that software system will run until a breakdown occurs and in some literature this is referred to as a breakdown strategy. [4] Figure 1. Classification of Maintenance Figure 2. Corrective Maintenance With a breakdown strategy the preventive maintenance is reduced to a minimum and the software system will be operated until a major failure of a software component occurs which

4 will result in a shutdown of the software system. This strategy is risky, since failures of relative small and dispensable software components can lead to severe consequential damages. Another aspect of such a strategy is that most software component failures are likely to be related to the actual program path of the software system and is also likely to happen during high satisfying conditions. This means that the shutdown of the software is related to high satisfying periods. With no knowledge of the consequence of a failure until it occurs makes it impossible to calculate the costs of replacements. The lifetime of the software component is unpredictable and only once the software component has failed can an assessment of the cost and lifetime be made. [5] 3.1. Preventive Maintenance Preventive maintenance is defined as [3]: Preventive maintenance Maintenance is carried out at predetermined intervals or according to prescribed criteria and intended to reduce the probability of failure or the degradation of functioning of an item. The preventive maintenance is performed regularly to postpone failures or to prevent failures from occurring. There are two different types of preventive maintenance; the scheduled maintenance and the state based maintenance. What differs between these two are the way of deciding when to perform the preventive maintenance Scheduled Maintenance Scheduled maintenance is defined as [3]: Scheduled maintenance- Preventive maintenance carried out in accordance with an established time schedule or established number of units of use. Scheduled maintenance means that preventive maintenance is carried out in accordance with an established time schedule [3]. The time-schedule for the preventive maintenance can be either clock-based or agebased maintenance. Clock-based maintenance means that the preventive maintenance is carried out at specified calendar times and age-based maintenance means that the maintenance is carried out when a software component reach a certain age. The age does not need to be calendar time, but measured in for example revolutions or operational time etc. [1] Figure 3. Scheduled Maintenance Preventive maintenance performed at scheduled intervals should be designed to reduce the probability of failures. Maintenance cycle times will be matched to the requirements of the software system. The software system will be

5 inspected and maintained periodically,. The software components that first show sign of wear and fatigue will be maintained and replaced. This type of maintenance strategy means that software components exposed to wear will be replaced regularly even if they are not at the end of their lifetime. Scheduled maintenance requires regular access to the software system and a big share of the costs for the maintenance will stem from the supply for software maintenance personnel. The advantage of preventive maintenance is that it can be scheduled ahead of time and the coordination of logistics can be made easy. [5] 3.2. State based maintenance State based maintenance is defined as [3]: State based maintenance Preventive maintenance based on performance and/or parameter monitoring and the subsequent actions. Performance and parameter monitoring may be scheduled on request or continuous. State based maintenance is a type of preventive maintenance that is based on the performance and monitoring of parameters from the software system. With this type of preventive maintenance, monitoring equipment collects software system s data. The state monitoring may be scheduled, on request or continuous. The collected software system data can indicate required maintenance prior to predicted failure. Maintenance is initiated when a state variable approaches or passes a threshold value. The software system components will be operated to a defined state of wear and fatigue. When this state is reached, the software component needs be maintained or replaced. [4] Examples of state variables that the software system monitors are input, program path, outputs of the software component etc. The ability to monitor the state of software components facilitates planning of maintenance prior to failure and will minimize downtime and repair costs. The software components will be used closer to their lifetimes and the coordination of software components will be easy. Another benefit of implementing a state based system is that trends and statistical data such as mean time to failure can be provided.[5].the statistical data from state monitoring system is important for getting reliable data for remaining lifetime of software components in the component based software system. With site specific data the prediction of remaining time for the software components can be more precise. Figure 9 shows an example of state based maintenance along with corrective and scheduled maintenance Comparison of software maintenance methods Figure [3] shows a graphical example of possible scenarios for maintenance. The comparison shows that scheduled maintenance is performed more often than state based maintenance. The example also shows that the lifetime of the software component is not fully used in the scheduled maintenance compared to the use of corrective- or state based maintenance. Table 1 shows some advantages and disadvantages found for the different maintenance methods when applied to component based software system

6 Table 1. Advantages and Disadvantages of Maintenance Methods Method Advantages Disadvantages Corrective Maintenance Low maintenance costs during operation. Software Components will be used for a maximum lifetime. High risk in consequential damages resulting in extensive downtimes. No maintenance scheduling is possible. Long delivery periods for parts are likely. Preventive Maintenance Scheduled Preventive Maintenance - State based Expected downtime is low Maintenance can be scheduled. Spare logistics is easy Software Components will be used up to almost their full lifetimes. Expected downtime is low. Software Maintenance activities can be scheduled. Spare part logistics is easy given that a failure can be detected early in time. Software Components will not be used for maximum lifetime. Software Maintenance costs are higher compared to corrective maintenance. Reliable information about the remaining lifetime of the software components is required. High effort for state monitoring hardware and software is required. Cost of another layer in the system. Not a mature market for monitoring systems within the Software System. Identification of appropriate state threshold-values is difficult Software Maintenance strategy With the three methods presented a maintenance strategy can be implemented. The strategy will be a combination of preventive and corrective maintenance. The use of state based monitoring tool makes the state based maintenance a good option as to reduce cost related to maintenance. The lifetime of the software components can be almost completely utilized. The use of state based maintenance is relatively new within the software system 3.5. Software Measurements To be able to acquire useful information about the performance of a software system or software component, some measurements of the reliability and availability have to be used. Later in the analysis of data form the component based software system these measurements will be used in order to compare different software components and different software systems for measuring and managing the reliability 4. RELIABILITY PERFORMANCE MEASUREMENT The component based software reliability can be measured in many ways depending on the particular situation, for example as: Mean time to failure or number of failures per time unit or failure rate. [1] The mean time to failure, MTTF, is defined as the mean time between initial operation and the first occurrence of a failure or malfunction, as the number of measurements of such time on many pieces of identical equipment

7 approaches infinity. When a failure has occurred the item is repaired and put back into operation and the item is then considered as fully functioning. The mean down time, MDT, is defined as the average time that the system is not functioning when a software component is being repaired, and is basically the time it takes to repair a failure. The mean time between failures, MTBF, takes into account the mean time to failure and the mean down time. The down time is usually much shorter than the time of operations and then the two measurements can be viewed as: MTTF MTBF Figure 4: Reliability Performance Measurement 4.1. Measurements of availability performance The availability performance is defined as: the ability of an item to be in a state to perform a required function under given conditions at a given instant of time or during a given time interval, assuming that the required external resources are provided Maintenance terminology, SIS 2001 [3] By using the measurements of reliability performance, i.e. MTBF and MTTF, the availability for the system can be described as the portion of operational time, MTTF, over a nominal period of time, in this case MTBF, given that the time t approaches infinity. In Equation 1 the equation for such a measurement of availability is shown MTTF MTTF Availability= = MTTF+ MDT MTBF The measurement of availability differs within software systems. A commonly used measurement of availability is the amount of operational time divided by the nominal time, using Equation 2. The nominal time is usually a period of one year and then the availability is presented as percentage of operational time per year. Nom. Time DownTime Availability= DownTime Another way of expressing the availability is to eliminate downtimes not caused by the component based software, such as external failures of the grid, using Equation 5 NomTime. ( DownTime DowntimeLCausedbyComponentFailures ) Availability = DownTime..5

8 A third option to use for availability is to not use the nominal time of one year but the actual available operational time. E.g. The available operational time is only when the software is in running stage and not when it has been stopped. Unavailability is the period which the software system is not functioning. This can be scheduled downtime (maintenance) or unscheduled downtime (malfunction or failure) Software Component Failure Restore When a software component failure occurs, a typical procedure for handling the failure may look like this [15], [16]; 1. A failure occurs inside the Component Based Software System, e.g. the software component fails. 2. The program path inside the software component either the failure directly or the consequence of the failure and acts according to what type of failure has occurred. In case of safety hazard or major damage, the software system is shut down. 3. If the program path is remotely monitored a warning message is sent to the error controller of the software system. 4. If a major failure has occurred, maintenance and software personnel have to be contacted to repair the damage or replace the damaged software components. When a major failure has occurred a report is filed describing which software component that was involved and possible causes and the downtime related to the failure. 5. The report is maintained and transformed into databases by the persons responsible for gathering the statistical data. 5. NUMERICAL ILLUSTRATION To illustrate the proposed approach, the failure count data sets of Calendar, Thunderbird and Xen are taken. Calendar, Xen and Thunderbird have been developed under Mozilla project. The fault detection data used in this paper are collected in the bug tracking system on the each website. The failure dataset of software components for each component based software system are shown in the Tables 1, 2 and 3. Table 2. Failure Data of Software Components in Calendar Component Name Critical Faults Specific OS Fault Fault Reporter Repairer Base CalDAV Provider General Help Installer bical Security Stoarge Provider Average Failures

9 Figure 5. Failure Frequency of Software Components in Calendar Failure Frequency of Software Compoents in Calendar 76 1 Base CalDAV Provider General Help Installer Libical Security Stoarge Provider Table 3. Failure Data of Software Components in Thunderbird Component Name Critical Specific Fault Fault Faults OS Reporter Repairer Account Manager Address Book General Help nn Installer Frond End Migration Preferences Average Failures Figure 6. Failure Frequency of Software Components in Thunderbird Failure Frequency of Software Compoents in Thunderbird Account Manager Address Book General Help nninstaller Frond End Migration Preferences 30

10 Component Name Table 4: Failure Data of Software Components in Xen. Critical Faults Specific Fault Reporter Fault Repairer Guest OS Hardware Assistance Hypervisor Tools Unspecified Average Failures Figure 7. Failure Frequency of Software Components in Xen Failure Frequency of Software Compoents in Xen Guest OS Hardware Assistance Hypervisor Tools Unspecified 33 Table 5. Failure frequency and Downtime for the component based software system Findings Calendar Thuderbird Xen Average number of failures Average downtime Total Number of failures Most number of failures 6. CONCLUSION General Base Libical The results shown that the critical software component concerning both failure frequency General Front End Address Book Hypervisor Tools Guest O/S and downtime for the component based software system within three different tools Calendar, Thunderbird and Xen from Mozilla Project. The

11 frequency of failure is not as high compared to other software components but the downtime is much longer than any of the other part of the software. It is therefore essential to be able to quickly replace or repair the software component after failure. The use of a good maintenance plan together with the possibility to predict the failure is a way of decreasing the impact of a software components failure. The State Based Monitoring System provides a tool for predicting failure of the component based software system. This solutions is applicable to any kind of software that is built under component based development methodology and is a good tool for predicting the State of Reliability Management and Failure maintenance of Component Based Software Systems, though it cannot be emphasized enough that the use of state monitoring also require a well functioning maintenance program REFERENCES [1] S. Gokhale et al., Reliability simulation of component-based software systems, in Proc. 9th Int. Symp. Software Reliability Engineering (ISSRE 98), Paderborn, Germany, Nov. 1998, pp [2] J. Horgan and A. Mathur, Software testing and reliability, in Handbook of Software Reliability Engineering, M. R. Lye, Ed. New York: McGraw-Hill, 1996, ch. 13, pp [3] T. Khoshgoftaar et al., Identifying modules which do not propagate errors, in Proc. IEEE Symp. Application-Specific Systems and SoftwareEngineering&Technology (ASSET 99), Richardson, Texas, Mar , 1999, pp [4] Certifying off-the-shelf software components, IEEE Comput.,pp , June [5] S. Krishnamurthy and A. P. Mathur, On the estimation of reliability of a software system using reliabilities of its components, in Proc. 8th Int. Symp. Software Reliability Engineering (ISSRE 97), Albuquerque, New Mexico, Nov. 1997, pp [6] M.R. Lyu, Handbook of software reliability engineering, IEEE Computer Society Press, [7] J.D. Musa, Iannino, A. & Okumoto, K., Software reliability: measurement, prediction, application, McGraw-Hill, New York, [8] A.L. Goel, K. Okumoto, Time-Dependent error- Detection Rate Model for Software Reliability and Other Performance Measures. IEEE transactions on Reliability, R-28(3): , [9] Mozilla Calendar, Calendar, [10] The Mozilla Thunderbird Mail Project, Thunderbird, /thunderbird/ [11] H. Singh et al., A Bayesian approach to reliability prediction and assessment of component based systems, in 12th IEEE Int. Symp. Software Reliability Engineering (ISSRE 01), Hong Kong, Nov. 2001, pp [12] H. Jin and P. Santhanam, An approach to higher reliability using software components, in 12th IEEE Int. Symp. Software Reliability Engineering (ISSRE 01), Hong Kong, Nov. 2001, pp [13] D. Hamlet et al., Theory of software reliability based on components, in 23rd Int. Conf. Software Engineering, Toronto, Canada, May [14] M. Heimdahl et al., Specification and analysis of intercomponent communication, IEEE Comput., pp , Apr [15] A. Whittaker and M. Thomason, A Markov chain model for statistical software testing, IEEE Trans. Software Eng., vol. 20, no. 10, pp , Oct [16] A. Whittaker, K. Rekab, and M. Thomason, A Markov chain model for predicting the reliability of multi-build software, J. Inform. Software Technol., vol. 42, no. 12, pp , Sept