Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000719Taste[All Projects] OpenGeodepublic2017-11-22 16:012018-12-11 13:40
Reportershd01 
Assigned Tomaxime 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusassignedResolutionopen 
PlatformOSOS Version
Summary0000719:

Feature request: cleaner alternative for parameters of CHOICE type

Description

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?

TagsNo tags attached.
Attached Filespng file icon choice_example.png [^] (392,719 bytes) 2017-11-22 16:01
png file icon present_operator.PNG [^] (437,619 bytes) 2017-11-22 16:28
png file icon routes1.png [^] (35,565 bytes) 2018-11-30 09:53


png file icon sdl_block.png [^] (71,184 bytes) 2018-11-30 09:53

- Relationships
related to 0000819closedellidiss 

The "group" option does not work

 

-  Notes
(0003134)
maxime (administrator)
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 (administrator)
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 (reporter)
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 (administrator)
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 (reporter)
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 (administrator)
2017-11-24 09:37

Yes, please send me the models to maxime.perrotin@esa.int

(0003159)
shd01 (reporter)
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 (reporter)
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 (administrator)
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)


- Issue History
Date Modified Username Field Change
2017-11-22 16:01 shd01 New Issue
2017-11-22 16:01 shd01 Status

new => assigned

2017-11-22 16:01 shd01 Assigned To

=> maxime

2017-11-22 16:01 shd01 File Added: choice_example.png
2017-11-22 16:28 maxime Note Added: 0003134
2017-11-22 16:28 maxime File Added: present_operator.PNG
2017-11-22 16:31 maxime Note Added: 0003135
2017-11-22 16:59 shd01 Note Added: 0003136
2017-11-22 17:01 shd01 Note Edited: 0003136 View Revisions
2017-11-22 19:17 maxime Note Added: 0003137
2017-11-22 20:54 shd01 Note Added: 0003138
2017-11-24 09:37 maxime Note Added: 0003154
2017-12-06 18:50 shd01 Note Added: 0003159
2018-11-30 09:53 shd01 File Added: routes1.png
2018-11-30 09:53 shd01 File Added: sdl_block.png
2018-11-30 09:57 shd01 Note Added: 0003526
2018-12-10 14:03 maxime Note Added: 0003535
2018-12-11 13:40 maxime Relationship added

related to 0000819



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker