taste-setup issueshttps://gitrepos.estec.esa.int/taste/taste-setup/-/issues2023-09-01T13:47:22Zhttps://gitrepos.estec.esa.int/taste/taste-setup/-/issues/8Port python3 viewers in COMPASTA2023-09-01T13:47:22ZAlberto BonizziPort python3 viewers in COMPASTAAlberto BonizziAlberto Bonizzihttps://gitrepos.estec.esa.int/taste/taste-setup/-/issues/3Feature request: cleaner alternative for parameters of CHOICE type2018-12-10T14:53:21ZMaxime PerrotinFeature request: cleaner alternative for parameters of CHOICE typeThis ticket is created to hold further the Mantis ticket 719 (https://taste.tuxfamily.org/mantis/view.php?id=719)
I'll try to summarize the issue and discuss possible solutions. Moving from Mantis allows easier inclusion of screenshots ...This ticket is created to hold further the Mantis ticket 719 (https://taste.tuxfamily.org/mantis/view.php?id=719)
I'll try to summarize the issue and discuss possible solutions. Moving from Mantis allows easier inclusion of screenshots and code snippets. When a proper solution is agreed, the conclusion will be pub back on Mantis.
The point concerns systems with protocols exchanging multiple messages.
If `function_A` can receive 10 messages, it is possible to model the system at least in two ways:
1) the usual way = 1 PI per message:
![image](/uploads/1346c6474c76c4ecf4909f156b9ab61c/image.png)
This should be the right way in the sense that all communication is shown. However this way makes the diagrams quickly impossible to read, and this is a *major issue*.
2) By grouping the messages into some form of PDUs - using CHOICE parameters
![image](/uploads/32cac7d0149438e590fe828a57be996f/image.png)
In this form, possibly _all the functions of the system_ may receive the same parameter type, of this form:
```
TC-Param ::= CHOICE {
msg1 Type1,
msg2 Type2,
...
}
```
This form is graphically better at interface view level, but the main drawback is that it implies manual demux:
![image](/uploads/c1c1a08a7df87a602eb19540d246e265/image.png)'
Since there is only one message, every state have to do the demux and this messes up the whole state machine.
Steve notes:
> I think the problem is that not enough use is made of signal routes. In normal SDL, you can route sets of signals together and it appears as a single channel on the diagram. These can be split into individual signals inside lower level decompositions to connect to either blocks or processes (see routes1.png) TASTE clearly has this concept (see sdl_block.png) but it is not possible to create hierarchies of blocks, so it is not useful. Allowing block hierarchy would solve the problem completely and would be a faithful implementation of SDL.
The point therefore is to avoid the second option (CHOICE type) and favour the use of separate PIs per message.
Block hierarchy in the interface view is partially supported but the grouping of messages remains suboptimal (and buggy):
In principle when you create a system with nested functions:
![image](/uploads/ed7112cd9978213a5be75be87edd007e/image.png)
It _should be possible_ to group several messages using the `group` button on the toolbar:
![image](/uploads/7353a8b750a6d8de4de70a6a30749b01/image.png)
However, I just tested it does not work as expected (will report to Ellidiss). At the moment it messes up the diagram.
Would this approach help fixing the issue?
(Cleaner diagrams at interface view level and no manual demultiplexing of the messages)Maxime PerrotinMaxime Perrotin