An approach to the design of software for distributed real-time systems

AnApproachtotheDesignofSoftwareforDistributedReal-TimeSystems

AndrewJ.Vickers†andJohnA.McDermid

DepartmentofComputerScience

UniversityofYork

Heslington

York

Y015DD

ABSTRACT

Thedesignofdistributedreal-timesystemsisdifficultbecauseofthelargenumber

ofissuesinvolvedwiththeirdesign—inter-processcommunication,module

structure,timingconstraints,hardwareconstraints,reliability,etc.Inthispaper,we

showhowsuchissuesmayusefullybepartitionedthroughtheuseofviewpoints

beforebeingcombinedtogethertoprovideanoveralldesignsolution.Ourdesign

approachandnotationisbaseduponasetofconceptswhichareanalagoustothe

constructionindustry’snotionofanarchitecturewhichactsasthecentralartefact

withinthecivilengineeringdesignprocess.Theapproachisintroducedbywayof

asmallcasestudywhichallowsthereadertobeexposedtothedetailofthe

notationasitbecomesnecessarywithinthedevelopmentoftheexampledesign.

1.Introduction

Distributedreal-timesystemsarebecomingmoreandmorewidelyusedinapplicationssuch

aspowerstationmonitoringsystems,aeroplanecontrolsystems,etc.Adistributedsystem

typicallycontainslogicallyseparatemultipleprocessingunitsthatcommunicatebywayofsome

underlyingelectronicnetwork[1].Suchunitsmaybehousedtogetherorbephysicallyseparate

andmayormaynotsharememory.Distributedreal-timesoftwarecontrolssuchsystemsandin

doingsomustsatisfymanyoftherequirementsoftraditionaldataprocessingsoftware.Inaddition

suchsoftwaremustservicetheneedsofitsenvironmentwithinwell-definedtimingdeadlines(the

penaltiesintermsofriskandsafetytomanandtheenvironmentareoftensevereifsuchdeadlines

aremissed).Thisissue,andotherslikeit(includingreliability)areoftentermednon-functional

andareprevalentinthistypeofsoftware[2].

Itistypicallythesekindsofrequirementthatmakethesuccessfuldesignandimplementation

ofreal-timesystemssodifficult.Theserequirementsaredifficulttospecify,difficulttovalidate

againstanddifficulttosatisfyinimplementation.Perhapshowever,themaindifficultyinrealising

distributedreal-timesystemsisthattherequirementsarehardtodesignwith;atleastinpartthisis

becausethenon-functionalpropertiesareemergent,ratherthanbeingpropertieswhichwecan

allocateorbudgetinsometop-downdesignprocess[3].Itisusuallythecasethatsuchnon-

functionalissuesaredealtwithlateinthedesignprocess,i.e.duringimplementation[4,5]where

theyareoftenaddressedthroughtheuseof‘tinkering’or‘optimisation’techniques.Whilstthis

worksoccasionally,itfailswhentheissuewasultimatelydecidedbysomepreviousdesign

decision(forexample,noamountofoptimisationwillincreasesystemperformanceifsome

structuraldesigndecisionwastakenwhichintroducedbottlenecksatalloftheperformance

†AndrewVickersisfundedbyanSERCStudentship.sensitiveareas).Theanswertothisproblemistodesignwiththeseissuesinmind—havea

designthatincorporatesallaspectsofthesolution[5].Wemustfindwaysofbringingsomeof

theseemergentpropertiesexplicitlyintothedesignprocess.Thisistheunderlyingconceptofan

architecture.

Turningforthemomenttoaconstructionindustryviewofthisproblem,wenotethatthe

architectureofabuildingisdevisedbyanArchitectasa‘‘grandplan’’[6]ofwhatistobebuilt

—thearchitectureisthecentralartefactofthedesignprocess.Analysisofpoorlyunderstood

requirementsisstillimportant,butitisnotundertakeninisolationwithoutthedesignbeing

considered,atleasttosomeextent.Requirementsareexpectedtochangeastheproblembecomes

betterunderstoodandarethemselvesmergedwithstatementsconcerningthesolution[7].

InthiswaytheArchitectbuildsupanevolvabledescriptionofthesolutiontotheproblem—

thedesignisprogressivelyshapedastherequirementsbecomeclearer.Requirementsissueswhich

wouldonlyberelevantintermsofcertaindesigndecisionsaredelayeduntilthosedecisionshave

beenmade—forexample,thedetailedrequirementsforafloor-to-floormovingpathwaywould

onlybeconsideredoncethefloorsthemselveshadbeencommittedtoinadesignsense.The

resultantarchitectureisthenusedasaworkplanfortheactualimplementationaswellasproviding

an‘assuredyardstick’withwhichtomeasurethecorrectnessofthebuildingconstruction.Inthis

waythearchitectureisabletoactasthebasisforcontractualagreementbetweenthecustomerand

thedeveloper.

ThisshouldbecontrastedwithconventionalSoftwareEngineeringwisdomwherethe

requirementsspecificationisusuallywhatisagreedto—whichisessentiallywhatthedeveloper

thinksthatthecustomerthinksiswanted.Thereisadifferenceinemphasisbetweenthetwo

industries:theimportanceofrequirementsinSoftwareEngineeringasopposedtoarchitecturein

CivilEngineering.

Amajortenetofourworkisthatasimilarphilosophyneedstobe,andcanbe,usedin

developingsoftwaresystems,especiallydistributedreal-timesystemswherewhatisrequiredis

heavilycontingentuponwhatcanberealised(suchanapproachacknowledgestherealitiesand

constraintsofconcurrentengineering).Withinthiscontextonecanconsideracomputational

architectureashavingtoservetwopurposes:

1.Itshouldincludealloftheinformationnecessarytosubsequentlyalloweachpartofthe

systemtobedevelopedindependently.

2.Itshouldtellyoueverythingyouneedtoknowtoshowthattherequirementswillbesatisfied

ifandonlyifthecomponentsareimplementedasspecified.

Inordertoallowforsubsequentdevelopment,thenotationusedtodescribethearchitecture

mustbesufficientlycompletetoallowfortherepresentationandmanipulationofallrelevant

information.Itisimportantthatthearchitecturaldesignnotationisnot‘‘representationally

myopic’’[8]—itneedstobecapableofrepresentingtheissuesthatcaninfluenceandeffecta

distributedreal-timesystem’sdesign[2].Thecompletenessalsoprovidesconfidencefromthe

assessmentthatmustbemadeindeterminingwhetherthearchitecturedescribesasuitablesolution

tothegivenproblemdefinition.Ifalltherelevantinformationconcerningsubsequentconstruction

hasbeendeclared,thentechniquesshouldbeavailablefordecidingwhetherthesolutionisgoing

tobeanadequateonewithouthavingtoimplementit.Clearlythisisanidealisedview—butour