Model Driven Development

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 58 | Pages: 8

Extension: PDF | Download: 0

Model-driven Automated Software FMEA Neal Snooke, PhD, Aberystwyth University Chris Price PhD, Aberystwyth University Key Words: Failure modes and effects analysis; software FMEA; model-driven software development SUMMARY & CONCLUSIONS This paper describes how software FMEA can be automated both for low-level languages intended for safety critical embedded systems, and also for model-driven software developments. It is possible for a computer to achieve a qualitative analysis of software based o
  Model-driven Automated Software FMEA Neal Snooke, PhD, Aberystwyth UniversityChris Price PhD, Aberystwyth University Key Words: Failure modes and effects analysis; software FMEA; model-driven software development SUMMARY & CONCLUSIONS  This paper describes how software FMEA canbe automated both for low-level languagesintended for safety critical embedded systems,and also for model-driven software developments.It is possible for a computer to achieve aqualitative analysis of software based on tracingdependencies through a body of code. This canreveal the propagation of any failure in thesoftware, whatever the cause of the failure.Application of a higher level representation of theintended purpose of the software can thenautomatically interpret the implications of failurein terms of the requirements put on the software. These techniques have been used to automatethe analysis of several thousand lines of code. They have been shown to provide useful resultsfor software engineers, and would suit embeddedsoftware in vehicles for example. This work is nota cure-all for badly written software, but providesassistance in software analysis for well designedsystems in low-level safe languages such asMISRA C. The software FMEA can be used toimprove automated or source code embeddedtesting since tests can exonerate many potentialfaults allowing the FMEA analysis to present anengineer with a reduced set of potential faults.Model-driven development (MDD) is a softwaredevelopment philosophy which encourages thedevelopment of models of the software to beproduced, for example using a language such asexecutable UML. The system is described in aplatform independent manner, and then thesoftware to be used is automatically generatedfrom the model.In MDD, the models make the intentions of theprogrammer much more explicit than is the casefor low-level programming, and so the gapbetween the intended functions of the system andthe description of the software is not so large.Representation of the design is much more explicitthrough use cases, component diagrams, statecharts and sequence diagrams. All of this designinformation can be utilized for the automatedgeneration of software FMEA. This means thatFMEA for model-driven software can be done moreeasily than for a system implemented in a low-level language, because it is not necessary toattempt to reconstruct the intentions of theprogrammer from the functions of the system andthe low-level code. The paper also discusses theadvantages and dangers of doing such analysis atthe design rather than the code level. 1INTRODUCTION  Typically, FMEA is practiced on physicalsystems, and the failure modes considered are thefailures of physical components, caused by wearor other damage to the system. Since software hasbeen introduced into automotive and aeronauticsystems, it has often been included in FMEAreports as a component with no failure modes (theECU containing the software), and the systemdesign FMEA has been produced assuming thatthe software works correctly. The concept of software failure mode andeffects analysis (software FMEA) has grown inattractiveness over recent years as a way of assessing the reliability of software. Like itshardware counterpart, software FMEA isimmensely tedious for an engineer to perform, aswell as being error-prone. Clearly, softwarecomponents do not fail in the same manner ashardware components — a function or methoddoes not break over time because it has becomeworn or damaged. Software FMEA considers allpotential faults such as faulty inputs or softwarebugs (mutations) that could exist and ensures theworst-case consequences are known, possiblyprompting actions to reduce risk. A software bugmay be treated analogously to a hardwarecomponent failure, the essential difference beingthat hardware failures occur over time whereassoftware bugs exist undetected but usually onlyaffect a very small (untested) region of the overallsystem behavior.One of the unique difficulties with softwaresystems is the complex relationship betweenfaults and effects. A minor fault can, for example,  cause a complete crash of a software system orhave almost invisible but very complex, subtle,and long lasting side effects. The result is thatsoftware often has very non-uniform quality interms of the effects of potential failures, and it isnot clear when effort is available, where it shouldbe expended to improve quality. An FMEA provides just this information allowing targeting of effort atthe highest risk areasCode-level software FMEA has been performedfor some years [1, 2, 3, 4], but has beenconsidered impractical except when applied tosmall pieces of highly critical code, because of itscost. On the other hand, software FMEA of a moreabstract specification of the system can ignoreimportant implications of failures, especially wherecode is not automatically generated from theabstract specification. This paper describes work to automate muchof the effort of performing software FMEA. Itdescribes a novel method for automating code-level software FMEA based on treating theimplemented software as a model of the desiredsystem and propagating faults through the modelto identify dependencies. High level descriptionsof the implications of each failure are producedthrough the use of functional descriptions of whatthe software is intended to achieve. The extension of this work to address theanalysis of software generated from executablemodels built in a language such as executableUML is described, and the implications of doing theanalysis at such a high level are discussed. 2ASSESSING SOFTWARE QUALITY  In much software engineering practice,engineers rely almost exclusively on qualitystandards that define development processes andpractices in order to assess whether qualitysoftware has been produced. While developmentprocesses are vitally important in any engineeringendeavor, they do not guarantee the safety of aproduct, as McDermid [5] has observed.Testing is the primary (and often the only)evidence based analysis performed on software,and although testing can initially  give indicationsof quality, once the results are used to improvethe software, the tests are no longer a reliableindication of overall quality. The value of tests inassessing quality is further reduced by hierarchicaltesting, because lower-level modules willthemselves have been made to pass a set of testsbefore being included in a system. It is likely thatthe system outside the scope of the testsperformed has only the quality achieved at thevery first execution of the code [5].Put another way, testing only finds faults, itdoes not help prevent or assess them. The reasonfor this is clear. Tests can only ever verify a tinysample of the expected behavioral envelope of thesoftware and they are often focused on verificationof nominal function, with perhaps a few limitingcase examples.Other domains such as electrical systemsanalysis also have an infinite number of possiblenumerical behaviors, but other kind of analysis aredone. For example, failure effect analysis is carriedout by abstracting the infinite number of possiblebehaviors into qualitatively similar regions, andconcentrating on a worst case analysis.All substantial software will enterunanticipated regions of behavior during its life,and all software will have to deal with externalfailures either from hardware or other software,and for most software there is limitedunderstanding of how the system might behave.Formal methods are often proposed as thesolution to these problems, but they can bedifficult to use, specification capture remains anissue, and pragmatically these methods are tooexpensive for the majority of software. SoftwareIntegrity Levels are often used to demonstrate aspecific level of integrity [6], however SIL levelspecification most often results in a mechanism tochange product requirements into processrequirements and for higher levels may alsorequire formal methods. These mechanisms are typically veryexpensive to implement and accordingly are usedonly for the highest risk systems, leaving the vastmajority of software development relying solely onthe talent and intuition of software developersalong with testing to verify basic functionality. Testing can be addressed by a variety of means, some of which begin to move towards awider ranging type of analysis that can considerboth more comprehensive and/or abstractbehavioral considerations, for example functionalanalysis testing and cause-effect graph testing.Other types of testing such as statementcoverage, path coverage, and modified conditiondecision coverage can help discover obviousinadequacies in test suites but they cannot reasonabout overall system behavior and potentialfailure modes or problematic operating states.Voas [7] proposed an analysis that identifieswhere faults are more likely to remain undetected,and although based on execution of test, sets it inthe spirit of a broader assessment of quality. The need for lower precision but highercoverage techniques that can reveal more general(good and bad) characteristics and potentialproblems in software has led to investigation of the adaptation of techniques from other areas  such as electrical systems analysis to the needs of software analysis. The next section considers developments inadapting failure modes and effects analysis(FMEA), srcinally applied to physical systems, tothe task of software analysis, and describes howsuch analysis can be automated, providing usefulresults for little effort on the part of the engineer. 3AUTOMATION OF SOFTWARE FMEA Automation of software FMEA is inspired bysuccess in automated electrical system FMEA [8],where automated analysis is now in routine use inthe automotive industry [9]. In that work, theexpected behavior of the system is simulated froma model of the design, and results are abstractedto the level of the function of the system.A comprehensive set of possible failures isidentified from the components that compose thestructure of the system. For each possible failure,the simulation and abstraction is repeated, andthe results with the failure present are comparedwith the results when no failure is present. Thedifference between the two sets of results givesthe system-level effect of that failure. Forelectrical system FMEA, the software producesengineer oriented automated reports giving theconsequences of each potential failure. These techniques can be applied to softwareby treating a piece of software as a model of thedesired system. It is then possible to reason aboutthe ways in which faults can be propagatedthrough the model in order to derive the possiblecauses of a given set of symptoms. There are three facets to the production of auseful report on failures in a piece of software:1.Automated model construction. Techniqueshave been developed capable of automatically constructing a faultpropagation model which can generate allpossible effects of a failure from the pieceof software being analyzed.2.Injection and propagation of faults. Allpossible faults that could occur in thesoftware need to be identified, so that theireffect on the overall system can beexplored. Given a specific fault, the faultpropagation model constructedautomatically from the software can beused to decide what parts of the piece of software could be affected by a specificfault, and in what way they could beaffected.3.Identification of system level effects.Generating a list of all variables affected bya fault would be far too much detail toreport to an engineer. The results areabstracted using the system requirementsas a focus.Each of these three facets will be explained inturn. 3.1Automated model construction  The source code of the software to be analyzedis parsed and transformed into a fault propagationmodel. This is essentially a graph, where thesource code statements are the edges and thevariables are the nodes of the graph. It is thenpossible to use the graph to reason about how theeffect of a fault can propagate through theprogram. This work is clearly programming languagedependent. In the work described here, modelconstruction has been achieved for a large subsetof the JAVA language, but the work would beequally applicable to other imperative languages.Limitations of this approach are discussed later,but generally correspond to the kind of codingrestrictions recommended when constructingsafety-critical software [10].Fault propagation is complicated by the reuseof memory, and this problem has been overcomeby using a Single Assignment Form (SAF) model[11] that transforms each memory write to allowsymbolic memory locations to be logically writtenonly once. SAF is used to generate a graph withdistinct nodes for each value of a variable. This isillustrated for a simple code fragment in figure 1. Figure 1: Code to propagation graph example Fault propagation graphs of the kind shown infigure 1 can be constructed for much morecomplex pieces of code, and used to predict theworst possible implications of any fault in terms of which other parts of the software it will affect.Fault propagation through non-sequentialcode, such as conditions and iterations can be  simplified by assuming worst case scenarios forthe propagation of faults [12]. When thisassumption does not hold, either a set of faults willhave no effect, or an effect will be generatedwhere the engineer knows of applicationconstraints that explain why the failure modescould not happen. 3.2Injection and propagation of faults All software faults can be characterized asfaulty values: ã faulty I/O ã faulty transfer functions (whether due towrong specification or wrongimplementation) ã loss of transfer function (due to crashing orhanging) ã missing outputs ã unexpected outputsIn order to perform an FMEA, it is assumed that any  value can become faulty and the propagationof that faulty value is explored to all statementsthat depend on it. This is achieved by propagatingthe faulty value using the fault propagation modelalready discussed, until the effects on systemoutputs have been derived. The scope and thepath of the propagation define a failure mode. 3.3Identification of system level effects Functional interpretation [13] is a vital part of organizing and abstracting the results of structuraland behavioral analysis into the form of an FMEAreport able to flag significant potential problems.Information regarding the purpose(s) of thesystem is required, and a functional model is usedto provide this information in a principled form. The functional model described in this sectionidentifies the purposes of the system by means of associations with the system interface.We use the following definition of function: Anobject or system O has a function f if it achievesan intended goal (purpose) by virtue of someexternal trigger T resulting in the achievement of an external (behavioral) effect E.  The function interpretation language allowsfunctions to be decomposed into subsidiaryfunctions to build a functional hierarchy. A gooddeal of intuition regarding the function model canbe obtained from an example functionaldescription for a simple travel expenses paymentprogram shown below:FUNCTION pay_expensesACHIEVES pay_money_owedBY run_program TRIGGERS display_expenses_totalAND print_cheque FUNCTION make_envelopeACHIEVES allow_delivery_chequeBY run_programTRIGGERS address_envelopeFUNCTION display_expenses_totalACHIEVES verify_expense_itemsBY show_expense_items_on_screenANDshow_total_on_screenFUNCTION print_chequeACHIEVES transfer_moneyBY print_in_figuresANDprint_in_textANDprint_details The functional model must be linked to thebehavior of the program via the causes (identifiedby BY ) and effects (identified by TRIGGERS ). These will be system inputs and outputs and couldbe memory locations, or ports that influenceexternal devices or system calls at higher levels. The causes and effects from the functiondefinitions need to be mapped onto variables inthe program implementing the functions, eitherglobal variables or instantiated variables. 3.4Application of these techniques  The techniques described here have beenapplied to a payroll program consisting of a fewthousand lines of Java code. This has shown thatthe computation is tractable for useful sizedprograms, and that the results produced are usefulwhen considering the reliability of software. Boththe techniques used and the results obtained aredescribed in greater detail in a longer paperelsewhere [12]. These techniques provide an evidence-basedanalysis that deals with a wide range of possiblebehaviors at a low level of precision. They considerhypothetical faults and determine the possibleeffects assigning significance to them. Anystatement, module, or subsystem is assumed tohave the potential to fail or produce incorrectoutput, and the techniques assess the potentialeffects. The results can be used to identify design orimplementation issues that might lead to faultswith disproportionate or unexpectedconsequences, identifying areas of design orimplementation that allow significant failures tooccur. Engineering effort can then be expended toaddress the most significant faults.
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!