Time Paper Description Conceptual Mode of Sheet Focus Operation 00:00 Gets the problem statement handed over. Expresses some difficulties in understanding the specififcation on available hardware. 00:02 #1 Draws a sketch of a building with a number of elevators Drawing and floors. This is a virtuel building with n floors and m elevators. Afterwards he uses a couple of minutes to understand the rules under which the elevators have to move. 00:05 Asks what to understand by the sequentially servicing as Asking stated in the problem statement. Observer clarifies the uncertainties. 00:07 Expresses that the task consists of a number of control Independence Reflecting units namely the elevators. States that the elevator is Communication to be compared with an independent entity. Outlines some properties of the future solution as he sees it. He says that the floors can communicate with the elevator and that the elevator then can decide to which floors it wants to visit. Further, he says that the floors will not communicate with each other. He also states that some of his knowledge of this problem is not only based upon the problem statement, but also on his general knowledge of elevators. 00:10 Gives a first draft outline of his future solution. He is Parallel Drawing of the opinion that he will solve the task by having only Explaining one elevator servicing the floors. He considers the elevators to be non-committal and hence he will be able to put the elevators together in parallel later on (this can easily be done in CCS). The people on the floors and the elevator are then able to influence the behaviour of the elevator by pushing the buttons. He is not quite sure if it is okay to make the elevators independent, but he chooses this solution for the present. 00:11 Starts to specify. Introduces the concept of an elevator Proces Specifying shaft. He defines a shaft to consist of an elevator and Parallel all the floors. States that the elevator and each of the Synchronization floors are non-deterministic final automats which again could be compared to processes. The task at this point is to specify these in more detail. Afterwards one can then put these into parallel. It is, however, also possible to synchronize them. This is in CCS done by having some transitions with the same label. Describes the aspect of synchronization with the opening of doors in a elevator system where the elevator and the floors synchronize to achieve this action. According to his opinion this is how its done in real life and it is easy to model in CCS. 00:15 States that he now has a more general design sketch for his solution. However, afterwards he starts to discuss aspects of problem statement where he realizes that people can push the buttons in a randomized order. 00:17 #2 Starts to specify the entity of an elevator. This first Specifying shot involves an elevator and a push at a pushbutton. He outlines what states it goes from and to. 00:18 Realizes quickly that he needs some sort of a medium in Complexity Reflecting which he can storage the requests from already pushed buttons. This introduces some difficulties with his form of notation. 00:20 Asks observer about some uncertainties regarding how people can register requests and how these request should be serviced. Agrees with the observer that he might skip some of the information in the beginning. 00:21 Starts to specify the elevator again. This time he has Synchronization Specifying introduced a parameter that indicates which floors have registered requests. Outlines the consequences of pushing a button on a floor. 00:23 Realizes that the elevator also can turn into a reduced state when the elevator arrives at a floor registered in the parameter. States that he now has to look at the behaviour of a floor. 00:26 Starts to look at the problem statement again to resolve some uncertainties. This includes aspects of how an elevator change direction and what happens when an elevator has no more requests. 00:27 Continues with the specifying. Wants to add some "things" Specifying the state of an elevator. Expresses that he also has to incorporate what floor the elevator is currently located on. Meditates for a while of this problem. 00:29 #3 Specifies a floor in its initel state (a floor without Synchrinization Specifying any requests). Outlines from this floor that the only possible actions are pushing up or down. Draws the states to which the actions lead. The outcome of this is actually a state transistion diagram. He says that the state Elevator-Up is a state where a floor is waiting for an elevator to arrive and that this is elevator is going up. 00:33 Wants to build in some extra functionality into the Complexity Explaining elevator. Says that at first he will only modell an elevator that is going all the way up to the top floor and then all the way down in order to reduce the complexity of the solution. 00:34 #4 Starts a new specification of the elevator. Specifying 00:35 #2 Realizes he lacks some information on paper sheet number Complexity Explaining 2. Introduces a limitation where it is only possible to Time aspects push buttons that have not been pushed yet. Gives an informal introduction to the purpose and working of CCS. He stresses that the actions in CCS are of an atomar kind which implies that the execution of an action takes no time. He claims the existence of an enhanced version of CCS where the aspect of time has been incorporated and the use of this version would be much more applicable with this problem. However, this will introduce a lot more complexity and hence he will not introduce in this solution. He will rather have a more untrustworthy yet simple solution. 00:37 #4 Returns to the specifying of an up elevator. Outlines the Communication Specifying actions possible for an elevator going up. He is aware of the fact that this solution is neither efficient nor economical sound. The specification further involves the pushing of not yet pushed buttons. 00:38 Suddenly he realizes that with his current solution the Reflecting elevators will move up and down all time even without any requests. He is not quite sure how this can be fixed. 00:40 Continues with the specifying of an up elevator. Specifying Specifies that the up elevator turns into a down elevator with it reaches the top floor. 00:42 Stops to reflect upon additional conditions that have to hold for a floor. Says thát the pushing on buttons is provided the users. 00:43 #5 Draws an abstract symbol of an elevator with one Synchronization transparent action push. Assumes that the users will push the buttons whenever they fell like it. In his solution he will not modell the users. Draws also an abstract symbol of a floor and says the these two synchronize upon the action of opening a door or closing a door. 00:47 #4 Returns to his specification of the up elevator where he Complexity Specifying wants to incorporate the aspect of opening a door. Realizes that it is not quite simple to specify which floors the elevator has to visit. His previously designed attribute describing all pushed buttons only involve the elevators pushbuttons and not the floors. Reduces some complexity by replacing the action open door with the action sync. Action sync defines that the doors open, people get out and in, and the doors close again. 00:51 #3 Returns to his state transistion diagram to incorporate Time aspects Specifying his latest knowledge of the action sync. Stresses once more that he is not modelling the time aspect. Explains how the transition diagram should be interpreted. 00:54 #4 Adds some information to his up elevator. Tries to figure Synchronization Specifying out when the floor is synchronizing with the elevator. 00:58 Talks informally about actions that the world must not Reflecting see in this kind of systems. Visualizes it with a tall Drawing building where people enter the building and later leave the building. The outside world does not know what has happen in between. He is uncertain whether the sync action should be unvisible to the outside world. Expresses difficulties how this can be specified in CCS. 01:00 #3 Adds information to his state transistion diagram about a Specifying down elevator. 01:04 #6 Starts to draw a state transition diagram for the up elevator. Seems to be faced with some difficulties and gradually stops to think aloud during this period. After a couple of minutes he asks if the observer wants another CCS expression or maybe a more realistic solution where the elevators do not have to go all the way up or down. 01:07 Observer says that it could be interesting to see what synchronization are involved between elevators. 01:09 During this discussion he realizes that he has misunderstood the functions of the pushbuttons on the floors. Has some difficulties in understanding that there is only one set of pushbuttons at each floor. 01:13 States that the elevators have to have more information Communication Explaining on each other at all times. Claims that it is not very difficult to get the elevators communicate all they have to do is to live in the same universe. 01:14 #5 Sketches a possible solution for above outlined problem. Drawing Here he is using a more informal type of notation. He is of the opinion that deciding which elevator that has to serve a request is a trivial task. However, he soon realizes that more factors influence this decision: which elevator is nearest, which direction is it going etc. He changes his opinion of this being a trivial task. 01:17 States that it is possible to design a more decentralized Decentralizatio solution in CCS. This would imply that elevators would n Broadcast hear a request from a floor and then they should decide which elevator to service the request autonomously. But he stresses that this is not easily solved. Claims that the use of broadcast should be avoided. 01:19 Observer says that it would be interesting to see how the avoidence of having all elevators service a request from a floor. The observer also asks whether the solution avoids starvation whereto he replies that since the elevators move all the way up and all the way down no floor will suffer from starvation in his solution. Observer and designer discusses the potential content of the rest of the experiment and agree upon looking at the synchronization between elevators. 01:22 #7 Starts to specify an action for receiving requests from Communication Specifying elevators. Says that when this action has received a request it has to go into another state where the request is been processed. 01:23 Suddenly stops the specifying and states that you get Communication Explaining some properties for free in CCS. He continues, when a floor has a request then it is only one elevator that are able to "hear" this fact. This is defined by the operational semantics. Illustrates this fact on middle of paper sheet number 7. So when using CCS a request from a floor is only serviced by one elevator. 01:28 #4 States that the just specified action on paper sheet number 7 could be incorporated into the up elevator action. However, he realizes that the chosen elevator for a request may likely not be the optimal one. 01:30 #7 Continues with the specifying. The spcification is the Synchronization Specifying final version of the up elevator where all possible actions are included. Part of this action is already outlined at paper sheet number 4. The actions includes the movement of the elevator in an upward direction, the receiving of requests from all the floors, and the synchronizing with the floors when people wants to get on or off. After the specifying, he compares the actions with the state transition diagram illustrated at paper sheet number 3. 01:34 States that the solution so far could be put into a Parallel parallel composition consisting of the floors and the elevators. 01:35 Starts to simulate a scenario in order to test his Synchronization Experimenting solution. Adds some information to his state transistion diagram for the elevator. Asks himself when the action sync can be performed. Says that this can be performed when a request has been registered either in the elevator or on the floor. Thereby you can perform the action sync and let the floor and the elevator synchronize. Stresses once more that his current solution is certainly not the most optimal one. When a request has be given at one of the floors this request will be heard by one of the elevator. However, as he points out you do not know which elevator will hear this request. 01:39 He claims that he would be nice to have a medium in CCS Communication where you could exchange information which could be heard be all entities involved. Then he would like to have some intelligent unit that could tell the elevators which to service the requests. But this cannot be done in pure CCS where only two entities can communicate at a time. He is, however, of the opinion that this could be solved by introducing a communication function. 01:41 #8 Draws a sketch of some elevators in order to illustrate Communication Drawing how the above communication function could be designed. This sketch is of a very informal nature with respect to CCS. 01:45 States that the deciding of the closest elevator to Complexity Explaining service a request is like hell in CCS. He would rather describe such aspects in another language e.g. Pascal. He further says that at first the algorithm looked quite simple but he later realized that this was not the case. 01:46 Says that CCS can be used when you are designing a system Parallel with a lot of components. For each of these components Synchronization you can define a state machine. The semantics for letting them act in parallel has been given by the paradigm. And yo can further let them synchronize on certain actions. 01:49 States that the cores of the CCS are the aspects of Concurrency Reflecting concurrency and communication. CCS solves the problem of Communication describing state machines living in parallel. This would Parallel be very complicated in e.g. Pascal wher you don not have the same medium for expressing these things. So finally, he is of the opinion that CCS is well-suited for specification but not that well-suited for actual implementation. 01:52 Says that the concept of proces is blurred in CCS. One Proces Explaining can consider the higher level entities as processes but it is also possible to consider the lower level entities as processes. He has difficulties in determine more abstract processes in his solution. 01:55 Observer and designer discusses some aspects of processes and concurrency informally.