Logo etsi

ETSI's Bug Tracker

Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007978Ext Pack: Config & Deployment Support (ES 202 781)New Featurepublic13-08-2020 15:0018-12-2020 14:36
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv1.7.1 (published 2019-04) 
Target Versionv1.8.1 (ongoing)Fixed in Versionv1.8.1 (ongoing) 
Summary0007978: Dealing with parallel control components
DescriptionTCI functions should be added to the CH interface to deal with:
- creation of parallel control components
- starting of PCCs
- termination of PCCs
- done/killed of PCCs
- alive/running of PCCs

These should mainly be copies of the same functionality for PTCs with the exception of verdict handling
TagsNo tags attached.
Clause Reference(s)6.1.13, 7.3.3, 8.5.3, 9.4.3, 10.6.3,12.5.3, C.3
Source (company - Author)Spirent - Jacob Wieland
TS version
Attached Filesdocx file icon CR7978.docx [^] (1,419,628 bytes) 05-10-2020 13:26
docx file icon CR7978-2.docx [^] (923,429 bytes) 08-10-2020 15:40
docx file icon CR7978-3.docx [^] (933,358 bytes) 07-12-2020 14:53
docx file icon CR7978-4.docx [^] (1,112,937 bytes) 08-12-2020 13:08
docx file icon CR7978-5.docx [^] (231,066 bytes) 10-12-2020 13:19
docx file icon CR7978-6.docx [^] (231,344 bytes) 11-12-2020 11:58
docx file icon CR7978-7.docx [^] (275,617 bytes) 11-12-2020 12:27

- Relationships
related to 0007910closedJens Grabowski Part 01: TTCN-3 Core Language Allow parallel control parts/components 

-  Notes
(0015757)
Jacob Wieland - Spirent (reporter)
05-10-2020 12:42

Having reviewed the existing TCI for component handling, I don't think new functionality needs to be introduced for handling of control components after all, as the CH is completely agnostic to what purpose a component has.

The only exception is the functionality tciGetMTCReq/tciGetMTC.

This should be supplemented by tciGetParallelMTC(TriComponentId pcc) to provide the mtc associated with the given pcc. As before, tciGetMTC() should give back the mtc executed by the MCC (if any).
(0015758)
Jacob Wieland - Spirent (reporter)
05-10-2020 13:27

please review
(0015782)
Jacob Wieland - Spirent (reporter)
08-10-2020 15:41

please review draft in Config&Deployment (still without TCI)
(0015788)
Tomas Urban (developer)
09-10-2020 08:35

I am basically fine with the proposed draft. However, I found three issues:
1. any and all component operations cannot have exactly the same semantics as in the core language standard as they are related to PTCs, while they should be related to PCCs in this case.
2. What is the use case for allowing map and connect operations in MCC and PCCs? I thought that communication operations are used only for controlling the test execution, i.e. for exchanging data between the control components. Are they supposed to be used for setting up the test run on the SUT side? If it is so, we should add a note explaining this so that users don't start to implement test logic directly in the control components.
3. There's a typo in the 2nd paragraph of 5.3.0 exected -> executed
(0015800)
Jacob Wieland - Spirent (reporter)
07-12-2020 14:55

I have addressed the issues and added the other changes to the TciCHRequired/TciCHProvided interfaces in the different language mappings needed for getting the mtc associated with a running pcc.
(0015812)
Tomas Urban (developer)
08-12-2020 13:12

I am mostly fine with the last proposal, I only made two minor changes:
- changed "testcase" to "test case" as the core language specification usually uses the latter term
- added a note describing the purpose of communication between MCC/PCC and the SUT

Since it is a long proposal, could you please check it two and if you are fine with it, assign it back to Jacob for final acceptance.
(0015830)
Kristóf Szabados (reporter)
09-12-2020 21:23

1)
Teh description sounds a bit confusing. There is nothing on what an MCC or PCC is, but there is a description on what it might do.

2)
I know this is nitpicking, but according to the current description an MCC may create PCC while "executing" a control function ... but is also allowed for it to simply not do anything, irrespective of what the user wanted.

Please note that the core in similar circumstances talks about executing the behaviour defined in the body of the test case ... aka. the behaviour is performed, while the current description allows to simply write out onto the screen "executig the control function".

Also in the core the behaviour shall execute on the component ... not may do something.

3)
Please note that according to the current description parallel test execution is not yet allowed.
The core states: "Within every configuration there shall be one (and only one) Main Test Component (MTC)"

As this is not overriden here, effectively it does not matter how many PCC there are in the system, only one of them can have a test case executing at any point in time.
(0015831)
Kristóf Szabados (reporter)
09-12-2020 21:40

4)
It is not clear how the existing component operations, like any component, changes.

The current description contains: "coordinated parallel execution of independent test cases "

However if each test cases running parallelly on PCCs is independent, than any component and all component shall refer only to the components started on the PCC they are invoked on, not every component in the whole system irrespective of which PCC they were started on.

Otherwise the test cases are not independent.

5)
Actually any component and all component, if I understand correctly should refer to different set of PTCs on each PCC and a separate set of PCCs on the MCC.

6)
According to the core standard the create operation shall return a unique component reference of the newly created instance.

In the context of MCC and PCCs, it needs to be clarified if that means systemwide uniqueness or uniqueness only in the context of a given PCC.
(for example when tools log something also containing the component reference do we wish to allow to have the same component reference on several PCC -s confusing the user or not)
(0015834)
Tomas Urban (developer)
10-12-2020 08:02

I think Kristof's remarks are addressed to Jacob, who is the author of the proposal. Jacob, could you please comment?
(0015840)
Jacob Wieland - Spirent (reporter)
10-12-2020 13:21

I have addressed all your points in the last draft. Please review.
(0015845)
Kristóf Szabados (reporter)
11-12-2020 10:29

1)
maybe there should be a note for implementors, that while the local ids of components can be the same in different testcases, they can also differ (having a benefit during human processing of logs)

2)
"test`case " might be a typo.

3)
"When the main control function is started"
Please note, that the term "main control function" is not defined.

Maybe we could say that the "control function started first is called/becomes the main control function"
(0015846)
Kristóf Szabados (reporter)
11-12-2020 10:29

4)
"Inside the behaviour definition being executed by a control component it is allowed to dynamically create additional parallel control components (PCCs) and start them with other control behaviour "

This seems to contradict itself.
If control components are not allowed to execute behaviour (other than creating additional parallel control components), there is no point in trying to start them with a behaviour (PCC -s are also control components).

5)
"The restriction that in every configuration there shall be one (and only one) MTC is amended to that in every test case configuration shall be exactly one MTC"

This is a strange sentence.
If there is only one MTC, than that is the only one MTC in every test case configuration.

6)
"Control hehaviour has no way of referencing components created for an executed test case"

A control behaviour can be any function called by control directly or indirectly.
The exact same function could also be called by a testcase directly or indirectly.
This might cause confusion in users, regarding what exactly for example any component will mean, loking at only the code of the function.
(0015847)
Kristóf Szabados (reporter)
11-12-2020 10:30

7)
"The component operations create, start, call, stop, kill, running, alive, done, killed shall be allowed to be used also in control behaviour with the same semantics and the same restrictions as for test components inside test behaviour "

Can PCC -s be alive?
And this way, transfer information from 1 test case to the next?

8)
"The semantics of alt statements and interleave statements as well as the activate and deactivate operations are the same as for test case behaviour"

I would believe they should rather work like any component and all component, in the sense that each test case behaiour and each PCC should have their own distinct set of activated defaults ... otherwise there can be sideeffects between the tests.

9)
"As for the MCC, the execute operation inside PCC behaviour will block until either the executed test case has terminated or the given timeout has occurred and test execution has been stopped"

This sounds strange.
Like ... lets talk about the MCC! <switching topic> the PCC behaves like this and that.

There was also no mention of the MCC being a PCC so far.
(0015848)
Jacob Wieland - Spirent (reporter)
11-12-2020 11:59

Addressed the issues as discussed in the meeting. please check.
(0015849)
Tomas Urban (developer)
11-12-2020 12:34

The proposal is mostly fine, but I made three changes in the final draft:

1. Added the following sentence to address Kristof's points 0000004 and 0000005:
PCCs are allowed to execute test cases independently and in parallel with test cases being executed on other PCCs and the MCC.

2. Changed the expression "test case behaviour" to "behaviour executed on a test component" to address Kristof's point 0000008

3. Replaced TTCN-3 upper case letter with lower case in TTCN-3 operations listed in the table 2.

All these changes were discussed with Jacob who approved them.

With these small updates, the proposal is ready to be included in the next version of the specification.
(0015891)
Gyorgy Rethy (reporter)
18-12-2020 14:36

Implemented in draft 1.7.2

- Issue History
Date Modified Username Field Change
13-08-2020 15:00 Jacob Wieland - Spirent New Issue
13-08-2020 15:00 Jacob Wieland - Spirent Status new => assigned
13-08-2020 15:00 Jacob Wieland - Spirent Assigned To => Jacob Wieland - Spirent
13-08-2020 15:01 Jacob Wieland - Spirent Relationship added related to 0007910
05-10-2020 12:42 Jacob Wieland - Spirent Note Added: 0015757
05-10-2020 13:26 Jacob Wieland - Spirent File Added: CR7978.docx
05-10-2020 13:27 Jacob Wieland - Spirent Note Added: 0015758
05-10-2020 13:27 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
05-10-2020 13:27 Jacob Wieland - Spirent Status assigned => confirmed
06-10-2020 13:26 Jens Grabowski Assigned To Tomas Urban => Jacob Wieland - Spirent
06-10-2020 13:26 Jens Grabowski Status confirmed => assigned
08-10-2020 15:40 Jacob Wieland - Spirent File Added: CR7978-2.docx
08-10-2020 15:41 Jacob Wieland - Spirent Note Added: 0015782
08-10-2020 15:41 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
08-10-2020 15:41 Jacob Wieland - Spirent Status assigned => confirmed
09-10-2020 08:28 Tomas Urban Assigned To Tomas Urban => Jacob Wieland - Spirent
09-10-2020 08:28 Tomas Urban Status confirmed => assigned
09-10-2020 08:35 Tomas Urban Note Added: 0015788
09-10-2020 15:14 Jacob Wieland - Spirent Project Part 06: TTCN-3 Control Interface => Ext Pack: Config & Deployment Support (ES 202 781)
07-12-2020 14:45 Jacob Wieland - Spirent File Added: CR7978-3.docx
07-12-2020 14:52 Jacob Wieland - Spirent File Deleted: CR7978-3.docx
07-12-2020 14:53 Jacob Wieland - Spirent File Added: CR7978-3.docx
07-12-2020 14:55 Jacob Wieland - Spirent Note Added: 0015800
07-12-2020 14:55 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
07-12-2020 14:55 Jacob Wieland - Spirent Status assigned => confirmed
08-12-2020 13:08 Tomas Urban File Added: CR7978-4.docx
08-12-2020 13:12 Tomas Urban Note Added: 0015812
08-12-2020 13:12 Tomas Urban Assigned To Tomas Urban => Kristóf Szabados
09-12-2020 21:23 Kristóf Szabados Note Added: 0015830
09-12-2020 21:40 Kristóf Szabados Note Added: 0015831
09-12-2020 21:41 Kristóf Szabados Assigned To Kristóf Szabados => Jacob Wieland - Spirent
09-12-2020 21:41 Kristóf Szabados Status confirmed => assigned
10-12-2020 08:02 Tomas Urban Note Added: 0015834
10-12-2020 13:19 Jacob Wieland - Spirent File Added: CR7978-5.docx
10-12-2020 13:21 Jacob Wieland - Spirent Note Added: 0015840
10-12-2020 13:21 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Kristof.Szabados
10-12-2020 13:21 Jacob Wieland - Spirent Status assigned => confirmed
10-12-2020 13:52 Kristóf Szabados Assigned To Kristof.Szabados => Kristóf Szabados
10-12-2020 13:52 Kristóf Szabados Status confirmed => assigned
10-12-2020 14:13 Jacob Wieland - Spirent Status assigned => confirmed
11-12-2020 10:29 Kristóf Szabados Note Added: 0015845
11-12-2020 10:29 Kristóf Szabados Note Added: 0015846
11-12-2020 10:30 Kristóf Szabados Note Added: 0015847
11-12-2020 10:30 Kristóf Szabados Assigned To Kristóf Szabados => Jacob Wieland - Spirent
11-12-2020 10:30 Kristóf Szabados Status confirmed => assigned
11-12-2020 11:58 Jacob Wieland - Spirent File Added: CR7978-6.docx
11-12-2020 11:59 Jacob Wieland - Spirent Note Added: 0015848
11-12-2020 11:59 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Tomas Urban
11-12-2020 11:59 Jacob Wieland - Spirent Status assigned => confirmed
11-12-2020 12:27 Tomas Urban File Added: CR7978-7.docx
11-12-2020 12:34 Tomas Urban Note Added: 0015849
11-12-2020 12:34 Tomas Urban Status confirmed => resolved
11-12-2020 12:34 Tomas Urban Resolution open => fixed
11-12-2020 12:34 Tomas Urban Assigned To Tomas Urban => Gyorgy Rethy
18-12-2020 14:36 Gyorgy Rethy Note Added: 0015891
18-12-2020 14:36 Gyorgy Rethy Status resolved => closed
18-12-2020 14:36 Gyorgy Rethy Product Version Next version (to be defined) => v1.7.1 (published 2019-04)
18-12-2020 14:36 Gyorgy Rethy Fixed in Version => v1.8.1 (ongoing)
18-12-2020 14:36 Gyorgy Rethy Target Version Next version (to be defined) => v1.8.1 (ongoing)


MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker