Academia.eduAcademia.edu

Figure 46 – uploaded by Marielle Stoelinga

See full PDFdownloadDownload figure
Fig. 1 Synoptic view of the self-balancing scooter The following figure shows a simplified overview of the mechanical system.

Figure 1 Synoptic view of the self-balancing scooter The following figure shows a simplified overview of the mechanical system.

Related Figures (105)

Fig. 1: Quantitative Resources and Constraints in Embedded Systems On the other hand, embedded systems must also satisfy a multitude of quantita- tive constraints as illustrated by Figure 1, that determines how well it performs its functions. By a quantitative constraints we mean a constraint that can be measured and expressed as a number. Existing development techniques tend to emphasize only functionality and is weak in correct construction of the quantitative aspects {Henzinger and Sifakis(2006)].
Fig. 1: Quantitative Resources and Constraints in Embedded Systems On the other hand, embedded systems must also satisfy a multitude of quantita- tive constraints as illustrated by Figure 1, that determines how well it performs its functions. By a quantitative constraints we mean a constraint that can be measured and expressed as a number. Existing development techniques tend to emphasize only functionality and is weak in correct construction of the quantitative aspects {Henzinger and Sifakis(2006)].
Fig. 3: Effort and Cost in Model Based Development testing it, or for diagnosing it, and when they are expressed in an executable lan- guage, they can be simulated (simulation models). Models can be made a priori to guide and analyze the design, or a posteriori to analyze, test, or diagnose an exist- ing system. Different models can be made of the same system, each focusing on a different kind of properties, e.g., a functional model, a performance model, or an energy-consumption model.
Fig. 3: Effort and Cost in Model Based Development testing it, or for diagnosing it, and when they are expressed in an executable lan- guage, they can be simulated (simulation models). Models can be made a priori to guide and analyze the design, or a posteriori to analyze, test, or diagnose an exist- ing system. Different models can be made of the same system, each focusing on a different kind of properties, e.g., a functional model, a performance model, or an energy-consumption model.
Fig. 4: Establishment of quantitative properties using MDD. A main benefit of model-based development is that given a concise model, ad- vanced tools can analyze it and help automate a number of difficult engineering tasks, see Figure 4.
Fig. 4: Establishment of quantitative properties using MDD. A main benefit of model-based development is that given a concise model, ad- vanced tools can analyze it and help automate a number of difficult engineering tasks, see Figure 4.
Fig. 5: Structure of a simple transmission system
Fig. 5: Structure of a simple transmission system
Fig. 6: Sender and Receiver Components
Fig. 6: Sender and Receiver Components
Fig. 7: Different Quantitative Aspects of a Simple Transmission Medium
Fig. 7: Different Quantitative Aspects of a Simple Transmission Medium
Fig. 1.1 State space for 3 gossiping girls. Figure 1.1 shows a state-transition diagram or automaton for the simplified ver- sion of the problem in which there are 3 girls. A state consists of a 3 by 3 matrix knows that records for each girl the gossips she knows. If girl i knows the gossip of girl j then we write a | in the entry for row i and column j: knows[i][j] == Otherwise we write a 0: knows[i][j] == 0. In the initial state, at the top of the dia- gram, each girl only knows her own gossip, and hence there are 1’s on the diagonal and 0’s elsewhere. Transitions between states occur whenever girls have a conver- sation. In the initial state three transitions are possible: girls 1 and 2 call each other,
Fig. 1.1 State space for 3 gossiping girls. Figure 1.1 shows a state-transition diagram or automaton for the simplified ver- sion of the problem in which there are 3 girls. A state consists of a 3 by 3 matrix knows that records for each girl the gossips she knows. If girl i knows the gossip of girl j then we write a | in the entry for row i and column j: knows[i][j] == Otherwise we write a 0: knows[i][j] == 0. In the initial state, at the top of the dia- gram, each girl only knows her own gossip, and hence there are 1’s on the diagonal and 0’s elsewhere. Transitions between states occur whenever girls have a conver- sation. In the initial state three transitions are possible: girls 1 and 2 call each other,
Fig. 1.2 Solution for gossiping girls puzzle found by model checker Uppaal. Uppaal is available for free for non-commercial applications in academia and for private persons via www. uppaal .org. For commercial applications a commercial license is required, see www.uppaal.com. The software runs under Windows,
Fig. 1.2 Solution for gossiping girls puzzle found by model checker Uppaal. Uppaal is available for free for non-commercial applications in academia and for private persons via www. uppaal .org. For commercial applications a commercial license is required, see www.uppaal.com. The software runs under Windows,
Fig. 1.3 A jobshop (picture taken from [10)]).
Fig. 1.3 A jobshop (picture taken from [10)]).
1 A First Introduction to Uppaal Fig. 1.4 Uppaal after starting the toolkit.
1 A First Introduction to Uppaal Fig. 1.4 Uppaal after starting the toolkit.
mode : Jobber. Next we right click (with the Select tool) on the location which Uppaal has already placed in the drawing window. We can then give this location a name, for instance begin. Each automaton has at most one initial location, marked by a double circle. During simulation or in verifications the automaton will always start in this location. By checking the box Jnitial in the menu for a location, we specify that this location is the initial location of the automaton. The menu contains a cou ple of other fields and options Unvariant, Urgent and Committed), but for the moment we will not use these. Fig. 1.6 A first version of the model.
mode : Jobber. Next we right click (with the Select tool) on the location which Uppaal has already placed in the drawing window. We can then give this location a name, for instance begin. Each automaton has at most one initial location, marked by a double circle. During simulation or in verifications the automaton will always start in this location. By checking the box Jnitial in the menu for a location, we specify that this location is the initial location of the automaton. The menu contains a cou ple of other fields and options Unvariant, Urgent and Committed), but for the moment we will not use these. Fig. 1.6 A first version of the model.
Fig. 1.7 Declaration of system components. At this point, we have not specified in our model how the choice between the transitions from location begin to location easy, average or hard is made. Also, we have not specified how the choice between the transitions from loca- tion average to location work_av_mallet and work_av_hammer is made. Choices for which the model does not specify how they are resolved are called nondeterministic. Nondeterminism is very useful for maintaining a high level of abstraction in descriptions of the behavior of physical systems and machines [6].
Fig. 1.7 Declaration of system components. At this point, we have not specified in our model how the choice between the transitions from location begin to location easy, average or hard is made. Also, we have not specified how the choice between the transitions from loca- tion average to location work_av_mallet and work_av_hammer is made. Choices for which the model does not specify how they are resolved are called nondeterministic. Nondeterminism is very useful for maintaining a high level of abstraction in descriptions of the behavior of physical systems and machines [6].
Fig. 1.8 Screenshot of the simulator.
Fig. 1.8 Screenshot of the simulator.
Fig. 1.10 Models of hammer and mallet. We have now completed our first Uppaal model! We can open the model in the simulator and convince ourselves that it indeed behaves as specified in the informal description. Once we are satisfied with the model, we can save it by selecting in the File menu the option Save System As.... Uppaal models are stored as . xm1 files.
Fig. 1.10 Models of hammer and mallet. We have now completed our first Uppaal model! We can open the model in the simulator and convince ourselves that it indeed behaves as specified in the informal description. Once we are satisfied with the model, we can save it by selecting in the File menu the option Save System As.... Uppaal models are stored as . xm1 files.
Fig. 1.9 Model of jobber, extended with synchronization labels.
Fig. 1.9 Model of jobber, extended with synchronization labels.
Fig. 1.11 Screenshot of the Verifier. The Simulator is extremely useful for playing with a model and obtaining insight, but it does not answer questions like “Is it possible to reach a state in which (some given) property Bad holds”? Even if we have not seen a Bad state after hours of simulation, this does not guarantee that no such state exists! Fortunately, Uppaal’s Verifier allows us to rigorously answer this type of questions.
Fig. 1.11 Screenshot of the Verifier. The Simulator is extremely useful for playing with a model and obtaining insight, but it does not answer questions like “Is it possible to reach a state in which (some given) property Bad holds”? Even if we have not seen a Bad state after hours of simulation, this does not guarantee that no such state exists! Fortunately, Uppaal’s Verifier allows us to rigorously answer this type of questions.
Table 1.1 Some logical operators in Uppaal
Table 1.1 Some logical operators in Uppaal
Fig. 1.12. Model of jobber in which exactly J jobs are carried out. from begin to done, which is taken whenever jobs has reached the value J and al jobs are done.
Fig. 1.12. Model of jobber in which exactly J jobs are carried out. from begin to done, which is taken whenever jobs has reached the value J and al jobs are done.
Fig. 1.13. Model of conveyor belt that delivers 10 jobs.
Fig. 1.13. Model of conveyor belt that delivers 10 jobs.
Fig. 1.14 Model of jobber extended with a clock.
Fig. 1.14 Model of jobber extended with a clock.
Fig. 1.15 Fastest schedule for completing the 10 jobs. When Uppaal computes a diagnostic trace which demonstrates that this property is satisfied, this will, in general, not be the shortest trace. After all, we have only specified lower bounds for the timing in our model and no upper bounds. Thus the belt may wait indefinitely before delivering a job, a jobber may dawdle for days before he starts with the job, and for years before completing it. However, if we select in the menu Options under Diagnostic Trace the option Fastest, then Uppaal will produce the fastest execution that leads to the specified state. In the simulator we can see that in the final state of this execution now >= 100. This means that the jobbers need at least 100 time units to complete the 10 jobs. The easiest way to understand the schedule that has been computed by Uppaal is via the so-called “message sequence chart” in the lower right window of the simulator: here we see which jobber handles which job. Figure 1.15 visualizes this fastest schedule in an even more compact way as a “Gantt chart”.* We see that one jobber is permanently busy with the hammer, whereas the other jobber has a relaxed schedule in which he is idling most of the time but also completes some jobs with his hands or with the mallet. It is easy to come up with an equally fast schedule in which the work load is more evenly distributed. We may decide, for instance, to give the third job to Jobber2.
Fig. 1.15 Fastest schedule for completing the 10 jobs. When Uppaal computes a diagnostic trace which demonstrates that this property is satisfied, this will, in general, not be the shortest trace. After all, we have only specified lower bounds for the timing in our model and no upper bounds. Thus the belt may wait indefinitely before delivering a job, a jobber may dawdle for days before he starts with the job, and for years before completing it. However, if we select in the menu Options under Diagnostic Trace the option Fastest, then Uppaal will produce the fastest execution that leads to the specified state. In the simulator we can see that in the final state of this execution now >= 100. This means that the jobbers need at least 100 time units to complete the 10 jobs. The easiest way to understand the schedule that has been computed by Uppaal is via the so-called “message sequence chart” in the lower right window of the simulator: here we see which jobber handles which job. Figure 1.15 visualizes this fastest schedule in an even more compact way as a “Gantt chart”.* We see that one jobber is permanently busy with the hammer, whereas the other jobber has a relaxed schedule in which he is idling most of the time but also completes some jobs with his hands or with the mallet. It is easy to come up with an equally fast schedule in which the work load is more evenly distributed. We may decide, for instance, to give the third job to Jobber2.
Fig. 1.16 Model of jobber with upper bounds on timing.
Fig. 1.16 Model of jobber with upper bounds on timing.
Fig. 1.17 Slowest schedule for completing the 10 jobs. Hence, the diagnostic trace for the last property gives the slowest possible schedule, which takes exactly 126 time units. In this schedule, the final transitions from the jobbers back to the begin state are missing, but these transitions take no time. So even when the jobbers always start working on jobs as soon as they can, and imme- diately grab tools whenever they become available, the worst case schedule is still 26 time units slower than the fastest schedule from Figure 1.15. Figure 1.17 visu- alizes the slowest schedule as a Gannt chart. At time 0, Jobber1 grabs the first (hard) job, and Jobber2 grabs the second (average) job. Of course, in any rea- sonable scenario, Jobber1 would use the hammer and Jobber2 the mallet. But
Fig. 1.17 Slowest schedule for completing the 10 jobs. Hence, the diagnostic trace for the last property gives the slowest possible schedule, which takes exactly 126 time units. In this schedule, the final transitions from the jobbers back to the begin state are missing, but these transitions take no time. So even when the jobbers always start working on jobs as soon as they can, and imme- diately grab tools whenever they become available, the worst case schedule is still 26 time units slower than the fastest schedule from Figure 1.15. Figure 1.17 visu- alizes the slowest schedule as a Gannt chart. At time 0, Jobber1 grabs the first (hard) job, and Jobber2 grabs the second (average) job. Of course, in any rea- sonable scenario, Jobber1 would use the hammer and Jobber2 the mallet. But
Fig. 1.18 Generic model of template Tool. In the jobshop model, we have defined a single template Jobber with two instances Jobber! and Jobber2. Likewise, we would like to have a single template Tool with two instances Hammer and Mallet. It is possible to define this in Uppaal using the notion of Parameters. Parameters can be declared to have either call-by- value or call-by-reference semantics, that is, a template may have access to either a local copy of the argument or to the original. The syntax is taken from C++, where the identifier of a call-by-reference parameter is prefixed with an ampersend in the parameter declaration. Clocks and channels must always be call-by-reference parameters.
Fig. 1.18 Generic model of template Tool. In the jobshop model, we have defined a single template Jobber with two instances Jobber! and Jobber2. Likewise, we would like to have a single template Tool with two instances Hammer and Mallet. It is possible to define this in Uppaal using the notion of Parameters. Parameters can be declared to have either call-by- value or call-by-reference semantics, that is, a template may have access to either a local copy of the argument or to the original. The syntax is taken from C++, where the identifier of a call-by-reference parameter is prefixed with an ampersend in the parameter declaration. Clocks and channels must always be call-by-reference parameters.
Fig. 1.1 The train gate problem. Trains run on their own tracks except on the bridge. Trains may be stopped before 10 time units, after which they must proceed to the bridge. If stopped a train will take some time to reach the bridge (7-15 time units). Crossing takes some time (3-5 time units).
Fig. 1.1 The train gate problem. Trains run on their own tracks except on the bridge. Trains may be stopped before 10 time units, after which they must proceed to the bridge. If stopped a train will take some time to reach the bridge (7-15 time units). Crossing takes some time (3-5 time units).
Fig. 1.2 Template for the trains (a) and the gate (b). correspond to the states in Fig. [1.1] The communication with the gate is done with the channels with this identifier. When trains are approaching, the gate con- troller is notified with appr [id] ! and when they leave the bridge they notify with leave [id] !. The gate controller can stop a train and then restart it. Trains listen on stop [id] ? and go [id] ? forthis purpose. The different timing constraints of Fig. [Tare modelled with invariants on states and guards. Trains have a local clock x for this purpose (the purpose of the additional clock z will be explained later).
Fig. 1.2 Template for the trains (a) and the gate (b). correspond to the states in Fig. [1.1] The communication with the gate is done with the channels with this identifier. When trains are approaching, the gate con- troller is notified with appr [id] ! and when they leave the bridge they notify with leave [id] !. The gate controller can stop a train and then restart it. Trains listen on stop [id] ? and go [id] ? forthis purpose. The different timing constraints of Fig. [Tare modelled with invariants on states and guards. Trains have a local clock x for this purpose (the purpose of the additional clock z will be explained later).
Fig. 1.4 Window for editing edges showing the different editable labels.
Fig. 1.4 Window for editing edges showing the different editable labels.
Fig. 1.5 Screenshot of the simulator running of the train-gate example.
Fig. 1.5 Screenshot of the simulator running of the train-gate example.
Fig. 1.6 Exploration of symbolic states. Starting from the origin (0,0), (a) shows all the states reachable by delaying, (b) depicts the reset on the clock y, (c) shows a subsequent delay, and (d) shows the states that can take a transition guarded by y > 2.
Fig. 1.6 Exploration of symbolic states. Starting from the origin (0,0), (a) shows all the states reachable by delaying, (b) depicts the reset on the clock y, (c) shows a subsequent delay, and (d) shows the states that can take a transition guarded by y > 2.
Fig. 1.7 The different types of logic formulas supported by UPPAAL.
Fig. 1.7 The different types of logic formulas supported by UPPAAL.
Fig. 1.10 State space representation (a) and hash table size (b) options.
Fig. 1.10 State space representation (a) and hash table size (b) options.
Table 1.1 Performance comparison with different options. The option def corresponds to the de- fault setting, which is breadth-first search, compact data structure, and conservative state-space representation. The option dfs only changes the search order to depth-first. The option S2 is the default setting changed with aggressive state-space representation. Finally the option -C is the de- fault setting without the compact data-structure. We show results in seconds and MBytes obtained on a PentiumD running at 2.8GHz. The entries ’*’ mark an experiment that was stopped because it was taking more than 3 minutes. Table[I.1|shows the impact of some of these options on a few examples that can be found on http: //www.uppaal.org under examples/benchmarks. The example csma is a collision detection protocol, here with 10 nodes. Then we experiment with Fis- cher’s protocol, a mutual exclusion protocol with 10 nodes here. Finally we use a token ring FDDI (fiber distributed data interface) protocol with 25 nodes. The prop- erties checked here are safety properties and the depth-first search option makes the search a lot slower. This is explained by inclusion of symbolic states that will not be effective with that order. However, in other cases where a simple schedule is wanted, this order will work well. Deactivating compact data-structures will in- cura small speed improvement and a large loss in memory compared to the default setting. The aggressive state-space representation stores fewer states and can some- times (in these cases) give speed improvements. This is explained by the inclusion check that is done on fewer states.
Table 1.1 Performance comparison with different options. The option def corresponds to the de- fault setting, which is breadth-first search, compact data structure, and conservative state-space representation. The option dfs only changes the search order to depth-first. The option S2 is the default setting changed with aggressive state-space representation. Finally the option -C is the de- fault setting without the compact data-structure. We show results in seconds and MBytes obtained on a PentiumD running at 2.8GHz. The entries ’*’ mark an experiment that was stopped because it was taking more than 3 minutes. Table[I.1|shows the impact of some of these options on a few examples that can be found on http: //www.uppaal.org under examples/benchmarks. The example csma is a collision detection protocol, here with 10 nodes. Then we experiment with Fis- cher’s protocol, a mutual exclusion protocol with 10 nodes here. Finally we use a token ring FDDI (fiber distributed data interface) protocol with 25 nodes. The prop- erties checked here are safety properties and the depth-first search option makes the search a lot slower. This is explained by inclusion of symbolic states that will not be effective with that order. However, in other cases where a simple schedule is wanted, this order will work well. Deactivating compact data-structures will in- cura small speed improvement and a large loss in memory compared to the default setting. The aggressive state-space representation stores fewer states and can some- times (in these cases) give speed improvements. This is explained by the inclusion check that is done on fewer states.
Fig. 1.13 First attempt for modelling the gossipping girls. The model consists in different instances of the same template with different identifiers to differentiate the girls. This is the template of a girl, taking as argument an identifier of type girl1_t. The girl template is named Girl and has girl_t id as parameter. A first version of the the template is shown in figure [1.13] Every girl has a different ID. The system declaration is simply: system Girl;. This makes use of the auto-instantiation fea- ture of UPPAAL. All instances of the template Girl ranging over its parameters are generated. The number of instances is controlled by the constant GIRLS.
Fig. 1.13 First attempt for modelling the gossipping girls. The model consists in different instances of the same template with different identifiers to differentiate the girls. This is the template of a girl, taking as argument an identifier of type girl1_t. The girl template is named Girl and has girl_t id as parameter. A first version of the the template is shown in figure [1.13] Every girl has a different ID. The system declaration is simply: system Girl;. This makes use of the auto-instantiation fea- ture of UPPAAL. All instances of the template Girl ranging over its parameters are generated. The number of instances is controlled by the constant GIRLS.
Fig. 1.14 Improved model of the gossipping girls. The updated model is shown in Fig. [1.14] This update is for both boolean (gos- sip3) and integer (gossip2) encodings. The template keeps as an invariant that the variable g is always equal to id whenever it is not sending. In addition, when a channel j is selected, then it corresponds to exactly girl j. Only one committed location is enough but it is a good practice to mark them both. It is more explicit when we read the model. The previous versions could only be checked up to 4 girls, now we can check 5 within roughly the same time. This is a very good improvement considering the exponential complexity of the problem.
Fig. 1.14 Improved model of the gossipping girls. The updated model is shown in Fig. [1.14] This update is for both boolean (gos- sip3) and integer (gossip2) encodings. The template keeps as an invariant that the variable g is always equal to id whenever it is not sending. In addition, when a channel j is selected, then it corresponds to exactly girl j. Only one committed location is enough but it is a good practice to mark them both. It is more explicit when we read the model. The previous versions could only be checked up to 4 girls, now we can check 5 within roughly the same time. This is a very good improvement considering the exponential complexity of the problem.
Fig. 1.15 Abstract model of the gossipping girls. message already contains the sent secrets. The global declaration is updated with only chan call; for the channel. The updated automaton is depicted in Fig. [1.15] The integer version of the model (gossip4.xml) has the following local functions:
Fig. 1.15 Abstract model of the gossipping girls. message already contains the sent secrets. The global declaration is updated with only chan call; for the channel. The updated automaton is depicted in Fig. [1.15] The integer version of the model (gossip4.xml) has the following local functions:
Table 1.2 Resource consumption for the different models with different number of girls. Result: are in seconds/M-bytes. Table[I.2]shows the resource consumption for the different models with different number of girls. Experiments are run on an AMD Opteron 2.2GHz with UPPAAL rev. 2842. The results show how important it is to be careful with the model and to optimise the model to reduce the state-space whenever possible. We notice that the model is not even using clocks. The model with integers is faster due to its simplicity but consumes marginally less memory. The two last models (gossip6 and gossip7) are discussed in the next paragraph. 1.8.7 Improving Verification with Symmetry and Progress Measures
Table 1.2 Resource consumption for the different models with different number of girls. Result: are in seconds/M-bytes. Table[I.2]shows the resource consumption for the different models with different number of girls. Experiments are run on an AMD Opteron 2.2GHz with UPPAAL rev. 2842. The results show how important it is to be careful with the model and to optimise the model to reduce the state-space whenever possible. We notice that the model is not even using clocks. The model with integers is faster due to its simplicity but consumes marginally less memory. The two last models (gossip6 and gossip7) are discussed in the next paragraph. 1.8.7 Improving Verification with Symmetry and Progress Measures
Fig. 1.16 Pattems for checking bounded liveness (a) and non-zeno behaviours (b). A model is zeno if it allows an infinite number of discrete transitions to take place in a finite amount of time. In other words, it contains a loop where time does not diverge. This is an undesirable behaviour for a real system but it is very easy to obtain with timed automata. It is sometimes useful to check that a model does not allow such behaviours.
Fig. 1.16 Pattems for checking bounded liveness (a) and non-zeno behaviours (b). A model is zeno if it allows an infinite number of discrete transitions to take place in a finite amount of time. In other words, it contains a loop where time does not diverge. This is an undesirable behaviour for a real system but it is very easy to obtain with timed automata. It is sometimes useful to check that a model does not allow such behaviours.
Fig. 1.1 Chess MyriaNode 2.4 Ghz wireless sensor node However, a big advantage is that the full state space of the model can be explored and worst case scenarios can be found. Within the context of the Quasimodo project, Chess therefore proposed the analysis of gMAC, the clock synchronization algo- rithm for its wireless sensor networks, as a case study for timed automata tech- nology. An informal description of the case study was made available by Chess as a deliverable of the project [14]. Figure 1.1 displays a sensor node developed by Chess on which the gMAC algorithm runs.
Fig. 1.1 Chess MyriaNode 2.4 Ghz wireless sensor node However, a big advantage is that the full state space of the model can be explored and worst case scenarios can be found. Within the context of the Quasimodo project, Chess therefore proposed the analysis of gMAC, the clock synchronization algo- rithm for its wireless sensor networks, as a case study for timed automata tech- nology. An informal description of the case study was made available by Chess as a deliverable of the project [14]. Figure 1.1 displays a sensor node developed by Chess on which the gMAC algorithm runs.
Fig. 1.2 The structure of a time frame The algorithm that we consider is part of the Medium Access Control (MAC) layer, which is responsible for the access to the wireless shared channel. Within its so- called gMAC protocol, Chess uses a Time Division Multiple Access (TDMA) pro- tocol. Time is divided in fixed length frames, and each frame is subdivided into slots (see Figure 1.2). Slots can be either active or sleeping (idle). During active slots, a
Fig. 1.2 The structure of a time frame The algorithm that we consider is part of the Medium Access Control (MAC) layer, which is responsible for the access to the wireless shared channel. Within its so- called gMAC protocol, Chess uses a Time Division Multiple Access (TDMA) pro- tocol. Time is divided in fixed length frames, and each frame is subdivided into slots (see Figure 1.2). Slots can be either active or sleeping (idle). During active slots, a
Fig. 1.3 The need for introducing guard times
Fig. 1.3 The need for introducing guard times
end_sending|id] signal is sent to the controller to indicate that the message has been sent. Receiver The automaton Receiver|id] models the receiving behavior of the radio. The automa- ton is shown in Figure 1.7. Again the behavior is rather simple. When the controller asks the receiver to start receiving, the receiver first switches to receiving mode (this takes r ticks). After that, the receiver may receive messages from all its neighbors. A function neighbor is used to encode the topology of the network: neighbor(j, id) holds if messages sent by j can be received by id. Whenever the receiver detects the end of a message transmission by one of its neighbors, it immediately informs the synchronizer via a message_received|id] signal. At any moment, the controller can switch off the receiver via an end_receiving[id] signal.
end_sending|id] signal is sent to the controller to indicate that the message has been sent. Receiver The automaton Receiver|id] models the receiving behavior of the radio. The automa- ton is shown in Figure 1.7. Again the behavior is rather simple. When the controller asks the receiver to start receiving, the receiver first switches to receiving mode (this takes r ticks). After that, the receiver may receive messages from all its neighbors. A function neighbor is used to encode the topology of the network: neighbor(j, id) holds if messages sent by j can be received by id. Whenever the receiver detects the end of a message transmission by one of its neighbors, it immediately informs the synchronizer via a message_received|id] signal. At any moment, the controller can switch off the receiver via an end_receiving[id] signal.
Controller
Controller
The task of the Controller[id] automaton, displayed in Figure 1.8, is to put the radio in sending and receiving mode at the appropriate moments. Figure 1.9 shows the definition of the predicates used in this automaton. The radio should be put in send- ing mode r ticks before message transmission starts (at time g in the transmission slot of id). If r > g then the sender needs to be activated r — g ticks before the end of the slot that precedes the transmission slot. Otherwise, the sender must be activated at tick g —r of the transmission slot. If the first slot in a frame is an RX slot, then the radio is switched to receiving mode r time units before the start of the frame to ensure that the radio will receive during the full first slot. However if there is an RX slot after the TX slot then, as described in Section 1.2.4, the radio is switched to the receiving mode only at the start of the RX slot. The controller stops the radio receiver whenever either the last active slot has passed or the sender needs to be switched on. All the channels used in the Controller{id] automaton (start_sending, end_sending, start_receiving, end_receiving and synchronize) are urgent, which means that these signals are sent at the moment when the transitions are enabled.
The task of the Controller[id] automaton, displayed in Figure 1.8, is to put the radio in sending and receiving mode at the appropriate moments. Figure 1.9 shows the definition of the predicates used in this automaton. The radio should be put in send- ing mode r ticks before message transmission starts (at time g in the transmission slot of id). If r > g then the sender needs to be activated r — g ticks before the end of the slot that precedes the transmission slot. Otherwise, the sender must be activated at tick g —r of the transmission slot. If the first slot in a frame is an RX slot, then the radio is switched to receiving mode r time units before the start of the frame to ensure that the radio will receive during the full first slot. However if there is an RX slot after the TX slot then, as described in Section 1.2.4, the radio is switched to the receiving mode only at the start of the RX slot. The controller stops the radio receiver whenever either the last active slot has passed or the sender needs to be switched on. All the channels used in the Controller{id] automaton (start_sending, end_sending, start_receiving, end_receiving and synchronize) are urgent, which means that these signals are sent at the moment when the transitions are enabled.
Table 1.2 Model checking experiments 1 An Industrial Application of Uppaal: The Chess gMAC WSN Protocol
Table 1.2 Model checking experiments 1 An Industrial Application of Uppaal: The Chess gMAC WSN Protocol
Fig. 1.13 Another problematic network configuration with two communities However, variations of the above scenario may occur in practice, even in a setting with dynamic slot allocation. In fact, the above synchronization problem is also not restricted to line topologies. We call a subset C of nodes in a network a community if each node in C has more neighbors within C than outside C [12]. For any network in which two disjoint communities can be identified, the Median algorithm allows for scenarios in which these two parts become unsynchronized. Due to the median voting mechanism, the phase errors of nodes outside a community will not affect the nodes within this community, independent of the slot allocation. Therefore, if nodes in one community A run slow and nodes in another community B run fast then the network will become unsynchronized eventually, even in a setting with infinitesimal clock drifts. Figure 1.13 gives an example of a network with two communities.
Fig. 1.13 Another problematic network configuration with two communities However, variations of the above scenario may occur in practice, even in a setting with dynamic slot allocation. In fact, the above synchronization problem is also not restricted to line topologies. We call a subset C of nodes in a network a community if each node in C has more neighbors within C than outside C [12]. For any network in which two disjoint communities can be identified, the Median algorithm allows for scenarios in which these two parts become unsynchronized. Due to the median voting mechanism, the phase errors of nodes outside a community will not affect the nodes within this community, independent of the slot allocation. Therefore, if nodes in one community A run slow and nodes in another community B run fast then the network will become unsynchronized eventually, even in a setting with infinitesimal clock drifts. Figure 1.13 gives an example of a network with two communities.
Table 1.3 Model checking experiments of a network with two communities
Table 1.3 Model checking experiments of a network with two communities
Fig. 1.14 A network with two communities that we analyzed using UPPAAI
Fig. 1.14 A network with two communities that we analyzed using UPPAAI
Programmable Gate Array) is the programmable logic that runs the commutation, the real time control and the system behaviour logic. The FPGA also reads the sen- sor and input data and forwards this to the other FPGA board such that both con- trollers operate based on the same information. The FPGA boards are connected by a parallel bus interface with error detection. Fig. 2 Overview of the self-balancing scooter electronics architecture
Programmable Gate Array) is the programmable logic that runs the commutation, the real time control and the system behaviour logic. The FPGA also reads the sen- sor and input data and forwards this to the other FPGA board such that both con- trollers operate based on the same information. The FPGA boards are connected by a parallel bus interface with error detection. Fig. 2 Overview of the self-balancing scooter electronics architecture
The user process models the behaviour of the user during nominal behaviour and it triggers abnormal behaviour. With /gnition! the user toggles the discrete control from IDLE state to CHECK state or from any of the discrete control states back to IDLE. After switching on, the user must hold the vehicle upright to let the controller power the motors. The transition angle = 0 is used to simulate holding the self- balancing scooter upright. The user may cause an accident and fall, in which case the vehicle angle becomes too large. This is modelled with the transition angle = 2 setting the angle to a larger angle, for example 0.2 rad. Similarly, when the driver falls off he/she will unplug the Safety Key. The person, holding the vehicle pulls out the safety key, using the transition SafetyKey = false. Both the transitions that simulate en error set a global clock to 0, to measure the time needed between causing an error and the system reaching a safe mode. Either one of the error transitions fire, meaning a single failure is modelled.
The user process models the behaviour of the user during nominal behaviour and it triggers abnormal behaviour. With /gnition! the user toggles the discrete control from IDLE state to CHECK state or from any of the discrete control states back to IDLE. After switching on, the user must hold the vehicle upright to let the controller power the motors. The transition angle = 0 is used to simulate holding the self- balancing scooter upright. The user may cause an accident and fall, in which case the vehicle angle becomes too large. This is modelled with the transition angle = 2 setting the angle to a larger angle, for example 0.2 rad. Similarly, when the driver falls off he/she will unplug the Safety Key. The person, holding the vehicle pulls out the safety key, using the transition SafetyKey = false. Both the transitions that simulate en error set a global clock to 0, to measure the time needed between causing an error and the system reaching a safe mode. Either one of the error transitions fire, meaning a single failure is modelled.
Fig. 4 UPPAAL safety switch model 4 The safety switch is the electronics that closes and opens the power lines to the motor. The controller for start-up and shutdown normally does the operation of this switch. In case of emergency, the safety monitor process overrules the con- troller. The idea is that in case of an emergency, the vehicle control should go to the safest situation. Instead of locking (braking) we have chosen to let the wheels rotate freely. That means that the power lines to the motor will be switched to open loop. The safety switch process models the closing and opening of the switch. In the nominal behaviour, the discrete control opens and closes this switch with the open? and close? events. The safety monitor can override normal control and open the switch, with the error? event. A Boolean signal enable telling other parts (the controller) whether the safety switch is in the OPEN or in the CLOSE state. A timer openDelay models the time needed to open the safety switch.
Fig. 4 UPPAAL safety switch model 4 The safety switch is the electronics that closes and opens the power lines to the motor. The controller for start-up and shutdown normally does the operation of this switch. In case of emergency, the safety monitor process overrules the con- troller. The idea is that in case of an emergency, the vehicle control should go to the safest situation. Instead of locking (braking) we have chosen to let the wheels rotate freely. That means that the power lines to the motor will be switched to open loop. The safety switch process models the closing and opening of the switch. In the nominal behaviour, the discrete control opens and closes this switch with the open? and close? events. The safety monitor can override normal control and open the switch, with the error? event. A Boolean signal enable telling other parts (the controller) whether the safety switch is in the OPEN or in the CLOSE state. A timer openDelay models the time needed to open the safety switch.
vehicle must be hold upright by the user (sbsAngle j= 1). If the conditions are met then the state may progress to the state SYNCHRONISE. In this state, both left and right controller signal that they are in this state and wait until this signal from the other side, to simultaneously progress to the DRIVE state. This last transition closes the safety switch and thus powers the motor. The controller not in IDLE state should return to the CHECK state when unsafe becomes true. The user must be able to toggle the ignition switch in each of the states, which makes the controller to return to the IDLE state. This ignition has been blocked for the transition from DRIVE to IDLE in case of an error to give preference to the state change from DRIVE to CHECK in case of an error. A transition was added to the DRIVE state to lower the battery level every 1 time unit. This battery reduction could have been modelled in other states as well, but as the motors are the main power consuming devices this was simplified to model the power consumption in the DRIVE state only.
vehicle must be hold upright by the user (sbsAngle j= 1). If the conditions are met then the state may progress to the state SYNCHRONISE. In this state, both left and right controller signal that they are in this state and wait until this signal from the other side, to simultaneously progress to the DRIVE state. This last transition closes the safety switch and thus powers the motor. The controller not in IDLE state should return to the CHECK state when unsafe becomes true. The user must be able to toggle the ignition switch in each of the states, which makes the controller to return to the IDLE state. This ignition has been blocked for the transition from DRIVE to IDLE in case of an error to give preference to the state change from DRIVE to CHECK in case of an error. A transition was added to the DRIVE state to lower the battery level every 1 time unit. This battery reduction could have been modelled in other states as well, but as the motors are the main power consuming devices this was simplified to model the power consumption in the DRIVE state only.
Note that the monitored variables are modelled as signals not as events. For ar event to take place both sides, the sender and the receiver, must be available to pass the transition. In physics the event of a Safety Key being pulled out or an angle out of bounds will not wait for the state machine to allow this error to happen; it just happens.
Note that the monitored variables are modelled as signals not as events. For ar event to take place both sides, the sender and the receiver, must be available to pass the transition. In physics the event of a Safety Key being pulled out or an angle out of bounds will not wait for the state machine to allow this error to happen; it just happens.
Figure 1: Task (a) and scheduler (b) templates. In our scheduling model that is based on [2], we have a number of tasks modeled by a Task template and one or more schedulers modeled by a Scheduler tem- plate. The idea here is that we need one scheduler per process and the scheduler decides which task to run.
Figure 1: Task (a) and scheduler (b) templates. In our scheduling model that is based on [2], we have a number of tasks modeled by a Task template and one or more schedulers modeled by a Scheduler tem- plate. The idea here is that we need one scheduler per process and the scheduler decides which task to run.
Figure 2: Synchronization between tasks and a scheduler. The scheduler en- queues ready tasks and run the tasks at the front of its internal queue.
Figure 2: Synchronization between tasks and a scheduler. The scheduler en- queues ready tasks and run the tasks at the front of its internal queue.
Figure 3: Task template extended with resource sharing. resource. The other tasks can run in parallel, provided that one scheduler is available.
Figure 3: Task template extended with resource sharing. resource. The other tasks can run in parallel, provided that one scheduler is available.
Figure 4: Gantt charts that show the run with one and two schedulers with resource sharing.
Figure 4: Gantt charts that show the run with one and two schedulers with resource sharing.
Figure 5: Extensions of the task (a) and scheduler (b) templates to model preemptive scheduling.
Figure 5: Extensions of the task (a) and scheduler (b) templates to model preemptive scheduling.
Fig. 2: Work-flow of schedulability analysis. Figure 2 shows the work-flow of response-time analysis (performed by Terma A/S) and schedulability analysis using UPPAAL: the task timing informations are obtained from ASW and BSW documentation, worst-case execution times (WCET) of BSW are obtained from BSW documentation [Terma A/S(Issue 9)] and ASW timings are obtained from simulation measurements. In addition the UPPAAL model uses information about the individual task flows, i.e. the timing of resource locks, CPU execution and suspension.
Fig. 2: Work-flow of schedulability analysis. Figure 2 shows the work-flow of response-time analysis (performed by Terma A/S) and schedulability analysis using UPPAAL: the task timing informations are obtained from ASW and BSW documentation, worst-case execution times (WCET) of BSW are obtained from BSW documentation [Terma A/S(Issue 9)] and ASW timings are obtained from simulation measurements. In addition the UPPAAL model uses information about the individual task flows, i.e. the timing of resource locks, CPU execution and suspension.
Schedulability Analysis of Herschel/Planck Software Using Uppaal Fig. 4: MainCycle task: periodically starts ASW functions.
Schedulability Analysis of Herschel/Planck Software Using Uppaal Fig. 4: MainCycle task: periodically starts ASW functions.
Fig. 6: Global process enforce invariants on stopwatches and cyclic progress.
Fig. 6: Global process enforce invariants on stopwatches and cyclic progress.
Fig. 7: Gantt chart of the first cycle, generated by UPPAAL TIGA: task T(i) is green when ready, blue - executing, red - blocked, cyan - suspended, resource R(j) is blue when locked and owner uses CPU, green - locked but the owner is preempted, cyan - locked but owner is suspended. A Gantt chart can be used to visualise a trace of the system, thus providing a rich picture for inspection. For example, the generated Gantt chart in Figure 7 shows that Cmd_P is blocked more than 5 times during the first cycle, while blocking times for PrimaryF (21) and StsMon_P (25) are significantly long only starting from the second cycle.
Fig. 7: Gantt chart of the first cycle, generated by UPPAAL TIGA: task T(i) is green when ready, blue - executing, red - blocked, cyan - suspended, resource R(j) is blue when locked and owner uses CPU, green - locked but the owner is preempted, cyan - locked but owner is suspended. A Gantt chart can be used to visualise a trace of the system, thus providing a rich picture for inspection. For example, the generated Gantt chart in Figure 7 shows that Cmd_P is blocked more than 5 times during the first cycle, while blocking times for PrimaryF (21) and StsMon_P (25) are significantly long only starting from the second cycle.
Table 2: Specification, blocking and worst-case response-times of individual tasks. On a Linux server with Intel Xeon E5420 2.5GHz processor UPPAAL takes 2min 40s to verify that the system is schedulable, 6min 30s to find WCRTs with 0% BCET deviation. In case of 10% BCET deviation it took slightly over 6 days to establish schedulability and slightly over 7 days of 6 parallel runs to find all WCRTs. Table 3 shows the amount of verification resources UPPAAL requires to verify schedulability with different task execution time windows and model time limits. In this study we used compact data structure (CDS) to store the clock val- uations in contrast to difference bound matrices (DBM) in previous study, which explains why the verification is slower, but the memory usage is limited and varies very little across model time limits.
Table 2: Specification, blocking and worst-case response-times of individual tasks. On a Linux server with Intel Xeon E5420 2.5GHz processor UPPAAL takes 2min 40s to verify that the system is schedulable, 6min 30s to find WCRTs with 0% BCET deviation. In case of 10% BCET deviation it took slightly over 6 days to establish schedulability and slightly over 7 days of 6 parallel runs to find all WCRTs. Table 3 shows the amount of verification resources UPPAAL requires to verify schedulability with different task execution time windows and model time limits. In this study we used compact data structure (CDS) to store the clock val- uations in contrast to difference bound matrices (DBM) in previous study, which explains why the verification is slower, but the memory usage is limited and varies very little across model time limits.
Table 3: Verification statistics for different task execution time windows and explo- ration limits: the percentage denotes difference between WCET and BCET, limit is in terms of 250ms cycles ( stands for no limit, i.e. full exploration), memory in MB, time in seconds.
Table 3: Verification statistics for different task execution time windows and explo- ration limits: the percentage denotes difference between WCET and BCET, limit is in terms of 250ms cycles ( stands for no limit, i.e. full exploration), memory in MB, time in seconds.
1 An Introduction to Automatic Synthesis of Discrete and Timed Controllers Fig. 1.1 A Chinese juggler (cartoon courtesy of Jean Cardinal.)
1 An Introduction to Automatic Synthesis of Discrete and Timed Controllers Fig. 1.1 A Chinese juggler (cartoon courtesy of Jean Cardinal.)
Fig. 1.2 An example of a game structure Example 1. Fig. 1.2 depicts a game structure. The set of locations is L = {L0,L1,L2, L3}. In location LO, Player 1 can choose between action a or action b, while Player 2 can choose between action u1 and action u2. LO (inner circle) is the initial location of the game. The edge (L0,a,L1) belongs to Player 1 and the edge (LO, u1,L1) belongs to Player 2.
Fig. 1.2 An example of a game structure Example 1. Fig. 1.2 depicts a game structure. The set of locations is L = {L0,L1,L2, L3}. In location LO, Player 1 can choose between action a or action b, while Player 2 can choose between action u1 and action u2. LO (inner circle) is the initial location of the game. The edge (L0,a,L1) belongs to Player 1 and the edge (LO, u1,L1) belongs to Player 2.
fig. 1.3 Controllable and uncontrollable predecessors Example 5. To illustrate the definition of controllable predecessors, we use Fig. 1.3. First, let us consider the set of locations T; = {L1,L3}. The location LO is a con- trollable predecessor of T;. Indeed, in LO if Player 1 chooses a, no matter what is the choice of Player 2 (to move the pebble using an edge labeled with a or to play an edge labeled with her own actions) the pebble will be either in L1 or L3 after the round, so it will lie in T;. Second, let us consider the set of locations T; = {L1,L2}. The location LO is not a controllable predecessor of Tz. Indeed, neither a nor b en- sures that the pebble will lie in T2 as Player 2 can choose to go to L3 using a or u2 in the first case, and Player 2 can decide to go to L1 using ul in the second case.
fig. 1.3 Controllable and uncontrollable predecessors Example 5. To illustrate the definition of controllable predecessors, we use Fig. 1.3. First, let us consider the set of locations T; = {L1,L3}. The location LO is a con- trollable predecessor of T;. Indeed, in LO if Player 1 chooses a, no matter what is the choice of Player 2 (to move the pebble using an edge labeled with a or to play an edge labeled with her own actions) the pebble will be either in L1 or L3 after the round, so it will lie in T;. Second, let us consider the set of locations T; = {L1,L2}. The location LO is not a controllable predecessor of Tz. Indeed, neither a nor b en- sures that the pebble will lie in T2 as Player 2 can choose to go to L3 using a or u2 in the first case, and Player 2 can decide to go to L1 using ul in the second case.
Fig. 1.4 An example of a timed game automaton
Fig. 1.4 An example of a timed game automaton
Fig. 1.5 Computation of the timed controllable states. The sets of states that we have to handle are infinite, so they cannot be repre- sented in extension. We need a symbolic data structure able to represent infinite sets. Those sets can be represented symbolically using formulas in an adequate con- straint language. All sets manipulated during the computation of the timed control- lable predecessors are representable by union of clock constraints. To illustrate the use of clock constraints and how the computation of the controllable predecessor in the timed setting is done, we consider our running example of Fig. 1.4.
Fig. 1.5 Computation of the timed controllable states. The sets of states that we have to handle are infinite, so they cannot be repre- sented in extension. We need a symbolic data structure able to represent infinite sets. Those sets can be represented symbolically using formulas in an adequate con- straint language. All sets manipulated during the computation of the timed control- lable predecessors are representable by union of clock constraints. To illustrate the use of clock constraints and how the computation of the controllable predecessor in the timed setting is done, we consider our running example of Fig. 1.4.
Fig. 1.6 A model for the plate. Fig. 1.6 shows the timed automaton model for Plate i € {1,2}. The timed game automaton has the set of locations {Stable, Spinning, Longspinning, Crashed}. The location Stab1Le intends to model the situation when the plate is stable, the lo- cation Crashed models the situation when the plate has crashed, Spinning mod- els the situation when the juggler does spin the plate spin fora timet < STABSHORT seconds (where STABSHORT is a constant equal to 2), and Longspinning when the juggler does spin the plate for more than STABSHORT seconds.
Fig. 1.6 A model for the plate. Fig. 1.6 shows the timed automaton model for Plate i € {1,2}. The timed game automaton has the set of locations {Stable, Spinning, Longspinning, Crashed}. The location Stab1Le intends to model the situation when the plate is stable, the lo- cation Crashed models the situation when the plate has crashed, Spinning mod- els the situation when the juggler does spin the plate spin fora timet < STABSHORT seconds (where STABSHORT is a constant equal to 2), and Longspinning when the juggler does spin the plate for more than STABSHORT seconds.
Fig. 1.1 Overview of the system. The design of controllers for embedded systems is a difficult engineering task. Con- trollers have to enforce properties like safety properties (e.g. “nothing bad will hap- pen’), or reachability properties (e.g. “something good will happen”), and ideally they should do that in an efficient way, e.g. consume the least possible amount of energy. The foundations of have been presented application of these in the approac automatic synthesis of discrete and timed controllers preceding chapter 1. In this chapter, we illustrate the hes with an industrial case study provided by the Hy- DAC ELECTRONIC GMBH company in the context of the European research project Quasimodo [?]. We present in the sequel how to use (in a systematic way) the tool UPPAAL-TIGA [?] (see cha pter | for an introduction to the tool) for the synthesis, together with tools for the verification and the simulation of a provable correct and near optimal control er for real industrial applications. The system to be controlled is depicted in Fig. 1.1 and is composed of:
Fig. 1.1 Overview of the system. The design of controllers for embedded systems is a difficult engineering task. Con- trollers have to enforce properties like safety properties (e.g. “nothing bad will hap- pen’), or reachability properties (e.g. “something good will happen”), and ideally they should do that in an efficient way, e.g. consume the least possible amount of energy. The foundations of have been presented application of these in the approac automatic synthesis of discrete and timed controllers preceding chapter 1. In this chapter, we illustrate the hes with an industrial case study provided by the Hy- DAC ELECTRONIC GMBH company in the context of the European research project Quasimodo [?]. We present in the sequel how to use (in a systematic way) the tool UPPAAL-TIGA [?] (see cha pter | for an introduction to the tool) for the synthesis, together with tools for the verification and the simulation of a provable correct and near optimal control er for real industrial applications. The system to be controlled is depicted in Fig. 1.1 and is composed of:
Fig. 1.6 Model of the cyclic consumption of the machine
Fig. 1.6 Model of the cyclic consumption of the machine
Results. It is worth noticing that the value Score is computed using the variable V_acc which is deduced from intermediary values of variable V. Since V corresponds to the value of the volume with no noise, V_acc represents the mean value of the accumulated volume for a given execution.
Results. It is worth noticing that the value Score is computed using the variable V_acc which is deduced from intermediary values of variable V. Since V corresponds to the value of the volume with no noise, V_acc represents the mean value of the accumulated volume for a given execution.
Table 1.1 Main characteristics of the strategies synthesized with UPPAAL-TIGA. in the interval /;, the corresponding period of activation of the pump is represented. We have represented volumes which share the same strategy in the same color. For the 50 initial possible values of volume, we obtain 10 different strategies (first row of Table 1.1). The overall strategy we synthesize thus measures the volume just once at the beginning of each cycle and plays the corresponding “local strategy” until the beginning of next cycle.
Table 1.1 Main characteristics of the strategies synthesized with UPPAAL-TIGA. in the interval /;, the corresponding period of activation of the pump is represented. We have represented volumes which share the same strategy in the same color. For the 50 initial possible values of volume, we obtain 10 different strategies (first row of Table 1.1). The overall strategy we synthesize thus measures the volume just once at the beginning of each cycle and plays the corresponding “local strategy” until the beginning of next cycle.
Fig. 1.12 Cyclic Behavior of the Bang-Bang controller with Noise
Fig. 1.12 Cyclic Behavior of the Bang-Bang controller with Noise
Fig. 1.15 Smart Controller / fluctuations Fig. 1.14 Smart Controller / no fluctuations
Fig. 1.15 Smart Controller / fluctuations Fig. 1.14 Smart Controller / no fluctuations
Fig. 1.16 The Pump Controlled over 3 Cycles To make sure that our strategies are implementable, we have verified them in presence of fluctuations of the rate consumption and two types of imprecision: on the time-stamp of start/stop of the pump (we use A = 0.01 second), and on the measure of the initial volume, the imprecision being 0.06 /. Fig. 1.16 shows how the volume is controlled over 3 cycles: after the first one at tf = 20, we measure the real volume with uncertainty (0.06 /) and use the corresponding controller from 20 to 40 and for 40 we again switch to another one.
Fig. 1.16 The Pump Controlled over 3 Cycles To make sure that our strategies are implementable, we have verified them in presence of fluctuations of the rate consumption and two types of imprecision: on the time-stamp of start/stop of the pump (we use A = 0.01 second), and on the measure of the initial volume, the imprecision being 0.06 /. Fig. 1.16 shows how the volume is controlled over 3 cycles: after the first one at tf = 20, we measure the real volume with uncertainty (0.06 /) and use the corresponding controller from 20 to 40 and for 40 we again switch to another one.
Fig. 1.18 The overall SIMULINK model.
Fig. 1.18 The overall SIMULINK model.
Table 1.2 Performance characteristics based on SIMULINK simulations. Now, the plots in Fig. 1.19 are the result of SIMULINK simulations of the con- trollers, illustrating the volume of the accumulator as well as the state of the pump (on or off) for a duration of 200 s, i.e. 10 cycles. Though the simulations do not reveal the known violation of the safety requirement R; in the HYDAC Smart con- troller case, the simulations yield useful information concerning the performance of the controllers. In particular, the simulations indicate that the accumulated oil vol- ume for all controllers grow linearly with time. Also, there is clear evidence that the strategies synthesized by UPPAAL-TIGA outperform the Smart controller of Hy- DAC — which is not robust — and also the Bang-Bang controller — which is robust but far from optimal.
Table 1.2 Performance characteristics based on SIMULINK simulations. Now, the plots in Fig. 1.19 are the result of SIMULINK simulations of the con- trollers, illustrating the volume of the accumulator as well as the state of the pump (on or off) for a duration of 200 s, i.e. 10 cycles. Though the simulations do not reveal the known violation of the safety requirement R; in the HYDAC Smart con- troller case, the simulations yield useful information concerning the performance of the controllers. In particular, the simulations indicate that the accumulated oil vol- ume for all controllers grow linearly with time. Also, there is clear evidence that the strategies synthesized by UPPAAL-TIGA outperform the Smart controller of Hy- DAC — which is not robust — and also the Bang-Bang controller — which is robust but far from optimal.
Fig. 1.19 The three controller types with SIMULINK 1 Timed Controller Synthesis: An Industrial Case Study
Fig. 1.19 The three controller types with SIMULINK 1 Timed Controller Synthesis: An Industrial Case Study
Fig. 2 Hidden node problem and its detection
Fig. 2 Hidden node problem and its detection
Fig. 9 Three different initiator positions Latency vs. energy consumption. A TDMA protocol is by design very predictable with respect to energy consumption: since only in the active slots the energy drain of the radio is non-negligible, and the number of active slots per frame is constant, also the power consumption is close to constant, depending linearly on the number of active slots. Energy consumption is therefore constant over time. However, tl question is how energy-efficiently the network fulfils its task. We thus focus on tl atency of message dissemination and the energy consumed by that. We consid the average time required and the total average energy consumed until a message nitially, only one node is infected, the initiator. To get insight into the effect of t delivered to all network nodes. We say a node is infected if it has received a message. he he el is Ne position in the network of the message initiator, we considera corner node, a midd gMAC’s energy consumption. le node at the border, and a center node (cf. Figure 9). Again, the simulations are run for different values of r and A to investigate the influence of these parameters on
Fig. 9 Three different initiator positions Latency vs. energy consumption. A TDMA protocol is by design very predictable with respect to energy consumption: since only in the active slots the energy drain of the radio is non-negligible, and the number of active slots per frame is constant, also the power consumption is close to constant, depending linearly on the number of active slots. Energy consumption is therefore constant over time. However, tl question is how energy-efficiently the network fulfils its task. We thus focus on tl atency of message dissemination and the energy consumed by that. We consid the average time required and the total average energy consumed until a message nitially, only one node is infected, the initiator. To get insight into the effect of t delivered to all network nodes. We say a node is infected if it has received a message. he he el is Ne position in the network of the message initiator, we considera corner node, a midd gMAC’s energy consumption. le node at the border, and a center node (cf. Figure 9). Again, the simulations are run for different values of r and A to investigate the influence of these parameters on
Energy Consumption in the Chess WSN: A MoDeST Case Study
Energy Consumption in the Chess WSN: A MoDeST Case Study
Fig. 5 LTS of the parallel composition of sender, receiver and communication channels Fig. 4 MODEST code for the parallel composition of sender, receiver and communication channels
Fig. 5 LTS of the parallel composition of sender, receiver and communication channels Fig. 4 MODEST code for the parallel composition of sender, receiver and communication channels
Probabilistic Analysis of Embedded Systems Fig. 8 Automaton for the channel with transmission delay
Probabilistic Analysis of Embedded Systems Fig. 8 Automaton for the channel with transmission delay
Amd Hartmanns, Holger Hermanns, and Joost- Pieter K atoen Fig. 10 Automaton for the channel with transmission delay and probabilities
Amd Hartmanns, Holger Hermanns, and Joost- Pieter K atoen Fig. 10 Automaton for the channel with transmission delay and probabilities
Armd Hartmanns, Holger Hermanns, and Joost- Pieter K atoen 3 Analysing MODEST Models
Armd Hartmanns, Holger Hermanns, and Joost- Pieter K atoen 3 Analysing MODEST Models
Armd Hartmanns, Holger Hermanns, and Joost- Pieter K atoen Fig. 12 Simulation results for the communication scenario
Armd Hartmanns, Holger Hermanns, and Joost- Pieter K atoen Fig. 12 Simulation results for the communication scenario
Probabilistic Analysis of Embedded Systems Fig. 13 mime, the integrated modelling environment for MODEST
Probabilistic Analysis of Embedded Systems Fig. 13 mime, the integrated modelling environment for MODEST
Fig. 1: The process and concepts of model-based testing. This section discusses these concepts of model-based testing in general; the next two sections will elaborate them for particular model-based testing approaches using labeled transition systems and Timed Automata, respectively.
Fig. 1: The process and concepts of model-based testing. This section discusses these concepts of model-based testing in general; the next two sections will elaborate them for particular model-based testing approaches using labeled transition systems and Timed Automata, respectively.
coffee is produced, modeled as cof!, or tea is output, modeled as tea!. Both bring the machine back into its initial state s9. The observable behaviour of s is expressed by its set of traces, of which there are infinitely many:
coffee is produced, modeled as cof!, or tea is output, modeled as tea!. Both bring the machine back into its initial state s9. The observable behaviour of s is expressed by its set of traces, of which there are infinitely many:
Fig. 3: Test case as a labeled transition system.
Fig. 3: Test case as a labeled transition system.
where a? is an input (output of the test case) such that at least one transi- tion with a? is enabled in some state of S. The test case tg is obtained by re- cursively applying the algorithm for the set of states S' reachable from S via a?: S' = Saftera?. Analogously, each t,, is obtained by recursively applying the algorithm for S,, = S after x;. The single-state test case pass is always a valid test case.
where a? is an input (output of the test case) such that at least one transi- tion with a? is enabled in some state of S. The test case tg is obtained by re- cursively applying the algorithm for the set of states S' reachable from S via a?: S' = Saftera?. Analogously, each t,, is obtained by recursively applying the algorithm for S,, = S after x;. The single-state test case pass is always a valid test case.
This test case awaits and checks the next output x;! from the SUT. If x;! is correct, i.e., x;! € out(S), then the algorithm continues recursively; otherwise the test fails. If no output arrives then quiescence 6 has been observed, and the corresponding test-case transition is taken. This test case attempts to supply input a? to the SUT, but if the SUT is faster and produces an output x! before a? could be supplied, then the tester checks whether this output is correct, x;! € out(S), or not.
This test case awaits and checks the next output x;! from the SUT. If x;! is correct, i.e., x;! € out(S), then the algorithm continues recursively; otherwise the test fails. If no output arrives then quiescence 6 has been observed, and the corresponding test-case transition is taken. This test case attempts to supply input a? to the SUT, but if the SUT is faster and produces an output x! before a? could be supplied, then the tester checks whether this output is correct, x;! € out(S), or not.
High? temperature indication it switches on the compressor relay within a reac- tion time of RelayLatency, which is controlled by clock x and the clock invariant x<=RelayLatency in location goOn. Dually, in the On-location it will transit towards the goOff location. Fig. 6: Alarm Monitor Model.
High? temperature indication it switches on the compressor relay within a reac- tion time of RelayLatency, which is controlled by clock x and the clock invariant x<=RelayLatency in location goOn. Dually, in the On-location it will transit towards the goOff location. Fig. 6: Alarm Monitor Model.
Fig. 4: System Diagram of Cooling Controller Model.
Fig. 4: System Diagram of Cooling Controller Model.
Fig. 5: Compressor Controller Model.
Fig. 5: Compressor Controller Model.
Fig. 7: Universal Environment Model for Cooling Controller Figure 6 shows the Alarm Monitor. When it detects a High? temperature it moves from the Off location to the Triggered location, where it remains for AlarmDelay time units, controlled by the clock z, unless it observes a Low? temperature in the mean time, after which the high temperature situation is ignored. If the high temper- ature remains for AlarmDelay time units, the automaton moves to the HighTooLong location with an internal transition. Here it sounds the alarm, allowing for a small timing tolerance up to AlarmSoundLatency. It remains Sounding until the user clears the alarm by pressing the ClearAlarm? key.
Fig. 7: Universal Environment Model for Cooling Controller Figure 6 shows the Alarm Monitor. When it detects a High? temperature it moves from the Off location to the Triggered location, where it remains for AlarmDelay time units, controlled by the clock z, unless it observes a Low? temperature in the mean time, after which the high temperature situation is ignored. If the high temper- ature remains for AlarmDelay time units, the automaton moves to the HighTooLong location with an internal transition. Here it sounds the alarm, allowing for a small timing tolerance up to AlarmSoundLatency. It remains Sounding until the user clears the alarm by pressing the ClearAlarm? key.
Fig. 8: Alternative, more realistic Environment Model speed bounded by MinTempDelay. Thus our framework enables the test engineer to use different environment models of varying strengths. Taken further, this can be used to focus testing on restricted, important scenarios, or on specific test purposes.
Fig. 8: Alternative, more realistic Environment Model speed bounded by MinTempDelay. Thus our framework enables the test engineer to use different environment models of varying strengths. Taken further, this can be used to focus testing on restricted, important scenarios, or on specific test purposes.
Fig. 1 Desktop applications, logger and a franking machine are connected to the central XBus. 2.2 Model-based testing
Fig. 1 Desktop applications, logger and a franking machine are connected to the central XBus. 2.2 Model-based testing
Fig. 3 The V-model that was used for development of XBus.
Fig. 3 The V-model that was used for development of XBus.
Fig. 4 High level architecture of the XBus system. It contains a server side package, and a client side package. Furthermore, it has functionality for TCP connections and XBus messages. Both server and client implement the Protocol interfaces. All interfaces are indicated with <i>.
Fig. 4 High level architecture of the XBus system. It contains a server side package, and a client side package. Furthermore, it has functionality for TCP connections and XBus messages. Both server and client implement the Protocol interfaces. All interfaces are indicated with <i>.
Fig. 7 Chosen solution: JTorX providing stimuli to XBus via generic clients (c) over TCP, and observing responses via test interface (t), also connected via TCP. of this solution is that the actual test architecture very closely resembles the model. However, it has the disadvantage that the XBus implementation has to be extended in multiple places.
Fig. 7 Chosen solution: JTorX providing stimuli to XBus via generic clients (c) over TCP, and observing responses via test interface (t), also connected via TCP. of this solution is that the actual test architecture very closely resembles the model. However, it has the disadvantage that the XBus implementation has to be extended in multiple places.
Fig. 8 Screen shot of configuration pane of JTorX, set up to test XBus. JTorX will connect to (the adapter that provides access to) the system under test via TCP on the local machine, at port 1234. The bottom two input fields list the input and output messages.
Fig. 8 Screen shot of configuration pane of JTorX, set up to test XBus. JTorX will connect to (the adapter that provides access to) the system under test via TCP on the local machine, at port 1234. The bottom two input fields list the input and output messages.
Related topics:
Formal methodProcess Algebra
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved