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

ID | Project | Category | View Status | Date Submitted | Last Update
0006614 | Ext Pack: Continuous signal support (ES 202 786) | Technical | public | 12-09-2013 13:23 | 06-01-2015 16:59

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 | 0006614: Using streaming ports in static configurations

Description

The use of streaming ports (defined in extension package ETSI ES 202 786) in static configuration (defined in extension package ETSI ES 202 781) is not defined in either of the specifications.
Logically, it should be possible, but at there should be at least some rules regarding the sampling mechanism:
1. Time progress for static MTCs should start in the begining of configuration function(and not in the beginning of a test case)
2. Sampling of ports of static components shall be active even when a test case is not running (during transition between test cases)

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6614_v1.docx (79,606) 10-10-2014 08:59 http://oldforge.etsi.org/mantis/file_download.php?file_id=3140&type=bug

Issue History
Date Modified | Username | Field | Change
12-09-2013 13:23 | Tomas Urban | New Issue |
12-09-2013 13:23 | Tomas Urban | Clause Reference(s) | => ETSI ES 202 786 and ETSI ES 202 781
12-09-2013 13:23 | Tomas Urban | Source (company - Author) | => Elvior
07-10-2013 12:17 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Ext Pack: Continuous signal support (ES 202 786)
07-10-2013 12:23 | Gyorgy Rethy | Assigned To | => Jens Grabowski
07-10-2013 12:23 | Gyorgy Rethy | Status | new => assigned
07-10-2013 12:23 | Gyorgy Rethy | Target Version | => v1.2.1 (published 2014-06)
22-10-2013 08:45 | Tomas Urban | Note Added: 0011811 |
08-04-2014 10:30 | 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)
10-10-2014 08:59 | Tomas Urban | File Added: CR6614_v1.docx |
10-10-2014 09:01 | Tomas Urban | Note Added: 0012337 |
10-10-2014 09:01 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
10-10-2014 09:01 | Tomas Urban | Status | assigned => confirmed
06-01-2015 16:59 | Jens Grabowski | Note Added: 0012642 |
06-01-2015 16:59 | Jens Grabowski | Status | confirmed => closed
06-01-2015 16:59 | Jens Grabowski | Resolution | open => fixed

Notes

(0011811)
Tomas Urban
22-10-2013 08:45

If the above mentioned proposals are accepted, there will be an impact on TRI. Current clock-related functions (triStartClock, triReadClock, triNextSampling, triBeginWait, triProcessStep, triEndWait) expect one active clock. However, the use of configurations means that there will be several clocks running in parallel with different starts. I order to distinguish between them, there should be a dedicated "static" version of these functions containing one additional parameter of a TriConfigurationIdType. This type should have the same format as TriFuncionIdType (being derived from QualifiedName). The parameter shall contain a value of an active configuration for all TRI calls from a test case running on the configuration or an inactive configuration when performing sampling of its ports between test cases (in triNextSampling, triProcessStep).

(0012337)
Tomas Urban
10-10-2014 09:01

Proposal uploaded. It contains also complete TRI mapping which was actually resolved in 0006628 but for some reason didn't make it to the final version of the document. Please check.

(0012642)
Jens Grabowski
06-01-2015 16:59

Implemented according to proposal.