1992-8645 an efficient architecture for … · an efficient architecture for semantic evolution of...

Journal of Theoretical and Applied Information Technology20th August 2015. Vol.78. No.2

© 2005 - 2015 JATIT & LLS. All rights reserved.

ISSN: 1992-8645 www.jatit.org E-ISSN: 1817-3195

314

AN EFFICIENT ARCHITECTURE FOR SEMANTICEVOLUTION OF EMBEDDED SYSTEM

SMT. J. SASI BHANU1, A. VINAYA BABU2, P. TRIMURTHY3

1 Assistant professor, Dept. of Computer Science and Engineering, KL University, Guntur, India2 Professor, Dept. of Computer Science and Engineering, JNTU, Hyderabad, India

3 Professor, Dept. of Computer Science and Engineering, ANU, Guntur, India

E-mail: [email protected], [email protected], [email protected]

ABSTRACT

Embedded systems (ES) are being used these days for monitoring and controlling Safety or mission criticalsystem. Mission and safety critical systems as such will not be shut down for the reasons of safety and alsodue the cost of restarting. Changes are inevitable for any system either due to the reasons of updating themodules contained in the ES software or addition of new modules for the reasons of adding newfunctionality. The changes to the ES software required are to be undertaken online while the ES system isup and running. Ability to make changes to the software while the system is running is called dynamicsemantic evolution. For any software architecture is the basis. Modules are to be reflected in thearchitecture that support dynamic evolution of the embedded software. Many architectures have beenproposed in the literature that cater to the dynamic semantic evolution of loaded systems. Everyarchitecture proposed incorporated only one method of undertaking the dynamic evolution. Many methodshave been in existence for dynamically evolving the embedded systems but all the available methods havenot be brought under the same architecture. In this paper a comprehensive architecture is presented thatconsiders all available approaches that help implementing dynamic semantic evolution of the ES software.

Keywords: ES Architectures, Dynamic Semantic Evolution, Monitoring And Controlling Safety CriticalSystems, Software Evolution

1. INTRODUCTION

Semantic evolution of a running software isdynamically updating a computer program, while itis executing. Dynamic updating is crucial inapplications where the cost of stopping andrestarting the program makes doing so impractical.Mission critical and safety critical systems such asnuclear reactor systems cannot be stopped formaking changes and therefore the changes must bemade while the system is running. Computersoftware changes constantly. Change may benecessary because new features were to be added toa program or because bugs were discovered in thecurrent version or improvements to the existingprogram units are to be carried.

Sometimes the changes have to be carried whilethe system is running as bring down the system forwant of making changes would be expensive.Examples of such systems include a airlinereservation system or a telecommunications

switching system or a computer-controlled life-support system or an air-traffic control system. Theability to dynamically update a program, i.e., load anew version of a program without stopping thecurrently running version, could alleviate the costsinvolved in making changes to a running program.

Prior approaches to the problem of replacingportions of computer programs without stoppingthem can be classified into three main categorieswhich include hardware-based, service- oriented,and procedural based. Several strategies have beenpresented in the past to undertake dynamicevolution of the software. The techniques includehardware based redundant systems, abstract datatype systems, client server based systems, Modulebased systems, Architectural based systems etc.

The architecture level based systems deals withdynamic evolution as the capability of modelingarchitectures in which the number of components,connectors, and bindings may vary when the




315

software system is executed. Dynamism has alsobeen defined as an aspect of configuring andallowing replication, insertion and removal, andreconnection of architectural elements eitherstatically and dynamically. Support for dynamicreconfiguration at run-time is supported in terms ofreconfiguration manager . A supervisor can senddirectives in a script language to the system thatinvoke dynamic reconfiguration. Every elementcan be either added, removed, or replaceddynamically but from external tools only. Theoperations for describing change include addingcomponents, removing components, upgrading orreplacing components, changing the architecturetopology by adding or removing connectionsbetween components, altering the mapping ofcomponents to processing elements, queryingproperties of architectural elements, obtainversioning information and querying the currentarchitectural topology. A typical change willrequire several modification operations.

Every system must be adaptable considering theapplication architecture or in the way the data isexchanged. The new software modules must beable to interact with the old software moduleconsidering the changes that might come up in thevery programming languages using which thesoftware is developed. When changes are made tothe software it is also necessary to consider otherissues that include fault tolerance, scalability andperformance. The scalability of the Hardware anddata must also be taken into account.

Specific architectures are required forimplementing dynamic evolution of the embeddedsystems for that matter any type of a system. Thearchitectural models that evolve at run rime arecalled dynamic and the models that do not getchanged after the software is implemented arecalled static architectural models. Staticarchitectural modeling notations do not supportconstructs that are required to express runtimechange. Notations and tools must be added todescribe run-time architectural changes. When thenotations and the tools are added to staticarchitectures they become dynamic architectures.

Dynamic architectures require formalisms andtools beyond those of static architectures. Adequatenotational constructs are needed to describe runtimechange, analysis tools are needed to help verifytheir unique properties, and runtime supportlibraries are needed to reduce the costs associatedwith their implementation.

The architectural modifications can occur duringfour periods of time which include design time, pre-execution time, constrained run-time and run-time.Changes made during constrained based run timeare safe and generally do not disturb the ongoingprocess. When modifications are carried that crossarchitectural boundaries, system integrity may belost. Mechanisms that maintain system integrity inlight of architectural modifications are needed.Modification constraints provide a means to specifylimits on what aspects of an architecture maychange. They may restrict change based onmodification operation, particular components,modification time, or a combination thereof. Theymay also require that functional properties beverified before a change is committed. Constraintsmust be related to behavioral properties of thesystem and must allow trade-offs if all constraintscannot be met simultaneously.

Architectural languages are required to supportrun time changes. The existing architecturallanguages describe static architectures. Twoadditional descriptions are required which includemodification language (AML) and constraintlanguage (ACL) are also required. Architectureplays a vital role to define the way the dynamicevolution of the ES software is to be undertaken.

Thus many methods and several architectureshave been in existence for undertaking the dynamicevolution of the loaded systems. But the limitationis that every architecture just supported only onemethod. Very few architectures and many methodshave been presented which are related to dynamicevolution of embedded system. Every architecturethat suits embedded systems also have beenincorporated with just one method. Thus there is arequirement of presenting a comprehensivearchitecture that incorporates all the existingmethods into a single architecture so that all aspectsof dynamic evolution of embedded software can beundertaken.

2. PROBLEM DEFINITION

Embedded systems are quite frequently used formonitoring and controlling Mission and safetycritical systems. The embedded systems are drivenby a HOST which is located at a long distanceconnected through Internet. Embedded softwarekeep changing either to improve response time,implement efficient sensing and actuating system,add more tasks, delete the existing tasks, improvethe algorithm or processing implemented through




316

existing tasks etc. The embedded systems whichmonitor and control the mission or safety criticalsystem cannot be shut down for want of makingchanges due to the nature of criticality attached toit. The changes to the ES software thus must beundertaken while the system is up and running. Anychange required must be initiated from the remotehost and the same has to be effected within the ESsoftware without actually bringing the ES systemdown

Very few architectural model exists and eventhese few implements only one method ofdynamically evolving the ES software. Manysoftware components are to be added into thearchitectural models which are all required tosupport various methods. No architectures as suchhas been recommended ever that considers dynamicevolution under the ambit of an RTOS.

The main problem thus is to find the architecturalmodels that can be implemented for the dynamicevolution of ES software. The architectural modelsshould consider all the methods and the relatedcomponents, tasks, processes etc., which arerequired to implement dynamic evolution of ESsoftware. It is also necessary to consider all thosecomponents that are required for dynamic evolutionof ES system that runs under the control of a realtime operating system.

3. LITERATURE SURVEY

Lui Sha et. al., 1996][9] have presented aSimplex Architecture that considers upgrades tothe existing systems using new technologies andensuring safe, reliable, with negligible down time.The Simplex Architecture was originally developedto support safe online upgrades to a feedbackcontrol and radar systems regardless of the faultsthat might exist in the modeling, designing andimplementation of the new software and hardware.The simplex Architecture is considered theevolution of the architecture itself while the systemwhich is developed using the very architecture isevolved. The simplex architecture considereddynamic evolution by incorporating independentmodules that ensures timing, fault tolerance throughhandling exceptions, monitor system status,configure the system as required and to provide theinterface for the users to manage changes online.To manage the changes online, advanced real timeresources management technology has beenincorporated into the architecture. The simplex

architecture considers, real time processmanagement primitives.

Peyman Oreizy[4] presented that run-timeevolution of the software require dynamicarchitectures that evolve as the system runs. Theevolution is done online. Most of the systemsrequire online updates without bringing down thesystem which is already running. Staticarchitectures will not be able to cater to incorporatedynamic changes. End-user customizability andextensibility also requires runtime evolution.

Huw evans [3] have presented an architecturetitled DRASTIC that supports run-time adaptabilitythrough implementation of run-time type changesand system configuration. The architecture uses akind of abstraction called “ZONE” for effecting theevolution. DRASTIC divides the system intosmaller and more easily managed sub-domainscalled zones. The change is encapsulated into theZones and a change in one zone will not affectanother zone. Zones to start-with are recognized atdesign stage and become explicit components at runtime. Software in one zone is evolvedautonomously from software in other zones, eventhough the source code may originally been sharedby components in many zones. Peyman Oreizy[4]have presented an architecture-based approachbased on which software evolution is undertakenthrough use of software connectors. Theimplementation of the architecture is undertakenthrough use of the tool called ArchStidio.

Software architectures D. E. Perr [8], M. Shaw[10] can provide a foundation for systematicruntime software evolution. An architecture-basedapproach to runtime software evolution has beenproposed that includes an explicit architecturalmodel, which is deployed with the system and usedas a basis for change, preservation of explicitsoftware connectors in the system implementation,and an imperative language for modifyingarchitectures. A tool suit has also been presentedthat supports runtime software evolution at thearchitectural level. The architecture proposed bythem considered various aspects related to changemanagement that include change policy, changescope, separation of concerns, level of abstractionat which change must be carried and the type ofchange that must be made.

Peyman Oreizy [4] have presented an approachwhich uses architecture of the software as a basis.The architecture as such describe and reason aboutthe systems behavior D. E. Perr[8], M. Shaw [10].




317

Change can be effectively managed by exploringthe system level knowledge of the architect. Eventhe off-the-shelf components can be accommodatedif no restrictions are imposed on the componentinternals. The change application policies areencapsulated into connectors which are independentof the functional components making it possible toseparate change policy independent of thefunctional support.

Peyman Oreizy [4] have presented, the waythe architectures support different types of softwareevolution and the circumstances which leads tomaking changes to the software. As such they haveconsidered three characteristic type of evolutionsthat include corrective, perfective and adaptive.Software faults are removed through correctiveevolution. Enhancement of the applicationfunctionality can be achieved thorough perfectiveevolution and adaptive evolution changes makesthe software adapt to a new environment.

Many design styles are in existence using whichcomponents can be added to the running system.Observers design Pattern E. Gamma [5] allowsaddition of more observers with minimal impact. Inthe mediator design approach, new mediators canbe introduced that maintain relationships betweenindependent components. Design approaches thatconsider the implicit invocation methods D. Garlan[6] are more effective to add components at run-time. Invoking components are generally unawareof the other components running at the time ofinvoking. Methods have been added which helpnew components discover the state of the systemand perform necessary actions to synchronize thenew components with the ongoing state of thesystem. When new components are to be added,structural changes to be made to the architecture ofthe software must be specified. The changes to thestructure some-times are implicit or derived fromexternally visible properties of the components.

Another approach, exemplified by the Simplexarchitectural style Gilsi Hjalmtysson [9],incorporates an “operational model” in theimplementation. The model rejects upgradedcomponents when they do not satisfy explicitperformance and accuracy requirements. Manysystems cannot tolerate loss of system state. In suchcases the state of the system must be preservedduring the change. More of the considerations areto be included in additions to those related toaddition and removal of the components. Severalmethods have been proposed that preserve the state

and communication when run time changes are tobe undertaken.

Structural reconfiguration of the architecturesupports recombining existing functionality tomodify overall system behavior. Data-flowarchitectures, such as UNIX’s pipe and filter styleand Weaves M. M. Gorlick[7], provide substantialflexibility through static reconfiguration of existingbehaviors. Runtime reconfiguration can beperformed by altering connector bindings sinceconnectors mediate all component communication.

Lawrence Chung[11] have presented howsemantic evolution of a remotely controlledembedded system can be carried. They havepresented a three tire architecture using which thesemantic evolution of the embedded systems can becarried. The overall architecture proposed by themcontains syntax evolution block, sematic evolutionblock and a communication interface. Run-timemodule adaption is a very powerful technique thatallows the system to change its behavior in manydifferent ways. New modules are generated at run-time to enable the system to adapt to the change inenvironment. Code generation algorithms arerequired in this case to generate code based on thecommands received. Based on the commandreceived, one of the module is linked. The modulegeneration could be undertaken by taking instanceof a template class or including the new class in theclass library or by loading the class using the classloader.

A system is adaptable if an adaptation functionexists. Adaptability then refers to the ability of thesystem to make adaptation. Adaptation involvesthree tasks which include ability to recognize,ability to determine the change to be made to asystem, ability to effect the change in order togenerate the new system. The adaption involvesverification and validation to ensure the correctnessof the modified system.

Dominic Duggan[12] has presented that hotswapping of running modules as one of the mostimportant requirement to be supported forachieving dynamic evolution essentially withinserver based software based systems. Under such asystem a new module be able to change the typesexported by the original module while preservingthe type safety. Type based approach of swappingrunning modules is the most important approachthat got evolved over the time. Programmer




318

defined version adapters at run-time adds typesharing constraints to the type system.

Michael Hicks [13] has developed a dynamicevolution system considering flexibility that takesinto account the time at which the change iseffected, robustness considering type safety,completeness, well-timed, simplicity, rollbackenabled, efficiency and ease-of-use. Dynamicevolution has been presented as practical andgeneral purpose when compared to the othersolutions presented in the literature which arespecific purpose and application dependent.

Narayanan [14] have presented severalarchitectures that can be used for evolution ofvocabulary of the embedded system which isnothing but evolution of command language whichis used to effect communication between the HOSTand the Embedded System. GARP [15] hasproposed an architecture that combinesconfigurable hardware with a standard MIPSprocessor on the same die. The architecture can beused for configuring the Hardware in microseconds.The GARP compiler can implement instructionlevel parallelism (ILP) from C code and directlycompile selected loops to the reconfigurable array.

M. Kau [20] proposed a SPARCS frameworkincludes a synthesis tool that estimates systemresources and latency. An Integer LinearProgramming(ILP) model is formulated to solvespatial and temporal partitioning problems. Thisflow is complete and well defined and mostlydependent on traditional hardware. Sasi [19] havepresented a basic architectural model that caters forsyntax evolution of the embedded systems.

Many presentations have been made for dynamicevolution of loaded systems. Few contributionshave been related to dynamic evolution ofembedded systems. An embedded system can beevolved by using different methods which include,invoking the tasks which are in dormant stage at therun time, rule based self-adaptability, Online codegeneration, online simple update and online updateconsidering the criticality of the update etc. Eachdynamic evolution method presented in theliterature looks into only one kind of dynamicevolution. It is necessary to comprehend differentkind dynamic evolution methods that can be usedand come out with a comprehensive model intowhich all kinds of dynamic evolution methods areincorporated considering the embedded systems.

4. INVESTIGATIONS AND FINDINGS

Several kinds of archliberal models can bedesigned which can be implemented for achievingdynamic evolution of the embedded systems. Thearchitectural models that can be used includeArchitecture based on stored data model.Architecture based rule based model, Architecturebased on code generation, Architecture based oncode migration, architecture that considers codeupdating considering both critical and non-criticalupdates

4.1 Architecture Based on Stored Data Model

In the stored data technique all the codecomponents are pre-identified for each of thechange expected in the environment andappropriate code is used based on the state of theembedded system. The change in this case is to bepre-identified and components are to be providedand made available right in the beginning beforereset of the micro controller. A state machine keepstrack of current state of the system. The change inthe environment is recognized as change of state ofthe embedded system. Every change is recognizedas the state of the machine.

An embedded system can be considered to be in astate when a particular external or internal event isbeing executed. The execution of a Task which is aunit of code will be based on the occurrence of anevent. The code units which are future additions orupdates to the existing tasks are to be identifiedwith pre-defined units. The commands to activatethe new code units are pre-identified and when suchcommands are received the relevant Tasks areinvoked. The tasks that are invoked will be made tobe waiting for the occurrence of its related event.




319

Sensor System

Actuator System

A/D Conversion

D/A Conversion

InterruptService

Routines

Control Logic

Add Task Update Task

Syntax Evolution

Communicationinterfce

Semantic Evolution

Delete Task

ES ApplicationtasksRTOS

Figure 1 Semantic Evolution Based Stored Data

Figure 1 shows the architecture for the storeddata model. In this architecture also all thecomponents required for catering to the changedenvironment are to be identified and make availableright in the beginning of the development of thesystem before the same are to be migrated to theTarget System. The code elements that are notrequired or in dormant state initially and they arebrought into the main stream based on thecommand that it receives. When a code element isinitiated to be brought into the main stream, theaddress of the code element, event that triggers theTask is to be sent along with the command toinvoke. Invoking is like adding new task. Chainingnew task with other tasks is achieved throughmaking the task to wait for a particular event.

Stored data means, the code elements whichare pre-stored and made available in the addressspace of the entire ES application. The pre-storedcode elements are only made to be active at runtime. The stored data model is not a true dynamicevolution model even though code elements whichare not active are activated at run time. A programstructure is required to be followed such that allvariables will be global variables.

4.2 Architecture Based on Rule Based ModelRule based model recognizes a set of rules and

the rules recognizes the changes that should beeffected within the semantics of ES application.The component dealing with the rules will parse therules set the environment data and invoke the set oftasks that comply and fulfil the rule. This approachis specifically suitable when control of the

production system must be done based on theconfiguration data and the conditional logic. Fig 2shows the architecture suitable for rule basedadoption.

The remote HOST shall provide the commandand associated rules to be adapted to syntaxevolution model and the rules are handed over tothe semantic evolution component. The semanticevolution component hands over the rules to beadapted to the rules manager. The rules manger willprocess the rules, parses the same and generatessome internal events and the tasks that are waitingfor those events are executed. The rules manageralso sets the environmental data generallymaintained as global variables. The rules aremaintained in a lookup table and the table which ismaintained dynamically through commands issuedby the remote HOST. If an existing rule is the oneto be adapted then the HOST just transmits thecommand and the name of the rule to be adapted.The control data required for the rules to be adaptedsometimes gets acquired automatically through thesensors which triggers the interrupts required. Inthis case also all the Tasks must have identified andhave been built along with ES application right inthe beginning. Rules implements dynamicevolution to certain extent when overall functioningof the embedded systems must be changed based onrules fed from a remote location, the control datafor which is either obtained through the sensors ortransmitted from the remote HOST.

Sensor System

Actuator System

A/D Conversion

D/A Conversion

InterruptService

Routines

Control Logic

ES Tasks

Rules manager

Synatx Evolution

Communicationinterface

SemanticEvolution

AdditionalTasks

RTOS

Figure 2 Rules Based Dynamic Adaption




320

4.3 Architecture Based on Code GenerationRuntime module generation is a very powerful

technique that allows new modules to be generatedat run time to enable the system to be adapted at runtime. Generation of new modules is a complexprocess. Code generation is a time taking processand also it is difficult to generate efficient codebased on the inputs fed from a remote HOST aboutthe changed situation. Huge repository has to bebuilt within the embedded system which is requiredfor generating the code

Figure 3 shows the architecture for Run-TimeModule Generation Technique. The details requiredfor code generation are transmitted from the HOSTand the same is maintained within the embeddedsystem. Two processes are to be included into thearchitecture one for maintaining Code generationrepository and the other for generating code. Thememory module will make available the addressspace required for storing the code that isgenerated. After creating the code, a task is createdalong with the event for which the task must bewaiting. The tasks that are related to Repositorybuilding, code generation and memory managementare invoked by the semantic evolution modulestriggering their related events.

4.4 Architecture Based on Moving Code fromHOST

Yet another important technique is to receive theTask code through a command received form theHOST and copy the code to the respective addressspaces and recognize the code separately identifiedwith the Real Time operating system. This kind ofmethod helps in dynamically creating new taskswithout the necessity of any code generation. Assuch code developed at the HOST is migrated to theES system.

Sensor System

Actuator System

A/D Conversion

D/A Conversion

InterruptService

Routines

Control Logic

MemoryManager

RTOS

CodeGenerator

SyntaxEvaluation

Communication System

RepositoryBuilder

SemanticEvolution

ESApplication

Tasks

Other TasksCreated

Figure 3 Semantic Evolution Based On Code Generation

Figure 4 shows the architecture for run rimecopying and reconfiguring of the Application code.The remote interface receives the new code ormodified code developed on the HOST as an inputto a command and the copy component copies thecode to the address space specified by thecommand. The location where the code must bewritten is obtained by the memory manager throughcalling the RTOS functions. The code may be sentfrom the HOST either for the purposes of creatingnew TASK in which case the code is copied and aTask is created under RTOS and the TASK is madeto wait for an event to be initiated from theSemantic Evolution Task.

Code also can be transmitted as data to theEmbedded system in respect of a TASK whichneeds to be updated. This code also can be copiedto the address location returned by the memorymanager. After copying the code another task canbe created under the operating system. But the mainissue is that the old task which is already scheduledand running must be deleted and the stateinformation of the old Task should be transferred.The state information gets automatically transferredto the new updated task as both share the sameglobal variables. If the code is modified the task iskilled and the task is created within the real timeoperating system if the task does not deal with anyof the control function. The priorities with whichthe code must be activated are set at the time ofcreating the task under the control of the operatingsystem.




321

4.5 Dynamic Task Updating

Sensor System

Actuator System

A/D Conversion

D/A Conversion

InterruptService

Routines

Control Logic

ESApplication

TasksNew tasks

CommunicationInterface

SyntaxEvolution

RTOS

SemanticEvolution

Copy Taskfor Update

Copy fornew task

UpdateTasks

Figure 4 Run Time Module Copy And ReconfigureArchitecture

The main issue is to determine the time at whichthe old task shall be deleted. If the tasks aremundane tasks, the deletion of the old task isstraight forward. If the Task to be deleted is a Taskthat undertakes an actuating / controlling function,then there should be a guarantee that the new taskwill do the actuating function exactly in the similarmanner as the old task or else addition of new taskand deletion of the existing task will make theentire system to get jeopardized. To avoid this acheck must be done by a different task and the taskwill have the logic which compares the output ofnew task with old task over a predefined period oftime. If the output is same over a period of time, theold task is deleted and the new task will take overthe new task using its output for handling thecontrol mechanism. If the output is not same, amessage is sent to the HOST and the new updateTask shall be deleted and the memory occupied byit will be released.

[Sha et. al, 2001] have proposed an architecturefor online update of real time embedded systemwhich is termed as simplex architecture. The Figure5 shows the simplex architecture for online updateof an ES Application.In this architecture all critical tasks are performed

by simple and verifiable components and the outputof new components (Complex Components) whichare counter parts to the simple verifiable

components is fed as input to the simplecomponents.

Sensor System

Actuator System

A/D Conversion

D/A Conversion

Interrupt ServiceRoutines

Simple reliableComponets

NewComponets

Decision Logic

Control Logic

Figure 5 Simplex Architecture For Online Updates

The new components may not have been testedfully. The input data is fed to the Micro Controllerby an A/D converter which communicates using aspecified communication protocol such as I2C. Aninterrupt service routine is activated to read the dataand place in a shared memory. The memory isaccessed by the simple reliable task and theComplex new task as soon as the data is placed inthe shared memory. The tasks shall be waiting forthe arrival of the data. The output generated by boththe tasks is fed to Decision logic. The architectureincludes a Decision and Logic Component that teststhe output from the complex component and alsochecks whether the system shall be in the recoveryregion once the output from the complex system isreleased to the rest of the system. The Decisionlogic components keep track of the recovery regionof the application in terms of the peripheral andmemory boundary values of various data elements,the timing requirements, the sequencingrequirements etc. The output from the complexcomponents shall be verified with safety criticalregion variable values. If the output produced bythe complex region is within the limits of the safetyof the systems, the output shall then be allowed tobe committed to the safety memory area of theapplication. If the output of complex componentsare not confirming to the safety region requirementsof the application then the output of the simplecomponent shall be considered and the output issubjected to the critical region.

The decision and logic system sufficiently checksthe upgrade of the simple components and on




322

ensuring the correctness and efficiency shallconfigure the new component as the simplecomponents. The architecture includes a runtimereconfiguration subsystem which shall have thefunctions to carry the switching between the testingmode and the normal operation mode and committhe upgrade of sufficiently tested software.

[Kihwal Lee, 2005] has extended the simplexArchitecture to carry online upgrading of theEmbedded Application and proposed eSimplexarchitecture. Lee proposed that the simplexcomponents and the Complex components beresident in different address space. Soft real timeprocesses and non-critical processes also run indifferent address space. The communicationbetween all the processes is achieved throughshared memory and communication wrapper wherenecessary. Figure 6 shows the interaction ofcomponents through shared memory to achieveonline upgrade of the system.

ESimplex uses the priority based scheduling ofthe processes and helps the isolation of processes inthe timing domain. The process level isolation isachieved through process level protection offeredby the operating system. The memory protectionand isolation is achieved through static compilerchecks. [Lee et. al., 2005] proposed code safetywithout runtime checks for control system throughusage of operating feature of Process protection.The replacing of the simplex code with Complexcomponents and restarting of the application isachieved through the concept called ProcessResurrection (PR). PR is a fast and efficientmechanism for restarting and replacing a process.PR mechanism is used to switch between theproduction mode and testing mode.

Sensor System

Actuator System

A/D Conversion

D/A Conversion

InterruptService

Routines

Simplereliable

Componets

NewComponets

DecisionLogic

ControlLogic

SharedMemory

RemoteControlInterfce

Figure 6 Online Upgrades Through Shared Memory

The new component image can replace thesimple component and the mode can be changedfrom Testing to Production. In the production modeonly the verified and tested components will bemade to run. The runtime sub system must be ableto reconfigure the code and switch between theproduction and testing in real time meaning theactivities related to reconfiguration and switchingmust be predictable and schedulable. Figure. 7illustrates the usage of the concept called processResurrection. Process resurrection is a featuresupported by most of the real time operatingsystems. The mode switch is achieved through theprocess Resurrection function which will map thenew code to the address space of the simple reliablecomponent address space and also setting thecontrol data a value realized by the control logic toindicate that a mode switch has been effected.

The system runs in the normal operation modewhen there is no need for testing or upgrade. In thismode only simple reliable functional modules shallbe running. The switching overhead is verynegligible and as such there is no CPU overheadand little extra storage is used to store the datarelated to changing the modes between productionsand testing & upgrading. When online testing ofnew software is needed the PR feature converts theregular processes into Esimplex enabled processesand the new software modules can be uploaded fortesting. When the new software is unproven and itsfeatures are needed then the system can be made torun at the cost of reduced response time of non-realtime and non-critical tasks. When the new modulesare believed to be running then the system isswitched to normal mode of operation through theProcess Resurrection.

The updating methods considering the criticalityof the tasks, simple tasks and complex tasksproposed by Lee, Sha and Kowshik are quitecomplicated and does not fit into the overallstructure of dynamic semantic evolution of theembedded system. The process of updating must beevent driven. Both the old process and the newprocess must be made to be running and the newtask will be made to continue to run while old taskwill be deleted when sufficient guarantee could beachieved that the new and updated task will meetall the criticality conditions. Figure 8 show the newarchitecture that deals with simple comparator thatruns under the control of a Real time operatingsystem. Both will share the same memory two setsof global variables which will mirror each other.Changeover of the tasks will only require swappingof the variable. When the changeover is undertaken




323

the original set of global variables will only be usedfor undertaking all the control actions

Operating System

StandaloneComplex

Component

Operating System

ComplexComponent

(under testing)

Switched by ProcessResurrection

Testing and UpgradeMode

Normal OperationMode

Figure 7 Process Resurrection For Mode Change Of TheEmbedded Systems

Copy task for update component will trigger anevent for which the compare task will be waiting.The compare Task will take the charge of makingthe tasks (old and the modified ) runsimultaneously each writing the output to the mirrorset of variables. The verification is undertaken aftercompletion of each cycle of execution of the oldTask. A task is considered to complete a cycle ofexecution when the task moves from Blocked stateto run sate and then to blocked state again.4.6 Comprehensive Architecture

All the methods discussed above help in semanticevolution of the Embedded Software in one way orthe other. The Application code changes when themethods modify the existing code or when newcode is created due to the reasons of environmentchanges and the reasons for adoptability. In the caseof mission critical and safety critical system theproduction system cannot be shut down for want ofmaking changes to the embedded system whichhelps in monitoring, and controlling of theembedded system. It is necessary that changes byway of modifications or additions must be done atthe runtime meaning that when the embeddedsystem is in ruining mode. The modified code andthe new code can be developed in the host machineand then have to be moved to the target machine inonline mode while the embedded system is inrunning mode.

Sensor System

Actuator System

A/D Conversion

D/A Conversion

InterruptService

Routines

Control Logic

ESApplication

TasksNew tasks


SyntaxEvolution

RTOS

SemanticEvolution

Copy Taskfor Update

Copy fornew task

UpdateTasks

CompareTasks

Figure 8 Architecture For Updating The Critical Tasks

The architectures presented above have merit ineach of them. It is necessary to consider all thearchitectures and provide a unified architecture andthe kind of dynamic evolution to be adapted shouldbe decided by the semantic evolution task. Thecomprehensive architecture that caters for all typesof dynamic evolutions of embedded systems isshown in the Figure 4.9. Dynamic semanticevolution of the embedded system thus can beachieved through Data Approach (Invoking anddeleting the existing Tasks as per the desiredfunctionality), Rule based Approach (Invoking thetask execution as per the rules for which arepository can be maintained), Module generationand invoking approach ( Generating new modulesbased on HOST sent specification), Module copyapproach (Creation of the new modules as per thecode sent from the remote HOST), Module updateapproach (Creation of update module and swappingthe old module with the Update module), Moduleupdate with attached criticality assessmentApproach (Create update modules and subject themodule for criticality assessment).

The overall architecture is efficient that itaccommodates any kind of evolution both simpleand complex evolution systems. It implements allkinds of approaches using which all possible typesof evolutions can be undertaken. The type ofevolution that must be taken up can be dictatedfrom the HOST through transmission of appropriatecommand. Semantic Evolution block canimplement the kind of semantic evolution thatneeds to be implemented as per the request initiatedfrom the HOST.




324

InterruptService

Routines

Control Logic

ESApplication

Tasks

Additionaltasks


SyntaxEvolution

RTOS

SemanticEvolution

CopyTask forUpdate

Copy fornew task

UpdateTasks

CompareTasks

MemoryManager

CodeGenerator

Repository Builder

Rulesmanager

A/DConversion

SensorSystem

D/AConversion

ActuatorSystem

InvokeTask

DeleteTask

Figure 4.9 Overall Semantic Evolution Architecture

5. COMPARATIVE ANALYSIS OFARCHITECTURAL MODEL

A comparison is made to show the coverage ofdynamic evolution by different architectureproposed by different authors. From the Table 5.1it could be seen that the comprehensive modelpresented by Sasi et. al., is most effective andextremely suitable for dynamic semantic evolutionwithin an embedded system which is interfacedwith a remote HOST.

6. CONCLUSIONS

Embedded systems that are used for monitoringand controlling safety or mission critical systemsmust be evolved dynamically for incorporating thechanges to the running systems as it is not possibleto shut down the ES system for want of makingchanges. Many architectural models have beenpresented in the literature and most of them are notquite suitable for implementing dynamic evolutionof embedded software and as such eacharchitectural model has been incorporated with justone method while many methods have been inexistence for dynamically evolving the embeddedsoftware. Few of the architectural models havebeen presented that have incorporated just onemethod for dynamically evolving the ES software.A comprehensive architectural model that supportsdifferent methods and runs under the ambit of anRTOS that includes all components that arerequired for dynamic semantic of the ES softwareis needed and the same is presented in this paper.

Further research needs to be conducted fordynamically semantic evolution of distributedembedded systems.

REFERENCES

[1]. Lui Sha, Ragunathan Rajkuman, andMichael Gagliardi, “Trans. SoftwareEngineering, CMU technical reportCMS/SEI-95-TR-005, 1995

[2]. Peyman Oreizy, “Issues in the RuntimeModification of software architecture,Technical report submitted to university ofCalifornia – Irvine, 1996

[3]. Huw Evans and Peter Dickman,``DRASTIC: A Run-Time Architecture forEvolving, Distributed, Persistent Systems”,Lecture Notes in Computer Science, vol.1241, pp. 243 – 249,1997

[4]. Peyman Oreizy, Nenad MedvidovicRichard, N. Taylor, “Architecture-BasedRuntime Software Evolution”, Proceedingsof the International Conference on SoftwareEngineering, 1998

[5]. E. Gamma, R. Helm, R. Johnson, J.Vlissides, “Design Patterns”, Addison-Wesley, 1995

[6]. D. Garlan, G. E. Kaiser, D. Notkin, “Usingtool abstraction to compose systems”, IEEEComputer, Vol. 25, Iss. 6, pp. 30-38, 1992

[7]. M. Gorlick, R. R. Razouk, “Using weavesfor software construction and analysisProceedings of 13th International conferenceon software engineering, 1991

[8]. D. E. Perry, A. L. Wolf, “Foundations for thestudy of software architecture”, SoftwareEngineering Notes, Vol. 17, Iss. 4, 1994

[9]. L. Sha, R. Raj Kumar, M. Gagliardi,“Evolving dependable real-time systems”,IEEE Aerospace Applications Conference,New York, pp. 335-446, 1996

[10]. M. Shaw, R. DeLine, D. V. Klien, T. L.Ross, D. M. Young, and G. Zelesnik,“Abstractions for software architecture andtools to support them”, IEEE Transactionson software engineering, pp. 314-336, 1995

[11]. Lawrence Chung, Nary Subramanian,“Architecture-Based Semantic Evolution: AStudy of Remotely Controlled EmbeddedSystems”, IEEE International Conference onsoftware Maintenance, 2001

[12]. Dominic Duggan, “Type-Based HotSwapping of Running Modules”, Intl. Conf.on Functional Programming, pp. 62-73,2001




325

[13]. Michael W. Hicks, Jonathan T. Moore, andScott Nettles. “Dynamic SoftwareUpdating”, In SIGPLAN Conf. onProgramming Language Design andImplementation, pp. 13-23, 2001

[14]. Narayanan (Nary) Subramanian andLawrence Chung, “Architecture - DrivenEmbedded Systems Adaption for supportingVocabulary Evolution, IEEE explorerreference 0-7695-0906-1/01 IEEE, 2001

[15]. J. R. Hauser and J. Wawrzynek, “Garp: AMIPS processor with a reconfigurable co-processor”, Proc. IEEE Symp. on Field-Programmable Custom ComputingMachines, pp. 12-21, 1998

[16]. Lee K and Sha L, “Process Resurrection: afast recovery mechanism for real-timeembedded systems, Proceedings of the 11thIEEE Real-Time and Embedded Technologyand Applications Symposium, 2005

[17]. L. Sha,, D. Seto, B. Krogh, L. Sha, and A.Chutinan, “The Simplex Architecture forSafe On-Line Control System Upgrades”,Proceedings of the American ControlConference, 1998

[18]. Kihwal Lee and Lui Sha, “A DependableOnline Testing and Upgrade Architecture forReal-Time Embedded Systems”,Proceedings of the 11th IEEE InternationalConference on Embedded and Real-TimeComputing Systems and Applications, 2005

[19]. Sasi J, Sastry KR Jammalamadaka,Rajasekhar Rao K, “Architectural models forsyntax evolution of safety critical embeddedsystems, International Journal of systemsand technologies, vol. 1, iss. 2 pp. 103-113.

[20]. M. Kaul, R. Vemuri, S. Govindarajan, and IQuaiss, “An automated temporal partitioningand loop fission approach for FPGA basedreconfigurable synthesis of DSPapplications”, Proc. Design AutomationConference, pp. 616-622, 1999




326

Table 5.1 Comparative Analysis Of Architectural Models Related To Dynamic Evolution

Ser

ial

Num

ber

Author Main themeCode

InvocationRule Based

Codegen

Copyfor

ADD

Copyfor

update

Copy forCriticality

update

1. Lui Sha Adding Independent Modules √2. Peyman Oreizy Online Update √3. Huw evans System Configuration √4. Peyman Oreizy Software Connectors √5. D. E. Perr System Connectors √6. M. Shaw System Connectors √7. D. E. Perr System Level Knowledge √8. M. Shaw System level Knowledge √9. Peyman Oreizy Theoretical evolution10. E. Gamma Mediators approach √11. D. Garlan Adding Components at run-time √12. Gilsi Hjalmtysson Addition of performance and optimization

methods into the new components√

13. M. M. Gorlick Run time reconfiguration √14. Lawrence Chung Run-Time module generation √15. Dominic Duggan Hot swapping √16. Michael Hicks General purpose dynamic update having many

features√

17. Narayanan Vocabulary Evolution18. J. R. Hause Configurable Hardware19. M. Kau Spatial Portioning √20. Lee, Sha and Kowshik Updating considering Criticality √21. Sasi Basic Evolution Architecture √22. Sasi Comprehensive Evolution √ √ √ √ √ √

1992-8645 an efficient architecture for … · an efficient architecture for semantic evolution of...

Documents