= ESA Summer of Code in Space 2015 Final Report =

[[TOC(SOCIS/2015/Final_Report , depth=2)]]

This summer the RTEMS Project had 2 excellent students participate in the ESA Summer of Code in Space Program (SOCIS).

In the following sections, each student has summarized their individual projects.

== Hermann Felbinger: Improve Code Coverage Analysis Meeting Aviation and Automotive Standards ==
The 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. 
The 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).

In 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.

I 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.
Further 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.

Documentation of the work in progress can be found in the [http://socis2015rtems.blogspot.com/ blog].
== Saeed Ehteshamifar: RTEMS Fault tolerance ==

Before this SOCIS, [https://devel.rtems.org/wiki/Developer/Projects/Open/Fault_injection 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:
1. [https://github.com/salpha2004/GRINDER-RTEMS GRINDER]: An open-source tool to automate test campaign execution and storing results.
2. [https://github.com/salpha2004/slingshot-rtems Slingshot]: An open-source tool to generate data type-based faults for POSIX API.
3. [https://www.r-project.org/ R]: A tool to analyze results, gather statistics, extract meaningful assertions, graphs, etc.

Of 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 [http://users.ece.cmu.edu/~koopman/ballista/ CMU's Ballista] project and some theoretical preliminaries were given.

Documentation of the work in progress can be found in the [http://rtems-fi.blogspot.de/ blog] and final report for this project which contains future works can be found [https://docs.google.com/document/d/1DVbwDUEf0DDzzLQbYQo7oPF0zKwueCaLS87cqKSlsGw/pub here]. Just to mention the next steps briefly, the followings can be listed:
1. Integrate GRINDER’s function into Slingshot. Automate the whole procedure, plus adding an analysis tool to the chain.
2. Test more RTEMS POSIX implementations.
3. Add support for RTEMS Classic API.