Changes between Version 41 and Version 42 of SOCIS/2015

Jun 4, 2016, 9:55:43 AM (4 years ago)
Saeed Ehteshamifar



  • SOCIS/2015

    v41 v42  
    7676* Aug 25: Improved code generation by using C macros and C Pre-Processor to avoid source code redundancy. Added to Slingshot a call to Linux Make to build test program. Should wrap up and prepare to publish Slingshot repository.
    7777* Sep 01: Wrapped up Slingshot and published it on Github. Wrote final report (which contains future works) and put the link to it on this page. End of SOCIS 2015.
     79= Final Reports (short) =
     81This summer the RTEMS Project had 2 excellent students participate in the ESA Summer of Code in Space Program (SOCIS).
     83In the following sections, each student has summarized their individual projects.
     85== Hermann Felbinger: Improve Code Coverage Analysis Meeting Aviation and Automotive Standards ==
     86The goal of this project is to improve the reporting of structural coverage analysis on testing RTEMS. The existing coverage analysis implementation supports statement and branch coverage. Mainly the tool for generating reports of this coverage analysis implementation is updated.
     87The detailed coverage analyisis reports are generated providing hints to uncovered code fragments depending on the used coverage metrics. Further the coverage analysis tool is extended to evaluate also MC/DC (Modified Condition/Decision Coverage).
     89In this project the planned work was to improve the coverage analysis of RTEMS. According to the ISO 26262 certification standard in automotive industry and the DO-178C for software-based avionics systems the evaluation of a complete test suite is based on different structural code coverage metrics. These metrics are statement, decision, and MC/DC. The metrics are selected on the Safety Integrity Level (SIL) (=potential for a safety hazard from A to D, where D is highest). E.g. a software application which is assigned a SIL level of D is required to achieve 100% MC/DC coverage. To use an operating system like RTEMS in safety related applications also RTEMS has to achieve 100% coverage. In this project an update of the existing coverage reporting application, which was implemented at SOCIS 2014, is provided.
     91I analyzed the capabilities of the instrumented QEMU emulator, called Couverture QEMU, to see for which CPU types the existing coverage analyzer and report generator can be used. Couverture QEMU generates the execution traces which are analyzed to generate coverage reports. I configured and built the existing tools for LEON2 and PC386 CPU. Running the coverage analysis for LEON2 yielded an issue caused by a mismatch of byte sizes of the execution traces and the symbols from the analyzed libraries. Together with Joel and Gedare we found and implemented a solution for this issue. Then coverage reports for PC386 and LEON2 were generated.
     92Further hard coded paths were eliminated from configuration files pointing to the analyzed libraries and to instrumented object files (.gcno) which are produced by the gcc compiler. Then I started working on the verification of coverage results produced by gcov and a possibility to identify control statements in source code such that branches from execution traces can be mapped to conditions within a decision in the source code.
     94Documentation of the work in progress can be found in the [ blog].
     96== Saeed Ehteshamifar: RTEMS Fault tolerance ==
     98Before this SOCIS, [ this project] was uninitiated and had the goal of getting a fault injection tool to work with RTEMS. During this SOCIS, 3 tools were introduced to fulfill this goal:
     991. [ GRINDER]: An open-source tool to automate test campaign execution and storing results.
     1002. [ Slingshot]: An open-source tool to generate data type-based faults for POSIX API.
     1013. [ R]: A tool to analyze results, gather statistics, extract meaningful assertions, graphs, etc.
     103Of these 3, the first two tools were successfully adapted to RTEMS. More specifically, more than 40 POSIX functions with more than 1300 test cases were tested using Slingshot. Results showed that 70 test cases failed which accounted for 4 functions: free, tanh, time, and times. Furthremore, CRASH failure model was proposed based on [ CMU's Ballista] project and some theoretical preliminaries were given.
     105Documentation of the work in progress can be found in the [ blog] and final report for this project which contains future works can be found [ here]. Just to mention the next steps briefly, the followings can be listed:
     1061. Integrate GRINDER’s function into Slingshot. Automate the whole procedure, plus adding an analysis tool to the chain.
     1072. Test more RTEMS POSIX implementations.
     1083. Add support for RTEMS Classic API.