UNIVERSITETET I OSLO

Like dokumenter
UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Slope-Intercept Formula

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Unit Relational Algebra 1 1. Relational Algebra 1. Unit 3.3

Neural Network. Sensors Sorter

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Oppgave 1a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet.

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITY OF OSLO DEPARTMENT OF ECONOMICS

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

KROPPEN LEDER STRØM. Sett en finger på hvert av kontaktpunktene på modellen. Da får du et lydsignal.

5 E Lesson: Solving Monohybrid Punnett Squares with Coding

Call function of two parameters

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Databases 1. Extended Relational Algebra

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Eksamen i emnet Mat131 - Differensiallikningar I Onsdag 25. mai 2016, kl.

Trigonometric Substitution

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Han Ola of Han Per: A Norwegian-American Comic Strip/En Norsk-amerikansk tegneserie (Skrifter. Serie B, LXIX)

INF 3230/4230 Forelesning 9: Omskrivningslogikk

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO

Hvor mye teoretisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye)

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Exercise 1: Phase Splitter DC Operation

Speed Racer Theme. Theme Music: Cartoon: Charles Schultz / Jef Mallett Peanuts / Frazz. September 9, 2011 Physics 131 Prof. E. F.

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

PARABOLSPEIL. Still deg bak krysset

GYRO MED SYKKELHJUL. Forsøk å tippe og vri på hjulet. Hva kjenner du? Hvorfor oppfører hjulet seg slik, og hva er egentlig en gyro?

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

EN Skriving for kommunikasjon og tenkning

UNIVERSITY OF OSLO DEPARTMENT OF ECONOMICS

UNIVERSITETET I OSLO

Gir vi de resterende 2 oppgavene til én prosess vil alle sitte å vente på de to potensielt tidskrevende prosessene.

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Dynamic Programming Longest Common Subsequence. Class 27

Eksamen ENG1002/1003 Engelsk fellesfag Elevar og privatistar/elever og privatister. Nynorsk/Bokmål

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

GEO231 Teorier om migrasjon og utvikling

Graphs similar to strongly regular graphs

Den som gjør godt, er av Gud (Multilingual Edition)

Moving Objects. We need to move our objects in 3D space.

Hvor mye teoretisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye)

Kartleggingsskjema / Survey

Trådløsnett med. Wireless network. MacOSX 10.5 Leopard. with MacOSX 10.5 Leopard

Du må håndtere disse hendelsene ved å implementere funksjonene init(), changeh(), changev() og escape(), som beskrevet nedenfor.

C13 Kokstad. Svar på spørsmål til kvalifikasjonsfasen. Answers to question in the pre-qualification phase For English: See page 4 and forward

UNIVERSITY OF OSLO DEPARTMENT OF ECONOMICS

Endelig ikke-røyker for Kvinner! (Norwegian Edition)

The exam consists of 2 problems. Both must be answered. English

EKSAMENSOPPGAVE I SØK 1002 INNFØRING I MIKROØKONOMISK ANALYSE

Hvordan føre reiseregninger i Unit4 Business World Forfatter:

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

0:7 0:2 0:1 0:3 0:5 0:2 0:1 0:4 0:5 P = 0:56 0:28 0:16 0:38 0:39 0:23

Physical origin of the Gouy phase shift by Simin Feng, Herbert G. Winful Opt. Lett. 26, (2001)

Perpetuum (im)mobile

Level-Rebuilt B-Trees

IN2010: Algoritmer og Datastrukturer Series 2

buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

// Translation // KLART SVAR «Free-Range Employees»

Andrew Gendreau, Olga Rosenbaum, Anthony Taylor, Kenneth Wong, Karl Dusen

FYSMEK1110 Eksamensverksted 23. Mai :15-18:00 Oppgave 1 (maks. 45 minutt)

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Dagens tema: Eksempel Klisjéer (mønstre) Tommelfingerregler

UNIVERSITETET I OSLO ØKONOMISK INSTITUTT

Oppgave. føden)? i tråd med

HONSEL process monitoring

UNIVERSITY OF OSLO DEPARTMENT OF ECONOMICS

Du kan bruke det vedlagte skjemaet Egenerklæring skattemessig bosted 2012 når du søker om frikort.

Information search for the research protocol in IIC/IID

Hvor mye praktisk kunnskap har du tilegnet deg på dette emnet? (1 = ingen, 5 = mye)

TMA4329 Intro til vitensk. beregn. V2017

1 User guide for the uioletter package

Modellering av kommuniserende systemer i Maude

Syntax/semantics - I INF 3110/ /29/2005 1

Utstyr for avstandsmåling. Dommersamling 14. mars 2015 Stein Jodal

Verifiable Secret-Sharing Schemes

Endringer i neste revisjon av EHF / Changes in the next revision of EHF 1. October 2015

Søker du ikke om nytt frikort/skattekort, vil du bli trukket 15 prosent av utbetalingen av pensjon eller uføreytelse fra og med januar 2016.

MID-TERM EXAM TDT4258 MICROCONTROLLER SYSTEM DESIGN. Wednesday 3 th Mars Time:

TDT4117 Information Retrieval - Autumn 2014

Transkript:

UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF 3230/4230 Formell modellering og analyse av kommuniserende systemer Eksamensdag: 8. juni 2006 Tid for eksamen: 9.00 12.00 Oppgavesettet er på 13 sider. Vedlegg: Ingen Tillatte hjelpemidler: Alle trykte og skrevne Kontroller at oppgavesettet er komplett før du begynner å besvare spørsmålene. Oppgavene og deloppgavene kan til en stor grad løses uavhengig av hverandre. Om det er en deloppgave du ikke har løst, så kan du anta at du har løst den og gå videre i settet. Legg vekt på å finne enkle og elegante løsninger (selv om dette skulle gå på bekostning av effektivitet)! Poengtallene angitt i parentes for hver deloppgave er veiledende. Alle svar skal begrunnes. English! This exam is given in English after the Norwegian part, from page 8 onwards. (Fortsettes på side 2.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 2 Oppgave 1 Swapping (18 poeng) Gitt følgende Maude modul: mod SWAP is protecting NAT. sort NatList. subsort Nat < NatList. op nil : -> NatList [ctor]. op : NatList NatList -> NatList [ctor assoc id: nil]. vars M N : Nat. var L : NatList. crl [swap] : M N => N M if N < M. op init : -> NatList. eq init = 8 2 6 54 2 0 3. endm 1a Reduksjon (2 poeng) Hva er resultatet av å kjøre Maude kommandoen red init. (Ingen begrunnelse nødvendig.) 1b Omskrivning (2 poeng) Hva er resultatet av å kjøre Maude kommandoen rew init. (Ingen begrunnelse nødvendig.) 1c Parallelle steg (3 poeng) Hva er det største antall bruk av regelen swap som kan foretas i ett parallelt steg på tilstanden init? (Du trenger ikke bevise ditt svar i detalj, men forklar kort hvilke regelapplikasjoner som kan foretas i det første parallelle omskrivningssteget fra init.) (Fortsettes på side 3.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 3 1d Invarianter (8 poeng) En helt sentral invariant i systemet er følgende tilstandutsagn: elementene i (den aktuelle) tilstanden er akkurat de samme (og i samme antall) som i initialtilstanden. 1. Angi Maude-kommandoen som sjekker om tilstandsutsagnet over er (en) invariant med hensyn til initialtilstanden init. Du må selvfølgelig definere eksplisitt eventuelle hjelpefunksjoner og nye sorter. 2. Hvilket svar vil Maude gi på din Maude-kommando? 1e Sluttilstander (3 poeng) Anta nå at vi modifiserer regelen swap til crl [swap] : M N => N M if N <= M. For å undersøke det modifiserte systemet, gir vi kommandoen search init =>! L:NatList. Vil denne søkekommandoen terminere? I så fall: hva vil svaret være? Oppgave 2 Trådløse Sensornettverk (45 poeng) Et trådløst sensornettverk består av en mengde små, billige batteridrevne datamaskiner, kalt sensornoder, som er utstyrt med sensorer som kan observere fenomener som magnetisme, røyk/varme, seismisk bevegelse, etc. En sensornode er også utstyrt med en svak radiosender og -mottaker, slik at sensornoder kan kommunisere med hverandre vha radio. For eksempel innfører man trådløse sensornettverk i California for kjapt å oppdage og varsle om skogbranner. Vi skal i denne oppgaven hjelpe Californiske myndigheter ved å modellere et slikt sensornettverk som skal varsle om brann. Vi antar for enkelhets skyld at sensorene er plassert i et flatt (to-dimensjonalt) område på størrelse Xsize Ysize. 1 En sensornode er identifisert ved sin lokasjon. Kommunikasjon i slike noder er altså ved radio, hvor enhver node har en urettet antenne. Den sender altså ut radiosignaler i alle retninger. For å spare batteri (og pga. den svake senderen) vil radiosignalet kun kunne mottas med tilstrekkelig styrke av noder som ligger innenfor en distanse transmissionrange fra senderen. Merk at en sensornode ikke kjenner sine naboer. 1 Det er helt trivielt å utvide vår løsning til et tre-dimensjonalt rom. (Fortsettes på side 4.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 4 2a Lokasjoner (6 poeng) Vi deklarer lokasjoner og transmissionrange på følgende måte: sort Location. op _._ : Nat Nat -> Location [ctor]. --- Some parameters of the system: ops transmissionrange Xsize Ysize : -> Nat. eq transmissionrange = 10. eq Xsize = 100. eq Ysize = 100. En lokasjon er altså en term x.y, hvor 0 x Xsize og 0 y Ysize. Merk at distansen mellom to lokasjoner x.y og x.y ifølge barneskole-geometri er gitt ved (x x ) 2 + (y y ) 2. 1. Definer en funksjon op _withintransmissionrangeof_ : Location Location -> Bool. slik at l withintransmissionrangeof l er true hvis og bare hvis avstanden mellom l og l ikke er større enn transmissionrange. (Hint: du trenger ikke bruke fancy matematiske operasjoner som kvadratrot, etc.) 2. Definer en sort LocationSet av mengder (ikke multisett!) av Location-elementer. Definer også en funksjon op _in_ : Location LocationSet -> Bool. som sjekker hvorvidt en Location er med i en mengde. Vår algoritme og noen klasse-deklarasjoner I en stor Californisk skog kan skogbranner oppstå på flere ulike steder, og vårt glimrende system skal notere dem alle. Vi har to slags objekter: sensornoder av en klasse WSNode, og en base-stasjon (eller brannstasjon) av en klasse FireStation. Brannstasjonen mottar meldinger fra nærliggende sensornoder om hvor det brenner, og lagrer lokasjonen til enhver brann. For å simulere et system, må vi også ha noen branner! Vi har derfor ett ekstra objekt (en pyroman ) av en klasse FireGenerator som lager branner. Disse tre klassene er deklarert som følger: (Fortsettes på side 5.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 5 class WSNode firesseen : LocationSet. class FireStation firelocations : LocationSet. class FireGenerator firelocations : LocationSet. Disse klassene skal helst ikke ha flere attributter, om det kan unngås. Du kan imidlertid deklarere tomme super- eller subklasser om du føler for det. Merk altså at en FireStation har en radiomottager som kan motta meldinger på samme måte som en WSNode. Derimot skal ikke vårt FireGenerator-objekt kunne få meldinger. Algoritmen som skal modelleres er en triviell flooding-algoritme beskrevet som følger: I sitt firelocations attributt har FireGenerator-objektet lokasjonen til alle brannene som skal oppstå i systemet. For hver brann (dvs lokasjon l), sender FireGenerator en melding med innhold fireat(l) som kan leses av enhver node (enten WSNode eller FireStation node!) som ligger innenfor en avstand transmissionrange fra brannstedet l. (Dette tilsvarer at en sensor i WSNoden oppdager brannen.) Meldingene som skal sendes rundt har altså innhold fireat(l): sort MsgContent. op fireat : Location -> MsgContent [ctor]. Når en WSNode mottar et signal med innhold fireat(l), så sjekker den om den allerede har sett et slikt signal om brann i lokasjon l. Hvis den allerede har fått kjennskap til brann i l tidligere, så gjør den ingenting. Hvis den ikke har fått slik kjennskap, så kringkaster noden fireat(l) til alle andre nodene som er innenfor dens transmissionrange. Når FireStation-objektet mottar en fireat(l) melding, så noterer den lokasjonen l i sitt firelocations attributt (og sender forhåpentligvis avgårde et brannslukkerhelikopter til lokasjonen l). Sensor-noder og brannstasjonen har ikke egne navn. Deres objekt-identifikatorer skal være deres lokasjoner. Det er kun FireGenerator objektet som skal ha et navn, nemlig FireGen: op FireGen : -> Oid [ctor]. subsort Location < Oid. 2b Modellering av kommunikasjon (11 poeng) I denne deloppgaven skal du modellere kommunikasjonsformen for dette trådløse sensornettverket: radiosending hvor alle objekter (med radiomottaker) innenfor en avstand transmissionrange mottar meldingen. Husk: en FireGenerator skal ikke bli tilsendt meldinger, men sender altså fireat(l) meldinger som skal mottas av enhver sensornode (Fortsettes på side 6.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 6 innenfor en avstand transmissionrange fra stedet l; en node kjenner ikke sine naboer; en brann kan skje akkurat der hvor en node er; og ved kringkasting skal ikke senderen få tilsendt meldingen den kringkaster. Modellerer den beskrevne kommunikasjonsformen (dvs. den nevnte formen av broadcast), og ta med alle nødvendige meldings- wrappers og andre deklarasjoner. (Denne deloppgaven kan sees i sammenheng med deloppgave 2d.) 2c Definisjon av initialtilstander (7 poeng) Vi skal nå definere initialtilstander, hvor vi kan plassere et ønsket antall n noder i (pseudo-) tilfeldige lokasjoner i området. I tillegg skal vi ha ett FireGenerator objekt FireGen med m branner i tilfeldige lokasjoner. Initialtilstanden skal til sist ha et FireStation objekt i en tilfeldig lokasjon. Anta gitt en funksjon random, slik at random(s) gir det første tilfeldige tallet med frø s, random(random(s)) gir det andre tilfeldige tallet, random(random(random(s))) gir det tredje tilfeldige tallet, etc. Definer en funksjon op init : Nat Nat Nat ->.... slik at init(n,m,s) generer en slik ønsket tilstand med n WSNoder plassert på pseudotilfeldige lokasjoner, m (pseudo-tilfeldige) brannsteder, og initialverdi til frøet s. For eksempel, i min implementasjon ga kommandoen (red init(5, 3, 1).) svaret {< FireGen : FireGenerator firelocations : (28. 19) ; (70. 82) ; (87. 38) > < 18. 60 : WSNode firesseen : none > < 46. 67 : WSNode firesseen : none > < 72. 53 : WSNode firesseen : none > < 78. 44 : WSNode firesseen : none > < 86. 92 : WSNode firesseen : none > < 95. 21 : FireStation firelocations : none >} 2d Modellering av algoritmen (12 poeng) Modeller algoritmen for det trådløse sensornettverket som ble beskrevet på sidene 4 og 5. 2e Invarianter (5 poeng) Gi en uformell (men presis) prosa beskrivelse av et tilstandsutsagn, som vi ønsker skal være invariant for systemet og som impliserer at FireStation har oppdaget alle brannene (Fortsettes på side 7.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 7 når det ikke er meldinger i systemet, og når FireGenerator ikke har fler branner å sende. (Du trenger ikke teste av din ønskede invariant i Maude.) (Hvorvidt utsagnet virkelig er en invariant avhenger av topologien; hvis vi har få noder så vil det kunne være branner som ligger for langt fra enhver sensornode til å bli oppdaget, og/eller kanskje det ikke er nok sensornoder til å formidle beskjeden helt til brannstasjonen.) 2f Konfluens (4 poeng) Er din (omskrivningslogikk-) spesifikasjon konfluent? En kort og god høynivå forklaring uten mye detaljer er tilstrekkelig her. Lykke til! Peter C. Ølveczky (Fortsettes på side 8.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 8 The exam in English The following pages present the (same!) exam exercises in English. The exercises can, to a certain degree, be solved independently of each other. If you have not solved an exercise, you may assume that you have solved it and can continue with other exercises. Emphasize simplicity and elegance in your solutions (even at the cost of computational efficiency of your specifications)! All answers should be explained/justified. Exercise 1 Swapping (18 points) Given the following Maude module: mod SWAP is protecting NAT. sort NatList. subsort Nat < NatList. op nil : -> NatList [ctor]. op : NatList NatList -> NatList [ctor assoc id: nil]. vars M N : Nat. var L : NatList. crl [swap] : M N => N M if N < M. op init : -> NatList. eq init = 8 2 6 54 2 0 3. endm Exercise 1a Reduction (2 points) What result do we get when executing the Maude command red init. (No explanation needed.) (Fortsettes på side 9.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 9 Exercise 1b Rewriting (2 points) What result do we get when executing the Maude command rew init. (No explanation needed.) Exercise 1c Concurrent Steps (3 points) What is the largest number of applications of the rule swap that can be performed in one concurrent step on the term init? (You do not need to prove your answer in detail, but only briefly explain which rule applications can be performed in the first concurrent rewrite step from init.) Exercise 1d Invariants (8 points) A crucial invariant in the system is the following state formula: the elements in the (current) state are the same (and with the same multiplicity) as in the initial state. 1. Give the precise Maude command that checks whether or not the above state formula is an invariant w.r.t. the initial state init. You have to explicitly define any auxiliary functions and/or sorts you may need. 2. What result will you get from executing your command in Maude? Exercise 1e Final States (3 points) Assume that we change the rule swap to crl [swap] : M N => N M if N <= M. To analyze the modified system, we give the command search init =>! L:NatList. Will the execution of this search command terminate? If so: what is the result? (Fortsettes på side 10.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 10 Exercise 2 Wireless Sensor Networks (45 points) A wireless sensor network consists of a set of small and cheap battery-powered computers, called sensor nodes. A sensor node is equipped with some sensing capability that allows the node to observe/detect some phenomenon such as smoke, heat, seismic movements, etc. A sensor node is also equipped with a low-powered radio transmitter and receiver, allowing sensor nodes to communicate with each other via radio to form a network. Wireless sensor networks are being introduced in southern California to help detect and locate forest fires. In this exercise we will help California by modeling such a fire-detecting sensor network. We assume for simplicity that the sensor nodes are located on a two-dimensional 2 surface in an area of size Xsize Ysize. A sensor node is identified by its location. Communication is, as mentioned, by radio, where the nodes do not have directed antennas. A node therefore broadcasts a radio signal in all directions. Due to the weak transmitter, the radio signal can only be received with sufficient strength by the nodes that are within a distance of transmissionrange from the sender. Note that a sensor node does not know its neighbors. Exercise 2a Locations (6 points) We declare locations and some constants as follows: sort Location. op _._ : Nat Nat -> Location [ctor]. --- Some parameters of the system: ops transmissionrange Xsize Ysize : -> Nat. eq transmissionrange = 10. eq Xsize = 100. eq Ysize = 100. A location is represented by a term x.y, with 0 x Xsize and 0 y Ysize. We remember from happy childhood days that the distance between two locations x.y and x.y is given by (x x ) 2 + (y y ) 2. 1. Define a function op _withintransmissionrangeof_ : Location Location -> Bool. such that l withintransmissionrangeof l is true if and only if the distance between l and l is less than or equal to transmissionrange. (You do not need to use fancy mathematical functions like square root.) 2 our model can be easily extended to the three-dimensional setting (Fortsettes på side 11.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 11 2. Define a sort LocationSet of sets of Location elements. That is, you should not define a multiset. Furthermore, define a function op _in_ : Location LocationSet -> Bool. that checks whether or not a Location is in a set. Our Algorithm and Some Class Declarations In the large Californian forests there may be fires at different locations, and our excellent system should discover them all. We have two kinds of objects: sensor nodes of the class WSNode, and a base station (or fire station) of the class FireStation. The fire station receives messages from nearby sensor nodes about the location of fires, and stores the location of each fire. To simulate our specification, we also need some fires! We have therefore added to our specification an additional object (a pyromaniac ) of a class FireGenerator that creates fires at different locations. These three classes are declared as follows: class WSNode firesseen : LocationSet. class FireStation firelocations : LocationSet. class FireGenerator firelocations : LocationSet. These classes should not have further attributes, if you can avoid it. However, you may declare empty sub- or superclasses if you feel like doing that. Notice that a FireStation is equipped with a radio receiver that can receive messages in the same way as a WSNode. Our FireGenerator object should not receive messages. The fire-reporting algorithm we will model in this exam is a trivial flooding algorithm described as follows: The FireGenerator object stores in its firelocations attribute all the fires that will take place in the system. For each fire (that is, for each location l in firelocations), the FireGenerator object sends a message with content fireat(l) that is received by each (WSNode or FireStation) node that is located within a distance of transmissionrange of l. (This models a sensor discovering a fire.) The messages that are communicated in our specification have content of the form fireat(l): sort MsgContent. op fireat : Location -> MsgContent [ctor]. When a WSNode receives a signal with content fireat(l), it checks whether it has already seen a fire report from this location, in which case it does nothing. If the node has not seen a fire reported at l, it broadcasts the fireat(l) message (to all the other nodes that are within its transmissionrange). (Fortsettes på side 12.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 12 When the FireStation object receives a fireat(l) message, it records the location l in its attribute firelocations (and hopefully sends a firefighting helicopter to that location). Sensor nodes and the fire station do not have names. Their object identifiers should instead be their locations. Only the FireGenerator should have a name, FireGen: op FireGen : -> Oid [ctor]. subsort Location < Oid. Exercise 2b Modeling Communication (11 points) In this exercise you should model communication for this kind of wireless network: radio transmission where each object (with a radio receiver) in the system within a distance of transmissionrange from the sender should receive the message. Remember: a FireGenerator object should not receive messages, but can send fireat(l) messages that should be received by each node within distance transmissionrange from l; a fire could happen anywhere in the area, also at the exact location of a node; a node does not know its neighbors; and the sender of a broadcast should not receive the message it is broadcasting. Model this form of broadcast communication, and define explicitly all necessary message wrappers and other declarations. Exercise 2c Defining Initial States (7 points) We will now define initial states, so that we can place n sensor nodes in pseudo-random locations in the sensing area. In addition, an initial state should have one FireGenerator object with m fires in random locations. Finally, the initial state should have one FireStation object in a pseudo-random location. Assume given a function random, so that, given a seed s, random(s) gives the first pseudo-random number, random(random(s)) gives the second pseudo-random number, random(random(random(s))) gives the third pseudo-random number, and so on. Define a function op init : Nat Nat Nat ->.... such that init(n,m,s) generates such a desired initial state with n WSNodes placed in pseudo-random locations, m (pseudo-randomly located) fires, and s the initial value of the seed. For example, in my specification, the command (red init(5, 3, 1).) returned the initial state (Fortsettes på side 13.)

Eksamen i INF 3230/4230, 8. juni 2006 Side 13 {< FireGen : FireGenerator firelocations : (28. 19) ; (70. 82) ; (87. 38) > < 18. 60 : WSNode firesseen : none > < 46. 67 : WSNode firesseen : none > < 72. 53 : WSNode firesseen : none > < 78. 44 : WSNode firesseen : none > < 86. 92 : WSNode firesseen : none > < 95. 21 : FireStation firelocations : none >} Exercise 2d Modeling the Algorithm (12 points) Model in (Full) Maude the wireless sensor algorithm described on pages 11 and 12. Exercise 2e Invariants (5 points) Give an informal but precise prose description of a state formula that we would like to be an invariant of the system, and which implies that the FireStation has recorded all the fires when there are no messages in the state, and when the FireGenerator does not have any more fires to send. (You do not need to test in Maude whether your state formula is invariant.) (Whether or not the formula actually is an invariant of the system depends on the topology: if there are too few nodes then there might be fires that are too far away from a sensor node to be discovered, and/or the nodes cannot forward the fire information to the fire station.) Exercise 2f Confluence (4 points) Is your (rewriting logic) specification confluent? A short and high level explanation without much detail is sufficient here. Good luck! Peter C. Ølveczky