Design

Learning Design Diagrams (part 1: the basics)

Design Diagrams describe a design of the system, i.e. they describe the structure and the behavior of the final system: this is no more the analysis of the system specification but rather the creation of a system respecting the system specification.

Open the slides on Modeling in SysML.

Watch the video on Design (part #1) and answer to the following questions when asked to pause the video.

Slide 57: What happens when executing this system? To find the answer, you may think about the depicted system, or you can also go to the section below called "Practising with Block Diagrams": watch the video on TTool, and make the model in the slides within TTool, then simulate it as explained in the video.
(Solution) Actually, nothing happens! Indeed, at first, Block0 tries to send sig1, which is a synchronous signal. Therefore, Block0 must wait for a block to be ready to receive sig1. But block1 is not ready to receive sig1 since it is waiting for sig2. So, there is a deadlock in this system.

Slide 58: What happens when executing this system?
(Solution) At first, since Block1 waits for sig2 that was not yet sent, Block1 is blocked. Block0 first sends sig1(5), then sig1(6). Since the FIFO is of size 1 with a bucket approach, sig(6) is trashed since the FIFO for sig1 signals already contains sig1(5). Then, sig2(7) is sent, and Block0 terminates. Block1 can now read sig2(7) (so it stores 7 in its x attribute). Then Block1 reads sig1(5) and terminates. The FIFO of sig1 and sig2 are both empty at the end of system execution.

Slide 59: What happens when executing this system?
(Solution) Block1 cannot execute because it waits for sig2. So Block0 executes first. It sends sig1(5) which is added to the FIFO of sig1. Then, Block0 tries to send sig1(6) but since the FIFO for signals sig1 is full, Block0 cannot perform the sending: Block0 is suspended. Since no block can execute, the system terminates.

Slide 60: What happens when executing this system?
(Solution) The sending of go_out synchronizes with the receiving of go_in, either in T1 or T2. So, there are two possible executions. (1) Synchronization between T0 and T1 go_out / go_in, then synchronization between done_out(1) and done_in(1), termination. (2) Synchronization between T0 and T2 go_out / go_in, then synchronization between done_out(2) and done_in(2), termination.

Learning Design Diagrams (part 2: advanced concepts)

Open the slides on Modeling in SysML.

Watch the video on Design (part #2) and answer to the following questions when asked to pause the video.

Slide 61: What happens when executing this system?
(Solution) Since the channel is a broacast channel, there are now three possibilities: either T0 and T1 synchonize, or T0 and T2, or T0, T1 and T2. The first two cases are similar to the ones described in previous slide. The last case is as follows. T0 sends go_out and T0 and T1 both receive go_in. Then, there are two subcases. Either T1 exchanges done_out(1) / done_in(1) with T0, and then T2 exchanges done_out(2) / done_in(2) with T0, or either T2 exchanges done_out(2) / done_in(2) with T0, and then T1 exchanges done_out(1) / done_in(1) with T0.

Practising with Block Diagrams

You cannot start by making the block diagram and state machine of the railroad crossing system: you first need to practise with much more simple diagrams. And you also first need to be at ease with TTool.

Starting with TTool

You obviously first need to TTool on your computer.

Watch My first Avatar model (video): how to make an AVATAR design, and how to perform simulations.

You may also consult the tutorial on AVATAR whenever necessary.

Pressure Controller

Open the PressureController model in TTool

Perform simulations of the model. Using the simulator, make the following traces:

Start the alarm
Start the alarm, and then see what happens when a second "highPressure" is detected while the alarm is already "ON"
Show a trace when the alarm has been set to "ON" and then to "OFF"
Show a (long) trace where the alarm is never started