In the context of software dependability, the software veri- fication process has an important role. Formal verification of programs is an activity that can be inserted in this process to improve software reliability. This paper presents the defini- tion of an approach that employs a formal verification tech- nique based on abstract interpretation. The main goal is to apply this technique as a formal activity in the software veri- fication process to help software engineers identify programs faults. The applicability of the proposed approach is demon- strated by a case study based on embedded aerospace control software. The results obtained from its use show that abstract interpretation can contribute to software dependability.Fundação para a Ciência e a Tecnologia (FCT

Arai, Nanci Naomi

Burgareli, Luciana Akemi

Oliveira, José M. Parente

Pinto, Jorge Sousa

Silva, Rovedy Aparecida Busquim e

Universidade do Minho: RepositoriUM

Using Abstract Interpretation to Produce Dependable Aerospace ControlSoftwareRovedy Aparecida Busquim e Silva, rovedyrabs@iae.cta.brNanci Naomi Arai, nancinna@iae.cta.brLuciana Akemi Burgareli, lucianalab@iae.cta.brLaboratorio de Engenharia de Software / Instituto de Aeronautica e Espaco (IAE), BrasilJose M. Parente Oliveira, jparente@ita.brDivisao de Ciencia de Computacao / Instituto Tecnologico de Aeronautica (ITA), BrasilJorge Sousa Pinto, jsp@di.uminho.ptHASLab / INESC TEC & Universidade do Minho, PortugalAbstractIn the context of software dependability, the software veri-fication process has an important role. Formal verification ofprograms is an activity that can be inserted in this process toimprove software reliability. This paper presents the defini-tion of an approach that employs a formal verification tech-nique based on abstract interpretation. The main goal is toapply this technique as a formal activity in the software veri-fication process to help software engineers identify programsfaults. The applicability of the proposed approach is demon-strated by a case study based on embedded aerospace controlsoftware. The results obtained from its use show that abstractinterpretation can contribute to software dependability.1. IntroductionAccidents caused by errors in software are a reality incritical real-time systems. To find faults throughout the soft-ware development life cycle and develop dependable soft-ware, software verification and validation processes must beused. Formal methods, complementary to traditional soft-ware verification and validation methods, are recommendedin standards specifically used in the aerospace area such asECSS-E-ST-40C [9].The formal verification of programs based on abstractinterpretation is the focus of this work. The goal is to com-plement the software testing and simulation activities. Thetesting activity may provide a partial verification of the soft-ware behavior using a subset of selected input data. A test-generation tool would necessarily pick only a subset of thebillions of possible entries to execute the application [7]. Onthe other hand, the results given by a tool based on abstractinterpretation are valid for all the range of values proposedby the user. In this context, the approach presented hereproposes the application of abstract interpretation to verifyembedded aerospace control software by the Frama-C staticanalyzer [7].The paper is organized as follows. Section 2 presentsbriefly the background in formal methods, formal verifica-tion of programs, and abstract interpretation. Section 3 de-scribes the verification approach. Section 4 shows the prac-tical experience. Section 5 presents related works. Finally,Section 6 is the conclusion, with a discussion about specificissues and future work.2. Background2.1. Formal MethodsFormal methods are abstract interpretations, which differin the way the abstract semantics is obtained [4]:- model-checking, where the abstract semantics is ob-tained manually by the user in the form of a finitarymodel of the program execution;- deductive methods, where the abstract semantics isspecified by verification conditions by the user in theform of inductive properties that satisfy (true at eachprogram step, such as loop invariants) these verifica-tion conditions;- static analysis, where the abstract semantics is com-puted automatically using the predefined approxima-tions possibly manually parameterizable by the user.2.2. Formal Verification of ProgramsFormal verification of a program is related to the use offormal methods at the level of implementation of programs.In general, an implementation of program is divided intosyntax and semantics around the programming languages.Most often in the software development process, the devel-opers are concerned with the syntax of a program, and thesemantics is implicitly considered. The main focus is tobuild an executable object source, and the correction of theprogram is obtained through testing and simulation. How-ever, in the context of formal verification of a program, thesemantics has an important role to play in the developmentof software applications because it is concerned with rigor-ously specifying the meaning or behavior of programs. Away to perform formal verification of programs is to usestatic analysis based on abstract interpretation. A static an-alyzer based on abstract interpretation is built by a rigorousmathematical theory.2.3. Abstract InterpretationAbstract interpretation considers abstract semantics,which is a superset of the concrete program semantics. Con-crete program semantics is the most precise semantics thatvery closely describes the actual execution of the programand formalizes the set of all possible executions of this pro-gram in all possible execution environments [4].Abstract interpretation can be understood through twomain views. The first encompasses a semantic to depict theabstract information (derived from concrete semantic) andan abstract function to relate the abstract to the concrete in-formation. The second encompasses an algorithm to evalu-ate the semantic information interactively [3].The basic idea of abstract interpretation is to transformthe program from a concrete domain to an abstract domainto infer results without running the program. Thus, a staticanalysis technique relates abstract analysis to executions ofthe program [5].A static analysis tool based on abstract interpretation isbuilt by combining abstract domains. It applies an abstracttransformer in the program, and an over-approximation ofthe least fix point of this transformer is computed iterativelyby extrapolation operators such as widening and narrowing[1].According to Bouissou [2], static analysis by abstract in-terpretation has been very successful in automatically ver-ifying complex properties of real-time, safety-critical em-bedded systems.3. Proposed Verification Approach3.1 ToolFrama-C is a platform dedicated to the static analysisof source code written in C constructed as plug-ins. Theplug-in of interest is the Value Analysis, which is based onabstract interpretation, and automatically computes sets ofpossible values for the variables of the analyzed program[7]. The Value Analysis/Frama-C can be useful to detectbugs, prove their absence, and get familiar with foreigncode. It is most useful for embedded code because it doesnot demand dynamic allocation and uses few functions fromexternal libraries [7].3.2 ApproachThe verification approach is based on the followingsteps:1. Identifying an analysis context for the case study;2. Adapting the source code to conform to ValueAnalysis/Frama-C execution;3. Running the analysis and refining the results;4. Addressing the alarms.The first step is to identify the analysis context. It is nec-essary to define an entry point for the analysis. The softwaredocumentation is essential to conduct this step.In the second step, it is necessary to adapt the sourcecode: verifying libraries related to the Real Time Opera-tional System (RTOS) and the hardware access as well asthe mathematical functions to detect missing functions thatmust be provided by the appropriate source code.In the third step, the idea is to refine the analyzer results.Because static analyzers based on abstract interpretation arealways sound and always terminate, they are necessarily in-complete [1]. Therefore, false alarms can occur. To improvethe results, arguments can be passed to the analyzer; how-ever, this will cost more time to determine whether eachalarm is true or false.The purpose of the fourth step, is to address the alarms.The process consists of picking an alarm, investigating itscauses, watching variables values, and keeping track of theanomalies encountered as well as the code changes. It couldbe necessary to interact with the developers when severeanomalies are suspected or their causes are doubted.4 Case StudyThe case study is based on a spacecraft with four stagescapable of launching satellites weighing maximum 350 kg2at altitudes up to 1000 km [10]. Its embedded software per-forms the initiation, verification, and control of the vehi-cle. The source code consists of approximately 15 KLOCof C language distributed in 120 files. The selected partof source code is related to the flight control task, which isthe most critical part of the code. For simplification issues,only functions related to the first stage were analyzed. Themain functions in the first stage are navigation and eventcontrol algorithms. The case study has 12306 SLOC, 47statements, 12155 if assignments, 9 loops, 50 calls, 2 gotos,and 3 pointer access. This data are results produced by theMetrics/Frama-C plugin.The case study considered two scenarios where the sen-sor measurements were treated in different ways. The firstscenario considered the maximum range of values acceptedby the sensors. In the second scenario, a different approachwas adopted. All the sensors measurement values obtainedfrom a flight simulation were used as input to the ValueAnalysis/Frama-C.Following the steps of the proposed verification ap-proach, the first activity was to prepare the analysis context.The main function, which is the entry point for the analy-sis, was created. In this step, the Software RequirementsSpecification (SRS), Data Dictionary (DD), and SoftwareDesign Document (SDD) were essential for looking up in-formation. The logic model in the SRS, represented by DataFlow Diagram (DFD), helped identify the input data for thefunctions. For example, the input for the navigation algo-rithm is the flight nominal data and the sensor values thatmust be provided.Following the second step, the first activity was to ad-dress the include files. The method used was to exclude allthe include files of the source code and to include them oneby one in the next executions as required. This way, it waspossible to detect a number of include files that were unnec-essary. Then, the missing functions were addressed. For theRTOS libraries, an implementation of functions was pro-vided with similar behaviors to the real ones. For the sen-sors measurements, the analysis was parameterized addingnon-determinism through the Frama C float interval andFrama C interval functions. For the hardware output,functions were created to examine the intermediate resultsthrough the tool functions. For mathematical functions,functions from the Frama-C itself were used when avail-able or functions with similar behaviors to the original oneswere implemented. After that, it was possible to run theverification, but the first results were imprecise as expectedbecause no refinement was made. Becoming familiar withthe source code was a complementary result of this step.The next step was to make the verification more precise.Frama-C asserts, parameters, and functions were studiedand used to refine the analysis, address some false alarms,and improve the results. In the analyzed case study, the vari-ous large loops and several control flow statements requiredspecial attention to be dealt with. Options were used as -slevel for unrolling loops and control flow statements to ob-tain more accurate results. However, these options usuallyslow down the analysis execution; therefore, it was neces-sary to strike a balance between the required precision andthe time spent by the analysis.In the last step, three warnings related to float opera-tion were found. By examining the function, it was pos-sible to ignore them. This is because the analyzed sourcecode is related to control algorithms, software with floating-point computations. These kinds of messages appear whena floating-point operation could result in an infinite value orNot a Number (NaN).The main proposal of the Value Analysis/Frama-C is toprovide valid results for all the range of values proposed bythe user, as opposed to what a test-generation tool wouldtypically do.The first scenario is often a useful method for using theValue Analysis/Frama-C. In this case, the analysis was per-formed smoothly and provided valid ranges of values forthe variables. As a conclusion, it was possible to infer thatthe implemented algorithms are working properly withoutany bugs, divisions by zero, invalid pointer access, bufferoverflows, and other run-time errors.In the second scenario, Value Analysis/Frama-C workedas C interpreter [6]. As a result, the analysis gave variablesprofiles very similar to the simulation. To compare them,three linear velocity parameters (Vx,Vy,Vz) were chosen,and the plots are shown in the Figure 1. The results obtainedfrom the flight simulation and the Value Analysis/Frama-Care so alike that the plots are indistinguishable, and in spiteof having six plots, it is possible to observe only three.Figure 1. Values computed by Frama-C x Sim-ulation data.35 Related WorkThis section presents research works related to formalverification of programs. Vijay makes a survey of auto-mated techniques for Formal Software Verification and con-cludes that, instead of the false alarms emitted, the staticanalysis techniques based on abstract interpretation scalewell at the cost of limited precision [8]. In an experimenton static analysis of the XEN Kernel, Pucetti [11] concludesthat abstract interpretation is the most promising techniqueto extract runtime level bugs from the code with little userassistance. Bouissou [2] shows the results of an ESA fundedproject on the use of abstract interpretation to validate crit-ical real-time embedded space software. In this paper, twotools are presented: a static program analyzer (ASTREE)and an abstract interpretation tool for studying numericalprograms coded in C (FLUCTUAT). The conclusion is thatthe performance of this new generation of tools has dramat-ically increased.6. Conclusions, Discussion, and Future WorkThe presented work applies a static analysis tool basedon abstract interpretation for formal verification on embed-ded aerospace control software. It has advantages comparedto the other two fundamental formal approaches describedin the section 2.1. When compared to deductive methods,the proposed approach has the advantage of automation, be-cause it is not necessary to include so many annotations inthe source code. In relation to the model checking, the staticanalysis can avoid the state space explosion problem.Some results obtained are worth being discussed. In theanalysis context, it was possible to detect an error relatedto the domain of sensor values in the Data Dictionary. Therecommendation is to review the document. Several inclu-sions were detected of unnecessary include files. Consider-ing that it is an embedded source code, the best approach isto maintain only the necessary source code. Therefore, therecommendation is to remove the unnecessary include filesfrom the source code. The analysis detected global parame-ters being passed by value in a function related to the sensormeasurements. The recommendation is to delete parametersand to perform the analysis of global variable usage.The main benefit of the proposed approach is to con-tribute to the development of dependable software systemsthrough the application of formal methods to remove soft-ware faults. Removing software faults directly improvesdependability because they are no longer potential causesof failure. Adding formalism in the dependability analysiswill increase the software quality and decrease the probabil-ity of a lost mission in the aerospace field. Of course, thisapproach alone is not appropriate. It must be a complemen-tary activity in the software process verification, which helpto reduce cost in the software validation process.Future works could include exploring the Frama-Cplug-in related with the deductive verification workingtogether Value Analysis.AcknowledgmentsThis research was sponsored by Agencia Espacial Brasileira(AEB). This work is partially funded by ERDF - EuropeanRegional Development Fund through the COMPETE Programme(operational programme for competitiveness) and by NationalFunds through the FCT - Fundacao para a Ciencia e a Tecnologia(Portuguese Foundation for Science and Technology) withinproject FCOMP-01-0124-FEDER-020486.References[1] J. Bertrane, P. Cousot, R. Cousot, J. Feret, L. Mauborgne,A. Mine´, and X. Rival. Static Analysis and Verification ofAerospace Software by Abstract Interpretation. In AIAA In-fotech@Aerospace 2010, number AIAA-2010-3385, pages1–38. American Institute of Aeronautics and Astronautics,April 2010.[2] O. Bouissou, E. Conquet, P. Cousot, R. Cousot, J. Feret,K. Ghorbal, E. Goubault, D. Lesens, L. Mauborgne, A. Mine´,S. Putot, X. Rival, and M. Turin. Space Software Valida-tion using Abstract Interpretation. In In Proceedings of theInternational Space System Engineering Conference, DataSystems in Aerospace (DASIA 2009), volume SP-669, pages1–7, Istambul, Turkey, May 2009. ESA.[3] A. Cheng. Abstract Interpretation Webpage.http://www.eleceng.adelaide.edu.au/personal/acheng/public/absInt/absIntMain.html, 2012.[4] P. Cousot. Abstract Interpretation in a Nutshell.http://www.di.ens.fr/˜cousot/AI/IntroAbsInt.html.[5] P. Cousot and R. Cousot. Abstract interpretation: a unifiedlattice model for static analysis of programs by constructionor approximation of fixpoints. In Proceedings of the 4thACM SIGACT-SIGPLAN symposium on Principles of pro-gramming languages, volume 82, pages 238–252, Los An-geles, California, New York, September 1977. ACM Press.[6] P. Cuoq, B. Monate, A. Pacalet, V. Prevosto, J. Regehr,B. Yakobowski, and X. Yang. Testing static analyzers withrandomly generated programs. In A. Goodloe and S. Per-son, editors, NASA Formal Methods, volume 7226 of LectureNotes in Computer Science, pages 120–125. Springer BerlinHeidelberg, 2012.[7] P. Cuoq and V. Prevosto. Frama-C’s value analysis plug-in20110201 carbon version, 2010.[8] V. D’Silva, D. Kroeningn, and G. Weissenbacher. A Surveyof Automated Techniques for Formal Software Verification.IEEE Transactions on Computer-Aided Design of IntegratedCircuits and Systems, 27(7):1165–1178, 2008.[9] ECSS. ECSS-E-ST-40C Space Engineering - Software,March 2009.[10] IAE. Instituto de Aeronautica e Espaco - Projeto VLS.http://www.iae.cta.br/?action=vls, 2011.[11] A. Puccetti. Static Analysis of the XEN kernel using Frama-C. Journal of Universal Computer Science, 16(4):543–553,2010.4

Using abstract interpretation to produce dependable aerospace control software

Abstract

Similar works

Full text

Available Versions

Universidade do Minho: RepositoriUM