ETSI's Bug Tracker - Ext Pack: Continuous signal support (ES 202 786)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006610 | Ext Pack: Continuous signal support (ES 202 786) | Technical | public | 04-09-2013 11:04 | 20-06-2014 10:20

Reporter | Tomas Urban |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v1.1.1 (published 2012-04) |
Target Version | v1.3.1 (published 2015-06) | Fixed in Version |  |

Summary | 0006610: Continuous signalling: restrictions on mapping of stream ports

Description

There are no specific rules on connecting and mapping stream ports. It means that the core language specification rules shall be used in these situations. However, the concept of streaming is unknown to the core rules, so they cannot be used directly, but only interpreted. In my opinion, it is an undesirable situation.
Proposal:
Dedicated restrictions on connecting and mapping stream ports shall be added to the continous signalling specification as follows:
a) The connect operation is allowed only if the in value type of port 1 is equal to the out value type of port 2 and the out value type of port 1 is equal to the in value type of port 2
b) The map operation is allowed only if the in value type of port 1 is equal to the in value type of port 2 and the out value type of port 1 is equal to the out value type of port 2
c) Incoming stream ports of a test component and outgoing stream ports of the system adapter cannot be connected/mapped to more than one port (The sampling procedure can insert only a single value into the incoming stream in one sampling step and with 2 or more connected/mapped ports it is not obvious from which port would that value come. Such limitation is not necessary for outgoing stream ports and incoming ports of the system adapter, which might be useful e.g. for streaming to several PTCs.)

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6610_v1.docx (16,453) 10-04-2014 11:10 http://oldforge.etsi.org/mantis/file_download.php?file_id=2990&type=bug

Issue History
Date Modified | Username | Field | Change
04-09-2013 11:04 | Tomas Urban | New Issue |
04-09-2013 11:04 | Tomas Urban | Clause Reference(s) | => 5.2
04-09-2013 11:04 | Tomas Urban | Source (company - Author) | => Elvior
25-09-2013 14:57 | Jacob Wieland - Spirent | Note Added: 0011673 |
07-10-2013 12:30 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:31 | Gyorgy Rethy | Assigned To | => Jens Grabowski
07-10-2013 12:31 | Gyorgy Rethy | Status | new => assigned
07-10-2013 12:31 | Gyorgy Rethy | Target Version | => v1.2.1 (published 2014-06)
10-10-2013 22:11 | Tomas Urban | Note Added: 0011763 |
11-10-2013 13:33 | Jacob Wieland - Spirent | Note Added: 0011778 |
11-10-2013 14:08 | Tomas Urban | Note Added: 0011782 |
14-10-2013 13:35 | Jacob Wieland - Spirent | Note Added: 0011805 |
08-04-2014 10:42 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
08-04-2014 17:09 | Gyorgy Rethy | Product Version | => v1.1.1 (published 2012-04)
08-04-2014 17:09 | Gyorgy Rethy | Target Version | v1.2.1 (published 2014-06) => v1.3.1 (published 2015-06)
09-04-2014 15:00 | Tomas Urban | Note Added: 0011973 |
09-04-2014 15:00 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
10-04-2014 11:10 | Tomas Urban | File Added: CR6610_v1.docx |
10-04-2014 11:13 | Tomas Urban | Status | assigned => confirmed
20-06-2014 10:20 | Jens Grabowski | Note Added: 0012181 |
20-06-2014 10:20 | Jens Grabowski | Status | confirmed => closed
20-06-2014 10:20 | Jens Grabowski | Resolution | open => fixed

Notes

(0011673)
Jacob Wieland - Spirent
25-09-2013 14:57

How do these restrictions (a/b) differ from the normal restrictions? Also, why isn't the normal disambiguation (from/sender) possible if an incoming port is mapped/connected to multiple other ports?

(0011763)
Tomas Urban
10-10-2013 22:11

The difference is in terminology. Streaming ports always support one type called "value type" while message and procedure ports have message or procedure lists. Since there's always one type, it is not necessary to use set comparison, but the compatibility rule is based on simple equality. But technically, the rules are similar. My intention was merely to provide explict rule so that the reader doesn't have to derivem them himself/herself.
Regarding source disambiguation: I don't think it is possible. Let's imagine the situation of having one incoming stream connected to two outgoing streams. The incoming stream gets its value during sampling procedure (which is active in the background without user interference and therefore cannot be influenced by any from/sender clause). With two outgoing streams, there are two candidates for the source value. Which one will be taken and stored in the port history? Will the TE store both and somehow create two parallel histories? The current specification doesn't consider it possible. Of course, one might modify the rules for value, history and values operations and add a from/sender operation to them to handle this parallelism, but is it actually necessary? Are there any users requiring it? I seriously doubt about it. And for that reason I proposed the restriction c which efficiently removes the problem of multiple source streams.

(0011778)
Jacob Wieland - Spirent
11-10-2013 13:33

I think the single-source/multiple-target restriction makes sense. Regarding the connect/map restrictions, I think a NOTE could be sufficient which clarifies that the rules that exist for lists of types also work for these single-element-lists in the same way.

(0011782)
Tomas Urban
11-10-2013 14:08

I might tentatively agree with a note, but I don't think it is a correct approach.
The original rules operate with terms inlist-PORT1, inlist-PORT2, outlist-PORT1, outlist-PORT2. These terms are define as messages or procerures in the in/out direction of a particular port. However, stream port don't contain messages or procedures, but a stream value type (see semantic description in 5.2.2.1). This term is not mentioned in the original rule.
In my opinion, all specifications should rigorously use correct terminology in order to be interpreted correctly. That's the reason why I proposed a dedicated rule for stream ports.
And there's a second reason, I totally forgot about in my previous post. Without the proposed rules, one might consider stream value type equal to a message list with one element, which would efficiently make it possible to map/connect stream ports with/to message ports.

(0011805)
Jacob Wieland - Spirent
14-10-2013 13:35

I agree that the restriction that stream ports shall only be connected/mapped to other stream ports is a valid point.
I also have no problem of repeating the more general statement from the standard in a more specialized way here, but I think that simple additional restrictions and stating that - except for the restrictions - a stream port behaves like a message port with one message type regarding map/connect would also be totally sufficient.

(0011973)
Tomas Urban
09-04-2014 15:00

Resolution uploaded. Please check.

(0012181)
Jens Grabowski
20-06-2014 10:20

Implemented as proposed in the DRAFT of the next version.