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

ID | Project | Category | View Status | Date Submitted | Last Update
0006625 | Ext Pack: Continuous signal support (ES 202 786) | Clarification | public | 07-10-2013 13:37 | 20-06-2014 10:31

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 | 0006625: Sampling rate of modes

Description

The current specification doesn't give clear guidelines whether it is possible to change a sampling rate of modes by the means of the stepsize parameter or whether sampling always occurs at basic sampling rate.
The chapter 5.1.2 says that "in addition, sampling rates can
be set separately and as part of the test specification by means of stepsize attribute." That would point out to the possibility that any sampling rate can be changed, including the one used in modes.
However, the following paragraph mentions only port sampling rates: "This number (i.e. the value associated with the stepsize parameter) interpreted as seconds is used as the default rate of sampling values over the stream ports to which are affected by this stepsize attribute."
In my opinion, the specification should explicitly specify if the stepsize attribute affects modes or not to prevent possible misinterpretation and one of the following rules shall be added to the specification:
1. (This number interpreted as seconds is used ... over the stream ports) and the sampling rate of modes (which are affected by this attribute).
2. The stepsize attribute has no effect on sampling procedure of modes; mode sampling rate is always equal to the basic rate of the concrete test system.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6625-Resolution-V1.doc (228,352) 10-10-2013 16:19 http://oldforge.etsi.org/mantis/file_download.php?file_id=2922&type=bug CR6625_v2.docx (72,484) 20-06-2014 10:27 http://oldforge.etsi.org/mantis/file_download.php?file_id=3071&type=bug

Issue History
Date Modified | Username | Field | Change
07-10-2013 13:37 | Tomas Urban | New Issue |
07-10-2013 13:37 | Tomas Urban | Clause Reference(s) | => 5.4
07-10-2013 13:37 | Tomas Urban | Source (company - Author) | => Elvior
07-10-2013 13:37 | Tomas Urban | TS version | => 1.2.1
07-10-2013 13:39 | Tomas Urban | Note Added: 0011686 |
07-10-2013 14:18 | Gyorgy Rethy | Note Added: 0011688 |
07-10-2013 14:18 | Gyorgy Rethy | Assigned To | => Jens Grabowski
07-10-2013 14:18 | Gyorgy Rethy | Status | new => assigned
07-10-2013 14:18 | Gyorgy Rethy | Target Version | => v1.3.1 (published 2015-06)
07-10-2013 14:18 | Gyorgy Rethy | Project | Ext Pack: Config & Deployment Support (ES 202 781) => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 14:19 | Gyorgy Rethy | Product Version | v1.2.1 (published 2013-06) =>
07-10-2013 14:19 | Gyorgy Rethy | Target Version | v1.3.1 (published 2015-06) => v1.2.1 (published 2014-06)
10-10-2013 16:19 | Jens Grabowski | File Added: CR6625-Resolution-V1.doc |
10-10-2013 16:20 | Jens Grabowski | Note Added: 0011759 |
10-10-2013 16:20 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
11-10-2013 12:33 | Jacob Wieland - Spirent | Note Added: 0011774 |
11-10-2013 12:37 | Jacob Wieland - Spirent | Note Edited: 0011774 |
11-10-2013 12:38 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
11-10-2013 12:38 | Jacob Wieland - Spirent | Status | assigned => confirmed
11-10-2013 13:56 | Tomas Urban | Note Added: 0011780 |
14-10-2013 13:45 | Jacob Wieland - Spirent | Note Added: 0011806 |
14-10-2013 14:17 | Tomas Urban | Note Added: 0011807 |
08-04-2014 10:42 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
08-04-2014 10:42 | Jens Grabowski | Status | confirmed => assigned
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:50 | Tomas Urban | File Added: CR6625_v1.docx |
09-04-2014 15:50 | Tomas Urban | File Deleted: CR6625_v1.docx |
09-04-2014 15:51 | Tomas Urban | File Added: CR6670_v2.docx |
09-04-2014 15:58 | Tomas Urban | Note Added: 0011975 |
09-04-2014 15:58 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
10-04-2014 11:14 | Tomas Urban | Status | assigned => confirmed
20-06-2014 10:25 | Tomas Urban | File Deleted: CR6670_v2.docx |
20-06-2014 10:27 | Tomas Urban | File Added: CR6625_v2.docx |
20-06-2014 10:31 | Jens Grabowski | Note Added: 0012182 |
20-06-2014 10:31 | Jens Grabowski | Status | confirmed => closed
20-06-2014 10:31 | Jens Grabowski | Resolution | open => fixed

Notes

(0011686)
Tomas Urban
07-10-2013 13:39

I am sorry for entering this issue under a wrong specification. It belongs to continuous signalling extension package.

(0011688)
Gyorgy Rethy
07-10-2013 14:18

Pls. Jens, look at this as well.

(0011759)
Jens Grabowski
10-10-2013 16:20

Proposal for Tomas ok, assigned to Jacob for cross-checking.

(0011774)
Jacob Wieland - Spirent
11-10-2013 12:33 (edited on: 11-10-2013 12:37)

There is, in my opinion, no sampling rate for modes. The only things that are sampled are stream ports. Their sampling activates mode-steps which then use the latest sampling values.
It is even conceptually. allowed to have modes which work on ports with different sampling rates. The mode, in essence is not an active entity, but a passive one which is event-and-sampling-driven.
Thus, I think the CR is invalid and should be rejected.

(0011780)
Tomas Urban
11-10-2013 13:56

I am afraid that I absolutely disagree with this explanation. I couldn't find a single word in the current specification saying that modes are passive event-driven entities.
All that I can read from the specification is that while a mode is active, its content is executed periodically, once each sampling step. Please notice that the specification even explicitely uses word "active" when describing mode behaviour.
In addition to that, current rules contained in the chapter of modes refer simply to "sampling step" without saying that it is actually a sampling step related to ports referenced inside mode statements. The current specification also doesn't say anything about dependency of sampling on events which you offer as an alternative trigger for mode activity.
Besides, there are practical problems related to the passive approach:
1. Modes can be defined without refering any port or trigger event. What would be the sampling step then?
2. Relevant ports (used in invariants and until guards) might be hidden behind functions containing runtime-evaluated branchinch statements. Gathering port references from these functions calls requires very complex analysis of the runtime code and might be practically impossible in some cases.

(0011806)
Jacob Wieland - Spirent
14-10-2013 13:45

As I was highly involved in the conception of the continuous package, I can assure you that there was never any concept of sampling rate of modes intended. They shall only be activated by ports being sampled or other non-periodic events (like message reception) they wait for.
The only things that are supposed to have sampling rates are the ports which then, when used by the modes, inflict an (implicit) sampling rate per mode, but, if the mode uses more than one port with different sampling rates, the activation of the modes by the ports is very arbitrary and has nothing much to do with a 'rate' anymore.
If our intention is not clear from the text, that needs to be clarified, but not by introducing concepts that clearly contradict our intention.

(0011807)
Tomas Urban
14-10-2013 14:17

Jacob, thank you for explanation. I have no problem with this concept, but I am afraid that the impression one can have from the the current text is that mode is an active statement whose stepsize can be set. At least I had this impression.
Actually, if the specification clearly stated that modes are always sampled using the base sampling rate, the concept of activity or passivity would be irrelevant, because port sampling rates are required to be multiples of the base sampling rate (there would be still differences e.g. in logging output, but similar differences occur during taking snapshots in alt statements and they do not affect test results). Such a rule (or similar) would be in line with the general approach used in the TTCN-3 specification: to introduce theoretical concepts rather than include implementaion details.
I would also appreciate if the specification contained operational semantics for mode statements. These statements are quite complicated and different from those known from standard programming languages. Operational semantics would provide the reader with schematic description of the concept and it could prevent misunderstandings of this kind.

(0011975)
Tomas Urban
09-04-2014 15:58

New draft created according to Jacob's comments. It contains a rule that modes alway use the base sampling and that the stepsize attribute doesn't have any effect. In addition, there's a note saying that mode sampling is just a theoretical concept, not a prescription for implementation and that implementation details might differ. Jacob's sample of passive approach with triggers is used as an example of possible implementation.
I hope the rules written this way are acceptable for everyone.
Jens, could you please check the resolution?

(0012182)
Jens Grabowski
20-06-2014 10:31

Implemented as proposed in the latest resolution proposal (V2).