XML schema based faultset definition to improve fault ...

4 downloads 106 Views 520KB Size Report
auto-motion control system of bigger bank systems or those of telecommunications. Sometimes many human lives depend on the correct functioning of these ...
Int. J. , Vol. x, No. x, xxxx

1

XML schema based faultset definition to improve fault injection tools interoperability Antonio da Silva, Alberto González-Calero, José F. Martínez, Lourdes López, Ana B. García and Vicente Hernández Department of Telematics’ Engineering and Architectures, E.U.I.T. de Telecomunicación, Universidad Politécnica de Madrid, Campus Sur, Crta Valencia km 7, 28031, Madrid, Spain E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] Abstract: Software Implemented Fault Injection tools (SWIFI) use fault injectors to carry out the fault injection campaign defined in a GUI-based application. However, the communication between the fault injector and the application is defined in an ad-hoc manner. This paper describes an XML schema formalization approach for the definition of fault sets which specify low level memory and/or register value corruptions in embedded microprocessor-based systems and resource usage faults in host based systems. Through this proposed XML Schema definition different injectors could be used to carry out the same fault set injection. To validate this approach an experimental tool called Exhaustif®, consisting of a GUI Java application for defining the fault sets and injection policies, one injector for Windows hosts systems and two injectors for Sparc and i386 architectures under RTEMS have been developed. Keywords: XML Schema, fault injection, fault triggers, experiment reproducibility Reference to this paper should be made as follows: da Silva, A., GonzalezCalero, A., Martínez, J.F., López, L., García, A.B., and Hernández, V. (200X) ‘XML schema based faultset definition to improve fault injection tools interoperability’, Int. J. of Critical Computer-Based Systems, Vol. X, No. X, pp.XX–XX. Biographical notes: Antonio da Silva is a lecturer in the Department of Telematics Engineering and Architectures (DIATEL) at Technical University of Madrid, Spain. He has over 15 year’s experience of lecturing in the fields of computer architecture, web technologies and formal software development with SDL. He has also worked with radiation tolerant architectures for space applications like ERC32 and real time operating systems and taught software communications training courses at Mannheim HochSchule (Germany). Now his interest areas are those related with fault tolerant techniques and tools for experimental dependability evaluation. Copyright © 200x Inderscience Enterprises Ltd.

Author Alberto Gonzalez-Calero Gonzalez is research assistant at DIATEL and now is working in his degree thesis. Dr. José-F Martínez received his Ph.D. degree in Telematic Engineering from the Technical University of Madrid (UPM) Spain in 2001. He is Associate Professor at DIATEL. His main interest areas are new services for Wireless Sensor Networks, advanced software architectures, component-based distributed applications, and telematic services for Internet new generation. Currently, he is responsible for different Spanish and European public-funded research projects and also research contracts with different IT companies. Prof. Dr. Lourdes López, received her Ph.D. degree in Computers Science from the Technical University of Madrid (UPM) Spain in 1998 on public key infrastructures. From 1991, she is professor in DIATEL and from 2000 deputy Director of the Department. More recently she has also participated in several research projects related to security in Wireless Sensor Networks. Dr. Ana-B García received her Ph.D. degree in Telematic Engineering from the Technical University of Madrid (UPM) Spain in 2002. Her teaching and research experience began in 1998 and she is currently an Associate Professor in DIATEL. Her research interests and expertise comprise Next Generation Multi-service Networks, advanced IP traffic analysis and Wireless Sensor Networks. She has also co-authored several technical reports belonging to research projects, some of them directly related to wireless sensor networks. Vicente Hernández is a lecturer since 1990 in DIATEL. He has lectured on information and communications security, protocols and communications services, software engineering, operating systems and hardware architectures. His main interest areas are technical and legislative topics related to advanced software engineering for Wireless Sensor Networks.

1

Introduction

In current society, computer systems that control any process are receiving more and more importance, from a simple domestic appliance up to the auto-motion control system of bigger bank systems or those of telecommunications. Sometimes many human lives depend on the correct functioning of these applications. The reliability requirements of these kinds of systems cannot be reached exclusively by fault prevention techniques or technologies (design, quality assurance shielding, etc.), since the hypothesis of being able to construct an absolutely fault free system is not realistic (Carreira and Silva, 1998). Therefore, it is necessary to construct systems that are capable of providing the expected fault-free service. It is possible to validate reliability attributes in a system in two ways: theoretical or experimental. The theoretical evaluation is carried out by evaluating the system model, while the experimental validation is carried out by observing the system in normal functioning mode while failures are deliberately instigated.

XML schema based faultset definition to improve fault injection tools interoperability

1.1 SWIFI Tools Software Implemented Fault Injection technique (SWIFI) is very attractive since it does not need specific hardware to carry out the fault injection. In a normal scenario SWIFI tools use software fault injectors to carry out the fault injection campaign defined in a GUI-based application. It can be used to prove the failure tolerance mechanisms of applications, operating systems and, in general commercial off-the-shelf software (COTS) where the source code is not available. The use of COTS and code reuse (Gacek and de Lemos, 2006) is becoming increasingly frequent, which complicates the evaluation of exception mechanisms. Some advantages of SWIFI techniques for fault injection can be highlighted:    

The temporary intrusion can be reduced to the time used in exception handling and it can be inappreciable if temporary restrictions of the tested system are not strict enough. It is possible to carry out many experiments in a simple and controlled way. The experiments are carried out on real hardware. No special equipment is necessary and it is easily adaptable to the tested target system.

The main characteristic of fault injection software is that it is capable of injecting failures into any functional addressing unit by means of software, such as memory, floating point registers, and peripherals. The goal of the fault injection software is to reproduce, in the logical scope, the errors that occur after failures in the hardware. Several tools have been created for fault injection by using pure SWIFI paradigms or in conjunction with hardware debugging resources present in some processors, the generalization for any kind of system being very complex. The following tools stand out: XCEPTION, GOOFI, NFTAPE (Carreira et al., 1998; Aidemark et al., 2001; Stott et al., 2000) . FAU Machine (Höxer et al., 2005) is a virtual machine that emulates PC/AT hardware and its peripherals. It has an advantage over other hardware simulation systems which allow the malfunction of some of their components. The use of virtual machines allows permanent failures to be simulated, which would not be possible by means of SWIFI techniques. The use of hardware debugging mechanisms is very interesting and indispensable for spatial trigger specification and to inject faults during the boot system phase before the operating system has been loaded (Rela et al., 2005) but it presents problems in distributed heterogeneous environments.

Author

In (Bondavalli et al., 2007) a study is done about several fault injections tools from the point of view of measurement theory. Key measurement attributes like repeatability, among others, are evaluated in fault injection tools and experiments. Within the scope of this work reproducibility is the most concerned property. Reproducibility is the property which guarantees that another tool o thirty party can perform or reproduce a fault injection experiment previously done. In order to achieve this it is necessary to increase the level of detail of the faulset to be injected and to specify faultsets in a common and tool independent language to interchange fault injection campaigns. The remainder of the paper is organized as follows: an approach for fault definition based on XML Schema is introduced and analyzed in section 2. Section 3 explains the experimental Exhaustive® workbench with two sample scenarios. Section 4 concludes this paper with the conclusions obtained. 2 XML Schema Formalization for Faults and Corruptions Injection An ontology is a formal and abstract description of a specific application domain, for example they have been applied to hardware faults and dependability concepts (Avižienis et al., 2004; Kitamura and Mizoguchi, 1999; Looker et al., 2005). In order to be processed by machines they must follow rules and lack ambiguities. Moreover they can go from a flat description with few relationships to very large and expressive descriptions trying to capture every possible aspect of a domain. For a computing perspective, ontologies have increased in popularity for two main reasons:  

Application interoperability. Machine reasoning.

There is a little confusion between taxonomy and ontology (Van Rees, 2002). In its simplest form, an ontology is a taxonomy of specific application domain attributes, this helps interoperability but does nothing about machine reasoning. Corruptions are those that may be caused by natural phenomena like Single Event Upsets (SEU) or Electromagnetic Compatibility (EMC) interferences and can cause bit changes in memory, hard drives and network connections, whereas faults are those that may be caused by hardware failures or fault-proof programming. It has been considered that the use of an ontology approach could be a useful mechanism to improve

XML schema based faultset definition to improve fault injection tools interoperability

interoperability between SWIFI tools since they can express those faults in a common way. The proposed Schema organizes faults and corruptions attributes and formalizes them in an XML based description that could be understood by different injectors from different tools. The key attributes list is taken from FARM model introduced in (Arlat et al., 1990). 2.1 Basic Fault and Corruption taxonomy A good characterization of a failure model should allow it to be as versatile as possible, allowing a large number of combinations between the location, trigger conditions, kind of fault or corruption and duration, so that the coverage is complete. The failure model characterization is carried out by limiting where, when, for how long the fault or the corruption has to be injected and which kind of failure has to be made. Some of these requirements can not be implemented by means of pure SWIFI techniques. An injection consists of faults and/or corruptions. A fault allows to intercept system calls by altering the content of the input parameters and/or the returned value or to limit the throughput’s resource on reading, writing or both of them. Fault types that are not OSdependant have been chosen to get a general faults vocabulary suitable for all systems. The runtime behaviour analysis of applications in the presence of faults can discover errors that normal procedures cannot. First, it tests the exception mechanisms and failure handling that in normal circumstances are not sufficiently tested and helps to evaluate the risk, verifying how much defective the system can behave in presence of errors. It must be taken into consideration that most commercial products which include desktop applications and operating systems as Components off the Shelf (COTS) have not been extensively tested. In despite of it, many of these products are used as essential components of critical systems. (Mariani, 2003) presents a taxonomy of component faults that is a general classification of faults in component-based systems. They are syntactic, semantic, non-functional, connector, infrastructure and topology faults. This classification of faults has a little focus on the causes of them and that is precisely where the fault taxonomy presented in this paper is focused. For example a network connection problem could be seen as either non-functional or infrastructure fault. (Brüning et al., 2007; Chan et al., 2007) presents taxonomies for Service Oriented Architectures and for Web Service Composition. In both cases the faults are described from the perspective of the service delivered, for example “binding faults” or “timeout faults”. Again, the taxonomy presented here could be seen as the underlying causes of the faults in those specific application domains.

Author

In the taxonomy described in table 1, it has been defined four types of resource faults: faults on disk files, faults on network connections, faults on memory management and faults on process management. Each fault type has specific faults based on errors and limits. The throughput’s limits in disk and networks operations might not be exactly considered as a fault in the underlying operating system but they are useful to test the system under test behaviour while running in a degraded mode environment. Table 1 shows the faults taxonomy. Table 1 Where

Disk files

Network connections

Memory management

Process management

Faults Taxonomy Which

When

Duration

File not found File read only File access denied File read error File write error File read bandwidth limit File write bandwidth limit File locked File already exists File can not be created Host not found Connection refused Net read bandwidth limit Net write bandwidth limit No ports available No route to host

Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger

Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger

Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger

Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger

Invalid access Invalid address Insufficient memory Page file too small Segment locked

Create process failed Invalid file type Access denied Not enough resources Process file not found

For corruptions injection, this model can corrupt three types of resources: disk files, network connections and memory locations. Each corruption type has several corruption patterns, none of them based on protocols or structures to reach a generic way to corrupt. The corruptions taxonomy is shown on Table 2.

XML schema based faultset definition to improve fault injection tools interoperability

Table 2 Where

Disk files

Network connections

Memory locations

2.2

Corruptions Taxonomy Which

When

Duration

Random corruption Find and replace corruption Replaces regular expressions

Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Always Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger

Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger Permanent Time trigger File action trigger Create process trigger Function call trigger Heap action trigger Logical combo trigger

Random corruption Find and replace corruption Replaces regular expressions

Bitflip Bitmask Function Interception

XML Schema definition

XML is a simple, well documented, straightforward data format that provides the explicitness required by machines to process data. It is a common practice to use XML Schemas in order to create standard vocabularies for multiple and distant disciplines (Babaie and Babaei, 2005; Tolman et al., 2001). Although the proposed XML vocabulary can be defined by using a Document Type Definition (DTD), there are several advantages in using XML Schema. The most significant is that declarations can have richer and more complex internal structures than declarations in DTDs (St. Lauren, 1999). Another advantage is that in XML Schema constraint mechanisms can be found for particular formats, lengths or range of values (Cowan, 2003). From the fault and corruption taxonomy given in the previous section, the specification of an abstract fault or corruption definition is given in terms of an XML Schema. The proposed schema allows to simulate faults of several resources and corruptions of memory locations, disk files or network connections to be specified by applying different corruption patterns, such as changes in the state of a bit (BitFlip), use of a mask (BitMask) or finding an expression and replace it. The injection’s structure is shown on Figure 1.

Auuthor

Figure 1

XML Main M tags rellationship

an be configured (figuree 2): Four diffeerent types of faults can   



Disk faults for a file actionn failure, for example for f openingg, closing, readinng or writiing a file, by setting the disk fault’s f type (TYPE), locatiion of the fille (URL) annd any extraa parameterr if needed. Network faults fo or a commuunication failure, for ex xample wheen trying a conneection, by setting s the network faault’s type (TYPE), taarget host (URL L) and any extra e parameeter if needeed. Memoory faults for f a memoory managem ment failuree, for exam mple when tryingg to get more m memoory, by settting the memory m fauult’s type (TYP PE), and any y extra paraameter if neeeded, for example e lim miting the amouunt of memo ory heap thaat could be requested. r Proceess faults fo or a processs managem ment failuree, for exam mple when creatiing a new process, p byy setting th he process fault’s f typee (TYPE), locatiion of the prrocess (URL L) and any extra param meter if needded.

XML schem ma based faulltset definitionn to improve fault f injection tools interopeerability

Figure 2

XML Faault tags rellationship

To achieve moree flexibilityy the URL tag in disk k and netwoork faults must accept wildcarrds when sppecifying a file path or o host nam me. In the case of neetwork fault host namee could be described d ussing its dom main name or its IP address. a Table 3

Disk, nettwork, mem mory and pro ocess fault types t

Disk files File not founnd File read onlly File access denied d File read error File write errror File read banndwidth limit File write bandwidth liimit File locked File already exists File can not n be created

Nettwork con nnections

Hostt not found Con nnection refusedd Net read bandwidthh limit Net write bandwidtth limit No ports p available No route r to host

Memory nagement man

Invaalid access Invaalid address Insufficient memory y Pagee file too small Segm ment locked

Process ment managem Process maanagement Create proccess failed Invalid filee type Access dennied Not enoughh resources Process filee not found

Auuthor

Figure 3

XML Corruption taags relationship

Three diffferent typess of corruptiions can be configured d (figure 3):  



File corruptionss for a conntent/headeer file chan nge, by seetting the locatiion of the file (URL L) and the corruption technique (random replacce, find and d replace or replace regu ular expresssions). Network corrupttions for anny datagram m change, by b setting tthe target host (URL), the corruptioon techniqu ue (random m replace, find and replacce or replacce regular expressionss) and the direction (oout, in or both). Memoory corrupttions for a memory bit b change, just by seetting the corrupption techn nique (bitflippping, bitm masking or function’s f pparameter intercception).

XML schema based faultset definition to improve fault injection tools interoperability

Finally, the trigger can be used to define when the fault or the corruption must be injected and how long it takes. It describes all the conditions that should be met for a fault to become active or deactivate. A trigger consists of an event or a logical combination of events to start and an event or a logical combination of events to stop. Trigger tags structure is shown in figure 4. Figure 4

XML Trigger tags relationship

To configure an event it is necessary to set the type of the event (TYPE), the number of times that the event happens before it triggers the start/stop condition (MULTIPLICITY) and an extra parameter to adjust each kind of event. The allowed events are:

Author

Table 4

Events Resource

Events

Time since application start FileSystem

Time File open, File read, File write, File close Socket open, Socket read, Socket write, Socket close

Network Memory Heap management Process management Function

Heap alloc, Heap free Create process Function call

Very complex activation/deactivation fault scenarios can be defined with this trigger activation schema. From a single file or network operation to a logical combination of several activation events can be used to define when the fault become active and how long it lasts. The stop trigger example that is shown in figure 4 consists of two events. The first one is a time event that becomes active 15000ms after the application starts, while the second one is a file close operation over the file “c:\web_server\run.cfg”. The multiplicity tag establishes that the operation must take place only one time in order to active the event. The final activation of the trigger is the logical AND combination of both events. If there is no start event, it is assumed that the fault or the corruption starts from the beginning and if there is no stop event, it is assumed that the fault or the corruption is always active. It is important to mention that this triggers schema is not intended for profiling purposes. For every trigger description FIK looks only for the events present in the description in order to activate the fault. Moreover, the fault description is made to test same specific working scenario in a controllable way, even more if the scenario is a distributed one and the purpose is to test the system as a whole. For this point of view not to many events are necessary and the tester must keep in mind the sequence he wants to test and the possibility of events interleaving. For example, to test the failover procedure in a web frontend cluster could be enough with a network fault in the hearbeat connection. The choice of a representative set of faults is a complex task (Barbosa, 2005; Sosnowski, 2006). Nevertheless it is possible to carry out memory corruptions without provoking any failure, maybe because they are not being used by the application or, because the corrupt value is not used and has been rewritten. This subject is not addressed in this work.

XML schem ma based faulltset definitionn to improve fault f injection tools interopeerability

3 Exhaaustif® Exp perimental Tool Exhaustiff® tool (D Da Silva eet al., 2007 7) consists of three principal elements,, see figure 5:   

EEM (Exhaustif Executive M Manager) FIK (Fault Injecttion Kernel)) XML L Faultset deescription

EEM offers a graphical useer interface in order to specify andd program the injecttions of fau ults in an uunderstandab ble and sim mple way, aas well as result vissualizations and inform mation abou ut the tasks carried out.. FIK is a lightweigght softwaree componennt which reesides in thee System uunder Test (SUT) and it has the functiion of injecting faullts. The fa faults and K over a corruptionns defined by the toool operator are sent to the FIK communiication link k like seriaal line or tcp/ip netwo ork connecction in a message using the XML X schem ma previoussly defined. In fact thee original XML Scchema has been imprroved to reeflect new types of ffaults and triggers inn order to apply a them nnot only in embedded systems butt in a host based envvironment. Figure 5

Exhausttif®, arquiteecture and components c s

Auuthor

One FIK F for Wiindows™ bbased host systems s and d two FIKss versions for Sparcc and i386 architecturres were deeveloped. The T Sparc-bbased one gives suppport to a mainboardd based on ERC32 faacilitated byy EADSASTRIUM M (EADS-A Astrium, 20006) and th he i386 baseed version runs on a standard PC mainbo oard. Both aapplicationss work undeer RTEMS (RTEMS, 2006). Onnce started,, the FIK w waits for an n EEM message with ffailures to insert. XM ML messag ges will nott cause com mmunication n overload problems with the system s sincce they are oonly used in n the initial configuratiion phase. Target syystems could be replacced by an ASCII A termiinal and theerefore be able to watch w the fau ult messagee sent to it by b the EEM, moreover the faults messagess can be valiidated againnst the XML L schema. On O the otherr hand the same term minal can bee used to seend a hand edited e XML L fault mess age to the FIK locatted in a file without EE EM participaation. 3.1 Fauult injection example Figure 6

Faults in njection expperimental setup s

This example, figure 6, describes a common system uunder test composedd by two main applicattions runnin ng under Windows™ inn order to show thee basic faullt injection capabilities. The COTS applicat ations are: Windowss Media Plaayer, a typpical audio/video playeer and Tom mcat Web Server, a Java container suppoorting JSP application ns. The exaample has been chosen by its simplicity s an and allows handling h thee faulty sceenario and the associated XML descriptionn in a simple way. Morre complex situations can be deefined but caan’t be easilly described d instead.

XML schem ma based faulltset definitionn to improve fault f injection tools interopeerability

Tomcat is a Java based appplication an nd the faullt injectionn is done interceptiing the sysstem calls made by the t Java Virtual V Macchine. No injection is done insside the Javva bytecodee. All system m calls inteerceptions are madee using dy ynamic binnary instrum mentation techniques, t allowing injecting operating system resouurces usage faults in Jaava applicatiions. Next is i the graphical descripption of faullts, figure 7, that are gooing to be injected and the trriggers assoociated to each fault.. The relatted XML descriptioon for each h injection m message wiith the faults and its ttriggers is shown inn section 3.2. 3 The fiirst messag ge is the fault f descriiption for WMedia and the seecond is thee Tomcat’ss one. For Windows m media the faults andd triggers arre:  

The file fi read ban ndwidth is reeduced betw ween instants T1 and T T2. After instant T3 all file acceess are forbiidden.

For Tomccat WEB seerver the fauults and trig ggers are: 

Everyy attempt to o access a W WMV file will w return “File “ not Foound” OS error even when n those filees exist. This T fault becomes b acctive after w remain active until an access to a html aarchive is instannt T4 and will made.

Figure 7

Faults to o be injecteed and injecttion triggerss

The expected e beh haviour is aas follows. WMedia W is used to opeen a video file. Betw ween instan nts T1 and T T2 the prog grammed file read banndwidth is not enough to play the video file and it begins to be played frame by frame. Affter instant T3 all file aaccesses retturn error an nd file videeos cannot be seen. Later WMeedia networrk capabilitties are used to accesss a WMV mcat but eacch access atttempt returrns file not ffound. To file exporrted by Tom provoke the t stop trig gger an exteernal access is made by internet exxplorer.

Author

3.2 Fault injection messages file://*.* 4000 10000 1 30000 1 file://*.* 50000 1 file://*.wmv 10000 1 file://*.html 1

XML schema based faultset definition to improve fault injection tools interoperability

3.3

Corruption injection example

Next is the scheme of an injection message generated with the specification of two corruptions to be injected. Both are memory corruptions of the memory contents of TEXT section. These corruptions are very dangerous since they modify the original program operational codes modifying the logical flow of the program. From our point of view these faults are worse than DATA section corruptions and more difficult to detect. If the new opcode is an illegal instruction then the associated exception will be raised and the operating system can gain control, but what about when the new opcode is legal? The first one is a memory corruption that consists of a Bitmask, “type=and”, starting at 0x0010001A address and takes place 5 seconds after the application starts. The second one is Bitmask, “type=or”, at 0x00100018 address, 3 seconds after the first one. These faults could simulate the effects of a SEU in the main memory of an onboard computer. But, what do these injections mean? 0x0010001A 5000 1 0x00100018 0x0020 8000 1

Auuthor

Figure 8

Corrupttion injectioon

If the exxecuted cod de was the one in the figure 8, the t memoryy address with the assembly 0x00010118 would correspond c a in nstruction ““add %i0, 0xA0, %i0”. This means m that the first corruption c changes c thee original instructioon to “add %i0, 0x0000, %i0” sin nce it resetss the immeddiate data within the instructio on. In the seecond corru uption, flipp ping just onne bit, the instructioon add becom mes sub. Thhe final cod de instead off adding subbtracts. 4 Summ mary Efficient faultset descriptions d between different fault f injecttion tools require capturing c and a translaating the specific vo ocabulary and data structuress into precisse and strucctured, dom main-specificc descriptioons. These can be acchieved by the use of sttandard marrkup languages that alloow giving a precise definition and meaninng to fault injection terms. This approach minimizees the loss of informaation from one o tool to another annd allows efficient sharing s of fault f injectioon experimeents descrip ptions. This first f modellling of the basic operaating system m services ffaults and basic binnary corrup ptions show ws that the XML-baased fault definition approach improvess the inteeroperability y between n SWIFI tools by uncouplinng the injecctors from the experim ment manag ger in charrge of the fault cam mpaign. Thee design hass been don ne in order that the wiidening to other fauults and corrruptions caan be easily y achieved. XML faullt sets are easy to reead and com mpare not only for machines m butt also for hhumans. It facilitatess communiication andd collaborattion and im mproves exxperiment reproduciibility.

XML schema based faultset definition to improve fault injection tools interoperability

5

References

Carreira, J. and Silva, J.G. (1998) ¿Why do some (weird) people Inject Faults?, Software Engineering Notes, Vol 23 no 1 pp. 42. Gacek, C. and de Lemos R. (2006) Architectural description of dependable systems, In: Structure for Dependability: ComputerBases Systems from an Interdisciplinary Perspective, Lecture Notes in Computer Science 4527. Springer-Verlang, pp. 127-142. Carreira, J., Madeira, H., and Silva, J.G. (1998) Xception: A technique for Experimental Evaluation of Dependability in Modern Computers, IEEE Transactions On Software Engineering, Vol. 24, pp 125-135. Aidemark, J., Vinter, J., Folkesson, P. and Karlsson, J. (2001) GOOFI: Generic Object-Oriented Fault Injection Tool, In Proceedings of International Conference on Dependable Systems and Networks. Stott, D.T., et. al, (2000) NFTAPE: A Framework for Assessing Dependability in Distributed Systems with Lightweight Fault Injectors, Int. Computer Performance and Dependability Symposium, pp. 91-100. Höxer, H.-J., Sieh V., Waitz M. (2005) Fast Simulation of Stuck-At and Coupling Memory Faults Using FAUmachine, In Supplement to Proceedings. HASE 2005: International Symposium on High Assurance Systems Engineering. Rela, M.Z., Cunha, J.C., Silva, C.B., da Silva L.F. (2005) “On the Effects of Errors During Boot”, Proc Second Latin-American Dependable Computing Symposium, LNCS 3747, Springer Verlag. Bondavalli, A., Ceccarelli, A., Falai, L. and Vadursi, M. (2007) Foundations of measurement theory applied to the evaluation of dependability attributes, 37th IEEE/IFIP International Conference on Dependable Systems and Networks (DSN’07) Avižienis, A., Laprie, J.-C., Randell, B., Landwehr, Carl. (2004) “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on Dependable & Secure Computing. Vol. 1, No. 1, pp. 11-33. Kitamura, Y. and Mizoguchi, R. (1999) "An Ontological Analysis of Fault Process and Category of Faults," presented at The Tenth International Workshop on the Principles of Diagnosis, pp. 118-128. Looker, N., Gwynne, B., Xu, J. and Munro, M. (2005) “An OntologyBased Approach for Determining the Dependability of ServiceOriented Architectures”, 10th IEEE International Workshop on Object-Oriented Real-Time Dependable Systems, (WORDS’05)

Author

Van Rees, R. (2002) Clarity in the usage of the terms ontology, taxonomy and classification, CIB W78 Conference. Arlat, J., Aguera, M., Amat, L., Crouzet, Y., Fabre, J.C., Laprie, J.-C., Martins, E., and Powell D. (1990) “Fault Injection for Dependability Validation: A Methodology and some Applications”, IEEE Transactions on Software Engineering, Vol. 16, No. 2, pp. 166-182. Mariani, L., (2003) “A Fault Taxonomy for Component-based Software”, Electronic Notes in Theoretical Computer Science. Vol. 82, No. 6, pp. 55-65. Brüning, S., Weissleder, S., and Malek, M. (2007) “A Fault Taxonomy for Service-Oriented Architecture”. 10th IEEE High Assurance Systems Engineering Symposium, pp. 367-368. Chan, K. S. M., Bishop, J., Steyn, J., Baresi, L. and Guinea, S. (2007) “A Fault Taxonomy for Web Service Composition”. ICSOC Workshops, LNCS 4907, pp. 363-375. Babaie, H.A.; Babaei, A. (2005) Modeling geological objects with the XML Schema, Computer and Geosciences, Vol. 31, pp 1135-1115. Tolman, F.; Stephens, J.; Steinmann, R.; Van Rees, R.; Böhms, M.; Zarli, A. (2001) bcXML, an XML Vocabulary for Building and Construction, European Council of Civil Engineers Conference. St. Lauren, S. (1999) Describing your Data: DTDs and XML Schemas”, O’Reilly xml.com Cowan, C. (2003) An XML Vocabulary for Error Message Documentation, ACM SIGSOFT Software Engineering Notes, Volume 28, Issue 4. Da Silva, A., Martínez J.F., Lopez, L., García A.B. and Redondo, L. (2007) “Exhaustif: A Fault Injection Tool for Distributed Heterogeneous Systems”, ACM DL. EADS-Astrium: www.astrium.eads.net (2008). RTEMS: Real Time Executive for Multiprocesor Systems. www.rtems.org. (2008). Barbosa, R., Vinter, J., Folkesson, P., Karlsson, J., (2005) “AssemblyLevel Pre-Injection Analysis for Improving Fault Injection Efficiency”, Fifth European Dependable Computing Conference (EDCC-5) Sosnowski, J., Gawkowski, P., Zygulski, P., Tymoczko, A., (2006) “Enhancing Fault Injection Testbench”, International Conference on Dependability of Computer Systems, DepCos-RELCOMEX.

Suggest Documents