Embedded Databases for Embedded Real-Time Systems: A

EmbeddedDatabasesfor EmbeddedReal-TimeSystems:A Component-BasedApproach1

AleksandraTešanovic DagNyström

JörgenHansson ChristerNorström

LinköpingUniversity MälardalenUniversityDepartmentof ComputerScience Departmentof ComputerEngineering

Linköping,Sweden Västerås,Sweden{alete,jorha}@ida.liu.se {dag.nystrom,christer.norstrom}@mdh.se

January18,2002

1This work is supportedby ARTES,a network for real-timeandgraduateeducationin Sweden,andCENIIT.

Abstract

In thelastyearsthedeploymentof embeddedreal-timesystemshasincreaseddramatically.At thesametime, theamountof datathatneedsto bemanagedbyembeddedreal-timesys-temsis increasing, thus requiring an efficient and structured data management. Hence,databasefunctionalityis neededto providesupportfor storage andmanipulationof datain embeddedreal-timesystems.However, a databasethat can be usedin an embeddedreal-timesystemmustfulfill requirementsbothfroman embeddedsystemandfroma real-timesystem,i.e., at thesametimethedatabaseneedsto bean embeddedanda real-timedatabase. Thereal-timedatabasemusthandletransactionswith temporal constraints,aswell as maintainconsistencyas in a conventionaldatabase. Themain objectivesfor anembeddeddatabaseare low memoryusage, i.e., smallmemoryfootprint,portability to dif-ferentoperatingsystemplatforms,efficientresourcemanagement,e.g., minimizationof theCPU usage, ability to run for long periodsof timewithoutadministration, and ability tobe tailored for differentapplications.In addition,developmentcostsmustbekeptas lowas possible, with short time-to-market and a reliable software. In this report we surveyembeddedandreal-timedatabaseplatformsdevelopedin industrialandresearch environ-ments.This survey representsthe state-of-the-artin the area of embeddeddatabasesforembeddedreal-timesystems.Thesurvey enablesus to identifya gap betweenembeddedsystems,real-timesystemsand databasesystems,i.e., embeddeddatabasessuitableforreal-timesystemsare sparse. Furthermore, it is observedthat there is a needfor a moregenericembeddeddatabasethat can be tailored, such that the applicationdesignercangetan optimizeddatabasefor a specifictypeof an application.We considerintegrationofa modernsoftware engineeringtechnique, component-basedsoftware engineering, for de-velopingembeddeddatabasesfor embeddedreal-timesystems.Thismergeprovidesmeansfor building anembeddeddatabaseplatformthatcanbetailoredfor differentapplications,such that it hasa small memoryfootprint, minimumof functionality, and is highly inte-gratedwith theembeddedreal-timesystem.

Contents

1 Intr oduction 3

2 Databasesystems 92.1 Traditionaldatabasesystems . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Embeddeddatabasesystems . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 An industrialcasestudy . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 CommercialembeddedDBMS: asurvey . . . . . . . . . . . . . . . . . . . 112.3.1 Criteriainvestigated . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Databasesinvestigated . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 DBMS model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Datamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.5 Dataindexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.6 Memoryrequirements . . . . . . . . . . . . . . . . . . . . . . . . 172.3.7 Storagemedia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.8 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.9 Operatingsystemplatforms . . . . . . . . . . . . . . . . . . . . . 212.3.10 Concurrency control . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.11 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.12 Real-timeproperties . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4 Currentstate-of-the-artfrom researchpointof view . . . . . . . . . . . . . 262.4.1 Real-timeproperties . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.3 Transactionworkloadcharacteristics. . . . . . . . . . . . . . . . . 322.4.4 Activedatabases. . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 Component-basedsystems 403.1 Component-basedsoftwaredevelopment. . . . . . . . . . . . . . . . . . . 41

3.1.1 Softwarecomponent . . . . . . . . . . . . . . . . . . . . . . . . . 423.1.2 Softwarearchitecture. . . . . . . . . . . . . . . . . . . . . . . . . 433.1.3 Thefutureof CBSE:from thecomponentto thecomposition. . . . 44

3.2 Component-baseddatabasesystems . . . . . . . . . . . . . . . . . . . . . 463.2.1 Granularitylevel of a databasecomponent. . . . . . . . . . . . . . 463.2.2 Componentvs. monolithicDBMS . . . . . . . . . . . . . . . . . . 483.2.3 Componentsandarchitecturesin differentCDBMSmodels. . . . . 493.2.4 ExtensibleDBMS . . . . . . . . . . . . . . . . . . . . . . . . . . 493.2.5 Databasemiddleware . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.6 DBMS service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2.7 ConfigurableDBMS . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3 Component-basedembeddedandreal-timesystems. . . . . . . . . . . . . 603.3.1 Componentsandarchitecturesin embeddedreal-timesystems . . . 61

1

CONTENTS 2

3.3.2 Extensiblesystems. . . . . . . . . . . . . . . . . . . . . . . . . . 613.3.3 Middlewaresystems . . . . . . . . . . . . . . . . . . . . . . . . . 623.3.4 Configurablesystems. . . . . . . . . . . . . . . . . . . . . . . . . 63

3.4 A tabularoverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 Summary 754.1 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Chapter 1

Intr oduction

Digital systemscan be classified in two categories: general purposesystemsandapplication-specificsystems[41]. Generalpurposesystemscan be programmedto runavarietyof differentapplications,i.e., they arenotdesignedfor any specialapplication,asopposedto application-specificsystems.Application-specificsystemscanalsobepartofa largerhostsystemandperformspecificfunctionswithin thehostsystem[20], andsuchsystemsareusuallyreferredto asembeddedsystems. An embeddedsystemis implementedpartly on softwareandpartly on hardware. Whenstandardmicroprocessors,microcon-trollersor DSPprocessorsareused,specializationof anembeddedsystemfor a particularapplicationconsistsprimarily onspecializationof software.In thisreportwefocusonsuchsystems.An embeddedsystemis requiredto beoperationalduringthelifetime of thehostsystem,which mayrangefrom a few years,e.g.,a low endaudiocomponent,to decades,e.g.,an avionic system. The natureof embeddedsystemsalsorequiresthe computertointeractwith theexternalworld (environment).They needto monitorsensorsandcontrolactuatorsfor a widevarietyof real-world devices.Thesedevicesinterfaceto thecomputervia input andoutputregistersandtheir operationalrequirementsaredevice andcomputerdependent.

Most embeddedsystemsarealsoreal-timesystems,i.e., thecorrectnessof thesystemdependsboth on the logical resultof the computation,andthe time whenthe resultsareproduced[101]. We referto thesesystemsasembeddedreal-timesystems1. Real-timesys-temsaretypically constructedoutof concurrentprograms,calledtasks.Themostcommontypeof temporalconstraintthat a real-timesystemmustsatisfyis the completionof taskdeadlines.Dependingon theconsequencedueto a misseddeadline,real-timesystemscanbeclassifiedashardor soft. In a hard real-timesystemconsequencesof missinga dead-line canbe catastrophic,e.g.,aircraft control,while in a soft-real-timesystem, missingadeadlinedoesnot causecatastrophicdamageto the system,but may affect performancenegatively. Below follows a list of exampleswhereembeddedreal-timesystemscanbefound.

� Vehiclesystemsfor automobiles,subways,aircrafts,railways,andships.

� Traffic controlfor highways,airspace,railway tracks,andshippinglines.

� Processcontrolfor powerplantsandchemicalplants.

� Medicalsystemsfor radiationtherapy andpatientmonitoring.

� Military usessuchasadvancedfiring weapons,tracking,andcommandandcontrol.

� Manufacturingsystemswith robots.

1Wedistinguishbetweenembeddedandreal-timesystems,sincetherearesomeembeddedsystemsthatdonotenforcereal-timebehavior, andtherearereal-timesystemsthatarenotembedded.

3

CHAPTER1. INTRODUCTION 4

� Telephone,radio,andsatellitecommunications.

� Multimediasystemsthatprovidetext, graphic,audioandvideointerfaces.

� Householdsystemsfor monitoringandcontrollingappliances.

� Building managersthatcontrolsuchentitiesasheat,lights,doors,andelevators.

In thelastyearsthedeploymentof embeddedreal-timesystemshasincreaseddramat-ically. As canbe seenfrom the examples,thesesystemsarenow virtually embeddedinevery aspectof our lives. At thesametime theamountof datathatneedsto bemanagedis growing, e.g.,embeddedreal-timesystemsthatareusedto controla vehicle,suchasamoderncar, mustkeeptrackof severalhundredssensorvalues.As theamountof informa-tion managedby embeddedreal-timesystemsincreases,it becomesincreasinglyimportantthatdatais managedandstoredefficiently andin auniformmannerby thesystem.Currenttechniquesadoptedfor storingandmanipulatingdataobjectsin embeddedandreal-timesystemsare ad hoc, sincethey normally manipulatedataobjectsas internal datastruc-tures. That is, in embeddedreal-timesystemsdatamanagementis traditionallybuilt asapart of the overall system. This is a costly developmentprocesswith respectto design,implementation,andverificationof the system.In addition,suchtechniquesdo not pro-vide mechanismsthatsupportportingof datato otherembeddedsystemsor largecentraldatabases.

Databasefunctionality is neededto provide supportfor storageandmanipulationofdata.Embeddingdatabasesinto embeddedsystemshave significantgains:(i) reductionofdevelopmentcostsdueto thereuseof databasesystems;(ii) improvementof quality in thedesignof embeddedsystemssincethe databaseprovidessupportfor consistentandsafemanipulationof data,whichmakesthetaskof theprogrammersimpler;and(iv) increasedmaintainabilityasthesoftwareevolves.Consequently, this improvestheoverall reliabilityof thesystem.Furthermore,embeddeddatabasesprovidemechanismsthatsupportportingof datato otherembeddedsystemsor largecentraldatabases.

However, embeddedreal-timesystemsput demandson suchembeddeddatabasethatoriginatefrom requirementsonembeddedandreal-timesystems.

Mostembeddedsystemsneedto beableto runwithout humanpresence,which meansthata databasein sucha systemmustbeableto recover from the failurewithout externalintervention[80]. Also, the resourceload thedatabaseimposeson theembeddedsystemshouldbecarefullybalanced,in particular, memoryfootprint. For example,in embeddedsystemsusedto control a vehicleminimizationof the hardwarecost is of utmostimpor-tance. This usually implies that memorycapacitymustbe kept as low aspossible,i.e.,databasesusedin suchsystemsmusthavesmallmemoryfootprint. Embeddedsystemscanbeimplementedin differenthardwareenvironmentssupportingdifferentoperatingsystemplatforms,which requirestheembeddeddatabaseto beportableto differentoperatingsys-templatforms.

Ontheotherhand,real-timesystemsputdifferentsetof demandsonadatabasesystem.Thedatain thedatabaseusedin real-timesystemsmustbelogically consistent,aswell astemporallyconsistent[50]. Temporalconsistency of datais neededin orderto maintainconsistency betweentheactualstateof theenvironmentthatis beingcontrolledby thereal-time system,andthestatereflectedby thecontentof thedatabase.Temporalconsistencyhastwo components:

� Absoluteconsistency, betweenthestateof theenvironmentandits reflectionin thedatabase.

� Relativeconsistency, amongthedatausedto deriveotherdata.

Weusethenotationintroducedby Ramamritham[50] to giveaformaldefinitionof tempo-ral consistency.


PID Task

AlarmTask

UserInterface

r

A/D

A/D

D/ADBMS

a' x'

y'

r'

I/

O

MGNT

(p,i,d)

Level Alarm a

Level indicator x

Valve y

Figure1.1: An examplesystem.On theleft sidea watertank is controlledby thesystemon the right side. ThePID-taskcontrolstheflow out by the valve (y) so that the level intank(x) is thesameasthelevel setby theuser(r). An alarmtaskshutsthesystemdown ifthelevel alarm(a) is activated.

A dataelement,denoted�, which is temporallyconstrained,is definedby threeat-

tributes:

� value��

, i.e., thecurrentstateof data�

in thedatabase,

� time-stamp��

, i.e., thetimewhentheobservationrelatingto�

wasmade,and

� absolutevalidity interval� ��

, i.e.,thelengthof thetimeinterval following� ��

duringwhich

�is consideredto beabsoluteconsistent.

A setof dataitemsusedto derive a new dataitem forms a relative consistency set,de-noted � , andeachsuchsetis associatedwith a relativevalidity interval, �� . Datain thedatabase,suchthat

�� , hasacorrectstateif andonly if [50]

1.� ��

is logically consistent,and

2.�

is temporallyconsistent,both

� absolute�� , and� relative ! ��"#� �%$& � �� "�� & � �'� �� .A transaction,i.e., a sequenceof readand write operationson data items, in conven-tional databasesmustsatisfy following properties:atomicity, consistency, isolation,anddurability, calledACID properties. In addition, transactionsthat processreal-timedatamust satisfy temporalconstraints. Someof the temporalconstraintson transactionsina real-timedatabasecomefrom the temporalconsistency requirement,and somefromrequirementsimposedon the systemreactiontime (typically, periodicity requirements)[50]. Theseconstraintsrequiretime-cognizanttransactionprocessingsothat transactionscanbeprocessedto meettheirdeadlines,bothwith respectto completionof thetransactionaswell assatisfyingthetemporalcorrectnessof thedata.


Level Alarm a

Level indicator x

Valve y

SystemEvent occuring at time t1

Shutdown occuring at time t1

Figure1.2: Theend-to-enddeadlineconstraintfor thealarmsystem.Theemergency shut-down mustbecompletedwithin a giventime

��( �� *) implying that �,+'�-��. � ��( �� /) .

An exampleapplication

We describeoneexampleof a typical embeddedreal-timesystem.Theexampleis typicalfor a largeclassindustrialprocesscontrolsystemthathandleslargevolumeof data,wheredatahavetemporalconstraints.In orderto keeptheexampleasillustrativeandassimpleaspossiblewe limit our exampleto a specificapplicationscenario,namelythecontrolof thewaterlevel in awatertank(seefigure1.1).Throughthisexampleweillustratedemandsputondatamanagementin suchasystem.Ourexample-systemcontainsa real-timeoperatingsystem,a database,anI/O managementsubsystemanda user-interface.

A controllertask(PID-regulator)controlsthe level in thewatertankaccordingto thedesiredlevel setby theuser, i.e., thehighestallowedwaterlevel. Theenvironmentconsistsof thewaterlevel, thealarmstate,thesettingof thevalveandthevalueof theuserinterface.Theenvironmentstateis reflectedby the contentof thedatabase(denoted0 " $/1 " $*2 " $*3 " infigure 1.1). Furthermore,PID variablesthat reflect internalstatusof the systemarealsostoredin the database.The I/O manager(I/O MGNT) is responsiblefor dataexchangebetweentheenvironmentandthedatabase.Thus,thedatabasestorestheparametersfromthe environmentand to the environment,and configurationdata. Data in the databaseneedsto betemporallyconsistent,bothabsoluteandrelative. In thiscase,absolutevalidityinterval candependonthewaterflow. Thatis, if thethetankin figure1.1is verybig andtheflow is small,absolutevalidity interval canbegreaterthanin thecasewherethewater-flowis big andthedataneedsto besampledmorefrequently. Therelative consistency depictsthedifferencebetweentheoldestdatasampleandtheyoungestsampleof data.Hence,ifthealarmin oursystemis activated,dueto highwaterlevel, andx’ indicatesa lower level,thesetwo valuesarenotvalid eventhoughthey haveabsolutevalidity.

For thisapplicationscenario,anadditionaltemporalconstraintmustbesatisfiedby thedatabase,andthatis anend-to-enddeadline.This temporalconstraintis importantbecausethe maximumprocessingtime for the alarmevent mustbe smallerthanthe end-to-end-deadline. Figure1.2 shows the whole end-to-endprocessfor an alarmevent. Whenanalarmis detected,analarmsensorsendsthesignalto theA/D converter. Thissignalis readby theI/O managerrecordingthealarmin thedatabase.Thealarmtaskthenanalyzesthealarmdataandsendsasignalbackto indicateanemergency shutdown.

In our example,thedatabasecanbeaccessedby thealarmtask,thePID task,theuserinterface,andtheI/O manager. Thus,anadequateconcurrency controlmustbeensuredinorderto serializetransactionscomingfrom thesefour differentdatabaseclients.

Let us now assumethat the water level in the tank is just below the highestallowedlevel, i.e., the level whenan alarmis triggered. The waterflowing into the tank createsrippleson the surface. Theseripplescould causethe alarmto go on andoff with everyripple touchingthe sensor, andconsequentlysendingburstsof alarmsto the system. Inthiscase,onemoretemporalconstraintmustbesatisfied,adelayedresponse.Thedelayed


responseis a periodof time within which thewaterlevel mustbehigherthanthehighestallowedlevel in orderto activatethealarm.

As we can see,this simple applicationscenarioputs different requirementson thedatabase.A completeindustrial processcontrol system,of which this exampleis partof, wouldputa varietyof additionalrequirementsonadatabase,e.g.,logging.

Note that requirementsplacedon the databaseby the embeddedreal-time systemare to someextent generalfor all embeddedandreal-timeapplications,but at the sametime, therearerequirementsthat arespecificto an applicationin question(e.g.,delayedresponse).Thus,anembeddeddatabasesystemmust,in a sense,betailored(customized)for eachdifferentapplicationto give an optimizedsolution. That is, given the resourcedemandsof theembeddedreal-timesystem,a databasemustbetailoredto have minimumfunctionality, i.e.,only functionalitythata specificapplicationneeds.

In recentyears,a significantamountof researchhasfocusedon how to incorporatedatabasefunctionality into real-timesystemswithout jeopardizingtimeliness,andhow toincorporatereal-timebehavior into embeddedsystems.However, researchfor embeddeddatabasesusedin embeddedreal-timesystems,explicitly addressingthedevelopmentanddesignprocess,andthelimited amountof resourcesin embeddedsystemsis sparse.Hence,thegoalof our reportis to identify thegapbetweenthefollowing threedifferentsystems:real-timesystems,embeddedsystems,anddatabasesystems.Further, we investigatehowcomponent-basedsoftwareengineeringwouldprovideafeasibleapproachfor bridgingthisgapby enablingdevelopmentof acustomizableembeddeddatabasesuitablefor embeddedreal-timesystems,in a short time with reduceddevelopmentcosts,and high quality ofsoftware.

Therearemany embeddeddatabasesonthemarket,but, asweshow in this report,theyvary widely form vendorto vendor. Existing commercialembeddeddatabasesystems,e.g.,Polyhedra[91], RDM andVelocis[70], Pervasive.SQL[88], Berkeley DB [99], andTimesTen[109], have differentcharacteristicsandaredesignedwith specificapplicationsin mind. They supportdifferent datamodels,e.g., relationalvs object-orientedmodel,andoperatingsystemplatforms.Moreover, they have differentmemoryrequirementsandprovidedifferenttypesof interfacesfor usersto accessdatain thedatabase.

Application developersmust carefully choosethe embeddeddatabasetheir applica-tion requires,andfind thebalancebetweenthefunctionalityanapplicationrequiresandthefunctionalitythatanembeddeddatabaseoffers.Thus,findingtheright embeddeddatabase,in additionof beinga quitetime consuming,costlyanddifficult process,is a processwithlot of compromises.Althougha significantamountof researchin real-timedatabaseshasbeendonein the pastyears,it hasmainly focussedon variousschemesfor concurrencycontrol,transactionscheduling,andloggingandrecovery. Researchprojectsthatarebuild-ing real-timedatabaseplatforms,suchasART-RTDB [52], BeeHive [103], DeeDS[9] andRODAIN [61], mainly addressreal-timeperformance,have monolithicstructure,andarebuilt for a particularreal-timeapplication.Hence,theissueof how to enabledevelopmentof anembeddeddatabasesystemthatcanbetailoredfor differentembeddedreal-timeap-plicationsarises.Thedevelopmentcostsof suchdatabasesystemmustbekeptlow, andthedevelopmentmustensuregoodsoftwarequality. Weshow thatexploitingcomponent-basedsoftwareengineeringin thedatabasedevelopmentseemto have a potential,andexaminehow component-basedsoftwareengineeringcanenabledatabasesystemsto beeasilytai-lored, i.e., optimized,for a particularapplication.By having well-definedreusablecom-ponentsasbuilding blocks,notonly developmentcostsarereduced,but moreimportantly,costsrelatedtoverificationandcertificationarereducedsincecomponentswill onlyneedtobecheckedonce.AlthoughsomemajordatabasevendorssuchasOracle,Informix, Sybase,andMicrosofthaverecognizedthatcomponent-baseddevelopmentofferssignificantbene-fits, theircomponent-basedsolutionsarelimited in termsof tailorabilitywith, in mostcases,inadequatesupportfor developmentof suchcomponent-baseddatabasesystems.Further-more,commercialcomponent-baseddatabasesdo not enforcereal-timebehavior andare


not,in mostcases,suitablefor environmentswith limited resources.Wearguethatin orderto composea reliableembeddedreal-timesystemoutof components,componentbehaviormustbepredictable.Thus,componentsmusthave well definedtemporalattributes.How-ever, existing component-baseddatabasesystemsdo not enforcereal-timebehavior. Also,issuesrelatedto embeddedsystemssuchaslow-resourceconsumptionarenot addressedat all in thesesolutions.We show that real-timepropertiesarepreservedonly in a few oftheexisting component-basedreal-timesystems.In additionto temporalproperties,com-ponentsin component-basedembeddedsystemsmusthave explicitly addressedmemoryneedsandpower consumptionrequirements.At the endof this report,we outline initialideasfor preservingreal-timeandembeddedpropertiesin componentsusedfor building anembeddeddatabaseplatformthatcanbetailoredfor differentapplications.

The report is organizedas follows. In chapter2 we survey commercialembeddedandresearchreal-timedatabasesystems.We thenexaminethecomponent-basedsoftwareengineeringparadigm,andits integrationwith databasesfor embeddedreal-timesystemsinchapter3. In chapter4 wediscussapossiblescenariofor developinganembeddeddatabaseplatformthatcanbetailoredfor differentapplications,andgiveconclusions.

Chapter 2

Databasesystems

2.1 Traditional databasesystems

Databasesareusedto storedataitemsin a structuredway. Dataitemsstoredin a databaseshouldbepersistent,i.e.,adataitemstoredin thedatabaseshouldremainthereuntil eitherremovedor updated.Transactionsaremostoftenusedto read,write, or updatedataitems.Transactionsshouldguaranteeserialization.The so-calleddatabasemanageris accessedthroughinterfaces,andonedatabasemanagercansupportmultiple interfaceslike C/C++,SQL,or ActiveX interfaces.

Mostdatabasemanagementsystemsconsistof threelevels[27]:

� Theinternallevel, or physicallevel, dealswith thephysicalstorageof thedataontoamedia.Its interfaceto theconceptuallevel abstractsall suchinformationaway.

� The conceptuallevel handlestransactionsand structuresof the data,maintainingserializationandpersistence.

� Theexternallevel containsinterfacesto users,uniforming transactionsbeforetheyaresentto theconceptuallevel.

Oneof themaingoalsfor many traditionaldatabasesystemsaretransactionthrough-put andlow averageresponsetime [50], while for real-timedatabasesthemaingoal is toachievepredictabilitywith respectto responsetimes,memoryusage,andCPUutilization.We cansaythatwhena worst caseresponsetime or maximummemoryconsumptionfora databasecanbe guaranteed,thesystemis predictable.However, therecanbe differentlevelsof predictability. For a systemthatcanguaranteea certainresponsetimewith somedefinedconfidence,is saidto havea certaindegreeof predictability.

2.2 Embeddeddatabasesystems

2.2.1 Definitions

A deviceembeddeddatabasesystemis a databasesystemthatresidesin anembeddedsys-tem. In contrast,an application-embeddeddatabaseis hiddeninsidean applicationandis not visible to the applicationuser. Application-embeddeddatabasesarenot addressedfurther in this survey. This survey focusesonly on databasesembeddedin real-timeandembeddedsystems.Themainobjectivesof a traditionalenterprisedatabasesystemoftenis throughput,flexibility , scalability, functionalityetc.,while size,resourceusage,andpro-cessorusagearenotasimportant,sincehardwareis relatively cheap.In embeddedsystemstheseissuesaremuchmoreimportant.Themainissuesfor anembeddeddatabasesystemcanbesummarizedas[96, 80, 94]:

9

CHAPTER2. DATABASESYSTEMS 10

� Minimization of thememoryfootprint: Thememorydemandfor anembeddedsys-temaremostoften,mainlyfor economicalreasons,keptaslow aspossible.A typicalfootprint for anembeddeddatabaseis within therangeof somekilobytesto acoupleof megabytes.

� Reductionof resourceallocations:In anembeddedsystem,thedatabasemanagementsystemandtheapplicationaremostoftenrunon thesameprocessor, puttinga greatdemandon the databaseprocessto allocateminimum CPU bandwidthto leave asmuchcapacityaspossibleto theapplication.

� Supportfor multipleoperatingsystems:In anenterprisedatabasesystem,theDBMSis typically run on a dedicatedserver usinga normaloperatingsystem.Theclients,thatcouldbedesktopcomputers,otherservers,or evenembeddedsystems,connectto theserver usinga network connection.Becausea databasemostoftenrun on thesamepieceof hardwareastheapplicationin anembeddedsystem,andthatembeddedsystemsoftenusespecializedoperatingsystems,thedatabasesystemmustsupporttheseoperatingsystems.

� High availability: In contrastto a traditional databasesystem,most embeddeddatabasesystemsdonothaveasystemadministratorpresentduringrun-time.There-fore,anembeddeddatabasemustbeableto runon its own.

Dependingon thekind of systemthedatabaseshouldresidein, someadditionalobjec-tivesmight bemoreemphasized,while othersarelessimportant.For example,Pervasive,which manufacturesPervasive.SQLDBMS system,hasidentifiedthreedifferenttypesofembeddedsystemsandhasthereforedevelopeddifferentversionsof theirdatabaseto sup-port thesesystems[89]:

� Pervasive.SQLfor smartcardsis intendedfor systemswith very limited memoryresources,typically atenkilobytes.Thisversionhastradedoff sophisticatedconcur-rency controlandflexible interfacesfor size. Typical applicationsincludebankingsystemslike cash-cards,identificationsystems,health-care,andmobilephones.

� Pervasive.SQLfor embeddedsystemsis designedfor smallcontrolsystemslike ourexamplesystemin figure 1.1. It canalsobe usedasa datapump,which is a sys-tem that readsdatafrom a numberof sensors,storesthe datain a local database,andcontinuously“pumps” datato a large enterprisedatabasein an unidirectionalflow. Importantissuesherearepredictability, with respectto bothtiming andsystemresources,aswe areapproachinga real-timeenvironment. The interfacesarekeptrathersimpleto increasespeedandpredictability. Sincethe numberof usersandtherateof transactionsoftencanbepredicted,theneedfor a complex concurrencycontrolsystemmightnotbenecessary.

� Pervasive.SQLfor mobilesystemsis usedin mobiledeviceslike cellularphonesorPDAs, wherethereis a needfor higherdegreeof concurrency control. Considerthat a userbrowsesthroughe-mailson a PDA while walking into his/hersoffice,thenthesynchronizerupdatesthee-maillist usingawirelesscommunicationwithoutinterruptingtheuser. The interfacessupportmorecomplex ad-hocqueriesthantheembeddedversion. The interfacesaremodularandcanbe includedor excludedtominimizememoryfootprint.

2.2.2 An industrial casestudy

In 1999,ABB Roboticswho developsandmanufacturesrobotsfor industrialuse,wantedto exchangethe existing in-housedevelopedconfigurationstoragemanagementsystem


into amoreflexible andgenericsystem,preferablysomecommercial-of-the-shelf(COTS)embeddeddatabase.

An industrial robot is a complex andcomputer-controlledsystem,which consistsofmany sub-systems.In eachrobot someconfigurationinformationaboutits equipmentisstored.Today, this amountsto about600kilobytesof data.Thisdataneedsto bestoredina structuredandorganizedway, allowing easyaccess.

Thecurrentsystem,calledCFG,is a custom-madeapplicationandresemblesin manyways to a regular databaseapplication. However, it is nowadaysconsideredto be tooinflexible and the user-interfaceis not user friendly enough. Furthermore,the internalstructuresandthechoiceof index systemhave leadto muchlongerresponsetimesastheamountof datahasincreased.

ABB Roboticsdecidedto investigatethemarket for anexisting suitabledatabasesys-tem that would fulfill their demands.The following requirementswereconsideredto beimportant[63]:

� Connectivity. It shouldbe possibleto accessthe databaseboth directly from therobotcontrollingapplicationandfrom anexternalapplicationvia anetwork connec-tion. Furthermorethedatabaseshouldsupportviewssodatacouldbequeriedfroma certainperspective. It would bepreferableif somekind of standardinterface,e.g.,ODBC,couldbeused.If possible,thedatabaseshouldbebackwardcompatiblewiththe querylanguageusedin the CFG system. The databaseshouldalsobe abletohandlesimultaneoustransactionsandqueries,andbeableto handleconcurrency.

� Scalability. Theamountof dataitemsin thesystemmustbeallowedto grow asthesystemevolves. Transactiontimesanddatabasebehavior mustnot changeduetoincreasein datasize.

� Security. It shouldbepossibleto assigndifferentsecuritylevelsfor differentpartsofthedatain thedatabase.Thatis, someform of useridentificationandsomesecuritylevelsmustexist.

� Datapersistence.Thedatabaseshouldbeableto recover safelyaftera systemfail-ure. Thereforesomeform of persistentstoragemustbesupported,andthedatabaseshouldremaininternallyconsistentafterrecovery.

� Memoryrequirements.To keepthesizeof theDBMS systemlow is a key issue.

2.3 Commercial embeddedDBMS: a survey

In this sectionwe discussandcomparea numberof commercialembeddeddatabasesys-tems.Wehaveselectedahandfulof systemswith differentcharacteristics.Thesedatabasesarecomparedwith eachotherwith respectto asetof criteria,whichrepresentthemostfun-damentalissuesrelatedto embeddeddatabases.

2.3.1 Criteria investigated� DBMS model,whichdescribesthearchitectureof thedatabasesystem.Two DBMS

architecturesfor embeddeddatabasesaretheclient/server modelandtheembeddedlibrary model.

� Datamodel,whichspecifieshow datain thedatabaseis organized.Commonmodelsaretherelational,theobject-orientedandtheobjectrelational.

� Dataindexing, whichdescribeshow thedataindexesareconstructed.


� Memory requirements,which describesthe memoryrequirementsfor the system,bothdataoverheadandthememoryfootprint,which is thesizeof thedatabaseman-agementsystem.

� Storagemedia,whichspecifiesthedifferentkindsof storagemediasthatthedatabasesupports.

� Connectivity, which describesthedifferentinterfacestheapplicationcanuseto ac-cessthe database.Network connectivity is alsospecified,i.e. the ability to accessthedatabaseremotelyvia a network connection.

� Operatingsystemplatforms,whichspecifiestheoperatingsystemssupportedby thedatabasesystem.

� Concurrency control, which describeshow concurrenttransactionsarehandledbythesystem.

� Recovery, whichspecifieshow backup/restorationis managedby asystemin caseoffailures.

� Real-timeproperties,whichdiscussesdifferentreal-timeaspectsof thesystem.

2.3.2 Databasesinvestigated

In this survey we have selecteda handfulof systemsthat togetherrepresentsa somewhatcompletepictureof thetypesof productscurrentlyon themarket.

� Pervasive.SQLby PervasiveSoftwareInc. Thisdatabasehasthreedifferentversionsfor embeddedsystems:Pervasive.SQLfor smart-card,Pervasive.SQLfor mobilesystems,andPervasive.SQLfor embeddedsystems.All threeversionsintegratewellwith eachotherandalsowith their nonembeddedversionsof Pervasive.SQL.Theirsystemview andthefactthatthey have,comparedto mostembeddeddatabases,verysmallmemoryrequirementswasonereasonfor investigatingthisdatabase[88].

� Polyhedraby PolyhedraPlc. Thisdatabasewasselectedfor threereasons,first of allit is claimedto bea real-timedatabase,secondlyit is a mainmemorydatabase,andthird, it supportsactivebehavior [91].

� Velocisby MbraneLtd. Thissystemis primarily intendedfor e-CommerceandWebapplications,but hassomesupportfor embeddedoperatingsystems[70].

� RDM by MbraneLtd. Like Polyhedra,RDM alsoclaimsto bea real-timedatabase.It is however fundamentallydifferentfrom the Polyhedrasystem,by, for example,beinganembeddedlibrary and,thus,doesnotadopttheclient/servermodel[70].

� Berkeley DB by SleepycatSoftwareInc. This database,which alsois implementedasa library, wasselectedfor thesurvey becauseit is distributedasopensourceandthereforeinterestingfrom a researchpointof view [99].

� TimesTenby TimesTenPerformanceSoftware. This relationaldatabaseis, like thePolyhedrasystema mainmemoryreal-timedatabasesystem[109].

2.3.3 DBMS model

Therearebasicallytwo differentDBMS modelssupported(seetable2.1). Thefirst modelis theclient/servermodel,wherethedatabaseservercanbeconsideredto beanapplicationrunningseparatelyfromthereal-timeapplication,eventhoughthey runonthesameproces-sor. TheDBMS is calledusinga request/responseprotocol. Theserver is accessedeither


DBMS system Client/server LibraryPervasive.SQL xPolyhedra xVelocis xRDM xBerkeley DB xTimesTen x

Table2.1: DBMS modelssupportedby differentembeddeddatabasesystems.

throughinter-processcommunicationor somenetwork. The secondmodelis to compiletheDBMS togetherwith thesystemapplicationinto oneexecutablesystem.Whena taskwantsto accessthedatabaseit only performsfunctioncallsto make therequest.Transac-tionsexecuteon behalfof their tasks’threads,eventhoughinternalthreadsin theDBMSmight be used. Thereareadvantagesanddrawbackswith both models. In a traditionalenterprisedatabase,theserver mostoftenrun on a dedicatedservermachine,allowing theDBMS to usealmost100%of theCPU.However in anembeddedclient/serversystem,theapplicationandthe server processoften sharethe sameprocessor. This implies that forevery transactionat leasttwo context switchesmustbe performed,seefigure 2.1. Morecomplex transactions,likeanupdatetransactionmight requireevenmorecontext switches.Considerfor examplea real-timetaskthat executesan updatetransactionthat first readsthedataelement1 , thenderivesa new valueof 1 from theold valueandfinally writes itbackto the database.This transactionwould generatefour context switches.Two whilefetchingthevalueof 1 andtwo while writing 1 backto thedatabase.

Thesecontext switchesaddsto thesystemoverhead,andcanfurthermoremake worstcaseexecutiontime estimationsof transactionsmore complex to predict. The networkmessagepassingor inter-processcommunicationbetweentheserverandtheclientalsoaddto theoverheadcost.A drawbackwith anembeddedlibrary is that they lack standardizedinterfaceslikeODBC[80].

Theproblemwith messagepassingoverheadhasbeenreducedin theVelocissystem.They allow the processto be compiledtogetherwith the application,thus reducingtheoverheadsincesharedmemorycanbeusedinstead.

Application taskDBMS server

taskApplication task

continued

DBMSrequest

DBMSresponse

Contextswitches

Figure2.1: In anembeddedclient/serverDBMS atleasttwo context switchesarenecessaryfor eachtransaction.

2.3.4 Data model

The datamodelconcernshow datais logically structured.The mostcommonmodel istherelationalmodelwheredatais organizedin tableswith columnsandrows. Databasesimplementingrelationaldatamodelarereferredto asrelationaldatabases(RDBMS).Oneadvantagewith a relationalmodelis thatcolumnsin thetablecanrelateto othertablessoarbitrarycomplex logical structurescanbecreated.Fromthis logical structurequeriescanbeusedto extracta specificselectionof data,i.e. a view. However, onedisadvantagewiththerelationalmodelis addeddatalookupoverhead.This is becausethatdataelementsare


DBMS system Relational Object-oriented Object-relational OtherPervasive.SQL xPolyhedra x (x)Velocis xRDM xBerkeley DB xTimesTen x

Table2.2: Datamodelssupportedby differentembeddeddatabasesystems.

organizedwith indexesin which pointersto the datais stored,andto performthe indexlookupcantake significantamountof time,especiallyfor databasesstoredonharddrives.This canbe a seriousproblemfor databasesthat residesin time critical applicationslikeourexampleapplicationin figure1.1.

The relationalmodel,which wasdevelopedby Codd,only supportsa few basicdatatypes,e.g., integers,floating point numbers,currency, and fixed length arrays. This isnowadaysconsidereda limitation which hasleadto the introductionof databaseswhichsupportsmorecomplex datatypes,e.g.,Binary Large Objects(BLOBs). BLOB is data,which is treatedas a set of binary digits. The databasedoesnot know what a BLOBcontainsandthereforecannotindex anything insideof theBLOB.

The object-orienteddatabase(ODMBS) is a different kind of datamodel, which ishighly integratedwith object-orientedmodelingandprogramming,TheODBMSis anex-tensionto thesemanticsof anobject-orientedlanguage.An object-orienteddatabasestoresobjectsthatcanbesharedby differentapplications.For example,a company which dealswith e-Commercehasadatabasecontainingall customers.Theapplicationis written in anobject-orientedlanguageanda customeris modeledasan object. This objecthasmeth-ods,likebuy andchangeAdress, associatedwith it. Whena new customerarrives,aninstanceof the classis createdandthenstoredin thedatabase.The instancecanthenberetrievedatany time. Controlledaccessis guaranteeddueto concurrency control.

A third datamodel,whichhasevolvedfrom boththerelationalandtheobject-orientedmodel, incorporatesobjectsin relations,thus is called object-relationaldatabases(OR-DBMS).

As shown in table2.2,all systemsin thesurvey exceptBerkeley DB arerelational.Fur-thermorethe Polyhedrahassomeobject-relationalbehavior throughits control languagedescribedbelow. However it is not fully object-relationalsinceobjectsitself cannotbestoredin the database.To our knowledge,no pure object-orientedembeddeddatabaseexistson themarket today. Therearehowever somelow requirementsdatabasesthatareobject-oriented,suchastheObjectivity/DB [79] system.Furthermoresomeobject-orientedclient-librariesexist thatcanbeusedin anembeddedsystem,suchasthePowerTier [87]and the PoetObject system[90]. Theseclient-librariesconnectto an externaldatabaseserver. SincetheactualDBMS andthedatabaseis locatedon a non-embeddedsystemwedonotconsiderthemembeddeddatabasesin thissurvey.

Mostsystemshavewaysto “shortcut”accessto data,andthereforebypassingtheindexlookup routine. Pervasive, for example,can accessdatausing the Btrieve transactionalenginethatbypassestherelationalengine.Mbraneusesa differentapproachin theRDMsystem.In many real-timesystemsdataitemsareaccessedin a predefinedorder(think ofa controllingsystemwheresomesensorvaluesarereadfrom thedatabaseandtheresultiswrittenbackto thedatabase).By insertingshortcutsbetweendataelementssuchthattheyaredirectly linkedin theorderthey areaccessed,fastaccessescanbeachieved. As theseshortcutspoint directly to physicallocationsin memory, reorganizationof thedatabaseismuchmorecomplex sincea largenumberof pointerscanbecomestalewhena singledatais droppedor moved.


6

3 4 9

Key1

Key2

Key3

Key4

Key6

Key7

Key9

DATA BLOCKS

Figure2.2: Thestructureof a B 4 -treewith fanoutof 3. Theinnernodesareonly usedtoindex down to the leave nodecontainingthe pointerto the correctdata. Figurepartiallyfrom [58].

The PolyhedraDBMS systemis fundamentallydifferentcomparedto the restof therelationalsystemsin this survey, becauseof its active behavior. This is achievedthroughtwo mechanisms,active queriesandby thecontrol language(CL). An active querylooksquitelikeanormalquerywheresomedatais retrievedand/orwritten,but insteadthequerystaysin thedatabaseuntil explicitly aborted.Whena changein thedataoccursthatwouldalter the resultof the query, the applicationis notified. The CL, which is a fully object-orientedscript languagethat supportsencapsulation,informationhiding andinheritance,candeterminethe behavior of datain the database.This meansthat methods,privateorpublic, canbeassociatedwith dataperformingoperationson themwithout involving theapplication.In our exampleapplication,theCL couldbeusedto derive thevalve setting2 " from thelevel indicator 1 " andthePID parameters,thusremoving theneedfor thePIDtask. The CL hasanotherimportantusage,sinceit canbe usedin the displaymanager(DM) to makeagraphicalinterface.TheDM, whichis implementedasaPolyhedraClient,togetherwith thecontrollanguageis ableto presenta graphicalview on a local or remoteuserterminal.This is actuallyexactly theuserinterfacein our exampleapplication,sinceDM alsocantakeuserinputandforwardthatto thedatabase.Activedatabasemanagementwill befurtherdiscussedin section2.4.4.

As mentionedabove, Berkeley DB is the only non-relationalsystemin this survey.Insteadit usesa key-datarelationship.Onedatais associatedwith a key. Therearethreewaysto searchfor data,from key, partof key or sequentialsearch.Thedatacanbearbitrarylarge andof virtually any structure. Sincethe keys areplain ASCII stringsthe datacancontainotherkeys so complex relationscanbe built up. In fact it would be possibletoimplementa relationalengineon top of theBerkeley DB database.This approachclaimsfor a very intimaterelationshipbetweenthedatabaseandtheprogramminglanguageusedin theapplication.

2.3.5 Data indexing

To beableto efficiently searchfor specificdata,anefficient index systemshouldexist. Tolinearlysearchthrougheverysinglekey from anunsortedlist wouldnotbeagoodsolutionsincetransactionresponsetimeswouldgrow asthenumberof dataelementsin thedatabaseincreases.To solvethisproblemtwo majorapproachesareused,treestructuresandhashedlists. Both approachessupplysimilar functionality, but differ somewhat in performance.Two major treestructuresareused,B 4 -tree indexing, which suitsdisk baseddatabases,andT-treeindexing,which is primarily usedin main-memorydatabases.

Themainissuefor B 4 -treeindexing is to minimizedisk I/O, thustradingdisk I/O foraddedalgorithmcomplexity. B 4 -treeindexing sortsthekeys in a treestructurein whichevery nodehasa predefinednumberof children,denoted5 . A largevalueof 5 resultsina wide but shallow tree,thusthetreehasa largefanout.A small valueof 5 resultsin the


Figure2.3: Thestructureof a T-tree.Eachnodecontainsa numberof entriesthatcontainsthekey andapointerto thecorrespondingdata.All key valuesthatarelessthenthebound-aryof thisnodeis directedto theleft child, andkey valuesthatareabovetheboundaryaredirectedto theright. Figurefrom TimesTenWhitepaper.

opposite.For 5768+ treeis abinarytree.Sinceall dataindexesresidein theleavenodesofthe tree,while only the innernodesareusedto navigateto theright leave, thenumberofvisitednodeswill be fewer for a shallow tree. This resultsin fewer nodesthathave to beretrievedfrom disk,thusreducingdiskI/O. In figure2.3.5weseeanexampleof aB 4 -tree.Therootdirectsrequeststo all keys thatarelessthansix to theleft child andkeysfrom sixto its middlechild. As thevalueof 5 increases,thelongertime it takesto passtherequestto the correctchild. Thus,whendecidingthe fanoutdegree,the time it takesto fetch anodefrom disk mustbe in proportionto thetime it takesto locatewhich child to redirectto. Proposalsonreal-timeconcurrency controlfor B 4 -treeindexing havebeenmade[58].

DBMS system B 4 -tr ee T-tr ee Hashing OtherPervasive.SQL xPolyhedra xVelocis n/a n/a n/a n/aRDM xBerkeley DB x x xTimesTen x x x

Table2.3: Dataindexing strategiesusedby differentembeddeddatabasesystems.

For main-memorydatabasesa differenttype of treecanbe used,the T-treestructure[60]. TheT-treeusesa deepertreestructurethantheB 4 -treesinceit is a balancedbinarytree,seefigure2.3.5,with amaximumof two childrenfor everynode.To locatedata,morenodesarenormally visited, comparedto the B 4 -tree , beforethe correctnodeis found.This is notaproblemfor amain-memorydatabasesincememoryI/O is significantlyfasterthandisk I/O. Theprimaryissuefor T-treeindexing is thatthealgorithmsusedto traversea T-treehave a lower complexity andfasterexecutiontime thancorrespondingalgorithms


for the B-tree. However, it hasbeenpointedout that a T-tree traversalcombinedwithconcurrency control might performworsethanB-tree indexesdue to the fact that morenodesin theT-treehadto belockedto ensuretreeintegrity duringtraversal[65] . They alsoproposedan improvementcalledT-tail, which reducesthenumberof costly re-balancingoperationsneeded.Furthermore,they proposedtwo concurrency algorithmsfor T-tail andT-treestructures,oneoptimisticandonepessimistic(for a moredetaileddiscussionaboutpessimisticandoptimisticconcurrency control,seesection2.3.10).

Thesecondapproach,hashing,usesanhashlist in which keys areinsertedaccordingto a valuederivedfrom thekey itself (differentkeys canbeassignedthesamevalue)[62].Therefore,eachentry in the list is a bucket that cancontaina predefinednumberof datakeys. If abucket is full a rehashoperationmustbeperformed.Theadvantagewith hashingis that the time to searchfor certaindatais constantindependentof the amountof dataentriesin thedatabase.However, hashingoftencausemoredisk I/O thanB-trees.This isbecausedatais oftenusedwith locality of reference,i.e., if dataelement

�:9is used,it is

moreprobablethatdataelement��;

will beusedshortly. In a B-treebothelementswouldbesortedcloseto eachother, andwhen

�:9is retrieved from disk, thenit is probablethat

also��;

will be retrieved. However in a hashlist�<9

and��;

are likely to be in differentbuckets,causingextra disk I/O if bothdataareused.Anotherdisadvantagewith hashingcomparedto tree-basedindexing is thatnon-exactqueriesis time consumingto perform.For example,considera queryfor all keys greaterthan 1 . After that 1 hasbeenfound,allkeys arefound to theright of 1 in a B 4 -tree. For a hashedindex, all bucketsneedto besearchedto find all matchingkeys.

Wecannoticethatmain-memorydatabases,namelyPolyhedraandTimesTenusehash-ing (seetable2.3).Additionally, TimesTensupportsT-trees.Pervasive,RDM andBerkeleyDB useB-treeindexing.

It is alsonoteworthy that Berkeley DB usesboth B 4 -treeand hashing. They claimthathashingis suitablefor databaseschemesthatareeithersosmallthattheindex fits intomainmemoryor whenthe databaseis so large thatB 4 -treeindexing will causedisk I/Ouponmostnodefetchingdueto that the cachecanonly fit a small fractionof the nodes.Thusmakingthe B 4 -treeindexing suitablefor databaseschemeswith a sizein betweentheseextremes.Furthermore,Berkeley DB supportsa third accessmethod,queue,whichis usedfor fastinsertsin thetail, andfastretrieval of datafrom theheadof thequeue.Thisapproachis suitablefor thelargeclassof systemsthatconsumelargevolumesof data,e.g.,statemachines.

2.3.6 Memory requirements

Memoryrequirementof thedatabaseis animportantissuefor embeddeddatabasesresidingin environmentswith smallmemoryrequirements.Formass-producedembeddedcomputersystemslike computernodesin a car, minimizing hardwareis usuallya significantfactorfor reducingdevelopmentcosts.Therearetwo interestingpropertiesto considerfor em-beddeddatabases,first of all thememoryfootprint size,which is thesizeof thedatabasewithout any dataelementsin it. Second,dataoverheadis of interest,i.e., the numberofbytesrequiredto storea dataelementapartfrom the sizeof the dataelementitself. Anentry in the index list with a pointerto the physicalstorageaddressis typical dataover-head. Typically client/server solutionsseemsto requiresignificantlymorememorythanembeddedlibraries,with Pervasive.SQLbeingtheexception(seetable2.4).Thisexceptioncouldpartially beexplainedby Pervasive’sBtrieve native interfacebeinga very low-levelinterface(seesection2.3.8),andthatmuchof thefunctionalityis placedin theapplicationinstead. In the caseof Berkeley DB, thereis a similar explanationto its small memoryfootprint. Additional functionality (not provided by the vendor)canbe implementedontopof thedatabase.

1Thevaluesgivenin thetablearethe“footprint”-valuesmadeavailableby databasevendors.


DBMS system Memory requirements1

Pervasive.SQLfor smartcards 8kbPervasive.SQLfor embeddedsystems 50kbPervasive.SQLfor mobilesystems 50 - 400kbPolyhedra 1.5- 2MbVelocis 4MbRDM 400- 500kbBerkeley DB 175kbTimesTen 5Mb

Table2.4: Differentmemoryneedsof investigatedembeddeddatabasesystems.

DBMS system Hard-dri ve Flash Smart card FTPPervasive.SQL x x xPolyhedra x x xVelocis xRDM xBerkeley DB x xTimesTen x

Table2.5: Storagemediasusedby investigatedembeddeddatabasesystems.

Regardingdataoverhead,Polyhedrahasa dataoverheadof 28 bytesfor every record.Pervasive’s dataoverheadis not aseasilycalculatedsinceit usespaging. Dependingonrecordand pagesizesdifferentamountof fragmentationis introducedin the datafiles.Therearehowever formulasprovidedby Pervasive for calculatingexactrecordsizes.Theothersystemsinvestigatedin thissurvey suppliesnoinformationaboutactualdataoverheadcosts.

For systemswherelow memoryusageis consideredmoreimportantthanprocessingspeed,thereis an option of compressingthe data. Datawill thenbe transparentlycom-pressedanddecompressedduringruntime. This,however, requiresfreeworking memoryof 16 timesthesizeof therecordbeingcompressed/decompressed.

2.3.7 Storagemedia

Embeddedcomputersystemssupportdifferentstoragemedias.Normally, datausedon thecomputeris storedon a hard-drive. Hand-heldcomputeruseFlashor othernon-volatilememoryfor storageof bothprogramsanddata.Sincedatain adatabaseneedsto bepersis-tentevenupona power loss,someform of stablestoragetechniquemustbeused.As canbeseenfrom table2.5,mostsystemssupportFlashin additionto a hard-drive. ThePoly-hedrasystemalsosupportsstoragevia a FTP-connection.This impliesthatthePolyhedrasystemcanrun without persistentstorage,sincedatacanbe loadedvia FTP-connectionuponsystemstartup.

2.3.8 Connectivity

Databaseinterfacesaretheusers’way to accessthedatabase.An interfacenormallycon-tainsfunctionsfor connectingto theserver, makingqueries,performingtransactions,andmakingchangesto thedatabaseschema.However differentinterfacescanbespecializedon specifictypesof operations,e.g.,SQL is usedmainly for schemamodificationsandqueries,while a C/C++ API normallyarespecializedfor transactionalaccess.Figure2.4


Database server

Client

ODBCdriver

SQL-client

OLE/DBdriver

ActiveX(ADO)

JDBCdriver

OLE/DBappl.

VB appl.Javaappl.

ODBCappl.

NativeAPI

Nativeappl.

Figure 2.4: Figure showing the architectureof applicationsthat usesdifferent typesofdatabaseinterfaces.Theshadedboxesarecomponentsthatnormallyareprovidedby thedatabasevendor.

showsa typical interfaceconfigurationfor anembeddeddatabasesystem.Themostbasicinterfaceis thenative interface.This interface,which is for a specific

programminglanguage,e.g.,C or C++, is often usedby the applicationrunningon theembeddedsystem.In ourexamplein figure1.1,tasksandI/O managementwouldtypicallyusethenative interfaceto performtheir transactions.

MicrosofthasdevelopedtheOpenDatabaseConnectivity (ODBC) interfacein thelate80’s. This interfaceusesthequerylanguageSQL,andis todayoneof thelargeststandardsof databaseinterfaces.Theadvantagewith ODBCis thatany databasethatsupportsODBCcanconnectwith any applicationwritten for ODBC. ODBC is a low-level interface,thatrequiresmoreimplementationperdatabaseaccessthena high-level interfacelike ActiveXDataObject(ADO) interface,explainedbelow in moredetail.TheODBCinterfacecannothandlenon-relationaldatabasesvery well. Main benefits,besidetheinterchangeability, isthat theperformanceis generallyhigherthanhigh-level interfaces,andtheinterfacegivesthepossibilityof detailedtuning.

A newerstandard,alsodevelopedby Microsoft,is theOLE DB interfacewhichis basedon theMicrosoft COM technology(for moredetaileddescriptionof OLE DB’s function-ality seesection3.2.5). OLE DB is, asODBC,a low-level interface.ThefunctionalityofOLE DB is similar to ODBC,but object-oriented.However, oneadvantageis thepossibil-ity to useOLE DB on non-relationaldatabasesystems.Therearealsodriversavailabletoconnectthe OLE DB interfaceon top of anODBC driver. In this casethe ODBC driverwouldactasa server for theapplicationbut asa client to theDBMS.

On top of OLE DB, thehigh-level ADO interfacecouldbeused.SincebothOLE DBandADO arebasedonMicrosoftCOM,they canbereachedfromalmostany programminglanguage.

For Javaapplications,theJDBCinterfacecanbeused.It buildsonODBCbut hasbeendevelopedwith the samephilosophyastheOLE DB andADO interfaces.For databasesthat do not directly supportJDBC, an ODBC driver can be usedas intermediatelayer,just like OLE DB. Pervasive.SQLusestheBtrieve interfacefor fastreadingandupdatingtransactions.Btrieve is very closelyconnectedto thephysicalstorageof data. In Btrievedatais written asrecords.A recordcanbedescribedasa predefinedsetof dataelements,similartoastructin theC programminglanguage.Btrieveis notawareof thedataelements


DBMS system C/C++ ODBC OLE DB ADO JDBC Java OtherPervasive.SQL x x x x Btrieve

RSIPolyhedra x x x x xVelocis x x x PerlRDM xBerkeley DB x x x TCL

PerlTimesTen x

Table2.6: Interfacessupportedby differentembeddeddatabasesystems.

DBMS system Network connectivityPervasive.SQL xPolyhedra xVelocis xRDM xBerkeley DBTimesTen x

Table2.7: Network connectivity in investigatedembeddeddatabasesystems.

in therecord,but treatsdataelementsasstringof bytesthatcanberetrievedor stored.Anindex key is attachedto every record.Recordscanthenbeaccessedin two ways,physicalor logical. Whenarecordis locatedlogically, anindex containingall keysis usedto lookupthelocationof thedata.Theindexesaresortedin eitherascendingor descendingorderin aB-tree. Somemethodsto accessdata,exceptby keyword,areget first, get last,get greater than, etc. However for very fastaccess,the physicalmethodcanbeused.Thenthedatais retrievedusinga physicallocation. This techniqueis usefulwhendatais accessedin apredefinedorder, thiscanbecomparedto thepointernetwork usedbyRDM discussedpreviously. Physicalaccessis performedusingfour basicmethods,stepfirst, step last, step next, andstep previous.

Onelimitation with theBtrieve interfaceis thatit is not relational.Pervasivehasthere-foreintroducedtheirRowSetinterface(RSI)thatcombinessomefunctionalityfromBtrieveandsomefrom SQL. Every recordis a row andthe dataelementsin the recordscanbeconsideredcolumnsin the relation. This interfaceis availablefor thesmartcardversion,embeddedversion,andmobileversion,but it is not availablefor non-embeddedversionsof Pervasive.SQL.

TheBtrieve andRSI interfacesarequitedifferentfrom thenative interfacein Polyhe-dra, which doesnot requirethe sameunderstandingof the physicaldatastructure. ThePolyhedraC/C++ interfaceusesSQL, thusoperatingon a higher level. Basically, threedifferentwaysto accessthedatabaseareprovidedin theinterface:queries,activequeries,andtransactions.A queryperformsaretrievalof datafrom thedatabaseimmediately, usingtheSQLselect command,andthequeryis thereafterdeleted.An activequeryworksthesameway asanordinaryquerybut will not bedeletedafter theresulthasbeendelivered,but will be reactivatedassoonasany of the involveddatais changed.This will continueuntil theactive queryis explicitly deleted.Oneproblemwith active queriesis that if datachangesveryfast,thenumberof activationsof thequerycanbesubstantial,thusriskingtooverloadthesystem.To preventthis a minimuminter-arrival time canbeset,andthusthequerycannotbereactivateduntil thetimespecifiedhaselapsed.Froma real-timeperspec-tive, theactivationcouldthenbetreatedasa periodicevent,addingto thepredictabilityof


thesystem.Using transactionsis the only way to make updatesto the database,queriesareonly

for retrieval of data. A transactioncanconsistof a mixture of active updatequeriesanddirectSQLstatements.Notethata querymightupdatethedatabaseif it is placedinsideofa transaction.Active updatequeriesinsertor updatea singledataelementandalsodeleteon singlerow. Transactionsare,asalways,treatedasatomicoperationsandareabortedupondataconflict. To further speedup transactionexecutiontime, SQL procedurescanbeused,bothin queriesandtransactions.Theseproceduresarecompiledonceandcannotbechangedafter that,only executed.This eliminatesthecompilationprocessandis veryusefulfor queriesthatrunoften.However, proceduresdonotallow schemachanges.

Noteworthyis thatTimesTenonly supportsODBCandJDBC,andit hasnonativeinter-facelike therestof thesystems.To increasethespeedof ODBCconnections,anoptimizedODBC driver is developedthat connectsonly to TimesTen. Like the PolyhedraDBMS,TimesTenusesprecompiledqueries,but in additionsupportsparameterizedqueries.A pa-rameterizedqueryis aprecompiledquerythatsupportsargumentspassedto it. For exampletheparameterizedquery

query( X )SELECT * from X

would returnthetablespecifiedby X.The Berkeley DB, asmentionedearlier, is not a client/server solution,but is imple-

mentedasan embeddedlibrary. It is, furthermore,not relationalbut uses,similar to theBtrieve interface,a key thatrelatesto a record.Thesimilaritiesto Btrieve go furtherthanthat;datacanbeaccessedin two ways,by key or by physicallocation,justasBtrieve. Themethodsget() andput() accessdataby thekey, while cursormethodscanbeusedtogetdataby physicallocationin thedatabase.As in Btrieve,thefirst, last,next, current,andpreviousrecordnumbercanberetrieved. A cursoris simply a pointerthatpointsdirectlyto a record.Thefunctionalityandmethodnamesaresimilar to eachotherindependentofwhichof thesupportedprogramminglanguagethatis used.Therearethreedifferentmodesthatthedatabasecanrun in:

� SingleuserDB. This versiononly allows oneuserto accessthedatabaseat a time,thus,removing theneedfor concurrency controlandtransactionsupport.

� ConcurrentDB. Thisversionallowsmultipleusersto accessthedatabasesimultane-ously, but doesnot supporttransactions.This databaseis suitablefor systemsthathasvery few updatesbut multiple read-onlytransactions.

� Transactionaldatabase.Thisversionallowsbothconcurrentusersandtransactions.

The RDM database,which is implementedasa library, hasa C/C++ interfaceas itsonly interface. This library is, in contrastto Berkeley DB, relational. The interfaceis alow-level interfacethatdoesnotcomplywith any of theinterfacestandards.As mentionedearlier, oneproblemwith databasesthat doesnot usethe client/server model is the lackof standardinterfaces. However, sinceRDM is relational,a separateSQL-like interfacedbqueryis developed.It is a supersetof thestandardlibrary, which makesuseof a subsetof SQL.

2.3.9 Operating systemplatforms

Differentembeddedsystemsmight run on variousoperatingsystemsdueto differencesinthe hardwareenvironment. Also the natureof the applicationdetermineswhat operatingsystemsmight be mostuseful. Thus,mostembeddeddatabasesmustbe able to run ondifferentoperatingsystemplatforms.


DBMS system DesktopOSWindows UNIX Linux OS/2 DOS

Pervasive.SQLfor smartcardsPervasive.SQLfor embeddedsystemsPervasive.SQLfor mobilesystems xPolyhedra x x xVelocis x x xRDM x x x x xBerkeley DB x x xTimesTen x x x

Table2.8: Desktopoperatingsystemssupportedby investigatedembeddeddatabasesys-tems.

DBMS system Real-Time OS Hand-heldOS SmartcardOS

VxW

orks

OS

E

pSO

S

Lynx

OS

QN

X

Pha

r-la

p

Win

CE

Palm

OS

Java

Car

d

Mul

tO

S

Win

0

Pervasive.SQL1 x x xPervasive.SQL2 x x xPervasive.SQL3 x xPolyhedra x x x xVelocisRDM x xBerkeley DB xTimesTen x x

Table2.9: Real-timeandembeddedoperatingsystemssupportedby investigatedembeddeddatabasesystems.

Tables2.8 and2.9 give an overview of differentoperatingsystemssupportedby em-beddeddatabasesweinvestigated.Therearebasicallyfour categoriesof operatingsystemsthatinvestigatedembeddeddatabasessupport:

� Operatingsystemstraditionallyusedby desktopcomputers.In thiscategoryyoufindthemostcommonoperatingsystemslike,Microsoft Windows,differentversionsofUNIX andLinux.

� Operatingsystemsfor hand-heldcomputers.In this category you find Palm OSandWindows CE/PocketPC.Theseoperatingsystemsdemandsmall memoryrequire-mentsbut still havemostof thefunctionalityof theordinarydesktopcomputeroper-atingsystems.A goodinteractionandinteroperabilitybetweentheoperatingsystemson thehand-heldcomputeranda standarddesktopis alsoimportant.This is recog-nizedby all databases,if you considerthe completePervasive.SQLfamily asonedatabasesystem.

� Real-timeoperatingsystems.In this category you find systemslike VxWorks andQNX.

� Smartcardoperatingsystems.Thesesystems,like JavaCardandMultOS,aremadefor very smallenvironments,typically no morethan32kb. TheJava Cardoperating

0Smartcardoperatingsystemfor Windows.1Pervasive.SQLfor smartcards.2Pervasive.SQLfor embeddedsystems.3Pervasive.SQLfor mobilesystems.


systemis simplyanextendedJava virtual machine.

Most commercialembeddeddatabasesystemsin this survey supporta real-timeoper-atingsystem(seetable2.9). Additionally, Pervasive.SQLsupportsoperatingsystemsforhand-heldcomputersandsmartcardoperatingsystems,in thePervasive.SQLfor mobilesystemsversionandthePervasive.SQLfor smartcardversion,respectively.

2.3.10 Concurrencycontrol

Concurrency control(CC)serializestransactions,retainingtheACID properties. All trans-actionsin a databasesystemmustfulfill all four ACID properties.Theseare:

� Atomicity: A transactionis indivisible,eitherit is run to completionor it is not runatall.

� Consistentency: It mustnot violate logical constraintsenforcedby thesystem.Forexample,a bank transactionmust follow the law of conservation of money. Thismeansthat after a money transfer, the sumof the receiver andthe sendermustbeunchanged.

� Isolation: A transactionmust not interferewith any other concurrenttransaction.This is alsoreferredto asserializationof transactions.

� Durability: A transactionis, oncecommitted,writtenpermanentlyto thedatabase.

If two transactionshave somedataelementsin commonand areactive at the sametime, a dataconflict might occur. Thenit is up to the concurrency control to detectandresolve this conflict. This is mostcommonlydonewith someform of locking mechanism.It substitutesthe semaphoreguardinga global datain a real-timesystem.Therearetwofundamentallydifferentapproachesonachieving thisserialization,anoptimisticandapes-simisticapproach.

The mostcommonpessimisticalgorithmis two-phase-locking(2PL) algorithmpro-posedin 1976by Eswaranet al. [34]. This algorithmconsists,asthenameindicates,oftwo phases.In thefirst phaseall locksarecollected,no readingor writing to datacanbeperformedbeforea lock hasbeenobtained.Whenall locksarecollectedandtheupdateshavebeendone,thelocksarereleasedin thesecondphase.

Optimisticconcurrency control(OCC)wasfirst proposedby KungandRobinson[57]in 1981. This strategy takesadvantageof the fact thatconflictsin generalareratherrare.Thebasicideais to readandupdatedatawithout regardingpossibleconflicts.All updatesare,however, doneon temporarydata. At commit-timea conflict detectionis performedandthedatais written permanentlyto thedatabaseif no conflict wasdetected.Howevertheconflictdetection(verificationphase)andtheupdatephaseneedto beatomic,implyingsomeform of locking mechanism.Sincethesetwo phasestake muchshortertime thanawhole transaction,locks that involvesmultiple data,or the whole database,canbe used.Sinceit is an optimistic approach,performancedegradeswhencongestionin the systemincreases.

For real-timedatabasesa numberof variantsof thesealgorithmshave beenproposedthatsuit thesedatabasesbetter[114, 10]. Thesealgorithmstry to find a goodbalancebe-tweenmisseddeadlinesandtemporallyinconsistenttransactions.SongandLiu showedthat OCC algorithmsperformedpoorly with respectto temporalconsistency in real-timesystemsthat consistof periodicactivities [100], while they performedvery well in sys-temswheretransactionshadrandomparameters,e.g.,event-drivensystems.However, ithasbeenshown that thestrategiesandtheimplementationof the locking andabortional-gorithmssignificantlydeterminetheperformanceof OCC[46]. All databasesexceptthePolyhedraDBMS usepessimisticCC (seetable2.10). SincePolyhedrais anevent-driven


DBMS system PessimisticCC Optimistic CC No CCPervasive.SQL xPolyhedra xVelocis xRDM xBerkeley DB x xTimesTen x

Table2.10:Concurrency controlstrategiesusedin differentembeddeddatabasesystems.

system,OCCis a naturalchoice.Furthermore,Polyhedrais a main-memorydatabasewithvery fastexecutionof queries,therisk of a conflict is thusreduced.

Pervasive.SQLhastwo kind of transactions:exclusive andconcurrent.An exclusivetransactionlocksacompletedatabasefile for theentiredurationof thetransaction,allowingonly concurrentnon-transactionalclients to performread-onlyoperationson the file. Aconcurrenttransaction,however, usesreadand write locks with muchfiner granularity,e.g.,pageor singledatalocks.

TheBerkeley DB hasthreeconfigurations:(i) Thenon-concurrentconfigurationallowsonly onethreadatatimetoaccessthedatabase,removing theneedfor concurrency control.(ii) Theconcurrentversionallows concurrentreadersandconcurrentwritersto accessthedatabasesimultaneously. (iii) The concurrenttransactionalversionallows for full trans-actionalfunctionality with concurrency control, suchasfine grain locking anddatabaseatomicity.

Similar to Berkeley DB, TimesTenalsohasa “no concurrency” option,in which onlya singleprocesscanaccessthedatabase.In addition,TimesTensupportstwo lock sizes:data-storelevel andrecordlevel locking.

2.3.11 Recovery

Oneimportantissuefor databasesis persistence,i.e., datawritten andcommittedto thedatabaseshouldremainuntil it is overwrittenor explicitly removed,evenif thesystemfailsandhave to berestarted.Furthermore,thestateof all ongoingtransactionsmustbesavedto be ableto restorethe databaseto a consistentstateuponrecovery, sinceuncommitteddatamighthavebeenwrittento thedatabase.Thereis basicallytwo differentstrategiesforbackuprestoration:roll-backrecovery, androll-forwardrecovery,normallycalled“forwarderrorrecovery”. Duringoperationcontinuousbackuppointsoccurswhereaconsistentstateof thedatabaseis storedon a non-volatile media,like a hard-drive. Thesebackuppointsarecalledcheckpoints.

In roll-backrecovery you simply restartthedatabaseusingthe latestcheckpoint,thusguaranteeinga consistentdatabasestate.Theadvantagewith this approachis that it doesnot requirea lot of overhead,but thedisadvantageis thatall changesmadeto thedatabaseafterthecheckpointarelost.

Whenroll-forwardrecoveryis used,checkpointsarestoredregularly, but all intermedi-ateevents,likewrites,commitsandabortsarewrittento alog. In roll-forwardrecovery, thedatabaseis restoredto thelastcheckpoint,andall log entriesareperformedin thesameor-derasthey havebeenenteredinto thelog. Whenthedatabasehasbeenrestoredto thestateit wasat the time of the failure,uncommittedtransactionsareroll-backed. This approachrequiresmorecalculationsat recovery-time,but will restorethedatabaseto thestateit wasin beforethe failure. Pervasive.SQLoffers threedifferenttypesof recovery mechanisms,aswell asthe option to ignorerecovery (seetable2.11). This canalsobe selectedpartsof the database.Ignoring check-pointingfor somedatacanbe usefulfor systemswheresomedatamustbepersistentwhile otherdatacanbevolatile. Goingbackto our example


DBMS system Roll-forward Roll-back Journalling No recoveryPervasive.SQL x xPolyhedra x xVelocis xRDM xBerkeley DB xTimesTen x x

Table2.11:Strategiesfor recoveryusedin differentembeddeddatabasesystems.

in section1.1, the desiredlevel givenby the userinterface,andthe regulatorparametersneedto bepersistent,while thecurrentreadingfrom thelevel indicatormustnot,sincebythe time the databaseis recoveredthe datawill probablybe stale. The secondoption isshadow-paging,which simply makesa copy of the databasefile andmakesthe changesthere,andwhenthetransactionis complete,thedatais writtenbackto theoriginalpage.Asimilarapproachis thedelta-paging,whichcreatesanemptypagefor eachtransaction,andonly writes thechanges(delta-values)to it. At theendof a transactionthedatais writtenbackto theoriginal,justasfor shadow-paging.With bothof thesetechniques,thedatabaseis consistentatall times.Thelastoptionis to useloggingandroll-forwardrecovery.

The default configurationfor Polyhedrais non-journalling,which meansthat no au-tomatic backupis performed,but the applicationis responsiblefor saving the databaseto non-volatile memory. This is particularlyimportantsincethis systemis a mainmem-ory database,andif no backupsis taken all datais, of course,lost. Whenjournalling isused,theusercanselectwhich tablesthatshouldbepersistentandthejournallerwill writean entry in the log whena transactioninvolving persistentdatais committed. Therearetwo approacheswhendatais persistentlywritten,directjournallingandnon-blockingjour-nalling. Thedirectjournallingapproachwritesdatato persistentstoragewhentheloadontheDBMS is low. However, thedatabaseis blockedduringthisprocessandthiscancauseproblemsfor systemswith time-criticaldata.Thesecondapproachcanthenbeused,andthatis to usea separatejournallingprocessresponsiblefor writing entriespersistent.

TimesTensupportsthreedifferentlevelsof recoverycontrol. Themoststringentguar-anteestransactionatomicityanddurability uponrecovery, in which casethetransactionisnotcommitteduntil thetransactionis writtenontodisk. Thesecondlevelof controlguaran-teestransactionatomicitybut notdurability. Uponcommit,thelog entryis put into aqueueandis laterwritten to disk. Uponrecovery thedatabasewill beconsistent,but committedtransactionsthat have not yet beenwritten to disk might be lost. The lowestlevel of re-coverycontrolis no recoverycontrol.Neitheratomicitynordurability is guaranteed.Thisoptionmightnotbeasinappropriateasit might seemata first glance,sinceTimesTenis amain-memorydatabase,oftenusedin systemswith datathatwouldbestaleuponrecovery,e.g.,a processcontroller.

2.3.12 Real-timeproperties

Eventhoughnoneof thecommercialdatabasesystemsin this survey canbeclassifiedasa real-timedatabasefrom a hardreal-timesystemsperspective, mostof the systemsaresuccessfullyusedin time-criticalsystems(to differentextent). EricssonusesPolyhedraintheir 3G platformfor wirelesscommunication.DelcanCorporationusesVelocisDB in atraffic controlsystemthathandlesabout1200traffic lightssimultaneouslyeventhoughthisdatabaseprimarily is usedin webande-Commerceapplications.Thedatabasesystemsaresimply so fastandefficient andhave so many optionsfor fine tuning their performancethat the applicationsystemswork, even thoughthe DB systemscannotitself guaranteepredictability.


A questiononecouldaskis: How wouldweuseoneof thesesystemsin ahardreal-timesystem?Are thereany waysto minimizetheunpredictabilityto sucha degreethata pes-simisticestimationwould fulfill hardreal-timerequirements?In our opinion it is. For aneventtriggeredreal-timesystem,Polyhedrawouldfit well. Let ususeourexampleapplica-tion again.Whennew sensorvaluesarrivetheI/O management,thedatabaseis updated.Ifthereis a changein thealarmdatatheCL codethat is connectedto thatdatais generatinganevent to trigger thealarmtask. Built into thesystemis alsotheminimuminter-arrivalinterval mentionedin the interfacessection. So by usingthe Polyhedradatabaseto acti-vatetasks,thatwill thenbescheduledby a priority basedreal-timeoperatingsystem,anacceptabledegreeof predictabilityis achieved. To furtherincreaseguaranteesthatcriticaldatawill beupdatedis to usea socalledwatchdog,thatactivatesa taskif it hasnot beenactivatedfor a predefinedtime. Thememoryandsizepredictabilitywould beno problemsincethey have specifiedtheexactmemoryoverheadfor every typeof object. However,temporalvalidity is notaddressedwith thisapproach.

For staticallyscheduledreal-timesystemstheRDM “Network access”couldbeabletorun with predictableresponsetimes.This becausetheorderof thedataaccessesis knowna priori andcan thereforebe linked togetherin a chain,and the recordlookup index isbypassed.

2.4 Curr ent state-of-the-art fr om research point of view

Thereexists a numberof databasesthat could be classifiedaspurereal-timedatabases.However thesedatabasesareresearchprojectandarenot yet on the commercialmarket.We haveselecteda numberof real-timedatabasesystemsandcomparedthemwith respectto thefollowing criteria:

� Real-timeproperties.Thecriteriaenablesusto discussreal-timeaspectsof thesys-temsandhow they areimplemented.

� Distribution. Thecriteriaenablesusto elaborateaboutdifferentaspectswith respectto distributing thedatabase.

� Transactionsworkload characteristics.The criteria enablesus to discusshow thetransactionsystemis implemented.

� Active behavior. The criteria enablesus to elaborateaboutthe active aspectsforsomeof thesystems.

The systemsselectedin this survey representsome of the more recent real-timedatabaseplatformsdeveloped. Thesesystemsarerepresentative of the ongoingresearchwithin thefield.

STRIP The STanfordReal-timeInformationProcessor(STRIP) [6] is a soft real-timedatabasesystemdevelopedat StanfordUniversity, US.STRIPis built for theUNIX oper-atingsystem,is distributedandusesstreamsfor datasharingbetweennodes.It is anactivedatabasethatusesSQL3-typerules.

DeeDS The Distributed active, real-timeDatabaseSystem(DeeDS)[9] supportsbothhardandsoft real-timetransactions.It is developedat theUniversityof Skövde,Sweden.It usesextendedECA rulesto achieve an active behavior with real-timeproperties.It isbuilt to takeadvantageof a multiprocessorenvironment.


BeeHive TheBeeHive system[103] is a virtual databasedevelopedat theUniversityofVirginia, Charlottesville,US, in which thedatain thedatabasecanbe locatedin multiplelocationsandforms. The databasesupportsfour different interfacesnamely, a real-timeinterface,a qualityof serviceinterface,a fault-tolerantinterface,andasecurityinterface.

REACH TheREACH system[116], developedattheTechnicalUniversityof Darmstadt,Germany, is anactive object-orienteddatabaseimplementedon top of theobject-orienteddatabaseopenOODB.Their goal is to archive active behavior in an OO databaseusingECA rules. A benchmarkingmodeis supportedto measureexecutiontimes of criticaltransactions.TheREACH systemis intendedfor soft real-timesystems.

RODAIN TheRODAIN system[108] developedat theUniversityof Helsinki, Finland,is a firm real-timedatabasesystemthatprimarily is intendedfor telecommunication.It isdesignedfor high degreeof availability andfault-tolerance.It is tailoredto fit the char-acteristicsof telecommunicationtransactionsidentifiedasshortqueriesandupdates,andlongmassiveupdates.

ARTS-RTDB The ARTS-RTDB system[52], developedat the University of Virginia,Charlottesville,US, supportsboth soft andhardreal-timetransactions.It usesimprecisecomputingto ensuretimelinessof transactions.It is built on top of the ARTS real-timeoperatingsystem[110].

2.4.1 Real-timeproperties

STRIP

TheSTRIP[6] systemis intendedfor soft real-timesystemsin which theultimategoal isto make asmany transactionsaspossiblecommitbeforetheir deadlines.It is developedfor the UNIX operatingsystemwhich might seemodd, but sinceSTRIP is intendedtorun in opensystemsUNIX wasselected.EventhoughUNIX is not a real-timeoperatingsystemit has,whenusedin theright way, turnedout to beagoodoperatingsystemfor softreal-timesystemssincea real-timeschedulingemulatorcanbeplacedon topof theUNIXschedulerwhich setsthe priorities accordingto somereal-timeschedulingalgorithm,areal-timebehavior canbeachieved.However, therehavebeensomeproblemsthatneededto beovercomewhile implementingSTRIPthatis relatedto real-timeschedulingin UNIX.For exampleto forcea UNIX schedulenot to adjusttheprioritiesof processesasthey arerunning. Non-real-timeoperatingsystemsoften have mechanismsto dynamicallyadjusttheprioritiesof processesduringrun time to addto throughputandfairnessin thesystem.By usingPosixUNIX, a new classof processeswhoseprioritiesarenot adjustableby theschedulerwasprovided. In [4] versionsof theearliestdeadlineandleastslackalgorithmswasemulatedontopof aschedulerin atraditionaloperatingsystem,andtheresultsshowedthatearliestdeadlineusingabsolutedeadlineandleastslackfor relativedeadlineperformedequalor betterthantheir real-timecounterparts,while the emulatedearliestdeadlineforrelative deadlinemissedmoredeadlinesthantheoriginal EDF algorithmfor low systemsload.However, duringhighloadtheemulatedalgorithmoutperformedtheoriginalEDF. InSTRIPEDF, highestvaluefirst,highestdensityvaluefirst or acustomschedulingalgorithmcanbeusedto scheduletransactions.To minimizeunpredictability, theSTRIPsystemis amain-memorydatabase,thusremoving disk I/O.

DeeDS

DeeDS[9] is intendedfor bothhardandsoft real-timesystems.It is built for theOSEdeltareal-timeoperatingsystemdevelopedby ENEADATA [31]. Thisdistributedhardreal-timeoperatingsystemis designedfor bothembeddeduniprocessorandmultiprocessorsystems.


If usedin a multiprocessorenvironmentthe CPUsarelooselycoupled. A moredetaileddescriptionof OSEdeltacanbefound in [43]. TheDeeDSsystemconsistsof two parts,onepart that handlesnon critical systemservicesandone that handlesthe critical. Allcritical systemsservicesareexecutedon a dedicatedprocessorto simplify overheadcostandincreasetheconcurrency in thesystem.TheDeeDSsystemis, astheSTRIPsystem,amainmemorydatabase.

BeeHive

BeeHive utilizes the conceptof datadeadline,forced-wait and the datadeadlinebasedschedulingalgorithms[113]. Theseconceptsassurethat transactionsarekept temporallyconsistentby assigninga morestringentdeadlineto a transactionbasedon themaximumallowedageof thedataelementsthatareusedin thetransaction,thusthenamedatadead-line. Thekey conceptof forcedwait is to, if a transactioncannotcompletebeforeits datadeadline,postponeit until dataelementsget updated,thusgiving the transactiona laterdatadeadline.Thesetransactionscanthenbe scheduledusing,for example,the earliestdata-deadlinefirst (EDDF) or datadeadlinebasedleastslack first (DDLSF) algorithms[113].

For real-timedatastoragea four level memoryhierarchyis assumed:main memory,non-volatile RAM (e.g., Flash),persistentdisk storage,and archival storage(e.g., tapestorage)[103]. The main memoryis usedto storedatathat is currently in useby thesystem. The non-volatile RAM is usedasa disk-cachefor dataor logs that arenot yetwritten to disk. Furthermore,systemdatastructureslike lock tablesandrule basescanbestoredin non-volatileRAM. Thedisk is usedto storethedatabase,just likeany disk-baseddatabase.Finally, thetapestorageis usedto make backupsof thesystem.By usingthesefour levelsof memorymanagementa higherdegreeof predictabilitycanbeachievedthanfor entirelydisk-baseddatabases,sincethebehavior canbesomewhatlikeamain-memorydatabaseeventhoughit is a disk-basedsystem.

REACH

REACHisbuilt ontopof TexasInstrumentsOpenOODBsystem,whichis anopendatabasesystem. By an opensystemwe refer to a systemthat canbe controlled,modified,andpartly extendedby developersandresearcher[112]. TheOpenOODBsystemis by itselfnot a real-timedatabasesystem,but an object-orienteddatabase.Someefforts hasbeendonein theREACH projectto aid theuserwith respectto systempredictability[18] suchasmilestones,contingency plans,abenchmarkingtool, anda tracetool.

Milestonesareusedto monitor theprogressof transactions.If a milestoneis missed,thetransactioncanbeabortedandacontingency planis releasedinstead.Thiscontingencyplanshouldbeimplementedto handlea misseddeadlinesituationby eitherdegradingthesystemin a safeway, or producea good-enoughresultbeforethe original transaction’sdeadline.Onecouldsaythatacontingency planin cooperationwith milestonesworksasawatch-dogthatis activatedwhenadeadlineis aboutto bemissed.

The REACH systemhasa benchmarkingtool that canbe usedto measureexecutiontimesfor methodinvocationsandevent triggering. The REACH tracetool cantracetheexecutionorderin thesystem.If thebenchmarkingtool is usedtogetherwith thetracetool,systembehavior andtimelinesscouldbedetermined.

RODAIN

The RODAIN systemis a real-timedatabasesystemintendedfor telecommunicationap-plications. The telecommunicationenvironmentis a dynamicandcomplex environmentthat dealswith both temporaldataandnon-temporaldata. A databasein sucha systemmust,supportboth soft andfirm real-timetransactions[108]. However, thebelief is that


hardreal-timedatabaseswill notbeusedin telecommunicationin thenearfuturesincetheygenerallyareto tooexpensiveto developor useto suit themarket [108].

Oneof thekey issuesfor RODAIN is availability, thusfault-toleranceis necessary. TheRODAIN systemis designedto havetwo nodes,thusgiving full databasereplication.Thisis especiallyimportantsincethedatabaseis a main-memorysystem.It usesa primaryanda mirror node. Theprimarydatabasesendslogs to the mirror databasewhich in turn ac-knowledgesall calls.Thecommunicationbetweenthenodesis assumedto bereliableandhave a boundedmessagetransferdelay. A watchdogmonitor keepstrack of any failingsubsystemandcaninstantlyswaptheprimarynodeandthemirror nodein caseof afailure,seefigure 2.5. The failed nodealwaysrecover asa mirror nodeand loadsthe databaseimagefrom permanentstorage.Furthermore,theUserRequestInterpretersystem(URIS)cankeeptrackof all ongoingtransactionsandtakeappropriateactionsif atransactionfails.Sinceboththeprimaryandthemirror nodehaveaURISnoactive transactionswill belostif a failurein theprimarysystemleadsto anodeswapbetweentheprimaryandthemirror.Figure2.5showsthearchitectureof RODAIN. ThesubsystemOODBMShandlesall tradi-tional databaseactivities, like concurrency control,physicalstorage,schemamanagementetc. Therearethreeinterfacesto thedatabase,thetraditionaluserinterface,referredto astheApplicationsinterface,theDBMS nodesinterface,andtheMirror interface.Notewor-thy is thedistinctionbetweenmirror nodesanddistributedDBMS nodes.Thepurposeofthemirror nodesis to ensurea fault-tolerantrunning,while thedistributionnodesareusedfor normaldatabasedistribution.

Database Management Node

User requestinterpretersubsystem

Distributeddatabase

subsystem

Fault-tolerantand recoverysubsystems

Watchdogsubsystem

OO DBMS

Applications

DBMS nodes

Mirror node

Figure2.5: RODAIN DBMS node.Figurefrom [108]

ARTS-RTDB

TherelationaldatabaseARTS-RTDB [52] incorporatesaninterestingfeaturecalledimpre-cisecomputing.If a query, whenits deadlineexpires,is not finished,theresultproducedsofarcanbereturnedto theclient if theresultcanbeconsideredmeaningful.For example,a querythatcalculatestheaveragevalueof hundredsof valuesin a relationcolumn. If anadequateamountof valueshasbeencalculatedat thetime of deadline,theresultcouldbeconsideredmeaningfulbut impreciseandit is thereforereturnedto theclientanyway.

ARTS-RTDB is built on top of the distributedreal-timeoperatingsystemARTS, de-velopedby Carnegie Mellon University[110]. ARTS schedulestasksaccordingto a time-varying value function, which specifiesboth criticality and importance. It doessupportbothsoft andhardreal-timetasks.

In ARTS-RTDB themostcritical dataoperationshasbeenidentifiedto betheINSERT,DELETE, UPDATE, andSELECToperations.Specialcarehasthereforebeenmadeto


optimizethesystemto increasetheefficiency for thefour basicoperations:insert,delete,update,andselect. Accordingto [52] many real-timeapplicationsalmostonly usetheseoperationsat run-time.

2.4.2 Distribution

To increaseconcurrency in the system,distributeddatabasescanbe used. Distributedina sensethat the databasecopiesresideon differentcomputernodesin a network. If thedatais fully replicatedover all nodes,applicationscanaccessany nodeto retrieve a dataelement.Unfortunately, maintainingdifferentdatabasenodesconsistentwith eachotherisnotaneasytask,especiallyif timelinessis crucial.Onemighthaveto tradeconsistency fortimeliness.A mechanismthatcontinuouslytries to keepthedatabasenodesasconsistentwith eachother as possibleis needed. Sincethe systemis distributed all updatesto adatabasenodemustbepropagatedviamessagepassing,or similar, thusaddingsignificantlyto thedatabaseoverheadbecauseof theaddedamountof synchronizationtransactionsinthe system.Oneof the mostcritical momentsfor a transactiondeployed in a distributeddatabaseis the point of commit. At this point all the involved nodesmust agreeuponcommittingthetransactionor not.

Oneof themostcommonlyusedcommitprotocolsfor distributeddatabasesis thetwo-phasecommitprotocol[39]. As thenameof thealgorithmsuggeststhealgorithmconsistsof two phases,theprepare-phaseandthecommit-phase.In thepreparephase,thecoordi-natorfor the transactionsendsaprepare messageto all othernodesandthenwaits forall answers.Thenodesthenanswerswith a ready messageif they canacceptthecom-mit. If thecoordinatorreceivesready from all nodesacommit messageis broadcasted,otherwisethe transactionis aborted.Thecoordinatorthenfinally waits for afinishedmessagefrom all nodesto confirmthecommit.Herebyis consistency guaranteedbetweennodesin thedatabase.

DeeDS

TheDeeDS[9] systemhasa lessstrict criteria for consistency, in orderto enforcetimeli-ness.They guaranteethateachnodehasa localconsistency, while thedistributeddatabasemight be inconsistentdue to differentviews of the systemon the differentnodes. Thisapproachmight be suitablefor systemsthat mostly rely on datathat is gatheredlocally,but sometimesusesdataimportedfrom othersubsystems.Consideranenginethathasallenginedata,e.g.,ignition control,enginespeedandfuel injection,storedin a localnodeofa distributeddatabase.Thetimelinessof theselocal dataitemsareessentialin orderto runthe engine. To further increasethe efficiency of the engine,remotelygathereddata,likedatafrom thetransmissionbox,with lesscritical timing requirementscanbedistributedtothelocalnode.

STRIP

The conceptof streamscommunicatingbetweennodesin a distributedsystemhasbeenrecognizedin STRIP[6]. Nodescanstreamviews or tablesto eachotheron a regularba-sis. Theusercanselectif wholetables/views or deltatables,which only reflectschangesto thetables/views, shouldbestreamed.Furthermoreit is selectableif thedatashouldbestreamed,periodicallywhensomedatahasreacheda predefinedageor only afteranex-plicit instructionto stream. In figure 2.6 we canseethe processarchitectureof STRIP.Themiddlepartof thefigureshowstheexecutionprocess,thetransactionqueue,theresultqueueandtherequestprocess.This partmakesthequerylayerof thedatabaseandcanbecomparedto anordinarydatabasethatprocessestransactionsandqueriesfrom theapplica-tion. Remoteapplicationaddressesqueriesor transactionsto therequestingprocess,whichin turn placesthe transactionin the transactionqueue. However, local applicationscan


accessthe transactionqueuedirectly via a client library, thusminimizing overhead.Eachexecutionprocessescanexecuteatransactionfromthetransactionqueueor anupdatetrans-actionfrom oneof theupdatequeues.Theupdatequeuesarefedfrom theincomingupdatestreams.Whena table/view needsto besentto anoutgoingstream,oneof theexecutionprocessesenqueuesit to theupdatequeuereadby theexport process.It hasbeenshownthatwhentheupdatefrequency is low, the import andexport processescanrun at a highpriority without significantlyaffectingtransactionresponsetimesbut whenthefrequencyincreasesthe needfor a differentupdateschedulingpolicy is necessary[6], seesection2.4.3.

ImportProcess

ExportProcess

ExecutionProcess

RequstProcess

TransactionQueue

ResultQueue

UpdateQueues

UpdateQueue

StreamUpdates

StreamUpdates

Requests

Figure2.6: Theprocessarchitectureof theSTRIPsystem.Figurefrom [6].

BeeHive

UnlikemostdatabasesBeeHiveis avirtual database,in thesensethatin additionto its owndatastoragefacility it canuseexternaldatabasesand incorporatethemasonedatabase.Thesedatabasescanbelocatedeitherlocally or onanetwork, e.g.,theInternet.

A virtual databaseis definedasa databasethat organizesdatascatteredthroughtheInternetinto a queriabledatabase[40]. Considera web servicethat comparespricesofproductsontheInternet.Whenyouenterthedatabaseyoucansearchfor aspecificproduct,andtheservicewill returna list of Internetretailersandto whatpricethey areselling theproduct.Thedatabasesystemconsistsof four parts[40]:

� Wrappers. A wrapperis placedbetweena web-pageor databaseand the virtualdatabase.In the web-pagecase,the wrapperconverts the textual contentof theweb-pageinto a relational format understandableby the virtual database.Whenusingawrapperin thedatabasecase,thewrapperconvertsthedatareceivedfrom thedatabaseinto thevirtual databaseformat.Sucha wrappercanbeimplementedusingahigh level descriptionlanguage,e.g.,Javaapplets.

� Extractors.Therelationsreceivedfrom thewrappermostoftencontainsunstructuredtextualdatain which theinterestingdataneedsto beextracted.

� Mappers.Themappermapsextractedrelationsinto acommondatabaseschema.

� Publishers.Thepublisheris usedto presentthedatabaseto the user, it hassimilarfunctionalityasa traditionaldatabase.


Figure2.7: TheBeeHivevirtual database.Figurefrom [103]

BeeHive cancommunicatewith othervirtual databases,web-browsersor independentdatabasesusingwrappers.ThesewrappersareJavaappletsandmayusetheJDBCstandard,seefigure2.7.

RODAIN

RODAIN systemsupportsdatadistribution.Thenodescanbeanythingbetweenfully repli-catedto completelydisjoint. Theirbelief is thatonly afew requestsin telecommunicationsneedaccessto morethanonedatabasenodeandthat the requestdistributionsamongthedatabasesin thesystemcanbearrangedto bealmostuniform[108].

ARTS-RTDB

ARTS-RTDB hasbeenextendedto supportdistribution. Thedatabasenodesusea sharedfile that containsinformationbinding all relationsto the server responsiblefor a partic-ular relation. Sincethe file is sharedbetweenthe nodes,it is to be treatedas a sharedresourceandmustthereforebeaccessedusinga semaphore.It is believedthat if relationsareuniformly distributedbetweenthenodesandif no hot-spotrelationsexist, an increasein performancewill beseen.A hot-spotrelationis a relationthat many transactionsuse,andsucharelationcanleadto a performancebottleneckin thesystem.

2.4.3 Transactionworkload characteristics

DeeDS

DeeDSsupportsbothsporadic(event-triggered)andperiodictransactions.Therearetwoclassesof transactions:critical (hardtransactions)andnon-critical(soft transactions).Toensurethat a deadlineis kept for a critical transaction,milestonemonitoringandcontin-gency plansareused.A milestonecanbeseenasa deadlinefor a partof the transaction.


If a milestoneis passed,it is clearthatthetransactionwill not make its deadline,a contin-gency plancanbeactivatedandthe transactionis aborted.A contingency planshould,ifimplementedcorrectly, dealwith theconsequencesof a transactionaborting.Oneway tocomputelessaccurateresultandpresentit in time,similar to imprecisecomputingusedbyARTS-RTDB (seesection2.4.1).Milestonesandcontingency plansarediscussedfurtherin[32]. Thetiming requirementsfor a transactionis passedto thesystemasa parameterizedvaluefunction,thisapproachreducesthecomputationalcostandthestoragerequirementsof thesystem.

Theschedulingof transactionsis madeonlinein two steps.First,asufficientscheduleisproduced.Thisschedulemeetstheminimumrequirements,for exampleall harddeadlinesand 90 percentof the soft deadlinesare met. Secondly, the event monitorsworst-caseexecutiontime is subtractedfrom theremainingallowedtime for theschedulerduringthistimeslot,andthis time is usedto refineandoptimizethetransactionschedule[72].

STRIP

STRIPsupportsfirm deadlinesontransactions[7], thuswhenatransactionmissesits dead-line it will beaborted.Therearetwo classesof transactionsin STRIP, low valueandhighvaluetransactions.Thetime whentransactionsarescheduledfor executionis determinedby transactionclass,valuedensity, andchoiceof schedulingalgorithm.Thevaluedensityis theratiobetweenthetransactionsvalueandtheremainingprocessingtime. In theSTRIPsystemthereis adistinctionbetweentransactionsandupdates.Transactionsareconsideredto be read,write andupdateoperationsinitiated by the useror the application,whereasupdatesareconsideredto be updateoperationsinitiated from otherdatabasenodesin adistributedsystem.The schedulingof transactionsis in competitionwith the schedulingof updates,thereforeupdatesalsohave thesamepropertiesastransactionswith respecttoclasses,values,andvaluedensity. STRIPhasfour schedulingalgorithms,UpdatesFirst(UF), TransactionsFirst (TF), Split Updates(SU),andApply UpdatesonDemand(OD).

� UpdatesFirst schedulesall updatesbeforetransactions,regardlessof thevalueden-sity of the transactions.It is selectableif a runningtransactionis preemptedby anupdateof if it shouldbeallowedto commitbeforetheupdateis executed.For asys-temwith a high loadof updatesthis policy cancauselong andunpredictableexecu-tion timesfor transactions.However, for systemswhereconsistency betweennodesandwheretemporaldataconsistency is moreimportantthantransactionthroughput,this canbea suitablealgorithm. Further, this algorithmis alsosuitablefor systemswhereupdatesareprioritizedover transactions.Considera databaserunningstockexchangetransactions.A changein pricefor a stockmustbeperformedbeforeanypendingtransactionsin orderto getthecorrectvalueof thetransaction.

� TransactionsFirst is theoppositeof updatefirst. Transactionsarealwaysscheduledin favor of updates.However a transactionscannotpreempta runningupdate.Thisbecauseupdatesmostoftenhaveshortexecutiontimecomparedto transactions.Thisalgorithmsuitssystemsthatvaluesthroughputof transactionshigherthantemporalconsistency betweenthe nodes. TransactionsFirst might be useful in a industrialcontrollingsystem.If, in anoverloadedsituation,themostrecentversionof a dataelementis not available,the systemmight gain in performancefrom beingabletorun its controlalgorithmsusinganoldervalue.

� Split Updatesmake useof thedifferentclassesof updates.It schedulesupdatesandtransactionsaccordingto thefollowing order: high valueupdates,transactions,andlow valueupdates.Thisalgorithmcombinesthetwo previousalgorithmsandwouldsuit a systemwhereonepartof thedataelementsis crucialwith respectto temporalconsistency, at thesametimeastransactionthroughputis important.


� Apply Updateson Demandexecutetransactionsbeforeupdates,but with thediffer-encethatwhenatransactionencountersstaledata,theupdatequeueis scannedfor anupdatethat is waiting to updatethestaledataelement.This approachwould enablea high throughputof transactionswith a high degreeof temporalconsistency. How-ever, calculatingtheexecutiontime for a transactionis moredifficult sincetheworstcaseis thatall dataelementsusedin thetransactionhaspendingupdates.Applyingupdatesondemandresemblesabouttheideasof triggeredupdates[8].

Sincetransactiondeadlinesarefirm, thus transactionsarevaluelessafter their dead-line hasexpired,a mechanismcalledfeasibledeadlinescanbeusedfor transactions.Themechanismabortstransactionsthathasnochanceof committingbeforetheirdeadline.

BeeHive

Thefactthatthedatabaseis virtual andmayconsistof many differentkindsof underlyingdatabasesis transparent.The useraccessesthe databasethroughat leastoneof the fourinterfacesprovidedby BeeHive: FT API, RT API, SecurityAPI, andQoSAPI (seefigure2.8). FT API is the fault-tolerantinterface. Transactioncreatedwith this interfacewillhave someprotectionagainstprocessorfailuresandtransientfaultsdueto power glitches,softwarebugs,raceconditions,andtiming faults.RT API is thereal-timeinterface,whichenablesthe userto specify time constraintsand typical real-timeparametersalongwithtransactions.Thesecurityinterfacecanbeusedby applicationthat for instancedemandsauthorizationfor usersandapplications.Furthermoreencryptioncanbe supported.TheQuality of Service(QoS)interfaceis primarily usedfor multimediatransactions.Theusercanspecifytransactionsdemandsonqualityof service.

Whena transactionarrivesfrom any interface,it is sentto theservicemapper, whichtransformsit to a commontransactionformat usedfor all transactionsin the system,re-gardlessof its type,e.g.,real-timetransaction.It is thenpassedon to theresourceplanner,which determineswhat resourceswill beneeded.Furthermore,it is passedto theadmis-sioncontroller, which in cooperationwith theresourceplanner, decidesif thesystemcanprovideasatisfactoryservicefor thetransaction.If thatis thecase,it is sentto theresourceallocationmodule,whichgloballyoptimizestheuseof resourcesin thesystem.Finally thetransactionis sentto thecorrectresource,e.g.,anetwork or theoperatingsystemetc.

RODAIN

Fivedifferentareasfor databasesin telecommunicationis identified[93]:

1. Retrieval of persistentcustomerdata.

2. Modificationsof persistentcustomerdata.

3. Authorizationof customers,e.g.,PIN codes.

4. Sequentiallog writing.

5. MasscallingandTelevoting. Thiscanbeperformedin largeblocks.

From thesefive areas,threedifferenttypesof transactionscanbe derived [77]: shortsimplequeries,simpleupdates,andlong massive updates.Shortsimplequeriesareusedwhenretrieving customerdataandauthorizingcustomers.Simpleupdatesareusedwhenmodifyingcustomerdataandwriting logs.Longmassiveupdatesareusedwhentelevotingandmasscalling is performed.

Theconcurrency controlin RODAIN supportsdifferentkindsof serializationprotocols.Oneprotocolis the = -serializationin which a transactionmaybeallowedto readold dataaslongastheupdateis notolderthanapredefinedtime [108].


FT API RT API Security API QoS API

..........

BeeKeeperServiceMapper

ResourcePlanner

AdmissionController

Resource Allocation Module

IP Network

RSVP

ATM Network

UNI 4.0

Real-Time OS

ResourceManager

Objects

Service-specific API

ResourceManagement

Resources

Figure2.8: Theresourcemanagerin BeeHive. Figurefrom [103]

Apart from a transactiondeadline,an isolationlevel canalsobeassignedto a transac-tion. A transactionrunningon a low isolationlevel acceptsthat transactionsrunningona higher isolation level areaccessinglocked objects. However, it cannotaccessobjectsbelongingto a transactionwith a highdegreeof isolation.

ARTS-RTDB

ARTS-RTDB usesapessimisticconcurrency control,strict two phaselockingwith priorityabort [52]. This meansthat assoonasa higherprioritized transactionwantsa lock thatis ownedby a transactionwith low priority, the low-level transactionis aborted.To avoidthecostlyprocessof rolling backtheabortedtransaction,all datawriting is performedoncopies.At thepoint of commit,thetransactionasksthelock-managerif a commitcanbeallowed. If this is thecase,thetransactioninvokesa subsystemthatwritesall datainto thedatabase.

2.4.4 Activedatabases

Active databasescanperformactionsnot explicitly requestedfrom theapplicationor en-vironment. Considera dataelement> , which is derivedfrom two otherdataelements,1and 2 . The traditionalway to keep > updatedwould be to periodicallypoll the databaseto determineif 1 or 2 have beenaltered. If that is the case,a new valueof > would becalculatedandtheresultwritten backto thedatabase.Periodicpolling is oftenperformedat a high costwith respectto computationalcostandwill increasethe complexity of theapplicationtaskschedule.A differentapproachwouldbeto introducea triggerthatwouldcauseaneventassoonaseither 1 or 2 hasbeenchanged.Theeventwould in its turnstarta transactionor similar thatwould update> . This functionalitywould beusefulfor otherpurposesthanto updatederiveddataelements.It could, for example,beusedto enforceboundariesof dataelements.If a dataelement,e.g.,datathat representsa desiredwaterlevel in ourexampleapplicationin figure1.1,hasamaximumandminimumallowedvaluethanthisrestrictioncanbeappliedin thedatabaseinsteadof in theapplication.An attempt


to setaninvalid valuecouldresultin somekind of action,e.g.,anerrorexceptionor a cor-rectionof thevalueto theclosestvalid value. By applyingthis restrictionin thedatabaseit is abstractedaway from theapplication,thusreducingtherisk of programmingerrorsorinconsistency betweentransactionsthatusethisdataelement.

Oneway to handlesuchactive behavior is throughthe useof ECA rules[35], whereECA is anabbreviation of Event-Condition-Action-rules,seefigure2.9. Theeventsin an

ON <event E>IF <condition C>

THEN <action A>

Figure2.9: Thestructureof anECA rule.

active databaseneedto be processedby an eventmanager, which sendsthemto the rulemanager. Therule managerin its turn locatesall ECA rulesthatareaffectedby thenewlyarrivedeventandcheckstheir conditions.For thoseECA ruleswhoseconditionsaretrue,theactionis activated.Thereare,however, threedistinctapproacheson whenandhow toexecutetheactions[32]:

� Immediate:Whenaneventarrives,theactivetransactionis suspendedandconditionevaluationandpossiblyactionexecutionis doneimmediately. Uponrulecompletion,thetransactionis resumed.Thisapproachaffectstheresponsetimeof thetransaction.

� Deferred:Whenaneventarrives,theactivetransactionis runto completionandthenconditionevaluationandpossiblyactionexecutionis done.This approachdoesnotaffect theresponsetimeof thetriggeringtransaction.

� Decoupled:Whenusingthis approach,conditionevaluationandpossiblyactionex-ecutionareperformedin oneor severalseparatetransactions.Thishastheadvantagethattheseupdateswill beloggedevenif thetriggeringtransactionaborts.

Onedisadvantagewith active databasesis that the predictability, with respectto re-sponsetimes,is decreasedin thesystem.This is becauseof theexecutionof therules.Forimmediateor deferredrules the responsetime of the triggeringtransactionis prolongedbecauseof the executionof rulesprior to its point of commit. To be ableto calculatearesponsetime for sucha transaction,theexecutiontimeof all possiblerulesthatthetrans-actioncaninvoke. Theserulescanin their turn activaterules,socalledcascading,whichcancreatearbitrarycomplex calculations.Whendecoupledrulesareused,transactionscangeneratenew transactionsin thesystem.Thesetransactionsandtheir priorities, responsetimes,andpossiblerule invocationsmustbetakenin accountwhencalculatingtransactionresponsetime,resultingin verypessimisticworst-case-executiontimes.

Someextensionsto ECA ruleswhichincorporatestimeconstraintshavebeenstudiedin[50]. ForamoredetaileddescriptionaboutECA rules,activedatabasesandactivereal-timedatabasessee[32, 98]

STRIP

TheSTRIPrulesystemchecksfor eventsatcommit-timeof eachtransaction? , andfor alleventswhoseconditionis trueanew transaction? " is created,whichexecutestheexecutionclauseof the rule. Thus, the STRIPsystemusesa decoupledapproach. ? " is activatedfor executionafter the triggering transactionhascommitted. By default ? " is releasedimmediatelyafter commit of the triggering transaction,but it can be delayedusing theoptionalafter statement,seefigure2.10.

Theafter statementenablesall ruleexecutionclauses,activatedduringthetimewin-dow betweenruleevaluationandtheexecutionclausespecifiedby theafter statement,to


WHEN <eventlist>[IF <condition>]THEN

EXECUTE <action>[AFTER <time-value>]

Figure2.10: A simplifiedstructureof a STRIP-rule.TheoptionalAFTER -clauseenablesfor batchingof severalrule-executionsin orderto decreasecomputationalcosts.

Sequential Parallel

Independent ?@� independentof ?A�Dependent ? � cannot start until ?A�

commits, otherwiseit is dis-carded.

? � cannot complete until?A� commits, otherwiseit isaborted.

Exclusive ?@� cannot start until ?A�aborts, otherwiseit is dis-carded.

?B� cannot complete until?A� aborts, otherwiseit isaborted.

Table2.12:Tableshowing all decoupledexecutionmodessupportedby theDeeDSsystem.?A� is thetriggeringtransactionand ?B� is therule transaction.Tablefrom [33].

bebatchedtogether. If multipleupdatesonasingledataelementexist in thebatch,only theonesnecessaryto derive theresultingvalueof thatdataelementareexecuted,thussavingcomputationalcost[5]. To have the executionclausein a separatetransactionsimplifiesrule processing.The triggeringtransactioncancommit regardlessof theexecutionof theexecutionsclauses,sincetheconditionclauseof therulescannotalterthedatabasestateinanyway. Possibleside-effectsof therulesarethendealtwith in aseparatetransaction.Onedisadvantagewith decoupledexecutionclausesis that theconditionresultsandtransitiondataaredeletedwhenthetriggeringtransactioncommits,thus,datais notavailablefor thetriggeredtransaction.This hasbeensolved in STRIPby thebind as statement.Thisstatementbindsacreatedtableto a relationthatcanbeaccessedby theexecutionclause.

DeeDS

SinceDeeDSsupportshardreal-timesystemstheruleprocessingmustbedesignedto retainasmuchpredictabilitywith respectto timelinessaspossible.This is achievedby restrictingrule processing.Cascading,for example,is limited so that unboundedrule triggeringisavoidedwhena rule is executed. The usercandefinea maximumlevel of the cascadedepth.If thecascadinggoesdeeperthanthatanexceptionis raised.Furthermore,conditionevaluationis restrictedto logicalexpressionsoneventsandobjectparameters,andmethodinvocations. DeeDSusesextendedECA rules [72] that alsoallows for specifyingtimeconstraintsto rules,e.g.,deadlines.

Event monitoring hasalso beendesignedfor predictability. Both synchronousandasynchronousmonitoringis available. In synchronousmodetheeventmonitor is invokedon time-triggeredbasisandresultshave shown that throughputis higherthanif theasyn-chronous(event-triggered)event monitoring is used,but at the costof longerminimumeventdelays.Whensynchronousmodeis used,eventburstswill not affect thesysteminanunpredictableway [72]. In DeeDS,theimmediateanddeferredcouplingmodesarenotallowed. Insteadwhena rule is triggeredandthe conditionstatesthat the rule shouldbeexecuted,a new transactionis created,which is immediatelysuspended.If a contingencyplanexistsfor this rule,a contingency transactionis alsocreatedandsuspended.All com-binationsof decoupledexecutionis supportedin DeeDS[33], seetable2.12. Depending


on which modethat is selected,the scheduleractivatesthe rule transactionsaccordingtothemode.Theexclusivemodeis usedto schedulecontingency plans.

REACH

REACH allows ECA rulesto be triggeredin all modes,immediate,deferredanddecou-pled. Decoupledrulesaredependentor independent,furthermorethey canbeexecutedinparallel,sequential,or exclusive mode. The exclusive modeis intendedfor contingencyplans.TheECA rulesusedin REACH haveno real-timeextensions.

Therearehoweversomerestrictionsonwhentousethedifferentcouplingmodes.Rulestriggeredby a singlemethodevent canbe executedin any couplingmode,while a ruletriggeredby a compositeeventonly cannotberun in immediatemode.This is becauseiftheeventsthatmakeupcompositeeventoriginatein multipletransactions,noidentificationof thespawning transactionsis possible[116]. Rulesthatareinvokedby temporalevents(time-triggered)can only be run in an independentdecoupledmode,sincethey arenottriggeredby a transaction[19].

To simplify the creationof the rule-basea tool, GRANT, hasbeendeveloped. Thisgraphicaltool promptstheuserfor necessaryinformation,providescertaindefaultchoices,createsC++ languagestructures,andmapsrulesto C functionsstoredin a sharedlibrary[18].

Theeventmanagerin REACH consumeseventsaccordingto two policies:chronolog-ical or mostrecent.Thechronologicalapproachexecutesall eventsin theorderthey arrivewhile themostrecentstrategy only executesthemostrecentinstanceof everyevent.Whatpolicy to useis dependentof thesemanticsof theapplication.Considertheexamplewiththe stockmarket databaseagain. If, in an overloadsituation,the databaseis not abletoimmediatelyexecuteall stockpriceupdates,only themostrecentupdateof astockis inter-estingsincethis updatecontainsthecurrentpriceof this stock.For a systemlike this, themostrecentapproachwouldbesufficient,while in a telephonebilling systemit mightnot.In a systemlike that,all updatesto the databaseconsistof a valueto addto the existingrecord,thereforemostrecentis notsufficienthere.

2.5 Observations

Thedatabasespresentedrepresenta setof systemsthat basicallyhave the samepurpose,i.e.,toefficientlystoreinformationin embeddedsystemsor real-timesystems.They mainlyconsistof the samesubsystems,e.g., interfaces,index system,andconcurrency controlsystem.But yet thesystemsbehave so differently. Somesystemsareprimarily intendedfor event-drivensystem,while othersuit staticallyscheduledsystemsmore.Somesystemsare relationalwhile otherareobject-oriented.Somesystemsare intendedfor a specificapplication,e.g.,telecommunication,processcontrolor multimediaapplication.

Furthermore,aninterestingobservationcanbemadeaboutthesesystems.Theresearchplatformsfocusmoreon functionalitywhile thecommercialsystemsaremoreinterestedin userfriendliness,adaptability, andstandardscompliance.While theresearchplatformshave detailedspecificationon new internalmechanismsthat improve performanceundercertaincircumstances,like new concurrency controlsor schedulingpolicies,thecommer-cial systemssupportsmultiple interfacesto easeintegrationwith theapplicationandsup-portsstandardslike ODBC, OLE DB, andJDBC.Looking backat thecriteriamentionedby ABB in section2.2.2,wecanseethatmostof thecriteriaarefulfilled by thecommercialproducts.To beableto combinethesecriteriawith thetechnologydeliveredby theresearchplatformswouldbeacontribution.

Oneimportantissuethatarisesis: Whichembeddeddatabasesystemshouldonechoosefor a specifictype of application?The taskof choosingthe bestdatabasesystemcanbea long andcostly processandprobablynot without compromises.A differentapproach


would be to have a moregenericdatabasethatcanbecustomized,possiblywith aid of atool, to fit a specificapplication.Thiswill befurtherdiscussedin thenext chapter.

Chapter 3

Component-basedsystems

Businessenterprisesandsocietyin generalarebecomingincreasinglydependenton com-putersystems.Almosteveryapplicationdomainis facedwith thechallengeof ensuringthatdatain the systemis managedin a uniform mannerandstoredefficiently by the system,e.g., telecommunications,e-commerce,businessenterprise,vehicle industry, embeddedandmobilesystems.As aresult,databasesystemsareusedin awidevarietyof applicationareas,andarerequiredto provideefficientmanagementof heterogeneousdataof all shapesandsizes.

Databaseindustryis today, morethanever, facedwith requirementsfor rapidapplica-tion developmentanddeployment,delivery of datain the right form to the right placeattheright time and,mostimportantly, minimizedcomplexity for bothendusersanddevel-opers. Rapiddevelopmentwith low costs,high quality andreliability, which minimizessystemcomplexity canbe achieved if component-basedsoftwaredevelopmentparadigmis introducedin databasedevelopment.This hasbeenrecognizedandexploitedby somemajor databasevendors,e.g.,Oracle,IBM, Informix andSybasehave all developedex-tensibledatabasesystems,which allow addingnon-standardfeaturesandfunctionality tothe extensibledatabasesystem. However, existing component-baseddatabasesolutionsmainly focuson solving oneproblem,e.g., the Microsoft UniversalDataAccessarchi-tectureprovidesuniform manipulationof datafrom differentdatastores,the extensibleOracle8i serverenablesmanipulationof non-standarddatatypes.

It has been recognizedthat embeddedand real-time systemscould benefit fromcomponent-baseddevelopmentaswell. Generally, by having well-definedreusablecom-ponentsasbuilding blocks,notonly developmentcostsarereduced,but moreimportantly,verificationandcertificationof componentswill only needto bedoneonce. However, toefficiently reusecomponentsfor composingdifferentsystems,goodcompositionrulesforthesystemassemblymustbeprovided,ensuringreliability of thecomposedsystem.Ex-isting component-basedembeddedandreal-timesystemsaremostly focusedon waysofpreservingreal-timebehavior of the systemand/orenablinguseof componentsin low-resourcesystems.A databasesystemthat canbe tailoredfor differentapplicationssuchthat it providesnecessaryfunctionality but requiresminimum memoryfootprint, and ishighly integratedwith thesystemwould mostlikely bea preferablesolutionfor integrat-ing databasesin embeddedreal-timesystems.However, databasesfor real-timeandem-beddedsystemssupportingfastdevelopmentthroughreuseof components,do not exist,whichmakestheseapplicationdomainsdeprivedof thebenefitsthatcomponent-basedde-velopmentcouldbring. Thus,in this chapterwe identify andcontrastmajor issuesin twocomponent-basedsystems,databaseandembeddedreal-time,andinspectpossibilitiesofcombiningthesetwo areas.

Component-basedsystemscan be analyzedonly if certain knowledge of generalcomponent-basedsoftwareengineeringandits conceptssuchascomponents,architecture,andreuseareunderstood.Therefore,basicconceptsof component-basedsoftwareengi-

40

CHAPTER3. COMPONENT-BASEDSYSTEMS 41

neeringare introducedin section3.1, and they arenecessaryin order to identify issuesin differentcomponent-basedsystemsandto obtainuniform criteria for surveying exist-ing component-baseddatabaseandembeddedreal-timesystems.In section3.2we reviewcomponentsandcomponent-basedsolutionsin databasesystems.This is followedby real-time componentsandsolutionsin embeddedreal-timesystemsin section3.3. Section3.4concludesthis chapterwith a tabular overview of investigatedcomponent-basedsystemsandtheir characteristics.

3.1 Component-basedsoftwaredevelopment

The needfor transitionfrom monolithic to openand flexible systemshasemergeddueto problemsin traditionalsoftwaredevelopment,suchashigh developmentcosts,inade-quatesupportfor long-termmaintenanceandsystemevolution, andoften unsatisfactoryquality of software[17]. Component-basedsoftwareengineering(CBSE)is anemergingdevelopmentparadigmthat enablesthis transitionby allowing systemsto be assembledfrom a pre-definedsetof componentsexplicitly developedfor multipleusage.Developingsystemsout of existing componentsoffers many advantagesto developersandusers. Incomponent-basedsystems[17, 25, 26, 36]:

� Developmentcostsaresignificantlydecreasedbecausesystemsarebuilt by simplypluggingin existingcomponents.

� Systemevolutionis easedbecausesystembuilt onCBSEconceptsis opento changesandextensions,i.e., componentswith new functionalitycanbepluggedinto anex-istingsystem.

� Quality of softwareis increasedsinceit is assumedthatcomponentsarepreviouslytestedin differentcontexts andhave validatedbehavior at their interfaces.Hence,validationefforts in thesesystemshave to primarily concentrateon validationof thearchitecturaldesign.

� Time-to-marketis shortenedsincesystemsdonothaveto bedevelopedfrom scratch.

� Maintenancecostsarereducedsincecomponentsaredesignedto becarriedthroughdifferentapplicationsandchangesin acomponentare,therefore,beneficialto multi-plesystems.

Asaresult,efficiency in thedevelopmentfor thesoftwarevendoris improvedandflexibilityof deliveredproductis enhancedfor theuser[59].

Component-baseddevelopmentalsoraisesmany challengingproblems,suchas[59]:

� Building goodreusablecomponents.This is notaneasytaskanda significanteffortmustbeusedto produceacomponentthatcanbeusedin differentsoftwaresystems.In particular, componentsmustbetestedandverifiedto beeligible for reuse.

� Composinga reliablesystemout of components.A systembuilt out of componentsis in risk of beingunreliableif inadequatecomponentsareusedfor the systemas-sembly. Thesameproblemariseswhenanew componentneedsto beintegratedintoanexistingsystem.

� Verificationof reusablecomponents.Componentsare developedto be reusedinmany differentsystems,which makesthecomponentverificationa significantchal-lenge. For every componentuse,the developerof a new component-basedsystemmustbe able to verify the component,i.e., determineif the particularcomponentmeetstheneedsof thesystemunderconstruction.


� Dynamicandon-line configurationof components.Componentscanbe upgradedandintroducedat run-time;thisaffectstheconfigurationof thecompletesystemandit is importantto keeptrackof changesintroducedin thesystem.

3.1.1 Software component

Softwarecomponentsarethe coreof CBSE.However, differentdefinitionsandinterpre-tationsof a componentexist. Within a softwarearchitecture,a componentis consideredto bea unit of compositionwith explicitly specifiedinterfacesandquality attributes,e.g.,performance,real-time,reliability [17]. In systemswhereCOM is usedfor a componentframework, a componentis generallyassumedto bea self-contained,configurablebinarypackagewith preciselydefinedstandardizedinterfaces[76]. A componentcan be alsoviewedasa softwareartifact thatmodelsandimplementsa well-definedsetof functions,andhaswell-definedcomponentinterface(which do not have to be standardinterfaces)[29].

Hence,thereis no commondefinitionof a componentfor everycomponent-basedsys-tem. Thedefinitionof a componentclearlydependson the implementation,architecturalassumptions,and the way the componentis to be reusedin the system. However, allcomponent-basedsystemshave onecommonfact, andthat is: componentsare for com-position[107].

While frameworks andstandardsfor componentstodayprimarily focuson CORBA,COM, or JavaBeans,theneedfor component-baseddevelopmenthasbeenidentifiedin theareaof operatingsystems(OSs).Theaimis to facilitateOSevolutionwithoutendangeringlegacy applicationsandprovidebettersupportof distributedapplications[73].

Commonfor all typesof components,independentof theirdefinition,is thatthey com-municatewith its environmentthroughwell-definedinterfaces,e.g.,in COM andCORBAinterfacesaredefinedin aninterfacedefinitionlanguage(IDL), MicrosoftIDL andCORBAIDL. Componentscanhave morethanoneinterface.For example,a componentmayhavethreetypesof interfaces:provided, required,andconfigurationinterface[17]. Providedandrequiredinterfacesare intendedfor the interactionwith othercomponents,whereasconfigurationinterfacesareintendedfor useby the userof the component,i.e., softwareengineer(developer)who is constructinganapplicationoutof reusablecomponents.Eachinterfaceprovidedby a componentis, uponinstantiationof thecomponent,boundto oneor moreinterfacesrequiredby othercomponents.Thecomponentproviding an interfacemayservicemultiplecomponents,i.e.,therecanbeone-to-many relationbetweenprovidedandrequiredinterfaces.Whenusingcomponentsin anapplicationtheremightbesyntacticmismatchbetweenprovided andrequiredinterfaces,even whenthe semanticsof the in-terfacesmatch.This requiresadaptationof oneor bothof thecomponentsor anadaptingconnectorto beusedbetweencomponentsto performthetranslationbetweencomponents

RequiredinterfaceProvided

interface

Connector

Component

Component

Figure3.1: Componentsandinterfaces


(seefigure3.1).Independentlyof applicationarea,asoftwarecomponentisnormallyconsideredtohave

blackbox properties[36, 29]: eachcomponentseesonly interfacesto othercomponents;internalstateandattributesof thecomponentarestronglyencapsulated.

Everycomponentimplementssomefield of functionality, i.e.,adomain[17]. Domainscanbehierarchicallydecomposedinto lower-level domains,e.g.,thedomainof communi-cationprotocolscanbedecomposedinto several layersof protocoldomainsasin theOSImodel.Thismeansthatcomponentscanalsobeorganizedhierarchically, i.e.,acomponentcanbecomposedout of subcomponents.In this context, two conflictingforcesneedto bebalancedwhendesigninga component.First, smallcomponentscover smalldomainsandarelikely to be reused,as it is likely that suchcomponentwould not containlarge partsof functionality unneededby the system. Second,large componentsgive moreleveragethansmallcomponentswhenreused,sincechoosingthelargecomponentfor thesoftwaresystemwould reducethe costassociatedwith the effort requiredto find the component,analyzeits suitability for a certainsoftwareproduct,etc [17]. Hence,whendesigningacomponent,a designershouldfind the balancebetweenthesetwo conflicting forces,aswell asactualdemandsof thesystemin theareaof componentapplication.

3.1.2 Software architecture

Everysoftwaresystemhasanarchitecture,althoughit maynotbeexplicitly modeled[71].Thesoftwarearchitecturerepresentsahighlevel of abstractionwhereasystemis describedasa collectionof interactingcomponents[3]. A commonlyuseddefinitionof a softwarearchitectureis [11]:

Thesoftwarearchitectureof aprogramor computingsystemis thestructureorstructuresof thesystem,which comprisesoftwarecomponents,theexternallyvisiblepropertiesof thosecomponentsandtherelationshipamongthem.

Thus,thesoftwarearchitectureenablesdecompositionof thesysteminto well-definedcom-ponentsandtheir interconnections,andconsequentlyprovidesmeansfor building complexsoftwaresystems[71]. Designof the softwarearchitectureis the first stepin the designprocessof a softwareproduct,right after the specificationof the system’s requirements.Hence,it allows earlysystemtesting,that is, aspointedout by Bosch[17] assessmentofdesignandquality attributesof a system.Quality attributesof a systemarethosethatarerelevant from the softwareengineeringperspective, e.g.,maintainability, reusability, andthosethat representquality of the systemin operation,e.g.,performance,reliability, ro-bustness,fault-tolerance.Thesequalityattributesof a systemcouldbefurtherclassifiedasfunctional(seetable3.1)andnon-functionalqualityattributes(seetable3.2),andusedforarchitecturalanalysis[111]. Thesoftwarearchitecturaldesignprocessresultsin compo-nentquality requirements,aswell asseveralconstraintsanddesignrulescomponentmustobey, e.g.,meansof communication[17]. Hence,developingreusablecomponentsdependson thesoftwarearchitecture,becausethesoftwarearchitectureto a largeextentdefinestheway a componentis to bedeveloped,its functionalityandrequiredquality [17]. Thus,thesoftwarearchitecturerepresentsthe effective basisfor reuseof components[86]. More-over, thereareindicationsthatsoftwareevolutionandreuseis morelikely to receivehigherpayoff if architecturesanddesignscanbereusedandcanguidelow level componentreuse[67, 75].

In thesystemdevelopmenttheissueof handlingconflictsin qualityrequirementsduringarchitecturaldesignmustbeexplicitly addressed.Thatis becausea solutionfor improvingonequality attributeaffectsotherquality attributesnegatively, e.g.,reusabilityandperfor-manceareconsideredto becontradicting,asarefault-toleranceandreal-timecomputing.E.g., considera softwaresystemfine-tunedto meetextremeperformancerequirements.In sucha system,it couldbe costly to addnew functionality (components),sinceadding


Performance Thesystem’scapacityof handlingdataor events.Reliability Theprobabilityof asystemworkingcorrectlyoveragiven

periodof time.Safety Thepropertyof the systemthat will not endangerhuman

life or theenvironment.Temporal constraints The real-timeattributessuchasdeadlines,jitter, response

time,worstcaseexecutiontime,etc.Security The ability of a software systemto resist malicious in-

tendedactions.Availability The probability of a systemfunctioningcorrectly at any

giventime.

Table3.1: Functionalqualityattributes

Testability Theability to easilyprovesystem’scorrectnessby testing.Reusability Theextentto which thearchitecturecanbereused.Portability The ability to move a softwaresystemto a differenthardware

and/orsoftwareplatform.Maintainability Theability of a systemto undergoevolutionandrepair.Modifiability Sensitivity of the systemto changesin one or several compo-

nents.

Table3.2: Non-functionalqualityattributes

new partscould result in degradedperformanceof the upgradedsystem. In sucha sce-nario,additionalefforts would have to bemadeto ensurethat thesystemmeetstheinitialperformancerequirements.

3.1.3 The futur e of CBSE: fr om the componentto the composition

So far we have examinedsoftware componentsand software architectures,as they arethe core of the component-basedsoftware development. However, the researchin thecomponent-basedsoftwareengineeringcommunityincreasinglyemphasizescompositionof thesystemasthewayto enabledevelopmentof reliablesystems,andthewayto improvereuseof components.In this sectionwe give an introductionto new techniquesdealingwith theproblemof systemcomposition.Figure3.2provideshierarchicalclassificationofcomponent-basedsystems[69].

Component-basedsystemson thefirst level, e.g.,CORBA, COM andJavaBeans,rep-resentthefirst generationof component-basedsystems,andarereferredto as“classical”component-basedsystems.Frameworksandstandardsfor componentsof todayin industryprimarily focuson classicalcomponent-basedsystems.Componentsareblackboxesandcommunicatethroughstandardinterfaces,providing standardservicesto clients,i.e., thecomponentis standardized.Standardizationeasesaddingor exchangingcomponentsin thesoftwaresystem,andimprovesreuseof components.However, classicalcomponent-basedsystemslack rulesfor thesystemcomposition,i.e.,compositionrecipe.

Thenext level representsarchitecturesystems,e.g.,RAPIDE[66] andUNICON [115].Thesesystemsprovideanarchitecturaldescriptionlanguage(ADL). ADL is usedto spec-ify architectureof thesoftwaresystem.In anarchitecturesystem,componentsencapsulateapplication-specificfunctionality, and are also black boxes. Componentscommunicatethroughconnectors[3]. A connectoris aspecificmodulethatencapsulatescommunicationbetweenapplication-specificcomponents.This givessignificantadvancementin thecom-positionascomparedto classicalcomponent-basedsystems,sincecommunicationandthearchitecturecanbevariedindependentlyof eachother. Thus,architecturesystemsseparate


Classical component-based systems

Systemswith composition operators

Composition systems

Architecture

Aspect

Black box component

Grey box component

Composition language

systems

systems

Figure3.2: Classesof component-basedsystems

threemajoraspectsof thesoftwaresystem:architecture,communication,andapplication-specificfunctionality. Oneimportantbenefitof anarchitecturesystemis possibilityof earlysystemtesting.Testsof thearchitecturecanbeperformedwith “dummy” componentslead-ing to the systemvalidationin the early stageof the development.This alsoenablesthedeveloperto reasonaboutthesoftwaresystemat anabstractlevel. Classicalcomponent-basedsystems,adoptedin the industry, canbeviewedasa subsetof architecturesystems(whicharenotyet adoptedby theindustry),asthey arein factsimplearchitecturesystemswith fixedcommunication.

The third level representsaspectsystems,basedon aspect-orientedprogramming(AOP)paradigm[51]. Aspectsystemsseparatemoreaspectsof thesoftwaresystemthanarchitecturesystems.Besidearchitecture,application,andcommunication,aspectsof thesystemcanbe separatedfurther: representationof data,control-flow, andmemoryman-agement.Temporalconstraintscanalsobe viewed asan aspectof the softwaresystem,implying thata real-timesystemcouldbedevelopedusingAOP[13]. Only recently, sev-eralprojectssponsoredby DARPA (DefenseAdvancedResearchProjectsAgency), havebeenestablishedwith anaim to investigatepossibilitiesof reliablecompositionof embed-dedreal-timesystemsusingAOP[92]. Aspectsareseparatedfrom thecorecomponentandarerecombinedautomatically, throughprocesscalledweaving. In AOP, a corecomponentis consideredto be a unit of system’s functionaldecomposition,i.e., application-specificfunctionality[51]. Weaversarespecialcompilerswhichcombineaspectswith corecompo-nentsat so-calledjoint pointsstatically, i.e.,at compiletime,anddynamicallyat run-time.Weaving breakesthecorecomponent(at joint points)andcross-cutsaspectsinto thecom-ponent,andtheweaving processresultsin anintegratedcomponent-basedsystem.Hence,corecomponentsarenolongerblackboxes,ratherthey aregrey boxesasthey arecross-cutwith aspects.However, aspectweaverscanbeviewedasblackboxessincethey arewrittenfor a specificcombinationof aspectsandcorecomponents,andfor eachnew combinationof aspectsandcorecomponentsa new aspectweaver needsto be written. Comparedtoarchitecturesystems,aspectsystemsaremoregeneralandallow separationof variousad-ditionalaspects,thus,architecturesystemscanbeviewedasa subsetof theclassof aspectsystems.Having differentaspectsimprovesreusabilitysincevariousaspectscanbecom-bined(reused)with differentcorecomponents.The maindrawbackof aspectsystemsisthat they arebuilt on speciallanguagesfor aspects,requiringsystemdevelopersto learntheselanguages.

At the fourth level are systemsthat provide compositionoperatorsby which com-ponentscan be composed.Compositionoperatorsare comparableto component-basedweaver, i.e., a weaver that is no longera blackbox,but is alsocomposableout of compo-nents,andcanbe, in a sense,re-composedfor every combinationof aspectsandcompo-nents,furtherimproving thereuse.Subject-orientedprogramming(SOP)[83], anexampleof systemswith compositionoperators,providecompositionoperatorsfor classes,suchasmerge (mergestwo views of a class),equate(mergestwo definitionof classesinto one),etc. SOPis a powerful techniquefor compositionalsystemdevelopment,sinceit provides


asimplesetof operatorsfor weaving aspectsor views,andSOPprogramssupportthepro-cessof systemcomposition.However, SOPfocuseson compositionanddoesnot provideany specialcomponent.Componentsin SOPareC++ classes.

Finally, at the last level aresystemsthat containfull-fledgedcompositionlanguage,andarecalledcompositionsystems.A compositionlanguageshouldcontainbasiccom-positionoperatorsto compose,glue,adopt,combine,extendandmergecomponents.Thecompositionlanguageshouldalsobe tailorable,i.e., component-based,andprovide sup-port for composing(different)systems,in the large. Invasive softwarecomposition[69]is oneapproachthataimsto provide a languagefor thesystemcomposition.Componentsin the invasive compositiontechniquearemoregeneral.The componentmay consistofa setof arbitraryprogramelements,andis calleda box [69]. Boxesareconnectedto theenvironmentthroughvery generalconnectionpoints, calledhooks. Compositionof thesystemis encapsulatedin compositionoperators(composers),which transformthe com-ponentwith hooksinto a componentwith code.Theprocessof systemcompositionusingcomposersis moregeneralthanaspectweaving andcompositionoperators,sinceinvasivecompositionallowscompositionoperatorsto becollectedin librariesandto beinvokedbythecompositionprograms(recipes)in acompositionlanguage.Composerscanberealizedin any programmingor specificationlanguage.Invasivecompositionsupportssoftwarear-chitecture,separationof aspects,andprovidescompositionreceipts,allowing productionof familiesof variantsystems[68]. Reuseis improved,ascomparedto systemsin thelowerlevels,sincecompositionrecipescanalsobereused,leadingto easyreuseof componentsandarchitectures.An exampleof thesystemthatsupportsinvasive compositionis COM-POST[23]. However, COMPOSTappearsto bemoresuitablefor complex non-real-timesoftwaresystems,ratherthansystemsthat have limited amountof resourcesandenforcereal-timebehavior. Also, the systemis not generalenough,sinceit only supportsJavasource-to-sourcetransformations.

The given overview illustratescurrentefforts to enableefficient systemcomposition.In particular, techniquesat the last threelayers in figure 3.2 focus on the compositionprocess. Component-basedsystemsthat we investigatein more detail in the followingsectionsdonotcoverall classesof component-basedsystemsshown in figure3.2.Systemsweinvestigaterepresentcurrentcomponentizationeffortsin thedatabaseandtheembeddedreal-timecommunity, andaremainly subsetsof component-basedsystemsin thefirst twolayersin figure3.2.

3.2 Component-baseddatabasesystems

A databasesystemconsistsof asoftwarecalleddatabasemanagementsystem(DBMS) andoneor moredatabasesmanagedby theDBMS [97]. Essentialpartof thedatabasesystemis theDBMS.

In thissectionwefocusondatabasesystemsthatcanbepartiallyor completelyassem-bledfromapre-definedsetof components,i.e.,thatexploit component-baseddevelopment.Wereferto thesesystemsascomponent-baseddatabasesystems.First,themaingranularitylevel of a componentusedfor thecompositionof a databasesystemis established.Then,in sectionsthat follow, the classificationanddetail analysisof existing component-baseddatabasesystemsis given. Of a particularinterestis to show how andto which degreedifferentcomponent-baseddatabasesystemsallow customization,i.e., to which degreeadesignercantailor thedatabasesystemfor aparticularapplication.

3.2.1 Granularity level of a databasecomponent

In general,two maingranularitylevelsof a databasecomponentin component-basedsys-temsexist:� DBMS (databasesystem)asacomponent,and


DBMS1 DBMS2 DBMS3

Database Database Database

FDBMS

DBS1 DBS2 DBS3

FDBS

Figure3.3: Componentsin FDBS

inte

rfac

e

inte

rfac

e

configuration

stub/proxy

configuration

stub/proxy

status database (SDB)

data flow data flow

control flow

component infrastructure (COM)

component component

ARTDBMS

Figure3.4: Component-basedsystemwith ARTDBSasacomponent

C partof theDBMS asa component.

The formercomponenttype is not exactly a component-basedsolutionof a databasesys-tem,ratherDBMS usedasa componentin largercomponent-basedsystems.For example,a databasesystemmaybeviewedasa componentin a federateddatabasesystem(FDBS),which is a collection of cooperatingbut autonomousdatabasesystems[97]. Databasesystemsarecontrolledandmanagedby a softwarecalledfederateddatabasemanagementsystem(FDBMS) (seefigure3.3). Hence,thedatabasesystemis not madeout of compo-nentsbut is rathera componentof a larger component-basedfederateddatabasesystem.In this respect,CORBA canbeusedto achieve interoperabilityamongDBMSsin a mul-tidatabaseapproach.CORBA enablesthebasicinfrastructurethatcanbeusedto providedatabaseinteroperability[30]. WhenusingCORBA asa middlewarein a multidatabasesystem,theDBMS itself is not customizable;rathertheDBMS is a component(CORBAobject)registeredto the CORBA infrastructure. Anotherexampleof a databasesystemusedasa componentis anactive real-timedatabasesystem(ARTDBMS) thatcanbeusedas a componentin an architecturewith standardizedcomponents[76] (seefigure 3.4).In this solution, infrastructureof the componenttechnology(in this caseCOM) is usedfor separatingtheexchangeof control informationbetweencomponentsanddatatransfervia the statusdatabasesystem. The statusdatabasesystemis implementedasan activereal-timedatabasesystemandcontainsall the informationaboutthe currentstatusof anapplicationthat is usedby at leasttwo differentcomponents.This architecturesupportsapplicationcompositionout of components,andaimsto enableaddingor removing com-ponentswithout additionalprogramming.A componentin this systemis assumedto beaself-contained,configurablebinarysoftwarepackagewith preciselydefinedstandardizedinterfacesthatcanbecombinedwith othercomponents.Time consistency of saveddata,in additionto thelogical consistency, is ensuredin thecomposedsystemby having a real-time database.However, this typeof component-basedsolutionis applicablefor tailoringcomponent-basedsystemswheretimeconsistency of datais neededandnot for tailoringa


databasesystem.A databasesystemin thissolutionis amonolithicsystem,andchangestothattypeof systemsarenoteasilydone.

It is our opinion that moreemphasisand detailedanalysisis neededfor the secondcategory of databasecomponents,i.e., a componentbeinga part of the DBMS. DBMSmadeoutof componentswouldindeedbeanactualcomponent-basedsolutionof adatabasesystem.We motivatethis furtherin thefollowing section.

3.2.2 Componentvs. monolithic DBMS

Databasesystemsare today usedin variousapplicationareas,suchas telecommunica-tions [1], e-commerce[37, 2], embeddedsystems[80], real-timesystems[44], etc. Ex-pansionof databasesystemsto new applicationdomainsunavoidably resultsin new re-quirementsa databasesystemmustfulfill [29]. ConsiderInternetapplicationswheredatais accessedfrom avarietyof sourcessuchasaudio,video,text, imagedata,etc.Therefore,many web-basedapplicationsrequirea databasethatcanmanagevide varietyof differenttypesof data. Also, new application-specificdatatypeshave emergedthat arenot sup-portedby traditionaldatabases.Examplesof non-standarddatatypesaretemporaldata,spatialdata,multimediadata.Hence,DBMSsarerequiredto providesupportfor modelingandstoringthesenew, non-standard,datatypes[82]. Broadvarietyof datafrom differentdatasourcesmakesheterogeneousdatamanagementa very importantchallenge,sincealargenumberof applicationsrequirea databasethat providesthemwith theuniform andhomogeneousview of theentiresystem[21]. Businesscomputingenvironmentposesad-ditional setof requirementson databasesystems,suchasrapid applicationdevelopment,andminimizedcomplexity both for endusersanddevelopers[81]. In addition,it is com-mon thata company needsto producea databasesystemfor a biggerspectraof differentapplicationareas.Suchscenariosrequirecost-effective solutionsof DBMSs. During thedevelopmentof a DBMS, it is very hardto exactly predictin which directionsystemwillevolve, i.e., which additionalfunctionalitythedatabasesystemwill have to provide in thefuture. Thus,a DBMS mustbedevelopedsuchthat it is opento new, future,uses.Havinga databasethatcanbeextendedwith new functionalityor modifiedduring its life-time isbeneficialbothfor usersanddatabasevendors.

Meetingnew requirementsimpliesthattraditional,monolithicDBMSmustbeextendedto includenew functionality. However, addingfunctionality to a monolithic DBMS hasseveraldrawbacks[29]:

D Partsin themonolithicDBMS areconnectedto oneanotheranddependenton oneanotherto suchadegreethatchangesmadein onepartof theDBMS structurewouldleadto a dominoeffect in otherpartsof themonolithicsystem,i.e., extensionsandmodificationsarenoteasilydone.

D Adding new functionality in themonolithicsystemwould resultin increasedcom-plexity of aDBMS andin turn, increasedmaintenancecostsof thesystem.

D Applicationswould have to pay performanceandcostpenaltyfor usingunneededfunctionality.

D Systemevolutionwouldbemorecomplex, sinceaDBMS vendormightnothavetheresourcesor expertiseto performsuchextensionsin a reasonableperiodof time.

Oneapproachto solve theseproblemscould be componentizationof a DBMS [29]. AcomponentDBMS (CDBMS),alsocalledacomponent-baseddatabasesystem,allowsnewfunctionality to be addedin a modularmanner, that is, systemcanbe easilymodifiedorextendedby addingor replacingnew components.Componentsandtheir interconnectionsshouldbewell-definedin theCDBMS architecture.Thearchitecturedefinesplacesin thesystemwherecomponentscanbeadded,thus,specifyingandrestrictingthewaysin whichDBMS canbecustomized.Ideally, applicationswouldno longerhave to payperformance


andcostpenaltyfor usingunneededfunctionalitybecauseunnecessarycomponentsdonothave to beaddedto a system.However, it hasto benotedthatcomponentsneededby theapplicationmightcontainsomeunnecessaryfunctionalitythemselves.Also, complexity ofthesystemandmaintenancecostwould bereducedif thesystemcouldbecomposedonlyout of components(functionality)applicationneeds.Finally, evolution of sucha systemwouldbesimplified,sincenew componentscanbepluggedinto thesystemwithouthavingto recompile(or shutdown) theentiresystem.Of course,this impliesthatnew componentshavepreviouslybeentestedandhavea verifiedbehavior.

Note thatcomponent-baseddatabasesystemsarefacedwith thesamechallengesasacomponent-basedtechnologyin general,suchasperformancedegradationof acomponent-basedsystemas comparedto a monolithic system,complex developmentprocessof areusablecomponent,etc.

3.2.3 Componentsand architecturesin different CDBMS models

Fourdifferentcategoriesof CDBMSshavebeenidentifiedin [29]:

D ExtensibleDBMS. The purposeof systemsfalling into this category is to extendexisting DBMS with non-standardfunctionality, e.g.,Oracle8i [82], Informix Uni-versalServer with its DataBladetechnology[48], SybaseAdaptive Server [81] andDB2 UniversalDatabase[21].

D Databasemiddleware. Thepurposeof systemsfalling into this category is to inte-grateexisting datastoresinto a databasesystemandprovide usersandapplicationswith a uniform view of theentiresystem,e.g.,Garlic [22] andDiscoveryLink [42],andOLE DB [74], .

D DBMS service. The purposeof systemsfalling into this category is to providedatabasefunctionality in standardizedform unbundled into services,e.g., COR-BAService[84].

D ConfigurableDBMS. Thepurposeof systemsfalling into this category is to enablecompositionof anon-standardDBMS outof reusablecomponents,e.g.,KIDS [38].

Sectionsthat follow focus on characteristicsof systemsin eachof thesefour differentcategories.

3.2.4 ExtensibleDBMS

Thecoresystemin this groupis formedfrom fully functionalDBMSsthat implementallstandardDBMS functionality [29]. Non-standardfeaturesandfunctionality not yet sup-portedcanbe pluggedinto this DBMS (seefigure 3.5). Componentsin this category ofCDBMSsarefamiliesof baseandabstractdatatypesor implementationsof someDBMSfunctionsuchasnew index structures.Thearchitecturedefinesanumberof plugsthatcom-ponentscanuseandformulatesexpectationsconcerninginterfacesthat componentmustmeetin orderto beintegratedsuccessfully.

Oracle8i

Oracle8i allowsdevelopersto createtheirown application-domain-specificdatatypes[82].Capabilitiesof theOracledataserver canbeextendedby meansof datacartridgeswhich,in this case,representcomponentsin theOracle8i architecture.Datacartridgesarestoredin anappropriatelibrary for reusability. A datacartridgeconsistsof oneor moredomain-specifictypesandcanbe integratedwith theserver. For example,a spatialdatacartridgemayprovidecomprehensivefunctionalityfor a geographicaldomainsuchasbeingabletostorespatialdata,performproximity/overlapcomparisonson suchdata,andalsointegrate


DBMS

Component

Figure3.5: Theprincipleof systemsfalling into anextensibleDBMS category

Server execution

Query processing

Data indexing

Type system

Data cartridge

Database and processing extensibility services

Oracle8 universal data server

Extensibility interface

Figure3.6: TheOracleextensibilityarchitecture

spatialdatawith theserverby providing theability to index spatialdata.In additionto thespatialcartridge,text, imageandvideodatacartridgecanbeintegratedin thearchitecture.Datacartridgescanbeintegratedinto a systemthroughextensibility interfaces.Therearethreetypesof theseinterfaces:DBMS anddatacartridgeinterfaces,usedfor communi-cationbetweencomponentsandtheDBMS, andserviceinterfacesusedby thedevelopersof a component.In theOracle8i architecture,datacartridgescanprovide their own imple-mentationof databaseservicessuchasstorageservice,queryprocessingservice,servicesfor indexing, queryoptimization,etc. Theseservicesareextendedby the datacartridgeimplementationandarecalleddatabaseextensibilityservices(seefigure3.6).Extensibilityof adatabaseservicecanbeillustratedwith theexampleof thespatialdatacartridge,whichprovidestheability to index spatialdata,andconsequentlyextendsindexing serviceof theserver. Configurationsupportis providedfor thedevelopment,packaginganddeploymentof datacartridges,asillustratedin figure3.7. TheOracleDesignerfamily of productshasmodelingand codegenerationtools which enabledevelopmentof datacartridges. TheCartridgePackagermodule,part of the OracleEnterpriseManagerfamily, assistsdevel-operin packagingdatacartridgesinto installableunits. Components(datacartridges)aretheninstalledinto theserverby endusersusingtheOracleInstaller.

Thearchitectureof the Oracle8i is fixed anddefinesthe placeswhereextensionscanbe made,i.e., componentsadded,as well as interfacesto thesecomponents.Designer


Oracle Cartridge Packager

LibraryBuilder (code)

InstallerOracle Universal

Driver editor

Cartridge developers

End-users

Cartridge developers

Administrators-customization

Stage:

-components-libraries

Libraries

Drivers

Logs

Component definition

Figure3.7: Packagingandinstallingcartridges

is allowed to customizedatabaseserver only by plugging-in new components,i.e., thesystemhaslow degreeof tailorability. Providedconfigurationsupportis adequate,sincethesystemalreadyhasa fixedarchitectureandpre-definedextensions,andthatextensionsareallowedonly in well-definedplacesof thearchitecture.Thistypeof systememphasizeson satisfyingonly onerequirement- handlingnon-standarddatatypes. If a systemneedsto provide another(non-standard)service besidemanagingabstractdata types, or ifsomeinternalpart of the infrastructureneedsto be changed,we arefacedwith thesamedifficultiesaswhenusingmonolithicsystems(seesection3.2.2).Also, this typeof systemcannot easilybe integratedin all applicationdomains,e.g.,real-timesystem,sincethereis noanalysissupportfor checkingtemporalbehavior.

The concept of the Informix DataBladetechnology, DB2 Universal Database,andSybaseAdaptive Server is the sameas the above describedconceptof the extensibleOracle8i server architecturefor manipulationof non-standarddata types. Moreover,conclusionsmadefor the Oracle8i with respectto configurationtools, tailorability forsatisfyingonly onerequirement(handlingnon-standarddatatypes),andlack of real-timepropertiesand analysistools, are applicablefor all systemsthat fall in this category,i.e., extensibleDBMS. Therefore,analysisof the Informix DataBladetechnology, DB2UniversalDatabase,andSybaseAdaptiveServer is keptveryshort.

Inf ormix DataBladetechnology

DataBlademodulesarestandardsoftwaremodulesthatcanbepluggedinto the InformixUniversalServer databaseto extendits capability [48]. DataBlademodulesarecompo-nentsin the Informix UniversalServer. Thesecomponentsare designedspecificallytoenableusersto store,retrieve,update,andmanipulateany domain-specifictypeof data.In-formix allowsdevelopmentof DataBlademodulesin Java,C,C++,J++or storedprocedurelanguage(SPL) by providing the applicationprogramminginterface(API) for thoselan-guages.SameasOracle,Informix hasprovidedlow degreeof tailoring,sincethedatabasecan only be extendedwith standardizedcomponentsthat enablemanipulationof non-standarddatatypes. Configurationsupportis provided for developmentand installationof DataBlademodules,e.g.,BladeSmith,BladePack,andBladeManager.


DB2 UniversalDatabase

As previously describeddatabaseservers, DB2 Universal Database[21, 28] also al-lows extensionsin thearchitectureto provide supportfor comprehensive managementofapplication-specificdatatypes. Application-specificdatatypesandnew index structuresfor thatdatatypesareprovidedby DB2 RelationalExtenders,reusablecomponentsin theDB2 UniversalDatabasearchitecture.ThereareDB2 RelationExtenderfor text (text ex-tender),image(imageextender),audioandvideo(extender).Eachextenderprovidestheappropriatefunctionsfor creating,updating,deleting,andsearchingthroughdatastoredin its datatype. An extenderdeveloperskit with wizardsfor generatingandregisteringextendersprovidessupportfor thedevelopmentandintegrationof new extendersin DB2UniversalDatabase.

SybaseAdaptiveServer

Similar to otherdatabasesystemsin thiscategory, theSybaseAdaptiveServer [81] enablesextensionsin its architecture,calledSybase’sAdaptiveComponentArchitecture(ACA), toenablemanipulationof application-specificdatatypes.Componentsthatenablemanipula-tion of thesedatatypesarecalledSpecialityDataStores,e.g.,specialitydatastoresfor text,time seriesandgeospatialdata. The SybaseAdaptive Server differs from otherdatabasesystemsin theextensibleDBMS category in thatit providesasupportfor standardcompo-nentsin thedistributedcomputingenvironment,asthenameof theACA architectureindi-cates.Throughopen(Java) interfacesSybase’s Adaptive ComponentArchitecture(ACA)providesmechanismsfor communicationwith otherdatabaseservers. In additionof pro-viding the interoperabilityof databaseserver, Sybaseenablesinteroperabilitywith otherstandardizedcomponentsin thenetwork, suchasJavaBeans.

3.2.5 Databasemiddleware

Theaimof systemsfalling into thiscategoryis to integrateexistingdatastores,into acom-mon DBMS-styleframework [29]. A CDBMS actingasa middlewarebetweendifferentdatastoresandtheapplicationof integrationprovidesusersandapplicationswith auniformand integratedview of the entiresystem(seefigure 3.8). In this model the architectureintroducesa commonintermediateformat into which the local dataformatscanbetrans-lated. Componentsin this category of CDMSsperformthis kind of translation.Commoninterfacesandprotocolsdefinehow thedatabasemiddlewaresystemandthecomponentsinteract.Components,alsoknown aswrappers,arelocatedbetweentheDBMS andeachdatasource. Eachcomponentmediatesbetweenthe datasourceand the DBMS, i.e., itwrapsthedatasource.

Garlic

Garlic [22] is an IBM researchprojectthat aimsto integrateandunify datamanagedbymultiple,disparate,datasources.Theprimarily goalof theGarlicprojectis to build a het-erogeneousmultimediainformationsystemcapableof integratingdatafrom a broadrangeof datasources.Eachdatasource(alsoknown asa repository)hasits own datamodel,schema,programminginterfaceandquerycapability. Datamodelsfor thesesourcesvarywidely, e.g.,relational,object-oriented,a simplefile-system,anda specializedmolecularsearchdatamodel. TheGarlic datamodelis basedon theObjectDatabaseManagementGroup(ODMG) standard.Garlic canprovide accessto a datasourceonly if appropriatewrapperfor thatdatasourceexists. Thus,associatedwith eachdatasourceis a wrapper, areusablecomponentin theGarlic architecture(seefigure3.9). In additionto datasourcescontaininglegacy data,Garlicallowsusersto createtheirown datasource,i.e.,datasourcefor Garlic complex objects.Wrappersfor new datasourcescanbe integratedinto anex-isting Garlic databasewithout disturbinglegacy applications,otherwrappersandGarlic


Application1 Application2 Application n

WrapperWrapper Wrapper

Figure3.8: Principleof systemsfalling into a DBMS middlewarecategory

applications.Garlicapplicationsinteractwith queryservicesandrun-timesystemthroughGarlic’sobjectquerylanguageandaC++API. Thequeryprocessordevelopsplansto effi-ciently decomposequeriesthatspanmultiple datasourcesinto piecesthat individual datasourcescanhandle.As shown in figure3.10wrapperprovidesfour majorservicesto the

Application Application

Wrapper

objectsComplex

Query processor

GARLIC

repository

Wrapper

archiveImage

repository

WrapperWrapper

repositoryData

repositoryData

Figure3.9: TheGarlicarchitecture

Garlicsystem[95]:

1. A wrappermodelsthecontentsof its datasourceasGarlicobjects,andallowsGarlicto retrievereferencesto theseobjects.TheGarlicDataLanguage(GDL), avariantofthe ODMG’s ObjectDescriptionLanguage(ODMG-ODL), is usedto describethecontentof a datasource. Interfacesthat describethe behavior of objectsin a datasource(repository)areknown collectively asa repositoryschema.Repositoriesareregisteredaspartsof theGarlicdatabaseandtheir individual repositoryschemasaremergedinto theglobalschemathatis presentedto Garlicusers.

2. A wrapperallows Garlic to invoke methodson objectsandretrieve their attributes.Method invocationcan be generatedby Garlic’s executionengine,or by a Garlicapplicationthathasobtaineda reference(eitherasa resultof a queryor by lookinguprootobjectby name).

3. A wrapperparticipatesin queryplaningwhena Garlic queryprocessorrangesovermultiple objectsin the repository. The goal of the query planningis to develop


alternativeplansfor answeringa query, andthento choosethemostefficientone.

4. A wrapper’s finaleserviceis to participatein plan translationandqueryexecution.A Garlic queryplanis presentedasa treeof operators,suchasFILTER,PROJECT,JOIN, etc. The optimizedplan mustbe translatedinto a form suitablefor execu-tion. During every execution,thewrappercompletesthework which wasassignedto it in thequeryplaningphase.Operatorsaremappedinto iterators,andeachwrap-perprovidesa specializedIterator subclassthatcontrolsexecutionof theworkdescribedby oneof its plans.

Hotel object

requestWork

Method invocation

Query execution

Wrapper

Data source

Modeling data

Execution planas objects

Query planning

Query plan

Wrapperplan

location cityname class daly_rate

Wrapperplan

get_class()

class=5

Iterator::advance()

Garlic

Figure3.10:Servicesprovidedby thewrapper

Having definedservicesthat a wrapperprovidesto the Garlic architecture,simplifiesthedevelopmentprocessof thewrapper. A designerof thewrapperneedsto performspe-cific tasksto ensurethata wrapperprovidesa certainservice.After definingthewrapperservices,i.e., performingtasksspecificto eachservice,the wrapperdesignerhasa finaltaskof packagingwrittenpiecesin acompletewrapper. To keepthecostof communicationbetweentheGarlicandawrapperlow, thewrappercodeis packagedasadynamicallyload-ablelibrary andresidesin thesameaddressspace.Every wrapperincludesinterfacefilesthatcontainoneor moreinterfacedefinitionswritten in GDL, environmentfiles thatcon-tainname/valuepairsto encoderepository-specificinformationfor useby thewrapper, andlibrariesthatcontaindynamicallyloadablecodeto implementschemaregistration,methodinvocation,andthequeryinterface.Decomposinga wrapperinto interfacefiles, libraries,andenvironmentfiles givesthe designerof a wrapperadditionalflexibility whendesign-ing a wrapperfor a particularrepositoryor family of repositories.For eachrepository, aninterfacefile describestheobjectsin thecorrespondingdatabase,andanenvironmentfileencodesthenameof thedatabasetowhichthewrappermustconnect,thenamesof therootsexportedby therepositoryandthetablesto which they arebound,etc. Wrapperdesignersareprovidedwith alibrary of schemaregistrationtools,query-plan-constructionroutines,afacility to gatherandstorestatistics,andotherusefulroutinesin orderto automatewritingwrappersasmuchaspossible.

To conclude,the well-definedGarlic wrapperarchitecturewith wrapperservicesandtasksfor a wrapperdesignerassociatedwith eachservice,enableseasyand fast (cost-effective)developmentof wrappers.Thearchitecturealsoprovidesstability in a sensethatnew wrapperscanbe easily installedinto an existing systemwithout effecting the otherwrappersor thesystemitself. TheGarlic systemis suitablefor largedistributeddatabasesystems. In termsof tailorability, one can observe that the Garlic wrapperarchitectureprovidesamoderatedegreeof customization,andcanbetailoredfor differentapplications,providedthatappropriatewrappersneededby theapplicationexist or aredeveloped.


However, theGarlic cannotbeusedwith easein everyapplicationdomain,e.g.,a real-timedomain,wherecorrectnessof asystemdependsonthetimewhenresultsareproduced.TheGarlicwrapperarchitectureunifiesaccessto differentdatasource,but it is not clearifsuchaccesscanbeguaranteedin a timely predictablemanner.

DiscoveryLink

DiscoveryLink [42] is a commercialmiddlewareDBMS, completelybasedon the Garlictechnology, andincorporatedinto the IBM’ s DB2 databaseserver. Discovery Link inte-grateslife sciencedatafrom heterogeneousdatasources.As in Garlic, components,i.e.,wrappers,in the DiscoveryLink areC++ programs,packagedassharedlibraries. Wrap-perscanbecreateddynamically, allowing a numberof datasourcesto grow (andshrink)on the fly. Most of the wrappersin DiscoveryLink are requiredto have only minimumfunctionality. In particular, the wrappermustbe ableto returnthe tuplesof any relationthat it exports. The wrapperarchitectureandthe notion of having reusablecomponentsthatcanbeaddedor exchangedmakesDiscoveryLink uniqueamongcommercialdatabasemiddlewaresystemsthatprovidequeryacrossmultiple relationalsources,e.g.,DataJoiner[24] andSybase[47].

OLE DB

OLE DB [14, 15] is designedasa Microsoft ComponentObjectModel (COM) interface.COM providesa framework for integratingcomponents.This framework supportsinter-operabilityandreusabilityof distributedobjectsby allowing developersto build systemsby assemblingreusablecomponentsfrom differentvendorswhichcommunicatevia COM.COM definesanapplicationprogramminginterface(API) to allow for thecreationof com-ponentsfor usein integratingcustomapplicationsor to allow diversecomponentsto inter-act. However, in orderto interact,componentsmustadhereto a binarystructurespecifiedby Microsoft. As long ascomponentsadhereto this binary structure,componentswrit-ten in differentlanguagescaninteroperate.COM supportsconceptssuchasaggregation,encapsulation,interfacefactoring,inheritance,etc.

OLEDB is aspecificationfor asetof dataaccessinterfacesdesignedto enableavarietyof datastoresto work together[74]. OLE DB providesa way for any typeof datastoretoexposeits datain a standardandtabular form, thusunifying dataaccessandmanipulation.In Microsoft’s infrastructurefor component-basedcomputing,a componentis thoughtofas[74]:

”. . . thecombinationof bothprocessanddatainto asecure,reusableobject.. . ”

andasa result,both consumersandprovidersof dataaretreatedascomponents.A dataconsumercanbe any pieceof the systemor the applicationcodethat needsaccessto abroadrangeof data.In contrast,dataprovidersarereusablecomponentsthatrepresentdatasource,suchasMicrosoftODBC,MicrosoftSQLserver, Oracle,MicrosoftAccess,whichareall standardOLE DB providers. Thus,OLE DB enablesbuilding component-basedsolutionsby linking dataprovidersanddataconsumersthroughprovidingservicesthataddfunctionality to existing OLE DB dataandwherethe servicesaretreatedascomponentsin thesystem(seefigure3.11).Thearchitecturein figure3.11is calledtheUniversalDataAccess(UDA) architecture.It is possibleto developnew, custom,dataprovidersthatreuseexistingdataprovidersastheunderlyingcomponentoracomponentbuildingblockof morecomplex (dataprovider) components.This enablesdevelopersto exposecustomviews ofdataandfunctionalitywithout rewriting theentiredatastoreor theaccessmethods.Notethat only reusablecomponentsin this systemaredataproviders. Thesecomponentscanbeviewedaswrappersin theUDA architecture.Note thatarchitecturalrequirementsgetmorecomplex ascomparedto the systemsin the extensiblecategory. In contrastto theGarlic wrapperarchitecture,OLE DB allows theUDA architectureto have morevariable


OLE DB

CO

M/D

CO

M

OLE DB

ActiveX Data Objects (ADO)

Application or tool

Microsoft transaction server

SERVICES

CONSUMERS

DATAPROVIDERSOLAP EMAIL ISAMSPATIAL

Cursor engine Distributed query engine

Relational query engine

Figure3.11:TheUniversalDataAccess(UDA) architecture

Application

ServiceServiceService

Platform

Figure3.12:Theprincipleof systemsfalling into aDBMS servicecategory

partsandmorecustomizationof thesystemis allowed. TheUDA architectureprovidesacommonformatinto whichall local dataformatscanbetranslatedaswell asstandardizedinterfacesthat enablecommunicationbetweenthe applicationsanddifferentdatastores,i.e.,OLE DB interface.

AlthoughOLE DB providesunifiedaccessto dataandenablesdevelopersto build theirowndataproviders,thereis nocommonimplementationoneithertheprovideror consumersideof the interface[16]. Compatibility is provided only throughthe specificationanddevelopersmust follow the specificationexactly to make interoperablecomponents,i.e.,adequateconfigurationsupportfor this is not yet provided. To make up for inadequateconfigurationsupport,Microsoft hasmadeavailable,in Microsoft’s SoftwareDeveloper’sKit (SDK), teststhatvalidateconformanceof thespecification.However, analysisof thecomposedsystemis missing.

OLE DB is not applicablefor a real-timedomain,sincetemporalbehavior is not of animportance.Additionally, OLE DB is limited with respectto softwareplatforms,sinceitcanonly beusedin Microsoftsoftwareenvironments.

3.2.6 DBMS service

In this typeof a CDBMS, the DBMS andrelatedtasksareunbundledinto services[29],andasa resultthemonolithicDBMS is transformedinto a setof stand-aloneservices(seefigure3.12).Applicationsno longeroperateon full fledgedDBMSs,but insteadusethoseservicesasneeded.Servicesaredefinedin a commonmodelor languageandareimple-mentedusingacommonplatformin orderto rendertheserviceimplementationsexchange-ableandfreely combinable.Systemsin this category have componentsthat aredatabaseservicesandtheir implementations.CORBA with its CORBAservicescouldbeanexam-ple of a systemfalling into this category. Although thereareno DBMS servicesystemsthatareimplementedsolutions,theobjectivesof this category canbeillustratedthroughaCORBAservicesexample-system.


DBMS

Figure3.13:Theprincipleof systemsfalling into aconfigurableDBMS category

CORBAservices

OnesingleDBMS couldbeobtainedby gluing togetherCORBAserviceswhich arerele-vant for databases,suchastransactionservice,backupandrecovery service,concurrencyservice.CORBAservicesareimplementedonthetopof theObjectRequestBroker(ORB).Serviceinterfacesaredefinedusingthe InterfaceDefinition Language(IDL) [30]. In thisscenarioa componentwouldbeoneof thedatabaserelevantCORBAservices.Thiswouldmeanthatapplicationscouldchoosefrom a setof stand-aloneservicesthoseservices,i.e.,components,which they need. However, this approachis (still) not viable becauseit re-quireswriting significantamountof gluecode. In addition,performanceoverheadcouldbeaproblemdueto theinability of anORBto efficiently dealwith fine-granularityobjects[84]. Also, an adequatevalue-addedframework that allows developmentof componentsanduseof thesecomponentsin otherapplicationsis still missing.Configurationaswell asanalysistoolsto supportthisprocessaremissing.

3.2.7 Configurable DBMS

Onestepfurtheraway from theDBMS servicecategoryof CDBMSs,wherethesetof ser-viceshave beenstandardizedandfixed,is a configurableDBMS category thatallows newDBMSpartstobedevelopedandintegratedinto aDBMS(seefigure3.13)[29]. Here,com-ponentsareDBMS subsystemsdefinedin theunderlyingarchitecturewhich is no longerfixed.

KIDS

The KIDS (Kernel-basedImplementationof DatabasemanagementSystems) [38] ap-proachto constructingCDBMSs is an interestingresearchproject at the University ofZürich,sinceit offersa methodical,open,andcost-effectiveconstructionof a DBMS. Theapproachoffershigh level of reusability, wherevirtually any resultobtainedin a previoussystemconstructionis reused(designs,architectures,specifications,etc.).Thearchitectureis well-defined,andoncecreatedit canbesaved in a library andreused.TheDBMS ar-chitectureis basedon the broker/servicemodel, i.e., it consistsof brokers,services,andresponsibilities.A servicerepresentsa specifictask to be provided by the DBMS, and


Object server

User interfaces

OMS TMS IMS

DBMS

Figure3.14:TheKIDS subsystemarchitecture

eachserviceis providedby at leastonecomponentin thesystemandcanberequestedbyraisingevents.Servicesareprovidedby reactive processingelementscalledbrokers(bro-kersarecomparableto objectsin object-orientedprogramming).Componentsin KIDS areDBMS subsystemsthat arecollectionsof brokers. Brokersareresponsiblefor a relatedsetof tasks,e.g.,objectmanagement,transactionmanagement,andintegrity management.For example,the transactionmanagementsubsystemcanconsistof a transactionbroker,scheduler, log managementbroker, andrecoverybroker. Transactionbroker is responsiblefor startingandterminatingtransactions,i.e., servicessuchasbegin transaction,commit,andabort. The scheduleris responsiblefor serializingconcurrenttransactions,i.e., vali-dateservicewhichcheckswhetherthedatabaseaccessis legitimatewith therespectto theexecutionof concurrenttransactions.A structuralview of theKIDS architectureis shownin figure3.14. TheDBMS architectureconsistsof two layers.Thefirst layer is theobjectserver component,which supportsthestorageandretrieval of storageobjects.Theobjectserverprovidesafixedinterface,whichhidesimplementationdetailsandoperatingsystemcharacteristicsfrom upperlayers. The objectserver componentis reusedin its entirety,andbelongsto the fixedpartof the DBMS architecture(this is becausetheobjectserverimplementsfunctionalityneededby any DBMS). The secondlayer is variableto a largeextent, andcanbe decomposedinto varioussubsystems.In the initial decompositionofKIDS, threemajorsubsystemsexist in thesecondlayer:D The object managementsubsystem(OMS), which implementsthe mappingfrom

datamodelobjectsinto storageobjects,retrieval of datamodelobjects,andmetadatamanagement.

D Thetransactionmanagementsubsystem(TSM), which implementstheconceptof atransaction,includingconcurrency control,recovery, andlogging.

D The integrity managementsubsystem(IMS), which implements the (DBMS-specific) notion of semanticintegrity, and is responsiblefor checking whetherdatabasestatetransitionsresultin consistentstates.

Eachof thesesubsystemsis implementedusingdedicatedlanguagesandreusetechniques.Thesethreesubsystems(OMS, TMS, andIMS) implementbasicdatabasefunctionality.Additional functionality canbe provided by addingnew subsystemsin the secondlayerof the KIDS architecture,i.e., expandingdecompositionof this layer to morethanthreesubsystems.

KIDS is composedout of components(subsystems)carefullydefinedin anunderlyingarchitecture.The constructionprocessof the CDBMS is well-defined,andstartsafter arequirementanalysisof thedesiredDBMS, for a specificdomain,hasbeenperformedandrelevantaspects,i.e.,functionalitythatDBMS needsto provide,havebeendetermined(seefigure3.15).Theprocessof DBMS constructionis donein phases:


subsystem integration

implementationsubsystem

subsystem design


subsystem design


subsystem design

DBMS analysis

selection

testingoptimization

subsystem developmentarchitecture

Figure3.15:Phasesof theDBMS constructionprocess

D Theselectionof anarchitectureskeletonfrom thelibrary, or adevelopmentof anewarchitectureskeleton,i.e.,a (possiblystill incomplete)collectionof partiallydefinedsubsystems.

D Thesubsystemdevelopment,which consistsof subsystemdesign,implementation,andsubsystemintegration. At this phasethe processbranchesin a senseof paral-lelismfor adesignandimplementationof eachsubsystem.Integrationof subsystemsinto previously definedarchitecturalskeletonis thenperformed.Sinceit might notalwaysbepossibleto integratethesubsystemaftertheimplementationof all subsys-temshasbeencompleted,it is possibleto performintegrationasfarasnecessaryandcontinuewith thesubsystemdevelopment,i.e., this phaseis iterative andincremen-tal.

D Testingandoptimizationfollow thesubsystemdevelopment.TheKIDS constructionprocessfocuseson thedevelopmentof subsystemsandtheir integration.Analysisofthesystemis not investigatedin greaterdetails.

KIDS allows new componentsto be developedand integratedinto the system,thus,enablestailoringof aDBMS for differentapplications.Expandingtheinitial setof compo-nentsin theKIDS architecturewith thefunctionality(components)neededby a particularapplication,onecould be ableto design“plain” object-orientedDBMS, a DBMS video-server, or a real-timeplant control DBMS. Of course,in the proposedinitial designofKIDS, real-timepropertiesof thesystemor componentsarenotconsidered.For areal-timeapplication,theproposedconstructionprocesscouldbeusedif acomponentis constructedsuchthat its timing behavior is known, andtheconsumptionof memoryby eachcompo-nentis takeninto account.KIDS offersgoodbasisfor theearlysystemtesting;in thefirstphaseof theconstructionprocess,at thearchitecturelevel of thesystem.

A definedprocessof a DBMS construction,reusabilityof componentsandarchitec-tures,and high degreeof componentization(tailorability) of a systemdifferentiatethisCDBMSfrom all others.


3.3 Component-basedembeddedand real-timesystems

Embeddedreal-timesystemsarebeingusedwidely in today’smodernsociety. Thus,agileandlow-costsoftwaredevelopmentfor embeddedreal-timesystemshasbecomecriticallyimportant.Successfuldeploymentof embeddedreal-timesystemsdependson low devel-opmentcosts,high degreeof tailorability andquicknessto market. Thus, the useof thecomponent-basedsoftwaredevelopmentparadigmfor constructingandtailoring embed-dedreal-timesystemshaspremise.We elaboratethis in moredetail by listing themajorbenefitsof using component-basedsoftware engineeringfor developmentof embeddedreal-timesystems[106, 64]:

D Rapiddevelopmentanddeploymentof thesystem.Component-basedsoftwarede-velopmentaimsto reducetheamountof new codethatmustbewritteneachtimenewapplicationis beingdeveloped.Many softwarecomponents,if properlydesignedandverified,canbereusedin differentembeddedreal-timeapplications.Embeddedreal-time systemsbuilt out of componentsmay be readily adoptedand tunedfor newenvironmentsasopposedto monolithicsystems.

D Changingsoftware“on-the-fly”. Embeddedreal-timesensor-basedcontrolsystemsmay be designedto have softwareresourcesthat canchangeon the fly, e.g.,con-trollers,device drivers.This featureis desirablein autonomousandintelligentcon-trol applications,aswell.

D Evolutionary design. In a component-basedsystemsoftware componentscan bereplacedor addedin the system. This is appropriatefor complex embeddedreal-timesystemsthatrequirecontinuoushardwareandsoftwareupgradesin responsetotechnologicaladvancements,environmentalchange,or alterationof systemgoals.

D Productlines. It is commonthatmanufacturerscreateseveraldifferent,but still sim-ilar, embeddedreal-timeproducts.Having reusablecomponentsstoredin a librarywould enabletheentireproductline to usesamesoftwarecomponentsfrom the li-brarywhendevelopingproducts.This eliminatestheneedto developandmaintainseparatesoftwarefor eachdifferentproduct.

D Increasedreliability. It is easierto develop,testandoptimizeindividualcomponentsof limited functionalitythanwhenthesamefunctionalityis embeddedwithin a largemonolithicsystem.In addition,individualcomponentscanbespecifiedandverifiedmoreeasily, andprovided that the rulesfor the compositionof a systemarewell-defined,safety-criticalapplicationscanbecomposedfrom suchcomponents.

D Fine-tuning.Having componentsin the systemthat canbe replacedoffersconsid-erableflexibility for fine-tuningof anembeddedreal-timeapplication,e.g.,compo-nentscanbeintroducedthatenableswitchingbetweenstaticanddynamicschedulingalgorithms.

D Reducedsystemcomplexity. Componentsaredesignedto have differentfunction-ality. Choosingcomponentsfrom the library that provide functionality neededbythe systemshouldreducesystem’s complexity. This is true sinceit is likely that acomponent(ascomparedto the monolithic system)will not containlarge partsoffunctionalityunneededby thesystem.

In the remainderof this sectionwe give analysisof existing component-basedembeddedreal-timesystems.However, someof thecomponent-basedsystemsanalyzedonly embed-dedor only real-timesystems.To obtaina goodunderstandingof how component-basedsoftwaredevelopmentcanbesuccessfullyintegratedin theareaof embeddedreal-timesys-tems,it is necessaryto investigatebothreal-timeandembeddedsystem,in additionto thosesystemthat canbe classifiedasembeddedreal-time(definitionsof embedded,real-time,


andembeddedreal time systemsaregivenin chapter1). In orderto keepthenotationassimpleaspossibleand,at thesametime,easilyunderstandable,whenreferringto multiplesystemsthatcanbeclassifiedeitherasreal-timeor asembeddedor asembeddedreal-time,weusethenotationembeddedreal-timesystems.

3.3.1 Componentsand architecturesin embeddedreal-timesystems

We have identifiedthreedistincttypesof component-basedembeddedreal-timesystems:

D Extensiblesystems.An exampleof thistypeof thesystemis SPIN[12], anextensiblemicrokernel.Extensionsin thesystemarepossibleby pluggingcomponents,whichprovide non-standardfeaturesor functionality, into anexisting system.Extensionsareallowedonly in well-definedplacesof thesystemarchitecture.

D Middlewaresystems. Theseare characterizedby their aim of providing efficientmanagementof resourcesin dynamicheterogeneousenvironments,e.g., 2K [53]is a distributedoperatingsystemthat is specificallydevelopedfor managementofresourcesin a distributedenvironment,which consistsof a differentsoftwareandhardwareplatforms.

D Configurablesystems.An architectureof a configurablesystemallowsnew compo-nentsto bedevelopedandintegratedinto thesystem.Componentsin suchsystemsaretruebuilding partsof thesystem.A varietyof configurablesystemsexists,e.g.,VEST [102], Ensemble[64], the approachto systemdevelopmentwith real-timecomponentsintroducedby Isovic [49], andsystemsbasedon theport-basedobject(PBO)model[105].

3.3.2 Extensiblesystems

SPIN

SPIN [12, 85] is an extensibleoperatingsystemthat allows applicationsto definecus-tomizedservices.Hence,SPINcanbeextendedto provide so-calledapplication-specificoperatingsystemservices[12]. An application-specificserviceis onethatpreciselysatis-fiesthefunctionalandperformancerequirementsof anapplication,e.g.,multimediaappli-cationsimposespecialdemandsonthescheduling,communicationandmemoryallocationpoliciesof anoperatingsystem.SPINprovidesa setof coreservicesthatmanagememoryandprocessorresources,suchasdevice access,dynamiclinking, andevents. All otherservices,suchasuser-spacethreadsandvirtual memoryareprovidedasextensions.Thus,SPIN providespossibility to customize,i.e, tailor, the systemaccordingto the needsofa specificapplication. However, the systemhasa low degreeof tailorability, sincethearchitecturecanonly beextendedwith components,calledextensions.

A reusablecomponent,anextension,is a codesequencethatcanbe installeddynam-ically into the operatingsystemkernel by the applicationor on behalf of it. Thus, anapplicationcandynamicallyaddcodeto an executingsystemto provide a new service.The applicationcanalsoreplaceor augmentold codeto exchangeexisting services,i.e.,componentscanbeadded,replaced,or modifiedin thesystem.E.g.,anapplicationmayprovide a new in-kernelfile system,replacean existing pagingpolicy, or addcompres-sion to network protocols. Extensionsarewritten in Modula-3,a modular, ALGOL-lik eprogramminglanguage.Themechanismthat integratesextensions(components)with thecoresystemareevents,i.e.,communicationin SPINis event-based.An eventis a messagethat is raisedto announcea changein the stateof the systemor a requestfor a service.Eventsareregisteredin aneventhandler, which is a procedurethatreceivesanevent. Anevent dispatcheroverseesevent-basedcommunication.The dispatcheris responsibleforenablingservicessuchasconditionalexecution,multicast,asynchrony, andaccesscontrol.


An extensioninstallsa handlerwith the event thorougha centraldispatcherthat routeseventsto handlers.Event-basedcommunicationallows considerableflexibility of thesys-temcomposition.All relationshipsbetweenthecoresystemandcomponentsaresubjecttochangesby simplychangingthesetof eventhandlersassociatedwith any givenevent.

The correctnessof the composedsystemdependsonly on the language’s safetyandencapsulationmechanisms;specificallyinterfaces,typesafety, andautomaticstorageman-agement.Analysisof thecomposedsystemis not performed,sinceit is assumedthat theconfigurationsupportprovidedwithin theModula-3languageis enoughto guaranteethecorrectandsafesystem.SPINallowsapplicationsto implementtheirown schedulingpoli-cies.Providedtheright extensionfor real-timeschedulingpolicy thisoperatingsystemcanbeusedfor soft real-timeapplicationssuchasmultimediaapplications.

3.3.3 Middleware systems

2K

2K [55, 53] is anoperatingsystemspecificallydevelopedfor manipulationof resourcesin a distributedheterogeneousenvironment(differentsoftwaresystemson differenthard-wareplatforms).2K is basedon a network-centricmodelandCORBA componentinfras-tructure. In the network centricmodelall entities,i.e., userapplications(labeledas2Kapplications),softwarecomponentsanddevices,exist in thenetwork andarerepresentedasCORBA objects(seefigure3.16). Whena particularserviceis instantiated,theentitiesthat constitutethat serviceareassembled.Softwarecomponents(CORBA objects)com-municatethroughIDL interfaces.As shown in figure3.16,2K middlewarearchitectureisrealizedusingstandardCORBA servicessuchasnaming,trading,securityandpersistence,and extendingthe CORBA servicemodel with additionalservices,suchas QoS-awaremanagement,automaticconfiguration,andcodedistribution. The2K automaticconfigura-

dynamic TAO

hardware

Solaris

LegORB

hardware

Solaris

LegORB

hardware

Palm OS

LegORB

hardware

WindowsCE

dynamic TAO

hardware

Windows

Automaticconfiguration

QoS-aware repositoryComponent environments

User

resource manager

Distributed operating system servicesNaming

Trading

Security

Persistency

Active meeting roomVideo-on-demandVideo-conferencing applications

2K

middleware

2K

Figure3.16:The2K middlewarearchitecture

tion servicesupportsloadingcomponentsinto run-timesystem.A CORBA object,calledComponentConfigurator, storesinter-componentdependenciesthat mustbe checked be-forecomponentscanbesuccessfullyinstalledinto asystemby theautomaticconfigurationservice.An Internetbrowser, for example,couldspecifythatit dependsuponcomponentsimplementinganX-Windowssystem,alocalfile service,theTCP/IPprotocol,andtheJavavirtualmachineversion1.0.2or later. TheautomaticconfigurationserviceandComponent-Configuratorenableautomatedinstallationandconfigurationof new componentsprovidedthesystemhasaccessto therequirementsfor installingandrunningasoftwarecomponent,i.e, inter-componentdependencies.

Integrationof componentsinto the middleware is donethrougha componentcalleddynamicTAO (TheAdaptiveCommunicationEnvironmentORB).ThedynamicTAO is aCORBA compliantreflectiveORBasit allowsinspectionandreconfigurationof its internal


engine[54]. This is importantsincethemiddlewaremustbeconfigurableandableto adopttodynamicchangesin resourceavailability andin thesoftwareandhardwareinfrastructure.

However, the dynamicTAO componenthasa memoryfootprint greaterthan a fewmegabytes,which makesit inappropriatefor usein environmentswith limited resources.A variantto thedynamicTAO, aLegORBcomponent,is developedby the2K groupandithasa small footprint andis appropriatefor embeddedenvironments,e.g.,6 Kbyteson thePalmPilotrunningon PalmOS.DynamicTAO andLegORBcomponentsarenot reusable,but arethekey enablerfor reuseof otherCORBA objects.Eventhoughthis systempro-videsautomatedinstallationandconfigurationof new components,it doesnot specifythedevelopmentof new components.Thedevelopmentof new componentsis doneonly basedon CORBA componentmodelspecifications.Softwarecomponentsin this systemcanbereused.However, thosearecomponentswhichalreadyexist in thenetwork, andarereusedin thesensethatthey canbedynamicallyinstalledinto thesystemwheneversomeapplica-tion needsa specificcomponent.Also, it is is assumedthatinter-componentdependenciesprovidegoodbasisfor thesystemintegration,andguaranteecorrectsystembehavior (otherguaranteesof thesystembehavior, obtainedby appropriateanalysis,donotexist).

As figure 3.16 shows, 2K provides servicesfor the applicationssuchas video-on-demandandvideo-conferencing,whichcanbeviewedassoft real-timeapplications.Con-sideringthat2K usesCORBA componentinfrastructurewith real-timeCORBA extensions,i.e., TAO ORB, implies that hardreal-timeapplicationscanalsobe supportedby the 2Kmiddlewarearchitecture.

3.3.4 Configurable systems

Ensemble

Ensembleis a high performancenetwork protocolarchitecturedesignedto supportgroupmembershipandcommunicationprotocols[64]. Ensembledoesnot enforcereal-timebe-havior, but is neverthelessinterestingbecauseof theconfigurablearchitectureandthewayit addressesthe problemof configurationandanalysisof the system.Ensembleincludesa library of over sixty micro-protocolcomponentsthat canbestacked, i.e, formedinto aprotocol in a variety of ways to meetcommunicationdemandsof an application. Eachcomponenthasa commonevent-drivenEnsemblemicro-protocolinterface,andusesthemessage-passingway of communication. Ensemble’s micro-protocolsimplementbasicsliding window protocols,andfunctionalitysuchasfragmentationandre-assembly, flowcontrol, signingandencryption,groupmembership,messageordering,etc. The Ensem-ble systemprovidesanalgorithmfor calculatingthestack,i.e., composingprotocolout ofmicro-protocols,giventhesetof propertiesthatanapplicationrequires.Thisalgorithmen-codesknowledgeof protocoldesignersandappearsto work quitewell, but doesnotassuregenerationof a correctstack(themethodologyfor checkingcorrectnessis not automatedyet). Thus,Ensemblecanbeefficientlycustomizedfor differentprotocols,i.e.,it hasahighlevel of tailorability. In addition,Ensemblegivesthepossibilityof formal optimizationofthecomposedprotocol.This is donein Nuprl [64] andappearsto give goodresultsasfarastheoptimizationof aprotocolfor a particularapplicationgoes.

Systemdevelopmentwith real-timecomponents

Isovic et al. [49] defineda developmentmethodspecificallytargetedtowardsreal-timesystemsregardlessof its complexity. Thedevelopmentmethodthey proposeis anextensionof themethodusedfor developingreal-timesystemsadoptedby Swedishcarindustry[78].In thisdevelopmentmethodit is assumedthat:

D The componentlibrary containsbinariesof components-of-the-shelf(COTS), anddescriptionof them,e.g.,memoryconsumption,identification,environmentassump-tions(processorfamily onwhichcomponentoperates),andfunctionaldescription.


D Thecomponentlibrary alsocontainsdependenciesto othercomponents.

D Componentsaremappedto tasks,or multiple tasksfor morecomplex components.

D Componentcommunicationis donethroughsharedmemory, andinterfacesarecalledports.

The developmentprocessfor real-timesystemsis divided in several stagesasshown infigure3.17,andstartswith asystemspecificationasaninputto thetop-level design.At thetop-leveldesignstagedecompositionof asystemintocomponentsis performed.A designerbrowsesthroughthe library anddesignsthe systemhaving in mind possiblecomponentcandidates.At the detaileddesignstagetemporalattributesareassignedto components:period,releasetimes,precedenceconstraints,deadline,mutualexclusion,andtime-budget(a componentis requiredto completeits executionwithin its time-budget).At thefollow-ing stagechecksareperformedto determineif selectedcomponentsareappropriateforthesystem,or, if theadaptationof componentsis required,or new componentsneedto bedeveloped.Also, at this stage,componentinterfacesarecheckedto seeif input portsareconnectedandif their typematches,andthatway systemintegrationis performed.If thisstageshows that selectedcomponentsarenot appropriatefor the systemunderconstruc-tion, thena new componentneedsto bedeveloped.Developedcomponentsareplacedinlibrariesfor futurereuse.Thedetaildesignstage,thescheduling/interfacecheckstage,andthetop-level designstagecanberepeateduntil propercomponentsfor systemintegrationarefound(or designed).Whenthesystemfinally meetstherequirementsfrom thespecifi-cation,thetemporalbehavior of componentsmustbetestedonthetargetplatformto verifyif they meettemporalconstrainsdefinedin thedesignphase,i.e.,verificationof worstcaseexecutiontime is performed.Themethoddescribedprovidesa high degreeof tailorability

System specification

Top-level design

Detailed design

Scheduling/Interface check

Timing behavior

System verification

Component library

Component developement

Figure3.17:Designmodelfor real-timecomponents

for thedeveloper, sincethearchitectureof thesystemis not fixed,andcomponentsin thesystemcanbeexchangedduringthedesignof thesystemin orderto obtainthemostsuit-ablecomponentsfor thatparticularsystem.Thedeveloperdoeshave somesupportwhilechoosingthe appropriatecomponentfor reuse,given the checkstagesof the designanddependency checksamongcomponentsthatarestoredin libraries.However, suchprocessis notautomated.

Thismethodsupportsanalysisof temporalbehavior of components(focusis onworst-caseexecutiontimechecks),but how thetemporalbehavior of theentiresystemis checkedis not clear. Also, this approachis constrainedby theassumptionthat thecomponentsinlibrary canbeCOTS andthat temporalbehavior of componentsis not known beforehand.Thisallowstemporalconstraintsof thecomponentto bedefined(or betterto saypredicted)only at thedesigntimeof thesystem.


VEST

While previouslydescribeddesignmethodis targetedtowardssystemsthat,in mostcases,needto be composedout of COTS, and suitablefor more complex real-timesystems,VEST [102] aimsto enabletheconstructionof theOS-like portionof anembeddedreal-time systemwith strengthenedresourceneeds.The VEST developmentprocessis fairlywell-definedwith anemphasison configurationandanalysistoolsis recognizedin VEST.The developmentprocessoffers moreflexibility thanthe onepresentedby Isovic et. al.[49], sincecomponentsin the library arepassive andreal-timeattributesof componentsareknown. Systemdevelopmentstartswith thedesignof theinfrastructure,which canbesaved in a library andusedagain(seefigure3.18). The infrastructureconsistsof micro-componentssuchas interrupthandlers,inidirection tables,dispatchers,plug andunplugprimitives,proxiesfor statemapping,etc. The infrastructurerepresentsa framework forcomposinga systemout of components.Configurationtoolspermitstheuserto createanembeddedreal-timesystemby composingcomponentsinto a system,i.e., mappingpas-sive componentsinto run-timestructures(tasks).After a systemis composed,dependencychecksareinvokedto establishcertainpropertiesof thecomposedsystem.If thepropertiesaresatisfiedandthesystemdoesnotneedto berefined,theusercaninvokeanalysistoolstoperformreal-time,aswell asreliability analysis.As canbeseen,VESToffershighdegreeof tailorability for thedesigner, i.e.,a specificsystemcanbecomposedout of appropriatecomponentsaswell asinfrastructurefrom thecomponentlibrary. Notethatcomponentsin

Infrastructure creation

Component selection/design

Integrated system

Dependency checks

Library

Analysis

components

infrastructure

dependencies

Figure3.18:Embeddedsystemdevelopmentin VEST

VEST arepassive (collectionof codefragments,functionsandobjects),andaremappedinto run-timestructures(tasks).Eachcomponentcanbecomposedoutof subcomponents.For example,thetaskmanagementcomponentcanbemadeof componentssuchascreatetask,deletetask,andsettaskpriority. Componentshavereal-timepropertiessuchasworstcaseexecutiontime,deadline,andprecedenceandexclusionconstraints,whichenablereal-timeanalysisof thecomposedsystem.In additionto temporalproperties,eachcomponenthasexplicit memoryneedsandpower consumptionrequirements,neededfor efficient usein an embeddedsystem. Selectinganddesigningthe appropriatecomponent(s)is fairlycomplex process,sinceboth real-timeandnon-real-timeaspectsof a componentmustbeconsideredandappropriateconfigurationsupporthasto beavailable.Dependency checksproposedin VEST areonegoodway of providing configurationsupportandthestrengthof theVESTapproach.Dueto its complexity dependency checksarebrokeninto 4 types:

E factual: component-by-component dependency checks(worst caseexecutiontime,memory, importance,deadline,etc.),

E inter-component:pairwisecomponentchecks(interfacerequirements,versioncom-patibility, is acomponentincludedin another, etc.),


D aspects:checksthatincludeissueswhichaffecttheperformanceor semanticof com-ponents(real-time,concurrency synchronizationandreliability issues),and

D general:checksof globalpropertiesof thesystem(thesystemshouldnotexperiencedeadlocks,hierarchicallocking rulesmustbefollowed,etc.).

Having well defineddependency checksis vital sinceit minimizespossibleerrorsin thesystemcomposition.Interfaceproblemsin VESTareonly identifiedbut arenot addressedat all; thusit is not obvioushow componentscanbeinterconnected.Also, analysisof thesystemis proposed,but somemoreconcretesolutionsarenot presented.Finally, VESTis anongoingprojectdevelopingtheplatformfor configurationandanalysisof embeddedreal-timesystems.

PBO model

A component-basedsystembasedon theport-basedobject(PBO)modelcanbeclassifiedasconfigurable,andis suitablefor developmentof embeddedreal-timecontrol softwaresystem[105]. Componentsfrom thecomponentlibrary, in additionto newly createdones,canbeusedfor thesystemassembly. A componentis thePBOthat is implementedasanindependentconcurrentprocess.Componentsareinterconnectedthroughports,andcom-municatethroughsharedmemory. ThePBOdefinesmodulespecificcode,includinginputandoutputports,configurationconstants(for adoptingcomponentsfor differentapplica-tions), the type of the process(periodicandaperiodic),andtemporalparameterssuchasdeadline,frequency, andpriority. Supportfor composinga systemout of componentsislimited to generalguidelinesthat aregiven to the designerfor composinga systemoutof PBO components,and is not automatedat all. This approachto componentizationissomewhat uniquesinceit givesmethodsfor creatinga framework that handlesthe com-munication,synchronizationand schedulingof eachcomponent. Any C programmingenvironmentcanbe usedto createcomponentswith minimal increasein performanceormemoryusage.CreatingcodeusingPBO methodologyis an “inside out” programmingparadigmascomparedto a traditionalcodingof real-timeprocesses.The PBO methodprovidesconsistentstructurefor every processandOS systemservices,suchascommu-nication,synchronization,scheduling.Only whennecessary, OS calls PBO’s methodtoexecuteapplicationcode.Analysisof thecomposedsystemis notconsidered.

3.4 A tabular overview

This chapterconcludeswith a tabular summaryof investigatedcomponent-basedsystemsandtheir characteristics.Thetables3.3and3.4provideanadditionalinstrumentfor com-paringandanalyzingcomponent-baseddatabaseandcomponent-basedembeddedreal-timesystems.Thefollowing symbolsareusedin thetable:

x — featureis supportedin/truefor thesystem,and

x/p — featureis partiallysupportedin/truefor thesystem,i.e, thesystemfulfills thefeatureto a moderateextent.

Below followsadescriptionof thecriteria.

1The systemaimsto supportthe feature,but only the draft of how the featureshouldbe supportedby thesystemexists,i.e., thereis noconcreteimplementation.


DB

MS

plat

form

sE

mbe

dded

and

real

-tim

epla

tform

s

Pla

tform

sC

hara

cter

istic

sofp

latfo

rms

[30]

[76]

Oracle8i[82]DataBlade[48]UDB2[21]

Sybase[81]

Garlic[95]

DiscoveryLink[42]OLEDB[74]CORBAService[84] KIDS[38]

SPIN[12]

2K[53]

Ensemble[64][49]

VEST[102]

PBO[105]

A.

Type

1)da

taba

sex

xx

xx

xx

xx

xx

ofth

e2)

embe

dded

xx

syst

em3)

real

-tim

e4)

embe

dded

real

-tim

ex

xx

xB

.S

tatu

s1)

rese

arch

plat

form

xx

xx

xx

xx

x2)

com

mer

cial

prod

uct

xx

xx

xx

xx

C.

Com

pone

nt1)

syst

emx

xx

gran

ular

ity2)

part

ofth

esy

stem

xx

xx

xx

xx

xx

xx

xx

xD

.C

ateg

ory

1)ex

tens

ible

xx

xx

xof

the

2)m

iddl

ewar

ex

xx

xsy

stem

3)se

rvic

ex

4)co

nfigu

rabl

ex

xx

xx

E.

Com

pone

nt1)

dom

ain-

spec

ificd

atat

ype

ora

new

inde

xx

xx

xty

pe2)

wra

pper

xx

x3)

serv

ice

xx

4)D

BM

Ssu

bsys

tem

x5)

CO

RBA

obje

ctx

xx

7)m

icro

prot

ocol

x8)

bina

ryx

9)pa

ssive

x10

)PB

Ox

Tabl

e3.

3:C

hara

cter

istic

sofc

ompo

nent

-bas

eddat

abas

e,em

bedd

edan

dre

al-t

imes

yste

ms


DB

MS

plat

form

sE

mbe

dded

and

real

-tim

epla

tform

s

Pla

tform

sC

hara

cter

istic

sofp

latfo

rms

[30]

[76]

Oracle8i[82]DataBlade[48]UDB2[21]

Sybase[81]

Garlic[95]

DiscoveryLink[42]OLEDB[74]CORBAService[84] KIDS[38]

SPIN[12]

2K[53]

Ensemble[64][49]

VEST[102]

PBO[105]

F.R

eal-t

ime

1)no

tpre

serve

dx

xx

xx

xx

xx

xx

xx

prop

ertie

s2)

pres

erve

dx/

px

x1x/

pG

.In

terfa

ce/

1)st

anda

rdiz

edx

xx

xx

com

mun

icat

ion

2)sy

stem

spec

ific

xx

xx

xx

xx

x3)

port

s/un

buffe

red

xx

H.

Con

figur

atio

n1)

nota

vaila

ble

xx

xx

tool

s3)

avai

labl

ex

xx

xx/

px/

px/

px

x/p

xx/

px1

x/p

I.A

naly

sis

1)no

tava

ilabl

ex

xx

xx

xx

xx

xx

xto

ols

3)av

aila

ble

x/p

x/p

x/p

xx/

p1

J.R

eusa

bilit

y1)

com

pone

ntx

xx

xx

xx

xx

xx

xx

xx

x1x

2)ar

chite

ctur

ex

x1

K.

Tailo

ring

1)no

nex

xx

abili

ty2)

low

xx

xx

x3)

mod

erat

ex

xx

x4)

high

xx

xx1

x

Tabl

e3.

4:C

hara

cter

istic

sofc

ompo

nent

-bas

eddat

abas

e,em

bedd

edan

dre

al-t

imes

yste

ms


A. Type of the system We investigatedintegrationof thecomponent-basedsoftwareen-gineeringfor thesystemdevelopmentin thefollowing areas:

1. database,

2. embedded,

3. real-time,and

4. embeddedreal-time.

This criteria illustrateslack of component-basedsolutionsin the areaof embeddedreal-timedatabasesystems.As canbeseenfrom table3.3,therearefew component-basedsys-temsthatcanbeclassifiedasembeddedreal-time;all component-basedsystemsareeitherembeddedandreal-timesystems,or databasesystems.Theredoesnot exist a component-baseddatabasesystemthatcanbeclassifiedasembeddedreal-time.

B. Status Analyzedcomponent-basedplatformsare:

1. researchplatforms,and

2. commercialproducts.

As canbeseenfrom the table3.3,mostcomponent-baseddatabasesystemsarecommer-cial products,while embeddedreal-timeplatformsareall researchprojects.It is importantto noticethatthedatabaseindustryhasembracedthecomponent-basedsoftwareparadigmand that the needfor componentizationis increasinglyimportant,sincealmostall ma-jor databasevendorsprovide somecomponent-basedsolution of their databaseservers.Also, it is clearthat real-timeandembeddedissuesarenot integratedin the commercialcomponent-baseddevelopment,thus,implying thatthereis still alot of openresearchques-tionsthatneedto beansweredbeforecomponent-basedembeddedreal-timesystemscouldbecommericalized.

C. Componentgranularity Therearetwo majorgranularitylevelsof components:

1. systemasacomponent,and

2. partof thesystemasacomponent.

It is noticeablethatadatabasecomponentcanbeanything from adatabasesystem,acom-ponentof large granularity, to lightweight componentsthat are composingpartsof theDBMS. In contrast,mostembeddedreal-timesystemshave lightweightcomponents,i.e.,partsof the system,andarebuilding anoperatingsystem-like portionof embeddedreal-timesystems.An exceptionis 2K wherea component(CORBA object)is of largergranu-larity andcanbeanembeddedsystemitself.

D. Category of the system If we emphasizethata databaseasa componentcannotrep-resenta real component-basedsolutionof a databasesystem,thenour view is narrowedto a componentDBMS (CDBMS) and partsor extensionsof the databasesystemas acomponent. Samecan be statedfor embeddedreal-timesystems. Hence,investigatedcomponent-basedsystemsareclassifiedasfollows:

1. extensible,

2. middleware,

3. service,and

4. configurable.

Notethatserviceis thecategoryof CDBMSs,andnotof embeddedreal-timesystems.


E. Component type A componentin a component-baseddatabasesystem and acomponent-basedembeddedreal-timesystemis oneof thefollowing:

1. domain-specificdatatypeor a new index,

2. wrapper,

3. service,

4. DBMS subsystem,

5. CORBA object,

6. microprotocol,

7. binarycomponent,

8. passivecomponent,and

9. PBO(port-basedobject).

Thefirst four componenttypesaretypically componentsfound in databasesystems.Wereferto theseasdatabasecomponents.Thelastfive typesof componentsaremostlyfoundin embeddedreal-timesystems.

CDBMSsmainlyconsistof componentsthatimplementacertaindatabasefunctionality(or extendexisting functionality),usuallymappedinto services.Thus,a databasecompo-nentprovidescertaindatabaseserviceor function.For example,in Oracle8i thespatialdatacartridgecomponentimplementsnon-standardDBMS functionalitysuchasspatialindex.Also, in KIDS, the DBMS subsystemcomponent,transactionmanagement,canprovideseveral relatedservicessuchas transaction,serializationandvalidationservices,and inCORBAservicesonecomponentis onedatabaseservice.

Componentsin embeddedreal-timesystemsaremorediverse.In somesystemscom-ponentsare not explicitly defined, and can only be classifiedas passive components(VEST) or asbinary components(in developmentmethodologyintroducedby Isovic etal. [49]). SystemssuchasSPINandEnsemblehavemorespecificcomponents,extensionsfor application-specificoperatingsystemservices(SPIN)andmicroprotocols(Ensemble).Only 2K hasstandardizedcomponents(CORBA objects).

Note that almostevery systemhasits own notion and a definition of a component,whichsuitesthesystem’spurposeandrequirements.

F. Real-time properties Component-baseddatabaseand embeddedreal-timesystemsmay:

1. notpreserve,or

2. preserve

real time properties.Component-baseddatabasesystemsdo not enforcereal-timebehav-ior (seetable3.4). In addition,issuesrelatedto embeddedsystemssuchaslow-resourceconsumptionarenot addressedat all. Accent in a databasecomponentis on providinga certaindatabasefunctionality. In contrast,a componentin existing component-basedembeddedreal-timesystemsis usuallyassumedto bemappedto a task,i.e., passive com-ponents[102], binary components[49] andPBO components[105] areall mappedto atask.Thiscomesnaturallyin thereal-timeresearchcommunitybecauseataskis thesmall-estschedulableunit in a real-timesystem.Therefore,analysisof real-timecomponentsinthesesolutionsaddressestheproblemof managingtemporalattributesatacomponentlevelby consideringthemastaskattributes[49, 102, 56]:


D worst-caseexecutiontime (WCET)- thelongestpossibletime it takesto completeatask,D releasetime - the time at which all datathat are requiredto begin executingare

available,D deadline- thetimeby whicha taskmustcompleteits execution,

D precedenceconstraintsandmutualexclusion- specifyif a taskneedsto precedeorexcludeothertasks,and

D period- if a taskis periodic.

Componentsin the PBO model [105] have only two temporalattributes,frequency anddeadline.Components,in thedevelopmentmethodfor component-basedreal-timesystemsintroducedby Isovic et al. [49], are assumedto have all of the above listed temporalattributes,andtheseattributesarepredictedin thedesignphaseof thesystemdevelopment.VEST includesfull list of temporalattributesin its componentsandexpandsthat list withattributesessentialfor correctbehavior of componentsin anembeddedenvironment:D powerconsumptionrequirements,and

D memoryconsumptionrequirements.

ThismakestheVESTapproachthemostflexible embeddedreal-timeapproach,sincecom-ponentattributesincludereal-timeandembeddedneeds,andareknown for every compo-nentin the library (this wasnot thecasein thedevelopmentmethodfor component-basedreal-timesystemsintroducedby Isovic et al. [49]).

A componentin anembeddedreal-timesystemmusthavewell definedtemporalprop-erties, i.e., componentbehavior must be predictable,in order to be able to composeareliableembeddedreal-timesystem.Hence,to beableto developa databasesuitableforan embeddedreal-timesystemout of components,suchcomponentswould have to havewell-definedtemporalpropertiesandresourcerequirements,e.g.,memoryandpowercon-sumption,issuesnot addressedin currentdatabasecomponents.Thus,we concludethatadatabasecomponentusedin anembeddedreal-timesystemwould have to bea real-timecomponent,andassuch,mappedto a taskin orderto ensurepredictabilityof thecompo-nentandof thecomposedembeddedreal-timesystem,i.e.,weneedto know, for example,worst-caseexecutiontime for a databasecomponentto beableto ensurepredictabilityofthecomponent,and,in turn,of thedatabasesystemcomposedoutof suchcomponents.

G. Interfaces / communication The componentcommunicateswith its environment(othercomponents)throughwell-definedinterfaces.Generally, existing component-baseddatabaseandembeddedreal-timesolutionsuse:

1. standardinterfaces,

2. systemspecific,and

3. unbufferedinterfaces(ports),in whichcasethey usecommunicationthroughsharedmemory.

For example,standardizedinterfacesdefinedin the IDL areusedin CORBAservicesandin 2K. Also, OLE DB interfaceis usedin theMicrosoft’sUniversalDataAccessarchitec-ture. Interfacesdevelopedwithin thesystemareusedin othersystems,e.g.,Oracle8i hasextensibilityinterfacesandKIDS hascomponent-specificinterface.Systemsthataimto al-low moreflexible compositionuseevent-basedcommunication,e.g.,KIDS, SPIN,Ensem-ble,and2K. Inter-componentcommunicationin databasesystemsandembeddedreal-timesystemshave differentgoals.Interfacesin embeddedreal-timesystemsmustbesuchthatinter-componentcommunicationcanbeperformedin a timely predictablemanner. Therearetwo possiblewaysof a real-timecomponentcommunication:


D Buffered communication. The communicationis donethroughmessagepassing,e.g., [64].

D Unbufferedcommunication.Unbuffereddatais accessedthroughsharedmemory,e.g.,[104, 49].

Notethatmostcomponent-baseddatabasesystemsusebufferedcommunicationsincepre-dictability of communicationis not of importancein suchsystems. Systemsenforcingreal-timebehavior use unbuffered communication(an exception is VEST where inter-facesof componentsarenot defined),dueto several disadvantagesof bufferedcommu-nication[45, 49]:

D Sendingandreceiving messagesincursignificantoverhead.

D Taskswaiting for datamightblock for anundeterminedamountof time.

D Crucialmessagescangetlostasaresultof thebuffer overflow if tasksdonotexecuteat thesamefrequency.

D Sendingmessagesin controlsystems,whichhavemany feedbackloops,createsriskfor deadlock.

D The upperboundon the numberof produced/consumedmessagesmust be deter-minedto enableguaranteeof temporalproperties.

Generally, a real-timesystemusing buffered communicationis difficult to analyzedueto dependenciesamongtasks.Unbufferedcommunicationeliminatesdirectdependenciesbetweentasks,sincethey only needto bind to a single elementin the sharedmemory.Communicationthroughsharedmemoryincursfeweroverheadsascomparedto amessage-passingsystem.Also, it is easierto checksystem’s temporalbehavior if unbufferedcom-municationis used[49]. Hence,unbufferedstyle of communicationis preferredstyle ofcommunicationin embeddedreal-timesystems.It is suggestedthat interfacesin (hard)real-timesystemsshouldbeunbuffered[49].

H. Configuration tools The developmentprocessmustbe well definedto enableeffi-cient systemassemblyout of existing componentsfrom the componentlibrary or newlycreatedones. Adequateandautomatedconfigurationsupportmustexist to help systemdesignerwith this process,e.g.,rulesfor composinga systemout of components,supportfor selectionof anappropriatecomponentfrom thecomponentlibrary, andsupportfor thedevelopmentof new components.However, in somesystemsconfigurationtools arenotavailable. Hence,we identify thatconfigurationtools in a component-baseddatabaseandembeddedreal-timesystemare:

1. notavailable,and

2. available.

Observe (table3.4) that mostextensibleCDBMSshave availableconfigurationsupport.Sinceextensiblesystemsalreadyhave fixedarchitectureandpre-definedextensions,pro-vided configurationtools aresufficient to enabledevelopmentandintegrationof compo-nentsinto anextensiblesystem.TheGarlic middlewaretechnologyprovidesa simpleandfairly easydevelopmentof new components(wrappers),but thesecomponentsarewithsimple functionality and structure. The situationgetsmore complicatedif we considerOLE DB middleware,wherenot only components,dataproviders,canbe addedor ex-changedin thearchitecture,but thearchitecturecanalsobeextendedto usecustomizabledataproviders. Hence,adequateconfigurationsupportis neededto ensureinteroperabil-ity of differentdataproviders. However, whendevelopinga dataprovider componentthe


developeris only encouragedto follow specificationexactly in orderto ensureinteroper-ability with otherdataproviders,i.e, limited configurationsupportavailable. OLE DB isalsolimited in termsof use,it canonly beusedin Microsoft’scomputingenvironments.

Ontheotherhand,extensibleandmiddlewareembeddedreal-timesystemsdonotpro-vide good configurationsupport. 2K, for example,doesnot have reusablecomponentsin its architectureandprovidesautomatedconfiguration(andreuse)of componentsfromdifferentsystems.The correctnessof integrated2K middlewareis only assumed(basedon checksof inter-componentdependencies).Also, SPIN offers very little configurationsupport,sincecorrectness,configuration,andintegrationof componentsin thecoresystemis basedon featuresof the extensionlanguagein which componentsaredeveloped.Therulesfor compositionof a systemarenot definedin 2K andSPIN,andthesesystemscanbeviewedasthefirst generationof acomponent-basedembeddedreal-timesystems.

In general,demandson developmentsupportin configurablesystemsarehigh. KIDShasmetthesedemandsto someextent,with a well-defineddevelopmentprocess.In mostconfigurableembeddedreal-timesystems,someconfigurationsupportis alsoprovided.Forexample,PBOmodelgivesgoodguidelinestohelpdesignerwhencomposingsystemoutofcomponents.Thedevelopmentmethodfor component-basedreal-timesystemsintroducedby Isovic et al. [49] providesconfigurationsupportfor choosingappropriatecomponentfor systemcomposition,i.e., checksof temporalpropertiesandinterfacesof componentsareperformedto ensurethatthecomponentfrom thelibrary is suitablefor thesystemun-derdevelopment.In VEST, thenecessityof having goodconfigurationtoolsis recognized.Compositionrulesaredefinedthroughfour typesof dependency checks.Notethatthede-velopmentintroducedby Isovic et al. [49] and2K have only inter-componentdependencychecks,which arejust oneout of four typesof checksproposedin VEST. This makestheVEST approachthemostappropriateonewith respectto thecorrectsystemcomposition,becausethemoredependenciesarecheckedin thesystem,within components,theproba-bility of errorsin thecomposedsystem,i.e.,compositionalerrors,is minimized.

I. Analysis tools Sincethe reliability of the composedsystemdependson the level ofcorrectnessof thecomponent,analysistoolsareneededto verify thebehavior of thecom-ponentandthecomposedsystem.In particular, real-timesystemsmustmeettheir temporalconstraints,andadequateanalysisto ensurethata systemhasmeettemporalconstraintsisrequired.Thus,analysistoolsare:

1. notavailable,and

2. available.

The problem of analysisof the composedcomponent-baseddatabasesystemis ratherstraightforward, in mostcases,analysisof the composedsystemis unavailable(seetable3.4). Importanceof having goodanalysisof thecomposedsystemis recognizedin KIDS,but is notpursuedbeyondthat,i.e.,analysistoolsarenotprovided.Component-basedem-beddedreal-timesystemsdo not provide analysisof the composedsystemaswell. Thatis true for SPIN,2K, andsystemsbasedon the PBO model. VEST introducesnotion ofreliability andreal-timeanalysisof thesystem,but doesnotgivemoredetaileddescriptionof suchanalysis.In thedevelopmentmethodintroducedby Isovic et al. [49] checksof theWCETof componentsareperformed.

G. Reusability Systemsarecomposedout of reusablecomponentsfrom thelibrary. Ar-chitectureof the systemcan be reusedin the system’s developmentas well. Thus, incomponent-baseddatabaseandembeddedreal-timesystemspartsthatcanbereusedare:

1. component,and

2. architecture.


As canbe seenfrom the table3.4, the part that canbe reusedin all systemsis the com-ponent.KIDS andVEST canalsoreusethearchitecture,asopposedto othersystems.Ifwe considerthat reusabilityof architectureasa way to receive a higherpay-off [67, 75],KIDS andVESThavesignificantlyhigherdegreeof reusabilityascomparedto others.Thefactthatanarchitectureof asystemcanbereusedis alsoimportantfrom adifferentaspect,earlysystemtesting.For example,eventhoughit doesnot have any analysistools,KIDSoffersgoodbasisfor theearlysystemtesting,in thefirst phaseof theconstructionprocess,at thearchitecturelevel of thesystemdevelopment.

H. Tailoring ability Thebenefitof usingcomponent-baseddevelopmentin databasesys-temsis customizationof thedatabasefor differentapplications.Therearefour degreesoftailorability in component-baseddatabaseandembeddedreal-timesystems:

1. none,

2. low,

3. moderate,and

4. high.

It is noticeablethatextensiblesystemshave low tailorability, middlewaremoderate,whileconfigurablesystemshavehigh tailorability (seetable3.4). Sincethegoalis to provideanoptimizeddatabasefor a specificapplicationwith low developmentcostsandshorttime-to-market,it is safeto saythatconfigurablesystemsarethemostsuitablein thisrespect.Inparticular, VEST andKIDS, sincethey allow architecturesto besavedandreused.At thesametime,themethodologyintroducedin KIDS andVESTshouldenabletailoringof onegenericsystemfor a varietyof differentapplications.

Chapter 4

Summary

Thisfinal chapterstartswith asummaryof themainissueswehave identifiedin thereportwith respectto currentstate-of-the-artin the areaof embeddeddatabasesfor embeddedreal-timesystems(section4.1). In the lastsection(section4.2)we identify challengesforfuturework.

4.1 Conclusions

Embeddedsystems,real-timesystems,anddatabasesystemsareresearchareasthathavebeenactively studied.However, researchon embeddeddatabasesfor embeddedreal-timesystems,explicitly addressingthedevelopmentanddesignprocess,is sparse.A databasethatcanbeusedin anembeddedreal-timesystemmusthandletransactionswith temporalconstraints,andmust,at the sametime, be suitablefor embeddedsystemswith limitedamountof resources,i.e., thedatabaseshouldhavesmallfootprint,beportableto differentoperatingsystemplatforms,have efficient resourcemanagement,andbe able to recoverfrom a failurewithoutexternalintervention.

As wehaveshown in thisreport,thereareavarietyof differentembeddeddatabasesonthemarket. However, they vary significantlyin their characteristics.Differencesin prod-uctsaretypically theway dataareorganizedin thedatabase(datamodel),thearchitectureof thedatabase(DBMS model),andmemoryusage.Commercialembeddeddatabasesalsoprovide different interfacesfor applicationsto accessthe database,andsupportdifferentoperatingsystemplatforms. Applicationdevelopersmustchoosecarefully theembeddeddatabasetheir applicationrequires. This is a difficult, time consumingand costly pro-cess,with a lot of compromises.Onesolutioncouldbeto have a moregenericembeddeddatabaseplatform that canbe tailoredandoptimizedsuchthat it is suitablefor differentapplications.Existingreal-timedatabaseresearchplatformsareunsuitablein this respect,sincethey aremainlymonolithicsystems,andassuch,they arenot easilytailoredfor newapplicationshaving differentor additionalrequirements.

Satisfyingrequirementsput on theembeddeddatabasein anembeddedreal-timesys-temcallsfor anew wayof designinganddevelopinganembeddeddatabasefor applicationspecificsystem. For this purposewe have examinedthe component-basedsoftwareen-gineeringparadigmsinceit hasbeensuccessfullyappliedin conventionalnon-real-timeenvironments.

Traditionalcomponent-basedsystems,e.g.,systemsbasedon COM or CORBA com-ponentframework,normallyview anentiredatabasesystemasonecomponent.Weempha-sizethatthecomponent-baseddatabasesystemis thedatabasesystem,wherethebuildingpartsare components,and refer to suchbuilding partsas databasecomponents.Com-ponentsin a databasesystemusuallyimplementcertaindatabasefunctionality(or extendexisting functionality),andthesearenormallymappedinto services.In contrast,compo-

75

CHAPTER4. SUMMARY 76

nentsin embeddedreal-timesystemsaredevelopedto have well-definedtemporalproper-ties,e.g.,worst-caseexecutiontime,deadline,andreleasetime,andaremappedto oneormultiple tasks.We have shown thata real-timedatabasecomponent,i.e., a databasecom-ponentwith temporalconstraintsthat representsthe intersectingtypeof thedatabaseandreal-timecomponent,doesnot exist. Existingcomponent-baseddatabasesystemsdo notenforcereal-timebehavior, andissuesrelatedto embeddedsystemssuchaslow-resourceconsumptionarenot addressedat all in thesesolutions.However, in orderto composeareliableembeddedreal-timesystemout of components,eachcomponent’s behavior mustbepredictable.This is thereasonwhy componentsin existing component-basedreal-timesystemsareusuallyassumedto be mappedto a taskwith well-definedtemporalproper-ties.To ensurepredictabilityandreliability of adatabasein anembeddedreal-timesystem,suchdatabasewouldhaveto becomposedoutof components,with well-definedandknowntemporalpropertiesof a componentmustbewell-definedandknown. This, in turn,wouldrequiresuchacomponentto bemappedto a task.

We have observed that the architectureof component-basedsystemsvary from fairlyfixed (extensiblesystems),to completelyconfigurable.In the extensiblesystems,whichhave fixed architecture,extensionsareallowed only in well-definedplacesof the archi-tecture.In theconfigurablesystemscomponentscanbefreely addedor exchangedin thearchitecture.Configurablesystemsallow significantamountof flexibility to thedeveloperandthe user, in comparisonto othersystems.Hence,configurablesystemsrepresentthepreferredtype of component-basedsystems,as they allow the embeddeddatabaseto betailoredfor new applicationswith differentrequirements.Sinceconfigurablesystemsofferthehighestdegreeof tailorability, andarethemostflexibleones,wefocusonthesesystems;in particularKIDS (component-baseddatabasesystem)andVEST (component-basedem-beddedreal-timesystem).Higherpay-off andquicknessto market canbeachievedif thearchitecturecanbestoredin a library andreused,aswell ascomponents(this featurecanalsobe found in configurablesystemssuchasKIDS andVEST). Moreover, to have anarchitecturalabstractionof a systemwouldenableearlysystemtesting.Temporalanalysisof systemsandcomponentscould be donein an early stageof the systemdevelopment,thus,reducingdevelopmentcosts,andenhancingreliability andpredictabilityof thesys-tem. For example,in KIDS thearchitectureis reusable,andeventhoughit doesnot haveany analysistools,KIDS offersgoodbasisfor theearlysystemtesting;in thefirst phaseoftheconstructionprocess,at thearchitecturelevel of thesystem.

To ensureminimum errorsin the systemcomposition,the mostefficient existing ap-proachis to have a large numberof dependency checks,as in VEST, wherefour typesof dependency checksareintroduced,e.g.,factual,inter-component,aspectsandgeneral.Notethatsomesystems,suchas2K, have only onetypeof dependency checks,i.e., inter-componentdependency checks.Othersystemsdonothavedependency checksatall, whichmakesthemmorevulnerablefor compositionalerrors.

Whencomposinganembeddeddatabasesystemout of components,theissueof inter-componentcommunicationshouldbe carefullyhandled.Componentsin embeddedreal-time systemsmustcommunicatein a timely predictablemanner, andfor that reasonmostembeddedreal-timesystemsuseunbufferedcommunication. In contrast,most existingcomponent-baseddatabasesystemshave bufferedcommunication(messagepassing),andarenot concernedwith predictabilityof inter-componentcommunication.Furthermore,mostcomponent-baseddatabasesystemsusestandardizedinterfaces,e.g.,IDL, OLE DB,whichmakesthemsuitablefor easierexchangeandadditionof new components(they mustconformto a standard),while embeddedreal-timesystemsmostly have system-specificinterfaces,i.e., interfacesdefinedwithin thesystem.

We have studiedcomponentsand their definitionsin component-basedsoftwareen-gineeringin particular, aswell as in component-baseddatabaseandembeddedreal-timesystems.We found that every component-basedsystemhasits own notion anda defini-tion of a component.Thus, the componentis to a large extent an arbitrarynotion, andis practicallyre-definedandre-inventedin eachsystem.However, thereareat leastthree


commonrequirementsthat a componentmustsatisfyin any component-basedsystem(i)to bea composingpartof thesystem;(ii) to bereusablewith well-definedconditionsandwaysof reuse;and(iii) to havewell-definedinterfacesfor inter-connectionwith othercom-ponents.Furthermore,rulesfor compositionof a systemmustbedefined,and(automated)tools to assistthe developermustbe available. Although mostof the component-baseddatabaseandembeddedreal-timesystemsfocuson components,their solutionslack goodcompositionrules,andautomateddevelopmentsupport.

4.2 Future work

It is evidentthatresearchfor embeddeddatabasesthatexplicitly addresses(i) developmentanddesignprocess,and(ii) limited amountof resources,inheritschallengesfrom thetradi-tional real-timesystems,embeddedsystems,andcomponent-basedsoftwareengineering.

Key challengesin component-basedsoftwareengineeringinclude:

D developinga componentthat canbe reusedasmany timesaspossible,andwouldconformto a standard,

D determininghow a componentshouldbeverified to obtainappropriateinformationin orderto determinesuitabilityof acomponentfor aspecificsystem,

D definingrulesfor thecompositionof a reliablesystem,which satisfiesspecificationrequirements,

D analyzingthebehavior of thecomposedsystem,aswell asensuringtrade-off analysisbetweenconflictingrequirementsin theearlydesignstage,and

D providing adequateconfigurationsupportfor developmentprocess,in particularde-terminingwhatis doableby toolsandwhatneedsto beleft to thedesigner.

Theaboveresearchchallengesin acomponent-basedsoftwareengineeringarefurtheraug-mentedfor embeddedreal-timesystems.Theadditionalchallengesinclude:

D defininga componentwith predictablebehavior,

D determininghow inter-componentcommunicationshouldbe performed,andwhatareappropriateinterfacesfor real-timecomponents,

D managingresourcessuchasmemoryusageandrequiredprocessingtimefor differentoperationsof a component,possiblyon differenthardwareplatformsandoperatingsystemplatforms,and

D determiningwhataretheappropriateanalysistools for analysisof systemresourcedemands,andanalysisof thetiming propertiesof thecomposedsystem.

Embeddingadatabasein a real-timesystemalsobringsa setof challenges:

D determiningwhat type of the DBMS architectureis appropriate(library vs client-server) to ensurepredictabilityin a real-timesystem,

D determiningthemostappropriatedatamodelfor theembeddeddatabase,and

D determiningwhich typeof interfaces,throughwhichuseris accessinga database,isthemostsuitable.

Finally, fundamentalresearchquestionswhen developingan embeddeddatabasefor anembeddedreal-timesystemusingcomponent-basedsoftwareengineeringinclude:


D defininga real-timedatabasecomponent,i.e., functionalityandservicesthata com-ponentshouldprovide,andtemporalconstraintsa componentshouldsatisfy,

D determiningwhich componentinterfacesareappropriate,andhow inter-componentcommunicationshouldbeperformed(messagepassingvs sharedmemory),and

D integratingthecomposeddatabaseinto anembeddedreal-timesystem.

Our researchis focusedon providing an experimentalresearchplatform for buildingembeddeddatabasesfor embeddedreal-timesystems.At a high-level, the platformcon-sistsof two parts.First,weintendto developacomponentlibrary, holdingasetof methods,whichcanbeusedwhenbuilding anembeddeddatabase.Initially, wewill developasetofcomponentsthatdealwith concurrency control,scheduling,andmain-memorytechniques.At thenext step,wedeveloptoolsthat,basedontheapplicationrequirements,will supportthedesignerwhenbuilding anembeddeddatabaseusingthesecomponents.More impor-tantly, wewantto developapplicationtoolsandtechniquesthat: (i) supportthedesignerinthecompositionandtailoringof anembeddeddatabasefor a specificsystemusingthede-velopedcomponents,wheretheapplicationrequirementsaregivenasaninput; (ii) supportthedesignerwhenanalyzingthetotalsystemresourcedemandof thecomposedembeddeddatabasesystem;and(iii) help the designerby recommendingcomponentsandmethodsif multiple componentscanbeused,basedon theapplicationrequirements.Further, sucha tool will help the designerto make trade-off analysisbetweenconflicting requirementsearlyin thedesignphase.

The componentsshouldcarry propertydescriptionsof themselves with informationabout(i) whatserviceandfunctionality thecomponentprovides;(ii) whatquality of ser-vice guaranteesfacilitatedby the component,e.g., techniquesmay be applicableto softreal-timeapplicationsbut not hardreal-timeapplications;(iii) their systemresourcede-mand,e.g,memoryusageandrequiredprocessingtime for differentoperationsandser-vicesprovidedby a component,possiblyon differenthardwareplatformsin orderto sim-plify interoperability;and(iv) compositionrules,i.e.,whichspecifieshow, andwith whichcomponents,acomponentcanbecombined.

Our researchshouldgive betterunderstandingof the specificationof componentstobe usedin an embeddedand real-timesetting. This includesfunctionality provided bythecomponent,theresourcedemandrequiredby a componentwhenexecutedondifferentplatforms,andrulesfor specifyinghow componentscanbecombinedandhow theoverallsystemcanbecorrectlyverifiedgiventhateachcomponenthasbeenverified.

Bibliography

[1] Proceedingsof InternationalWorkshop,Databasein Telecommunications, number1819in LectureNotesin ComputerScience,Edinburgh,Scotland,UK, September1999.Springer-Verlag.

[2] S.Abiteboul,B. Amann,S.Cluet,A. Eyal,L. Mignet,andT. Milo. Activeviewsforelectroniccommerce.In VLDB’99, Proceedingsof 25th InternationalConferenceon Very Large Data Bases, pages138–149,Edinburgh, Scotland,UK, September1999.MorganKaufmann.ISBN 1-55860-615-7.

[3] G. D. Abowd, R. Allen, andD. Garlan. Using style to understanddescriptionsofsoftwarearchitectures.ACM SoftwareEngineeringNotes, 18(5):9–20,1993.

[4] B. Adelberg, H. Garcia-Molina,andB. Kao. Emulatingsoft real-timeschedulingusingtraditionaloperatingsystemschedulers.In Proceedingsof IEEE Real-TimeSystemSymposium, 1994.

[5] B. Adelberg,H. Garcia-Molina,andJ.Widom.TheSTRIPrulesystemfor efficientlymaintainingderiveddata.In SIGMOD, pages147–158,1997.

[6] B. Adelberg, B. Kao,andH. Garcia-Molina.Overview of theSTanfordReal-TimeInformationProcessor(STRIP). SIGMODRecord (ACM SpecialInterestGrouponManagementof Data), 25(1),1996.

[7] B. S.Adelberg. STRIP:A SoftReal-TimeMainMemoryDatabasefor OpenSystems.PhDthesis,StanfordUniversity, 1997.

[8] Q. N. AhmedandS. V. Vrbsky. TriggeredUpdatesfor TemporalConsistency inReal-TimeDatabases.Real-TimeSystems, 19(3):209–243,November2000.

[9] S. F. Andler, J. Hansson,J. Eriksson,J. Mellin, M. Berndtsson,and B. Eftring.DeeDSTowardsa DistributedandActive Real-Time DatabaseSystem.ACM Sig-mondRecord, Volume25,1996.

[10] F. Baothman,A. K. Sarje,andR.C.Joshi.Onoptimisticconcurrency controlfor RT-DBS. IEEE Region10 InternationalConferenceon Global Connectivityin Energy,Computer, CommunicationandControl, 1998.

[11] L. Bass,P. Clements,andR. Kazman.SoftwareArchitectureIn Practice. SEISeriesin SoftwareEngineering.AddisonWesley, 1998.

[12] B. N. Bershad,C.Chambers,S.Eggers,C.Maeda,D. McNamee,P. Pardyak,S.Sav-age,andE. G. Sirer. SPIN- anextensiblemicrokernelfor application-specificoper-atingsystemservices.TechnicalReport94-03-03,Departmentof ComputerScienceandEngineering,Universityof Washington,Seattle,WA, USA, February1994.

[13] L. Blair andG. Blair. A tool suiteto supportaspect-orientedspecification.In Pro-ceedingsof theAspect-OrientedProgrammingWorkshopat ECOOP’99, pages7–10,Lisbon,Portugal,June1999.A positionpaper.

79

BIBLIOGRAPHY 80

[14] J. A. Blakeley. OLE DB: A componentDBMS architecture.In Proceedingsof the12th InternationalConferenceon Data Engineering(ICDE), pages203–204,NewOrleans,Louisiana,USA, March1996.IEEEComputerSocietyPress.

[15] J.A. Blakeley. Universaldataaccesswith OLEDB. In Proceedingsof the42ndIEEEInternationalComputerConference(COMPCON), pages2–7,SanJoseCalifornia,February1997.IEEEComputerSocietyPress.

[16] J. A. Blakeley andM. J. Pizzo. ComponentDatabaseSystems, chapterEnablingComponentDatabaseswith OLE DB. DataManagementSystems.MorganKauf-mannPublishers,2000.

[17] J. Bosch. DesignandUseof Software Architectures. ACM Pressin collaborationwith Addison-Wesley, 2000.

[18] A. P. Buchmann,A. Deutsch,J. Zimmermann,andM. Higa. The REACH activeOODBMS.In Proceedingsof the1995ACM SIGMODInternationalConferenceonManagementof Data, pages476–476,1995.

[19] A. P. Buchmann,J. Zimmermann,J. A. Blakeley, and D. L. Wells. Building anIntegratedActive OODBMS: Requirements,Architecture,and DesignDecisions.In Proceedingsof the 11th InternationalConferenceon Data Engineering, pages117–128.IEEEComputerSocietyPress,1995.

[20] R. CamposanoandJ. Wilberg. Embeddedsystemdesign. DesignAutomationforEmbeddedSystems, 1(1):5–50,1996.

[21] M. J.Carey, L. M. Haas,J.Kleewein,andB. Reinwald. Dataaccessinteroperabilityin theIBM databasefamily. IEEEQuarterlyBulletinonDataEngineering;SpecialIssueonInteroperability, 21(3):4–11,1998.

[22] M. J.Carey, L. M. Haas,P. M. Schwarz,M. Arya,W. F. Cody, R.Fagin,M. Flickner,A. Luniewski, W. Niblack, D. Petkovic, J. ThomasII, J. H. Williams, and E. L.Wimmers. Towardsheterogeneousmultimediainformation systems:The Garlicapproach.In Proceedingsof the5th InternationalWorkshopon Research IssuesinData Engineering:DistributedObjectManagement(RIDE-DOM), pages124–131,Taipei,Taiwan,March1995.IEEEComputerSociety. ISBN 0-8186-7056-8.

[23] COMPOST.http://i44w3.info.uni-karlsruhe.de/compost/.Universityof Karlsruhe,Germany.

[24] IBM Coorporation.http://www.software.ibm.com/data/datjoiner.

[25] I. Crnkovic andM. Larsson. A casestudy: Demandson component-baseddevel-opment.In Proceedingsof 22thInternationalConferenceof Software Engineering,pages23–31,Limeric, Ireland,June2000.ACM.

[26] I. Crnkovic, M. Larsson,andF. Lüders. Stateof the practice: Component-basedsoftware engineeringcourse. In Proceedingsof 3rd International WorkshopofComponent-BasedSoftwareEngineering. IEEEComputerSociety, January2000.

[27] C. J.Date.AnIntroductionto DatabaseSystems. Addison-Wesley, 2000.

[28] J.R.Davis. Creatinganextensible,object-relationaldatamanagementenvironment:IBM’ sDB2UniversalDatabase.DatabaseAssociatedInternational,InfoIT Services,November1996.Availableathttp://www.dbaint.com/pdf/db2obj.pdf.

[29] K. R. Dittrich andA. Geppert.ComponentDatabaseSystems, chapterComponentDatabaseSystems:Introduction,Foundations,and Overview. Data ManagementSystems.MorganKaufmannPublishers,2000.

BIBLIOGRAPHY 81

[30] A. Dogac,C. Dengi,andM. T. Öszu.Distributedobjectcomputingplatform. Com-municationsof theACM, 41(9):95–103,1998.

[31] ENEA Data.OSEReal-timesystem.http://www.enea.se.

[32] J.Eriksson.Real-timeandactivedatabases:A survey. In Proceedingsof theSecondInternationalWorkshopon Active, Real-TimeandTemporal Databases, nr. 1553inLecturenoteseries.Springer-Verlag,December1998.

[33] J.Eriksson.SpecifyingandManagingRulesin an ActiveReal-TimeDatabaseSys-tem. LicenciateThesis,Number738. Linköping University, Sweden,December1998.

[34] K. P. Eswaran,J.N. Gray, R. A. Lorie, andI. L. Traiger. Thenotionsof consistencyandpredicatelocksin adatabasesystem.Thecommunicationsof theACM, 19,1976.

[35] S. Chakravarthy et al. HiPAC: A researchproject in active, time-constraineddatabasemanagement.TechnicalReportXAIT-8902,XeroxAdvancedInformationTechnology, 1989.

[36] W. Fleisch. Applying use casesfor the requirementsvalidation of component-basedreal-timesoftware. In Proceedingsof 2ndIEEE InternationalSymposiumonObject-OrientedReal-Time Distributed Computing(ISORC), pages75–84,Saint-Malo, France,May 1999.IEEE.

[37] A. Gal. Datamanagementin ecommerce(tutorial session):thegood,thebad,andtheugly. In Proceedingsof the2000ACM SIGMODon Managementof Data, vol-ume34,page587,Dallas,TX, USA, May 2000.ACM.

[38] A. Geppert,S.Scherrer, andK. R.Dittrich. KIDS: Constructionof databasemanage-mentsystemsbasedon reuse.TechnicalReportifi-97.01,Departmentof ComputerScience,Universityof Zurich,September1997.

[39] J.Gray. Noteson databaseoperatingsystems.In OperatingSystems:An AdvancedCourse, number60in LectureNotesin ComputerScience,pages393–481.Springer-Verlag,1978.

[40] A. Gupta,V. Harinarayan,andA. Rajaraman.Virtual databasetechnology. In Pro-ceedingsof 14th InternationalConferenceon Data Engineering, pages297–301,1998.

[41] R.K. Gupta.Co-SynthesisofHardwareandSoftwarefor Digital EmbeddedSystems.TheKluwer InternationalSeriesin EngineeringandComputerScience.KluwerAca-demicPublishers,1995.

[42] L. M. Haas,P. Kodali, J. E. Rice, P. M. Schwarz, andW. C. Swope. Integratinglife sciencesdata-witha little Garlic. In Proceedingsof the IEEE InternationalSymposiumon Bio-Informaticsand BiomedicalEngineering(BIBE), pages5–12.IEEE,2000.

[43] J. Hansson. Dynamicreal-timeschedulingin OSEDelta. TechnicalReportHS-IDA-TR-94-007,Dept.of ComputerScience,Univ. of Skövde,1994.

[44] J. R. HaritsaandK. Ramamritham.Real-timedatabasesystemsin the new mil-lennium. Real-TimeSystems, 19(19):205–208,November2000. The InternationalJournalof Time-CriticalComputingSystems.

[45] M. HassaniandD. B. Stewart. A mechanismfor communicationin dynamicallyreconfigurableembeddedsystems.In Proceedingsof High AssuranceSoftware En-gineering(HASE)Workshop, pages215–220,WashingtonDC, August1997.

BIBLIOGRAPHY 82

[46] J.Huang,J.Stankovic, K. Ramamritham,andD. Towsley. ExperimentalEvaluationof Real-timeOptimisticConcurrency Control Schemes.In Proceedingsof VLDB,Barcelona,Spain,September1991.

[47] SybaseInc. http://www.sybase.com.

[48] Developing DataBlademodulesfor Informix-Universal Server. Informix Dat-aBlade Technology. Informix Corporation, 22 March 2001. Available athttp://www.informix.com/datablades/.

[49] D. Isovic, M. Lindgren,andI. Crnkovic. Systemdevelopmentwith real-timecompo-nents.In Proceedingsof ECOOPWorkshop- PervasiveComponent-BasedSystems,France,June2000.

[50] K. Ramamritham.Real-Time Databases.InternationalJournal of distributedandParallel Databases, pages199–226,1993.

[51] G. Kiczales,J. Lamping,A. Mendhekar, C. Maeda,C. Lopes,J-M. Loingtier, andJ. Irwin. Aspect-orientedprogramming. In Proceedingsof the ECOOP, volume1241of LectureNotesin ComputerScience, pages220–242.Springer-Verlag,1997.

[52] Y-K. Kim, M. R. Lehr, D. W. George,andS. H. Song. A databaseserver for dis-tributedreal-timesystems:Issuesandexperiences.In Proceedingsof the SecondIEEEWorkshoponParallel andDistributedReal-TimeSystems, 1994.

[53] F. Kon,R. H. Campbell,F. J.Ballesteros,M. D. Mickunas,andK. Nahrsted.2K: Adistributedoperatingsystemfor dynamicheterogeneousenvironments.In Proceed-ings of the 9th IEEE International Symposiumon High PerformanceDistributedComputing(HPDC’9), pages201–208,Pittsburgh,August2000.

[54] F. Kon,M. Román,P. Liu, J. Mao,T. Yamane,L. C. Magalhales,andR. H. Camp-bell. Monitoring,security, anddynamicconfigurationwith thedynamicTAO reflec-tiveORB. In Proceedingsof theIFIP/ACMInternationalConferenceonDistributedSystemsPlatformsand OpenDistributed Processing(Middleware’2000), number1795in LectureNotesin ComputerScience,pages121–143,New York,USA,April2000.Springer.

[55] F. Kon,A. Singhai,R. H. Campbell,andD. Carvalho.2K: A reflective,component-basedoperatingsystemfor rapidly changingenvironments. In Proceedingsof theECOOPWorkshopon ReflectiveObjectOrientedProgrammingand Systems, vol-ume 1543 of Lecture Notesin ComputerScience, Brussels,Belgium, July 1998.Springer.

[56] C. M. KrishnaandK. G.Shin.Real-timeSystems. McGraw-Hill Seriesin ComputerScience.TheMcGraw-Hill Companies,Inc., 1997.

[57] H. T. Kung andJ. T. Robinsson.On optimistic methodsfor concurrency control.ACM TransactionsonDatabaseSystems, 6, 1981.

[58] T-W. Kuo, C-H. Wei, andK-Y. Lam. Real-Time DataAccessControl on B-TreeIndex Structures.In Proceedingsof the15thInternationalConferenceon Data En-gineering, 1999.

[59] M. LarssonandI. Crnkovic. New challengesfor configurationmanagement.In Pro-ceedingsofSystemConfigurationManagement,9thInternationalSymposium(SCM-9), volume1675of Lecture Notesin ComputerScience, pages232–243,Toulouse,France,August1999.Springer.

BIBLIOGRAPHY 83

[60] T. J. Lehmanand M. J. Carey. A study of index structuresfor main memorydatabasemanagementsystems.In Proceedingsof the12thConferenceonVeryLargeDatabases,MorganKaufmannpubs.(LosAltosCA),Kyoto, 1986.

[61] J.Lindstrom,T. Niklander, P. Porkka,andK. Raatikainen.A DistributedReal-TimeMain-MemoryDatabasefor Telecommunication.In Proceedingsof the WorkshoponDatabasesin Telecommunications, pages158–173,1999.

[62] W. Litwin. Linearhashing:A new tool for file andtableaddressing.In Proceedingsof the6th InternationalConferenceonVeryLargeDatabases, 1980.

[63] B. Liu. Embeddedreal-timeconfigurationdatabasefor anindustrialrobot.Master’sthesis,LinköpingUniversity, 2000.

[64] X. Liu, C. Kreitz, R. Renesse,J.Hickey, M. Hayden,K. Birman,andR. Constable.Building reliable,high-performancecommunicationsystemsfrom components.InProceedingsof the17thACM SymposiumonOperatingSystemsPrinciples(SOSP),volume34,pages80–92,December1999.PublishedasOperatingSystemsReview.

[65] H. Lu, Y. YeungNg, andZ. Tian. T-Treeor B-Tree:Main MemoryDatabaseIndexStructureRevisited. 11thAustralasianDatabaseConference, 2000.

[66] D. C. Luckham,J. J. Kenney, L. M. Augustin,J. Vera,D. Bryan, andW. Mann.Specificationandanalysisof systemarchitectureusingRapide.IEEE Transactionson Software Engineering, 21(4):336–355,April 1995. SpecialIssueon SoftwareArchitecture.

[67] C.H. Lung,S.Bot,K. Kalaichelvan,andR.Kazman.An approachtosoftwarearchi-tectureanalysisfor evolutionandreusability. In Proceedingsof CASCON, Toronto,ON, November1997.IBM Centerfor AdvancedStudies.

[68] U. Aßmann.A componentmodelfor invasivecomposition.In ECOOP2000Work-shopon AspectsandDimensionsof Concerns, Sophia,Antipolis andCannes,June2000.

[69] U. Aßmann. Invasive softwarecompositionwith programtransformation.Forth-cominghabilitation,2001.

[70] MBraneLtd. http://www.mbrane.com.

[71] N. Medvedovic andR. N. Taylor. Separatingfact from fiction in softwarearchitec-ture. In Proceedingsof theThird InternationalWorkshopon Software Architecture,pages10–108.ACM Press,1999.

[72] J. Mellin, J. Hansson,andS. Andler. Refiningtiming constraintsof applicationinDeeDS. In S. H. Son, A. Bestavros, and K-J. Lin, editors,Real-Time DatabaseSystems:IssuesandApplications, pages325–343,1997.

[73] B. Meyer andC. Mingins. Component-baseddevelopment:From buzz to spark.IEEEComputer, 32(7):35–37,July 1999.GuestEditors’ Introduction.

[74] Universal data access through OLE DB. OLE DB Technical Ma-terials. OLE DB White Papers, 12 April 2001. Available athttp://www.microsoft.com/data/techmat.htm.

[75] R. T. MonroeandD. Garlan. Style-basedreusefor softwarearchitectures.In Pro-ceedingsof the Fourth InternationalConferenceon Software Reuse, pages84–93.IEEEComputerSocietyPress,April 1996.

BIBLIOGRAPHY 84

[76] A. Münnich,M. Birkhold, G. Färber, andP. Woitschach.Towardsan architecturefor reactivesystemsusinganactivereal-timedatabaseandstandardizedcomponents.In Proceedingsof InternationalDatabaseEngineeringandApplicationSymposium(IDEAS), pages351–359,Montreal,Canada,August1999.IEEEComputerSocietyPress.

[77] T. NiklanderandK. Raatikainen.RODAIN: A Highly AvailableReal-Time Main-Memory DatabaseSystem. In Proceedingsof the IEEE International ComputerPerformanceandDependabilitySymposium, 1998.

[78] C. Norström,M. Gustafsson,K. Sandström,J. Mäki-Turja, and N-E. Bånkestad.Findings from introducingstate-of-the-artreal-time techniquesin vehicle indus-try. In Industrial sessionof the12thEuromicro Conferenceon Real-TimeSystems,Stockholm,Sweden,June2000.

[79] Objectivity inc. Objectivity/DB. http://www.objectivity.com.

[80] M. A. Olson. Selectingand implementingan embeddeddatabasesystem. IEEEComputers, 33(9):27–34,September2000.

[81] S.Olson,R. Pledereder, P. Shaw, andD. Yach.TheSybasearchitecturefor extensi-ble datamanagement.DataEngineeringBulletin, 21(3):12–24,1998.

[82] All your data:TheOracleextensibilityarchitecture.OracleTechnicalWhite Paper.OracleCorporation.RedwoodShores,CA, February1999.

[83] H. OssherandP. Tarr. Subject-orientedprogramming:a critiqueof pureobjects.InProceedingsof theeighthannualconferenceon object-orientedprogrammingsys-tems,languages,and applications, pages411–428,Washington,USA, September26 - October1 1993.ACM Press.

[84] M. T. ÖzsuandB. Yao.ComponentDatabaseSystems, chapterBuildingComponentDatabaseSystemsUsingCORBA. DataManagementSystems.MorganKaufmannPublishers,2000.

[85] P. PardyakandB. N. Bershad.Dynamicbindingfor anextensiblesystem.In Pro-ceedingsof theSecondUSENIXSymposiumon Operating SystemsDesignandIm-plementation(OSDI), OperatingSystemsReview, SpecialIssue,pages201–212,SeattleWA, USA,October1996.ACM andUSENIX Association.ISBN 1-880446-82-0.

[86] D. E. PerryandA. L. Wolf. Foundationsfor thestudyof softwarearchitecture.InProceedingsof theFourth ACM SIGSOFTSymposiumon Foundationsof SoftwareEngineering, volume17,1992.

[87] Persistencesoftwareinc. PowerTier. http://www.persistence.com.

[88] PervasiveSoftwareInc. http://www.pervasive.com.

[89] Pervasive Software Inc. Pervasive.SQL2000 Reviewers guide. Technicalwhitepaper.

[90] POETsoftwarecorp. POETObject.http://www.poet.com.

[91] PolyhedraPlc. http://www.polyhedra.com.

[92] DARPA ITO projects. Program composition for embedded systems.http://www.darpa.mil/ito/research/pces/index.html, 7 August2001.

BIBLIOGRAPHY 85

[93] K. Raatikainenand J. Taina. Designissuesin databasesystemsfor telecommu-nicationservices. In Proceedingsof IFIP-TC6 Working conferenceon IntelligentNetworks,Copenhagen,Denmark, pages71–81,1995.

[94] Raima Corporation. Databases in real-time and embedded systems.http://www.raimabenelux.com/,February2001.

[95] M. T. Roth andP. M. Schwarz. Don’t scrapit, wrap it! A wrapperarchitecturefor legacy datasources.In Proceedingsof 23rd InternationalConferenceon VeryLarge Data Bases(VLDB’97), pages266–275,Athens,Greece,August1997.Mor-ganKaufmann.ISBN 1-55860-470-7.Availableathttp://dblp.uni-trier.de.

[96] S.Ortiz Jr. Embeddeddatabasescomeoutof hiding. In IEEEComputer, 2000.

[97] A. P. ShethandJ.A. Larson.Federateddatabasesystemsfor managingdistributed,heterogeneous,andautonomousdatabases.ACM ComputingSurveys, 22(3):183–236,September1990.

[98] R. Sivasankaran,J.Stankovic, D. Towsley, B. Purimetla,andK. Ramamritham.Pri-ority assignmentin real-timeactivedatabases.TheVLDBJournal, Volume5, 1996.

[99] SleepycatSoftwareInc. http://www.sleepycat.com.

[100] X. SongandJ. Liu. Maintainingtemporalconsistency: Pessimisticvs. optimisticconcurrency control. IEEETransactionsonKnowledgeandDataEngineering, Vol.7, October1995.

[101] J. Stankovic. Misconceptionsaboutreal-timecomputing: a seriousproblemfornext-generationsystems.IEEEComputer, 21,Oct1988.

[102] J. Stankovic. VEST: A toolset for constructingand analyzingcomponentbasedoperatingsystemsfor embeddedandreal-timesystems.TechnicalReportCS-2000-19, Departmentof ComputerScience,University of Virginia, Charlottesville,VA,May 2000.

[103] J.A. Stankovic, S.H. Son,andJ.Liebeherr. Real-TimeDatabasesandInformationSystems, chapterBeeHive: Global Multimedia DatabaseSupportfor Dependable,Real-TimeApplications,pages409–422.Kluwer AcademicPublishers,1997.

[104] D. B. Stewart, M. W. Gertz,and P. K. Khosla. Softwareassemblyfor real-timeapplicationsbasedon a distributedsharedmemorymodel. In Proceedingsof the1994 Complex SystemsEngineeringSynthesisand AssessmentTechnology Work-shop, pages214–224,SilverSpring,MD, July1994.

[105] D. S. Stewart. Designingsoftwarecomponentsfor real-timeapplications.In Pro-ceedingsof EmbeddedSystemConference, SanJose,CA, September2000. Class408,428.

[106] D. S.Stewart andG. Arora. Dynamicallyreconfigurableembeddedsoftware- doesit make sense? In Proceedingsof IEEE Intl. Conf. on Engineeringof ComplexComputerSystems(ICECCS)andReal-TimeApplicationWorkshop(RTAW), pages217–220,Montreal,Canada,October1996.

[107] C. Szyperski. ComponentSoftware - Beyond Object-OrientedProgramming.Addison-Wesley, 1999.

[108] J. Taina and K. Raatikainen. RODAIN: A Real-Time Object-OrientedDatabaseSystemfor Telecommunications.In Proceedingsof theDART’96workshop, pages12–15,1996.

BIBLIOGRAPHY 86

[109] TimesTenPerformanceSoftware.http://www.timesten.com.

[110] H. TokudaandC. Mercer. ARTS: A DistributedReal-Time Kernel. In ACM Oper-atingSystemsReview, 23(3), 1989.

[111] A. Wall. Software architecturefor real-timesystems. TechnicalReport00/20,MälardenReal-Time ResearchCenter, MälardalenUniversity, Västerås,Sweden,May 2000.

[112] D. L. Wells, J. A. Blakeley, andC. W. Thompson.Architectureof anopenobject-orienteddatabasemanagementsystem.IEEEComputer, 25(10):74–82,1992.

[113] M. Xiong,R.Sivasankran,J.Stankovic, K. Ramamritham,andD. Towsley. Schedul-ing transactionwith temporalconstraints:Exploitingdatasemantics.In Proceedingsof the17thIEEEReal-timeSystemsSymposium, 1996.

[114] P. S.Yu,K. Wu,K. Lin, andS.H. Son.Onreal-timedatabases:Concurrency controlandscheduling.In Proceedingsof theIEEE, volume82,pages140–157,1994.

[115] G. Zelesnik. The UniCon Language User Manual. CarnegieMellon University, Pittsburgh, USA, May 1996. Available athttp://www.cs.cmu.edu/afs/cs/project/vit/www/unicon/reference-manual/.

[116] J. ZimmermannandA. P. Buchmann.REACH. In N. Paton (ed): ActiveRulesinDatabaseSystems,Springer-Verlag, 1998.

Documents

Embedded Databases for Embedded Real-Time Systems: A