D32 Code generation

From Event-B
Revision as of 11:46, 1 December 2010 by imported>Andy (→‎Motivations)
Jump to navigationJump to search

Overview

The code generation activity has been undertaken at the University of Southampton. This has been a new line of work for DEPLOY that was not identified in the original Description of Work for the project. Development of the approach and the tools to support it involved a number of team members at Southampton, and also at other institutions. The code generation approach draws on our recent experience with technologies such as Shared Event Decomposition [[1]], and the EMF Framework for Event-B [[2]]. There was collaboration at an early stage with Newcastle University, exploring the commonalities between work-flow [[3]] and the algorithmic structures used in our approach. Collaboration with the University of York was also established since we chose to use their Epsilon [[4]] model-to-model transformation technology.

Motivations

The decision was taken in 2009 [[5]] to include code generation as a project goal, and to focus our efforts on supporting the generation of code for typical real-time embedded control software. To this end we have developed a multi-tasking approach such as that supported by the Ada tasking model. Individual tasks are treated as sequential programs. These are modelled by an extension to Event-B, called Tasking Machines. Tasks have mutually exclusive access to state variables through the use of protected resources. The protected resources correspond to Event-B machines. For real-time control, periodic and one-shot activation is currently supported; and it is planned to support aperiodic tasks in the near future. Tasks have priorities to ensure appropriate responsiveness of the control software.

For the DEPLOY pilots, it was regarded as sufficient to support construction of programs with a fixed number of tasks and a fixed number of shared variables – no dynamic creation of processes or objects has been accommodated. In the past year our goal has been to provide an approach, and tool support, to act as a proof-of-concept. We also gained much practical experience with the development of a code generation framework.


This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements are addressed and what are the main benefits.

Choices / Decisions

This paragraph shall summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.

Available Documentation

This paragraph shall give pointers to the available wiki pages or related publications. This documentation may contain:

   * Requirements.
   * Pre-studies (states of the art, proposals, discussions).
   * Technical details (specifications).
   * Teaching materials (tutorials).
   * User's guides. 

A distinction shall be made on the one hand between these different categories, and on the other hand between documentation written for developers and documentation written for end-users.

Planning

This paragraph shall give a timeline and current status (as of 28 Jan 2011).