D32 Code generation
THIS DOCUMENT IS NOT YET COMPLETE !!!
- 1 General Overview
- 2 Motivations
- 3 Choices / Decisions
- 4 Planning
- 5 References
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. The development of the approach, and the tools to support, it involved a number of team members at Southampton; and also at other institutions. This work draws on our recent experience with technologies such as Shared Event Decomposition , and the EMF Framework for Event-B . There was collaboration at an early stage with Newcastle University, where we explored the commonalities between their flow plug-in  and the algorithmic structures used in our approach. Collaboration with the University of York was also established since we chose to use their Epsilon  model-to-model transformation technology.
The decision was taken in 2009 to include code generation as a project goal . It had been recognised that support for generation of code from refined Event-B models would be an important factor in ensuring eventual deployment of the DEPLOY approach within their organisations. This was especially true for Bosch and Space Systems Finland (SSF). After receiving more detailed requirements from Bosch and SSF, it became clear we should focus our efforts on supporting the generation of code for typical real-time embedded control software.
Choices / Decisions
During the last year we have focussed on supporting the generation of code for typical real-time embedded control software. To this end we have evolved a multi-tasking approach which is conceptually similar to that of the Ada tasking model. Individual tasks are treated as sequential programs; these tasks 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 project, 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.
Our main goal this year has been to devise an approach for, and provide tool support for, code generation. In accord with the resources available during the year it was decided to limit the provision of tool support to that of a demonstrator tool. The tool is a proof-of-concept only, and lacks the productivity enhancements expected in a more mature tool. Nevertheless much insight has been gained in undertaking this work; it lays a foundation for future research, and will be useful since it will allow interested parties to explore the approach.
The Tasking Extension for Event-B
The following text can be read in conjunction with the slides from the Deploy Plenary Meeting - Zurich 2010.
Tasking Event-B can be viewed as an extension of the existing Event-B language. We use the existing approaches of refinement and decomposition to structure a development that is suitable for construction of a Tasking Development. At some point during the modelling phase parameters may have to be introduced to facilitate decomposition. This constitutes a natural part of the refinement process as it moves towards decomposition and on to the implementation level. During decomposition parameters form part of the interface that enables event synchronization. We make use of this interface and add information (see #Events For Tasking) to facilitate code generation.
A Tasking Development is generated programmatically, at the direction of the user; the Tasking Development consists of a number of machines (and perhaps associated contexts). In our approach we make use of the Event-B EMF extension mechanism which allows addition of new constructs to a model. The tasking extension consists of the constructs in the following table.
|Machine Type||DeclaredTask, AutoTask, SharedMachine|
|Control||Sequence, Loop, Branch, EventSynch|
|Task Type||Periodic(n), Triggered, Repeating, OneShot|
|Event Type||Branch, Loop, ProcedureDef, ProcedureSynch|
|Parameter Type||ActualIn, ActualOut, FormalIn, FormalOut|
The machines in the Tasking Development are extended with the constructs shown in the table, and may be viewed as keywords in a textual representation of the language. With extensions added, a Tasking Development can be translated to a common language model for mapping to implementation source code. There is also a translator that constructs new machines/contexts modelling the implementation, and these should refine/extend the existing elements of the Event-B project.
The following constructs relate only to Tasking Machines, and provide implementation details. Timing of periodic tasks is not modelled formally. Tasking Machines are related to the concept of an Ada task. These can be implemented in Ada using tasks, in C using the pthread library C, or in Java using threads.
- Tasking Machines may be characterised by the following types:
- AutoTasks - Singleton Tasks.
- Declared tasks - (Not currently used) A task template relating to an Ada tasktype declaration.
- TaskType - Defines the scheduling, cycle and lifetime of a task. i.e. one-shot periodic or triggered.
- Priority - An integer value is supplied, the task with the highest value priority takes precedence when being scheduled.
A Shared Machine corresponds to the concept of a protected resource, such as a monitor. They may be implemented in Ada as a Protected Object, in C using mutex locking, or in Java as a monitor.
- Applied to the Shared Machine we have:
- A SharedMachine keyword that identifies a machine as a Shared Machine.
Tasks and Events
Each Tasking Machine has a task body which contains the flow control, or algorithmic, constructs.
- We have the following constructs available in the Tasking Machine body:
- Sequence - for imposing an order on events.
- Branch - choice between a number of mutually exclusive events.
- Loop - event repetition while it's guard remains true.
- Event Synchronisation - synchronization between an event in a Tasking Machine and an event in a Shared Machine. Synchronization corresponds to an subroutine call with atomic (with respect to an external viewer) updates. The updates in the protected resource are implemented by a procedure call to a protected object, and tasks do no share state. The synchronization construct also provides the means to specify parameter passing, both in and out of the task.
- Event wrappers - The event synchronization construct is contained in an event wrapper. The wrapper may also contain a single event (we re-use the synchronization construct, but do not use it for synchronizing). The event may belong to the Tasking Machine, or to a Shared Machine that is visible to the task. Single events in a wrapper correspond to a subroutine call in an implementation.
An event's role in the implementation is identified using the following extensions which are added to the event. Events used in task bodies are 'references' that make use of existing event definitions in the inherited machines. The events are extended. to assist with translation, with a keyword indicating their role in the implementation.
- Event implementation.
- Branch - In essence a task's event is split in the implementation; guards are mapped to branch conditions and actions to the branch body. If the branch refers to a Shared Machine event (procedureDef) then this is mapped to a simple procedure call.
- Loop - The task's event guard maps to the loop condition and actions to to loop body. If the loop refers to a Shared Machine event then it is mapped to a simple procedure call.
- ProcedureSych - This usually indicates to the translator that the event maps to a subroutine, but an event in a task may not require a subroutine implementation if its role is simply to provide parameters for a procedure call.
- ProcedureDef - Identifies an event that maps to a (potentially blocking) subroutine definition. Event guards are implemented as a conditional wait; in Ada this is an entry barrier, and in C may use a pthread condition variable .
In an implementation, when an subroutine is defined, its formal parameters are replaced by actual parameter values at run-time. We identify formal and actual parameters in the implementation by extending Event-B parameters as follows:
- Event parameter types
- FormalIn FormalOut - event parameters are extended with the ParameterType construct. Extension with formal parameters indicates a mapping to formal parameters in the implementation.
- ActualIn, ActualOut - Extension with an actual parameter indicates a mapping to an actual parameter in the implementation.
Other Technical Issues
The decision was made to use Epsilon Cite error: Closing
</ref> missing for
There are technical notes available , that give more precise details of the approach and the mapping between Event-B and the common language meta-model, and its corresponding Event-B model.
There is a wiki page at http://wiki.event-b.org/index.php/Code_Generation_Activity
There is a tutorial at http://wiki.event-b.org/index.php/Code_Generation_Tutorial
This paragraph shall give a timeline and current status (as of 28 Jan 2011).