TASTE bugtrack - Taste
View Issue Details
0000719Taste[All Projects] OpenGeodepublic2017-11-22 16:012018-12-11 13:40
shd01 
maxime 
normalfeatureN/A
assignedopen 
0000719: Feature request: cleaner alternative for parameters of CHOICE type
It would be very convenient to be able to select input to SDL processes by type qualifiers, if the type of the signal parameter is a choice. When modelling signalling over a channel that carries a variety of packet types, I have to write muxers/demuxers that break out the choices from the parameter using "present" statements. Either that, or route each packet type across my diagram as a separate interface (which gets messy very quickly). Instead, it would be great if I could include the choice determinant in the input statement. Instead of this SDL: input inMsg(rxMsg); where rxMsg is of type MyChoice, with choices "a" and "b", I would have this: input inMsg(a:rxMsg) I have attached an OpenGeode screenshot (containing illegal code) to show how much cleaner it would be. Would this be easy to implement?
No tags attached.
related to 0000819closed ellidiss The "group" option does not work 
png choice_example.png (392,719) 2017-11-22 16:01
https://taste.tuxfamily.org/mantis/file_download.php?file_id=257&type=bug
png present_operator.PNG (437,619) 2017-11-22 16:28
https://taste.tuxfamily.org/mantis/file_download.php?file_id=258&type=bug
png routes1.png (35,565) 2018-11-30 09:53
https://taste.tuxfamily.org/mantis/file_download.php?file_id=287&type=bug
png

png sdl_block.png (71,184) 2018-11-30 09:53
https://taste.tuxfamily.org/mantis/file_download.php?file_id=288&type=bug
png
Issue History
2017-11-22 16:01shd01New Issue
2017-11-22 16:01shd01Statusnew => assigned
2017-11-22 16:01shd01Assigned To => maxime
2017-11-22 16:01shd01File Added: choice_example.png
2017-11-22 16:28maximeNote Added: 0003134
2017-11-22 16:28maximeFile Added: present_operator.PNG
2017-11-22 16:31maximeNote Added: 0003135
2017-11-22 16:59shd01Note Added: 0003136
2017-11-22 17:01shd01Note Edited: 0003136View Revisions
2017-11-22 19:17maximeNote Added: 0003137
2017-11-22 20:54shd01Note Added: 0003138
2017-11-24 09:37maximeNote Added: 0003154
2017-12-06 18:50shd01Note Added: 0003159
2018-11-30 09:53shd01File Added: routes1.png
2018-11-30 09:53shd01File Added: sdl_block.png
2018-11-30 09:57shd01Note Added: 0003526
2018-12-10 14:03maximeNote Added: 0003535
2018-12-11 13:40maximeRelationship addedrelated to 0000819

Notes
(0003134)
maxime   
2017-11-22 16:28   
This breaks SDL semantics. The input parameters cannot be evaluated to discriminate the transition. But the "present" operator is equally compact in terms of graphical representation. I do not think that a new syntax would improve readability Look at the picture I attached for an example. There is just one call to "present" and as many branches as there are choices in the ASN.1 type.
(0003135)
maxime   
2017-11-22 16:31   
(I think in your screenshot, you misuse the "present" operator. It does not return a boolean, it returns the actual choice item)
(0003136)
shd01   
2017-11-22 16:59   
(edited on: 2017-11-22 17:01)
Many thanks for your quick reply and for the clarification of the "present" operator. The problem remains, however, that I have to write mux/demux functions. This is because I am obliged to consume the signal at the input statement, when really I want the choices to be handled differently (or rejected) in the various states of my process. Mux/demux functions are ugly, as they they look like functionality when they are merely a modelling artefact. How about a "split/join" symbol in the interface view instead?
(0003137)
maxime   
2017-11-22 19:17   
I agree that you should not have to mux-demux message manually. Why are you grouping your messages into a CHOICE in the first place instead of using multiple messages?
(0003138)
shd01   
2017-11-22 20:54   
I'm modelling a transfer protocol on redundant serial buses. If I use multiple messages, then all those messages must be propagated over both arms of the bus, and to all its end points. The interface view gets pretty messy, and it's difficult to extend. Also it's harder to model the various layers of the protocol independently. I can send you some stuff to show you what I mean, but I can't post it on a public forum.
(0003154)
maxime   
2017-11-24 09:37   
Yes, please send me the models to maxime.perrotin@esa.int
(0003159)
shd01   
2017-12-06 18:50   
I am working on getting this for you. It currently doesn't compile due to what I suspect is an OpenGEODE bug, so I have raised http://taste.tuxfamily.org/mantis/view.php?id=725 [^]
(0003526)
shd01   
2018-11-30 09:57   
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.
(0003535)
maxime   
2018-12-10 14:03   
I moved the discussion here: https://gitrepos.estec.esa.int/taste/taste-setup/issues/3 [^] Can you please comment there? (It's easier to include images in the text)