Quasimodo Industrial Handbook on Quantitative Modeling and Analysis for Embedded Systems

241 Pages·2011·4.92 MB·English

ICT-FP7-STREP-214755/
QUASIMODO
3rdJune2011
Page1of242
Projectno.: ICT-FP7-STREP-214755
Projectfulltitle: QuantitativeSystemPropertiesinModel-DrivenDesign
ProjectAcronym: QUASIMODO
Deliverable no.: D5.12
Title of Deliverable: Industrial Handbook
ContractualDateofDeliverytotheCEC: Month39
ActualDateofDeliverytotheCEC: June1,2011
Organisationnameofleadcontractorforthisdeliverable: ESI
Author(s):
BrianNielsen,KimG.Larsen
JanTretmans
Participants(s): AllPartners)
Workpackagecontributingtothedeliverable: WP1-5
Nature: R
Version: 1
Totalnumberofpages: 242
Startdateofproject: 1Jan. 2008 Duration: 40months
Projectco-fundedbytheECwithintheSeventhFrameworkProgramme(2007-2013)
DisseminationLevel
PU Public X
PP Restrictedtootherprogrammeparticipants(includingtheCommissionServices)
RE Restrictedtoagroupspecifiedbytheconsortium(includingtheCommissionServices)
CO Confidential,onlyforconsortiummembers(includingtheCommissionServices)
Abstract:
ThusdeliverablecontainsthelatestdraftoftheQuasimodoIndustrialHandbook. Itiscontinuously
updated on the internal Quasimodo Web-pages, and will be printed by Springer Verlag, Automn
2011.
Keyword list: Modeling, Analysis, Testing, Synthesis, Timing, Probabilities, Performance
analysis,Tools,CaseStudies
ICT-FP7-STREP-214755/QUASIMODO Page2of2 Confidential
Contents
1. IntroductionbyBrianNielsen,JanTretmans,andKimLarsen 1
2. ModellingReal-TimeSystemsusingUppaalbyFritsVaandrager 18
3. MoreFeaturesinUPPAALbyAlexandreDavidandKimG.Larsen 49
4. IndustrialApplicationofUppaal: ThegMACSynschronizationProtocolby
MathijsSchuts,FengZhu,FaranakHeidarianandFritsVaandrager 77
5. Design of a Sage Real-Time Embedded System in Uppaal: The Self-
Balancing Scooter Case by Bert Bos, Jiansheng Xing, Teun van Kuppeveld,
andMarcelVerhoef 95
6. An Introduction to Schedulability Analysis using Timed Automata by Al-
exandreDavid,ArneSkou,andKimLarsen 107
7. Schedulability Analysis using UPPAAL: The Herschel/Planck Satellite
SoftwareCasebyMariusMikucionis,BrianNielsen,KimLarsen 119
New: Time and Cost Optimal Schedulling and Planning by Nicolas Markey,
PatriciaBoyerandKimG.Larsen 133
8. An Introduction to Automatic Synthesis of Discrete and Timed Control-
lersbyJean-FrancoisRaskin,FranckCassez,Pierre-AlainReynier,KimLarsen133
9. TimedControllerSynthesis: AnIndustrialCaseStudy(TheHydacCase)by
Jean-FrancoisRaskin,FranckCassez,Pierre-AlainReynier,KimLarsen 150
10. Probabilistic Analysis of Embedded Systems by Arnd Hartmanns, Joost-
PieterKatoen,HolgerHermanns 170
11. EnergyConsumptionintheChessWSN:AMoDeSTCaseStudybyHaidi
Yue,Joost-PieterKatoen,HolgerHermanns 184
12. Model-BasedTestingbyJanTretmans,BrianNielsen 201
13. Model-Based Protocol Conformance Testing: The Case of the Chess
Wireless Sensor Network Node by Marcel Verhoef, Jan Tretmans, Axel Belin-
fante 226
14. Experiences with Formal Engineering: Model-Based Specification, Im-
plementation,andTestingofaSoftwareBusatNeopostbyMarie¨lleStoelinga,
MartenSijtema,AxelBelinfanteandLawrenceMarinelli 226
15. Perspectives byKimLarsen 240
2
Introduction
KimG.LarsenandBrianNielsenandJanTretmans
Abstract Theengineeringofhighqualityembeddedsystemsischallengingdueto
theeverinreasingdemandsforintelligentfunctionalitythatmustoperateefficiently
andcorrectlyundertightresourceconstraints.
Theresultingcomplexityandpressurefortimetomarketcallsfornewengineer-
ing methods and tools that supports early and integrated analysis of the systems
behavior,performance,andreliability.
This handbook presents a set of promising advanced model-based engineering
techniques and tools that goes beyond functionality and also address quantitative
system properties. The book introduces specific techniques and tools for model-
based analysis, synthesis and testing of timed and stochastic system properties.
Moreover, it shows how to apply the techniques to solve complex industrial cast
studies.
Thehandbookistargetedtowardstheprofessionalembeddedsystemsengineer,
whowouldliketobeintroducedtopromisingadvancedtechniquesforquantitative,
model-based analysis of embedded systems, what techniques are available, which
are mature enough to be applied, how they can be applied, and what benefits can
be expected from using such a method, technique, or tool. The book introduces
modellingandanalysisfromfirstprinciples,andadvancesthistomorespecialised
applications.
BrianNielsen
AalborgUniversity,Aalborg,Denmark,e-mail:[email protected]
JanTretmans
EmbeddedSystemsInstitute,Eindhoven,TheNetherlands,e-mail:[email protected]
1
Page 1
2 KimG.LarsenandBrianNielsenandJanTretmans
1 Motivation
During the design and construction of a modern complex embedded system the
engineerdeterminesthebestwaytoturntherequirementsintoasystemdesignand
further materialize this into a concrete implementation. At the same time he must
asses whether his solution proposals are safe, efficient, and reliable. The engineer
is thus continuously evaluating the consequences of different proposed solutions,
andisfacedwithanumberofconcretequestionsaboutthedesign,algorithm,and
implementation.
Someexamplesofsuchquestionsthatcanbeaddressedbyapplyingthetechniques
proposedinthisbookare:
• Doesasetofcomposedcomponentscorrectlyimplementthedesiredbehavior?
Arethereunforeseenracesordeadlocks?Istheend-to-endtimingofthesystem
adequate to safely operate under the time constraints of the physical environ-
mentofthesystem.E.g.,isitpossiblethataSegwaymaythrowitsuseroutof
balance?
• What collision rate can be expected for a given a wireless sensor network
mediumaccessprotocol?Andwhatminimumgapseparationshouldexistbe-
tweentwoslotstoavoidcollision?
• Is a collection of interaction tasks schedulable such that all tasks meet their
deadline? What is the slowest execution time that can be afforded while still
meetingdeadlines?
• Whatisthebestwaytocontrolahydraulicpumpsafelywhileminimizingits
energyconsumption?
• How should a set of tasks be mapped to a set of computational resources to
achieveoptimalspeedorminimalenergyconsumption?
It is inherent in embedded systems that they in addition to functional require-
ments have to meet a multitude of quantitative constraints. Whereas traditionally
developmentattentionandefforthasbeenfocusedonfunctionalcorrectnessofem-
beddedsystems,i.e.,qualitativepropertiessuchascorrectsystemresponsestogiven
stimuli,wecurrentlyseeanincreasingimportanceofquantitativeproperties1.These
propertiesinclude:
• precisetimingbehaviorandsufficientperformance
• lowenergyconsumption
• efficientuseofcomputationmemory,communication,andotherresources
• assumptionsaboutarrivalratesoftriggers
• availability,andotherprobabilisticaspects
Quantitativepropertiesarecrucialfortheoverallfunctioningofembeddedsys-
tems,yet,theyaredifficulttodesign,build,analyze,andtest.Inaddition,thequest
foreverbetterproductswithstricterquantitativeconstraints,tobedevelopedinless
1Inotherliteraturequantitativepropertiesaresometimesreferredtoas“non-functional“or“extra-
functional”properties.
Page 2
Introduction 3
timeandwithlesscosts,putshighdemandsonthedesignanddevelopmentprocess
offutureembeddedsystems.
Model-based, or model-driven2 development and engineering approaches use
models,orabstractions,fordesigning,reasoning,andanalysingsystems.
Itise.g.,seenintheEuropeanArtemisIndustryAssociation’sresearchagendaas
akeyenablerforthedevelopmentofhigh-qualitycomplexembeddedsystems[ARTEMISSRAWG(????a),
ARTEMISSRAWG(????b)]. During the last decade significant amounts of re-
search have been invested into methods, modeling tools, and powerful automated
analysisandsynthesistools.Theapproachesarealsogainingpopularityintheem-
beddedsystemsindustryandisappliedforspecifictasks.
However, most attention has been focused until now on modeling and analyz-
ing functional, qualitative properties. Existing model-based approaches and tools
areratherlimitedintheirhandlingofquantitativeconstraints.Hence,model-based
approachesmustbeextendedtohandlequantitativeproperties,inordertodevelop
embedded systems that are not only functionally correct but that also satisfy their
quantitativerequirements.
Itistheambitionofthisbooktointroducethereadertorecentmodel-basedmeth-
ods,techniquesandtoolsforthedesign,analysis,andtestingofquantitativeprop-
ertiesofembeddedsystems.Morespecifically,thebookdealswith
• modelingofdifferentfunctionalandquantitativeaspectsofembeddedsystems
liketime,energy,cost,probability;
• techniquesforanalysingmodelswithquantitativeinformation;
• synthesis and generation of controllers for systems with quantitative con-
straints;
• testingandtestgenerationforsystemimplementationswithrespecttoquanti-
tativemodels.
The book is intended for engineers and technical professionals involved in de-
signed,analyzing,andtestingembeddedsystemsinwhichquantitativeaspectsplay
amajorrole.Itisnotintendedtogiveafullscientifictreatmentofthearea.Where
appropriate references to further publications, such as journal and conference pa-
pers,aremade.
Thischapterintroducestheareaofmodel-based,quantitativeanalysisofembed-
dedsystem.Moreover,itintroducesthetopicspresentedinthedifferentchaptersof
thisbook,therelationsbetweenthetopics,andtheirdependencies,thusprovidinga
readingguidelineforthebook.
Theremainderofthechapterisorganizedasfollows.Section2givestheback-
groundforthebookbycharacterizingthechallengesofbuildingembeddedsystems
thatsatisfythemultitudeofquantitativedesignconstraints.Itdescribeshowmodel-
2Wedistinguishbetweenmodel-basedandmodel-drivendevelopment.Inmodel-drivendevelop-
mentalldevelopmentactivitiesarecenteredaroundanddrivenbymodelswithincreasingamounts
ofdetailuntilcode/hardwarecanbeeasilyobtained.Thisrepresentsalongtermvisionofanew
developmentapproach,butisalsoabigstepfromcurrentdevelopmentpractices.Inmodel-based
developmentmodelsareusedtosupportdevelopmentactivitiesbyautomatingspecifictaskslike
correctnesschecking,performanceanalysis,testgenerationetc.
Page 3
4 KimG.LarsenandBrianNielsenandJanTretmans
baseddevelopmentandtheuseofquantitativemodelsmayaddressthesechallenges.
ThisbookhasbeenwrittenanoutcomeofaEuropeanresearchproject,Quasimodo.
ThisisbrieflydescribedinSection3.Section4describesthestructureofthebook
andcontainsreadingguidelines.
2 Model-based,QuantitativeAnalysisofEmbeddedSystems
2.1 EmbeddedSystems
ToDo: ESI
research Embeddedsystemsaresystemsinwhichacomputerincludingsoftwareisembed-
agenda? : dedinsometechnicalorphysicalcontextorsystem.Theyarenotalwaysperceived
ToDo: Artist as computers: embedded computers may perform many tasks, but they are not al-
roadmap LNCS ways observed as such. The embedded computer controls the system, it observes
3436? : andchecksitsfunctioning,itmakescalculations,de-andencodesdata,itprocesses
data,e.g.,obtainedfromtheenvironmentviasensors,anditinfluencestheenviron-
mentbycontrollingactuators.
There is a great variation of embedded systems; many we use on a daily basis
withoutreallynoticingit(whentheywork).Othersaremoreexotic.Theyragefrom
consumer products, like electric shavers, and washing machines, to professional
equipmentlikewaferscanners.Somearemanufacturedinhundredthousandcopies
like mobile phones and television sets, whereas others are built only once, e.g., a
satelliteorastormsurgebarriercontrolsystem.Forsomeembeddedsystemssuch
asDVDplayers,watches,orhearingaids,theirmalfunctioningisannoyingandmay
costtheirmanufacturersmarketshare.Butifapacemakerorthebrakingsystemof
a car does not function as required, lives may be at stake, whereas an error in the
automaticpilotsystemofanaircraftorinthecontrolofanuclearpowerplantmay
causeacatastrophy.
Thus,therearemanydifferentapplicationdomains,butthemethodsdescribedin
thisbookaregeneralandnottargetedtowardsspecificdomains.Dependingonthe
riskofaparticularproductthemethodsmaybemoreorlessextensivelyapplied.
Software in embedded systems shares many characteristics. A first important
characteristic of embedded systems is that hardware and software have to interact
withtheirtechnicalandphysicalcontextinordertoperformsometaskorprovide
some service: multi-disciplinarity plays an important role. The development of an
embedded system requires the interaction of various technical disciplines such as
hardwareandsoftwareengineering,electricalandelectronicengineering,mechan-
icsandmechatronics,communicationtechnology,(nuclear)physics,dependingon
theapplicationdomain.Multi-disciplinaritymakesdesigningembeddedsystemsa
challengingtask.
A second characteristic of embedded systems is that they are very often time
critical.Whereasa2-seconddelayinthecalculationofaninsurancepremiumcal-
culation may annoy, a 2 second delay in delay in the trigger to close a valve in a
Page 4
Introduction 5
nuclearpowerplantcancauseacatastrophy.Embeddedsystemsarereal-timesys-
tems.
Inaddition,inordertodealwithdifferentconcurrentandinterrelatedtasksand
with different input streams, embedded systems are often realized as a large num-
ber of concurrent interacting software components individually tracking parts of
theenvironmentstate,andpossiblyrunninginparallelonmultipleexecutionunits.
concurrent.Thisgivesrisetointricatecommunicationandfailurescenarios.
Embedded systems often have special purpose components and hardware, such
asspecialpurposesensorsoractuators,adaptedtospecificcontexts.Embeddedsys-
temsalsomustbedevelopedwithlimitedresourcesandbudgettomeetsellingcost
targets.
Therefore,embeddedsystemstendtoquicklygrowintheircomplexity,bothin
thenumberofcomponentsofasystem,andinthecomplexityoftheindividualcom-
ponents.Itisconsequentlyverydifficulttocomprehendalltheinteractionsbetween
thecomponents,andinparticularavoidingundesiredinteractions,suchasheatpro-
ductionorelectromagneticinterference. ToDo: can we
really solve
this? :
2.2 QuantitativeProperties
Ontheonehand,embeddedsystemsmustperformthefunctiontheyaresupposedto
do(functionalrequirements),e.g.,openavalveunderhightemperatureconditions,
orreportthelocationofaflower-cart.
Ontheotherhand,embeddedsystemsmustalsosatisfyamultitudeofquantita-
tiveconstraintsasillustratedbyFigure1,thatdetermineshowwellitperformsits
functions.Byaquantitativeconstraintswemeanaconstraintthatcanbemeasured
and expressed as a number. Existing development techniques tend to emphasize
only functionality and is weak in correct construction of the quantitative aspects
[HenzingerandSifakis(2006)]. ToDo: maybe use
[Henzinger and Sifakis(2007)]
instead? :
Environment assumptions
•Timing constraints
•Hybrid behavior
•Arrival rates Communication 
Bandwidth Power
Compute 
resources
MMeemmoorryy
Service requirements
•QoS
••AAvvaaiillaabbiilliittyy Cost
•Fault tolerance
Fig.1:QuantitativeResourcesandConstraintsinEmbeddedSystems
Page 5
6 KimG.LarsenandBrianNielsenandJanTretmans
Aquantitativeconstraintoccursbecausetheenvironmentincludingusersofthe
systemshasanumberofdemandsontheresourcesofthesystem,whereasthesys-
temhasalimitedsetofavailableresourcestoperformitstask.
Oneimportantquantitativeaspectistheresponsetimeorlatencyofthesystem.
Sinceanembeddedsysteminteractswithaphysicalenvironmentitneedstokeepup
withthis.Inahardreal-timesystemnoviolationsofdeadlinescanbetolerated,ina
firmreal-timesystemdeadlinemissesareveryundesirable,butanoccasionalmiss
isnotcatastrophic.Inasoftreal-timesystemmostresponsetimesshouldbebefore
the deadline; sometimes the desired response times are further characterized by a
ToDo: probabilitydistributionofitsresponsetimeswithspecifiedmeansandpercentiles.
continuous Anotherexampleisthroughput(numberoftaskscompletedpertimeunit,num-
signals : ber of packets sent or received per time unit). Sometimes the term “goodput” is
usedtodistinguishsuccessfullycompletedtasksversusinitiatedtasks(todifferen-
tiate e.g., bandwidth of correctly received messages versus bandwidth used by the
sender and wasted due to collisions and message corruption). Again requirements
canbeformulatedinworst-caseorprobabilisticterms.
Further, reliability parameters (like (mean) time between failures and (mean)
time to repair), and availability (the fraction of time the system is correctly oper-
ational)arealsoquantifiable,butprobabilisticinnature.
Duringexecutionthesystemconsumesvariousresources.Thisincludesplatform
resources such as CPU-time, memory, bandwidth, and energy. But it may also be
scarceresourcesofthesystem’senvironmentsuchasspecialliftingcranes,mixing
stations, or mechanical wear that vary depending on the reactions of the system.
Theuseofthese/suchresourcescanbequantified,andtreatedgenerallyasdifferent
kindsofcosts.
Itisinterestingtonotethatthereoftenaretensionsbetweenthedifferentquanti-
ties,andconsequentlyengineeringtrade-offstobemade.Forinstance,itispossible
toimproveresponsetimebyusingafasterprocessor(orusingdynamicvoltagescal-
ing)butatthecostofasuperlinearincreaseinenergyconsumption.Thelatencyof
awirelesssensornetworkmaybeimprovedbutatacostofincreasingcollisionrate
andenergyconsumption.
It is an non-trivial engineering task to predict these quantities, and to optimize
andbalancethem.
To focus on quantitative aspects like performance, timeliness, and efficient
resource-usage, which are central to embedded systems, the models must provide
quantitative information such as information about timing, cost, data, stochastics
andhybridphenomena.
2.3 Modelsandmodel-baseddevelopment
In our basic approach for designing, analyzing, and testing embedded systems is
theuseofmodels.Amodelisanabstractviewofreality,inwhichessentialproper-
Page 6
Introduction 7
tiesarerecorded,andotherpropertiesanddetailsconsiderednotimportantforthe
problemathand,areremoved.
Anevery-dayexampleofamodelisaroadmap:aroadmaponlycontainslines
representing roads, and circles representing cities. The map abstracts from many
other details of reality, such as buildings, forests, railways, mountains, the width
and the kind of pavement of roads, et cetera. Such a map, i.e., a model, may very
well help with planning your trip by car from Brussels to Paris, because all rele-
vant details for such a trip are there. For planning a railway trip, however, or for
calculating the altitude difference between Brussels and Paris, such a road map is
useless.Anothermap,i.e.,anothermodelwithotherabstractions,isneededsuchas
arailwaymap,orageographicmap,respectively.
As another example consider civil engineers building large complex structures
like bridges. Here it is customary (mandatory) to use and analyze various model
beforeconstruction.Forinstance,astaticloadmodelisusedtopredictwhetherthe
bridgecansustainitselfandacertainnumberofcars.Adynamicmodelisusedto
investigatethedynamiceffectsofwindandmovingcarsandtrucks.
(a)Engineringmodelofabridge. (b)Abridgeimplementation
Fig.2:Civilengineeringanalogy.
Insoftwareengineeringmodelsnowadaysemphasizethestructureofthesystem
(i.e.,therelationshipsbetweenitscomponents),butverylittleanalysis,calculation,
and prediction about the behavior and performance of the system is being made.
Satirically3speaking,ifsoftwareengineersmadebridgestheywouldstartimmedi-
atelybypouringconcrete,andthenextmorningrunaheavytruckontothebridgeto
testitsloadcarryingcapabilities.Mostlikelyitcrashes,sotheyrebuildthebridge
slightlystrongerinthetroublesomearea.Incontrast,usingmodelsforpredictionis
partofanymatureengineeringdiscipline.
Models can be analyzed, they can be the basis for calculations, they can help
inunderstandingaproblem,theycanformthebasisforconstructingasystem,for
3Longman’sdictionaryofcontemporaryEnglish:awayofcriticizingsomethingsuchasagroup
ofpeopleorasystem,inwhichyoudeliberatelymakethemseemfunnysothatpeoplewillsee
theirfaults.
Page 7
8 KimG.LarsenandBrianNielsenandJanTretmans
testing it, or for diagnosing it, and when they are expressed in an executable lan-
guage,theycanbesimulated(simulationmodels).Modelscanbemadeapriorito
guideandanalyzethedesign,oraposterioritoanalyze,test,ordiagnoseanexist-
ingsystem.Differentmodelscanbemadeofthesamesystem,eachfocusingona
different kind of properties, e.g., a functional model, a performance model, or an
ToDo: Relate to energy-consumptionmodel.
OMG’s MDA, and
AADL? :
(cid:1)(cid:65)(cid:65) Low (cid:65)(cid:65) (cid:1)
(cid:1) (cid:65) (cid:65) Analysis (cid:1)
(cid:1) (cid:65) (cid:65) (cid:1)
(cid:1) (cid:65) (cid:65) (cid:1)
(cid:1)Analysis(cid:65) (cid:65) Design (cid:1)
(cid:1) (cid:65) (cid:65) (cid:1)
Cost
(cid:1) Design (cid:65) (cid:65) Implement. (cid:1)
(cid:1) (cid:65) (cid:65) (cid:1)
(cid:1) (cid:65) (cid:65) (cid:1)
(cid:1) Implementation (cid:65) (cid:65) (cid:1)
Test
(cid:1) (cid:65) (cid:65) (cid:1)
(cid:1) (cid:65) (cid:65) (cid:1)
(cid:63)
(cid:1) Test&Measurement (cid:65) (cid:65) (cid:1)
(cid:1)(cid:1) (cid:65) High (cid:65)(cid:1)(cid:1)
(a)Traditional (b)Model-based.
Fig.3:EffortandCostinModelBasedDevelopment
In current development practice, comparatively more effort is spent in the later
developmentactivities,andontestinginparticular.Especiallythequantitativeprop-
erties are established by measurements and tests after the system has been built.
Thisisunfortunately,becausecorrectionsorpursuingalternativesrequirecostlyre-
design,re-implementation,andre-testingiterations.Moreover,itiswellknownthat
defects are much more expensive to correct the later they are found (most costly
duringdeployment).ThisisschematicallyshowninFigure3a.
It is the thesis that by putting more effort into early analysis and design explo-
rationlessemphasisisrequiredlatebecauseoflesstestingandtuningasdepicted
inFigure3b.Theresultisoveralllesscost.
Inmostprojects,requirementschange(orarediscovered)duringsystemdevelop-
ment. Model based development accommodates this well; obviously models must
be updated, but making these changes and (automatically) analyzing their conse-
quencesiseasierandcheaperatthelevelofmodelsthanoncompletedesignsand
implementations.
ItisbeyondthescopeofthisbooktodiscusslifecyclemodelsliketheV-model,
multiple-V,iterative,agile,etc. butweremarkthatmodelbaseddevelopmentgoes
wellinhandwithiterativeandagiledevelopmentmethods.Modelsmaybegrown
andrefinediterativelylikeotherdesignandimplementationartifacts.
Page 8