ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0000354 | Part 01: TTCN-3 Core Language | New Feature | public | 22-11-2006 13:55 | 12-12-2008 11:57

Reporter | Stephan Schulz |
Assigned To |  |
Priority | low | Severity | feature | Reproducibility | always
Status | closed | Resolution | suspended |
Platform |  | OS |  | OS Version |
Product Version | v2.2.1 (published 2003-02) |
Target Version | v3.1.1 (published 2005-06) | Fixed in Version |  |
Clause Reference(s) | 6, 6.3.4, 14.2.2, 18, 19.3, 22.1, 22.4, 24, 25.1, 25.2, 27.1, A.1.5, A.1.6
Source (company - Author) | Helmut Neukirchen, Institute for Telematics, University of Luebeck

Summary | 0000354: TimedTTCN-3

Description

This CR is intended to make TTCN-3 applicable to the (hard) real-time domain.
Since the snapshot semantics was not designed for real-time testing and even timers cannot be used for real-time requirements which are distributed between several test components, current TTCN-3 cannot be applied for specifying real-time test cases.
A TTCN-3 real-time extension has been developed in the context of the European research project INTERVAL. This change request reflects these extension which solve the described problems of using TTCN-3 for real-time.
The proposed extension is based on the introduction of clocks which are local to test components, on a formalised logfile handling and on the notion of a testrun.

Steps To Reproduce |

Additional Information

This document describes the changes which are needed in order to extend the TTCN-3 Core Language by the concepts needed for specifing real-time tests. The changes have to be applied to the ETSI Standard ES 201 873 1 V2.2.0 (2002-03).
1. Clause 6 (ï¿½Types and Valuesï¿½): Add to Table 3 two rows on ï¿½Special testrun typesï¿½:
with entries ï¿½testrunï¿½ and ï¿½logfileï¿½.
Furthermore, add:
ï¿½The special testrun types testrun and logfile can be used to refer to the outcome of a test execution (see clause reference to clause on logfile operations and reference to clause on module control part).ï¿½
2. Clause 6.3.4 (ï¿½Enumerated type and valuesï¿½): Add:
ï¿½The identifier timezones is a reserved identifier for defining an enumeration type which can be used to assign symbolic names to different clock synchronisation timezones. The values of the enumeration type timezones can be passed as parameter to the execute and create statement. The self.timezone statement returns a value of type timezones. A value of name none, which represents no clock synchronisation, is implicitly member of the enumeration type timezones.ï¿½
3. Between Clause 14.2.2 (ï¿½Templates for acceptiong procedure invokationsï¿½) and Clause 14.3 (ï¿½Template matching mechanismsï¿½): Add a new clause ï¿½Templates for sorting logfile entriesï¿½:
ï¿½A template used in a .first logfile operation defines a sorting key. The symbol ? defines the field element which is used as sorting key, all other template fields have to set to -. A sorting key shall be of a type which allows relational operators to be applied to.
EXAMPLE:
// timestamp type definition
type record MyTimestampType
{
float field1,
timezones field2,
integer field3
}
// a sorting key template might be
template MyTimestampType MyTemplate:=
{
field1 := ?,
field2 := -,
field3 := -
}
ï¿½
4. Clause 18 (ï¿½Overview of program statements and operationsï¿½): Add to table 11 several rows:
Add section ï¿½Statements for real-time handlingï¿½: ï¿½Wait ; resume ; ; Yesï¿½, ï¿½Read local clock ; self.now ; ; Yesï¿½, ï¿½Get timezone of test component ; self.timezone ; ; Yesï¿½.
In section ï¿½Verdict Operationsï¿½: ï¿½Set testrun verdict ; setverdict ; Yes ; Yes (see note 2)ï¿½, ï¿½Get testrun verdict ; getverdict ; Yes ; Yes (see note 2)ï¿½
Add section ï¿½Logfile operationsï¿½: ï¿½Get logfile of testrun ; getlog ; Yes ; Yes (see note 2)ï¿½, ï¿½Sort logfile and move to first entry ; first ; Yes ; Yes (see note 2)ï¿½, ï¿½Move to next entry ; next ; Yes ; Yes (see note 2)ï¿½, ï¿½Move to previous entry ; previous ; Yes ; Yes (see note 2)ï¿½, ï¿½Retrieve entry at current position; first ; retrieve ; Yes (see note 2)ï¿½
5. Clause 19.3 (ï¿½The Log statementï¿½): Replace clause by:
ï¿½The log statement provides means to write values of arbitrary data types to some local logging device associated with test control or the test component in which the statement is used. For example:
log(ï¿½Line 248 in PTC_Aï¿½);
// The string ï¿½Line 248 in PTC_Aï¿½ is written to some log device of the test system
log(MyTimestampType:{self.now, self.timezone,1});
// A structured value which contains local time, local time zone and the integer 1 is written to some log device of the test system
The logfiles may be subject of further processing (see clause reference to clause on logfile operations).
NOTE: The mechanisms for storing and maintaining logfiles are considered to be implementation specific and are outside the scope of the present document.ï¿½
6. Clause 22.1 (ï¿½The Create operationï¿½): Add:
ï¿½The create operation may be called with an optional parameter of enumerated type timezones. In this case the test implementation has to take care that all test components which are created with the same timezones value (the timezones value of the MTC may be specified as an optional parameter of the execute operation) have synchronised clocks.
NOTE 1: The concrete mechanism for clock synchronisation of test components is tool specific and therefore outside the scope of the present document.
NOTE 2: If clock synchronisation cannot be established, the error verdict will be set.
EXAMPLE:
:
type enumerate timezones {
zone1, zone2, zone3
}
:
var MyComponentType MyNewComponent;
:
MyNewComponent := MyComponentType.create(zone1); // create component in timezone zone1
:
ï¿½
7. After Clause 22.4 (ï¿½The MTC, System and Self operationsï¿½): Add a new clause ï¿½The self.timezone operationï¿½:
ï¿½The timezone of a test component may be retrieved using the self.timezone operation which returns a value of enumerated type timezones. If the self.timezone operation is called within a test component which has no clock synchronisation, the value none is returned.
EXAMPLE:
:
var timezones MyTimezone;
:
MyTimezone := self.timezone; // Retrieve timezone of component
:
ï¿½
8. After Clause 24: Add a new clause ï¿½Real-time operationsï¿½:
ï¿½TTCN-3 supports two operations which operate on the absolute value of a test components local clock.
Subclause The self.now operation
The self.now operation is used to read the absolute value of a test components clock. It is assumed that each test component has its own local clock. Further synchronisation of different test components may be specified by a timezone parameter passed to the execute and create statement (see clause reference to clause on Enumerated type and values, The Create operation and Execution of test cases). The return type of the self.now operation is of type float and represents local time by seconds elapsed since a fixed point in time.
NOTE: The present document does not define a fixed starting point for time measurement, but requires a starting point which is at least older than the point in time when a testrun has been started.
Subclause The resume operation
The resume operation allows a test component to suspend execution and resume at a certain absolute point in time with respect to the test components local clock. This absolute value is passed as a parameter of type float and represents local time as returned by the self.now operation.
EXAMPLE:
:
var float myTime;
:
myTime:=self.now; // Read local clock
resume(myTime+5.0); // Wait for five seconds
:
ï¿½
9. Clause 25.1 (ï¿½Test case verdictï¿½): Replace ï¿½This verdict is not accessible to the getverdict and setverdict operationsï¿½ by ï¿½This verdict is not accessible to the getverdict and setverdict operations within a test component, but by the setverdict and getverdict operations which can be applied in the module control part to a testrun handle for further processing of a global verdict (see clause reference to new clause on testrun handles). ï¿½
Remove sentence ï¿½If the returned verdict is not explicitly saved in the control part (e.g. assigned to a variable) then it is lost.ï¿½
10. Clause 25.2 (ï¿½Verdict values and overwriting rulesï¿½): Replace ï¿½The verdict can have five different values: pass, fail, inconc, none and errorï¿½ by ï¿½The verdict can have six different values: pass, fail, inconc, conf, none and errorï¿½.
Add ï¿½NOTE 2: conf means a verdict which indicates conformance with respect to pure functional behaviour, but a failure with respect to non-functional behaviour.ï¿½
Replace Table 21 (ï¿½Overwriting rules for the verdictï¿½) by:
Current value of verdict New verdict assignment value
pass conf inconc fail none
Pass pass conf inconc fail pass
Conf conf conf inconc fail conf
Inconc inconc inconc inconc fail inconc
Fail fail fail fail fail fail
None pass conf inconc fail none
11. Clause 27.1 (ï¿½Execution of test casesï¿½): Replace ï¿½As the result of the execution of a test case a test verdict of either none, pass, inconclusive, fail or error shall be returned and may be assigned to a variable for further processing.ï¿½ by ï¿½As the result of the execution of a test case, a testrun handle shall be returned and may be used for further evaluation of a testrun (see clause reference to clause on testrun handles).ï¿½
Add:
ï¿½A further, optional parameter of enumerated type timezones allows to specify a synchronisation timezone for the local clock of the main test component.
If a timezone parameter is passed to the execute statement, the test implementation has to take care that all parallel test components which are created with the same timezone value as the main test component have synchronised clocks.
NOTE: The concrete mechanism for clock synchronisation of test components is tool specific and therefore outside the scope of the present document.ï¿½
Replace example by:
ï¿½execute(MyTestcase1()); // executes MyTestCase1, without storing the returned testrun handle and without time supervision nor clock synchronisation timezone
MyTestrunHandle := execute(MyTestCase2()); // executes MyTestCase2 and stores the returned testrun handle in variable MyTestrunHandle.
MyTestrunHandle := execute(MyTestCase3(),5E-3); // executes MyTestCase3 and stores the returned testrun handle in variable MyTestrunHandle. If the test case does not terminate within 5ms, MyVerdict will get the value ï¿½errorï¿½.
MyTestrunHandle := execute(MyTestCase4(),zone1); // executes MyTestCase3 and stores the returned testrun handle in variable MyTestrunHandle. The clock synchronisation timezone of the MTC is set to value ï¿½zone1ï¿½.
MyTestrunHandle := execute(MyTestCase5(),5E-3,zone1); // executes MyTestCase3 and stores the returned testrun handle in variable MyTestrunHandle. The clock synchronisation timezone of the MTC is set to value ï¿½zon1ï¿½. If the test case does not terminate within 5ms, MyVerdict will get the value ï¿½errorï¿½.
ï¿½
12. After Clause 27.1: Add clause ï¿½Testrun handleï¿½:
ï¿½The value which shall be returned by the execute statement shall be of type testrun. Values of this type may be used to handle the outcome of a testrun, e.g. pass it to a function for further evaluation of a testrun. Three operations which may be applied to a testrun handle are defined:
Testrun operation
Statement Associated keyword
Get logfile getlog
Get global verdict getverdict
Set global verdict setverdict
The getlog operations retrieves the global logfile of type logfile which is build when test execution finishes, i.e. the main test component terminates. The global logfile is merged from the local logfiles which are associated to test control or the test (see clause reference to clause on logfile operations).
NOTE: The order in which entries of the local logfiles are initially merged is tool specific and therefore outside the scope of the present document. An ordering of entries of a particular type may be explicitly requested by applying the first operation to a logfile variable.ï¿½
The global verdict which is calculated when each test component finishes execution may be accessed by the getverdict and setverdict operations which may be applied to a variable of type testrun.
EXAMPLE:
control {
var testrun myTestrun; // Variable for testrun handling
var logfile myLog; // Variable for testlog handling
var verdicttype myVerdict // Variable for verdict handling
myTestrun := execute(MyTestCase()); // Execute testcase
myVerdict := myTestrun.getverdict; // Retrieval of testrun verdict
myLog := myTestrun.getlog; // Retrieval of testrun log
:
myTestrun.setverdict(fail); // Change of testrun verdict
}
ï¿½
13. After Clause 27: Add new clause ï¿½Logfile operationsï¿½:
ï¿½Five operations are defined for processing the logfiles which are created by test control and test components.
Logfile operation
Statement Associated keyword
Get logfile of a testrun testrunhandle.getlog
Get logfile of test control or test component self.getlog
Select entries from logfile, sort them and move cursor to first matching entry first
Move cursor to the next matching entry next
Move cursor to the previous matching entry previous
Retrieve entry from the current logfile cursor position retrieve
A test component or test control may call self.getlog operation to get its own logfile which is of type logfile.
When test execution finishes, i.e. the main test component terminates, the local logfiles are merged into a global logfile of type logfile, which may be retrieved from within test control by applying the getlog operation to a testrun handle (see clause reference to clause Testrun handle).
Further postprocessing of logfiles has to be initiated by applying the first operation on variables of type logfile. A search template shall be used as the first parameter of operation first to select entries from the logfiles by their type and to sort them. The type of the search template is used to select entries which are regarded by further next, previous and retrieve operations. The second parameter is used to move an internal cursor in the logfile to the first entry that matches this parameter. Templates may be used to avoid to restrictive search patterns. If no matching entry is found, the cursor position is undefined and operation first returns value false, otherwise value true.
The operations next and previous may be applied to a logfile in order to move the logfiles cursor to the next or previous respectively entry which matches the search pattern which is given as parameter. If no matching entry is found, the cursor position remains unchanged and operation first returns value false, otherwise value true.
If the logfiles cursor is at a defined position, the retrieve operation may be applied to a logfile in order to retrieve the logfile entry at the current cursor position. Otherwise, an undefined value will be returned. The type of the returned value is determined by the type of the search template specified as first parameter of operation first.
NOTE: The mechanisms for storing, maintaining and processing logfiles are considered to be implementation specific and are outside the scope of the present document.
EXAMPLE:
control {
var testrun myTestrun; // Variable for testrun handling
var logfile myLog; // Variable for testlog handling
var MyTimestampType MyTimestamp;
myTestrun := execute(MyTestCase(),Berlin); // Execute testcase
myLog := myTestrun.getlog; // Retrieval of testrun log
if (myLog.first(MyTimestampType:{?,-,-},MyTimestampType{?,Berlin,?})) {
// Select logfile entries of type
// MyTimestampType and sort them
// ascending with respect to the
// first field element. Set cursor to
// the first entry with second field
// element of value Berlin.
if (myLog.next(MyTimestampType:{?,Berlin,?})) {
// Advance cursor to next matching
// entry with second field element of
// value Berlin.
MyTimestamp := myLog.retrieve; // If first and next operation were
// successful, retrieve value at
// cursor position.
:
}
}
}
ï¿½
14. Annex A.1.5 (ï¿½TTCN-3 terminalsï¿½): Add to Table A.3:
ï¿½conf, first, getlog, logfile, next, now, previous, resume, retrieve, testrun, timezone, timezones
ï¿½
15. Annex A.1.6 (ï¿½TTCN-3 syntax BNF productionsï¿½): Change according to the following diffs:
Old 187. TestcaseInstance ::= ExecuteKeyword "(" TestcaseRef "(" [TestcaseActualParList] ")" ["," TimerValue] ")"
New 187. TestcaseInstance ::= ExecuteKeyword "(" TestcaseRef "(" [TestcaseActualParList] ")" ["," TimerValue] ["," Expression] ")" /* STATIC SEMANTICS ï¿½ Expression must evaluate to timezones enumeration type */
Old 272. ControlStatement ::= TimerStatements |
BasicStatements |
BehaviourStatements |
SUTStatements
New 272. ControlStatement ::= TimerStatements |
BasicStatements |
BehaviourStatements |
SUTStatements |
SetGlobalVerdict
Old 288. ConfigurationOps ::= CreateOp | SelfOp | SystemOp | MTCOp | RunningOp
New 288. ConfigurationOps ::= CreateOp | SelfOp | SelfTimezoneOp | SelfNowOp | SelfGetLogOp| SystemOp | MTCOp | RunningOp
Old 289. CreateOp ::= ComponentType Dot CreateKeyword
New 289. CreateOp ::= ComponentType Dot CreateKeyword ["(" Expression] ")" /* STATIC SEMANTICS ï¿½ Expression must evaluate to timezones enumeration type */
New 291b. SelfTimezoneOp ::= "self" Dot "timezone"
New 291c. SelfNowOp ::= "self" Dot "now"
New 291d. SelfGetLogOp ::= "self" Dot "getlog"
Old 408. PredefinedType ::= BitStringKeyword |
BooleanKeyword |
CharStringKeyword |
UniversalCharString |
CharKeyword |
UniversalChar |
IntegerKeyword |
OctetStringKeyword |
ObjectIdentifierKeyword |
HexStringKeyword |
VerdictTypeKeyword |
FloatKeyword |
AddressKeyword |
DefaultKeyword |
AnyTypeKeyword
New 408. PredefinedType ::= BitStringKeyword |
BooleanKeyword |
CharStringKeyword |
UniversalCharString |
CharKeyword |
UniversalChar |
IntegerKeyword |
OctetStringKeyword |
ObjectIdentifierKeyword |
HexStringKeyword |
VerdictTypeKeyword |
FloatKeyword |
AddressKeyword |
DefaultKeyword |
AnyTypeKeyword |
TestrunKeyword |
LogfileKeyword
New 423b. TestrunKeyword ::= "testrun"
New 423c. LogfileKeyword ::= "logfile"
Old 444. VerdictTypeValue ::= "pass" | "fail" | "inconc" | "none" | "error"
New 444. VerdictTypeValue ::= "pass" | "conf" | "fail" | "inconc" | "none" | "error"
Old 445. EnumeratedValue ::= EnumerationIdentifier
New 445. EnumeratedValue ::= EnumerationIdentifier | "none" /* STATIC SEMANTICS ï¿½ implicit value "none" only for enumeration types of name "timezones" */
Old 509. VerdictStatements ::= SetLocalVerdict
Old 509. VerdictStatements ::= SetLocalVerdict | SetGlobalVerdict
New 511b. SetGlobalVerdict ::= TestrunIdentifier Dot SetVerdictKeyword "(" SingleExpression ")"
Old 540. BasicStatements ::= Assignment | LogStatement | LoopConstruct | ConditionalConstruct
New 540. BasicStatements ::= Assignment | LogStatement | LoopConstruct | ConditionalConstruct | ResumeStatement
Old 568. OpCall ::= ConfigurationOps |
VerdictOps |
TimerOps |
TestcaseInstance |
FunctionInstance |
TemplateOps |
ActivateOp
New 568. OpCall ::= ConfigurationOps |
VerdictOps |
TimerOps |
TestcaseInstance |
FunctionInstance |
TemplateOps |
ActivateOp |
TestlogOp |
TestrunOp
Old 577. LogStatement ::= LogKeyword "(" [FreeText] ")"
New 577. LogStatement ::= LogKeyword "(" [TemplateInstance] ")"
New 578b. ResumeStatement ::= ResumeKeyword "(" Expression ")" /* STATIC SEMANTICS: expression must resolve to value of type float */
New 578b. ResumeKeyword ::= "resume"
New heading: A.1.5.2.6 Testrun and Testlog Operations
New 406b. TestlogOps ::= FirstOp | NextOp | PreviousOp | RetrieveOp
New 406c. FirstOp ::= TestlogIdentifier Dot FirstKeyword "(" TemplateInstance "," TemplateInstance ")"
New 406d. FirstKeyword ::= "first"
New 406e. NextOp ::= TestlogIdentifier Dot NextKeyword "(" TemplateInstance ")"
New 406f. NextKeyword ::= "next"
New 406g. PreviousOp ::= TestlogIdentifier Dot PreviousKeyword "(" TemplateInstance ")"
New 406h. PreviousKeyword ::= "previous"
New 406i. RetrieveOp ::= TestlogIdentifier Dot RetrieveKeyword
New 406j. RetrieveKeyword ::= "retrieve"
New 406k. TestlogIdentifier ::= FunctionInstance | VariableRef
New 406l. TestrunOps ::= GetlogOp | GetGlobalVerdictOp
New 406m. GetlogOp ::= TestrunIdentifier Dot GetlogKeyword /* STATIC SEMANTICS: may only be applied in module control part */
New 406n. GetlogKeyword ::= "getlog"
New 406o. GetGlobalVerdictOp ::= TestrunIdentifier Dot GetverdictKeyword /* STATIC SEMANTICS: may only be applied in module control part */
New 406p. TestrunIdentifier ::= FunctionInstance | VariableRef

Tags | No tags attached.

Relationships

related to | 0000355 | closed |  | TimedGFT
related to | 0004483 | closed | Jens Grabowski | New Concepts to Test Real Time Properties

Attached Files |

Issue History
Date Modified | Username | Field | Change
22-11-2006 13:55 | Stephan Schulz | New Issue |
22-11-2006 13:55 | Stephan Schulz | Clause Reference(s) | => 6, 6.3.4, 14.2.2, 18, 19.3, 22.1, 22.4, 24, 25.1, 25.2, 27.1, A.1.5, A.1.6
22-11-2006 13:55 | Stephan Schulz | Source (company - Author) | => Helmut Neukirchen, Institute for Telematics, University of Luebeck
22-11-2006 13:55 | Stephan Schulz | Note Added: 0000283 |
22-11-2006 13:58 | Stephan Schulz | Status | new => closed
22-11-2006 13:58 | Stephan Schulz | Note Added: 0000284 |
22-11-2006 13:58 | Stephan Schulz | Resolution | open => suspended
22-11-2006 13:58 | Stephan Schulz | Fixed in Version | => Edition 3.1.1
24-11-2006 13:38 | Stephan Schulz | Relationship added | related to 0000355
12-12-2008 11:57 | Ina Schieferdecker | Product Version | => Edition 2.2.1
12-12-2008 11:57 | Ina Schieferdecker | Fixed in Version | Edition 3.1.1 =>
12-12-2008 11:57 | Ina Schieferdecker | Target Version | => Edition 3.1.1
12-12-2008 11:57 | Ina Schieferdecker | Additional Information Updated |
12-12-2008 12:06 | Ina Schieferdecker | Relationship added | related to 0004483

Notes

(0000283)
Stephan Schulz
22-11-2006 13:55

The usage of this extension was presented as a paper at Testcom 2002. This paper contains a complete example and shows the interworking of the individual extensions provided in this change request. Thus it is recommonded to read this paper. It can be downloaded via: http://www.itm.mu-luebeck.de/pubs/single_pub/index.php?lang=en&pub_nr=183 [^]

(0000284)
Stephan Schulz
22-11-2006 13:58

Will be addressed in the continuation project for STF213