This section presents the Danfossowmeter system modelled inthe project.
Theoverallarchitectureofthesystemisdescribedrst,followedbyadescription
of the communication protocols. We describe themain issuesinthe design of
the owmeter system, and nally we list some of the most crucial properties
whichtheowmetersystem isrequiredto full.
7.3.1 System Architecture and Communication Protocols
Figure 7.1showstheoverall architectureoftheowmetersystem. Aowmeter
system consists of one or more modules connected via a Controller Area
Net-work (CAN) [62]. Each module consists of a numberof processes called CAN
Applications(CANAPPs)and adriverthat interfacesthemoduleto theCAN.
Figure7.1showsan exampleofaowmetersystemconsistingofthreemodules
containingtwo,three,andfourCANAPPs,respectively. EachCANAPPinthe
system has a small piece of local memory which holds a number of so-called
attributes. Thecommunicationinthesystemconsistsofasynchronousmessage
passing between the CANAPPs. This message passing allows each CANAPP
to read andwritetheattributes of theother CANAPPs.
CANAPP
CANAPP CANAPP CANAPP
DRIVER DRIVER
MODULE 1 MODULE 2
CAN
CANAPP CANAPP
DRIVER MODULE 3
CANAPP
CANAPP
CANAPP
Figure 7.1: Overallarchitectureof theowmetersystem.
The concrete location of the CANAPPs and the number of modules are
exible, e.g., ina systemwith fourCANAPPs itis possibleto puteach of the
CANAPPsinanindividualmoduleortohavetwomoduleswithtwoCANAPPs
each. A typical owmetersystem consistsof 3-10 CANAPPs and 1-5modules
depending on the location of the CANAPPs. It is, however, important to
mentionthatthelocationoftheCANAPPsisxedduringtheoperationofthe
owmetersystem, i.e., itisnotpossibleforone CANAPPto migratefromone
module to another module. In the rest of this paper we will use the notation
CANAPP
(i;j)
to denoteCANAPPj onmodulei. Similarly,wewilluseDriver
j
to denote thedriveronmodulej,andModule
j
to denote module j.
ThecommunicationbetweentheCANAPPsisbasedonaprotocol
architec-ture withthree layers. Thelayersconstitute acollapsedform ofthe OSIseven
layerarchitecture,mappingontothephysical,datalink,andapplicationlayers
of theOSIReference Model [25].
Allcommunication in theowmeter system consists of asynchronous
mes-sage passing between the CANAPPs. We will illustratea representative
com-municationpatternshortly. ThedierentmessagetypesarelistedinTable7.1.
Table 7.1: The message typesand theirfunction.
Message Function
ReadRequest Requestto readan attributeofanotherCANAPP
ReadResponse Response to aReadRequestcontaining thevalue
ofan attribute
WriteRequest Requestto writean attributeof anotherCANAPP
WriteResponse Response to aWriteRequestindicatinga change
ofan attribute
Broadcast Distributea value to all otherCANAPPs inthe
system(withoutacknowledgement from each driver)
Event Distributea value to all otherCANAPPs inthe
system(with acknowledgement from each driver)
use. The Read messages (ReadRequest and ReadResponse) and the Write
mes-sages (WriteRequest and WriteResponse) are used in point-to-point
communica-tion between the CANAPPs, whereas the Broadcast and Event messages are
usedinbroadcast communication. In point-to-point Read(Write)
communica-tion,aReadRequest(WriteRequest)issenttoread(write)theattributeofanother
CANAPP. A ReadResponse (WriteResponse) is then generated by the receiving
CANAPP containing either the value of the attribute (in case of a read
mes-sage) or just a value indicating an accept (in case of a write message). The
delivery of the point-to-point messages is guaranteed by use of an
acknowl-edgementmechanisminthecommunicationbetweenthedrivers. TheBroadcast
and Eventmessages areused to distributeinformation to all CANAPPs in the
owmeter system { either as a Broadcast message without any guaranty of
de-livery,orasan Eventmessage,withguaranteed delivery.
Atypicalpoint-to-pointcommunicationinaowmetersystemconsistingof
two CANAPPs located indierent modulesis shown inthe MSC in Fig. 7.2.
TheMSCillustratesawritecommunicationbetweentwoCANAPPslocatedin
dierent modules. The MSC is identical to the kindof MSCs used intensively
inphaseone of theproject.
TheMSCcontainsaverticallineforeachofthetwoCANAPPs,thedrivers
ofthemodules,andtheCAN.Thearrowsbetweentheverticallinescorrespond
tomessagessentintheowmetersystem. Thecommunicationsequence
consid-eredcorresponds to a writerequest/response communicationto CANAPP
(2;1)
initiated by CANAPP
(1;1)
, and causes the following sequence of events to
oc-cur. Thenumbersinthelistbelowcorrespond tothenumbersfoundbelowthe
arrows and next to themarkon therightmostlineof Fig. 7.2.
1. CANAPP
(1;1)
generatesaWriteRequestmessagetobesenttoCANAPP
(2;1)
to writethe value ofan attribute, and passesthemessage to Driver
1 .
2. Driver
1
sendsthemessage on theCAN.
3. Driver receives themessage fromtheCAN.
WriteRequest
Figure 7.2: Writecommunicationbased onthe request/response mechanism.
4. Driver
2
generates an acknowledgement whichis sent on theCAN.
5. Driver
1
receivestheacknowledgement from theCAN.
6. Driver
2
deliverstheWriteRequestmessageto CANAPP
(2;1)
,whichaccepts
to have its attributewrittenbyCANAPP
(1;1) .
7. CANAPP
(2;1)
updates therequestedattribute.
8. CANAPP
(2;1)
now generates a WriteResponsemessage indicatingthat the
attributehasbeenupdated. Theresponseis handedto Driver
2 .
9. Driver
2
sendsthemessage on theCAN.
10. Driver
1
receivestheWriteResponsemessage fromthe CAN.
11. Driver
1
generates an acknowledgement whichis sent on theCAN.
12. Driver
2
receivestheacknowledgement from theCAN.
13. Driver
1
deliverstheWriteResponsemessagefromCANAPP
(2;1)
toCANAPP
(1;1) .
7.3.2 CANAPP Design Patterns
When two CANAPPs communicate they do it in an asynchronous way as
il-lustrated above. When receiving a ReadRequest (WriteRequest) a ReadResponse
(WriteResponse) is generated and sent back to thesender of therequest. When
designingtheowmetersystemDanfossusedtheOctopusmethod[5]. This
methoddescribestwodierentdesignalternatives/patternsforsuchasynchronous
communication between objects (processes). The two design alternatives are
calledInternal Wait PointandPrimary Wait Point. Belowwe brieydescribe
InternalWait Point (IWP) approach. When aCANAPPsendsa request
the execution of the CANAPPis blocked. If the CANAPPis located in
the same module asother CANAPPs,then allCANAPPs in themodule
are blocked. The CANAPPs are not released untila response matching
the request hasbeenreceived.
Primary Wait Point (PWP) approach. Inthisapproachtheresponse
mes-sage is treated as an event. The requesting CANAPP and all other
CANAPPsresidinginthesamemodulearenotblockedasintheIWP
ap-proach. This meansthata CANAPPcan receive a request from another
CANAPP even ifit istemporarily waiting foraresponseto apreviously
sent request. Thisis typicallyimplementedbymeansof two threads.
AsidentiedinpracticaltestsatDanfoss,theCANAPPsneedto becarefully
designed,e.g.,toavoiddeadlocks. Thisleadstotheformulationofthreecrucial
propertieswhichthenaldesignoftheowmetersystemis requiredto posses.
Thepropertiesaregivenhereinaninformalway. WewillshowinSect.7.5how
theycan betranslatedintodynamicpropertiesoftheconstructedCPN model.
Absence of Deadlocks. Itshouldnotbepossibletobringtheowmeter
sys-tem into a situationinwhichall the CANAPPsin theowmetersystem
are blocked.
Absence of Attribute Corruption. It is important for the correct
opera-tionoftheowmetersystemthatwhenaCANAPPhasinitiatedarequest
its attributes arenotmodiedbeforetherequest hasbeencompleted.
Topology Independence. Oneofmainadvantagesenvisionedforthe
owme-ter system was that it could easily be adapted to customers' needs by
providing exibilityin the choice asto which and how many CANAPPs
shouldgointothemodules. Itisthereforeimportantthatthetwo
proper-ties above are validindependentlyof how theCANAPPs are distributed
in themodules.