wiki:SOCIS/2017

Version 16 (modified by Mikail Yayla, on Sep 16, 2017 at 12:03:11 AM) (diff)

student update socis

European Space Agency Summer of Code in Space 2017

This page captures the students who make proposals as well as those who work on projects for RTEMS as part of ESA SOCIS 2017.

Students' Proposals

Start filling in this table for yourself as soon as possible and update as needed.

Student Completed Hello IRC Handle Proposal Title Google Docs URL
NAME Yes or No nick on #rtems Project Title Link to Google Docs for proposal (shared with mentors)
Mikail Yayla Yes myay Software-based Fault Tolerance Proposal

The columns are to be filled in as follows:

  • The Student column is for your name.
  • The Completed Hello column lets us all know whether or not you completed the require Hello World project. Based upon our experience, students who have successfully compiled and run an RTEMS application have a MUCH MUCH higher chance of success on the proposed project.
  • The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on freenode.net.
  • The Proposal Title should be self-explanatory.
  • The Google Docs URL is your proposal in Google Docs that can be reviewed and commented on by mentors. The proposal template should be copied and used as a baseline. This can be shared with mentors for review. Mentors can insert comments for you.

WARNING: The Google Docs version of the proposal is a WORKING copy. You MUST submit the official and final proposal using the ESA SOCIS site. If you do not submit the final proposal via the ESA SOCIS site, you cannot be considered

Students' Summer of Code Tracking Table

Students whose SOCIS project is accepted by RTEMS shall fill in a slot with their information in the following table, which helps to centralize SoC Project Management.

Student IRC Handle Project Link Repository Link Blog
NAME nick on #rtems Link to Project Wiki page Link to project's public Github repository Link to your development blog
Mikail Yayla myay TBA Github Blog

The columns are to be filled in as follows:

  • The Student column is for your name.
  • The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on freenode.net.
  • The Project Link is a link to the Wiki page for your project.
  • The Repository Link is a link to the github repository for your project.
  • The Blog is a link to your blog with entries about your project. It should be updated regularly during the summer.

Student Status Updates

Each student has a section below for putting in notes from the weekly IRC meetings.

Mikail

  • May 31
    • Created page and added the link to my proposal
  • June 7
    • Set up blog (two wip entries) and Github repository
    • Met with mentor Kuan, very helpful in giving me pointers on how to prepare for our project
    • Introduced my project in SOC meeting: Since hardware in space is subject to transient faults, the project's goal is to implement a fault tolerant scheduler which is based on soft-error handling techniques in the literature
    • For next week: refine proposal and add details, read the RTEMS C user manual to further familiarize with the subject matter
    • Preparing to fully involve in the project on schedule (according to SOCIS: probably 15th June)
  • June 14
    • Wrote first blog entry about the project
    • Read resources about the scheduler in rtems (papers, documentation, blogs) to learn how components of it work
    • Begin implementing the fault tolerant scheduler
  • June 21
    • What was done:
      • Updated blog about which faults the fault tolerant scheduler can protect the system from, and explained how the schedulability can still be guaranteed despite different execution versions of a task
      • read various papers and documentation on the scheduling in rtems
    • The current issues:
      • waiting for the official SoC start
    • Plans for the next week:
      • get a sufficient understanding of the scheduler infrastructure in rtems
      • finish the blog post on how the fixed priority scheduler is implemented in rtems
      • find out where exactly the ft scheduler can be implemented
  • July 5
    • found out that the fault tolerant scheduler will not be on scheduler level, but will be implemented as an application framework which coordinates different execution versions
    • in the next week I will focus on getting information about how to create this framework
    • read SIMPLEX paper as guideline, it is a similar project
  • July 12
    • What was done:
      • work on the groundwork of the fault tolerant scheduler API (basic data structures and functions needed)
    • Plans for the next week:
      • write up the detailed design as a blog post
      • read related work from Sibin Mohan and Rudolfo Pellizoni about security in real-time systems
  • July 19
    • What was done:
      • wrote up the detailed design of the FTS API
      • read related papers
    • Plans for the next week:
      • implement a working version of the fault tolerant scheduler, with a simple fault tolerance technique first
  • July 26
    • What was done:
      • finished implementing a FTS scheduler which only lets the tasks execute the error correction versions or the version without protection
    • Plans for the next week:
      • work on a test for this implementation, create tasks which use protection under a certain condition
      • add other fault tolerant techniques, SRE first
  • August 2
    • Mostly off due to exams, but I worked on the pattern-based soft-error handling approach and two blog posts
  • August 9
    • What was done:
      • Worked on the pattern-based approach to handle soft-errors. Finished two blog posts; one about how the approach is implemented and one is about how I compile the system and test the FTS.
    • Current issues
      • Most of the current code works, but there is still an issue with the iteration within the pattern. For example if the pattern is 16 bit long, the task iterates through the first "round" of the pattern correctly, but in the following rounds, it does not. At the moment I'm trying to figure out what the problem is, but it will probably be resolved if I test it carefully.
    • Plans for the next week:
      • After I have solved the problem with the pattern iteration, I will start to implement a soft-error technique that also follows the pattern, but uses error detection to execute the correction versions (SDR).
  • August 16
    • What was done:
      • This week I finished implementing the first fault tolerance technique (of four) and fixed the pattern iterator. Tasks can now follow the pattern to execute the corresponding task version. I also completed the implementation of the algorithms which generate R- or E-patterns, which guarantee that (m,k)-reqiurements hold.
    • Current issues
      • How to cleverly implement fault injection and error detection, I am collecting ideas and will meet with my mentor Kuan to discuss the implementation.
    • Plans for the next week:
      • Next week, I will work on a fault injection and fault detection mechanism, so that I can implement the fault tolerance technique which uses fault detection.
  • August 23
    • What was done:
      • I have completed and the two fault tolerance techniques SRE and SDR and are working. This concludes the work for the static approaches (two dynamic techniques are next). A Fault injection model with a means to detect faults is also present now. To make the application more user-friendly, I edited the code such that only one function call is needed to activate the Fault-tolerant Scheduler; this call includes the passing of all needed FTS information, e.g. the pattern is generated automatically, and the three execution versions are created and started by the FTS.
    • Current issues
      • The current issue is to integrate the FTS code into the Rate-Monotonic scheduling, I need to investigate thoroughly how rate monotonic scheduling is done in RTEMS, to implement an "own version" of it which can tolerate faults.
    • Plans for the next week:
      • Understand the code of the Rate-Monotonic Scheduling code and begin implementing a version of the Rate-Monotonic scheduler which uses fault tolerance techniques.
  • August 30
    • What was done:
      • I edited the rate monotonic scheduler such that it calls the fault tolerant scheduler every time a new period is released. After adapting SRE and SDR (the two static pattern-based fault tolerant techniques) for this new design, I ran tests with the two techniques. To get SDR working I had to find a way to detect the faults with the fault model I have. For this I looked at message passing in rtems, but in the end I decided that calling a function which takes care of error correction is a method that works well already.
    • Plans for the next week:
      • Next week I will focus on implementing the dynamic fault tolerant techniques. After this I will work on the details, e.g, cleaning code, adding comments, working on documentation, and making the access to the FTS easier for the users.
  • September 6
    • What was done:
      • Finished implementing the dynamic fault-tolerance techniques for R- and E-patterns. I also ran tests for the two techniques, with different patterns and fault rates.
    • Current Issues:
      • How to change the design of the software such that the periodicity is guaranteed. Also overload situations can be prevented by deleting the task versions before each period completion.
    • Plans for the next week:
      • Draw diagrams for a blog post which explain the FTS scheduler in a clear way. Design and implement solutions which prevent the issues mentioned above.
  • September 13
    • What was done:
      • After discussing with my mentors, I reconfigured the FTS scheduler such that all tasks that are created within one period are deleted by the FTS at the beginning of the new period. This way, overload situations can be avoided. Besides editing the my comments in the code, I also began working on the final report, which is now halfway done.
    • Plans for the next week:
      • Finish the final report and try to improve the FTS so that it is more accessible to the users.

Final Report (RTEMS Fault Tolerance)

Future Works

  • /