System Validation is the field that studies the fundamentals of system communication and information processing. It allows automated analysis based on behavioural models of a system to see if a system works correctly. We want to guarantee that the systems does exactly what it is supposed to do. The techniques put forward in system validation allow to prove the absence of errors. It allows to design embedded system behaviour that is structurally sound and as a side effect enforces you to make the behaviour simple and insightful. This means that the systems are not only behaving correctly, but are also much easier to maintain and adapt. ’Modeling Software Protocols, and other behaviour' demonstrates the power of formal methods in software modelling, communication protocols, and other examples. Reading material. J.F. Groote and M.R. Mousavi. Modeling and analysis of communicating systems. The MIT Press, 2014.

审阅

Filled StarFilled StarFilled StarFilled StarHalf Faded Star

4.7（9 个评分）

5 stars

7 ratings

4 stars

1 ratings

3 stars

1 ratings

从本节课中

Advanced modelling

We show how the behavior of simple programs and communication protocols can be modelled and analysed. Furthermore, we introduce the notion of a linear process: a simple normal form to which every behavior can be reduced. This normal form is the workhorse when it comes to the analysis of behavior.

教学方

Jan Friso Groote

Full professor

脚本

[MUSIC]. Welcome again. In this lecture I would share a little bit of our experience, with the remote control Six Standard of elipse. So the remote control standard protocol, is actually called a bounded retransmission protocol, because when we were studying this protocol we had no idea that it was related to this remote control application. What's the protocol about? Actually the protocol speaks about, transmitting data over an unreliable channel, and the way to do it in reliable channel, is that we resend data with this alternating bits. So this is just the very end of the alternating bit protocol, and a typical property of the protocol is that the number of retransmission is bounded, so there is a strict limit on the number of retransmission that's allowed. And what the protocol does is, it sends not small packages of data but a lot of huge packages of data, from the sending side to the receiving side. And these huge packages are split up in small sub-packages. And in this model, I will just have a list of individual data messages that are being sent. These data is sent separately to the receiving side. What's happening at the receiving side is that, each data element arrives individually, and there is an indicator, indicating the status of that message. And after the data is delivered properly or not, there's an indication at the sending side on the status of the delivery. So what we see, is that there are status messages. I first indicates, that this is the first message to be delivered at the receiving side. And that's then the first message of such a list of individual data messages, I inc indicates that this is an incremental message, or an intermediate message. And that can also be data be delivered with an I ok indicator, and that means that, this was the last message of the whole sequence, and this delivery was correct. At the receiving side, you can also get an I, knock location, and not okay indication, and that occurs when the number of reach admissions was exceeded. And indicates that transmission failed, and that no more data for this list of data elements will come. The last message, which can only occur at the sending site, is this, I d, k indicator, that's from don't know. And this is shown, if the protocol does not know where the data is correctly transfers to the receiving side. And that's a strange option of this protocol, but it can occur and actually it is quite natural. So we are interested in the external behavior, and not so much in the internal workings of this protocol. So, here, we see the external behavior when we sent a list of five individual messages. We are not interested in what happens when something goes wrong, but we are only interested for the moment, and therefore, I hide the inner part. In the correct delivery of data, and that's on the outer circle of this figure. So here we receive a list of five data elements, what we see here is that it's actually decided that, of the first elements do arrives correctly at receiving site, and it's delivered with the I first indicator. Here we have the second message written inc indicator. The third message, the fourth message. And then the fifth message here, has this okay indication, indicating that the whole list of messages has now been transferred. And we will see that there is also an OK indicator at the sending site, such that the sender is now informed that data transmission was successful. And this is the ideal, and actually quite straight forward and simple behavior of this protocol. Now, let's look when something goes wrong. So, what can happen is that the number of free transmissions is exceeded at some point, and then this tau action towards the inside of the circle can happen. That's what this tau represents. If you look at this tau, this means that data is actually successfully transferred in one of the allowed attempts of this bounded retransmission protocol. But if data is not delivered at all at the receiving side, then what can happen is that, without the receiver knowing it, a not okay is actually delivered in response to an attempt to send the data to the other site. It can also be that the first data is delivered, but while the data is being transmitted to the receiving site, a number of free transmissions is exceeded and that corresponds to one of these tau's going to this interstate. And if it happens that the number of retransmissions are exceeded, then a not okay is indicated at the sending side and not okay is indicated at the receiving side. And that's basically what happens when a number of retransmissions is exceeded during ordinary transmission. With the last message the situation is more complex. So it can be, that we have sent and delivered the third message, but that's the sender will never attempted to send the fourth message to the receiver. So in that case, it knows that the receiver can not have received this fourth message and it can indicate a not okay, the data for sure did not arrive correctly. It can also be that the data, that the descender attempted to send the last message to the receiver, but then, and the receiver actually receives this forward message. And it is delivered, or it can be that the data, the fourth message never arrives at the receiver, and that's this transition. And in that case, the sender does not know whether the data has been delivered. So the only thing it can say is that it simply does not know whether the whole message did arrive properly, so there is this don't know indicator here. If the data is sent to the receiver, if it's actually delivered, if it's given to the user. Using side of the receiver, that it might still be that acknowledgement does not arrive, and that file sending that acknowledgement, the number of retransmissions is exceeded, and also in that case, there is this don't know indicator, at the sending site. So in this particular case, there is no extra message to the receiving site, but the sender gets the message that the data transfer was successful, but there is still this don't know indication. And these two transitions should be compared, so there is this one situation where the data is properly delivered with the don't know indicator, and there is this sequence where the data is not properly delivered with this don't know indication at the sending site. Okay, if you have looked at this behavior, then we can also ask ourselves, can we reduce these behaviors such that we know exactly what is happening at either the sending or the receiving side. So we hide the behavior at the receiving side, and simply make a transition system of the behavior at the sending side, and we now do this modulo weak trace equivalence. And what we see is this typical picture. And I think it should quite satisfy us, because it's completely unsurprising. And according to our expectations, namely, what we do is we send this list of individual messages to the protocol, and our protocol will respond with one of these three options namely, the data did arrive. Well, so we gives an okay or it's says transmission filled, and you get a not okay message. Or we get this don't know, where protocol indicates that it has no clue on whether delivery was correct or not. And you can do the same, at sending and at the receiving side, namely at the receiving side, this is the behavior and it looks more complex. But actually, what you can see is, that this is also very structured and very natural. So look at the initial green states. We see, that at receiving sides we can get a first message, with the first indicator. We get, if we follow the outer rim of this pentagon, a second message with an increment indicator, a third message, a fourth message, and then actually a last message with a okay. Or at any time, we can get this, not okay indicator, indicating that transmitting this message actually fails somewhere, and that no more messages regarding this list of messages will arrive. And this should give a perfect understanding of the behavior of this protocol. Okay let's look at an exercise. So if you have this protocol would it be possible to repeatedly sent lists of messages to the protocol In such a way that the receiver will never, ever know that this is happening. And these are the answers and in order to answer this, we should of course look at external behavior of the protocols, so I provide it here. So what did we see? We modelled the core of the RC6 standards. And that's actually, relatively and easy thing to do with current tools. It should be possible to do it within a day, including complete analysis. We have seen that with behavioral reduction, we could get the total behavior and understand the total behavior, including the purpose of all these status messages. We have seen that we can also easily get the behavior at single interfaces, and understand how we can interact with the single interfaces. And there is something that we did not see. Namely we investigated the protocol further, looked at a number of other features and actually found a number of quite serious errors in there. And then it turned out for the protocol had already been implemented and put in all kinds of products, so unfortunately all our investigations did not lead to an improvement of the protocol, and that's really a pity, because also these extensions were extremely easy to analyze and was very easy to repair the problems that occurred. But Alas, this did not happen. In the next lecture, I would like to look into the state space explosion problem, and into guidelines on how to avoid this when making models. Thank you for watching. [MUSIC]