Automatic Code Generation from Event-B Models

Dominique MéryUniversité Henri Poincaré Nancy 1

LORIA, BP 239, 54506Nancy, France

mery@loria.fr

Neeraj Kumar Singh∗

Université Henri Poincaré Nancy 1LORIA, BP 239, 54506

Nancy, Francesinghnne@loria.fr

ABSTRACTThis paper presents a translation tool that automaticallygenerates efficient target programming language code (C,C++, Java and C#) from Event-B formal specification re-lated to the analysis of complex problems. This tool is acollection of plug-ins, which are used for translating Event-B formal specifications into different kinds of programminglanguages. The translation tool is rigorously developed withsafety properties preservation. The results detailed in thispaper are an architecture of the translation process, to gen-erate a target language code from Event-B models usingEvent-B grammar through syntax-directed translation, codescheduling architecture and verification of an automatic gen-erated code. The translator checks syntax and type consis-tency before generating the target programming languagecode. The translation tool has been developed as a set ofRodin plug-ins under the Eclipse development framework.An assessment of the proposed approach is given through acase study, relative to the development of a cardiac pace-maker system.

Categories and Subject DescriptorsD.2.1 [Software Engineering]: Requirements/Specifica-tions; D.2.2 [Software Engineering]: Design Tools andTechniques; D.2.4 [Software Engineering]: Software/Pro-gram Verification

KeywordsCode Generation, Event-B, Proof-based development, Re-finement, Code Verification

1. INTRODUCTIONFormal methods provide a sound mathematical basis for

system requirements descriptions and aim to produce zero-

∗Work of Neeraj Kumar Singh is supported by grantawarded by the French Ministry of University and Research.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SoICT 2011, October 13-14, 2011, Hanoi, Vietnam.Copyright 2011 ACM 978-1-4503-0880-9/11/10 ...$10.00.

defect software, by controlling the whole software develop-ment process, from specification to implementation. The ca-pability of formal and automated verification of safety prop-erties in formal models, before transformation into code, hasadded real value to industrial systems, including the hard-ware and software systems. In top-down approaches, theystart from high-level and abstract specifications, by describ-ing fundamental properties of the final product. Detailsand design choices are introduced in an incremental way.The correctness between two levels is ensured by refinementproofs. It also maintains very well the refinement techniquesthat can transform an abstract and non-deterministic spec-ification into a concrete, deterministic system, in severalstages. Refinement leads to a last level that describes theexpected behavior of the system, which can be easily imple-mented into target language code.

The code generation process consists in several stages: for-mal implementations are translated into programs in a givenprogramming language using a tool chain of translators, andthen these programs are compiled. The approach offers sev-eral desirable features: the translation process is as simpleas possible, and it can be validated in an easy way; sec-ondly having a formal specification of the available systemsuggests as a next step to use it during tests of the system.Software testing tries to check the correctness of the systemwith respect to its specification in program states that arechosen for the test. The simplicity of the translation en-sures traceability between the formal specification and theexecuted code.

Several constraining requirements are existing particularlyin the embedded domain due to limited size of memory fortranslating from formal specifications to a given target pro-gramming language (C [19, 25], C++ [30], Java [3, 18] andC# [27]). To overcome such kind of problems, first, a com-promise must be found between the expressiveness of theformal implementation language and the simplicity of thetranslation process. Another compromise is also necessarybetween formal models, which generally favor the readabil-ity and the simplicity of the verification process, over thecode efficiency.

This article presents an architecture of a code generationtool [15], which can be used to translate an Event-B [1, 2]specification into any given target programming language.The architecture of code generation tool is proposed to sup-port for direct-translation from Event-B formal specificationinto any target programming language with code correct-ness. We provide a rigorous translation tool [15] for Event-Bspecification to target programming language that can easily

179

be adapted in any domain and giving freedom for develop-ers to adjust their integer representations [28] for overcomingmemory related problems. It consists of generating C, C++,Java and C# codes from Event-B [1, 2] with a multi-phasedtranslation process. This translation tool is developed as aplug-in to Rodin [26] under the Eclipse framework.

We present a multi-phased translation process from Event-B [1, 2] models. An Event-B model supports set-theoreticalnotations that are not possible to directly translate into anytarget programming language. The translator automaticallyrewrite partially formal notations of Event-B [1, 2], that canbe easily translatable for final target programming language.Any target programming language source code is then auto-matically generated from the model via using an appropriatetranslation phase of the tool. The final translated code isapplicable to compile into an executable code using conven-tional compilation tool.

A developer can also use translated code to extend thefunctionality of the system by inserting extra code of thesystem or some new functionalities that are not included inEvent-B formal development. Some parts of the implemen-tation code is not supported by the code generator and auser wants to implement some existing components more ef-ficiently are main reasons for inserting extra code into theautomatically generated code. In a complex system, someparts are always developed by third party, which is not trans-latable by any generator. Therefore, we have used functionsto include the behavior of the third party codes, which havesame input and output parameters. In the generated code,functional blocks are replaced by the third party codes. Forinstance, in the cardiac pacemaker models [23] actuatorsand sensors have some embedded codes, which are providedby the third parties. Moreover, it offers a flexible way forEvent-B designer to generate C, C++, Java and C# codes.Due to manual intervention in generated source code, wepropose a code verification technique using meta-proof andsoftware model checking tools like BLAST [9] for verifyingdesired behaviors of the developed system. This tool is freelyavailable for download1. The use of this tool is exemplifiedthrough the generation of C, C++, Java and C# codes fromspecification of a cardiac pacemaker [23].

This paper is organized as follows. Section 2 presentsrelated work and Section 3 depicts an architecture of thetranslator in form of a tool chain and describes various partsof the translation process. Section 4 presents results of thetranslator using a case study, relative to the development ofa cardiac pacemaker system. Finally, in Section 5 we providesome concluding remarks and directions for future work.

2. RELATED WORKAutomatic Code Generation is a standard technique in

the area of Software Engineering. Several tools are devel-oped by the research community for generating source codefrom graphical modeling tools like UML [29] to any targetprogramming languages like C++ and Java. The automaticsource code generation from formal specification to high-level programming languages is supported by few formaltechniques like Classical B [2, 4] and Vienna DevelopmentMethod (VDM) [24, 10].

VDM [24, 10] is a set of techniques and tools based onformal specification language - the VDM Specification Lan-

1Download: http://eb2all.loria.fr/

guage (VDM-SL). An extended version of VDM tool (i.e.VDM++ [24]) supports object-oriented and concurrent sys-tems modeling. VDM tools provide features for analyzingmodels, testing and proving properties of models and gen-erating program code from validated VDM models.

A tool vMAGIC [12] is based on Java library that is usedfor automatic code generation for VHDL. According to thepaper this tool is very usable and reliable, but a lot ofuseful features are not implemented yet like semantic op-erations. In the area of model-driven software engineering,a tool PADL2Java [11] has been developed that translatesPADL models into Java code. PADL is a process algebraicarchitectural description language equipped with a rigor-ous semantics and transformation rules into multi-threadedobject-oriented software, which is employed in the verifica-tion tool TwoTowers. This tool provides the code generationapproach and code synthesizing techniques.

From Classical-B [2, 4] notation to C language translationtool has been developed by D. Bert, et al. [8], in which mod-els are restated in an intermediate language “B0”, and thenconverted to finally in C and ADA languages. A pioneer-ing work for automatic translation of a subset of Event-Bformal notation of MIDAS [31] specification in C languageis proposed by S. Wright [31]. The work shows only forsimple translations of formal concrete machines. Edmundset al. [16, 17] have presented a way for generating code,for concurrent programs, from Event-B specifications. Au-thors aim to integrate their code generation approach withexisting Event-B methodology and tools. Based on previ-ous work [8, 31], we have developed a set of software tools(EB2C, EB2C++, EB2J and EB2C#) to translate Event-B [1] formal specifications into C, C++, Java, and C#codes. Moreover these tools (EB2C++, EB2J and EB2C#)are more richer in supporting formal notations than previ-ous tools [31, 8] and also support set theory based nota-tions in the translation, which is not supported by existingtools [8, 31, 16]. This paper discusses the code generationapproach underlying EB2C, EB2C++, EB2J and EB2C#tools [15] using some additional refinement approach, whichtransform an indeterministic model into deterministic modelusing clean termination approach [28].

3. TRANSLATOR ARCHITECTUREThe translation process consists in transforming the con-

crete part of an Event-B project into a semantically equiv-alent text written in any target programming language. Wepropose an architecture for the Event-B translator; differ-ent parts of the translator are shown in Fig. 1 and this ar-chitecture supports translation for several target program-ming high level languages like C, C++, Java and C#. Thetranslator tool must be customized for each new target pro-gramming language or for specific execution platforms. Thetranslation tool is implemented in the Eclipse framework asa set of plug-ins for Event-B. Event-B translation process asa chain of tool description is given as follows:

3.1 Rodin ProjectEvent-B is provided with tool support in the form of an

open and extensible Eclipse-based IDE called Rodin [26],which is a platform for Event-B specification and verifica-tion, and model information stored in an internal database,via defined APIs. The translation tool is implemented as aset of Rodin plug-ins under the Eclipse framework. This tool

180

Filter Context and Concrete Files

Rodin Project

Target Language Context File

Generated Proof-Obligation

Lexical Analysis

Syntactic Analysis

Code Generation

Events Scheduling

GeneratedCode verification

Code Compilation and Execution

Pre-Processing

Event-B to TargetLanguageTranslator

Code Optimization

Code Verification

Figure 1: Architecture of Translator

uses the recommended interfaces according the Rodin archi-tecture, to traverse the internal database of models. Thisphase presents an explicit selection of a particular Rodin [26]project from all the projects loaded into the workspace. Aparticular selected project is passed into the next phase ofthe translation process.

3.2 Target Language Context FileSystems fail most of the time because of a run-time error.

For instance, overflow and underflow of bounded integer isa type of a run-time error that should be addressed in theproof process. The papers [28, 13, 14] address a solutionfor proof of clean termination that provides the facts that aprogram is totally correct. Clean termination means thatthe program terminates normally without any execution-time semantic errors like integer overflow, use of undefinedvariables, subscript out of range, etcetera [28, 14]. We pro-pose the Pre-Processing stages for obtaining a determinis-tic model using one more level of refinement introductionthrough a new context, which are similar to the clean ter-mination approach [28, 13]. This refinement phase providesdeterministic definitions of constants and variables using onemore level of refinement, and discharges all new generatedproof obligations. Types of generated proof obligations andproof details are similar to the papers [28, 13, 14]. This levelof refinement compiles system specification abstractly. Thegenerated proof obligations are discharged by automatic aswell as manual, and all proofs that are necessary to verifythe specification in order to guarantee the consistency andcorrectness of the system. Therefore, this phase is very im-portant to maintain all safety properties into automatic codegeneration from the Event-B model. This phase providesmany context files, to add into current project according toa target programming language choice (C, C++, Java andC#). Table 1 shows bounded integer data types for all tar-

get programming languages. In the Event-B language, thereare two kinds of constants and variables (data): abstractdata and concrete data. Abstract data consists in all theelements and sets that can be used in set theory, as definedin Event-B (integers, enumerated sets, cartesian products,power sets, relations, and so on). They are mainly used atthe higher levels of specification (machines and in top levelrefinements) [1].

Concrete data are those which may be used in the finaltranslation process, each time the data thus introduced willnot be further refined in the development. It is the casefor constants and variables at the implementation level butalso for parameters and results of operations, which cannotbe refined in Event-B [1]. Concrete data must match or-dinary data types in usual programming language becausethey should be “implemented” directly in the target pro-gramming language. So, the correspondence between con-crete data and data types must be obvious. In the sequel,concrete data types will be called “context data type”. Instandard Event-B, they are the following ones:

• enumerated types (including the boolean type)

• bounded integer type (from MININT to MAXINT)

• arrays on finite index intervals where the type of ele-ments is a concrete type (in set theory, they are similarto total functions)

A developer can replace all Event-B data types corre-sponding to the limitations of the selected target program-ming language data types. If a developer skips this phasein translation process, then the translator generates defaultmaximum bounded integer primitive data type [19, 30, 3,27] for all the variables and constants and there is no guar-antee to preserve all safety properties (related to overflowor underflow) of the proved system unless all proof obliga-tions are discharged after introducing new context file in thedeveloped formal model.

3.3 Generated Proof ObligationsAn additional context file and replacement of all Event-

B non-deterministic ranges of data types according to thetarget programming language, deterministic data types gen-erate a lot of proof obligations. A developer can manuallyprove all generated proof obligations with the help of theRodin proof tool [26]. The proved Rodin project can passto the next phase of the translation process.

3.4 Filter Context and Concrete machine Mod-ules

Refinement based formal model is a chain of incremen-tal development, which starts from an abstract machine andending with the implementation of this machine as a finalconcrete machine. Relations between modules are only re-lations “sees” and “refines”. This stage is used to find allcontext and concrete machine modules from the selectedproject. Final concrete models are obtained by gathering allthe concrete data contained in the Event-B original module.Context modules contain static properties as sets, constants,functions and enumerated sets of the system while final con-crete machine modules contain dynamic properties as vari-ables, functions and events form. It contains concrete sets,concrete constants, concrete variables, initialization and op-erations of the implementation. If the tool is not able to find

181

Event-B type Formal Range C & C++ type Java type C# type

tl int16 −215..215 − 1 int short shorttl uint16 0..216 − 1 unsigned int - ushorttl int32 −231..231 − 1 long int int inttl uint32 0..232 − 1 unsigned long int - uinttl int64 −263..263 − 1 - long longtl uint64 0..264 − 1 - - ulong

Table 1: Integer bounded data type declaration in different context files

the final concrete module, then immediately the translationprocess is terminated with an error message, else all filteredcontext and concrete modules are passed to the next phaseof the translation process.

3.5 Principles of Code Generation through Lex-ical and Syntactic Analysis

The purpose of this phase is to translate Event-B code ofeach filtered module in a semantically observationally equiv-alent standard target programming language code. TheEvent-B code translation process is repeated for all mod-ules of contexts and leaf-machines (i.e. those found to haveno further refinement). A target programming language (C,C++, Java and C#) file is produced for each concrete ma-chine module. The generated file name is similar to thesource Event-B machine with proper extension according tothe selected language. The generated file is created into theselected Rodin project. Generation of the target program-ming language file begins with the insertion of header com-ments containing a timestamp and references to the sourceRodin project and machine. Some required header informa-tions are also inserted in the header according the targetprogramming language requirements.

Main cause of failure of this translation tool is unable toparse the predicate. For example, current tool is not ableto handle relational operator (↔) and quantifiers (∃ and ∀).If translation tool is failed for translating a machine file,the translation tool immediately proceeds with translationof the next machine file. A set of supported symbols oftranslation tool is available in Table-2. Table-2 shows a setof Event-B syntaxes to an equivalent C and C++ program-ming languages. This table shows a list of supported Event-B syntax. All constants defined in a model’s context mustbe replaced with their literal values. This translation toolsupports conditional, Sets theory notation (only in C++,Java and C#), arithmetic and logical expression of formalmodel and translates it into an equivalent target program-ming language. Java and C# languages have also similar listof supported Event-B syntax, which are not given here dueto limited space. A detailed translation process of contextsand concrete machines are given as follows:

3.5.1 Processing Context FilesThe context of a Event-B model consists of sets, enumer-

ated sets, constants, arrays and functions, associated withtheir respective type. The translation tool supports all kindsof context components for translation purpose. The observa-tional equivalence is based on equivalence between Event-Bvalues and target programming language values. This equiv-alence on values is naturally extended on instances of con-text. The observational equivalence between Event-B setsand target programming language types is given in Table-3,

which has some equivalence in [8] related to “B0” [2].An Event-B enumerated sets is semantically equivalent to

the target programming language enumerated types. It isvery simple to translate into target programming languageequivalent form due to equivalent semantical structure.

The links between Event-B and target programming lan-guage for integer values have been considered as crucial forthe efficiency of the generated code and for the correctnessof the translation. So, the solution is provided in the secondphase by introducing target programming language contextand it is able to interface very tightly in between Event-B integer types and target programming language integertypes.

The links between Event-B arrays and target program-ming language arrays are not straightforward. In Event-B, arrays correspond to the total functions whereas in tar-get programming language, they correspond to a contiguouszone of memory (coded as the beginning address of the arrayand its size). However, it is easy to do a semantical corre-spondence between an array element arr(i) in Event-B andthe value at the location arr[i] in the target programminglanguage.

The links between Event-B functions and target program-ming language functions are also very ambiguous. Transla-tion tool only supports total function of Event-B into equiv-alent corresponding target programming language function.However, it is easy to do a semantical correspondence be-tween a function passing parameters in a target program-ming language is equivalent to the elements of a left sideof the total function symbol (→) and an output of the tar-get programming language function corresponds to the righthand side of the total function symbol (→) in Event-B.So, this step of function translation generates the functionstructure into the target programming language. All ele-ments of context file are declared as global. Context elementtype information is derived from the type-defining AXIOMstatement within the context, which may express as integerranges, specially supported bit-map types or arrays of thesedefined by mapping functions. Main body of the function isadded by developer, but behavior of the function is alwayssame, which is proved by the system abstractly. The mainbody of the function includes abstractly in the formal devel-opment of the system, while code generated function body isempty and it allows to a user to add new codes. New addedcodes can be a set of complex expressions, which can not bepossible to formalised it during modeling process. A set ofcomplex expressions can be an algorithm, which has similarbehavior as the formal function.

3.5.2 Processing Machine FilesA machine file contains functions, arrays and variables.

All these elements are declared as global. Global element

182

Event-B ’C’ & ’C++’ Language Commentn..m int Interger type

x ∈ Y Y x; Scaler declarationx ∈ tl int16 int x; ’C’ & ’C++’ Context declaration

x ∈ n..m → Y Y x [m+1]; Array declarationx :∈ Y /* No Action */ Indeterminate initializationx : | Y /* No Action */ Indeterminate initializationx = y if(x==y) { Conditionalx 6= y if(x!=y) { Conditionalx < y if(x<y) { Conditionalx ≤ y if(x<=y) { Conditionalx > y if(x>y) { Conditionalx ≥ y if(x>=y) { Conditional

(x>y) ∧ (x≥z) if ((x>y) && (x>=z) { Conditional(x>y) ∨ (x≥z) if ((x>y) ‖ (x>=z) { Conditional

x := y + z x = y + z; Arithmetic assignmentx := y - z x = y - z; Arithmetic assignmentx := y * z x = y * z; Arithmetic assignmentx := y ÷ z x = y / z; Arithmetic assignmentx := F(y) x = F(y); Function assignment

a := F(x7→y) a = F(x, y); Function assignmentx := a(y) x = a[y]; Array assignment

x := y x = y; Scalar actiona := a �− {x7→y} a[x] = y; Array action

a := a �− {x7→y} �− {i7→j} a[x]=y; a[i]=j; Array actionX⇒Y if(!X ‖ Y){ Logical ImplicationX⇔Y if((!X ‖ Y) && (!Y ‖ X)){ Logical Equivalence¬x<y if(!(x<y)){ Logical notx ∈ N unsigned long int x Natural numbersx ∈ Z signed long int x Integer numbers∀ /* No Action */ Quantifier∃ /* No Action */ Quantifier

fun ∈ N× N→ N long int fun(unsigned long int arg1,unsigned long int arg2) Function Definition

{//TODO: Add your Code

return;}

set var set <data type> set var STL library∪ set union(...) STL library∩ set intersection(...) STL library\ set difference(...) STL library⊆ includes(...) STL library⊂ includes(...) && !(equal(...)) STL library6⊆ !(includes(...)) STL library6⊂ !(includes(...)) && !(equal(...)) STL library

Table 2: Event-B to C & C++ translation syntax

Event-B types Target Language typesEnumerated sets Enumerated typesBasic integer sets Predefined integer typesEvent-B array types Target programming language array typeFunction Target programming language function structureSets theory Set theory implementation using advanced library function

in target language (not in ’C’)

Table 3: Equivalence between Event-B and programming language

183

type information is derived from the type-defining INVARI-ANT statements within the machine, which may be ex-pressed as integer ranges, function structure, and arrays.Translation tool translates all those into target program-ming language code according to the same rules, which aredefined in the last context section. Static and dynamic typedefinitions are only difference between context and machinemodules data types. For instance constants and variableshave same definition but in ‘C‘ language constants use constkeyword with data type definition and variables are definedwithout const keyword.

3.5.3 Processing EventsTranslation tool provides a recursive process to generate a

source code for each event of the Event-B specification intoa target programming language. Translation tool alwayschecks for “null” event (i.e. guard of false condition), nevergenerates the source code for that event and inserts suitablecomment into the source code for the traceability purpose.For instance, if an event has single guard with false con-dition, then the code generation tool does not generate thesource code for this event. This automatic reduction is per-formed to avoid generation of unreachable run-time code.

In the Event-B specification, there are two kinds of vari-ables: global variables and local variables. Global variablesare derived directly from VARIABLES statements of theconcrete machine and all these variables have global scope.Local variables are derived from the ANY statement of aparticular event, and are entirely local to the correspond-ing event function. Therefore no parameters are passed tothe target programming language function. The function re-turns a boolean value, signaling whether the event has beentriggered to its calling environment at run-time. After gen-eration of the function header, all local variable declarationsare inserted at the beginning of the function, giving themscope across the whole function.

In the Event-B, guard handling is very ambiguous due todifferent meaning, such as local variable type definition, theassignment of a value to a local variable, condition state-ments using negation (¬), conjunction (∧), disjunction (∨),implication (⇒) and equivalence (⇔) operators. Therefore,for handling so much complex situation, we have designeda recursive algorithm for parsing a complex guard and sep-arate each element of guard for translation purpose. Thuseach guard must be automatically analyzed to resolve thisambiguity from the context information. For example animplication (⇒) and equivalence (⇔) operator, the transla-tor tool automatically rewrite the predicate in an equivalentform using conjunction (∧), disjunction (∨) and negation(¬) operators, an equal relation may signify an assignmentor equality comparison, and the precise meaning (and hencethe resulting translation) deduced from the type and scopeof its operands. A further ambiguity that must be resolvedis the meaning of a functional-image relation, which may beused to model a data array or an external function. Oncethe guards of an event have been classified, those conferringlocal variable type information are used for variable decla-rations in the function, and remaining guards are used togenerate local assignment and conditional statements. Lo-cal variable type information is derived in a similar fashionas the global variables from the guard information insteadof using INVARIANTS.

All guards are placed into the event function as a set

of nested conditional statements, using directly translatedconditional and local variables declared within nested scoperanges. After insertion of all conditional guards, we pro-vide translation for remaining local assignments with a com-ment. The meaning of functional-image statements withinthe model is automatically resolved to an array if the map-ping is a global variable, otherwise a call to an uninterpretedfunction is inserted.

The next sub-stage of event translation is the actionstranslation. In the Event-B, actions are triggered in a con-current manner and state that all state modification in theactions is only valid in the entire event post-condition. There-fore, dependency checks must be performed to ensure thatany state variable used as an action assignee has not al-ready been modified to its post-condition prior to use. Asimilar way of parsing is applied on Event-B action state-ment as a guard statement. An action translation supportsassignments to scalar variables, override statements actingon array-type variables and arithmetic complex expression.The translation tool translates all Event-B actions into anequivalent target programming language source code.

3.6 Events SchedulingAn incremental refinement-based structure of events within

an Event-B model provides grouping information about theevents through analysis of strength of the guards and refine-ment structure. Fig. 2 presents an architecture of the eventsscheduling using sequential and optimized ways for callingorder of the events. We have designed a recursive algorithmin this phase of translation tool to discover structuring in-formation from the current Rodin project, and could exploitit to recursively generate nesting calling a set of functionscorresponding to the abstract events. Merging of commonevent guards is currently avoided in order to preserve directmapping between Event-B statements and translated code,at the cost of possible performance optimizations. However,if translatable guards are already placed in an abstract level,then guards are forming a group of concrete events. An eventgroup is inserted for execution in place of multiple events forimproving run-time performance.

Event scheduling phase is used to synthesize all generatedevent functions. All these event functions are equivalent tothe Event-B events. We propose two techniques to triggerall translated events. First is calling a function “Iterate”that implements a continuous iteration of generated eventfunctions of the Event-B model, in the same order, definedby their position in the Event-B model. Second technique isto optimize the calling order of the events. An optimizationapproach schedules calling generated event functions usinga refinement approach. An incremental refinement-basedstructure of events within an Event-B model exploit to re-cursively generate nesting calling functions corresponding tothe abstract events. An abstract level guards are forming agroup of concrete events. Each group of events are triggeredby the main “Iterate” function. This technique is used to im-prove run-time performance wherever at concrete level hasseveral events.

Finally, top-level main function of target programminglanguage is generated to call the generated functions “INI-TIALISATION” and “Iterate”. The only procedural require-ment is the calling of “INITIALISATION” prior to “Iterate”.All other behaviors regarding iteration control may be se-lected. The INITIALISATION function is exposed to allow

184

later calls to it by the execution environment, providing amechanism for run-time reset of the Event-B machine if re-quired. In a particular example the machine is invoked onlyonce and, after initialization, is iterated continuously with-out any scheduling constraints until either implicit or ex-plicit deadlock (i.e. an event having no actions) is detected.Implicit deadlock is flagged as an error condition, explicitdeadlock is treated as normal termination.

BOOL Iterate(void){

if(Event1() == TRUE) return TRUE;if(Event2() == TRUE) return TRUE;

.

.

.

.

.

.if(Eventn() == TRUE) return TRUE;

/∗Signal deadlock ∗ /return FALSE;

}

BOOL Iterate(void){

if(Condition1 . . .){if(Event1() == TRUE) return TRUE;if(Event2() == TRUE) return TRUE;. . .}

if(Condition2 . . .){if(Event4() == TRUE) return TRUE;if(Event5() == TRUE) return TRUE;. . .}...if(Conditionm . . .){if(Eventn−1() == TRUE) return TRUE;if(Eventn() == TRUE) return TRUE;. . .}/∗Signal deadlock ∗ /return FALSE;

}

Figure 2: Event Scheduling Architecture

3.7 Generated Code VerificationThe code verification is a very important step to verify

the correctness of the automatic generated code. This stepis required due to manual insertion of an external code. Twomain motives for adding external codes into the generatedcode:

• if some part of the implementation code is not sup-ported by the code generator;

• a user wants to implement some existing componentsmore efficiently.

Due to manual intervention in generated source code, wepropose a code verification technique. Fig. 3 shows an ap-proach to verify source code of a final developed system.Our idea is to verify the correctness of generated code withrespect to Event-B formal specification to give a meta-proofthat for all Event-B models, and target language transla-

tion, the execution of the target language program satisfiesthe execution (abstractly) of the Event-B model.

In fact, as can be expected, the translation of Event-Bdescriptions into a target language software cannot be com-plete, and hence will require the intervention of the softwaredeveloper in specific positions of the generated code, e.g.for inserting the target language statements correspondingto internal actions. Hence, next level of code verificationinjects hand-written code corresponding to the internal ac-tions. Now, we have used software model checking tool ac-cording to different target language like BLAST [9] for ’C’language. The software model checking tools are comple-ment of the analysis conducted on Event-B specification bymaking it possible the verification of property preservationat the code level. In fact, although property preservation isguaranteed under certain constraints [6, 7], an inappropri-ate intervention of the software developer on the generatedcode may lead to the violation of properties proved at thearchitectural level.

Verified Hand Written Code

Generated Code Meta Proof

Verified Generated Code

Final Generated and Hand Written Code

Software Model Checking Tool

Final Generated Target Language Code

Figure 3: Generated Code Verification

3.8 Compiling and Running the CodeOnce automatic translation and verification of an Event-B

model is completed, all additional requirements are added,an execution environment must be provided and compiledby a suitable target programming language compiler. Thisfinal step of the translation tool is for compiling a set ofgenerated files on target platform.

4. CASE STUDY: CARDIAC PACEMAKER

4.1 EB2ALL Translation ToolFig. 4 represents a screen shot of translator tools (EB2C,

EB2C++, EB2J and EB2C#)2 under the Rodin environ-ment [15]. Combined name of all these set of plug-ins areEB2ALL [15]. All these tools are developed as a set of plug-ins under the Eclipse framework. After installation of theEB2C, EB2C++, EB2J and EB2C# plug-ins, menus Trans-lator/EB2C, /EB2C++, /EB2J, /EB2C# and tool buttonson toolbar, will appear. To generate a source code in anytarget language of any formal model, a user can click on anymenu (EB2C, EB2C++, EB2J and EB2C#) or tool but-ton, then a dialog box will appear (see Fig. 4). This dialog

2Download: http://eb2all.loria.fr/

185

Code Generation Tool(Toolbox and Menu Item)

Code Generation Dialog Box

Figure 4: Screen shots of Code Generation Tool

box presents a list of active projects. A user can select anyproject for generating a source code. These tools generatetarget language code for all concrete models of the selectedproject and also generates a log file for the code generatingprocess.

We now illustrate the use of EB2C, EB2C++, EB2J andEB2C# tools [15] by means of the automatic generation ofC, C++, Java and C# codes for the cardiac pacemaker sys-tem described with Event-B in [23]. Next section describescode generation process using EB2C from formal model ofthe cardiac pacemaker [23].

4.2 Code Generation for A Cardiac PacemakerSystem

We have presented a proof-based on incremental formaldevelopment of a cardiac pacemaker in [23, 5, 20, 22]. Here,we present an automatic code generation from developedformal specification of a cardiac pacemaker. We have usedEB2C tool to generate ’C’ code from Event-B model. Thistool has a technique of automatic support of safety assur-ance of a generated code. To achieve a verified source codeof the cardiac pacemaker, we have done further refinementof concrete model of the cardiac pacemaker using a new con-text, which has some data ranges corresponding to the ’C’language. This refinement makes model deterministic andgenerate some proof obligations due to defining the fixeddata range of all the constants and variables of the cardiacpacemaker model. The generated proof obligations are dis-charged by automatic as well as manual and all these proofsare necessary to verify the specification in order to guaran-tee the consistency and correctness of the system. We havedischarged all the generated proof obligations before gener-ating the source code and move to the next level of codetranslation methodology as to pass the concrete model forcontinuing translation process.

Source code generation from Event-B formal specificationinto ’C’ programming language using EB2C tool [15, 21] isstraightforward. The main idea is to translate an Event-Bmodel into ’C’ code using last concrete model. EB2C toolgenerates ’C’ files corresponding to the concrete models. Agenerated ’C’ file using EB2C tool has a basic structure: a

set of constants, variables and functions. A set of constantsand variables are extracted from the context and machinessections of the Event-B model, respectively. Data type of aconstant is defined as an axiom in Event-B model. Similarlydata type of a variable is extracted from the invariant sectionof the model. A set of constants and variables are given asfollows, which are excerpted from the translated ’C’ codesof the cardiac pacemaker model.

enum s ta tu s {ON,OFF} ;/∗ Enumerated d e f i n i t i o n ∗/

const i n t FixedAV=90;/∗ I n t eg e r in range 70−300 ∗/

const i n t LRL=60;/∗ I n t eg e r in range 30−175 ∗/

const i n t ARP=200;/∗ I n t eg e r in range 50−175 ∗/

const i n t URL=120;/∗ I n t eg e r in range 50−175 ∗/

const i n t VRP=250;const i n t PVARP=150;const i n t V Blank=50;. . .

enum s ta tu s PM Actuator V ;/∗ Enumerated type va r i ab l e ∗/

enum s ta tu s PM Sensor V ;/∗ Enumerated type va r i ab l e ∗/

unsigned long i n t Thr V ;/∗ I n t eg e r in range undef ined ∗/

unsigned long i n t AV Count ;/∗ I n t eg e r in range undef ined ∗/

BOOL AV Count STATE ;unsigned long l a s t s p ;unsigned long i n t sp ;unsigned long i n t Pace Int ;. . .

All the events of Event-B are translated into equivalent’C’ functions. An event INITIALIZATION is a ’C’ func-tion, which initialize default values of all the variables. Anevent of Event-B model has fixed organization of the inter-nal components: local variables, guards (pre-conditions) andactions. An event may contain some local variables. Theglobal constants and variables are declared on the top ofthe ’C’ source file, while local variables are declared withinthe function body. All events of a formal model is trans-lated as a set of ’C’ functions. During the translation ofthe events, the guards are translated into equivalent to ’if’statement using logical conjunction, disjunction, implicationand equivalence. Each guard represents into a separate ’if’statement like nested ’if’ structure. All these guards repre-sent a set of preconditions, which are required to satisfy forexecuting the action predicates.

All action predicates of an event are translatable into ’C’assignment expressions. EB2C tool is capable to analysethe syntax of Event-B guard and action predicates. All pre-conditions or guards are required to be TRUE for firing allthe set of actions. If all guards are true, then the actionspredicates execute and return TRUE for successful execu-tion of this ’C’ function. If any ’if’ condition false then this

186

EVENT Actuator ON VWHEN

grd1 : PM Actuator V = OFFgrd2 : (sp = Pace Int)

∨(sp < Pace Int∧AV Count > V Blank ∧AV Count ≥ FixedAV )

grd3 : sp ≥ V RP ∧ sp ≥ PV ARPTHEN

act1 : PM Actuator V := ONact2 : last sp := sp

END

Figure 5: Event of Formal Specification

’C’ function returns FALSE and actions part of the functiondoes not execute.

. . .BOOL Actuator ON V ( void ){

/∗ Guards No . 1∗/i f ( PM Actuator V == OFF){

/∗ Guards No . 2∗/i f ( ( sp == Pace Int ) | |( ( sp < Pace Int ) &&(AV Count > V Blank ) &&(AV Count >= FixedAV ) ) ){

/∗ Guards No . 3∗/i f ( ( sp >= VRP)&&(sp >= PVARP) &&( sp >= URI) ){

/∗ Actions ∗/PM Actuator V = ON;l a s t s p = sp ;

re turn TRUE;}}}

r e turn FALSE;}. . .

To make the generated code executable, the EB2C toolgenerates an Iterate function that contains a list of all func-tions in a calling order, which may be optimized or sequen-tial. Another function is main(), which calls Iterate func-tion. These two extra functions are used to make the gen-erated code executable.

The source code is automatically generated in ’C’ from theverified specification in less than five seconds. The generatedcode resulted in over 5000 lines in all the operating modes.Due to lack of space, we have presented a brief overview ofthe translation process from the Event-B specification of thecardiac pacemaker formal model into ’C’ using EB2C tool.Based on this translation, we were able to automaticallygenerate ’C’ code and execute a simulation of the pacemaker.We have used same approach to generate the source codesin other languages (C++, Java and c#). These codes areautomatically generated in C, C++, Java and C# codesfrom the verified specification. Due to lack of space, we onlyshow the translation of part of the sample codes.

5. CONCLUSION AND FUTURE WORKThis paper has introduced the main principles, some of the

rules for translating and implementation solutions for trans-lation tool and code verification techniques for generatingtarget programming language (C, C++, Java and C#) codefrom Event-B specifications [15]. The translation tool has

been developed as a set of Rodin plug-ins under the Eclipsedevelopment framework. The translation tool is rigorouslydeveloped with safety properties preservation. The resultsdetailed in this paper are an architecture of the transla-tion process, to generate a target language code from Event-B models using Event-B grammar through syntax-directedtranslation, code scheduling architecture and verification ofan automatic generated code. The syntax adopted is restric-tive, but it already covers most numeric applications, sup-ports powerful static-analysis methods and generates sourcecode in the target programming language. The paper showsthe translator architecture and verification of the generatedcode. Many algorithms (e.g. embedded system, distributedsystem) are subject to further refinement. The translatorprovides useful assistance to human programmers by auto-matically adding comments, generating code for each pro-cess, optimizing expressions and partitioning event as wellas data structures. The automatically generated commentshelp to a programmer to understand the significance of alldefined constants, variables and events from the formal spec-ifications. The translator generates a separate code for allevents of concrete modules. Systematic studies on parti-tioning methods using a refinement structure in the targetprogramming languages (C, C++, Java and C#) style is aninteresting area of future research. This approach may beapplicable to massively parallel processing.

The benefits of developing and enhancing the translationtool [15] presented stem primarily from their increased sup-port for automated translation between the two componentsof a formal model and target programming language. It hasbeen shown that the Event-B models have been transformedinto a deterministic model [28] for automatically source codegeneration using one more level of data refinement. The finalconcrete model provides sufficient refinement for introduc-ing full determinism and use an easily translatable subset ofthe notations [8]. The Rodin tool supports development ofthe translation tool under the Eclipse framework using allrequired model information via supported interfaces. Rodintool uses an internal database to handle model information,which allows model generation is based on underlying mean-ing of a model and reduces the syntax dependency.

The adaptation of the translation rules required more com-plete experiments, specially with large formal models forchecking the impact on the execution time for some specificplatforms. Finally, we have shown satisfactory results anddemonstrate the ability to generate automatically sourcecode from the Event-B specification of the cardiac pace-maker [23, 20, 22] in C, C++, Java and C# languages, whichare comparable to a code written by hand with ordinary pro-gramming languages. Generated code has been presented toa group of pacemaker developers (French-Italian based pace-maker development company). The developers are satisfiedby the result of code generation. The gains rely then onthe guarantees provided by the use of a formal method andon the certification level which can be obtained by this way.As far as we know, only few formal methods support codegeneration which is as time/space efficient as handwrittencode.

We are working on our translation tool and now we areimplementing last step of our tool chain; Generated codeverification. This is the most important and challengingtask in the development of tool. The reason is that thepreservation at the code level of the properties proved at

187

the architectural level is guaranteed only if - the underlyingplatform is correct and - correctness of final system whenfilling in the stubs for internal actions into the automaticgenerated code. It is our ongoing project, so we are continueextending this tool to support all other remaining Event-Bformal symbols, which provides freedom for a developer toformalised a critical system and automatic source code gen-eration of a developed model into any target language. Infuture, we have planned to extend this translation tool ofother kind target programming language such as PLC pro-gramming language, so that this translation tool [15] can beused by all industrial areas, whereas formal verification andvalidation are primary techniques to develop a system.

6. REFERENCES[1] J.-R. Abrial. Modeling in Event-B: System and

Software Engineering. Cambridge University Press.

[2] J.-R. Abrial. The B-book: assigning programs tomeanings. Cambridge University Press, New York,NY, USA, 1996.

[3] Ken Arnold, James Gosling, and David Holmes. TheJava Programming Language (Fourth Edition).Addison-Wesley Professional, 2005.

[4] Atelier B. Atelier de genie logiciel permettant dedevelopper des logiciels prouves sans defaut.http://www.atelierb.eu/.

[5] S. Serge Barold, Roland X. Stroobandt, and Alfons F.Sinnaeve. Cardiac Pacemakers Step by Step. FuturaPublishing, 2004. ISBN 1-4051-1647-1.

[6] Marco Bernardo and Edoardo Bonta. Generatingwell-synchronized multithreaded programs fromsoftware architecture descriptions. In WICSA, pages167–176, 2004.

[7] Marco Bernardo and Edoardo Bonta. Preservingarchitectural properties in multithreaded codegeneration. In COORDINATION, LNCS, pages188–203, 2005.

[8] Didier Bert, Sylvain Boulme, Marie-Laure Potet,Antoine Requet, and Laurent Voisin. AdaptableTranslator of B Specifications to Embedded CPrograms. In FME, pages 94–113, 2003.

[9] Dirk Beyer, Thomas Henzinger, Ranjit Jhala, andRupak Majumdar. The software model checkerBLAST, Applications to software engineering. STTT,9:505–525, 2007.

[10] Dines Bjørner and Cliff B. Jones, editors. The ViennaDevelopment Method: The Meta-Language, London,UK, 1978. Springer-Verlag.

[11] E. Bonta and M. Bernardo. PADL2Java: A Java codegenerator for process algebraic architecturaldescriptions. In Software Architecture, 2009 EuropeanConference on Software Architecture. WICSA/ECSA2009., pages 161 –170, 2009.

[12] Carlos Paiz Christopher Pohl and Mario Porrmann.vMAGIC-Automatic Code Generation for VHDL. InInternational Journal of Reconfigurable Computing.

[13] D. Coleman and J. W. Hughes. The clean terminationof Pascal programs. Acta Informatica, 11:195–210,1979. 10.1007/BF00289066.

[14] Patrick Cousot, Radhia Cousot, Jerome Feret, LaurentMauborgne, Antoine Mine, David Monniaux, and

Xavier Rival. Combination of abstractions in theastree static analyzer. In Proceedings of the 11th Asiancomputing science conference on Advances incomputer science: secure software and related issues,ASIAN’06, pages 272–300, Berlin, Heidelberg, 2007.Springer-Verlag.

[15] EB2ALL. Automatic code generation from Event-B tomany Programming Languages. http://eb2all.loria.fr/,2011.

[16] Andrew Edmunds and Michael Butler. Tool Supportfor Event-B Code Generation. In WS-TBFM2010,February 2010.

[17] Andrew Edmunds and Michael Butler. TaskingEvent-B: An Extension to Event-B for GeneratingConcurrent Code. In PLACES 2011, February 2011.

[18] James Gosling, Bill Joy, Guy Steele, and GiladBracha. Java(TM) Language Specification, The (3rdEdition). Addison-Wesley Professional, 2005.

[19] Brian W. Kernighan and Dennis Ritchie. CProgramming Language. Prentice Hall, 1988.ISBN-100131103628.

[20] Dominique Mery and Neeraj Kumar Singh.Pacemaker’s Functional Behaviors in Event-B.Research Report(http://hal.inria.fr/inria-00419973/en/), 2009.

[21] Dominique Mery and Neeraj Kumar Singh. EB2C : ATool for Event-B to C Conversion Support, Poster andTool Demo submission and published in a CNRTechnical Report in SEFM. 2010.

[22] Dominique Mery and Neeraj Kumar Singh. TechnicalReport on Formal Development of Two-ElectrodeCardiac Pacing System.(http://hal.archives-ouvertes.fr/inria-00465061/en/),2010.

[23] Dominique Mery and Neeraj Kumar Singh. Functionalbehavior of a cardiac pacing system. InternationalJournal of Discrete Event Control Systems,1(2):129–149, 2011.

[24] Overture Tool Box. Overture: Formal Modelling inVDM. http://www.overturetool.org/.

[25] David J. Pearce, Paul H.J. Kelly, and Chris Hankin.Efficient field-sensitive pointer analysis of c. ACMTrans. Program. Lang. Syst., 30(1):4, 2007.

[26] Project RODIN. Rigorous open developmentenvironment for complex systems.http://rodin-b-sharp.sourceforge.net/, 2004.

[27] Jeffrey Richter. CLR Via C#, Second Edition.Microsoft Press, Redmond, 2006.

[28] Richard L. Sites. Clean Termination of ComputerPrograms. Ph.D. dissertation, Stanford University,Stanford, California, June 1974.

[29] Jeffrey E. Smith, Mieczyslaw M. Kokar, and KennethBaclawski. Formal verification of uml diagrams: Afirst step towards code generation. In The UnifiedModeling Language, pages 224–240. GI, 2001.

[30] Bjarne Stroustrup. The C++ Programming Language,Third Edition. Addison-Wesley, 1994.

[31] Steve Wright. Automatic Generation of C fromEvent-B. In Workshop on Integration of Model-basedFormal Methods and Tools IM FMT’2009 - inIFM’2009, Dusseldorf, Germany.

188