Ravenscar Computational Model compliant AADL Simulation on LEON2

Transcription

1 Ravenscar Computatonal Model complant AADL Smulaton on LEON2 Roberto VARONA-GÓMEZ, Eugeno VILLAR TEISA, GIM, Unversdad de Cantabra Santander, Span {roberto, Ana-Isabel RODRÍGUEZ-RODRÍGUEZ OSV, GMV Aerospace and Defence SAU Tres Cantos, Span ABSTRACT AADL has been proposed for desgnng and analyzng SW and HW archtectures for real-tme msson-crtcal embedded systems Although the Behavoral Annex mproves ts smulaton semantcs, AADL s a language for analyzng archtectures and not for smulatng them AADS-T s an AADL smulaton tool that supports the performance analyss of the AADL specfcaton throughout the refnement process from the ntal system archtecture untl the complete, detaled applcaton and executon platform are developed In ths way, AADS-T enables the verfcaton of the ntal tmng constrants durng the complete desgn process In ths paper we focus on the compatblty of AADS-T wth the Ravenscar Computatonal Model (RCM) as part of the TASTE toolset Its flexblty enables AADS-T to support dfferent processors In ths work we have focused on performng the smulaton on a LEON2 processor Keywords: AADL, smulaton, Ravenscar, LEON2, SystemC 1 INTRODUCTION Archtecture Analyss and Desgn Language (AADL) [1-4] was developed as a Socety of Automotve Engneers (SAE) standard to enable the descrpton of task and communcaton archtectures of real-tme, embedded, fault-tolerant, secure, safety-crtcal, SW-ntensve systems It s used to descrbe the software and hardware components of a system and the nterfaces among them The Automated proof-based System and Software Engneerng for Real-Tme systems (ASSERT) project [5] led to a new development process for dstrbuted embedded real-tme software, and a set of methods and tools for supportng the process The process s based on separaton of concerns, automatc code generaton and property preservaton An mportant feature of the ASSERT process s the adherence of the concurrency model to the RCM [6], a restrcted taskng model that enables statc response tme analyss of real-tme systems The model restrcts the concurrency model to a statc set of perodc and sporadc threads communcated by means of a statc set of shared data objects, protected by mutual excluson synchronzaton mechansms There are two varants of the ASSERT software process: Hard Real- Tme Unfed Modelng Language (HRT-UML) and AADL tracks The ASSERT Set of Tools for Engneerng (TASTE) [7] toolset s an open source toolset supportng the latter The LEON2 [8] processor was desgned by the European Space Agency (ESA) as a 32-bt syntheszable processor core based on the SPARC V8 archtecture The core s hghly confgurable, and partcularly sutable for System on Chp (SOC) desgns There s a commonly recognzed need for new development frameworks that enable desgners to perform effcent exploraton of desgn alternatves and analyze system propertes throughout the desgn cycle Some system propertes can be obtaned by statc analyss Many other propertes can only be obtaned through smulaton In most complex cases, system smulaton s necessary for performance analyss under real executon condtons System smulaton valdates the correct dmensonng of the system, detecton of locks, mssed deadlnes and other potental problems caused by the complex nteracton among components that can be found n a real system The earler all those problems are detected, the less s the assocated cost of correctng them [9] Evolutonary prototypng s becomng a well-accepted development approach n Model-Drven Engneerng (MDE) [10] The desgn flow s based on a central model that s teratvely refned untl t s satsfactory Programs can be generated from ths model and consttute ntermedate versons of the product The last model refned corresponds to the fnal system A prototypngbased desgn process s of nterest to verfy, as early as possble, the mpact of deployment decsons, or the use of a partcular HW/SW component n the system In ths paper, an AADL smulaton methodology, now compatble wth the RCM, s recalled Ths methodology has been mplemented n the tool AADS-T [11] AADS s a smulaton framework that can support prototype-based ISSN: SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 11 - NUMBER 1 - YEAR

2 desgn allowng the functonal and non-functonal (executon tmes, power consumpton, etc) verfcaton of the system whle t s beng refned rght through to the fnal mplementaton AADS s based on SystemC, whch has become a relevant standard language for modelng and smulaton of HW/SW embedded systems [12] The SystemC framework supports the seamless ntegraton of HW components and an easy optmzaton of the executve platform The contents of the paper are as follows The followng secton revews the state of the art In Secton 3, the prevous work carred out wth AADS s summarzed Secton 4 descrbes how support s provded to perform the smulaton on a LEON2 processor Then, we explan the man part of ths paper, whch s the compatblty of AADS-T wth the RCM Next, a case study s presented and fnally conclusons are stated 2 STATE OF THE ART Several authors have consdered ASSERT and the RCM n ther research Some of ther papers deal wth the ASSERT Vrtual Machne (VM), the executon platform on whch ASSERT applcatons run, based on the RCM J A de la Puente et al [13] and J Zamorano et al [14] are good examples of ths M Bordn et al [15] propose some gudelnes to generate RCM-complant Ada code from HRT-UML S Mazzn et al [16] explan a MDE methodology for the development of hgh-ntegrty real-tme systems However usng UML does not facltate the low-level descrpton of the system Besdes, the dfferent vews of the system use dfferent formalsms, so one must modfy all vews on each change of the system to get a coherent model, hnderng rapd prototypng J Kwon et al [17] propose Ravenscar-Java, a hghntegrty profle for real-tme Java However we thnk that Java s not a good hgh ntegrty programmng language due to ts object-orented programmng features, ts automatc garbage collecton, and the proposed lmtatons to the extenson of real-tme mult-threadng that cause confuson Ocarna [10] s a tool sute that uses code generaton facltes n Ada and C to analyze AADL models The code generated s compatble wth the RCM After analyzng the state of the art, t follows that no approach uses SystemC [18], whch s a recognzed standard for modelng HW/SW platforms, wth ts great potental for ntegraton of processors, buses, memores and specfc platform HW Our soluton makes HW/SW co-desgn easer because of the use of SystemC SCoPE [19-20] s a C++ lbrary that extends the standard language SystemC wthout modfyng t It smulates C/C++ SW code based on two dfferent operatng system nterfaces (POSIX [21-22] and McroC/OS [23]) Moreover, t co-smulates these peces of code wth HW descrbed n SystemC SCoPE generates a fle wth ths SystemC descrpton of the model In prevous works [24-25], prelmnary versons of AADS supportng a part of the AADL standard and ts Behavoral Annex were developed Now we have mproved AADS to make t compatble wth the RCM and to take nto account the LEON2 processor AADS-T supports RCM-complant AADL smulaton n SystemC, thus enablng the HW platform to be modeled and permttng HW/SW codesgn The AADL model s based on Portable Operatng System Interface for UNIX (POSIX), so t supports many dfferent Real Tme Operatng Systems (RTOS) 3 PREVIOUS WORK Ths work s an extenson of AADS, an AADL smulaton tool wrtten n Java, whch was developed as a plug-n [26] of Eclpse [27] AADS enables the modelng of a subset of AADL ncludng the Behavoral Annex for purposes of mplementaton and smulaton The startng pont of the smulator s a functonal AADL specfcaton wthout detaled code For each component, the correspondng tmng constrants are defned Ths ntal AADL specfcaton supports the verfcaton of the global performance constrants of the system based on the specfc tmng constrants of the dfferent components The AADL model s parsed usng AADS and a model sutable for smulaton wth SCoPE s produced, n order to check whether the AADL constrants are fulflled As the desgn process advances and, on the one hand, the actual functonalty s attached to the SW components usng the correspondng source code and, on the other, the functonalty s mapped onto specfc platform resources, a more accurate performance estmaton s performed These refned propertes can be added to the AADL model and a new model can be generated by AADS By comparng the ntal tmng constrants wth these refned, tmng estmatons, t s possble to verfy the nonfunctonal correctness of the desgn process at any refnement step AADL enables the specfcaton of both the archtecture and functonalty of an embedded real-tme system AADS translates both to SystemC (see Fg 1) It parses the AADL model ncludng the Behavoural Annex so the functonalty s translated to an equvalent POSIX model and the archtecture s represented n extensble Mark-up Language (XML) [28] AADS supports multple HW components (processors, memores, devces and buses) Fgure 1 Translaton process 4 LEON2 MODELING In prevous works, SCoPE admtted only some of the Advanced RISC Machnes (ARM) famly processors The LEON2 processor was desgned by the ESA as a 32-bt syntheszable processor core based on the SPARC V8 38 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 11 - NUMBER 1 - YEAR 2013 ISSN:

3 archtecture The core s hghly confgurable, and partcularly sutable for SOC desgns SCoPE has been modfed to nclude the LEON2 processor at 50 Mhz, 154 Mllon nstructons per second (MIPS) and 3064 nj of energy consumed per nstructon n ts processorsxml confguraton fle It was necessary to specfy the data and nstructon cache szes too A sze of 8192, a sze of lne of 8 and an assocatvty of 1, consderng an nstructon sze of 4 (32 bts), was consdered for both Another confguraton fle of SCoPE, memnstxml, was modfed to nclude the operaton codes of the LEON2 The GNU cross-compler for LEON2 used s the GNAT for the LEON 210 C compler so, to be compled, the source code produced by AADS-T has to comply wth certan characterstcs of lttle mportance 5 COMPATIBILITY WITH THE RCM The real-tme behavor specfcaton of ASSERT models s based on the RCM, a model of concurrency for hghntegrty systems that enables formal analyss of the temporal propertes of a system usng response-tme analyss technques The model ncludes a statc set of concurrent threads of executon, communcatng by means of shared protected data wth mutually exclusve read and wrte access, and a restrcted form of condtonal synchronzaton The model s smple enough to be mplemented by a smple, small-sze real-tme kernel, thus easng the way to the eventual certfcaton of real-tme systems based on t Twelve propertes must be fulflled to be RCM-complant; the source code generated by AADS-T obeys all of them These propertes are stated n an nternal document of the HW-SW CODESIGN project [29] ttled R1-4 Evaluaton of Complance wth the ASSERT Process, wrtten by Juan Antono de la Puente and Juan Zamorano Basc Elements There are two man elements n the RCM: threads and protected objects A thread s the basc unt of executon, whch can be executed concurrently wth other threads on a sngle processor Protected objects are an abstracton of shared data, synchronzaton, and nterrupt handlng There are a statc number of threads and protected objects Therefore, threads and protected objects can only be created at system ntalzaton tme RCM 1: A real-tme system conssts of: A statc set of N threads, Τ = { τ }, 1N A statc set of M protected objects, Ο = { θ }, 1M The set Ο may be empty (M = 0), n whch case the system s sad to have only ndependent threads In the source code generated by AADS-T all the threads and protected objects are created callng pthread_create and as objects of the correspondng classes respectvely at system ntalzaton tme Propertes of Threads A thread s a concurrent unt of executon wth the followng propertes: RCM 2: Threads are non-termnatng They exhbt an endless repettve behavor alternatng between the followng states (see Fg 2): Suspended: a suspended thread s not elgble for executon Ready: a ready task can be executed when the processor s allocated to t Fgure 2 States of RCM threads RCM 3: Threads have a sngle actvaton pont An actvaton pont s a pont n the executable code of a thread at whch ts state changes from Suspended to Ready When actvated, a thread becomes ready and then executes a pece of sequental code (thread actvty), after whch t becomes suspended awatng the next actvaton Threads of the source code generated by AADS-T use whle(true) to be non-termnatng They are suspended after executng the sequental code n a clock_nanosleep and when sleepng tme has passed they become ready at ther sngle actvaton pont RCM 4: The actvty of a thread s a sequence of code wth a bounded and known worst-case executon tme (WCET) The WCET of thread τ s C AADS-T utlzes the AADL property Compute_Executon_Tme to know the WCET of a thread The source code generated checks that ths WCET s not exceeded Ths property mples that a thread does not execute any operaton that could result n ts becomng suspended other than the suspenson mmedately before the actvaton pont So do the threads created by AADS-T RCM 5: A thread can be actvated only by one of the followng two knds of events: One s by a tmng event whch s ssued perodcally by the envronment In ths case the thread τ s sad to be perodc or tme-drven wth perod T The other s a synchronzaton event ssued when the barrer of a synchronzaton protected object s opened (see RCM 8 below) In ths case, the thread τ s sad to be sporadc The synchronzaton event must have a mnmum nter-arrval tme assocated to t, e a mnmum elapsed tme nterval between two consecutve occurrences of the event, T AADS-T uses the AADL propertes Perod, Dspatch_Protocol and Devce_Dspatch_Protocol to ISSN: SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 11 - NUMBER 1 - YEAR

4 know the perod and the type of a thread respectvely It accepts only perodc and sporadc threads and not aperodc or background threads The dfference between the codes generated s that a sporadc thread wats for an event from an event or eventdata port connecton after nvokng a synchronzaton operaton n the actvaton pont In both cases clock_nanosleep wats a tme T Propertes of Protected Objects A protected object s an object whch encapsulates a set of data and a set of assocated operatons (protected operatons) The value of the data makes up the state of the object The state can only be read or changed by nvokng one of the operatons of the protected object If θ s a protected object: θ S denotes ts state, θ S S, where S s an approprate data doman θ P k denotes the k -th operaton of θ Notce that a protected object must have at least one operaton; otherwse ts state s naccessble The notaton τ θ wll be used to denote that τ nvokes one or more operatons of θ Smlarly, τ θ P means that τ calls the operaton θ P AADS-T generates an object of the correspondng class whch s a protected object n the source code for each AADL data, event and eventdata port connecton Classes generated by AADS-T have the approprate data members to acheve the communcaton of data and/or events between threads Each class has a constructor and member functons read and wrte to ntalze and access data members Protected objects have the followng propertes: RCM 6: Only one thread can be executng an operaton of a gven protected object at any gven tme, e protected operatons are mutually exclusve Consequently, f a thread nvokes a protected operaton at a tme when another thread s already executng an operaton of the same object, t has to wat When the protected operaton that was beng executed s completed, the watng thread s allowed to execute the operaton t had nvoked Notce that a thread that s watng to begn a protected operaton s not consdered to be suspended In consequence, a thread actvty can nvoke protected operatons wthout volatng RCM 4 Each class produced by AADS-T defnes a mutex that s locked when a member functon s called and unlocked when t ends, ensurng complance wth mutual excluson RCM 7: All protected operatons have a bounded and known WCET The WCET of the protected operaton θ P s C, k Agan, ths property mples that no operatons that could result n a thread beng suspended can be nvoked from a protected operaton AADS-T uses the ad hoc defned AADL propertes (newly defned propertes n the property set UC) PO_read_WCET and PO_wrte_WCET for each port connecton to know the WCET of each member functon The source code generated checks f these WCETs are k exceeded Moreover, no member functon calls any suspendng operaton RCM 8: A protected object can have at most one synchronzaton operaton that has an assocated barrer, whch s a Boolean varable that s part of the object state When the value of the barrer s true, the barrer s sad to be open, and otherwse t s sad to be closed The behavour assocated wth synchronzed operatons s as follows: When a thread nvokes a synchronzaton operaton, f the barrer s open the executon proceeds as wth an ordnary protected operaton; but f the barrer s closed, the thread s blocked At most one thread can be blocked at a barrer at any gven tme A thread that s blocked at a barrer s unblocked whenever the barrer becomes true (as the result of the executon of another protected operaton by some other thread) Invokng a synchronzaton operaton s a potentally blockng operaton, and thus cannot be done wthn a thread actvty; ths can only be used to mplement the actvaton events of sporadc threads In the source code produced by AADS-T only the objects correspondng to event and eventdata port connectons have a synchronzaton member functon because a sporadc thread s dspatched by an event as stated above Only sporadc threads nvoke the synchronzaton The classes correspondng to event and eventdata port connectons have a POSIX condton varable as a datum member that s ntalzed at system ntalzaton tme The barrer s ntalzed as false n the constructor, then set to true n the wrte member functon (besdes sgnallng the condton varable to unblock the sporadc thread), then checked to see whether t s false n the synchronzaton to block the sporadc thread on the condton varable, and fnally set to false after unblockng t Schedulng The RCM s assocated wth an nstance of the fxedprorty pre-emptve schedulng (FPPS) method, together wth the mmedate celng prorty nhertance protocol (ICPP) The schedulng model s defned by the followng propertes: RCM 9: Each thread τ has a basc prorty, P P Z, where Z s the set of the nteger numbers The basc prorty of a thread s fxed, e t s never changed AADS-T uses the ad hoc AADL property Prorty to create a thread at system ntalzaton tme wth sched_prorty at that prorty, whch s never changed RCM 10: Each protected object θ has a celng prorty CP whch s the maxmum of the basc prortes of all the threads nvokng any of ts operatons: CP =max P, τ θ j j 40 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 11 - NUMBER 1 - YEAR 2013 ISSN:

5 As basc prortes of all threads are fxed so too are the celng prortes of all protected objects RCM 11: At every nstant of tme, each thread has an actve prorty The actve prorty of a thread s the maxmum of: The basc prorty of the thread, and The celng prorty of all protected objects that contan an operaton that s currently beng executed by the thread Therefore, whenever a thread nvokes a protected operaton, t mmedately nherts the celng prorty of the enclosng protected object In the source code generated by AADS-T the functon pthread_mutexattr_setprotocol s used wth the value PTHREAD_PRIO_PROTECT and the functon pthread_mutexattr_setprocelng wth the maxmum of the prortes of the two threads communcatng through a port connecton Ths s done when ntalzng the mutex of the object correspondng to that connecton at system ntalzaton tme guaranteeng the fulfllment of RCM 10 and RCM 11 RCM 12: Ready threads are conceptually grouped nto ready queues There s a ready queue for each prorty level n P Threads are added to and removed from prorty queues accordng to the followng rules: When a suspended thread becomes ready, t s added at the tal of the prorty queue for ts actve prorty When the processor s dle, the thread whch s at the head of the non-empty ready queue wth the hghest prorty s dspatched for executon and removed from the queue Whenever there s a non-empty ready queue wth a hgher prorty than the prorty of the currently runnng thread, the thread s preempted from the processor and t s added at the head of the ready queue for ts actve prorty Notce that accordng to the prevous rule, the thread at the head of the ready queue that caused the pre-empton s dspatched for executon mmedately afterwards AADS-T admts only SCHED_FIFO for the ad hoc AADL property POSIX_Schedulng_Polcy of a thread, to set so sched_polcy n the source code The above model specfes a concurrent system wth a predctable, analyzable temporal behavour Snce the executon tme of threads s bounded (RCM 4, RCM 7) and the schedulng method s FPPS wth ICPP, wellknown response-tme analyss technques can be appled to statcally guarantee that the system satsfes ts temporal requrements 6 CASE STUDY AADS-T has been tested n the case study shown n Fg 3, to assure the feasblty of the translaton and ts compatblty wth RCM It s a space applcaton of dgtal mage processng that conssts of dfferent modules for mage processng, scence data reportng, control, LEON target on board SW and payload data handlng unt The fles produced by AADS-T are compled wth SCoPE to smulate the model and the results obtaned are used to refne the model as needed The smulaton executed the source code of the threads and the protected objects enabled the communcaton among the threads Durng the smulaton we have observed that all the threads and protected objects were created at the begnnng and ther number remaned statc durng the smulaton We have also observed that the threads do not termnate tll the smulaton tme ends as stated n a parameter for SCoPE The threads alternate ther executon as they become suspended or ready The trace of the smulaton shows that each thread actvty s executed from the correspondng actvaton pont We have been able to dstngush clearly between perodc threads and threads actvated by an event Varous protected objects correspondng to dfferent port connectons (data, event and eventdata) between threads have been tested to assure a sutable communcaton between the threads Fgure 3 Case Study functonal descrpton ISSN: SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 11 - NUMBER 1 - YEAR

6 It has been proven that f the WCET of a thread or a protected operaton s exceeded, a warnng message appears n the trace of the smulaton Synchronzaton operatons have been tested on sporadc threads dspatched by event or eventdata We have appled dfferent prortes of threads and protected objects to test the schedulng method FPPS wth ICPP Smulaton on a LEON2 processor dffers notably after applyng AADS+ [25] or AADS-T (see Table I) The AADL model requres more lnes to apply AADS-T but there are not as many C++ code lnes generated as one mght fear As ths code s RCM-complant, t does not use POSIX sgnals or message queues (sendng and recevng sgnals and messages are more tme consumng than read and wrte protected operatons), so SCoPE can execute many more nstructons and threads and load the bus more For ths reason, the cost n terms of core energy/power, msses, etc s certanly greater TABLE I COMPARISON BETWEEN THE TWO SIMULATIONS' METRICS 7 CONCLUSIONS AND FURTHER WORK Ths paper descrbes the compatblty wth RCM of the AADS-T smulaton tool AADS-T supports the refnement of AADL models, ncludng the Behavoral Annex, through performance analyss done wth SCoPE, after translatng those models The generaton of the SystemC model from the Ravenscar Computatonal Model complant AADL specfcaton s not straghtforward Nevertheless, the SystemC model generated by AADS-T s able to capture the fundamental dynamc propertes of the ntal system specfcaton In ths way, AADS-T supports desgn space exploraton by refnement of the AADL functonalty and ts mplementaton on an optmzed platform Future work ncludes ncorporaton of AADS-T features that appear n V20 of the AADL standard 8 ACKNOWLEDGEMENT Ths work has been supported by ESTEC 22810/09/NL/JK HW-SW CODESIGN Project contracted to GMV Aerospace and Defence SAU The authors would lke to acknowledge the ad receved n ths work from Francsco Ferrero Mateos and Elena Alaña Salazar of GMV, as well as from Juan Antono de la Puente and Juan Zamorano 9 REFERENCES [1] SAE: AADL June 2006, document AS5506/1 wwwsaeorg/techncal/standards/as5506/1 [2] P H Feler, D P Gluch, J J Hudak: The AADL: An Introducton CMU Pttsburgh (2006) [3] P H Feler, J J Hudak: Developng AADL Models for Control Systems: Practtoner s Gude CMU 2006 [4] SAE Annex Behavor V20 AS5506, 2007 [5] wwwassert-projectnet 2008 ESA/ESTEC [6] A Burns et al: The Ravenscar taskng profle for hgh ntegrty RT programs Ada-Europe 98 Sprnger-Verlag [7] M Perrotn et al: The TASTE toolset: Turnng human desgned heterogeneous systems nto computer bult homogeneous software ERTS2 2010, Toulouse, France [8] LEON2-FT ESA Mcroelectroncs 2009 wwwesant/ TEC/Mcroelectroncs/SEMUD70CYTE_0html [9] AD Pmentel et al: A systematc approach to explorng embedded system archtectures at multple abstracton levels IEEE Transactons on Computers, 2006 [10] J Hugues, B Zalla, L Pautet, F Kordon: From the prototype to the fnal embedded system usng the Ocarna AADL tool sute ACM TECS, 2008 NY, USA [11] AADS V31 UC 2011 wwwtesauncanes/aads [12] H Posadas et al: RTOS modelng n SystemC for realtme embedded SW smulaton: A POSIX model Desgn Automaton for Embedded Systems Sprnger 2005 [13] J A de la Puente et al: The ASSERT VM: A Predctable Platform for Real-Tme Systems IFAC08 Korea [14] J Zamorano et al: The ASSERT VM kernel: Support for preservaton of temporal propertes DASIA 2008 Span [15] M Bordn et al: Automated Model-based Generaton of Ravenscar-complant Source Code ECRTS05 Span [16] S Mazzn et al: An MDE Methodology for the Development of Hgh-Integrty RT Systems DATE09 [17] J Kwon et al: Ravenscar-Java: a Hgh-Integrty Profle for Real-Tme Java ACM-ISCOPE, 2002 Washngton [18] Davd C Black, Jack Donovan: SystemC: From the ground up Kluwer Academc Publshers Boston (2004) [19] SCoPE V110 UC 2009 wwwtesauncanes/scope [20] H Posadas et al: SystemC Platform Modelng for Behavoral Smulaton and Performance Estmaton of Embedded Systems 2009 IGI Global [21] M González: POSIX tempo real UC, Santander 2004 [22] The Open Group: The Sngle UNIX Specfcaton, V 2, 1997 wwwopengrouporg/onlnepubs/ [23] J J Labrosse: µc/os RT Kernel ISBN [24] R Varona Gómez, E Vllar: AADL Smulaton and Performance Analyss n SystemC ICECCS 2009 Germany [25] R Varona Gómez, E Vllar: AADS+: AADL Smulaton ncludng the Behavoral Annex ICECCS 2010 Oxford [26] P H Feler, A Greenhouse: OSATE Plug-n Development Gude CMU Pttsburgh (2006) [27] The Eclpse Foundaton 2009 wwweclpseorg [28] W3C: Extensble Markup Language (XML) W3C Recommendaton (2006) wwww3org/tr/rec-xml/ [29] 42 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 11 - NUMBER 1 - YEAR 2013 ISSN: