diff --git a/titan_executor_api/.gitignore b/titan_executor_api/.gitignore
index 0787962ceb0afacbef34580d3e56ba6ef9e91047..3537d7d6b8cbce93afc64866165536d9de6be2b3 100644
--- a/titan_executor_api/.gitignore
+++ b/titan_executor_api/.gitignore
@@ -7,4 +7,5 @@
 /TITAN_Executor_API/nbbuild/
 /TITAN_Executor_API/dist/
 /TITAN_Executor_API_Demo/dist/
-/TITAN_Executor_API_test/build/
\ No newline at end of file
+/TITAN_Executor_API_test/build/
+
diff --git a/titan_executor_api/doc/Titan_Executor_API_User_Guide.adoc b/titan_executor_api/doc/Titan_Executor_API_User_Guide.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..8a9addcfe86b6c500c77b447d5b67f8797b54274
--- /dev/null
+++ b/titan_executor_api/doc/Titan_Executor_API_User_Guide.adoc
@@ -0,0 +1,81 @@
+---
+Author: Arpad Lovassy
+Version: 8/198 17-CRL 113 200/6, Rev. PE1
+Date: 2018-06-19
+
+---
+= Titan Executor API User Guide
+:author: Arpad Lovassy
+:revnumber: 8/198 17-CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-19
+:title-logo-image: images/titan_logo.png
+:toc:
+
+ifdef::env-github,backend-html5[]
+image::images/titan_logo.png[alt]
+endif::[]
+
+*Abstract*
+
+This document describes detailed information of using the TITAN Executor API.
+
+*Copyright*
+
+Copyright (c) 2000-2018 Ericsson Telecom AB +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution and is available at +
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html.
+
+*Disclaimer*
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
+
+= Overview
+
+The Titan Executor API provides the following functionalities:
+
+* execution control as in mctr_gui
+* callback for host controller connecting events
+* console log callback
+
+It is implemented in Java using JNI calls to the C++ side, which is based on the implementation of titan_eclipse JNI executor. The Titan Executor API is independent from Eclipse.
+
+= Titan Executor API
+
+== Prerequisites
+
+* TITAN installed (_libmctrjninative.so_ library file is in _TTCN3_DIR/lib_, and library path is in `LD_LIBRARY_PATH`)
+* Java JRE 1.7 installed
+
+== Install
+
+Copy _lib/TITAN_Executor_API.jar_ to your classpath.
+
+== Usage
+
+The entry point of the API is the `com.ericsson.titan.executor.api.JniExecutor`, and the client must implement `com.ericsson.titan.executor.api.IJniExecutorObserver` interface for the callbacks.
+
+For further details see the Javadoc embedded in the project.
+
+= Titan Executor API Demo
+
+== Install
+
+Copy _TITAN_Executor_API_Demo.jar_ and _lib/TITAN_Executor_API.jar_ to any selected directory, so keep the directory structure, make sure, that _TITAN_Executor_API.jar_ is in _lib/_, so it means, that Titan Executor API is in the classpath, which is defined in the manifest file of _TITAN_Executor_API_Demo.jar_.
+
+== Usage
+
+To start the demo the following command must be used:
+
+[source]
+java -jar <install directory>/TITAN_Executor_API_Demo.jar
+
+= Javadoc
+
+== Install
+
+Extract javadoc directory from the zip file
+
+== Usage
+
+Open _javadoc/index.html_ from a browser.
+
diff --git a/titan_executor_api/doc/Titan_Executor_API_User_Guide.doc b/titan_executor_api/doc/Titan_Executor_API_User_Guide.doc
deleted file mode 100644
index 0aaa68b5538dbe82c6af1e0fd89d71381f2d42ea..0000000000000000000000000000000000000000
Binary files a/titan_executor_api/doc/Titan_Executor_API_User_Guide.doc and /dev/null differ
diff --git a/titan_executor_api/doc/images/titan_logo.png b/titan_executor_api/doc/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..5c759d7ea667f54880d77e2ede10c775f73d037d
Binary files /dev/null and b/titan_executor_api/doc/images/titan_logo.png differ
diff --git a/usrguide/PRI.docx b/usrguide/PRI.docx
deleted file mode 100644
index 98de6d5afb03627d45a90131bf4935a11da2d0b9..0000000000000000000000000000000000000000
Binary files a/usrguide/PRI.docx and /dev/null differ
diff --git a/usrguide/PRI/PRI.adoc b/usrguide/PRI/PRI.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..231730d68ea53e4cc08ff07a8ffa154f755775f7
--- /dev/null
+++ b/usrguide/PRI/PRI.adoc
@@ -0,0 +1,86 @@
+---
+Author: Jenő Balaskó
+Version: 109 21-CRL 113 200/6-4, Rev. A
+Date: 2018-05-16
+
+---
+= Product Revision Information for TITAN
+:author: Jenő Balaskó
+:revnumber: 109 21-CRL 113 200/6-4, Rev. A
+:revdate: 2018-05-16
+:toc:
+
+= Product Revision
+
+== Product
+
+[cols=",,,",options="header",]
+|===
+|Product number |Old Rev |New Rev |Function designation
+|CRL 113 200/6 |R3B |R4A |TTCN-3 Executor
+|===
+
+This release is done to deliver updated and improved TTCN related products to all customers within and outside Ericsson.
+
+== Subordinate product release
+
+Legend: R = Revised, N = New, C = Cancelled, E = Equal
+
+[cols=",,,,",options="header",]
+|===
+|Name |Product |Old R-State |New R-State |Status
+|*Titan* |*CRL 113 200/6* |*R3B* |*R4A* |N
+|Editline Library (libedit) |2/CAX 105 4373 | |R1A |E
+|GNU C Library (glibc) |7/CAX 105 3195 | |R1A |E
+|LibXML2 |8/CAX 105 3282 | |R1A |E
+|OpenSSL |4/CAX 105 3048 | |R1A |E
+|Cygwin |1/CAX 105 3757 | |R1A |E
+|===
+
+== Affected documents
+
+Important note: *The documents are available via the hyperlinks.*
+
+Legend: R = Revised, N = New, C = Cancelled, E = Equal
+
+[width="100%",cols="25%,25%,25%,25%",options="header",]
+|===
+|Name |Old Revision |New Revision |
+|link:https://github.com/eclipse/titan.core/blob/master/usrguide/releasenotes.adoc[Release Notes for TITAN TTCN-3 Test Executor 109 47-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.core/blob/master/usrguide/installationguide.adoc[Installation guide for TITAN TTCN-3 Test Executor 1/1531-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.EclipsePlug-ins/blob/master/Eclipse_installationguide.adoc[Installation Guide for TITAN Designer and TITAN Executor for the Eclipse IDE 3/1531-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.core/blob/master/usrguide/userguide/README.adoc[User Guide for TITAN 1/198 17-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.core/blob/master/usrguide/referenceguide/README.adoc[Programmers Technical Reference for TITAN TTCN-3 Test Executor 2/198 17-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.EclipsePlug-ins/blob/master/Eclipse_Designer_userguide/README.doc[User Guide for the TITAN Designer for the Eclipse IDE 4/198 17-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.EclipsePlug-ins/blob/master/Eclipse_Executor_userguide/README.doc[User Guide for the TITAN Executor for the Eclipse IDE 5/198 17-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.core/blob/master/usrguide/apiguide/README.doc[API Technical Reference for TITAN TTCN-3 Test Executor 6/198 17-CRL 113 200/6] |B |Cloud stored |R
+|link:https://github.com/eclipse/titan.core/blob/master/titan_executor_api/doc/Titan_Executor_API_User_Guide.doc[Titan Executor Java API user guide 8/198 17-CRL 113 200/6] |B |Cloud stored |R
+|Programmers Tech. Reference Guide for Titanium |B |Cloud stored |R
+|Titanium Description |B |Cloud stored |R
+|Statement of Compliance for Eclipse Titan |B |Cloud stored |R
+|Statement of Compliance for use of XML schema in Eclipse Titan |B |Cloud stored |R
+|===
+
+= Reason for revision
+
+== Implementations Proposals
+
+See embedded document for details.
+
+== Change Requests
+
+See embedded document for details.
+
+== Exemption Requests
+
+== Trouble Reports
+
+=== Implemented Trouble Reports
+
+See embedded document for details.
+
+=== Not Implemented Trouble Reports
+
+=== Embedded slide with details
+
+
diff --git a/usrguide/SoC_TITAN.docx b/usrguide/SoC_TITAN.docx
deleted file mode 100644
index b9a5be93bb147c2bf357f102f6dca0bddb5e2728..0000000000000000000000000000000000000000
Binary files a/usrguide/SoC_TITAN.docx and /dev/null differ
diff --git a/usrguide/SoC_TITAN/SoC_TITAN.adoc b/usrguide/SoC_TITAN/SoC_TITAN.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..0ce3be8b302cb81a67131534531480a52ee4eeef
--- /dev/null
+++ b/usrguide/SoC_TITAN/SoC_TITAN.adoc
@@ -0,0 +1,5419 @@
+---
+Author: Adrien Kirjak
+Version: 1/174 02- CRL 113 200/6, Rev. PE1
+Date: 2018-06-18
+
+---
+= Statement of compliance for Eclipse Titan
+:author: Adrien Kirjak
+:revnumber: 1/174 02- CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-18
+:title-logo-image: images/titan_logo.png
+:toc:
+
+ifdef::env-github,backend-html5[]
+image::images/titan_logo.png[alt]
+endif::[]
+
+*Abstract*
+
+The present document provides the Implementation Conformance Statement (ICS) proforma for the conformance test suite for the Eclipse Titan TTCN-3 implementation.
+
+*Copyright*
+
+Copyright (c) 2000-2018 Ericsson Telecom AB +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution, and is available at +
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
+
+*Disclaimer*
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
+
+= Description
+
+The present document provides the Implementation Conformance Statement (ICS) proforma for the conformance test suite for the Eclipse Titan TTCN-3 implementation as defined in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf[ES 201 873-1] in compliance with the relevant guidance given in the proforma for TTCN-3 reference test suite link:https://www.etsi.org/deliver/etsi_ts/102900_102999/102995/01.01.01_60/ts_102995v010101p.pdf[TS 102 995]. In the present document only the core language features, specified in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf[ES 201 873 1] have been considered but not the tool implementation (see link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187305/04.08.01_60/es_20187305v040801p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)] and link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187306/04.03.01_60/es_20187306v040301p.pdf[ETSI ES 201 873-6: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI).]), language mapping (see link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.03.01_60/es_20187307v040301p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 7: Using ASN.1 with TTCN-3], link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187308/04.05.01_60/es_20187308v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 8: The IDL to TTCN-3 Mapping] and link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.08.01_60/es_20187309v040801p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3]) and language extension (see e.g. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.05.01_60/es_202781v010501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support.] , link:https://www.etsi.org/deliver/etsi_es/202700_202799/202784/01.06.01_60/es_202784v010601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Advanced Parameterization] and link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.05.01_60/es_202785v010501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Behaviour Types]) aspects.
+
+= References
+
+== Normative references
+
+The following referenced documents are necessary for the application of the present document.
+
+1.	link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf[ETSI ES 201 873-1: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language v4.7.1.]
+
+2. [[_2]]ISO/IEC 9646-7 (1994): Conformance testing methodology and framework -
+Part 7: Implementation Conformance Statement.
+
+3. [[_3]]ISO/IEC 9646-1 (1992): Information Technology - Open Systems Interconnection - Conformance Testing Methodology and Framework - Part 1: General concepts.
+
+4.	link:https://www.etsi.org/deliver/etsi_ts/102900_102999/102995/01.01.01_60/ts_102995v010101p.pdf[ETSI TS 102 995: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Proforma for TTCN-3 reference test suite]
+
+
+== Informative references
+
+The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
+[start=5]
+5. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187305/04.08.01_60/es_20187305v040801p.pdf[ETSI ES 201 873-5: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI).]
+
+6. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187306/04.03.01_60/es_20187306v040301p.pdf[ETSI ES 201 873-6: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI).]
+
+7. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.03.01_60/es_20187307v040301p.pdf[ETSI ES 201 873-7: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 7: Using ASN.1 with TTCN-3.]
+
+8. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187308/04.05.01_60/es_20187308v040501p.pdf[ETSI ES 201 873-8: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 8: The IDL to TTCN-3 Mapping.]
+
+9. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.08.01_60/es_20187309v040801p.pdf[ETSI ES 201 873-9: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3.]
+
+10. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.05.01_60/es_202781v010501p.pdf[ETSI ES 202 781: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support.]
+
+11. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202784/01.06.01_60/es_202784v010601p.pdf[ETSI ES 202 784: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Advanced Parameterization.]
+
+12.	link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.05.01_60/es_202785v010501p.pdf[ETSI ES 202 785: Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Behaviour Types.]
+
+= Definitions and abbreviations
+
+== Definitions
+
+*Abstract Test Suite (ATS):* +
+Test suite composed of abstract test cases
+
+*Implementation Conformance Statement (ICS):* +
+Statement made by the supplier of an implementation claimed to conform to a given specification, stating which capabilities have been implemented
+
+*ICS proforma:* +
+Document, in the form of a questionnaire, which when completed for an implementation or system becomes an ICS
+
+*Implementation eXtra Information for Testing (IXIT):* +
+Statement made by a supplier or implementor of an IUT which contains or references all of the information related to the IUT and its testing environment, which will enable the test laboratory to run an appropriate test suite against the IUT
+
+*IXIT proforma:* +
+Document, in the form of a questionnaire, which when completed for the IUT becomes the IXIT
+
+*Implementation Under Test (IUT):* +
+Implementation of one or more OSI protocols in an adjacent user/provider relationship, being part of a real open system which is to be studied by testing
+
+== Abbreviations
+
+ATS:: Abstract Test Suite
+
+BNF:: Backus Naur Form
+
+ICS:: Implementation Conformance Statement
+
+IUT:: Implementation under Test
+
+IXIT:: Implementation eXtra Information for Testing
+
+SUT:: System Under Test
+
+TC:: Test Case
+
+TCI:: TTCN-3 Control Interface
+
+TP:: Test Purpose
+
+TRI:: TTCN-3 Runtime Interface
+
+TS:: Test System
+
+TSS:: Test Suite Structure
+
+TSS&TP:: Test Suite Structure and Test Purposes
+
+TTCN-3:: Testing and Test Control Notation edition 3
+
+= Instructions for completing the ICS proforma
+
+== Other information
+
+More detailed instructions are given at the beginning of the different clauses of the ICS proforma.
+
+The supplier of the implementation shall complete the ICS proforma in each of the spaces provided. If necessary, the supplier may provide additional comments separately in Clause A.4.
+
+=== Purposes and structure
+
+The purpose of this ICS proforma is to provide a mechanism whereby a TTCN-3 tool vendor of the link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf[TTCN-3 core language] may provide information about the implementation in a standardized manner.
+
+The ICS proforma is subdivided into clauses for the following categories of information:
+
+* instructions for completing the ICS proforma;
+* identification of the implementation;
+* ICS proforma tables (containing the global statement of conformance).
+
+=== Conventions
+
+The ICS proforma is composed of information in tabular form in accordance with the guidelines presented in <<_2,ISO/IEC 96467>> .
+
+* Item column
+
+It contains a number that identifies the item in the table.
+
+* Item description column
+
+It describes each respective item (e.g. parameters, timers, etc.).
+
+* Reference column
+
+It gives reference to the  link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf[TTCN-3 core language], except where explicitly stated otherwise.
+
+* Status column
+
+The following notations, defined in <<_2,ISO/IEC 96467>> , are used for the status column:
+
+m:: mandatory - the capability is required to be supported.
+
+n/a:: not applicable - in the given context, it is impossible to use the capability. No answer in the support column is required.
+
+u:: undecided
+
+o:: optional - the capability may be supported or not.
+
+o.i:: qualified optional - for mutually exclusive or selectable options from a set. `i` is an integer which identifies a unique group of related optional items and the logic of their selection which is defined immediately following the table.
+
+ci:: conditional - the requirement on the capability ("m", "o" or "n/a")  depends on the support of other optional or conditional items. `i` is an integer identifying a unique conditional status expression that is defined immediately following the table. For nested conditional expressions, the syntax `IF … THEN (IF … THEN … ELSE…) ELSE …` shall be used to avoid ambiguities. If an `ELSE` clause is omitted, `ELSE n/a` shall be implied.
+
+NOTE: Support of a capability means that the capability is implemented in conformance to the link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf[TTCN-3 core language].
+
+* Support column
+
+The support column shall be filled in by the supplier of the implementation. The following common notations, defined in ISO/IEC 96467 <<_2,[2]>>, are used for the support column:
+
+Y or y supported by the implementation.
+
+N or n not supported by the implementation.
+
+N/A or n/a or "no answer required" (allowed only if the status is N/A, directly or after evaluation of a conditional status).
+
+* Values allowed column
+
+This column contains the values or the ranges of values allowed.
+
+* Values supported column
+
+The support column shall be filled in by the supplier of the implementation. In this column the values or the ranges of values supported by the implementation shall be indicated.
+
+* References to items
+
+For each possible item answer (answer in the support column) within the ICS proforma, a unique reference exists. It is defined as the table identifier, followed by a slash character "/", followed by the item number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters (a, b, etc.) respectively.
+
+EXAMPLE: 5/4 is the reference to the answer of item 4 in Table 5.
+
+== Identification of the implementation
+
+Identification of the Implementation under Test (IUT) and the system in which it resides - the System Under Test (SUT) should be filled in so as to provide as much detail as possible regarding version numbers and configuration options.
+
+The product supplier information and client information should both be filled in if they are different.
+
+A person who can answer queries regarding information supplied in the ICS should be named as the contact person.
+
+=== Date of the statement
+
+[cols=",",options="header",]
+|==================================
+|Date of the statement: |2016.05.09
+|==================================
+
+=== Implementation under Test (IUT) identification
+
+[cols=",",options="header",]
+|===============================
+|IUT name: |Eclipse Titan
+|IUT version: |CRL 113 200/5 R5A
+|===============================
+
+=== ICS contact person
+
+[cols=",",options="header",]
+|==========================================
+|Name: |Elemer Lelik
+|Telephone number: |
+|Facsimile number: |
+|E-mail address: |Elemer.Lelik@ericsson.com
+|Additional information: |
+|==========================================
+
+= ICS proforma tables
+
+== Global statement of conformance
+
+[cols="70%,30%",options="header",]
+|=============================================
+| |(Yes/No)
+|Are all mandatory capabilities implemented? |
+|=============================================
+
+NOTE: Nonsupported mandatory capabilities are to be identified in the ICS, with an explanation of why the implementation is nonconforming.
+
+== Basic language elements
+
+.Basic language elements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_05_TopLevel_001 |When the IUT loads a module containing some definitions before the module declaration then the module is rejected. |Clause 5 |m |y
+|=============================================================================================================================================================
+
+== Identifiers and keywords
+
+.Identifiers and keywords
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0501_Identifier_001 |Cannot pass a charstring value to an integer variable. |Clause 5.1 |m |y
+|2 |NegSyn_0501_Identifier_001 |When the IUT loads a module containing an identifier named with a keyword then the module is rejected. |Clause 5.1 |m |y
+|3 |Syn_0501_Identifier_001 |The IUT handle the identifiers case sensitively. |Clause 5.1 |m |y
+|=======================================================================================================================================================
+
+== Scope rules
+
+.Scope rules
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0502_Scope_001 |The IUT correctly handles definitions of local scope |Clause 5.2 |m |y
+|2 |NegSem_0502_Scope_002 |The IUT correctly handles definitions of local scope |Clause 5.2 |m |y
+|3 |NegSem_0502_Scope_003 |The IUT correctly handles definitions of local scope |Clause 5.2 |m |y
+|4 |Sem_0502_Scope_001 |The IUT handle scope hieararchy of component constants. |Clause 5.2 |m |y
+|5 |Sem_0502_Scope_002 |The IUT handle scope hieararchy with component booleans. |Clause 5.2 |m |y
+|6 |Sem_0502_Scope_003 |The IUT handles scope hierarchy via functions. |Clause 5.2 |m |y
+|7 |Sem_0502_Scope_004 |The IUT correctly handles the scope of definitions made in the module part. |Clause 5.2 |m |y
+|8 |Sem_0502_Scope_008 |The IUT correctly handles definitions of extended component scope |Clause 5.2 |m |y
+|9 |Syn_0502_Scope_001 |The IUT supports all the nine scope units. |Clause 5.2 |m |y
+|====================================================================================================================
+
+== Scope of formal parameters
+
+.Scope of formal parameters
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_050201_Scope_of_parameters_001 |The IUT correctly handles scope of formal function parameters |Clause 5.2.1 |m |y
+|2 |Sem_050201_Scope_of_parameters_002 |The IUT correctly handles scope of formal function parameters |Clause 5.2.1 |m |y
+|========================================================================================================================
+
+== Uniqueness of identifiers
+
+.Uniqueness of identifiers
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_050202_Uniqueness_001 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|2 |NegSem_050202_Uniqueness_004 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|3 |NegSem_050202_Uniqueness_005 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|4 |NegSem_050202_Uniqueness_006 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|5 |NegSem_050202_Uniqueness_007 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|6 |NegSem_050202_Uniqueness_008 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|7 |NegSem_050202_Uniqueness_009 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|8 |NegSem_050202_Uniqueness_010 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|9 |NegSem_050202_Uniqueness_011 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |n
+|10 |NegSem_050202_Uniqueness_012 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |n
+|11 |Sem_050202_Uniqueness_001 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|12 |Sem_050202_Uniqueness_002 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|13 |Sem_050202_Uniqueness_003 |The IUT correctly handles the uniqueness of variable names in its scope |Clause 5.2.2 |m |y
+|14 |Sem_050202_Uniqueness_004 |Identifiers for fields of structured types, enumerated values and groups do not have to be globally unique |Clause 5.2.2 |m |y
+|15 |Sem_050202_Uniqueness_005 |Identifiers for fields of structured types, enumerated values and groups do not have to be globally unique |Clause 5.2.2 |m |y
+|=============================================================================================================================================================
+
+== Ordering of language elements
+
+.Ordering of language elements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0503_Ordering_001 |Declarations are in the allowed ordering |Clause 5.3 |m |y
+|2 |NegSem_0503_Ordering_002 |Declarations are in the allowed ordering |Clause 5.3 |m |n
+|3 |NegSem_0503_Ordering_003 |Declarations are in the allowed ordering |Clause 5.3 |m |n
+|4 |Sem_0503_Ordering_001 |Allowed orderings of declarations are supported |Clause 5.3 |m |y
+|5 |Sem_0503_Ordering_002 |Allowed any ordering with component definitions are supported |Clause 5.3 |m |y
+|6 |Sem_0503_Ordering_005 |Allowed orderings of declarations are supported |Clause 5.3 |m |y
+|=========================================================================================================
+
+== Parameterization
+
+.Parameterization
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0504_parametrization_incompatibility_001 |The IUT correctly handles received testcase parametrization type incompatibility. |Clause 5.4 |m |y
+|2 |NegSyn_0504_forbidden_parametrization_001 |The IUT rejects forbidden module parametrization types. |Clause 5.4 |m |n
+|3 |NegSyn_0504_forbidden_parametrization_002 |The IUT rejects forbidden module parametrization types. |Clause 5.4 |m |y
+|=======================================================================================================================================================
+
+== Formal parameters
+
+.Formal parameters
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_050401_top_level_001 |verify that error is generated for incompatible actual value of `in` parameter |Clause 5.4.1 |m |y
+|2 |NegSem_050401_top_level_002 |verify that error is generated for incompatible actual value of `out` parameter |Clause 5.4.1 |m |y
+|3 |NegSem_050401_top_level_003 |verify that error is generated if actual `inout` parameter doesn't adhere to strong typing rules |Clause 5.4.1 |m |n
+|4 |Sem_050401_top_level_001 |verify that `in` parameters can be read within parametrized content |Clause 5.4.1 |m |y
+|5 |Sem_050401_top_level_002 |verify that `out` parameters can be read within parametrized content |Clause 5.4.1 |m |n
+|6 |Sem_050401_top_level_003 |verify that `inout` parameters can be read within parametrized content |Clause 5.4.1 |m |y
+|7 |Sem_050401_top_level_004 |verify that `in` parameters can be set within parametrized content |Clause 5.4.1 |m |y
+|8 |Sem_050401_top_level_005 |verify that `out` parameters can be set within parametrized content |Clause 5.4.1 |m |y
+|9 |Sem_050401_top_level_006 |verify that `inout` parameters can be set within parametrized content |Clause 5.4.1 |m |y
+|10 |Sem_050401_top_level_007 |verify that `in` parameters can be used as actual in parameters of parameterized objects |Clause 5.4.1 |m |y
+|11 |Sem_050401_top_level_008 |verify that `in` parameters can be used as actual out parameters of parameterized objects |Clause 5.4.1 |m |y
+|12 |Sem_050401_top_level_009 |verify that `in` parameters can be used as actual `inout` parameters of parameterized objects |Clause 5.4.1 |m |y
+|13 |Sem_050401_top_level_010 |verify that `out` parameters can be used as actual `in` parameters of parameterized objects |Clause 5.4.1 |m |y
+|14 |Sem_050401_top_level_011 |verify that `out` parameters can be used as actual `out` parameters of parameterized objects |Clause 5.4.1 |m |y
+|15 |Sem_050401_top_level_012 |verify that `out` parameters can be used as actual `inout` parameters of parameterized objects |Clause 5.4.1 |m |y
+|16 |Sem_050401_top_level_013 |verify that `inout` parameters can be used as actual `in` parameters of parameterized objects |Clause 5.4.1 |m |y
+|17 |Sem_050401_top_level_014 |verify that `inout` parameters can be used as actual `out` parameters of parameterized objects |Clause 5.4.1 |m |y
+|18 |Sem_050401_top_level_015 |verify that `inout` parameters can be used as actual `inout` parameters of parameterized objects |Clause 5.4.1 |m |y
+|19 |Sem_050401_top_level_016 |verify that compatibility rules are used for passing `in` parameters |Clause 5.4.1 |m |y
+|20 |Sem_050401_top_level_017 |verify that compatibility rules are used for passing `out` parameters |Clause 5.4.1 |m |y
+|21 |Sem_050401_top_level_018 |verify that strong typing is used for passing `inout` parameters |Clause 5.4.1 |m |y
+|22 |Sem_050401_top_level_019 |verify that `@lazy` modifier can be used for value parameters |Clause 5.4.1 |m |y
+|23 |Sem_050401_top_level_020 |verify that `@lazy` modifier can be used for template parameters |Clause 5.4.1 |m |y
+|24 |Sem_050401_top_level_021 |verify that `@lazy` parameters containing component variable references are properly evaluated |Clause 5.4.1 |m |y
+|25 |Sem_050401_top_level_022 |verify that `@fuzzy` modifier can be used for value parameters |Clause 5.4.1 |m |y
+|26 |Sem_050401_top_level_023 |verify that `@fuzzy` modifier can be used for template parameters |Clause 5.4.1 |m |y
+|27 |Sem_050401_top_level_024 |verify that `@fuzzy` parameters containing component variable references are properly evaluated |Clause 5.4.1 |m |y
+|28 |Sem_050401_top_level_025 |verify that default values of `@lazy` parameters are properly evaluated |Clause 5.4.1 |m |y
+|29 |Sem_050401_top_level_026 |verify that default values of `@fuzzy` parameters are properly evaluated |Clause 5.4.1 |m |n
+|30 |Sem_050401_top_level_027 |verify that passing lazy parameter to formal parameter without modifier disables lazy evaluation |Clause 5.4.1 |m |y
+|31 |Sem_050401_top_level_028 |verify that passing fuzzy parameter to formal parameter without modifier disables fuzzy evaluation |Clause 5.4.1 |m |y
+|32 |Sem_050401_top_level_029 |verify that fuzzy parameter passed to lazy formal parameter enables lazy evaluation |Clause 5.4.1 |m |y
+|====================================================================================================================================================
+
+== Formal parameters of kind value
+
+.Formal parameters of kind value
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_05040101_parameters_of_kind_value_001 |verify that `in` value formal parameters of template cannot used dash as default value |Clause 5.4.1.1 |m |y
+|2 |NegSem_05040101_parameters_of_kind_value_002 |verify that modified template cannot used dash as default value when original value parameter had no default value |Clause 5.4.1.1 |m |y
+|3 |NegSem_05040101_parameters_of_kind_value_003 |verify that template definitions cannot contain `out` value formal parameters |Clause 5.4.1.1 |m |y
+|4 |NegSem_05040101_parameters_of_kind_value_004 |verify that template definitions cannot contain `inout` value formal parameters |Clause 5.4.1.1 |m |y
+|5 |NegSem_05040101_parameters_of_kind_value_005 |verify that `out` value formal parameters cannot have default values |Clause 5.4.1.1 |m |y
+|6 |NegSem_05040101_parameters_of_kind_value_006 |verify that `inout` value formal parameters cannot have default values |Clause 5.4.1.1 |m |y
+|7 |NegSem_05040101_parameters_of_kind_value_007 |verify that incompatible value in default value assignment of value formal parameters causes error |Clause 5.4.1.1 |m |y
+|8 |NegSem_05040101_parameters_of_kind_value_008 |verify that default value of value formal parameters cannot reference component variables |Clause 5.4.1.1 |m |y
+|9 |NegSem_05040101_parameters_of_kind_value_009 |verify that default value of value formal parameters cannot reference other parameters |Clause 5.4.1.1 |m |y
+|10 |NegSem_05040101_parameters_of_kind_value_010 |verify that default value of value formal parameters cannot invoke functions with `runs on` clause |Clause 5.4.1.1 |m |y
+|11 |NegSem_05040101_parameters_of_kind_value_011 |verify that error is generated if formal value parameter of function contains dash |Clause 5.4.1.1 |m |y
+|12 |NegSem_05040101_parameters_of_kind_value_012 |verify that error is generated if formal value parameter of altstep contains dash |Clause 5.4.1.1 |m |y
+|13 |NegSem_05040101_parameters_of_kind_value_013 |verify that error is generated if formal value parameter of test case contains dash |Clause 5.4.1.1 |m |y
+|14 |NegSem_05040101_parameters_of_kind_value_014 |verify that `out` formal value parameters cannot have lazy modifier |Clause 5.4.1.1 |m |y
+|15 |NegSem_05040101_parameters_of_kind_value_015 |verify that `out` formal value parameters cannot have fuzzy modifier |Clause 5.4.1.1 |m |n
+|16 |NegSem_05040101_parameters_of_kind_value_016 |verify that `inout` formal value parameters cannot have lazy modifier |Clause 5.4.1.1 |m |y
+|17 |NegSem_05040101_parameters_of_kind_value_017 |verify that `inout` formal value parameters cannot have fuzzy modifier |Clause 5.4.1.1 |m |n
+|18 |NegSyn_05040101_parameters_of_kind_value_001 |verify that `const` definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|19 |NegSyn_05040101_parameters_of_kind_value_002 |verify that `var` definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|20 |NegSyn_05040101_parameters_of_kind_value_003 |verify that template variable definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|21 |NegSyn_05040101_parameters_of_kind_value_004 |verify that timer definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|22 |NegSyn_05040101_parameters_of_kind_value_005 |verify that control definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|23 |NegSyn_05040101_parameters_of_kind_value_006 |verify that record of definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|24 |NegSyn_05040101_parameters_of_kind_value_007 |verify that set of definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|25 |NegSyn_05040101_parameters_of_kind_value_008 |verify that enumerated definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|26 |NegSyn_05040101_parameters_of_kind_value_009 |verify that port definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|27 |NegSyn_05040101_parameters_of_kind_value_010 |verify that component definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|28 |NegSyn_05040101_parameters_of_kind_value_011 |verify that subtype definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|29 |NegSyn_05040101_parameters_of_kind_value_012 |verify that group definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|30 |NegSyn_05040101_parameters_of_kind_value_013 |verify that import definition cannot be parameterized |Clause 5.4.1.1 |m |y
+|31 |Sem_05040101_parameters_of_kind_value_001 |The IUT correctly handles parametrization through the use of module parameters. |Clause 5.4.1.1 |m |y
+|32 |Sem_05040101_parameters_of_kind_value_002 |The IUT correctly handles parametrization through the use of module parameters. |Clause 5.4.1.1 |m |y
+|33 |Sem_05040101_parameters_of_kind_value_003 |The IUT correctly handles parametrization through the use of module parameters. |Clause 5.4.1.1 |m |y
+|34 |Sem_05040101_parameters_of_kind_value_004 |The IUT correctly handles parametrization through the use of module parameters. |Clause 5.4.1.1 |m |y
+|35 |Sem_05040101_parameters_of_kind_value_005 |verify that template definition can contain `in` value formal parameters |Clause 5.4.1.1 |m |y
+|36 |Sem_05040101_parameters_of_kind_value_006 |verify that local template definition can contain `in` value formal parameters |Clause 5.4.1.1 |m |n
+|37 |Sem_05040101_parameters_of_kind_value_007 |verify that function definition can contain `in`, `out` and `inout` value formal parameters |Clause 5.4.1.1 |m |y
+|38 |Sem_05040101_parameters_of_kind_value_008 |verify that altstep definition can contain `in`, `out` and `inout` value formal parameters |Clause 5.4.1.1 |m |y
+|39 |Sem_05040101_parameters_of_kind_value_009 |verify that test case definition can contain `in`, `out` and `inout` value formal parameters |Clause 5.4.1.1 |m |y
+|40 |Sem_05040101_parameters_of_kind_value_010 |verify that value formal parameters can be used in expressions |Clause 5.4.1.1 |m |y
+|41 |Sem_05040101_parameters_of_kind_value_011 |verify that `in` value formal parameters of template can have default values |Clause 5.4.1.1 |m |n
+|42 |Sem_05040101_parameters_of_kind_value_012 |verify that `in` value formal parameters of local template can have default values |Clause 5.4.1.1 |m |y
+|43 |Sem_05040101_parameters_of_kind_value_013 |verify that `in` value formal parameters of function can have default values |Clause 5.4.1.1 |m |y
+|44 |Sem_05040101_parameters_of_kind_value_014 |verify that `in` value formal parameters of altstep can have default values |Clause 5.4.1.1 |m |y
+|45 |Sem_05040101_parameters_of_kind_value_015 |verify that `in` value formal parameters of test case can have default values |Clause 5.4.1.1 |m |y
+|46 |Sem_05040101_parameters_of_kind_value_016 |verify that `in` value formal parameters of modified template can used dash as default value |Clause 5.4.1.1 |m |y
+|47 |Sem_05040101_parameters_of_kind_value_017 |verify that `null` is suitable default value of formal value parameters of component type |Clause 5.4.1.1 |m |y
+|48 |Sem_05040101_parameters_of_kind_value_018 |verify that `self` is suitable default value of formal value parameters of component type |Clause 5.4.1.1 |m |n
+|49 |Sem_05040101_parameters_of_kind_value_019 |verify that `mtc` is suitable default value of formal value parameters of component type |Clause 5.4.1.1 |m |y
+|50 |Sem_05040101_parameters_of_kind_value_020 |verify that `system` is suitable default value of formal value parameters of component type |Clause 5.4.1.1 |m |y
+|51 |Sem_05040101_parameters_of_kind_value_021 |verify that `null` can be used as default value of formal value parameters of default type |Clause 5.4.1.1 |m |y
+|52 |Sem_05040101_parameters_of_kind_value_022 |verify that passing by value and by reference works correctly |Clause 5.4.1.1 |m |y
+|=========================================================================================================================================================================================
+
+== Formal parameters of kind template
+
+.Formal parameters of kind template
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_05040102_parameters_of_kind_template_001 |verify that `in` template formal parameters of template cannot used dash as default value |Clause 5.4.1.2 |m |y
+|2 |NegSem_05040102_parameters_of_kind_template_002 |verify that modified template cannot used dash as default value when original template parameter had no default value |Clause 5.4.1.2 |m |y
+|3 |NegSem_05040102_parameters_of_kind_template_003 |verify that template definitions cannot contain `out` template formal parameters |Clause 5.4.1.2 |m |y
+|4 |NegSem_05040102_parameters_of_kind_template_004 |verify that template definitions cannot contain `inout` template formal parameters |Clause 5.4.1.2 |m |y
+|5 |NegSem_05040102_parameters_of_kind_template_005 |verify that `out` template formal parameters cannot have default values |Clause 5.4.1.2 |m |y
+|6 |NegSem_05040102_parameters_of_kind_template_006 |verify that `inout` template formal parameters cannot have default values |Clause 5.4.1.2 |m |y
+|7 |NegSem_05040102_parameters_of_kind_template_007 |verify that incompatible template instance in default template assignment of template formal parameters causes error |Clause 5.4.1.2 |m |y
+|8 |NegSem_05040102_parameters_of_kind_template_008 |verify that default template instance of template formal parameters cannot reference component elements |Clause 5.4.1.2 |m |y
+|9 |NegSem_05040102_parameters_of_kind_template_009 |verify that default template instance of template formal parameters cannot reference other parameters |Clause 5.4.1.2 |m |y
+|10 |NegSem_05040102_parameters_of_kind_template_010 |verify that default template instance of template formal parameters cannot invoke functions with `runs on` clause |Clause 5.4.1.2 |m |y
+|11 |NegSem_05040102_parameters_of_kind_template_011 |verify that error is generated if formal template parameter of function contains dash |Clause 5.4.1.2 |m |n
+|12 |NegSem_05040102_parameters_of_kind_template_012 |verify that error is generated if formal template parameter of altstep contains dash |Clause 5.4.1.2 |m |n
+|13 |NegSem_05040102_parameters_of_kind_template_013 |verify that error is generated if formal template parameter of test case contains dash |Clause 5.4.1.2 |m |n
+|14 |NegSem_05040102_parameters_of_kind_template_014 |verify that out formal template parameters cannot have lazy modifier |Clause 5.4.1.2 |m |y
+|15 |NegSem_05040102_parameters_of_kind_template_015 |verify that out formal template parameters cannot have fuzzy modifier |Clause 5.4.1.2 |m |n
+|16 |NegSem_05040102_parameters_of_kind_template_016 |verify that `inout` formal template parameters cannot have lazy modifier |Clause 5.4.1.2 |m |y
+|17 |NegSem_05040102_parameters_of_kind_template_017 |verify that `inout` formal template parameters cannot have fuzzy modifier |Clause 5.4.1.2 |m |n
+|18 |NegSem_05040102_parameters_of_kind_template_018 |Verify that template parameter of an activated altstep cannot be an out parameter |Clause 5.4.1.2 |m |n
+|19 |NegSem_05040102_parameters_of_kind_template_019 |Verify that template parameter of an activated altstep cannot be an `inout` parameter |Clause 5.4.1.2 |m |n
+|20 |NegSyn_05040102_parameters_of_kind_template_001 |verify that module parameter of template kind is not allowed |Clause 5.4.1.2 |m |n
+|21 |Sem_05040102_parameters_of_kind_template_001 |The IUT correctly handles parametrization through the use of parameterized templates. |Clause 5.4.1.2 |m |y
+|22 |Sem_05040102_parameters_of_kind_template_002 |The IUT correctly handles parametrization through the use of parameterized templates. |Clause 5.4.1.2 |m |y
+|23 |Sem_05040102_parameters_of_kind_template_003 |verify that template definition can contain `in` template formal parameters |Clause 5.4.1.2 |m |y
+|24 |Sem_05040102_parameters_of_kind_template_004 |verify that local template definition can contain `in` template formal parameters |Clause 5.4.1.2 |m |n
+|25 |Sem_05040102_parameters_of_kind_template_005 |verify that function definition can contain `in`, `out` and `inout` template formal parameters |Clause 5.4.1.2 |m |y
+|26 |Sem_05040102_parameters_of_kind_template_006 |verify that altstep definition can contain `in`, `out` and `inout` template formal parameters |Clause 5.4.1.2 |m |y
+|27 |Sem_05040102_parameters_of_kind_template_007 |verify that test case definition can contain `in`, `out` and `inout` template formal parameters |Clause 5.4.1.2 |m |y
+|28 |Sem_05040102_parameters_of_kind_template_008 |verify that template formal parameters can be used in the same way as templates or template variables |Clause 5.4.1.2 |m |y
+|29 |Sem_05040102_parameters_of_kind_template_009 |verify that `in` template formal parameters of template can have default values |Clause 5.4.1.2 |m |y
+|30 |Sem_05040102_parameters_of_kind_template_010 |verify that `in` template formal parameters of local template can have default values |Clause 5.4.1.2 |m |n
+|31 |Sem_05040102_parameters_of_kind_template_011 |verify that `in` template formal parameters of function can have default values |Clause 5.4.1.2 |m |y
+|32 |Sem_05040102_parameters_of_kind_template_012 |verify that `in` template formal parameters of altstep can have default values |Clause 5.4.1.2 |m |y
+|33 |Sem_05040102_parameters_of_kind_template_013 |verify that `in` template formal parameters of test case can have default values |Clause 5.4.1.2 |m |y
+|34 |Sem_05040102_parameters_of_kind_template_014 |verify that `in` template formal parameters of modified template can used dash as default value |Clause 5.4.1.2 |m |y
+|35 |Sem_05040102_parameters_of_kind_template_015 |verify that template definition can contain `in` template formal parameters with omit restriction |Clause 5.4.1.2 |m |y
+|36 |Sem_05040102_parameters_of_kind_template_016 |verify that local template definition can contain `in` template formal parameters with omit restriction |Clause 5.4.1.2 |m |n
+|37 |Sem_05040102_parameters_of_kind_template_017 |verify that function definition can contain `in`, `out` and `inout` template formal parameters with omit restriction |Clause 5.4.1.2 |m |y
+|38 |Sem_05040102_parameters_of_kind_template_018 |verify that altstep definition can contain `in`, `out` and `inout` template formal parameters with omit restriction |Clause 5.4.1.2 |m |y
+|39 |Sem_05040102_parameters_of_kind_template_019 |verify that test case definition can contain `in`, `out` and `inout` template formal parameters with omit restriction |Clause 5.4.1.2 |m |y
+|40 |Sem_05040102_parameters_of_kind_template_020 |verify that template definition can contain `in` template formal parameters with present restriction |Clause 5.4.1.2 |m |y
+|41 |Sem_05040102_parameters_of_kind_template_021 |verify that local template definition can contain `in` template formal parameters with present restriction |Clause 5.4.1.2 |m |n
+|42 |Sem_05040102_parameters_of_kind_template_022 |verify that function definition can contain `in`, `out` and `inout` template formal parameters with present restriction |Clause 5.4.1.2 |m |y
+|43 |Sem_05040102_parameters_of_kind_template_023 |verify that altstep definition can contain `in`, `out` and `inout` template formal parameters with present restriction |Clause 5.4.1.2 |m |y
+|44 |Sem_05040102_parameters_of_kind_template_024 |verify that test case definition can contain `in`, `out` and `inout` template formal parameters with present restriction |Clause 5.4.1.2 |m |y
+|45 |Sem_05040102_parameters_of_kind_template_025 |verify that template definition can contain `in` template formal parameters with value restriction |Clause 5.4.1.2 |m |y
+|46 |Sem_05040102_parameters_of_kind_template_026 |verify that local template definition can contain `in` template formal parameters with value restriction |Clause 5.4.1.2 |m |n
+|47 |Sem_05040102_parameters_of_kind_template_027 |verify that function definition can contain in, out and `inout` template formal parameters with value restriction |Clause 5.4.1.2 |m |y
+|48 |Sem_05040102_parameters_of_kind_template_028 |verify that altstep definition can contain in, out and `inout` template formal parameters with value restriction |Clause 5.4.1.2 |m |y
+|49 |Sem_05040102_parameters_of_kind_template_029 |verify that test case definition can contain in, out and `inout` template formal parameters with value restriction |Clause 5.4.1.2 |m |y
+|50 |Sem_05040102_parameters_of_kind_template_030 |verify that template definition can contain in template formal parameters with short omit restriction |Clause 5.4.1.2 |m |y
+|51 |Sem_05040102_parameters_of_kind_template_031 |verify that local template definition can contain in template formal parameters with short omit restriction |Clause 5.4.1.2 |m |n
+|52 |Sem_05040102_parameters_of_kind_template_032 |verify that function definition can contain in, out and `inout` template formal parameters with short omit restriction |Clause 5.4.1.2 |m |y
+|53 |Sem_05040102_parameters_of_kind_template_033 |verify that altstep definition can contain in, out and `inout` template formal parameters with short omit restriction |Clause 5.4.1.2 |m |y
+|54 |Sem_05040102_parameters_of_kind_template_034 |verify that test case definition can contain in, out and `inout` template formal parameters with short omit restriction |Clause 5.4.1.2 |m |y
+|55 |Sem_05040102_parameters_of_kind_template_035 |verify that `null` is suitable default value of formal template parameters of component type |Clause 5.4.1.2 |m |y
+|56 |Sem_05040102_parameters_of_kind_template_036 |verify that `self` is suitable default value of formal template parameters of component type |Clause 5.4.1.2 |m |n
+|57 |Sem_05040102_parameters_of_kind_template_037 |verify that `mtc` is suitable default value of formal template parameters of component type |Clause 5.4.1.2 |m |y
+|58 |Sem_05040102_parameters_of_kind_template_038 |verify that `system` is suitable default value of formal template parameters of component type |Clause 5.4.1.2 |m |y
+|===============================================================================================================================================================================================
+
+== Formal parameters of kind timer
+
+.Formal parameters of kind timer
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_05040103_parameters_of_kind_timer_001 |Verify that functions with timer parameters cannot be used in `component.start` operation |Clause 5.4.1.3 |m |y
+|2 |NegSem_05040103_parameters_of_kind_timer_002 |Verify that altsteps with timer parameters cannot be used in `component.start` operation |Clause 5.4.1.3 |m |n
+|3 |NegSem_05040103_parameters_of_kind_timer_003 |Verify that test cases cannot have timer parameters |Clause 5.4.1.3 |m |y
+|4 |NegSem_05040103_parameters_of_kind_timer_004 |Verify that templates cannot have timer parameters |Clause 5.4.1.3 |m |y
+|5 |NegSyn_05040103_parameters_of_kind_timer_001 |Verify that in timer parameters are not allowed |Clause 5.4.1.3 |m |y
+|6 |NegSyn_05040103_parameters_of_kind_timer_002 |Verify that out timer parameters are not allowed |Clause 5.4.1.3 |m |y
+|7 |Sem_05040103_parameters_of_kind_timer_001 |The IUT correctly handles parametrization through the use of timer parameters. |Clause 5.4.1.3 |m |y
+|8 |Sem_05040103_parameters_of_kind_timer_002 |Verify that `inout` prefix can be used for timer parameters |Clause 5.4.1.3 |m |y
+|9 |Sem_05040103_parameters_of_kind_timer_003 |Verify that altstep can have timer parameters |Clause 5.4.1.3 |m |y
+|==============================================================================================================================================================
+
+== Formal parameters of kind port
+
+.Formal parameters of kind port
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_05040104_parameters_of_kind_port_001 |Verify that functions with port parameters cannot be used in `component.start` operation |Clause 5.4.1.4 |m |y
+|2 |NegSem_05040104_parameters_of_kind_port_002 |Verify that altsteps with port parameters cannot be used in `component.start` operation |Clause 5.4.1.4 |m |n
+|3 |NegSem_05040104_parameters_of_kind_port_003 |Verify that in port parameters are not allowed |Clause 5.4.1.4 |m |y
+|4 |NegSem_05040104_parameters_of_kind_port_004 |Verify that out port parameters are not allowed |Clause 5.4.1.4 |m |y
+|5 |NegSem_05040104_parameters_of_kind_port_005 |Verify that test cases cannot have port parameters |Clause 5.4.1.4 |m |y
+|6 |NegSem_05040104_parameters_of_kind_port_006 |Verify that templates cannot contain port parameters |Clause 5.4.1.4 |m |y
+|7 |Sem_05040104_parameters_of_kind_port_001 |The IUT accepts port parametrization types for functions. |Clause 5.4.1.4 |m |y
+|8 |Sem_05040104_parameters_of_kind_port_002 |Verify that `inout` prefix can be used for port parameters |Clause 5.4.1.4 |m |y
+|============================================================================================================================================================
+
+== Actual parameters
+
+.Actual parameters
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_050402_actual_parameters_001 |verify that template parameters cannot be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|2 |NegSem_050402_actual_parameters_002 |verify that template variables cannot be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|3 |NegSem_050402_actual_parameters_003 |verify that template `in` parameters cannot be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|4 |NegSem_050402_actual_parameters_004 |verify that template `out` parameters cannot be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|5 |NegSem_050402_actual_parameters_005 |verify that template `inout` parameters cannot be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|6 |NegSem_050402_actual_parameters_006 |verify that template parameters cannot be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|7 |NegSem_050402_actual_parameters_007 |verify that template variables cannot be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|8 |NegSem_050402_actual_parameters_008 |verify that template `in` parameters cannot be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|9 |NegSem_050402_actual_parameters_009 |verify that template `out` parameters cannot be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|10 |NegSem_050402_actual_parameters_010 |verify that template `inout` parameters cannot be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|11 |NegSem_050402_actual_parameters_011 |verify that template parameters cannot be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|12 |NegSem_050402_actual_parameters_012 |verify that template variables cannot be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|13 |NegSem_050402_actual_parameters_013 |verify that template `in` parameters cannot be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|14 |NegSem_050402_actual_parameters_014 |verify that template `out` parameters cannot be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|15 |NegSem_050402_actual_parameters_015 |verify that template `inout` parameters cannot be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|16 |NegSem_050402_actual_parameters_016 |verify that template parameters cannot be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|17 |NegSem_050402_actual_parameters_017 |verify that template variables cannot be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|18 |NegSem_050402_actual_parameters_018 |verify that template `in` parameters cannot be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|19 |NegSem_050402_actual_parameters_019 |verify that template `out` parameters cannot be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|20 |NegSem_050402_actual_parameters_020 |verify that template `inout` parameters cannot be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|21 |NegSem_050402_actual_parameters_021 |verify that literals cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|22 |NegSem_050402_actual_parameters_022 |verify that module parameters cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|23 |NegSem_050402_actual_parameters_023 |verify that constants cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|24 |NegSem_050402_actual_parameters_024 |verify that function calls cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|25 |NegSem_050402_actual_parameters_025 |verify that expressions cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|26 |NegSem_050402_actual_parameters_026 |verify that template parameters cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|27 |NegSem_050402_actual_parameters_027 |verify that template variables cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|28 |NegSem_050402_actual_parameters_028 |verify that template `in` parameters cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|29 |NegSem_050402_actual_parameters_029 |verify that template `out` parameters cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|30 |NegSem_050402_actual_parameters_030 |verify that template `inout` parameters cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|31 |NegSem_050402_actual_parameters_031 |verify that template variable element reference cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|32 |NegSem_050402_actual_parameters_032 |verify that reference to elements of formal value parameters cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|33 |NegSem_050402_actual_parameters_033 |verify that literals cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|34 |NegSem_050402_actual_parameters_034 |verify that module parameters cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|35 |NegSem_050402_actual_parameters_035 |verify that constants cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|36 |NegSem_050402_actual_parameters_036 |verify that function calls cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|37 |NegSem_050402_actual_parameters_037 |verify that expressions cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|38 |NegSem_050402_actual_parameters_038 |verify that template parameters cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|39 |NegSem_050402_actual_parameters_039 |verify that template variables cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|40 |NegSem_050402_actual_parameters_040 |verify that template `in` parameters cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|41 |NegSem_050402_actual_parameters_041 |verify that template out parameters cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|42 |NegSem_050402_actual_parameters_042 |verify that template `inout` parameters cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|43 |NegSem_050402_actual_parameters_043 |verify that template variable element reference cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|44 |NegSem_050402_actual_parameters_044 |verify that reference to elements of formal value parameters cannot be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|45 |NegSem_050402_actual_parameters_045 |verify that literals cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|46 |NegSem_050402_actual_parameters_046 |verify that module parameters cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|47 |NegSem_050402_actual_parameters_047 |verify that constants cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|48 |NegSem_050402_actual_parameters_048 |verify that function calls cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|49 |NegSem_050402_actual_parameters_049 |verify that expressions cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|50 |NegSem_050402_actual_parameters_050 |verify that template parameters cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|51 |NegSem_050402_actual_parameters_051 |verify that template variables cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|52 |NegSem_050402_actual_parameters_052 |verify that template `in` parameters cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|53 |NegSem_050402_actual_parameters_053 |verify that template `out` parameters cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|54 |NegSem_050402_actual_parameters_054 |verify that template `inout` parameters cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|55 |NegSem_050402_actual_parameters_055 |verify that template variable element reference cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|56 |NegSem_050402_actual_parameters_056 |verify that reference to elements of formal value parameters cannot be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|57 |NegSem_050402_actual_parameters_057 |verify that literals cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|58 |NegSem_050402_actual_parameters_058 |verify that module parameters cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|59 |NegSem_050402_actual_parameters_059 |verify that constants cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|60 |NegSem_050402_actual_parameters_060 |verify that function calls cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|61 |NegSem_050402_actual_parameters_061 |verify that expressions cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|62 |NegSem_050402_actual_parameters_062 |verify that template parameters cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|63 |NegSem_050402_actual_parameters_063 |verify that literals cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|64 |NegSem_050402_actual_parameters_064 |verify that module parameters cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|65 |NegSem_050402_actual_parameters_065 |verify that constants cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|66 |NegSem_050402_actual_parameters_066 |verify that function calls cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|67 |NegSem_050402_actual_parameters_067 |verify that expressions cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|68 |NegSem_050402_actual_parameters_068 |verify that template parameters cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|69 |NegSem_050402_actual_parameters_069 |verify that literals cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|70 |NegSem_050402_actual_parameters_070 |verify that module parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|71 |NegSem_050402_actual_parameters_071 |verify that constants cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|72 |NegSem_050402_actual_parameters_072 |verify that function calls cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|73 |NegSem_050402_actual_parameters_073 |verify that expressions cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|74 |NegSem_050402_actual_parameters_074 |verify that template parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|75 |NegSem_050402_actual_parameters_075 |verify that literals cannot be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|76 |NegSem_050402_actual_parameters_076 |verify that module parameters cannot be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|77 |NegSem_050402_actual_parameters_077 |verify that constants cannot be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|78 |NegSem_050402_actual_parameters_078 |verify that function calls cannot be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|79 |NegSem_050402_actual_parameters_079 |verify that expressions cannot be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|80 |NegSem_050402_actual_parameters_080 |verify that template parameters cannot be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|81 |NegSem_050402_actual_parameters_081 |verify that literals cannot be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|82 |NegSem_050402_actual_parameters_082 |verify that module parameters cannot be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|83 |NegSem_050402_actual_parameters_083 |verify that constants cannot be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|84 |NegSem_050402_actual_parameters_084 |verify that function calls cannot be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|85 |NegSem_050402_actual_parameters_085 |verify that expressions cannot be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|86 |NegSem_050402_actual_parameters_086 |verify that template parameters cannot be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|87 |NegSem_050402_actual_parameters_087 |verify that literals cannot be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|88 |NegSem_050402_actual_parameters_088 |verify that module parameters cannot be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|89 |NegSem_050402_actual_parameters_089 |verify that constants cannot be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|90 |NegSem_050402_actual_parameters_090 |verify that function calls cannot be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|91 |NegSem_050402_actual_parameters_091 |verify that expressions cannot be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|92 |NegSem_050402_actual_parameters_092 |verify that template parameters cannot be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|93 |NegSem_050402_actual_parameters_093 |verify that referencing errors are detected in actual parameters passed to `in` formal value parameters |Clause 5.4.2 |m |y
+|94 |NegSem_050402_actual_parameters_094 |verify that referencing errors are detected in actual parameters passed to `in` formal template parameters |Clause 5.4.2 |m |y
+|95 |NegSem_050402_actual_parameters_095 |verify that referencing errors are detected in actual parameters passed to `out` formal template parameters |Clause 5.4.2 |m |y
+|96 |NegSem_050402_actual_parameters_096 |verify that referencing rules are correctly applied to actual parameters of `inout` formal template parameters |Clause 5.4.2 |m |y
+|97 |NegSem_050402_actual_parameters_097 |verify that string item references cannot be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|98 |NegSem_050402_actual_parameters_098 |verify that ordinary values cannot be passed to timer parameters |Clause 5.4.2 |m |y
+|99 |NegSem_050402_actual_parameters_099 |verify that values cannot be passed to port parameters |Clause 5.4.2 |m |y
+|100 |NegSem_050402_actual_parameters_100 |verify that list notation containing actual parameters in wrong order is not accepted |Clause 5.4.2 |m |y
+|101 |NegSem_050402_actual_parameters_101 |verify that list notation containing less actual parameters than required is not accepted |Clause 5.4.2 |m |y
+|102 |NegSem_050402_actual_parameters_102 |verify that parameter without default value cannot be skipped |Clause 5.4.2 |m |y
+|103 |NegSem_050402_actual_parameters_103 |verify that mixing list and assignment notation is not allowed in parameterized calls (value as actual parameter) |Clause 5.4.2 |m |y
+|104 |NegSem_050402_actual_parameters_104 |verify that mixing list and assignment notation is not allowed in parameterized calls (skipped actual parameter) |Clause 5.4.2 |m |y
+|105 |NegSem_050402_actual_parameters_105 |verify that parameters cannot be assigned more than once in assignment notation |Clause 5.4.2 |m |y
+|106 |NegSem_050402_actual_parameters_106 |verify that assignment notation that doesn't contain all parameters is not accepted |Clause 5.4.2 |m |y
+|107 |NegSem_050402_actual_parameters_107 |verify that incompatible values cannot be passed to in formal parameters |Clause 5.4.2 |m |y
+|108 |NegSem_050402_actual_parameters_108 |verify that incompatible values cannot be passed from out formal parameters |Clause 5.4.2 |m |y
+|109 |NegSem_050402_actual_parameters_109 |verify that incompatible values cannot be passed to `inout` formal parameters |Clause 5.4.2 |m |y
+|110 |NegSem_050402_actual_parameters_110 |verify that values of compatible but distinct types cannot be passed to `inout` formal parameters |Clause 5.4.2 |m |n
+|111 |NegSem_050402_actual_parameters_111 |verify that incompatible templates cannot be passed to template parameters with omit restriction |Clause 5.4.2 |m |y
+|112 |NegSem_050402_actual_parameters_112 |verify that compatible templates can be passed to template parameters with value restriction |Clause 5.4.2 |m |y
+|113 |NegSem_050402_actual_parameters_113 |verify that compatible templates can be passed to template parameters with present restriction |Clause 5.4.2 |m |y
+|114 |NegSem_050402_actual_parameters_114 |verify that parametrized entities used as actual parameter cannot be passed without parameter list |Clause 5.4.2 |m |y
+|115 |NegSem_050402_actual_parameters_115 |verify that error is generated when no actual parameter list is used for functions with no parameters |Clause 5.4.2 |m |y
+|116 |NegSem_050402_actual_parameters_116 |verify that error is generated when no actual parameter list is used for test cases with no parameters |Clause 5.4.2 |m |y
+|117 |NegSem_050402_actual_parameters_117 |verify that error is generated when no actual parameter list is used for altsteps with no parameters |Clause 5.4.2 |m |y
+|118 |NegSem_050402_actual_parameters_118 |verify that error is generated when empty actual parameter list is used for templates with no parameters |Clause 5.4.2 |m |y
+|119 |NegSem_050402_actual_parameters_119 |verify that uninitialized values cannot be passed to in formal parameters |Clause 5.4.2 |m |n
+|120 |NegSem_050402_actual_parameters_120 |verify that uninitialized values cannot be passed to `inout` formal parameters |Clause 5.4.2 |m |n
+|121 |NegSem_050402_actual_parameters_121 |verify that function calls passed to lazy formal parameters cannot contain `inout` parameters |Clause 5.4.2 |m |n
+|122 |NegSem_050402_actual_parameters_122 |verify that function calls passed to fuzzy formal parameters cannot contain `inout` parameters |Clause 5.4.2 |m |n
+|123 |NegSem_050402_actual_parameters_123 |verify that function calls passed to lazy formal parameters cannot contain out parameters |Clause 5.4.2 |m |n
+|124 |NegSem_050402_actual_parameters_124 |verify that function calls passed to fuzzy formal parameters cannot contain out parameters |Clause 5.4.2 |m |n
+|125 |NegSem_050402_actual_parameters_125 |verify that error is generated when lazy variable is passed to `inout` formal parameter |Clause 5.4.2 |m |n
+|126 |NegSem_050402_actual_parameters_126 |verify that error is generated when fuzzy variable is passed to `inout` formal parameter |Clause 5.4.2 |m |n
+|127 |NegSem_050402_actual_parameters_127 |verify that error is generated when lazy variable is passed to out formal parameter |Clause 5.4.2 |m |n
+|128 |NegSem_050402_actual_parameters_128 |verify that error is generated when fuzzy variable is passed to out formal parameter |Clause 5.4.2 |m |n
+|129 |NegSem_050402_actual_parameters_129 |verify that error is generated when passing record and its field to `inout` parameters |Clause 5.4.2 |m |n
+|130 |NegSem_050402_actual_parameters_130 |verify that error is generated when passing set and its field to `inout` parameters |Clause 5.4.2 |m |n
+|131 |NegSem_050402_actual_parameters_131 |verify that error is generated when passing union and its element to `inout` parameters |Clause 5.4.2 |m |n
+|132 |NegSem_050402_actual_parameters_132 |verify that error is generated when passing record of and its element to `inout` parameters |Clause 5.4.2 |m |n
+|133 |NegSem_050402_actual_parameters_133 |verify that error is generated when passing set of and its element to `inout` parameters |Clause 5.4.2 |m |n
+|134 |NegSem_050402_actual_parameters_134 |verify that error is generated when passing array and its element to `inout` parameters |Clause 5.4.2 |m |n
+|135 |NegSem_050402_actual_parameters_135 |verify that error is generated when passing anytype value and its element to `inout` parameters |Clause 5.4.2 |m |n
+|136 |NegSem_050402_actual_parameters_136 |verify that error is generated when passing record and its sub-elements to `inout` parameters |Clause 5.4.2 |m |n
+|137 |NegSem_050402_actual_parameters_137 |verify that error is generated when passing set and its sub-field to `inout` parameters |Clause 5.4.2 |m |n
+|138 |NegSem_050402_actual_parameters_138 |verify that error is generated when passing union and its sub-element to `inout` parameters |Clause 5.4.2 |m |n
+|139 |NegSem_050402_actual_parameters_139 |verify that error is generated when passing record of and its sub-element to `inout` parameters |Clause 5.4.2 |m |n
+|140 |NegSem_050402_actual_parameters_140 |verify that error is generated when passing set of and its sub-element to `inout` parameters |Clause 5.4.2 |m |n
+|141 |NegSem_050402_actual_parameters_141 |verify that error is generated when passing array and its sub-element to `inout` parameters |Clause 5.4.2 |m |n
+|142 |NegSem_050402_actual_parameters_142 |verify that error is generated when passing anytype value and its sub-element to `inout` parameters |Clause 5.4.2 |m |n
+|143 |NegSem_050402_actual_parameters_143 |verify that error is generated when passing distinct union alternatives to `inout` parameters |Clause 5.4.2 |m |n
+|144 |NegSem_050402_actual_parameters_144 |verify that error is generated when passing distinct union alternatives to `inout` parameters |Clause 5.4.2 |m |n
+|145 |NegSem_050402_actual_parameters_145 |verify that the fourth part of the Example 3 produces the expected error |Clause 5.4.2 |m |n
+|146 |NegSem_050402_actual_parameters_146 |verify that literal cannot be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|147 |NegSem_050402_actual_parameters_147 |verify that expression cannot be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|148 |NegSem_050402_actual_parameters_148 |verify that function calls cannot be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|149 |NegSem_050402_actual_parameters_149 |verify that module parameters cannot be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|150 |NegSem_050402_actual_parameters_150 |verify that templates cannot be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|151 |NegSem_050402_actual_parameters_151 |verify that constants cannot be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|152 |NegSem_050402_actual_parameters_152 |verify that literal cannot be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|153 |NegSem_050402_actual_parameters_153 |verify that expression cannot be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|154 |NegSem_050402_actual_parameters_154 |verify that function calls cannot be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|155 |NegSem_050402_actual_parameters_155 |verify that module parameters cannot be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|156 |NegSem_050402_actual_parameters_156 |verify that templates cannot be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|157 |NegSem_050402_actual_parameters_157 |verify that constants cannot be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|158 |NegSem_050402_actual_parameters_158 |verify that function cannot have more actual than formal parameters |Clause 5.4.2 |m |y
+|159 |NegSem_050402_actual_parameters_159 |verify that templates cannot have more actual than formal parameters |Clause 5.4.2 |m |y
+|160 |NegSem_050402_actual_parameters_160 |verify that altstep cannot have more actual than formal parameters |Clause 5.4.2 |m |y
+|161 |NegSem_050402_actual_parameters_161 |verify that function testcase cannot have more actual than formal parameters |Clause 5.4.2 |m |y
+|162 |NegSem_050402_actual_parameters_162 |verify that restricted template variables cannot be passed to unrestricted `inout` template parameters |Clause 5.4.2 |m |n
+|163 |NegSem_050402_actual_parameters_163 |verify that unrestricted template variables cannot be passed to restricted `inout` template parameters |Clause 5.4.2 |m |n
+|164 |NegSem_050402_actual_parameters_164 |verify that restricted template variables cannot be passed to `inout` template parameters with a different restriction |Clause 5.4.2 |m |n
+|165 |NegSem_050402_actual_parameters_165 |verify that value variables cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|166 |NegSem_050402_actual_parameters_166 |verify that value `in` parameters cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|167 |NegSem_050402_actual_parameters_167 |verify that value `out` parameters cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|168 |NegSem_050402_actual_parameters_168 |verify that value `inout` parameters cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|169 |NegSem_050402_actual_parameters_169 |verify that value variable element reference cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|170 |NegSem_050402_actual_parameters_170 |verify that reference to elements of formal value parameters cannot be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|171 |NegSem_050402_actual_parameters_171 |verify that value variables cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|172 |NegSem_050402_actual_parameters_172 |verify that value `in` parameters cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|173 |NegSem_050402_actual_parameters_173 |verify that value `out` parameters cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|174 |NegSem_050402_actual_parameters_174 |verify that value `inout` parameters cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|175 |NegSem_050402_actual_parameters_175 |verify that value variable element reference cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|176 |NegSem_050402_actual_parameters_176 |verify that reference to elements of formal value parameters cannot be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|177 |NegSem_050402_actual_parameters_177 |verify that value variables cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|178 |NegSem_050402_actual_parameters_178 |verify that value `in` parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|179 |NegSem_050402_actual_parameters_179 |verify that value `in` parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|180 |NegSem_050402_actual_parameters_180 |verify that value `in` parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|181 |NegSem_050402_actual_parameters_181 |verify that value `in` parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|182 |NegSem_050402_actual_parameters_182 |verify that value `in` parameters cannot be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|183 |Sem_050402_actual_parameters_001 |The IUT accepts allowed assignments of actual parameters. |Clause 5.4.2 |m |y
+|184 |Sem_050402_actual_parameters_002 |The IUT accepts nested assignment of actual parameters. |Clause 5.4.2 |m |y
+|185 |Sem_050402_actual_parameters_003 |verify that literals can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|186 |Sem_050402_actual_parameters_004 |verify that module parameters can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|187 |Sem_050402_actual_parameters_005 |verify that constants can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|188 |Sem_050402_actual_parameters_006 |verify that variables can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|189 |Sem_050402_actual_parameters_007 |verify that function calls can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|190 |Sem_050402_actual_parameters_008 |verify that in value parameters can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|191 |Sem_050402_actual_parameters_009 |verify that out value parameters can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|192 |Sem_050402_actual_parameters_010 |verify that `inout` value parameters can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|193 |Sem_050402_actual_parameters_011 |verify that expressions can be used as `in` formal value parameters of functions |Clause 5.4.2 |m |y
+|194 |Sem_050402_actual_parameters_012 |verify that literals can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|195 |Sem_050402_actual_parameters_013 |verify that module parameters can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|196 |Sem_050402_actual_parameters_014 |verify that constants can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|197 |Sem_050402_actual_parameters_015 |verify that variables can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|198 |Sem_050402_actual_parameters_016 |verify that function calls can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|199 |Sem_050402_actual_parameters_017 |verify that `in` value parameters can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|200 |Sem_050402_actual_parameters_018 |verify that out value parameters can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|201 |Sem_050402_actual_parameters_019 |verify that `inout` value parameters can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|202 |Sem_050402_actual_parameters_020 |verify that expressions can be used as `in` formal value parameters of templates |Clause 5.4.2 |m |y
+|203 |Sem_050402_actual_parameters_021 |verify that literals can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|204 |Sem_050402_actual_parameters_022 |verify that module parameters can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|205 |Sem_050402_actual_parameters_023 |verify that constants can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|206 |Sem_050402_actual_parameters_024 |verify that variables can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|207 |Sem_050402_actual_parameters_025 |verify that function calls can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|208 |Sem_050402_actual_parameters_026 |verify that `in` value parameters can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|209 |Sem_050402_actual_parameters_027 |verify that out value parameters can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|210 |Sem_050402_actual_parameters_028 |verify that `inout` value parameters can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|211 |Sem_050402_actual_parameters_029 |verify that expressions can be used as `in` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|212 |Sem_050402_actual_parameters_030 |verify that literals can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|213 |Sem_050402_actual_parameters_031 |verify that module parameters can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|214 |Sem_050402_actual_parameters_032 |verify that constants can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|215 |Sem_050402_actual_parameters_033 |verify that variables can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|216 |Sem_050402_actual_parameters_034 |verify that function calls can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|217 |Sem_050402_actual_parameters_035 |verify that `in` value parameters can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|218 |Sem_050402_actual_parameters_036 |verify that `out` value parameters can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|219 |Sem_050402_actual_parameters_037 |verify that `inout` value parameters can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|220 |Sem_050402_actual_parameters_038 |verify that expressions can be used as `in` formal value parameters of test cases |Clause 5.4.2 |m |y
+|221 |Sem_050402_actual_parameters_039 |verify that variables can be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|222 |Sem_050402_actual_parameters_040 |verify that `in` value parameters can be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|223 |Sem_050402_actual_parameters_041 |verify that `out` value parameters can be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|224 |Sem_050402_actual_parameters_042 |verify that `inout` value parameters can be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|225 |Sem_050402_actual_parameters_043 |verify that variable element reference can be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|226 |Sem_050402_actual_parameters_044 |verify that reference to elements of formal value parameters can be used as `inout` formal value parameters of functions |Clause 5.4.2 |m |y
+|227 |Sem_050402_actual_parameters_045 |verify that variables can be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|228 |Sem_050402_actual_parameters_046 |verify that `in` value parameters can be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|229 |Sem_050402_actual_parameters_047 |verify that `out` value parameters can be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|230 |Sem_050402_actual_parameters_048 |verify that `inout` value parameters can be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|231 |Sem_050402_actual_parameters_049 |verify that variable element reference can be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|232 |Sem_050402_actual_parameters_050 |verify that reference to elements of formal value parameters can be used as `inout` formal value parameters of altsteps |Clause 5.4.2 |m |y
+|233 |Sem_050402_actual_parameters_051 |verify that variables can be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|234 |Sem_050402_actual_parameters_052 |verify that `in` value parameters can be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|235 |Sem_050402_actual_parameters_053 |verify that `out` value parameters can be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|236 |Sem_050402_actual_parameters_054 |verify that `inout` value parameters can be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|237 |Sem_050402_actual_parameters_055 |verify that variable element reference can be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|238 |Sem_050402_actual_parameters_056 |verify that reference to elements of formal value parameters can be used as `inout` formal value parameters of test cases |Clause 5.4.2 |m |y
+|239 |Sem_050402_actual_parameters_057 |verify that literals can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|240 |Sem_050402_actual_parameters_058 |verify that module parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|241 |Sem_050402_actual_parameters_059 |verify that constants can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|242 |Sem_050402_actual_parameters_060 |verify that variables can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|243 |Sem_050402_actual_parameters_061 |verify that function calls can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|244 |Sem_050402_actual_parameters_062 |verify that `in` value parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|245 |Sem_050402_actual_parameters_063 |verify that `out` value parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|246 |Sem_050402_actual_parameters_064 |verify that `inout` value parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|247 |Sem_050402_actual_parameters_065 |verify that expressions can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|248 |Sem_050402_actual_parameters_066 |verify that template parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|249 |Sem_050402_actual_parameters_067 |verify that template variables can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|250 |Sem_050402_actual_parameters_068 |verify that template `in` parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|251 |Sem_050402_actual_parameters_069 |verify that template `out` parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|252 |Sem_050402_actual_parameters_070 |verify that template `inout` parameters can be used as in formal template parameters of functions |Clause 5.4.2 |m |y
+|253 |Sem_050402_actual_parameters_071 |verify that literals can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|254 |Sem_050402_actual_parameters_072 |verify that module parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|255 |Sem_050402_actual_parameters_073 |verify that constants can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|256 |Sem_050402_actual_parameters_074 |verify that variables can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|257 |Sem_050402_actual_parameters_075 |verify that function calls can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|258 |Sem_050402_actual_parameters_076 |verify that `in` value parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|259 |Sem_050402_actual_parameters_077 |verify that `out` value parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|260 |Sem_050402_actual_parameters_078 |verify that `inout` value parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|261 |Sem_050402_actual_parameters_079 |verify that expressions can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|262 |Sem_050402_actual_parameters_080 |verify that template parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|263 |Sem_050402_actual_parameters_081 |verify that template variables can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|264 |Sem_050402_actual_parameters_082 |verify that template `in` parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|265 |Sem_050402_actual_parameters_083 |verify that template `out` parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|266 |Sem_050402_actual_parameters_084 |verify that template `inout` parameters can be used as in formal template parameters of templates |Clause 5.4.2 |m |y
+|267 |Sem_050402_actual_parameters_085 |verify that literals can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|268 |Sem_050402_actual_parameters_086 |verify that module parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|269 |Sem_050402_actual_parameters_087 |verify that constants can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|270 |Sem_050402_actual_parameters_088 |verify that variables can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|271 |Sem_050402_actual_parameters_089 |verify that function calls can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|272 |Sem_050402_actual_parameters_090 |verify that `in` value parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|273 |Sem_050402_actual_parameters_091 |verify that `out` value parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|274 |Sem_050402_actual_parameters_092 |verify that `inout` value parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|275 |Sem_050402_actual_parameters_093 |verify that expressions can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|276 |Sem_050402_actual_parameters_094 |verify that template parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|277 |Sem_050402_actual_parameters_095 |verify that template variables can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|278 |Sem_050402_actual_parameters_096 |verify that template `in` parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|279 |Sem_050402_actual_parameters_097 |verify that template `out` parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|280 |Sem_050402_actual_parameters_098 |verify that template `inout` parameters can be used as in formal template parameters of altsteps |Clause 5.4.2 |m |y
+|281 |Sem_050402_actual_parameters_099 |verify that literals can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|282 |Sem_050402_actual_parameters_100 |verify that module parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|283 |Sem_050402_actual_parameters_101 |verify that constants can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|284 |Sem_050402_actual_parameters_102 |verify that variables can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|285 |Sem_050402_actual_parameters_103 |verify that function calls can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|286 |Sem_050402_actual_parameters_104 |verify that `in` value parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|287 |Sem_050402_actual_parameters_105 |verify that `out` value parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|288 |Sem_050402_actual_parameters_106 |verify that `inout` value parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|289 |Sem_050402_actual_parameters_107 |verify that expressions can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|290 |Sem_050402_actual_parameters_108 |verify that template parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|291 |Sem_050402_actual_parameters_109 |verify that template variables can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|292 |Sem_050402_actual_parameters_110 |verify that template `in` parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|293 |Sem_050402_actual_parameters_111 |verify that template `out` parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|294 |Sem_050402_actual_parameters_112 |verify that template `inout` parameters can be used as in formal template parameters of test cases |Clause 5.4.2 |m |y
+|295 |Sem_050402_actual_parameters_113 |verify that template variables can be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|296 |Sem_050402_actual_parameters_114 |verify that template `in` parameters can be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|297 |Sem_050402_actual_parameters_115 |verify that template `out` parameters can be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|298 |Sem_050402_actual_parameters_116 |verify that template `inout` parameters can be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|299 |Sem_050402_actual_parameters_117 |verify that template variable element reference can be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|300 |Sem_050402_actual_parameters_118 |verify that reference to elements of formal value parameters can be used as out formal template parameters of functions |Clause 5.4.2 |m |y
+|301 |Sem_050402_actual_parameters_119 |verify that template variables can be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|302 |Sem_050402_actual_parameters_120 |verify that template `in` parameters can be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|303 |Sem_050402_actual_parameters_121 |verify that template `out` parameters can be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|304 |Sem_050402_actual_parameters_122 |verify that template `inout` parameters can be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|305 |Sem_050402_actual_parameters_123 |verify that template variable element reference can be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|306 |Sem_050402_actual_parameters_124 |verify that reference to elements of formal value parameters can be used as out formal template parameters of altsteps |Clause 5.4.2 |m |y
+|307 |Sem_050402_actual_parameters_125 |verify that template variables can be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|308 |Sem_050402_actual_parameters_126 |verify that template `in` parameters can be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|309 |Sem_050402_actual_parameters_127 |verify that template `out` parameters can be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|310 |Sem_050402_actual_parameters_128 |verify that template `inout` parameters can be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|311 |Sem_050402_actual_parameters_129 |verify that template variable element reference can be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|312 |Sem_050402_actual_parameters_130 |verify that reference to elements of formal value parameters can be used as out formal template parameters of test cases |Clause 5.4.2 |m |y
+|313 |Sem_050402_actual_parameters_131 |verify that template variables can be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|314 |Sem_050402_actual_parameters_132 |verify that template `in` parameters can be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|315 |Sem_050402_actual_parameters_133 |verify that template `out` parameters can be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|316 |Sem_050402_actual_parameters_134 |verify that template `inout` parameters can be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|317 |Sem_050402_actual_parameters_135 |verify that template variable element reference can be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|318 |Sem_050402_actual_parameters_136 |verify that reference to elements of formal value parameters can be used as `inout` formal template parameters of functions |Clause 5.4.2 |m |y
+|319 |Sem_050402_actual_parameters_137 |verify that template variables can be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|320 |Sem_050402_actual_parameters_138 |verify that template `in` parameters can be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|321 |Sem_050402_actual_parameters_139 |verify that template `out` parameters can be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|322 |Sem_050402_actual_parameters_140 |verify that template `inout` parameters can be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|323 |Sem_050402_actual_parameters_141 |verify that template variable element reference can be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|324 |Sem_050402_actual_parameters_142 |verify that reference to elements of formal value parameters can be used as `inout` formal template parameters of altsteps |Clause 5.4.2 |m |y
+|325 |Sem_050402_actual_parameters_143 |verify that template variables can be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|326 |Sem_050402_actual_parameters_144 |verify that template `in` parameters can be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|327 |Sem_050402_actual_parameters_145 |verify that template `out` parameters can be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|328 |Sem_050402_actual_parameters_146 |verify that template `inout` parameters can be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|329 |Sem_050402_actual_parameters_147 |verify that template variable element reference can be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|330 |Sem_050402_actual_parameters_148 |verify that reference to elements of formal value parameters can be used as `inout` formal template parameters of test cases |Clause 5.4.2 |m |y
+|331 |Sem_050402_actual_parameters_149 |verify that referencing rules are correctly applied to actual parameters of `in` formal value parameters |Clause 5.4.2 |m |y
+|332 |Sem_050402_actual_parameters_150 |verify that referencing rules are correctly applied to actual parameters of in formal template parameters |Clause 5.4.2 |m |n
+|333 |Sem_050402_actual_parameters_151 |verify that referencing rules are correctly applied to actual parameters of `out` formal value parameters |Clause 5.4.2 |m |y
+|334 |Sem_050402_actual_parameters_152 |verify that referencing rules are correctly applied to actual parameters of out formal template parameters |Clause 5.4.2 |m |y
+|335 |Sem_050402_actual_parameters_153 |verify that referencing rules are correctly applied to actual parameters of `inout` formal value parameters |Clause 5.4.2 |m |y
+|336 |Sem_050402_actual_parameters_154 |verify that referencing rules are correctly applied to actual parameters of `inout` formal template parameters |Clause 5.4.2 |m |y
+|337 |Sem_050402_actual_parameters_155 |verify that `out` formal parameters are passed to actual parameter in correct (list notation) |Clause 5.4.2 |m |y
+|338 |Sem_050402_actual_parameters_156 |verify that `out` formal parameters are passed to actual parameter in correct (assignment notation) |Clause 5.4.2 |m |n
+|339 |Sem_050402_actual_parameters_157 |verify that component timers can be passed to timer parameters |Clause 5.4.2 |m |y
+|340 |Sem_050402_actual_parameters_158 |verify that component timers can be passed to timer parameters |Clause 5.4.2 |m |y
+|341 |Sem_050402_actual_parameters_159 |verify that timer parameters can be passed to timer parameters |Clause 5.4.2 |m |y
+|342 |Sem_050402_actual_parameters_160 |verify that component ports can be passed to port parameters |Clause 5.4.2 |m |y
+|343 |Sem_050402_actual_parameters_161 |verify that port parameters can be passed to port parameters |Clause 5.4.2 |m |y
+|344 |Sem_050402_actual_parameters_162 |verify that actual parameters override default values |Clause 5.4.2 |m |y
+|345 |Sem_050402_actual_parameters_163 |verify that default values are used if actual parameters are missing |Clause 5.4.2 |m |y
+|346 |Sem_050402_actual_parameters_164 |verify that actual parameters override default templates |Clause 5.4.2 |m |y
+|347 |Sem_050402_actual_parameters_165 |verify that default templates are used if actual parameters are missing |Clause 5.4.2 |m |y
+|348 |Sem_050402_actual_parameters_166 |verify that actual parameters are evaluated in order of their appearance (list notation) |Clause 5.4.2 |m |n
+|349 |Sem_050402_actual_parameters_167 |verify that actual parameters are evaluated in order of their appearance (assignment notation) |Clause 5.4.2 |m |n
+|350 |Sem_050402_actual_parameters_168 |verify that rules for referencing are applied to actual paremeters before passing to out formal parameters |Clause 5.4.2 |m |y
+|351 |Sem_050402_actual_parameters_169 |verify that rules for referencing are applied to actual paremeters before passing to `inout` formal parameters |Clause 5.4.2 |m |y
+|352 |Sem_050402_actual_parameters_170 |verify that default parameters are evaluated in order of the formal parameter list (list notation) |Clause 5.4.2 |m |n
+|353 |Sem_050402_actual_parameters_171 |verify that default parameters are evaluated in order of the formal parameter list (assignment notation) |Clause 5.4.2 |m |n
+|354 |Sem_050402_actual_parameters_172 |verify that it is possible to use parametrized template with no parentheses if all parameters have default values |Clause 5.4.2 |m |y
+|355 |Sem_050402_actual_parameters_173 |verify that it is possible to use parametrized template with empty parentheses |Clause 5.4.2 |m |y
+|356 |Sem_050402_actual_parameters_174 |verify that actual parameter values override default values |Clause 5.4.2 |m |y
+|357 |Sem_050402_actual_parameters_175 |verify that actual parameters in the beginning of list notation can be skipped |Clause 5.4.2 |m |y
+|358 |Sem_050402_actual_parameters_176 |verify that multiple actual parameters of list notation can be skipped |Clause 5.4.2 |m |y
+|359 |Sem_050402_actual_parameters_177 |verify that actual parameters at the end of list notation can be explicitly skipped |Clause 5.4.2 |m |y
+|360 |Sem_050402_actual_parameters_178 |verify that missing actual parameters at the end of list notation are considered to be skipped (single parameter) |Clause 5.4.2 |m |y
+|361 |Sem_050402_actual_parameters_179 |verify that missing actual parameters at the end of list notation are considered to be skipped (multiple parameter) |Clause 5.4.2 |m |y
+|362 |Sem_050402_actual_parameters_180 |verify that assignment notation containing all parameters in declaration order is accepted |Clause 5.4.2 |m |y
+|363 |Sem_050402_actual_parameters_181 |verify that assignment notation containing all parameters in random order is accepted |Clause 5.4.2 |m |n
+|364 |Sem_050402_actual_parameters_182 |verify that assignment notation can omit parameters with default value |Clause 5.4.2 |m |y
+|365 |Sem_050402_actual_parameters_183 |verify that compatible values can be passed to in formal parameters |Clause 5.4.2 |m |y
+|366 |Sem_050402_actual_parameters_184 |verify that compatible values can be passed from out formal parameters |Clause 5.4.2 |m |y
+|367 |Sem_050402_actual_parameters_185 |verify that compatible templates can be passed to template parameters with omit restriction |Clause 5.4.2 |m |y
+|368 |Sem_050402_actual_parameters_186 |verify that compatible templates can be passed to template parameters with value restriction |Clause 5.4.2 |m |y
+|369 |Sem_050402_actual_parameters_187 |verify that compatible templates can be passed to template parameters with present restriction |Clause 5.4.2 |m |y
+|370 |Sem_050402_actual_parameters_188 |verify that it is possible to use nested actual parameter lists |Clause 5.4.2 |m |y
+|371 |Sem_050402_actual_parameters_189 |verify that empty actual parameter list can be used for functions with no parameters |Clause 5.4.2 |m |y
+|372 |Sem_050402_actual_parameters_190 |verify that empty actual parameter list can be used for altsteps with no parameters |Clause 5.4.2 |m |y
+|373 |Sem_050402_actual_parameters_191 |verify that partially initialized values can be passed to in formal parameters |Clause 5.4.2 |m |y
+|374 |Sem_050402_actual_parameters_192 |verify that partially initialized values can be passed to `inout` formal parameters |Clause 5.4.2 |m |y
+|375 |Sem_050402_actual_parameters_193 |verify that Example 1 can be executed |Clause 5.4.2 |m |n
+|376 |Sem_050402_actual_parameters_194 |verify that Example 2 can be executed |Clause 5.4.2 |m |y
+|377 |Sem_050402_actual_parameters_195 |verify that the first part of the Example 3 can be executed |Clause 5.4.2 |m |y
+|378 |Sem_050402_actual_parameters_196 |verify that the third part of the Example 3 can be executed |Clause 5.4.2 |m |y
+|379 |Sem_050402_actual_parameters_198 |verify that the the Example 4 can be executed |Clause 5.4.2 |m |y
+|380 |Sem_050402_actual_parameters_199 |verify that the Example 5 can be executed |Clause 5.4.2 |m |y
+|381 |Sem_050402_actual_parameters_200 |verify that the Example 6 can be executed |Clause 5.4.2 |m |y
+|382 |Sem_050402_actual_parameters_201 |verify that the Example 7 can be executed |Clause 5.4.2 |m |y
+|383 |Sem_050402_actual_parameters_202 |verify that the Example 8 can be executed |Clause 5.4.2 |m |n
+|384 |Sem_050402_actual_parameters_203 |verify that variables can be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|385 |Sem_050402_actual_parameters_204 |verify that variables can be used as actual out value parameters of functions |Clause 5.4.2 |m |n
+|386 |Sem_050402_actual_parameters_205 |verify that in value parameters can be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|387 |Sem_050402_actual_parameters_206 |verify that `out` value parameters can be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|388 |Sem_050402_actual_parameters_207 |verify that `inout` value parameters can be used as actual out value parameters of functions |Clause 5.4.2 |m |y
+|389 |Sem_050402_actual_parameters_208 |verify that `in` template parameters can be used as actual out value parameters of functions |Clause 5.4.2 |m |n
+|390 |Sem_050402_actual_parameters_209 |verify that `out` template parameters can be used as actual out value parameters of functions |Clause 5.4.2 |m |n
+|391 |Sem_050402_actual_parameters_210 |verify that `inout` template parameters can be used as actual out value parameters of functions |Clause 5.4.2 |m |n
+|392 |Sem_050402_actual_parameters_211 |verify that dash can be used as an actual out value parameter of functions |Clause 5.4.2 |m |n
+|393 |Sem_050402_actual_parameters_212 |verify that variables can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|394 |Sem_050402_actual_parameters_213 |verify that variables can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |n
+|395 |Sem_050402_actual_parameters_214 |verify that in value parameters can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|396 |Sem_050402_actual_parameters_215 |verify that `out` value parameters can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|397 |Sem_050402_actual_parameters_216 |verify that `inout` value parameters can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |y
+|398 |Sem_050402_actual_parameters_217 |verify that `in` template parameters can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |n
+|399 |Sem_050402_actual_parameters_218 |verify that `out` template parameters can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |n
+|400 |Sem_050402_actual_parameters_219 |verify that `inout` template parameters can be used as actual out value parameters of altsteps |Clause 5.4.2 |m |n
+|401 |Sem_050402_actual_parameters_220 |verify that dash can be used as an actual out value parameter of altsteps |Clause 5.4.2 |m |n
+|402 |Sem_050402_actual_parameters_221 |verify that dash can be used as an actual out template parameter of functions |Clause 5.4.2 |m |n
+|403 |Sem_050402_actual_parameters_222 |verify that dash can be used as an actual out template parameter of altsteps |Clause 5.4.2 |m |n
+|404 |Sem_050402_actual_parameters_223 |verify that actual out value parameters of functions can be skipped if they are the last ones |Clause 5.4.2 |m |n
+|405 |Sem_050402_actual_parameters_224 |verify that actual `out` value parameters of altsteps can be skipped if they are the last ones |Clause 5.4.2 |m |n
+|406 |Sem_050402_actual_parameters_225 |verify that actual `out` template parameters of functions can be skipped if they are the last ones |Clause 5.4.2 |m |n
+|407 |Sem_050402_actual_parameters_226 |verify that actual `out` template parameters of altsteps can be skipped if they are the last ones |Clause 5.4.2 |m |n
+|========================================================================================================================================================================================
+
+== Cyclic definitions
+
+.Cyclic definitions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0505_cyclic_definitions_001 |Verify that an error is detected when two constants reference each other |Clause 5.5 |m |y
+|2 |NegSem_0505_cyclic_definitions_002 |Verify that an error is detected when a forbidded cyclic reference occurs in cyclic import |Clause 5.5 |m |y
+|3 |Sem_0505_cyclic_definitions_001 |The IUT correctly handles recursive functions |Clause 5.5 |m |y
+|4 |Sem_0505_cyclic_definitions_002 |The IUT correctly handles cyclic imports |Clause 5.5 |m |y
+|5 |Sem_0505_cyclic_definitions_003 |Verify that cyclic import containing cyclic function calls is allowed |Clause 5.5 |m |y
+|6 |Sem_0505_cyclic_definitions_004 |Verify that cyclic altsteps are allowed |Clause 5.5 |m |y
+|===================================================================================================================================================
+
+== Simple basic types and values
+
+.Simple basic types and values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_060100_SimpleBasicTypes_001 |Assign float to integer values |Clause 6.1.0 |m |y
+|2 |NegSyn_060100_SimpleBasicTypes_002 |Assign boolean to integer values |Clause 6.1.0 |m |y
+|3 |NegSyn_060100_SimpleBasicTypes_003 |Assign integer to float values |Clause 6.1.0 |m |y
+|4 |NegSyn_060100_SimpleBasicTypes_004 |Assign boolean to float values |Clause 6.1.0 |m |y
+|5 |NegSyn_060100_SimpleBasicTypes_005 |Assign verdicttype to float values |Clause 6.1.0 |m |y
+|6 |NegSyn_060100_SimpleBasicTypes_006 |Assign integer to verdicttype values |Clause 6.1.0 |m |y
+|7 |Sem_060100_SimpleBasicTypes_001 |Assign and read integer values |Clause 6.1.0 |m |y
+|8 |Sem_060100_SimpleBasicTypes_002 |Assign and read large integer values |Clause 6.1.0 |m |y
+|9 |Sem_060100_SimpleBasicTypes_003 |Assign and read float values |Clause 6.1.0 |m |y
+|10 |Sem_060100_SimpleBasicTypes_004 |Assign and read large float values |Clause 6.1.0 |m |y
+|11 |Sem_060100_SimpleBasicTypes_005 |Assign and read verdicts |Clause 6.1.0 |m |y
+|12 |Syn_060100_SimpleBasicTypes_001 |Assign different integer values |Clause 6.1.0 |m |y
+|13 |Syn_060100_SimpleBasicTypes_002 |Assign large integer values |Clause 6.1.0 |m |y
+|14 |Syn_060100_SimpleBasicTypes_003 |Assign different float values |Clause 6.1.0 |m |y
+|15 |Syn_060100_SimpleBasicTypes_004 |Assign small and large float values |Clause 6.1.0 |m |y
+|16 |Syn_060100_SimpleBasicTypes_005 |Accept float mantissa for float values |Clause 6.1.0 |m |y
+|17 |Syn_060100_SimpleBasicTypes_006 |Accept all verdict values |Clause 6.1.0 |m |y
+|===============================================================================================
+
+== Basic string types and values
+
+.Basic string types and values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_060101_TopLevel_001 |Assign invalid bitstring value |Clause 6.1.1 |m |y
+|2 |NegSyn_060101_TopLevel_002 |Assign string to bitstring values |Clause 6.1.1 |m |y
+|3 |NegSyn_060101_TopLevel_003 |Assign octetstring to bitstring values |Clause 6.1.1 |m |y
+|4 |NegSyn_060101_TopLevel_004 |Assign invalid hexstring value |Clause 6.1.1 |m |y
+|5 |NegSyn_060101_TopLevel_005 |Assign string to hexstring values |Clause 6.1.1 |m |y
+|6 |NegSyn_060101_TopLevel_006 |Assign octetstring to hexstring values |Clause 6.1.1 |m |y
+|7 |NegSyn_060101_TopLevel_007 |Assign invalid octetstring value |Clause 6.1.1 |m |y
+|8 |NegSyn_060101_TopLevel_008 |Assign string to octetstring values |Clause 6.1.1 |m |y
+|9 |NegSyn_060101_TopLevel_009 |Assign hexstring to octetstring values |Clause 6.1.1 |m |y
+|10 |NegSyn_060101_TopLevel_010 |Assign invalid hexstring value |Clause 6.1.1 |m |y
+|11 |Sem_060101_TopLevel_001 |Assign and read bitstring |Clause 6.1.1 |m |y
+|12 |Sem_060101_TopLevel_002 |Assign and read hexstring |Clause 6.1.1 |m |y
+|13 |Sem_060101_TopLevel_003 |Assign and read octetstring |Clause 6.1.1 |m |y
+|14 |Sem_060101_TopLevel_004 |Assign and read charstring |Clause 6.1.1 |m |y
+|15 |Sem_060101_TopLevel_005 |Assign and read universal charstring |Clause 6.1.1 |m |y
+|16 |Sem_060101_TopLevel_006 |Assign and read universal charstring |Clause 6.1.1 |m |y
+|17 |Sem_060101_TopLevel_007 |Assign and read universal charstring using USI like notation |Clause 6.1.1 |m |y
+|18 |Sem_060101_TopLevel_008 |Assign and read bitstring with newline character |Clause 6.1.1 |m |n
+|19 |Sem_060101_TopLevel_009 |Whitespaces, control characters and backslash will be ignored for the bitstring length calculation |Clause 6.1.1 |m |n
+|20 |Sem_060101_TopLevel_010 |Assign and read hexstring with newline character |Clause 6.1.1 |m |n
+|21 |Sem_060101_TopLevel_011 |Whitespaces, control characters and backslash will be ignored for the hexstring length calculation |Clause 6.1.1 |m |n
+|22 |Sem_060101_TopLevel_012 |Assign and read octetstring with newline character |Clause 6.1.1 |m |n
+|23 |Sem_060101_TopLevel_013 |Whitespaces, control characters and backslash will be ignored for the octetstring length calculation |Clause 6.1.1 |m |n
+|24 |Sem_060101_TopLevel_014 |Whitespaces and backslash character is allowed in a universal charstring |Clause 6.1.1 |m |n
+|25 |Sem_060101_TopLevel_015 |Whitespaces, control characters and backslash will be included for the universal charstring length calculation |Clause 6.1.1 |m |n
+|26 |Syn_060101_TopLevel_001 |Assign different bitstring values |Clause 6.1.1 |m |y
+|27 |Syn_060101_TopLevel_002 |Assign different hexstring values |Clause 6.1.1 |m |y
+|28 |Syn_060101_TopLevel_003 |Assign different octetstring values |Clause 6.1.1 |m |y
+|===============================================================================================================================================================
+
+== Accessing individual string elements
+
+.Accessing individual string elements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06010101_AccessStringElements_001 |Accessing not individual elements of a bitstring |Clause 6.1.1.1 |m |y
+|2 |NegSem_06010101_AccessStringElements_002 |Access bitstring element out of range |Clause 6.1.1.1 |m |y
+|3 |NegSem_06010101_AccessStringElements_003 |Accessing not individual elements of a hexstring |Clause 6.1.1.1 |m |y
+|4 |NegSem_06010101_AccessStringElements_004 |Access hexstring element out of range |Clause 6.1.1.1 |m |y
+|5 |NegSem_06010101_AccessStringElements_005 |Accessing not individual elements of an octetstring |Clause 6.1.1.1 |m |y
+|6 |NegSem_06010101_AccessStringElements_006 |Access hexstring element out of range |Clause 6.1.1.1 |m |y
+|7 |Sem_06010101_AccessStringElements_001 |Access bitstring elements |Clause 6.1.1.1 |m |y
+|8 |Sem_06010101_AccessStringElements_002 |Access octetstring elements |Clause 6.1.1.1 |m |y
+|9 |Sem_06010101_AccessStringElements_003 |Access hexstring elements |Clause 6.1.1.1 |m |y
+|10 |Sem_06010101_AccessStringElements_004 |Access bitstring elements |Clause 6.1.1.1 |m |y
+|11 |Sem_06010101_AccessStringElements_005 |Access hexstring elements |Clause 6.1.1.1 |m |y
+|12 |Sem_06010101_AccessStringElements_006 |Access octetstring elements |Clause 6.1.1.1 |m |y
+|13 |Sem_06010101_AccessStringElements_007 |Access charstring elements |Clause 6.1.1.1 |m |y
+|14 |Sem_06010101_AccessStringElements_008 |Access charstring elements |Clause 6.1.1.1 |m |y
+|15 |Sem_06010101_AccessStringElements_009 |Access charstring elements with nonprintable characters |Clause 6.1.1.1 |m |y
+|========================================================================================================================
+
+== Lists of values
+
+.Lists of values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06010201_ListOfValues_001 |Assign values to restricted bitstring. |Clause 6.1.2.1 |m |y
+|2 |NegSem_06010201_ListOfValues_002 |Assign values to restricted hexstring. |Clause 6.1.2.1 |m |y
+|3 |NegSem_06010201_ListOfValues_003 |Assign values to restricted octetstring. |Clause 6.1.2.1 |m |y
+|4 |NegSem_06010201_ListOfValues_004 |Assign values to restricted charstring. |Clause 6.1.2.1 |m |y
+|5 |NegSem_06010201_ListOfValues_005 |Assign values to restricted integer. |Clause 6.1.2.1 |m |y
+|6 |NegSem_06010201_ListOfValues_006 |Assign values to restricted float. |Clause 6.1.2.1 |m |y
+|7 |Sem_06010201_ListOfValues_001 |Assign invalid values to restricted bitstring. |Clause 6.1.2.1 |m |y
+|======================================================================================================
+
+== Lists of types
+
+.Lists of types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06010202_ListOfTypes_001 |Assign invalid values to list of types restricted bitstring. |Clause 6.1.2.2 |m |y
+|2 |NegSem_06010202_ListOfTypes_002 |Assign invalid values to list of types restricted hexstring. |Clause 6.1.2.2 |m |y
+|3 |NegSem_06010202_ListOfTypes_003 |Assign invalid values to list of types restricted octetstring. |Clause 6.1.2.2 |m |y
+|4 |NegSem_06010202_ListOfTypes_004 |Assign invalid values to list of types restricted charstring. |Clause 6.1.2.2 |m |y
+|5 |NegSem_06010202_ListOfTypes_005 |Assign invalid values to list of types restricted universal charstrings. |Clause 6.1.2.2 |m |y
+|6 |NegSem_06010202_ListOfTypes_006 |Assign invalid values to list of types restricted integers. |Clause 6.1.2.2 |m |y
+|7 |NegSem_06010202_ListOfTypes_007 |Assign invalid values to list of types restricted floats. |Clause 6.1.2.2 |m |y
+|8 |NegSem_06010202_ListOfTypes_008 |Assign invalid values to list of types restricted boolean value. |Clause 6.1.2.2 |m |y
+|9 |NegSem_06010202_ListOfTypes_009 |Assign invalid values to list of types restricted verdicttype. |Clause 6.1.2.2 |m |y
+|10 |Sem_06010202_ListOfTypes_001 |Assign values to list of types restricted bitstring. |Clause 6.1.2.2 |m |y
+|11 |Sem_06010202_ListOfTypes_002 |Assign values to list of types restricted hexstring. |Clause 6.1.2.2 |m |y
+|12 |Sem_06010202_ListOfTypes_003 |Assign values to list of types restricted octetstring. |Clause 6.1.2.2 |m |y
+|13 |Sem_06010202_ListOfTypes_004 |Assign values to list of types restricted charstring. |Clause 6.1.2.2 |m |y
+|14 |Sem_06010202_ListOfTypes_005 |Assign values to list of types unicharstring allows non-printable characters |Clause 6.1.2.2 |m |y
+|15 |Sem_06010202_ListOfTypes_006 |Assign values to list of types restricted integers. |Clause 6.1.2.2 |m |y
+|16 |Sem_06010202_ListOfTypes_007 |Assign values to list of types restricted floats. |Clause 6.1.2.2 |m |y
+|17 |Sem_06010202_ListOfTypes_008 |Assign values to list of types restricted boolean value. |Clause 6.1.2.2 |m |y
+|18 |Sem_06010202_ListOfTypes_009 |Assign values to list of types restricted verdicttype. |Clause 6.1.2.2 |m |y
+|====================================================================================================================================
+
+== Ranges
+
+.Ranges
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06010203_Ranges_001 |Assign invalid values to restricted integer. |Clause 6.1.2.3 |m |y
+|2 |NegSem_06010203_Ranges_002 |Assign invalid values to restricted integer. |Clause 6.1.2.3 |m |y
+|3 |NegSem_06010203_Ranges_003 |Assure that not_a_number is not allowed in float range subtyping. |Clause 6.1.2.3 |m |y
+|4 |NegSem_06010203_Ranges_004 |Assign invalid values to restricted integer with exclusive bounds. |Clause 6.1.2.3 |m |y
+|5 |NegSem_06010203_Ranges_005 |Assign invalid values to restricted integer with exclusive bounds. |Clause 6.1.2.3 |m |y
+|6 |NegSem_06010203_Ranges_006 |Assign range to boolean not permitted. |Clause 6.1.2.3 |m |y
+|7 |NegSem_06010203_Ranges_007 |Assign invalid value to range constrained charstring. |Clause 6.1.2.3 |m |y
+|8 |NegSem_06010203_Ranges_008 |Assign invalid value to range constrained charstring. |Clause 6.1.2.3 |m |y
+|9 |NegSem_06010203_Ranges_009 |Assign invalid value to range constrained charstring. |Clause 6.1.2.3 |m |y
+|10 |NegSem_06010203_Ranges_010 |Assign invalid values to restricted float. |Clause 6.1.2.3 |m |y
+|11 |NegSem_06010203_Ranges_011 |Assign invalid values to range restricted float. |Clause 6.1.2.3 |m |y
+|12 |NegSem_06010203_Ranges_012 |Assign invalid values to range excluded restricted float. |Clause 6.1.2.3 |m |y
+|13 |NegSem_06010203_Ranges_013 |Assign invalid value to range constrained universal charstring. |Clause 6.1.2.3 |m |y
+|14 |NegSem_06010203_Ranges_014 |Assign invalid value to range constrained universal charstring with mixed bounds. |Clause 6.1.2.3 |m |y
+|15 |NegSem_06010203_Ranges_015 |Assign invalid value to range constrained charstring. |Clause 6.1.2.3 |m |y
+|16 |NegSem_06010203_Ranges_016 |Invalid value infinity for range constrained charstring. |Clause 6.1.2.3 |m |y
+|17 |NegSem_06010203_Ranges_017 |Invalid value -infinity for range constrained charstring. |Clause 6.1.2.3 |m |y
+|18 |Sem_06010203_Ranges_001 |Assign values to range restricted integer. |Clause 6.1.2.3 |m |y
+|19 |Sem_06010203_Ranges_002 |Assign values to infinity range restricted integer. |Clause 6.1.2.3 |m |y
+|20 |Sem_06010203_Ranges_003 |Assign values to range restricted integer with exclusive bounds. |Clause 6.1.2.3 |m |y
+|21 |Sem_06010203_Ranges_004 |Assign values to range restricted cahrstring with inclusive bounds. |Clause 6.1.2.3 |m |y
+|22 |Sem_06010203_Ranges_005 |Assign values to range restricted cahrstring with exclusive bounds. |Clause 6.1.2.3 |m |y
+|23 |Sem_06010203_Ranges_006 |Assign values to range restricted cahrstring with mixed bounds. |Clause 6.1.2.3 |m |y
+|24 |Sem_06010203_Ranges_007 |Assign values to range restricted universal charstring. |Clause 6.1.2.3 |m |y
+|25 |Sem_06010203_Ranges_008 |Assign values to range restricted universal charstring with mixed bounds. |Clause 6.1.2.3 |m |y
+|=======================================================================================================================================
+
+== String length restrictions
+
+.String length restrictions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06010204_StringLengthRestrict_001 |Assign invalid values to length restricted bitstring. |Clause 6.1.2.4 |m |y
+|2 |NegSem_06010204_StringLengthRestrict_002 |Assign invalid values to length restricted bitstring. |Clause 6.1.2.4 |m |y
+|3 |NegSem_06010204_StringLengthRestrict_003 |Assign invalid values to length restricted hexstring |Clause 6.1.2.4 |m |y
+|4 |NegSem_06010204_StringLengthRestrict_004 |Assign invalid values to length restricted hexstring |Clause 6.1.2.4 |m |y
+|5 |NegSem_06010204_StringLengthRestrict_005 |Assign invalid values to length restricted octetstring |Clause 6.1.2.4 |m |y
+|6 |NegSem_06010204_StringLengthRestrict_006 |Assign invalid values to length restricted octetstring |Clause 6.1.2.4 |m |y
+|7 |NegSem_06010204_StringLengthRestrict_007 |Assign invalid values to length restricted charstring |Clause 6.1.2.4 |m |y
+|8 |NegSem_06010204_StringLengthRestrict_008 |Assign invalid values to length restricted charstring |Clause 6.1.2.4 |m |y
+|9 |NegSyn_06010204_StringLengthRestrict_001 |upper boundary should be greater than lower boundary in string lenght restictions |Clause 6.1.2.4 |m |y
+|10 |NegSyn_06010204_StringLengthRestrict_002 |boundary integers should be non negative integers |Clause 6.1.2.4 |m |y
+|11 |Sem_06010204_StringLengthRestrict_001 |Assign values to list of types restricted bitstring. |Clause 6.1.2.4 |m |y
+|12 |Sem_06010204_StringLengthRestrict_002 |Assign values to list of types restricted hexstring. |Clause 6.1.2.4 |m |y
+|13 |Sem_06010204_StringLengthRestrict_003 |Assign values to list of types restricted octetstring. |Clause 6.1.2.4 |m |y
+|14 |Sem_06010204_StringLengthRestrict_004 |Assign values to list of types restricted charstring. |Clause 6.1.2.4 |m |y
+|====================================================================================================================================================
+
+== Pattern subtyping of character string types
+
+.Pattern subtyping of character string types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06010205_StringPattern_001 |Assign invalid values to pattern restricted character strings. |Clause 6.1.2.5 |m |y
+|2 |NegSyn_06010205_StringPattern_001 |Assign values to pattern restricted character strings without `@nocase` modifier. |Clause 6.1.2.5 |m |y
+|3 |NegSyn_06010205_StringPattern_002 |Assign quadruple values to pattern restricted character strings. |Clause 6.1.2.5 |m |y
+|4 |Sem_06010205_StringPattern_001 |Assign values to pattern restricted character strings. |Clause 6.1.2.5 |m |y
+|5 |Sem_06010205_StringPattern_002 |Assign values to pattern restricted character strings. |Clause 6.1.2.5 |m |y
+|6 |Sem_06010205_StringPattern_003 |Assign values to pattern restricted character strings with `@nocase` modifier. |Clause 6.1.2.5 |m |y
+|===========================================================================================================================================
+
+== Mixing patterns, lists and ranges
+
+.Mixing patterns, lists and ranges
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0601020601_MixingSubtype_001 |Assign invalid values to mixed restricted floats. |Clause 6.1.2.6.1 |m |y
+|2 |NegSem_0601020601_MixingSubtype_002 |Assign invalid values to mixed restricted integers. |Clause 6.1.2.6.1 |m |y
+|3 |Sem_0601020601_MixingSubtype_001 |Assign values to mixed restricted floats. |Clause 6.1.2.6.1 |m |y
+|4 |Sem_0601020601_MixingSubtype_002 |Assign values to mixed restricted integers. |Clause 6.1.2.6.1 |m |y
+|===================================================================================================================
+
+== Using length restriction with other constraints
+
+.Using length restriction with other constraints
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0601020602_StringMixing_001 |Assign invalid values to mixed restricted character strings. |Clause 6.1.2.6.2 |m |y
+|2 |NegSem_0601020602_StringMixing_002 |Assign invalid values to mixed restricted character strings. |Clause 6.1.2.6.2 |m |y
+|3 |NegSem_0601020602_StringMixing_003 |Assign invalid values to mixed restricted character strings. |Clause 6.1.2.6.2 |m |y
+|4 |NegSem_0601020602_StringMixing_004 |Assign invalid values to mixed restricted bit strings. |Clause 6.1.2.6.2 |m |y
+|5 |NegSem_0601020602_StringMixing_005 |Assign invalid values to mixed restricted hex strings. |Clause 6.1.2.6.2 |m |y
+|6 |NegSem_0601020602_StringMixing_006 |Assign invalid values to mixed restricted octet strings. |Clause 6.1.2.6.2 |m |y
+|7 |Sem_0601020602_StringMixing_001 |Assign values to mixed restricted character strings. |Clause 6.1.2.6.2 |m |y
+|8 |Sem_0601020602_StringMixing_002 |Assign values to mixed restricted character strings. |Clause 6.1.2.6.2 |m |y
+|9 |Sem_0601020602_StringMixing_003 |Assign values to mixed restricted character strings. |Clause 6.1.2.6.2 |m |y
+|10 |Sem_0601020602_StringMixing_004 |Assign values to mixed restricted bit strings. |Clause 6.1.2.6.2 |m |y
+|11 |Sem_0601020602_StringMixing_005 |Assign values to mixed restricted hex strings. |Clause 6.1.2.6.2 |m |y
+|12 |Sem_0601020602_StringMixing_006 |Assign values to mixed restricted octet strings. |Clause 6.1.2.6.2 |m |y
+|13 |Sem_0601020602_StringMixing_007 |Assign values to pattern restricted character strings using `@nocase` modifier |Clause 6.1.2.6.2 |m |y
+|=========================================================================================================================================
+
+== Structured types and values
+
+.Structured types and values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0602_TopLevel_001 |Value list notation can not be used for a union type. |Clause 6.2 |m |y
+|2 |NegSem_0602_TopLevel_002 |Indexed notation can not be used for a record type. |Clause 6.2 |m |y
+|3 |NegSem_0602_TopLevel_003 |Indexed notation can not be used for a set type. |Clause 6.2 |m |y
+|4 |NegSem_0602_TopLevel_004 |Indexed notation can not be used for a union type. |Clause 6.2 |m |y
+|5 |NegSyn_0602_TopLevel_001 |Invalid recursive union type definition causing an error |Clause 6.2 |m |y
+|6 |NegSyn_0602_TopLevel_002 |Invalid recursive record type definition causing an error |Clause 6.2 |m |y
+|7 |NegSyn_0602_TopLevel_003 |Combined value list and assignment notation not allowed in the same (immediate) context. |Clause 6.2 |m |y
+|8 |NegSyn_0602_TopLevel_004 |Combined value list and assignment notation not allowed in the same (immediate) context. |Clause 6.2 |m |y
+|9 |NegSyn_0602_TopLevel_005 |Combined value list and assignment notation not allowed in the same (immediate) context. |Clause 6.2 |m |y
+|10 |NegSyn_0602_TopLevel_006 |Combined value list and assignment notation not allowed in the same (immediate) context. |Clause 6.2 |m |y
+|11 |NegSyn_0602_TopLevel_007 |Combined value list and assignment notation not allowed in the same (immediate) context. |Clause 6.2 |m |y
+|12 |Sem_0602_TopLevel_001 |Assignment notation can be used for a record type. |Clause 6.2 |m |y
+|13 |Sem_0602_TopLevel_002 |Assignment notation can be used for a record of type. |Clause 6.2 |m |y
+|14 |Sem_0602_TopLevel_003 |Assignment notation can be used for a set type. |Clause 6.2 |m |y
+|15 |Sem_0602_TopLevel_004 |Assignment notation can be used for a set of type. |Clause 6.2 |m |y
+|16 |Sem_0602_TopLevel_005 |Assignment notation can be used for a union type. |Clause 6.2 |m |y
+|17 |Sem_0602_TopLevel_006 |Assignment notation can be used for an array. |Clause 6.2 |m |y
+|18 |Sem_0602_TopLevel_007 |Value list notation can be used for a record type. |Clause 6.2 |m |y
+|19 |Sem_0602_TopLevel_008 |Value list notation can be used for a record of type. |Clause 6.2 |m |y
+|20 |Sem_0602_TopLevel_009 |Indexed notation can be used for an arrays. |Clause 6.2 |m |y
+|21 |Sem_0602_TopLevel_010 |Value list notation can be used for a set of type. |Clause 6.2 |m |y
+|22 |Sem_0602_TopLevel_011 |Value list notation can be used for an array. |Clause 6.2 |m |y
+|23 |Sem_0602_TopLevel_012 |Indexed notation can be used for a record of type. |Clause 6.2 |m |y
+|24 |Sem_0602_TopLevel_013 |Indexed notation can be used for a set of type. |Clause 6.2 |m |y
+|25 |Sem_0602_TopLevel_014 |Value list notation can be used for a set type and the values |Clause 6.2 |m |n
+|26 |Syn_0602_TopLevel_001 |Valid recursive union type definition |Clause 6.2 |m |y
+|27 |Syn_0602_TopLevel_002 |Valid recursive record type definition |Clause 6.2 |m |y
+|28 |Syn_0602_TopLevel_003 |Valid recursive record type definition |Clause 6.2 |m |y
+|29 |Syn_0602_TopLevel_004 |constant definition of a record type. |Clause 6.2 |m |y
+|30 |Syn_0602_TopLevel_005 |Fields not mentioned are implicitly left unspecified. |Clause 6.2 |m |y
+|========================================================================================================================================
+
+== Record type and values
+
+.Record type and values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_060201_RecordTypeValues_001 |The omit keyword shall not be used for mandatory fields. |Clause 6.2.1 |m |y
+|2 |NegSyn_060201_RecordTypeValues_002 |The omit keyword shall not be used for mandatory fields. |Clause 6.2.1 |m |y
+|3 |Sem_060201_RecordTypeValues_001 |Assignments with `implicit omit` attribute are correctly handled |Clause 6.2.1 |m |y
+|4 |Sem_060201_RecordTypeValues_002 |Assignments with `implicit omit` attribute are correctly handled |Clause 6.2.1 |m |y
+|5 |Sem_060201_RecordTypeValues_003 |Assignments with `implicit omit` attribute are correctly handled |Clause 6.2.1 |m |y
+|6 |Syn_060201_RecordTypeValues_001 |The element identifiers are local to the record and shall be unique within the record (but do not have to be globally unique). |Clause 6.2.1 |m |y
+|7 |Syn_060201_RecordTypeValues_002 |The IUT correctly handles empty record definitions. |Clause 6.2.1 |m |y
+|8 |NegSyn_060202_SetTypeValues_001 |The omit keyword shall not be used for mandatory fields. |Clause 6.2.1 |m |y
+|9 |NegSyn_060202_SetTypeValues_002 |The omit keyword shall not be used for mandatory fields. |Clause 6.2.1 |m |y
+|10 |Sem_060202_SetTypeValues_005 |Assignments with `implicit omit` attribute are correctly handled |Clause 6.2.1 |m |y
+|11 |Sem_060202_SetTypeValues_006 |Assignments with `implicit omit` attribute are correctly handled |Clause 6.2.1 |m |y
+|12 |Sem_060202_SetTypeValues_007 |Assignments with `implicit omit` attribute are correctly handled |Clause 6.2.1 |m |y
+|======================================================================================================================================================================================
+
+== Referencing fields of a record type
+
+.Referencing fields of a record type
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06020101_ReferencingRecordFields_001 |The dot notation used in record type definitions is correctly handled |Clause 6.2.1.1 |m |y
+|2 |NegSem_06020101_ReferencingRecordFields_002 |verify that record fields cannot reference themselves |Clause 6.2.1.1 |m |y
+|3 |NegSem_06020101_ReferencingRecordFields_003 |verify that referencing uninitialized record on the right hand of an assignment is not allowed |Clause 6.2.1.1 |m |y
+|4 |NegSem_06020101_ReferencingRecordFields_004 |verify that referencing omitted record on the right hand of an assignment is not allowed |Clause 6.2.1.1 |m |y
+|5 |Sem_06020101_ReferencingRecordFields_001 |The dot notation used in record type definitions is correctly handled |Clause 6.2.1.1 |m |y
+|6 |Sem_06020101_ReferencingRecordFields_002 |The dot notation used in record type definitions is correctly handled |Clause 6.2.1.1 |m |y
+|7 |Sem_06020101_ReferencingRecordFields_003 |The dot notation used in record type definitions is correctly handled |Clause 6.2.1.1 |m |y
+|8 |Sem_06020101_ReferencingRecordFields_004 |The dot notation used in record type definitions is correctly handled |Clause 6.2.1.1 |m |y
+|9 |Sem_06020101_ReferencingRecordFields_005 |verify that dot notation can be used for referencing elements on the right hand side of an assignement |Clause 6.2.1.1 |m |y
+|10 |Sem_06020101_ReferencingRecordFields_006 |verify that dot notation can be used for referencing sub-elements on the right hand side of an assignement |Clause 6.2.1.1 |m |y
+|11 |Sem_06020101_ReferencingRecordFields_007 |verify that dot notation can be used for referencing function invocation results |Clause 6.2.1.1 |m |y
+|12 |Sem_06020101_ReferencingRecordFields_008 |verify that mandatory fields are created and uninitialized when expanding uninitialized record values |Clause 6.2.1.1 |m |y
+|13 |Sem_06020101_ReferencingRecordFields_009 |verify that optional fields are created and uninitialized when expanding uninitialized record values (explicit omit) |Clause 6.2.1.1 |m |y
+|14 |Sem_06020101_ReferencingRecordFields_010 |verify that optional fields are created and omitted when expanding uninitialized record values (implicit omit) |Clause 6.2.1.1 |m |n
+|15 |Sem_06020101_ReferencingRecordFields_011 |verify that referencing fields nested deep inside uninitialized record invokes expansion |Clause 6.2.1.1 |m |y
+|16 |Sem_06020101_ReferencingRecordFields_012 |verify that expansion of uninitialized record values works when other constructive types are involved |Clause 6.2.1.1 |m |y
+|17 |Sem_06020101_ReferencingRecordFields_013 |verify that mandatory fields are created and uninitialized when expanding omitted record values |Clause 6.2.1.1 |m |y
+|18 |Sem_06020101_ReferencingRecordFields_014 |verify that optional fields are created and uninitialized when expanding omitted record values (explicit omit) |Clause 6.2.1.1 |m |y
+|19 |Sem_06020101_ReferencingRecordFields_015 |verify that optional fields are created and omitted when expanding omitted record values (implicit omit) |Clause 6.2.1.1 |m |n
+|20 |Sem_06020101_ReferencingRecordFields_016 |verify that referencing fields nested deep inside omitted record invokes expansion |Clause 6.2.1.1 |m |y
+|21 |Sem_06020101_ReferencingRecordFields_017 |verify that expansion of omitted record values works when other constructive types are involved |Clause 6.2.1.1 |m |y
+|========================================================================================================================================================================================
+
+== Set type and values
+
+.Set type and values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060202_SetTypeValues_001 |The dot notation used in set type definitions is correctly handled |Clause 6.2.2 |m |y
+|2 |Sem_060202_SetTypeValues_001 |The dot notation used in set type definitions is correctly handled |Clause 6.2.2 |m |y
+|3 |Sem_060202_SetTypeValues_002 |The dot notation used in set type definitions is correctly handled |Clause 6.2.2 |m |y
+|4 |Sem_060202_SetTypeValues_003 |The dot notation used in set type definitions is correctly handled |Clause 6.2.2 |m |y
+|5 |Sem_060202_SetTypeValues_004 |The dot notation used in set type definitions is correctly handled |Clause 6.2.2 |m |y
+|6 |Syn_060202_SetTypeValues_001 |The element identifiers are local to the set and shall be unique within the record (but do not have to be globally unique). |Clause 6.2.2 |m |y
+|7 |Syn_060202_SetTypeValues_002 |The IUT correctly handles empty set definitions. |Clause 6.2.2 |m |y
+|================================================================================================================================================================================
+
+== Records and sets of single types
+
+.Records and sets of single types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060203_records_and_sets_of_single_types_003 |negative index applied to a record of value on the right hand side of an assignment |Clause 6.2.3 |m |y
+|2 |NegSem_060203_records_and_sets_of_single_types_004 |negative index applied to a set of value on the right hand side of an assignment |Clause 6.2.3 |m |y
+|3 |NegSem_060203_records_and_sets_of_single_types_005 |negative index applied to a record of value on the left hand side of an assignment |Clause 6.2.3 |m |y
+|4 |NegSem_060203_records_and_sets_of_single_types_006 |negative index applied to a set of value on the left hand side of an assignment |Clause 6.2.3 |m |y
+|5 |NegSem_060203_records_and_sets_of_single_types_007 |wrong index type applied to a record of value on the right hand side of an assignment |Clause 6.2.3 |m |y
+|6 |NegSem_060203_records_and_sets_of_single_types_008 |wrong index type applied to a set of value on the right hand side of an assignment |Clause 6.2.3 |m |y
+|7 |NegSem_060203_records_and_sets_of_single_types_009 |wrong index type applied to a record of value on the left hand side of an assignment |Clause 6.2.3 |m |y
+|8 |NegSem_060203_records_and_sets_of_single_types_016 |array as a record-of value index on right hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|9 |NegSem_060203_records_and_sets_of_single_types_017 |array as a record-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|10 |NegSem_060203_records_and_sets_of_single_types_018 |fixed-size record-of as a record-of value index on right hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|11 |NegSem_060203_records_and_sets_of_single_types_019 |fixed-size record-of as a record-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|12 |NegSem_060203_records_and_sets_of_single_types_020 |fixed-size set-of as a record-of value index on right hand side |Clause 6.2.3 |m |y
+|13 |NegSem_060203_records_and_sets_of_single_types_021 |fixed-size set-of as a record-of value index on left hand side |Clause 6.2.3 |m |y
+|14 |NegSem_060203_records_and_sets_of_single_types_022 |variable-size record-of as a record-of value index on right hand side |Clause 6.2.3 |m |y
+|15 |NegSem_060203_records_and_sets_of_single_types_023 |variable-size record-of as a record-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|16 |Sem_060203_records_and_sets_of_single_types_020 |referencing non-existent element of set of value (left-hand side) |Clause 6.2.3 |m |y
+|17 |Sem_060203_records_and_sets_of_single_types_021 |referencing element of uninitialized record of value (left-hand side) |Clause 6.2.3 |m |y
+|18 |Sem_060203_records_and_sets_of_single_types_022 |referencing element of uninitialized set of value (left-hand side) |Clause 6.2.3 |m |y
+|19 |Sem_060203_records_and_sets_of_single_types_023 |array as a record-of value index on right hand side (dimensions match) |Clause 6.2.3 |m |y
+|20 |Sem_060203_records_and_sets_of_single_types_024 |array as a record-of value index on left hand side (dimensions match) |Clause 6.2.3 |m |y
+|21 |Sem_060203_records_and_sets_of_single_types_025 |array as a record-of value index on right hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|22 |Sem_060203_records_and_sets_of_single_types_026 |array as a record-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|23 |Sem_060203_records_and_sets_of_single_types_027 |fixed-size record-of as a record-of value index on right hand side (dimensions match) |Clause 6.2.3 |m |y
+|24 |Sem_060203_records_and_sets_of_single_types_028 |fixed-size record-of as a record-of value index on left hand side (dimensions match) |Clause 6.2.3 |m |y
+|25 |Sem_060203_records_and_sets_of_single_types_029 |fixed-size record-of as a record-of value index on right hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|26 |Sem_060203_records_and_sets_of_single_types_030 |fixed-size record-of as a record-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|27 |Sem_060203_records_and_sets_of_single_types_031 |array as a set-of value index on right hand side (dimensions match) |Clause 6.2.3 |m |y
+|28 |Sem_060203_records_and_sets_of_single_types_032 |array as a set-of value index on left hand side (dimensions match) |Clause 6.2.3 |m |y
+|29 |Sem_060203_records_and_sets_of_single_types_033 |array as a set-of value index on right hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|30 |Sem_060203_records_and_sets_of_single_types_034 |array as a set-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|31 |Sem_060203_records_and_sets_of_single_types_035 |fixed-size set-of as a record-of value index on right hand side (dimensions match) |Clause 6.2.3 |m |y
+|32 |Sem_060203_records_and_sets_of_single_types_036 |fixed-size set-of as a record-of value index on left hand side (dimensions match) |Clause 6.2.3 |m |y
+|33 |Sem_060203_records_and_sets_of_single_types_037 |fixed-size set-of as a record-of value index on right hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|34 |Sem_060203_records_and_sets_of_single_types_038 |fixed-size record-of as a set-of value index on left hand side (less items than record-of dimension) |Clause 6.2.3 |m |y
+|======================================================================================================================================================================================
+
+== Referencing elements of record of and set of types
+
+.Referencing elements of record of and set of types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060203_records_and_sets_of_single_types_001 |ensure that the inner type referencing is correctly handled |Clause 6.2.3.2 |m |y
+|2 |NegSem_060203_records_and_sets_of_single_types_002 |ensure that the inner type referencing is correctly handled |Clause 6.2.3.2 |m |y
+|3 |NegSem_060203_records_and_sets_of_single_types_010 |wrong index type applied to a set of value on the left hand side of an assignment |Clause 6.2.3.2 |m |y
+|4 |NegSem_060203_records_and_sets_of_single_types_011 |record of index greater than the upper bound (left-hand side) |Clause 6.2.3.2 |m |n
+|5 |NegSem_060203_records_and_sets_of_single_types_012 |set of index greater than the upper bound (left-hand side) |Clause 6.2.3.2 |m |n
+|6 |NegSem_060203_records_and_sets_of_single_types_013 |wrong index type applied to a record of value on the right hand side of an assignment |Clause 6.2.3.2 |m |y
+|7 |NegSem_060203_records_and_sets_of_single_types_014 |wrong index type applied to a record of value on the right hand side of an assignment |Clause 6.2.3.2 |m |y
+|8 |NegSem_060203_records_and_sets_of_single_types_015 |verify than an error is generated when sending a partially initialized record of value |Clause 6.2.3.2 |m |y
+|9 |NegSyn_060203_records_and_sets_of_single_types_001 |ensure that value list cannot contain an empty assignment |Clause 6.2.3.2 |m |y
+|10 |Sem_060203_records_and_sets_of_single_types_001 |ensure that the inner type referencing is correctly handled |Clause 6.2.3.2 |m |y
+|11 |Sem_060203_records_and_sets_of_single_types_002 |verify assignment of explicitly identified elements to record of values |Clause 6.2.3.2 |m |n
+|12 |Sem_060203_records_and_sets_of_single_types_003 |verify assignment of explicitly identified elements to set of values |Clause 6.2.3.2 |m |n
+|13 |Sem_060203_records_and_sets_of_single_types_004 |verify handling of missing elements in assignment notation for record of values |Clause 6.2.3.2 |m |y
+|14 |Sem_060203_records_and_sets_of_single_types_005 |verify handling of missing elements in assignment notation for set of values |Clause 6.2.3.2 |m |y
+|15 |Sem_060203_records_and_sets_of_single_types_006 |verify handling of missing and ignored elements during record of value re-assignment |Clause 6.2.3.2 |m |n
+|16 |Sem_060203_records_and_sets_of_single_types_007 |verify handling of missing and ignored elements during record of value re-assignment |Clause 6.2.3.2 |m |n
+|17 |Sem_060203_records_and_sets_of_single_types_008 |verify handling of value list assignment used for initialization of record of values |Clause 6.2.3.2 |m |y
+|18 |Sem_060203_records_and_sets_of_single_types_009 |verify handling of value list assignment used for initialization of set of values |Clause 6.2.3.2 |m |y
+|19 |Sem_060203_records_and_sets_of_single_types_010 |verify handling of value list assignment used for update of record of values |Clause 6.2.3.2 |m |y
+|20 |Sem_060203_records_and_sets_of_single_types_011 |verify handling of value list assignment used for update of set of values |Clause 6.2.3.2 |m |y
+|21 |Sem_060203_records_and_sets_of_single_types_012 |verify handling of index notation applied to record of values on right-hand side |Clause 6.2.3.2 |m |y
+|22 |Sem_060203_records_and_sets_of_single_types_013 |verify handling of index notation applied to set of values on right-hand side |Clause 6.2.3.2 |m |y
+|23 |Sem_060203_records_and_sets_of_single_types_014 |verify handling of index notation applied to record of values on left-hand side |Clause 6.2.3.2 |m |y
+|24 |Sem_060203_records_and_sets_of_single_types_015 |verify handling of index notation applied to set of values on left-hand side |Clause 6.2.3.2 |m |y
+|25 |Sem_060203_records_and_sets_of_single_types_016 |verify the first element of a record of value is accessible by an index notation |Clause 6.2.3.2 |m |y
+|26 |Sem_060203_records_and_sets_of_single_types_017 |verify the first element of a set of value is accessible by an index notation |Clause 6.2.3.2 |m |y
+|27 |Sem_060203_records_and_sets_of_single_types_019 |referencing non-existent element of record of value (left-hand side) |Clause 6.2.3.2 |m |y
+|===================================================================================================================================================================
+
+== Enumerated type and values
+
+.Enumerated type and values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060204_enumerated_type_and_values_001 |not unique identifiers in enumerated type declaration |Clause 6.2.4 |m |y
+|2 |NegSem_060204_enumerated_type_and_values_002 |two equal user-assigned enumerated values |Clause 6.2.4 |m |y
+|3 |NegSem_060204_enumerated_type_and_values_003 |using enumerated value number directly (left hand side of assignments) |Clause 6.2.4 |m |y
+|4 |NegSem_060204_enumerated_type_and_values_004 |using enumerated value number directly (right hand side of assignments) |Clause 6.2.4 |m |y
+|5 |NegSem_060204_enumerated_type_and_values_005 |using enumerated value without implicit or explicit type reference |Clause 6.2.4 |m |y
+|6 |NegSem_060204_enumerated_type_and_values_006 |modulepar with the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |n
+|7 |NegSem_060204_enumerated_type_and_values_007 |formal parameter with the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |n
+|8 |NegSem_060204_enumerated_type_and_values_008 |constant with the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |n
+|9 |NegSem_060204_enumerated_type_and_values_009 |variable with the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |n
+|10 |NegSem_060204_enumerated_type_and_values_010 |template with the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |n
+|11 |NegSem_060204_enumerated_type_and_values_011 |parameterized template with default parameters and the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |n
+|12 |NegSem_060204_enumerated_type_and_values_012 |using enumerated value number integer conversion |Clause 6.2.4 |m |y
+|13 |NegSyn_060204_enumerated_type_and_values_001 |expression as user-assigned enumerated value |Clause 6.2.4 |m |y
+|14 |Sem_060204_enumerated_type_and_values_001 |reusing enumerated value identifier in another enumerated type declaration |Clause 6.2.4 |m |y
+|15 |Sem_060204_enumerated_type_and_values_002 |automatic numbering of enumerated items |Clause 6.2.4 |m |y
+|16 |Sem_060204_enumerated_type_and_values_003 |explicit numbering of enumerated items |Clause 6.2.4 |m |y
+|17 |Sem_060204_enumerated_type_and_values_004 |mixed automatic and explicit numbering of enumerated items |Clause 6.2.4 |m |y
+|18 |Sem_060204_enumerated_type_and_values_005 |using enumerated value with implicit type reference |Clause 6.2.4 |m |y
+|19 |Sem_060204_enumerated_type_and_values_006 |parameterized template without default parameters and with the same name as one of enumerated values of the imported parent type |Clause 6.2.4 |m |y
+|20 |Sem_060204_enumerated_type_and_values_007 |mixed automatic and explicit numbering of enumerated items |Clause 6.2.4 |m |n
+|21 |Syn_060204_enumerated_type_and_values_001 |enumerated type declaration |Clause 6.2.4 |m |y
+|22 |Syn_060204_enumerated_type_and_values_002 |enumerated type declaration with user-assigned values |Clause 6.2.4 |m |y
+|23 |Syn_060204_enumerated_type_and_values_003 |constant as user-assigned enumerated values |Clause 6.2.4 |m |y
+|24 |Syn_060204_enumerated_type_and_values_004 |expression as user-assigned enumerated value |Clause 6.2.4 |m |y
+|===================================================================================================================================================================================================
+
+== Unions
+
+.Unions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_06020503_nested_type_definition_for_field_types_001 |union type declaration |Clause 6.2.5 |m |y
+|2 |NegSem_060205_top_level_001 |assignment notation for union values with two items |Clause 6.2.5 |m |y
+|3 |NegSem_060205_top_level_002 |assignment notation for union values with unknown alternative |Clause 6.2.5 |m |y
+|4 |NegSem_060205_top_level_003 |``not used'' symbol in union value notations |Clause 6.2.5 |m |y
+|5 |NegSem_060205_top_level_004 |omit symbol in union value notations |Clause 6.2.5 |m |y
+|6 |NegSem_060205_top_level_005 |value list notation used for union value definition |Clause 6.2.5 |m |y
+|7 |NegSyn_060205_top_level_001 |union type declaration with two equal identifiers |Clause 6.2.5 |m |y
+|8 |Sem_060205_top_level_001 |assignment notation for union values |Clause 6.2.5 |m |y
+|9 |Syn_060205_top_level_001 |union type declaration |Clause 6.2.5 |m |y
+|10 |Syn_060205_top_level_002 |union type declaration with single item |Clause 6.2.5 |m |y
+|=================================================================================================================
+
+== Referencing fields of a union type
+
+.Referencing fields of a union type
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06020501_referencing_fields_of_union_type_001 |unknown union alternative in value dot notation |Clause 6.2.5.1 |m |y
+|2 |NegSem_06020501_referencing_fields_of_union_type_002 |unknown union alternative in extended type reference |Clause 6.2.5.1 |m |y
+|3 |NegSem_06020501_referencing_fields_of_union_type_003 |union alternative referencing itself |Clause 6.2.5.1 |m |y
+|4 |NegSem_06020501_referencing_fields_of_union_type_004 |union alternative referencing indirectly itself |Clause 6.2.5.1 |m |y
+|5 |NegSem_06020501_referencing_fields_of_union_type_005 |union alternative costraint passed through extended type reference |Clause 6.2.5.1 |m |y
+|6 |NegSem_06020501_referencing_fields_of_union_type_006 |referencing not chosen alternative on right hand side of assignment |Clause 6.2.5.1 |m |y
+|7 |NegSem_06020501_referencing_fields_of_union_type_007 |referencing alternative of uninitialized union on right hand side of assignment |Clause 6.2.5.1 |m |y
+|8 |NegSem_06020501_referencing_fields_of_union_type_008 |referencing alternative of omitted union on right hand side of assignment |Clause 6.2.5.1 |m |y
+|9 |Sem_06020501_referencing_fields_of_union_type_001 |ensure that union is initialized by dot notation |Clause 6.2.5.1 |m |y
+|10 |Sem_06020501_referencing_fields_of_union_type_002 |union alternative in extended type reference |Clause 6.2.5.1 |m |y
+|11 |Sem_06020501_referencing_fields_of_union_type_003 |union costraint not applied to extended type reference to its item |Clause 6.2.5.1 |m |y
+|12 |Sem_06020501_referencing_fields_of_union_type_004 |referencing alternative on left hand side of assignment |Clause 6.2.5.1 |m |y
+|13 |Sem_06020501_referencing_fields_of_union_type_005 |referencing nested alternative on left hand side of assignment |Clause 6.2.5.1 |m |y
+|14 |Sem_06020501_referencing_fields_of_union_type_006 |referencing field of structured alternative on left hand side of assignment |Clause 6.2.5.1 |m |y
+|15 |Sem_06020501_referencing_fields_of_union_type_007 |union is initialized by anytype dot notation |Clause 6.2.5.1 |m |y
+|16 |Sem_06020501_referencing_fields_of_union_type_008 |union is initialized by anytype dot notation |Clause 6.2.5.1 |m |y
+|==============================================================================================================================================================
+
+== Option and union
+
+.Option and union
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_06020502_option_and_union_001 |referencing alternative on left hand side of assignment |Clause 6.2.5.2 |m |y
+|======================================================================================================================
+
+== Anytype
+
+.Anytype
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060206_anytype_001 |ensure that after redeclaration of an anytype value the old type and value are lost |Clause 6.2.6 |m |y
+|2 |NegSem_060206_anytype_002 |Ensure that anytype can not be address type if not explicitly declareted in the module |Clause 6.2.6 |m |y
+|3 |NegSyn_060206_anytype_001 |ensure that anytype can not be a default type |Clause 6.2.6 |m |n
+|4 |NegSyn_060206_anytype_002 |ensure that anytype cannot be port type |Clause 6.2.6 |m |y
+|5 |NegSyn_060206_anytype_003 |ensure that component type not allowed for anytype |Clause 6.2.6 |m |n
+|6 |Sem_060206_anytype_001 |ensure that anytype comprise integer data type |Clause 6.2.6 |m |y
+|7 |Sem_060206_anytype_002 |ensure that anytype comprise float data type |Clause 6.2.6 |m |y
+|8 |Sem_060206_anytype_003 |ensure that anytype comprise boolean data type |Clause 6.2.6 |m |y
+|9 |Sem_060206_anytype_004 |ensure that anytype comprise verdicttype data type |Clause 6.2.6 |m |y
+|10 |Sem_060206_anytype_005 |ensure that anytype comprise bitstring and hexstring data type |Clause 6.2.6 |m |y
+|11 |Sem_060206_anytype_006 |ensure that ensure that anytype comprise octetstring and charstring |Clause 6.2.6 |m |y
+|12 |Sem_060206_anytype_007 |ensure that ensure that anytype comprise universal charstring |Clause 6.2.6 |m |y
+|13 |Sem_060206_anytype_008 |ensure that anytype is a valid value inside an union |Clause 6.2.6 |m |y
+|14 |Sem_060206_anytype_009 |ensure that record values can be anytype |Clause 6.2.6 |m |y
+|15 |Sem_060206_anytype_010 |ensure that anytype can be an enum type |Clause 6.2.6 |m |y
+|16 |Sem_060206_anytype_011 |ensure that anytype can have an set value and set value can be anytype |Clause 6.2.6 |m |y
+|17 |Sem_060206_anytype_012 |ensure that redeclaration of an anytype value works properly |Clause 6.2.6 |m |y
+|18 |Sem_060206_anytype_013 |ensure that address type is included to anytype |Clause 6.2.6 |m |y
+|19 |Sem_060206_anytype_014 |ensure that anytype can be record type |Clause 6.2.6 |m |y
+|20 |Sem_060206_anytype_015 |ensure that anytype can act as a set type |Clause 6.2.6 |m |y
+|21 |Sem_060206_anytype_016 |ensure that anytype can act as an union |Clause 6.2.6 |m |y
+|22 |Sem_060206_anytype_017 |ensure that anytype can comprise array type |Clause 6.2.6 |m |y
+|23 |Sem_060206_anytype_018 |ensure that anytype can comprise set of and record of types |Clause 6.2.6 |m |y
+|24 |Sem_060206_anytype_019 |ensure that anytype can be imported from another module |Clause 6.2.6 |m |y
+|========================================================================================================================================
+
+== Arrays
+
+.Arrays
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060207_arrays_001 |ensure that the value limitation is correctly handled within array |Clause 6.2.7 |m |y
+|2 |NegSem_060207_arrays_002 |ensure that the inner type referencing is correctly handled |Clause 6.2.7 |m |y
+|3 |NegSem_060207_arrays_003 |negative index applied to an array on the right hand side of an assignment |Clause 6.2.7 |m |y
+|4 |NegSem_060207_arrays_004 |negative index applied to an array on the left hand side of an assignment |Clause 6.2.7 |m |y
+|5 |NegSem_060207_arrays_005 |wrong index type applied to an array on the right hand side of an assignment |Clause 6.2.7 |m |y
+|6 |NegSem_060207_arrays_006 |wrong index type applied to an array on the left hand side of an assignment |Clause 6.2.7 |m |y
+|7 |NegSem_060207_arrays_007 |array index greater than the upper bound (left-hand side) |Clause 6.2.7 |m |y
+|8 |NegSem_060207_arrays_008 |wrong index type applied to an array on the right hand side of an assignment |Clause 6.2.7 |m |y
+|9 |NegSem_060207_arrays_009 |verify than an error is generated when sending a partially initialized array |Clause 6.2.7 |m |y
+|10 |NegSem_060207_arrays_010 |ensure that the value limitation is correctly handled within array |Clause 6.2.7 |m |y
+|11 |NegSem_060207_arrays_011 |runtime resolved constant in array type declaration |Clause 6.2.7 |m |y
+|12 |NegSem_060207_arrays_012 |runtime resolved constant in array variable declaration |Clause 6.2.7 |m |y
+|13 |NegSem_060207_arrays_013 |variable in array variable declaration |Clause 6.2.7 |m |y
+|14 |NegSem_060207_arrays_014 |modulepar in array variable declaration |Clause 6.2.7 |m |y
+|15 |NegSem_060207_arrays_015 |zero dimension array |Clause 6.2.7 |m |y
+|16 |NegSem_060207_arrays_016 |array with negative dimension |Clause 6.2.7 |m |y
+|17 |NegSem_060207_arrays_017 |zero in array dimension (range notation) |Clause 6.2.7 |m |n
+|18 |NegSem_060207_arrays_018 |negative value in array dimension (range notation) |Clause 6.2.7 |m |n
+|19 |NegSem_060207_arrays_019 |float instead of integer in array dimension |Clause 6.2.7 |m |y
+|20 |NegSem_060207_arrays_020 |integer array with too many items as multidimensional array index |Clause 6.2.7 |m |y
+|21 |NegSem_060207_arrays_021 |variable-size record of integer as multidimensional array index |Clause 6.2.7 |m |y
+|22 |NegSem_060207_arrays_022 |using lower than allowed custom array index on the right hand side of assignments |Clause 6.2.7 |m |y
+|23 |NegSem_060207_arrays_023 |using lower than allowed custom array index on the left hand side of assignments |Clause 6.2.7 |m |y
+|24 |NegSem_060207_arrays_024 |using greater than allowed custom array index on the right hand side of assignments |Clause 6.2.7 |m |y
+|25 |NegSem_060207_arrays_025 |using greater than allowed custom array index on the left hand side of assignments |Clause 6.2.7 |m |y
+|26 |NegSem_060207_arrays_026 |referencing uninitialized array element on the right hand side of assignments |Clause 6.2.7 |m |y
+|27 |NegSem_060207_arrays_027 |referencing element of uninitialized arrays on the right hand side of assignments |Clause 6.2.7 |m |y
+|28 |NegSem_060207_arrays_028 |referencing element of omitted arrays on the right hand side of assignments |Clause 6.2.7 |m |y
+|29 |NegSyn_060207_arrays_001 |ensure that array cannot contain an empty assignment |Clause 6.2.7 |m |y
+|30 |NegSyn_060207_arrays_002 |ensure that array field cannot contain an empty index |Clause 6.2.7 |m |y
+|31 |NegSyn_060207_arrays_003 |ensure that array field cannot contain an empty index |Clause 6.2.7 |m |y
+|32 |NegSyn_060207_arrays_004 |infinity in array variable dimension |Clause 6.2.7 |m |y
+|33 |NegSyn_060207_arrays_005 |arrays upper value shall not be lesser than the corresponding lower value |Clause 6.2.7 |m |y
+|34 |Sem_060207_arrays_001 |verify that value list notation can be used for an array |Clause 6.2.7 |m |y
+|35 |Sem_060207_arrays_002 |verify assignment of explicitly identified elements to arrays |Clause 6.2.7 |m |n
+|36 |Sem_060207_arrays_003 |verify handling of missing elements in assignment notation for arrays |Clause 6.2.7 |m |y
+|37 |Sem_060207_arrays_004 |verify handling of missing and ignored elements during an array re-assignment |Clause 6.2.7 |m |n
+|38 |Sem_060207_arrays_005 |verify handling of value list assignment used for initialization of arrays |Clause 6.2.7 |m |y
+|39 |Sem_060207_arrays_006 |verify handling of value list assignment used for update of arrays |Clause 6.2.7 |m |y
+|40 |Sem_060207_arrays_007 |verify handling of index notation applied to array on right-hand side |Clause 6.2.7 |m |y
+|41 |Sem_060207_arrays_008 |verify handling of index notation applied to array on left-hand side |Clause 6.2.7 |m |y
+|42 |Sem_060207_arrays_009 |verify the first element of an array is accessible by an index notation |Clause 6.2.3.2 |m |y
+|43 |Sem_060207_arrays_010 |verify that arrays can be used to specify record of type and they are compatible |Clause 6.2.7 |m |y
+|44 |Sem_060207_arrays_011 |index notation applied to omitted array field on left hand side of assignment |Clause 6.2.7 |m |y
+|45 |Sem_060207_arrays_012 |referencing element of uninitialized array (left-hand side) |Clause 6.2.7 |m |y
+|46 |Sem_060207_arrays_013 |ensure that the two dimensional array type referencing is correctly handled |Clause 6.2.7 |m |y
+|47 |Sem_060207_arrays_014 |verify assignment of explicitly identified elements to two dimensional array |Clause 6.2.7 |m |y
+|48 |Sem_060207_arrays_015 |constant expression in array dimension |Clause 6.2.7 |m |y
+|49 |Sem_060207_arrays_016 |predefined function in array dimension |Clause 6.2.7 |m |y
+|50 |Sem_060207_arrays_017 |integer array as multidimensional array index |Clause 6.2.7 |m |y
+|51 |Sem_060207_arrays_018 |fixed-size record of integer as multidimensional array index |Clause 6.2.7 |m |y
+|52 |Sem_060207_arrays_019 |integer array as multidimensional array index (less items than dimension count) |Clause 6.2.7 |m |y
+|53 |Sem_060207_arrays_020 |using custom array index on the right hand side of assignments |Clause 6.2.7 |m |y
+|54 |Sem_060207_arrays_021 |using custom array index on the left hand side of assignments |Clause 6.2.7 |m |y
+|55 |Sem_060207_arrays_022 |using less indexes than array dimensions on the right hand side of assignments |Clause 6.2.7 |m |y
+|56 |Sem_060207_arrays_023 |using less indexes than array dimensions on the left hand side of assignments |Clause 6.2.7 |m |y
+|57 |Syn_060207_arrays_001 |array specified in variable declaration |Clause 6.2.7 |m |y
+|58 |Syn_060207_arrays_002 |multidimensional array type declaration |Clause 6.2.7 |m |y
+|59 |Syn_060207_arrays_003 |multidimensional array specified in variable declaration |Clause 6.2.7 |m |y
+|60 |Syn_060207_arrays_004 |array type dimension specified as a range |Clause 6.2.7 |m |y
+|61 |Syn_060207_arrays_005 |multiple array type dimensions specified as a range |Clause 6.2.7 |m |y
+|62 |Syn_060207_arrays_006 |array variable dimension specified as a range |Clause 6.2.7 |m |y
+|63 |Syn_060207_arrays_007 |multiple array variable dimensions specified as a range |Clause 6.2.7 |m |y
+|=====================================================================================================================================
+
+== The default type
+
+.The default type
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_060208_default_type_001 |verify than a reference to an activated default can be assigned to a default variable |Clause 6.2.8 |m |y
+|2 |Sem_060208_default_type_002 |verify than `null` value can be assigned to a default variable |Clause 6.2.8 |m |y
+|3 |Sem_060208_default_type_003 |verify than existing default references can be assigned |Clause 6.2.8 |m |y
+|=========================================================================================================================================
+
+== Communication port types
+
+.Communication port types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060209_CommunicationPortTypes_001 |Restriction of port definitions are appropriately handles |Clause 6.2.9 |m |n
+|2 |NegSem_060209_CommunicationPortTypes_002 |Restriction of port definitions are appropriately handles |Clause 6.2.9 |m |n
+|3 |NegSem_060209_CommunicationPortTypes_003 |Restriction of port definitions are appropriately handles |Clause 6.2.9 |m |n
+|4 |NegSem_060209_CommunicationPortTypes_004 |Verify that an error is generated when a message port type definition contains no message types |Clause 6.2.9 |m |y
+|5 |NegSem_060209_CommunicationPortTypes_005 |Verify that an error is generated when a procedure port type definition contains no signatures |Clause 6.2.9 |m |y
+|6 |NegSem_060209_CommunicationPortTypes_006 |Verify that an error is generated when a signature port definition contains multiple `address` clauses |Clause 6.2.9 |m |n
+|7 |NegSem_060209_CommunicationPortTypes_007 |Verify that an error is generated when a signature port definition contains multiple `map` clauses |Clause 6.2.9 |m |n
+|8 |NegSem_060209_CommunicationPortTypes_008 |Verify that an error is generated when a signature port definition contains multiple `unmap` clauses |Clause 6.2.9 |m |n
+|9 |Sem_060209_CommunicationPortTypes_004 |`Map` and `unmap` param and local port address are allowed in a testcase block |Clause 6.2.9 |m |n
+|10 |Sem_060209_CommunicationPortTypes_005 |Parameter `MessageType` of the port shall be data type |Clause 6.2.9 |m |n
+|11 |Syn_060209_CommunicationPortTypes_001 |Message-based ports are accepted. |Clause 6.2.9 |m |y
+|12 |Syn_060209_CommunicationPortTypes_002 |Message-based ports with address are accepted. |Clause 6.2.9 |m |n
+|13 |Syn_060209_CommunicationPortTypes_003 |Verify that it is possible to define procedute-based port types |Clause 6.2.9 |m |y
+|14 |Syn_060209_CommunicationPortTypes_004 |Procedure-based ports with address are accepted |Clause 6.2.9 |m |n
+|15 |Syn_060209_CommunicationPortTypes_005 |`Map` param is accepted by the port definition. |Clause 6.2.9 |m |n
+|16 |Syn_060209_CommunicationPortTypes_006 |`Unmap` param is accepted by the port definition. |Clause 6.2.9 |m |n
+|17 |Syn_060209_CommunicationPortTypes_007 |Complex port definition are accepted. |Clause 6.2.9 |m |n
+|18 |Syn_060209_CommunicationPortTypes_008 |Procedure-base port type definition can contain `map` parameter definition |Clause 6.2.9 |m |n
+|19 |Syn_060209_CommunicationPortTypes_009 |Procedure-base port type definition can contain `unmap` parameter definition |Clause 6.2.9 |m |n
+|20 |Syn_060209_CommunicationPortTypes_010 |Complex procedure-based port type definition are accepted |Clause 6.2.9 |m |n
+|=====================================================================================================================================================================
+
+== Component types
+
+.Component types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_060210_ReuseofComponentTypes_001 |Cyclic extension is not allowed |Clause 6.2.10 |m |y
+|2 |NegSyn_060210_ReuseofComponentTypes_002 |Extending a component that occurs name clash is not allowed |Clause 6.2.10 |m |y
+|3 |NegSyn_060210_ReuseofComponentTypes_003 |Extending a component that occurs name clash is not allowed |Clause 6.2.10 |m |y
+|4 |Sem_060210_ReuseofComponentTypes_001 |Extending a component with another component works properly |Clause 6.2.10 |m |y
+|5 |Sem_060210_ReuseofComponentTypes_002 |Extending a component with several other component works properly |Clause 6.2.10 |m |y
+|6 |Sem_060210_ReuseofComponentTypes_003 |Extending a component with and extended component works properly |Clause 6.2.10 |m |y
+|===============================================================================================================================
+
+== Addressing entities inside the SUT
+
+.Addressing entities inside the SUT
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060212_AddressingEntitiesInsideSut_001 |Ensure right type checking for address types in ports |Clause 6.2.12 |m |n
+|2 |NegSem_060212_AddressingEntitiesInsideSut_002 |Address type cannot be used in a from part of `receive` operation with connected ports |Clause 6.2.12 |m |n
+|3 |NegSem_060212_AddressingEntitiesInsideSut_003 |Address type cannot be used in a sender part of `receive` operation with connected ports |Clause 6.2.12 |m |n
+|4 |NegSem_060212_AddressingEntitiesInsideSut_004 |Address type cannot be used in a to part of `sender` operation with connected ports |Clause 6.2.12 |m |n
+|5 |Sem_060212_AddressingEntitiesInsideSut_001 |Ensure `null` assignment is accepted for addresses |Clause 6.2.12 |m |n
+|6 |Sem_060212_AddressingEntitiesInsideSut_002 |The right port address is used |Clause 6.2.12 |m |n
+|=============================================================================================================================================================
+
+== Subtyping of structured types
+
+.Subtyping of structured types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_06021301_LengthSubtyping_001 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|2 |NegSem_06021301_LengthSubtyping_002 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|3 |NegSem_06021301_LengthSubtyping_003 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|4 |NegSem_06021301_LengthSubtyping_004 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|5 |NegSem_06021301_LengthSubtyping_005 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|6 |NegSem_06021301_LengthSubtyping_006 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|7 |Syn_06021301_LengthSubtyping_001 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|8 |Syn_06021301_LengthSubtyping_002 |The length subtyping check for `record of' or `set of' types |Clause 6.2.13.1 |m |y
+|9 |NegSem_06021302_ListSubtyping_001 |ensure that list subtyping check for record types is properly handled |Clause 6.2.13.2 |m |y
+|10 |NegSem_06021302_ListSubtyping_002 |ensure that list subtyping check for record types is properly handled |Clause 6.2.13.2 |m |y
+|11 |Sem_06021302_ListSubtyping_001 |ensure that list subtyping check for record types is properly handled |Clause 6.2.13.2 |m |y
+|12 |Sem_06021302_ListSubtyping_002 |ensure that list subtyping check for record types is properly handled |Clause 6.2.13.2 |m |n
+|13 |Sem_06021302_ListSubtyping_003 |ensure that list subtyping check for record types is properly handled |Clause 6.2.13.2 |m |n
+|===================================================================================================================================
+
+== Type compatibility of non-structured types
+
+.Type compatibility of non-structured types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060301_non_structured_types_001 |The IUT correctly handles assignments from incompatible type ranges |Clause 6.3.1 |m |n
+|2 |NegSem_060301_non_structured_types_002 |The IUT correctly handles assignments from incompatible type ranges |Clause 6.3.1 |m |n
+|3 |NegSem_060301_non_structured_types_003 |The IUT correctly handles assignments from incompatible type ranges |Clause 6.3.1 |m |n
+|4 |NegSem_060301_non_structured_types_004 |The IUT correctly handles assignments from incompatible type ranges |Clause 6.3.1 |m |n
+|5 |NegSem_060301_non_structured_types_005 |The IUT correctly handles assignments from incompatible type ranges |Clause 6.3.1 |m |n
+|6 |NegSem_060301_non_structured_types_006 |The IUT correctly handles assignments from incompatible type ranges |Clause 6.3.1 |m |n
+|7 |NegSem_060301_non_structured_types_007 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |y
+|8 |NegSem_060301_non_structured_types_008 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |y
+|9 |NegSem_060301_non_structured_types_009 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |n
+|10 |NegSem_060301_non_structured_types_010 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |n
+|11 |NegSem_060301_non_structured_types_011 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |n
+|12 |NegSem_060301_non_structured_types_012 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |n
+|13 |Sem_060301_non_structured_types_001 |The IUT correctly handles assignments from compatible type ranges |Clause 6.3.1 |m |y
+|14 |Sem_060301_non_structured_types_002 |The IUT correctly handles assignments from compatible size restrictions |Clause 6.3.1 |m |n
+|15 |Sem_060301_non_structured_types_003 |The IUT correctly handles assignments from compatible type ranges |Clause 6.3.1 |m |y
+|16 |Sem_060301_non_structured_types_004 |The IUT correctly handles assignments from compatible type ranges |Clause 6.3.1 |m |y
+|=======================================================================================================================================
+
+== Type compatibility of structured types
+
+.Type compatibility of structured types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060302_structured_types_002 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |y
+|2 |NegSem_060302_structured_types_003 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |n
+|3 |NegSem_060302_structured_types_004 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |y
+|4 |NegSem_060302_structured_types_005 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |n
+|5 |NegSem_060302_structured_types_006 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |n
+|6 |NegSem_060302_structured_types_007 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |n
+|7 |NegSem_060302_structured_types_008 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |n
+|8 |NegSem_060302_structured_types_009 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |y
+|9 |NegSem_060302_structured_types_010 |The IUT rejects assignments from incompatible types or type ranges |Clause 6.3.2 |m |y
+|10 |NegSem_060302_structured_types_011 |The IUT rejects assignments from structures having incompatible anytypes |Clause 6.3.2 |m |y
+|11 |NegSem_060302_structured_types_012 |The IUT rejects assignments having mismatch between undefined and omitted elements |Clause 6.3.2 |m |n
+|12 |NegSem_060302_structured_types_013 |The IUT rejects assignments having mismatch between undefined and omitted elements |Clause 6.3.2 |m |n
+|13 |NegSem_060302_structured_types_014 |The IUT rejects assignments between incompatible structures |Clause 6.3.2 |m |n
+|14 |NegSem_060302_structured_types_015 |The IUT rejects assignments between incompatible structures |Clause 6.3.2 |m |n
+|15 |NegSem_060302_structured_types_016 |The IUT rejects assignments between incompatible structures |Clause 6.3.2 |m |y
+|16 |NegSem_060302_structured_types_017 |The IUT rejects assignments between incompatible structures |Clause 6.3.2 |m |n
+|17 |NegSem_060302_structured_types_018 |The IUT rejects assignments between incompatible structures |Clause 6.3.2 |m |y
+|18 |NegSem_060302_structured_types_019 |The IUT correctly handles assignments from structures having compatible types and lengths |Clause 6.3.2 |m |n
+|19 |Sem_060302_structured_types_001 |The IUT correctly handles assignments from structures having compatible types and type ranges |Clause 6.3.2 |m |y
+|20 |Sem_060302_structured_types_002 |The IUT correctly handles assignments from structures having compatible types and lengths |Clause 6.3.2 |m |y
+|21 |Sem_060302_structured_types_003 |The IUT correctly handles assignments from structures having compatible types and type ranges |Clause 6.3.2 |m |y
+|22 |Sem_060302_structured_types_004 |The IUT correctly handles assignments from structures having compatible anytypes |Clause 6.3.2 |m |y
+|23 |Sem_060302_structured_types_005 |The IUT correctly handles assignments from structures having compatible types and type ranges |Clause 6.3.2 |m |y
+|24 |Sem_060302_structured_types_006 |The IUT correctly handles assignments from structures having compatible types and lengths |Clause 6.3.2 |m |n
+|======================================================================================================================================================
+
+== Type compatibility of enumerated types
+
+.Type compatibility of enumerated types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060302_structured_types_001 |Reject assignment of other enumerated types since they are only compatible to synonym types |Clause 6.3.2.1 |m |y
+|========================================================================================================================================================
+
+== Type compatibility of component types
+
+.Type compatibility of component types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060303_component_types_001 |The IUT correctly handles component incompatibility due to differing list of constant definitions |Clause 6.3.3 |m |y
+|2 |NegSem_060303_component_types_002 |The IUT correctly handles component incompatibility due to differing constant types having same name |Clause 6.3.3 |m |y
+|3 |NegSem_060303_component_types_003 |Ensure that the IUT correctly handles component compatibility of different `runs on` clauses |Clause 6.3.3 |m |y
+|4 |NegSem_060303_component_types_004 |Ensure that the IUT correctly handles component compatibility of `mtc` and `runs on` clause |Clause 6.3.3 |m |y
+|5 |NegSem_060303_component_types_005 |Ensure that the IUT correctly handles component compatibility of `system` and `runs on` clause |Clause 6.3.3 |m |y
+|6 |NegSem_060303_component_types_006 |Ensure that the IUT correctly handles component compatibility of different `system` clauses |Clause 6.3.3 |m |y
+|7 |Sem_060303_component_types_001 |The IUT correctly handles assignments from structures having compatible components |Clause 6.3.3 |m |y
+|8 |Sem_060303_component_types_002 |The IUT correctly handles assignments from structures having compatible components |Clause 6.3.3 |m |y
+|9 |Sem_060303_component_types_003 |Ensure that the IUT correctly handles component compatibility of different `runs on` clauses |Clause 6.3.3 |m |n
+|10 |Sem_060303_component_types_004 |Ensure that the IUT correctly handles component compatibility of `mtc` and `runs on` clause |Clause 6.3.3 |m |y
+|11 |Sem_060303_component_types_005 |Ensure that the IUT correctly handles component compatibility of `system` and `runs on` clause |Clause 6.3.3 |m |y
+|12 |Sem_060303_component_types_006 |Ensure that the IUT correctly handles component compatibility of different `system` clauses |Clause 6.3.3 |m |y
+|==============================================================================================================================================================
+
+== Type compatibility of communication operations
+
+.Type compatibility of communication operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_060304_compatibility_of_communication_operations_001 |compatible but not strongly typed value in `send` operation |Clause 6.3.4 |m |n
+|2 |NegSem_060304_compatibility_of_communication_operations_002 |compatible but not strongly typed value in `receive` operation |Clause 6.3.4 |m |n
+|3 |NegSem_060304_compatibility_of_communication_operations_003 |compatible but not strongly typed value in `raise` operation |Clause 6.3.4 |m |n
+|4 |NegSem_060304_compatibility_of_communication_operations_004 |compatible but not strongly typed value in `raise` operation |Clause 6.3.4 |m |n
+|5 |NegSem_060304_compatibility_of_communication_operations_005 |compatible but not strongly typed value in `trigger` operation |Clause 6.3.4 |m |n
+|================================================================================================================================================
+
+== Expression
+
+.Expression
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===========================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_07_toplevel_001 |function without `return` clause in expression |Clause 7 |m |y
+|2 |NegSem_07_toplevel_002 |template used as expression operand |Clause 7 |m |y
+|3 |NegSem_07_toplevel_003 |uninitialized value in an expression |Clause 7 |m |y
+|4 |NegSem_07_toplevel_004 |partially initialized value in an expression |Clause 7 |m |n
+|5 |NegSem_07_toplevel_005 |null value in an expression |Clause 7 |m |n
+|6 |Sem_07_toplevel_001 |expression composed of several expressions |Clause 7 |m |y
+|7 |Sem_07_toplevel_002 |compound expression as an operand of array type |Clause 7 |m |y
+|8 |Sem_07_toplevel_003 |compound expression as an operand of record type |Clause 7 |m |y
+|9 |Sem_07_toplevel_004 |compound expression as an operand of record-of type |Clause 7 |m |y
+|10 |Sem_07_toplevel_005 |compound expression as an operand of set-of type |Clause 7 |m |y
+|11 |Sem_07_toplevel_006 |element of partially initialized structured value |Clause 7 |m |y
+|12 |Sem_07_toplevel_007 |compound expression as an operand of set-of type |Clause 7 |m |y
+|13 |Sem_07_toplevel_008 |compound expression as an operand of set-of type |Clause 7 |m |y
+|14 |Sem_07_toplevel_009 |compound expression as an operand of set type |Clause 7 |m |y
+|===========================================================================================
+
+== Arithmetic operators
+
+.Arithmetic operators
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_070101_ArithmeticOperators_001 |Arithmetic operators are for integer and float values |Clause 7.1.1 |m |y
+|2 |NegSem_070101_ArithmeticOperators_002 |Arithmetic operators can handle same type of variables |Clause 7.1.1 |m |y
+|3 |NegSem_070101_ArithmeticOperators_003 |Mod arithmetic operator can handle integer variables |Clause 7.1.1 |m |y
+|4 |NegSem_070101_ArithmeticOperators_004 |Rem arithmetic operator can handle integer variables |Clause 7.1.1 |m |y
+|5 |NegSem_070101_ArithmeticOperators_008 |In x mod y arithmetic operator y is non-zero positive number |Clause 7.1.1 |m |y
+|6 |NegSem_070101_ArithmeticOperators_009 |In x rem y arithmetic operator y is non-zero positive number |Clause 7.1.1 |m |y
+|7 |NegSem_070101_ArithmeticOperators_010 |In x rem y arithmetic operator y is non-zero positive number |Clause 7.1.1 |m |y
+|8 |Sem_070101_ArithmeticOperators_001 |The addition of two integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|9 |Sem_070101_ArithmeticOperators_002 |The addition of multiple integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|10 |Sem_070101_ArithmeticOperators_003 |The addition of two integer variables is evaluated correctly when the expression contains a negative value. |Clause 7.1.1 |m |y
+|11 |Sem_070101_ArithmeticOperators_004 |The substraction of two integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|12 |Sem_070101_ArithmeticOperators_005 |The substraction of multiple integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|13 |Sem_070101_ArithmeticOperators_006 |The multiplication of two integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|14 |Sem_070101_ArithmeticOperators_007 |The multiplication of multiple integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|15 |Sem_070101_ArithmeticOperators_008 |The division of two integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|16 |Sem_070101_ArithmeticOperators_009 |The division of multiple integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|17 |Sem_070101_ArithmeticOperators_010 |The application of the modulo operator on integer variables is evaluated correctly when the remainder is zero. |Clause 7.1.1 |m |y
+|18 |Sem_070101_ArithmeticOperators_011 |The application of the modulo operator on integer variables is evaluated correctly when the integer value is smaller than the modulo value. |Clause 7.1.1 |m |y
+|19 |Sem_070101_ArithmeticOperators_012 |The application of the modulo operator on integer variables is evaluated correctly when the integer value greater than the modulo value. |Clause 7.1.1 |m |y
+|20 |Sem_070101_ArithmeticOperators_013 |The application of the modulo operator on integer variables is evaluated correctly when two consecutive modulo operators are applied. |Clause 7.1.1 |m |y
+|21 |Sem_070101_ArithmeticOperators_014 |The application of the modulo operator on integer variables is evaluated correctly when the operand is a negative integer. |Clause 7.1.1 |m |y
+|22 |Sem_070101_ArithmeticOperators_015 |The application of the remainder operator on integer variables is evaluated correctly when the operand is a negative integer. |Clause 7.1.1 |m |y
+|23 |Sem_070101_ArithmeticOperators_016 |The application of the remainder operator on integer variables is evaluated correctly when the operand is a negative integer. |Clause 7.1.1 |m |y
+|24 |Sem_070101_ArithmeticOperators_017 |The consecutive application of the remainder operator and the modulo operator on integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|25 |Sem_070101_ArithmeticOperators_018 |Operator combinations and the modulo operator on integer variables is evaluated correctly. |Clause 7.1.1 |m |y
+|26 |Sem_070101_ArithmeticOperators_019 |The addition operator works on float variables. |Clause 7.1.1 |m |y
+|27 |Sem_070101_ArithmeticOperators_020 |The substraction operator works on float variables. |Clause 7.1.1 |m |y
+|28 |Sem_070101_ArithmeticOperators_021 |The multiplication operator works on float variables. |Clause 7.1.1 |m |y
+|29 |Sem_070101_ArithmeticOperators_022 |The division operator works on float variables. |Clause 7.1.1 |m |y
+|30 |Sem_070101_ArithmeticOperators_023 |The combination of different operators works on float variables. |Clause 7.1.1 |m |y
+|31 |Sem_070101_ArithmeticOperators_024 |The operator precedence is evaluated correctly. |Clause 7.1.1 |m |y
+|32 |Sem_070101_ArithmeticOperators_025 |The operator precedence is evaluated correctly. |Clause 7.1.1 |m |y
+|33 |Sem_070101_ArithmeticOperators_026 |The operator precedence is evaluated correctly. |Clause 7.1.1 |m |y
+|34 |Sem_070101_ArithmeticOperators_027 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|35 |Sem_070101_ArithmeticOperators_028 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|36 |Sem_070101_ArithmeticOperators_029 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|37 |Sem_070101_ArithmeticOperators_030 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|38 |Sem_070101_ArithmeticOperators_031 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|39 |Sem_070101_ArithmeticOperators_032 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|40 |Sem_070101_ArithmeticOperators_033 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|41 |Sem_070101_ArithmeticOperators_034 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|42 |Sem_070101_ArithmeticOperators_035 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|43 |Sem_070101_ArithmeticOperators_036 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|44 |Sem_070101_ArithmeticOperators_037 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|45 |Sem_070101_ArithmeticOperators_038 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|46 |Sem_070101_ArithmeticOperators_039 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|47 |Sem_070101_ArithmeticOperators_040 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|48 |Sem_070101_ArithmeticOperators_041 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|49 |Sem_070101_ArithmeticOperators_042 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|50 |Sem_070101_ArithmeticOperators_043 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|51 |Sem_070101_ArithmeticOperators_044 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|52 |Sem_070101_ArithmeticOperators_045 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|53 |Sem_070101_ArithmeticOperators_046 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|54 |Sem_070101_ArithmeticOperators_047 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|55 |Sem_070101_ArithmeticOperators_048 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|56 |Sem_070101_ArithmeticOperators_049 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|57 |Sem_070101_ArithmeticOperators_050 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|58 |Sem_070101_ArithmeticOperators_051 |Arithmetic operators can handle special float values |Clause 7.1.1 |m |y
+|59 |Syn_070101_ArithmeticOperators_001 |The addition of two integers in a constant is accepted. |Clause 7.1.1 |m |y
+|60 |Syn_070101_ArithmeticOperators_002 |The substraction of two integers in a constant is accepted. |Clause 7.1.1 |m |y
+|61 |Syn_070101_ArithmeticOperators_003 |The multiplication of two integers in a constant is accepted. |Clause 7.1.1 |m |y
+|62 |Syn_070101_ArithmeticOperators_004 |The division of two integers in a constant is accepted. |Clause 7.1.1 |m |y
+|63 |Syn_070101_ArithmeticOperators_005 |The modulo operator on two integers is accepted. |Clause 7.1.1 |m |y
+|64 |Syn_070101_ArithmeticOperators_006 |The remainder operator on two integers is accepted. |Clause 7.1.1 |m |y
+|65 |Syn_070101_ArithmeticOperators_007 |Operator combinations on integers is accepted. |Clause 7.1.1 |m |y
+|66 |Syn_070101_ArithmeticOperators_008 |The addition operator on float constants is accepted. |Clause 7.1.1 |m |y
+|67 |Syn_070101_ArithmeticOperators_009 |The substraction operator on float constants is accepted. |Clause 7.1.1 |m |y
+|68 |Syn_070101_ArithmeticOperators_010 |The multiplication operator on float constants is accepted. |Clause 7.1.1 |m |y
+|69 |Syn_070101_ArithmeticOperators_011 |The division operator on float constants is accepted. |Clause 7.1.1 |m |y
+|70 |Syn_070101_ArithmeticOperators_012 |A combination of operators on float constants is accepted. |Clause 7.1.1 |m |y
+|=======================================================================================================================================================================================================
+
+== List operator
+
+.List operator
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_070102_ListOperator_001 |The list operator on bitstrings is evaluated correctly. |Clause 7.1.2 |m |y
+|2 |Sem_070102_ListOperator_002 |The list operator on charstrings is evaluated correctly. |Clause 7.1.2 |m |y
+|3 |Sem_070102_ListOperator_003 |The list operator on record of is evaluated correctly. |Clause 7.1.2 |m |y
+|4 |Sem_070102_ListOperator_004 |The list operator on set of is evaluated correctly. |Clause 7.1.2 |m |y
+|5 |Sem_070102_ListOperator_005 |The list operator on arrays is evaluated correctly. |Clause 7.1.2 |m |n
+|6 |Sem_070102_ListOperator_006 |The list operator on record of is evaluated correctly. |Clause 7.1.2 |m |y
+|============================================================================================================
+
+== Relational operators
+
+.Relational operators
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_070101_ArithmeticOperators_051 |The equal to operator on address with value `null` is evaulated correctly |Clause 7.1.3 |m |n
+|2 |Sem_070101_ArithmeticOperators_052 |The not equal to operator on address with value `null` is evaulated correctly |Clause 7.1.3 |m |n
+|3 |NegSem_070103_RelationalOperators_001 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |n
+|4 |NegSem_070103_RelationalOperators_002 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|5 |NegSem_070103_RelationalOperators_003 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|6 |NegSem_070103_RelationalOperators_004 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|7 |NegSem_070103_RelationalOperators_005 |The not equal to operator on address can not be evaluated if value is uninitialized. |Clause 7.1.3 |m |n
+|8 |NegSyn_070103_RelationalOperators_001 |The greater operator on address can not be evaluated. |Clause 7.1.3 |m |n
+|9 |NegSyn_070103_RelationalOperators_002 |The less operator on address can not be evaluated. |Clause 7.1.3 |m |n
+|10 |NegSyn_070103_RelationalOperators_003 |The less or equal to operator on address can not be evaluated. |Clause 7.1.3 |m |n
+|11 |NegSyn_070103_RelationalOperators_004 |The greater or equal to operator on address can not be evaluated. |Clause 7.1.3 |m |n
+|12 |Sem_070103_RelationalOperators_001 |The equals operator on integers is evaluated correctly. |Clause 7.1.3 |m |y
+|13 |Sem_070103_RelationalOperators_002 |The equals operator on floats is evaluated correctly. |Clause 7.1.3 |m |y
+|14 |Sem_070103_RelationalOperators_003 |The equals operator on enumerations is evaluated correctly. |Clause 7.1.3 |m |y
+|15 |Sem_070103_RelationalOperators_004 |The less than operator on integers is evaluated correctly. |Clause 7.1.3 |m |y
+|16 |Sem_070103_RelationalOperators_005 |The less than operator on floats is evaluated correctly. |Clause 7.1.3 |m |y
+|17 |Sem_070103_RelationalOperators_006 |The less than operator on enumerations is evaluated correctly. |Clause 7.1.3 |m |y
+|18 |Sem_070103_RelationalOperators_007 |The less than or equal to operator on integers is evaluated correctly with differing values. |Clause 7.1.3 |m |y
+|19 |Sem_070103_RelationalOperators_008 |The less than or equal to operator on integers is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|20 |Sem_070103_RelationalOperators_009 |The less than or equal to operator on floats is evaluated correctly with differing values. |Clause 7.1.3 |m |y
+|21 |Sem_070103_RelationalOperators_010 |The less than or equal to operator on floats is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|22 |Sem_070103_RelationalOperators_011 |The less than or equal to operator on enumerations is evaluated correctly with differing values. |Clause 7.1.3 |m |y
+|23 |Sem_070103_RelationalOperators_012 |The less than or equal to operator on enumerations is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|24 |Sem_070103_RelationalOperators_013 |The greater than operator on integers is evaluated correctly. |Clause 7.1.3 |m |y
+|25 |Sem_070103_RelationalOperators_014 |The less than operator on floats is evaluated correctly. |Clause 7.1.3 |m |y
+|26 |Sem_070103_RelationalOperators_015 |The less than operator on enumerations is evaluated correctly. |Clause 7.1.3 |m |y
+|27 |Sem_070103_RelationalOperators_016 |The greater than or equal to operator on integers is evaluated correctly with differing values. |Clause 7.1.3 |m |y
+|28 |Sem_070103_RelationalOperators_017 |The greater than or equal to operator on integers is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|29 |Sem_070103_RelationalOperators_018 |The greater than or equal to operator on floats is evaluated correctly with differing values. |Clause 7.1.3 |m |y
+|30 |Sem_070103_RelationalOperators_019 |The greater than or equal to operator on floats is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|31 |Sem_070103_RelationalOperators_020 |The less than or equal to operator on enumerations is evaluated correctly with differing values. |Clause 7.1.3 |m |y
+|32 |Sem_070103_RelationalOperators_021 |The greater than or equal to operator on enumerations is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|33 |Sem_070103_RelationalOperators_022 |The not equals operator on integers is evaluated correctly. |Clause 7.1.3 |m |y
+|34 |Sem_070103_RelationalOperators_023 |The not equals operator on floats is evaluated correctly. |Clause 7.1.3 |m |y
+|35 |Sem_070103_RelationalOperators_024 |The not equals operator on enumerations is evaluated correctly. |Clause 7.1.3 |m |y
+|36 |Sem_070103_RelationalOperators_025 |The equals operator on sets is evaluated correctly. |Clause 7.1.3 |m |y
+|37 |Sem_070103_RelationalOperators_026 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|38 |Sem_070103_RelationalOperators_030 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|39 |Sem_070103_RelationalOperators_031 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|40 |Sem_070103_RelationalOperators_032 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|41 |Sem_070103_RelationalOperators_033 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|42 |Sem_070103_RelationalOperators_034 |The equals operator on records is evaluated correctly. |Clause 7.1.3 |m |y
+|43 |Sem_070103_RelationalOperators_035 |The eqaul to operator on address is evaluated correctly with equal values. |Clause 7.1.3 |m |n
+|44 |Sem_070103_RelationalOperators_036 |The eqaul to operator on address is evaluated correctly with equal values. |Clause 7.1.3 |m |y
+|45 |Sem_070103_RelationalOperators_037 |The not eqaul to operator on record type address is evaluated correctly. |Clause 7.1.3 |m |n
+|46 |Sem_070103_RelationalOperators_038 |Less than operator evaulates correctly infinity special float |Clause 7.1.3 |m |y
+|47 |Sem_070103_RelationalOperators_039 |Less than or equal to operator evaulates correctly infinity special float |Clause 7.1.3 |m |y
+|48 |Sem_070103_RelationalOperators_040 |Greather than operator evaulates correctly -infinity special float |Clause 7.1.3 |m |y
+|49 |Sem_070103_RelationalOperators_041 |Greather than or equal to operator evaulates correctly -infinity special float |Clause 7.1.3 |m |y
+|50 |Sem_070103_RelationalOperators_042 |Equal to operator evaulates correctly -infinity special float |Clause 7.1.3 |m |y
+|51 |Sem_070103_RelationalOperators_043 |Equal to operator evaulates correctly infinity special float |Clause 7.1.3 |m |y
+|52 |Sem_070103_RelationalOperators_044 |Not equal to operator evaulates correctly infinity special float |Clause 7.1.3 |m |y
+|53 |Sem_070103_RelationalOperators_045 |NaN special float is evaulated correctly in a relation. |Clause 7.1.3 |m |y
+|54 |Sem_070103_RelationalOperators_046 |NaN special float is evaulated correctly in a relation. |Clause 7.1.3 |m |y
+|55 |Sem_070103_RelationalOperators_047 |Infinity special float is evaulated correctly in a relation. |Clause 7.1.3 |m |y
+|56 |Sem_070103_RelationalOperators_048 |anytypes can be compared |Clause 7.1.3 |m |y
+|57 |Sem_070103_RelationalOperators_049 |anytypes can be compared |Clause 7.1.3 |m |y
+|58 |Sem_070103_RelationalOperators_050 |the less than or equal to operator on enumerations is evaluated correctly with differing values |Clause 7.1.3 |m |n
+|============================================================================================================================================================
+
+== Logical operators
+
+.Logical operators
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_070104_LogicalOperators_001 |The boolean operator supports negation. |Clause 7.1.4 |m |y
+|2 |Sem_070104_LogicalOperators_002 |The the and operator with true and false as operands work on boolean variables. |Clause 7.1.4 |m |y
+|=======================================================================================================================================
+
+== Bitwise operators
+
+.Bitwise operators
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_070105_BitwiseOperators_001 |The bitwise negation operator works as expected. |Clause 7.1.5 |m |y
+|2 |Sem_070105_BitwiseOperators_002 |The bitwise negation operator works as expected on hexstrings. |Clause 7.1.5 |m |y
+|======================================================================================================================
+
+== Shift operators
+
+.Shift operators
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_070106_ShiftOperators_001 |The shift left operator works as expected on bitstrings. |Clause 7.1.6 |m |y
+|2 |Sem_070106_ShiftOperators_002 |The shift left operator works as expected on hexstrings. |Clause 7.1.6 |m |y
+|3 |Sem_070106_ShiftOperators_003 |The shift right operator works as expected on bitstrings. |Clause 7.1.6 |m |y
+|4 |Sem_070106_ShiftOperators_004 |The shift right operator works as expected on hexstrings. |Clause 7.1.6 |m |y
+|===============================================================================================================
+
+== Rotate operators
+
+.Rotate operators
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_070107_RotateOperators_001 |The rotate left operator works as expected on bitstrings. |Clause 7.1.7 |m |y
+|2 |Sem_070107_RotateOperators_002 |The rotate left operator works as expected on hexstrings. |Clause 7.1.7 |m |y
+|3 |Sem_070107_RotateOperators_003 |The rotate right operator works as expected on bitstrings. |Clause 7.1.7 |m |y
+|4 |Sem_070107_RotateOperators_004 |The rotate right operator works as expected on hexstrings. |Clause 7.1.7 |m |y
+|=================================================================================================================
+
+== Field references and list elements
+
+.Field references and list elements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_0702_FieldReferencesAndListElements_001 |The IUT correctly handles field referencing |Clause 7.2 |m |y
+|2 |Sem_0702_FieldReferencesAndListElements_002 |The IUT correctly handles field referencing |Clause 7.2 |m |y
+|=============================================================================================================
+
+== Definition of a module
+
+.Definition of a module
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_0801_DefinitionOfAModule_001 |A module definition with multiple language specifications is rejected. |Clause 8.1 |m |n
+|2 |Syn_0801_DefinitionOfAModule_001 |A ``plain'' module definition is accepted. |Clause 8.1 |m |y
+|3 |Syn_0801_DefinitionOfAModule_002 |A module definition with language specification is accepted. |Clause 8.1 |m |y
+|4 |Syn_0801_DefinitionOfAModule_003 |A module definition with language and package is accepted. |Clause 8.1 |m |n
+|5 |Syn_0801_DefinitionOfAModule_004 |A module definition with package and without language is accepted. |Clause 8.1 |m |y
+|6 |Syn_0801_DefinitionOfAModule_005 |A module definition with ed4.3.1 language and package is accepted. |Clause 8.1 |m |y
+|7 |Syn_0801_DefinitionOfAModule_006 |A module definition with ed4.4.1 language and package is accepted. |Clause 8.1 |m |y
+|8 |Syn_0801_DefinitionOfAModule_007 |A module definition with ed4.5.1 language and package is accepted. |Clause 8.1 |m |y
+|9 |Syn_0801_DefinitionOfAModule_008 |A module definition with ed4.6.1 language and package is accepted. |Clause 8.1 |m |y
+|10 |Syn_0801_DefinitionOfAModule_009 |A module definition with ed4.7.1 language and package is accepted. |Clause 8.1 |m |y
+|11 |Syn_0801_DefinitionOfAModule_010 |A module definition with ed4.8.1 language and package is accepted |Clause 8.1 |m |y
+|================================================================================================================================
+
+== Module definitions part
+
+.Module definitions part
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_0802_ModuleDefinitionsPart_001 |A TypeDef module definition with public visibility is accepted. |Clause 8.2 |m |y
+|2 |Syn_0802_ModuleDefinitionsPart_002 |A TypeDef module definition with private visibility is accepted. |Clause 8.2 |m |y
+|=========================================================================================================================
+
+== Module parameters
+
+.Module parameters
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_080201_ModuleParameters_001 |A port, default or component types cannot be module parameters |Clause 8.2.1 |m |y
+|2 |NegSem_080201_ModuleParameters_002 |A port, default or component types cannot be module parameters |Clause 8.2.1 |m |n
+|3 |NegSem_080201_ModuleParameters_003 |A port, default or component types cannot be module parameters |Clause 8.2.1 |m |n
+|4 |NegSem_080201_ModuleParameters_004 |Ensure that module parameters remain constant |Clause 8.2.1 |m |y
+|5 |NegSem_080201_ModuleParameters_005 |A reference to plain module parameter with a default value delivers the default value unless it is overwritten |Clause 8.2.1 |m |y
+|6 |NegSem_080201_ModuleParameters_006 |A reference to plain module parameter with a default value delivers the default value unless it is overwritten |Clause 8.2.1 |m |y
+|7 |NegSyn_080201_ModuleParameters_001 |Module parameter can be declared within the module definition part only |Clause 8.2.1 |m |y
+|8 |NegSyn_080201_ModuleParameters_002 |Module parameter can be declared within the module definition part only |Clause 8.2.1 |m |y
+|9 |Sem_080201_ModuleParameters_001 |A reference to plain module parameter with a default value delivers the default value unless it is overwritten. |Clause 8.2.1 |m |y
+|10 |Syn_080201_ModuleParameters_001 |Plain module parameters are accepted. |Clause 8.2.1 |m |y
+|11 |Syn_080201_ModuleParameters_002 |Plain module parameters with default values are accepted. |Clause 8.2.1 |m |y
+|12 |Syn_080201_ModuleParameters_003 |Plain module parameters with default values and visibility modifiers are accepted. |Clause 8.2.1 |m |y
+|=========================================================================================================================================================================
+
+== Groups of definitions
+
+.Groups of definitions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_080202_GroupOfDefinitions_001 |A definition within a group is accepted. |Clause 8.2.2 |m |y
+|2 |Syn_080202_GroupOfDefinitions_002 |A definition within a nested group is accepted. |Clause 8.2.2 |m |y
+|3 |Syn_080202_GroupOfDefinitions_003 |A definition within a group with public visibility modifier is accepted. |Clause 8.2.2 |m |y
+|4 |Syn_080202_GroupOfDefinitions_004 |A definition within a group with public visibility modifier and attributes is accepted. |Clause 8.2.2 |m |y
+|=================================================================================================================================================
+
+== General format of import
+
+.General format of import
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_08020301_GeneralFormatOfImport_001 |Name handling of imported enumerations is properly handled |Clause 8.2.3.1 |m |n
+|2 |NegSem_08020301_GeneralFormatOfImport_002 |Name handling of imported enumerations is properly handled |Clause 8.2.3.1 |m |y
+|3 |NegSem_08020301_GeneralFormatOfImport_005 |Make sure that the identifier of the current module cannot be used for prefixing imported entities |Clause 8.2.3.1 |m |y
+|4 |NegSem_08020301_GeneralFormatOfImport_006 |The only top-level visible definitions of a module may be imported. |Clause 8.2.3.1 |m |y
+|5 |NegSem_08020301_GeneralFormatOfImport_007 |Verify that information about message types is imported together with port type |Clause 8.2.3.1 |m |y
+|6 |NegSem_08020301_GeneralFormatOfImport_008 |Verify that identifiers of module parameter types are not imported together with module parameters |Clause 8.2.3.1 |m |n
+|7 |NegSem_08020301_GeneralFormatOfImport_009 |Verify that identifiers of constant types are not imported together with constants |Clause 8.2.3.1 |m |n
+|8 |NegSem_08020301_GeneralFormatOfImport_010 |Verify that identifiers of field types are not imported together with structured types |Clause 8.2.3.1 |m |n
+|9 |NegSem_08020301_GeneralFormatOfImport_011 |Verify that identifiers of message types are not imported together with port types |Clause 8.2.3.1 |m |n
+|10 |NegSem_08020301_GeneralFormatOfImport_012 |Verify that identifiers of signatures are not imported together with port types |Clause 8.2.3.1 |m |n
+|11 |NegSem_08020301_GeneralFormatOfImport_013 |Verify that identifiers of constant types are not imported together with component types |Clause 8.2.3.1 |m |n
+|12 |NegSem_08020301_GeneralFormatOfImport_014 |Verify that identifiers of variable types are not imported together with component types |Clause 8.2.3.1 |m |n
+|13 |NegSem_08020301_GeneralFormatOfImport_015 |Verify that identifiers of port types are not imported together with component types |Clause 8.2.3.1 |m |n
+|14 |NegSem_08020301_GeneralFormatOfImport_016 |Verify that identifiers of parameter types are not imported together with signatures |Clause 8.2.3.1 |m |n
+|15 |NegSem_08020301_GeneralFormatOfImport_017 |Verify that identifiers of return types are not imported together with signatures |Clause 8.2.3.1 |m |n
+|16 |NegSem_08020301_GeneralFormatOfImport_018 |Verify that identifiers of exception types are not imported together with signatures |Clause 8.2.3.1 |m |n
+|17 |NegSem_08020301_GeneralFormatOfImport_019 |Verify that identifiers of template types are not imported together with data templates |Clause 8.2.3.1 |m |n
+|18 |NegSem_08020301_GeneralFormatOfImport_020 |Verify that identifiers of parameter types are not imported together with data templates |Clause 8.2.3.1 |m |n
+|19 |NegSem_08020301_GeneralFormatOfImport_021 |Verify that identifiers of constants are not imported together with data templates |Clause 8.2.3.1 |m |n
+|20 |NegSem_08020301_GeneralFormatOfImport_022 |Verify that identifiers of module parameters are not imported together with data templates |Clause 8.2.3.1 |m |n
+|21 |NegSem_08020301_GeneralFormatOfImport_023 |Verify that identifiers of functions are not imported together with data templates |Clause 8.2.3.1 |m |n
+|22 |NegSem_08020301_GeneralFormatOfImport_024 |Verify that identifiers of signatures are not imported together with signature templates |Clause 8.2.3.1 |m |n
+|23 |NegSem_08020301_GeneralFormatOfImport_025 |Verify that identifiers of constants are not imported together with signature templates |Clause 8.2.3.1 |m |n
+|24 |NegSem_08020301_GeneralFormatOfImport_026 |Verify that identifiers of module parameters are not imported together with signature templates |Clause 8.2.3.1 |m |n
+|25 |NegSem_08020301_GeneralFormatOfImport_027 |Verify that identifiers of functions are not imported together with signature templates |Clause 8.2.3.1 |m |n
+|26 |NegSem_08020301_GeneralFormatOfImport_028 |Verify that identifiers of parameter types are not imported together with functions |Clause 8.2.3.1 |m |n
+|27 |NegSem_08020301_GeneralFormatOfImport_029 |Verify that identifiers of return type are not imported together with functions |Clause 8.2.3.1 |m |n
+|28 |NegSem_08020301_GeneralFormatOfImport_030 |Verify that identifiers of component types are not imported together with functions |Clause 8.2.3.1 |m |n
+|29 |NegSem_08020301_GeneralFormatOfImport_031 |Verify that identifiers of parameter types are not imported together with external functions |Clause 8.2.3.1 |m |n
+|30 |NegSem_08020301_GeneralFormatOfImport_032 |Verify that identifiers of return type are not imported together with external functions |Clause 8.2.3.1 |m |n
+|31 |NegSem_08020301_GeneralFormatOfImport_033 |Verify that identifiers of parameter types are not imported together with altsteps |Clause 8.2.3.1 |m |n
+|32 |NegSem_08020301_GeneralFormatOfImport_034 |Verify that identifiers of component types are not imported together with altsteps |Clause 8.2.3.1 |m |n
+|33 |NegSem_08020301_GeneralFormatOfImport_035 |Verify that identifiers of parameter types are not imported together with test cases |Clause 8.2.3.1 |m |n
+|34 |NegSem_08020301_GeneralFormatOfImport_036 |Verify that identifiers of component types (`runs on`) are not imported together with test cases |Clause 8.2.3.1 |m |n
+|35 |NegSem_08020301_GeneralFormatOfImport_037 |Verify that identifiers of component types (`system`) are not imported together with test cases |Clause 8.2.3.1 |m |n
+|36 |NegSem_08020301_GeneralFormatOfImport_038 |Verify that definition from inside an imported function cannot be referenced |Clause 8.2.3.1 |m |y
+|37 |NegSem_08020301_GeneralFormatOfImport_039 |Verify that `import` clause cannot override language tag of imported module |Clause 8.2.3.1 |m |n
+|38 |NegSem_08020301_GeneralFormatOfImport_040 |Verify that unsupported language concepts cannot be used when language is set by `import` clause |Clause 8.2.3.1 |m |n
+|39 |NegSyn_08020301_GeneralFormatOfImport_001 |`import` statement cannot be used in test case blocks |Clause 8.2.3.1 |m |y
+|40 |NegSyn_08020301_GeneralFormatOfImport_002 |`import` statement cannot be used in module control part |Clause 8.2.3.1 |m |y
+|41 |Sem_08020301_GeneralFormatOfImport_003 |Make sure that local definition takes precedence over imported one when their identifiers are equal |Clause 8.2.3.1 |m |y
+|42 |Sem_08020301_GeneralFormatOfImport_004 |Make sure that imported enumeration values take precedence over local definition |Clause 8.2.3.1 |m |y
+|43 |Sem_08020301_GeneralFormatOfImport_005 |Make sure that it is possible to use module prefix for local definitions |Clause 8.2.3.1 |m |y
+|44 |Sem_08020301_GeneralFormatOfImport_006 |Make sure that it is possible to use module prefix for local definitions |Clause 8.2.3.1 |m |n
+|45 |Sem_08020301_GeneralFormatOfImport_007 |Make sure that it is possible to use module prefix for imported definitions |Clause 8.2.3.1 |m |y
+|46 |Sem_08020301_GeneralFormatOfImport_008 |Verify that structured type is imported together with its field names and nested type definitions |Clause 8.2.3.1 |m |y
+|47 |Sem_08020301_GeneralFormatOfImport_009 |Verify that component type is imported together with constant, variable, timer and port names |Clause 8.2.3.1 |m |y
+|48 |Sem_08020301_GeneralFormatOfImport_010 |Verify that signature is imported together with parameter names |Clause 8.2.3.1 |m |y
+|49 |Sem_08020301_GeneralFormatOfImport_011 |Verify that parameterized template is imported together with parameter names |Clause 8.2.3.1 |m |y
+|50 |Sem_08020301_GeneralFormatOfImport_012 |Verify that function is imported together with parameter names |Clause 8.2.3.1 |m |y
+|51 |Sem_08020301_GeneralFormatOfImport_013 |Verify that altstep is imported together with parameter names |Clause 8.2.3.1 |m |y
+|52 |Sem_08020301_GeneralFormatOfImport_014 |Verify that test case is imported together with parameter names |Clause 8.2.3.1 |m |y
+|53 |Sem_08020301_GeneralFormatOfImport_015 |Verify that information about module parameter type is imported together with module parameter |Clause 8.2.3.1 |m |y
+|54 |Sem_08020301_GeneralFormatOfImport_016 |Verify that information about type of constant is imported together with constant |Clause 8.2.3.1 |m |y
+|55 |Sem_08020301_GeneralFormatOfImport_017 |Verify using of `import` clause with language tag for importing module having identical language tag |Clause 8.2.3.1 |m |y
+|56 |Sem_08020301_GeneralFormatOfImport_018 |Verify using of `import` clause with language tag for importing module with no language tag |Clause 8.2.3.1 |m |y
+|57 |Sem_08020301_GeneralFormatOfImport_019 |Verify that type of port is imported from a module as expected |Clause 8.2.3.1 |m |y
+|58 |Sem_08020301_GeneralFormatOfImport_020 |Verify that prefixed type is evaluated as expected |Clause 8.2.3.1 |m |y
+|59 |Syn_08020301_GeneralFormatOfImport_001 |Import all is accepted. |Clause 8.2.3.1 |m |y
+|60 |Syn_08020301_GeneralFormatOfImport_002 |Import of specific types is accepted. |Clause 8.2.3.1 |m |n
+|======================================================================================================================================================================
+
+== Importing single definitions
+
+.Importing single definitions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_08020302_ImportingSingleDefinitions_001 |The value of an explicitly imported constant can be read and carries the same value. |Clause 8.2.3.2 |m |n
+|2 |Sem_08020302_ImportingSingleDefinitions_002 |The value of an explicitly imported template can be read and carries the same value. |Clause 8.2.3.2 |m |n
+|==========================================================================================================================================================
+
+== Importing groups
+
+.Importing groups
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_08020303_ImportingGroups_001 |Constants listed as exceptions in imported groups are not accessible. |Clause 8.2.3.3 |m |n
+|2 |Sem_08020303_ImportingGroups_001 |A const defined in a group can be accessed if the group is imported. |Clause 8.2.3.3 |m |n
+|3 |Sem_08020303_ImportingGroups_002 |The IUT properly handles `except` clause in group import definitions |Clause 8.2.3.3 |m |n
+|4 |Sem_08020303_ImportingGroups_003 |but that it is in fact a shortcut notation for explicit imports. |Clause 8.2.3.3 |m |n
+|===================================================================================================================================
+
+== Importing definitions of the same kind
+
+.Importing definitions of the same kind
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_08020301_GeneralFormatOfImport_003 |Transitive import rules are properly handled |Clause 8.2.3.4 |m |y
+|2 |NegSem_08020301_GeneralFormatOfImport_004 |Transitive import rules are properly handled |Clause 8.2.3.4 |m |y
+|3 |Sem_08020301_GeneralFormatOfImport_001 |Transitive imports are properly handled |Clause 8.2.3.4 |m |y
+|4 |Sem_08020301_GeneralFormatOfImport_002 |Enumerated type definitions are automatically imported when needed |Clause 8.2.3.4 |m |y
+|5 |Sem_08020304_ImportingDefinitionsOfTheSameKind_001 |An import of all constants allows access to a sample constant. |Clause 8.2.3.4 |m |n
+|6 |Sem_08020304_ImportingDefinitionsOfTheSameKind_002 |A previously valid const import is not removed by an import covering the same definition with an except. |Clause 8.2.3.4 |m |n
+|7 |Sem_08020304_ImportingDefinitionsOfTheSameKind_003 |A previously valid const import is not removed by a second `import` statement excluding the same definition. |Clause 8.2.3.4 |m |n
+|=======================================================================================================================================================================================
+
+== Importing all definitions of a module
+
+.Importing all definitions of a module
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_08020305_ImportingAllDefinitionsOfAModule_001 |The constant is not visible after import with except. |Clause 8.2.3.5 |m |n
+|2 |NegSem_08020305_ImportingAllDefinitionsOfAModule_002 |The constant is not visible after import with except. |Clause 8.2.3.5 |m |n
+|3 |Sem_08020305_ImportingAllDefinitionsOfAModule_001 |The constant is be visible after multiple imports. |Clause 8.2.3.5 |m |y
+|4 |Sem_08020305_ImportingAllDefinitionsOfAModule_002 |The constant is be visible after multiple imports. |Clause 8.2.3.5 |m |n
+|====================================================================================================================================
+
+== Import definitions from other TTCN-3 editions and from non-TTCN-3 modules
+
+.Import definitions from other TTCN-3 editions and from non-TTCN-3 modules
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_08020306_ImportingDefinitionsFromOtherT3EditionsAndFromNonT3Modules_001 |It is possible to import from previous language versions. |Clause 8.2.3.6 |m |y
+|2 |Syn_08020306_ImportingDefinitionsFromOtherT3EditionsAndFromNonT3Modules_001 |Imports work with language references when importing definitions of the same kinds (in this case constants) is accepted. |Clause 8.2.3.6 |m |y
+|3 |Syn_08020306_ImportingDefinitionsFromOtherT3EditionsAndFromNonT3Modules_002 |Imports work with language references when importing all definitions of another module is accepted. |Clause 8.2.3.6 |m |y
+|==============================================================================================================================================================================================================================
+
+== Importing of `import` statements from TTCN-3 modules
+
+.Importing of `import` statements from TTCN-3 modules
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_08020307_ImportingOfImportStatementsFromT3Modules_001 |The import of `import` statements works for import all. |Clause 8.2.3.7 |m |y
+|2 |NegSem_08020307_ImportingOfImportStatementsFromT3Modules_002 |The import of `import` statements works for import all. |Clause 8.2.3.7 |m |y
+|3 |Sem_08020307_ImportingOfImportStatementsFromT3Modules_001 |The import of `import` statements works for import all. |Clause 8.2.3.7 |m |y
+|============================================================================================================================================
+
+== Compatibility of language specifications of imports
+
+.Compatibility of language specifications of imports
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_08020308_CompatibilityOfLanguageSpecificationsInImports_001 |Imports referring to future TTCN-3 versions are rejected. |Clause 8.2.3.8 |m |n
+|2 |NegSem_08020308_CompatibilityOfLanguageSpecificationsInImports_002 |Verify that modules with explicit language tag cannot import from newer TTCN-3 versions |Clause 8.2.3.8 |m |n
+|3 |NegSem_08020308_CompatibilityOfLanguageSpecificationsInImports_003 |Verify that modules with explicit language tag cannot import from newer TTCN-3 versions |Clause 8.2.3.8 |m |n
+|4 |Sem_08020308_CompatibilityOfLanguageSpecificationsInImports_001 |Verify that modules with explicit language tag can import from older TTCN-3 versions |Clause 8.2.3.8 |m |y
+|5 |Sem_08020308_CompatibilityOfLanguageSpecificationsInImports_002 |Verify that modules with explicit language tag can import from older TTCN-3 versions |Clause 8.2.3.8 |m |y
+|====================================================================================================================================================================================
+
+== Definition of friend modules
+
+.Definition of friend modules
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_080204_DefinitionOfFriendModules_001 |Friend visibility works for a sample constant. |Clause 8.2.4 |m |y
+|2 |NegSem_080204_DefinitionOfFriendModules_002 |Private definitions are not made visible by friend declarations (for a constant sample definition). |Clause 8.2.4 |m |y
+|3 |Sem_080204_DefinitionOfFriendModules_001 |Friend visibility works for a sample constant. |Clause 8.2.4 |m |y
+|=======================================================================================================================================================================
+
+== Visibility of definitions
+
+.Visibility of definitions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_080205_VisibilityOfDefinitions_001 |Private definition (in this case a sample constant) is not visible using a normal import. |Clause 8.2.5 |m |y
+|2 |NegSem_080205_VisibilityOfDefinitions_002 |Private definition (in this case a sample constant) is not visible using an import of a friend module. |Clause 8.2.5 |m |y
+|3 |NegSem_080205_VisibilityOfDefinitions_003 |Friend definition (in this case a sample constant) is not visible using a group import of a non-friend module. |Clause 8.2.5 |m |y
+|4 |NegSem_080205_VisibilityOfDefinitions_004 |Private definition (in this case a sample constant) is not visible using a group import of a non-friend module. |Clause 8.2.5 |m |y
+|5 |NegSem_080205_VisibilityOfDefinitions_005 |Private definition (in this case a sample constant) is not visible using a group import of a friend module. |Clause 8.2.5 |m |y
+|6 |Sem_080205_VisibilityOfDefinitions_001 |Explicitly defined public definitions (in this case a sample constant) are visible when imported. |Clause 8.2.5 |m |y
+|7 |Sem_080205_VisibilityOfDefinitions_002 |Explicitly defined public definitions (in this case a sample constant) are visible when imported by a friend module. |Clause 8.2.5 |m |y
+|8 |Sem_080205_VisibilityOfDefinitions_003 |Explicitly defined public definitions (in this case a sample constant) are visible when imported through a group. |Clause 8.2.5 |m |y
+|9 |Sem_080205_VisibilityOfDefinitions_004 |Explicitly defined public definitions (in this case a sample constant) are visible when imported through a group of a friend module. |Clause 8.2.5 |m |y
+|10 |Sem_080205_VisibilityOfDefinitions_005 |Friend definitions (in this case a sample constant) are visible when imported through a group of a friend module. |Clause 8.2.5 |m |y
+|===================================================================================================================================================================================================
+
+== Module control part
+
+.Module control part
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_0803_ModuleControlPart_001 |There is not more than one control part. |Clause 8.3 |m |y
+|2 |Sem_0803_ModuleControlPart_001 |The verdict returned from a test case to the control-part does not influence the execution of a second test case. The result of the last test case execution corresponds to the overall test verdict. |Clause 8.3 |m |y
+|3 |Syn_0803_ModuleControlPart_001 |The module control is able to accept `execute` statements. |Clause 8.3 |m |y
+|4 |Syn_0803_ModuleControlPart_002 |The module control part with a few commonly used stateents is accepted. |Clause 8.3 |m |y
+|5 |Syn_0803_ModuleControlPart_003 |An empty control part is accepted. |Clause 8.3 |m |y
+|==========================================================================================================================================================================================================================================================
+
+== Port types, component types and test configurations
+
+.Port types, component types and test configurations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_0901_Communication_ports_001 |The IUT correctly handles loopback message |Clause 9 |m |y
+|2 |Sem_0901_Communication_ports_002 |The the IUT receives the message sent by mycompA |Clause 9 |m |y
+|3 |Sem_0901_Communication_ports_003 |The the IUT receives the message sent by mycompB and mycompC |Clause 9 |m |y
+|4 |Sem_0901_Communication_ports_004 |The IUT correctly handles message exch. between ports |Clause 9 |m |y
+|5 |Sem_0901_Communication_ports_005 |The the IUT receives the message sent by mycompA |Clause 9 |m |y
+|6 |NegSem_0902_Communication_ports_001 |The IUT correctly handles the assoc. of two port to the same system interface |Clause 9 |m |n
+|7 |NegSem_0902_Communication_ports_002 |The mycomp is connected to two system interface port. |Clause 9 |m |n
+|8 |NegSem_0902_Communication_ports_003 |The two system interf. port cannot connect |Clause 9 |m |y
+|9 |NegSem_0902_Communication_ports_004 |The a connected port cannot be mapped |Clause 9 |m |n
+|10 |Sem_0902_Communication_ports_001 |The IUT port correctly mapped with a system interface |Clause 9 |m |y
+|11 |Sem_0902_Communication_ports_002 |The IUTs two ports are mapped correctly to system interfaces |Clause 9 |m |y
+|12 |Syn_0902_Communication_ports_001 |Two component can be mapped by one system interface |Clause 9 |m |y
+|=====================================================================================================================================
+
+== Communication ports
+
+.Communication ports
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_0901_Communication_ports_001 |A port owned by a component cannot be connected with two other ports |Clause 9.1 |m |n
+|2 |NegSem_0901_Communication_ports_002 |It is not possible to connect a mapped port |Clause 9.1 |m |y
+|3 |NegSem_0901_Communication_ports_003 |It is not possible to connect a port with two other ports owned by the same component |Clause 9.1 |m |n
+|4 |NegSem_0901_Communication_ports_004 |Verify that it is not possible to map a connected port |Clause 9.1 |m |y
+|5 |NegSem_0901_Communication_ports_005 |Verify that it is not possible to connect a port with a port owned by the same component |Clause 9.1 |m |n
+|6 |NegSem_0901_Communication_ports_006 |Verify that only 1:1 connection between component port and TSI are allowed |Clause 9.1 |m |n
+|7 |NegSem_0901_Communication_ports_007 |Verify that a two TSI port cannot be connected |Clause 9.1 |m |y
+|8 |NegSem_0901_Communication_ports_008 |Verify that mapping an already connected port is not allowed |Clause 9.1 |m |n
+|9 |NegSem_0901_Communication_ports_009 |Verify that connections within the test system interface are not allowed |Clause 9.1 |m |y
+|10 |NegSyn_0901_Communication_ports_001 |Verify that a two TSI port cannot be connected |Clause 9.1 |m |y
+|11 |Sem_0901_Communication_ports_006 |Verify that a port can connect to itself |Clause 9.1 |m |y
+|12 |Sem_0901_Communication_ports_007 |Verify that a port can connect to another port of the same component |Clause 9.1 |m |y
+|13 |Sem_0901_Communication_ports_008 |Verify that more than one component port can mapped to a single system port |Clause 9.1 |m |y
+|14 |Sem_0901_Communication_ports_009 |Verify that a component port can be connected to two other component ports |Clause 9.1 |m |y
+|15 |Sem_0901_Communication_ports_010 |Verify that a component port can be mapped to TSI port |Clause 9.1 |m |y
+|16 |Sem_0901_Communication_ports_011 |Verify that a component ports can be mapped to TSI ports |Clause 9.1 |m |y
+|==================================================================================================================================================
+
+== Declaring constants
+
+.Declaring constants
+
+[width="99%",cols="20%,16%,16%,16%,16%,16%",options="header",]
+|========================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_10_Constants_001 |Assign rnd to constant used in type, not allowed since constant expressions used in types have to be known at compile-time. |Clause 10 |m |y
+|2 |NegSem_10_Constants_002 |A value is assigned only once to a constant |Clause 10 |m |y
+|3 |NegSem_10_Constants_003 |Constant shall not be of port type |Clause 10 |m |y
+|4 |NegSem_10_Constants_004 |Dot notation of a field in a record, which actual value is `null` shall cause an error |Clause 10 |m |n
+|5 |NegSem_10_Constants_005 |Index notation of a field in a set of type, which actual value is `null` shall cause an error |Clause 10 |m |n
+|6 |Sem_10_Constants_001 |Assign and read constants |Clause 10 |m |y
+|7 |Sem_10_Constants_002 |Assign and read constants values |Clause 10 |m |y
+|8 |Sem_10_Constants_003 |Single expression and constant values |Clause 10 |m |y
+|9 |Sem_10_Constants_004 |Constant used within invoke function with return |Clause 10 |m |y
+|10 |Sem_10_Constants_005 |Constant used within predefined function |Clause 10 |m |y
+|11 |Sem_10_Constants_006 |Record type used as a constant |Clause 10 |m |y
+|12 |Sem_10_Constants_007 |Record type used as a constant with optional fields |Clause 10 |m |y
+|13 |Sem_10_Constants_008 |Set type used as a constant |Clause 10 |m |y
+|14 |Sem_10_Constants_009 |Set type used as a constant with optional fields |Clause 10 |m |y
+|15 |Syn_10_Constants_001 |Create constants |Clause 10 |m |y
+|16 |Syn_10_Constants_002 |Assign default constants values |Clause 10 |m |y
+|17 |Syn_10_Constants_003 |Assign component constants values |Clause 10 |m |y
+|18 |Syn_10_Constants_004 |Define constants in different scopes |Clause 10 |m |y
+|========================================================================================================================================================================
+
+== Value variables
+
+.Value variables
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1101_ValueVars_001 |Variables should be assigned only by values |Clause 11.1 |m |y
+|2 |NegSem_1101_ValueVars_002 |Partially initialized variables are evaluated correctly. |Clause 11.1 |m |n
+|3 |NegSem_1101_ValueVars_003 |Dot notation referencing to a field, which actual value is `null` shall cause an error. |Clause 11.1 |m |n
+|4 |NegSem_1101_ValueVars_004 |Index notation referencing to a "set of", which actual value is `null` shall cause an error. |Clause 11.1 |m |n
+|5 |NegSem_1101_ValueVars_005 |Variables should be assigned only by values |Clause 11.1 |m |y
+|6 |NegSyn_1101_ValueVars_001 |Define variables in module scope |Clause 11.1 |m |y
+|7 |Sem_1101_ValueVars_001 |Define variables in different scopes |Clause 11.1 |m |y
+|8 |Sem_1101_ValueVars_002 |Define variables in different scopes |Clause 11.1 |m |y
+|9 |Sem_1101_ValueVars_003 |Read and write variables |Clause 11.1 |m |y
+|10 |Sem_1101_ValueVars_004 |Partially initialized variables are evaluated correctly. |Clause 11.1 |m |y
+|11 |Sem_1101_ValueVars_005 |Partially initialized variables are evaluated correctly. |Clause 11.1 |m |y
+|12 |Syn_1101_ValueVars_001 |Define variables in different scopes |Clause 11.1 |m |y
+|=============================================================================================================================================
+
+== Template variables
+
+.Template variables
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1102_TemplateVars_001 |Template variables should be assigned with unitialized variables |Clause 11.2 |m |y
+|2 |NegSem_1102_TemplateVars_002 |Partially initialized templates are evaluated correctly. |Clause 11.2 |m |n
+|3 |NegSem_1102_TemplateVars_003 |Dot notation referencing to a field, which actual value is `null` shall cause an error. |Clause 11.2 |m |n
+|4 |NegSem_1102_TemplateVars_004 |Index notation referencing to a set of, which actual value is `null` shall cause an error. |Clause 11.2 |m |n
+|5 |NegSyn_1102_TemplateVars_001 |Define template variables in module scope |Clause 11.2 |m |y
+|6 |NegSyn_1102_TemplateVars_002 |Template variables should be assigned with unitialized variables |Clause 11.2 |m |y
+|7 |Sem_1102_TemplateVars_001 |Define variables in different scopes |Clause 11.2 |m |y
+|8 |Sem_1102_TemplateVars_002 |Partially initialized templates are evaluated correctly. |Clause 11.2 |m |y
+|9 |Sem_1102_TemplateVars_003 |Partially initialized templates are evaluated correctly. |Clause 11.2 |m |y
+|10 |Syn_1102_TemplateVars_001 |Define template variables in different scopes |Clause 11.2 |m |y
+|============================================================================================================================================
+
+== Declaring timers
+
+.Declaring timers
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_12_toplevel_timer_001 |Ensure timer can not be initialized with negative duration |Clause 12 |m |y
+|2 |NegSem_12_toplevel_timer_002 |Ensure timer in array can not be initialized with negative duration |Clause 12 |m |y
+|3 |NegSem_12_toplevel_timer_003 |Ensure uninitialized timer can't be started |Clause 12 |m |y
+|4 |NegSem_12_toplevel_timer_004 |Ensure uninitialized timer in array can't be started |Clause 12 |m |y
+|5 |NegSem_12_toplevel_timer_005 |Ensure uninitialized timer in array can't be started |Clause 12 |m |y
+|6 |NegSem_12_toplevel_timer_006 |Ensure `timer declaration` `syntax` - reject single timer instance initialized with array |Clause 12 |m |y
+|7 |NegSem_12_toplevel_timer_007 |Ensure `timer declaration` syntax – reject array initialization with wrong number of initializers |Clause 12 |m |y
+|8 |NegSem_12_toplevel_timer_008 |Ensure `timer declaration` syntax – reject array of timers initizlized with a single float value |Clause 12 |m |y
+|9 |NegSyn_12_toplevel_timer_001 |Ensure timer can`t be used in module control parts when declared in components | Clause 12 | m |  y | | 10 | NegSyn_12_toplevel_timer_002 | Ensure `timer declaration` syntax | Clause 12 | m |  y | | 11 | NegSyn_12_toplevel_timer_003 | Ensure `timer declaration` syntax | Clause 12 | m |  y | | 12 | NegSyn_12_toplevel_timer_004 | Ensure `timer declaration` syntax | Clause 12 | m | y | | 13 | NegSyn_12_toplevel_timer_005 | Ensure `timer declaration` syntax | Clause 12 | m |  y | | 14 | NegSyn_12_toplevel_timer_006 | Ensure timer array declaration syntax | Clause 12 | m |  y | | 15 | NegSyn_12_toplevel_timer_007 | Ensure `timer array declaration` syntax | Clause 12 | m |  y | | 16 | Sem_12_toplevel_timer_001 | Ensure timer can be declared in components | Clause 12 | m |  y | | 17 | Sem_12_toplevel_timer_002 | Ensure timer can be declared in module control parts | Clause 12 | m |  y | | 18 | Sem_12_toplevel_timer_003 | Ensure timer can be declared in altsteps | Clause 12 | m |  y | | 19 | Sem_12_toplevel_timer_004 | Ensure timer can be declared in functions | Clause 12 | m |  y | | 20 | Sem_12_toplevel_timer_005 | Ensure timer can be declared in test cases | Clause 12 | m |  y | | 21 | Sem_12_toplevel_timer_006 | Ensure timer`s elapsed time is plausible |Clause 12 |m |y
+|22 |Sem_12_toplevel_timer_007 |Ensure timer can be declared in components but used in test cases |Clause 12 |m |y
+|23 |Sem_12_toplevel_timer_008 |Ensure timer can be declared in components but used in functions |Clause 12 |m |y
+|24 |Sem_12_toplevel_timer_009 |Ensure timer can be declared in components but used in altsteps |Clause 12 |m |y
+|25 |Syn_12_toplevel_timer_001 |Ensure non-initialized `timer declaration` syntax |Clause 12 |m |y
+|26 |Syn_12_toplevel_timer_002 |Ensure `timer array declaration` syntax |Clause 12 |m |y
+|27 |Syn_12_toplevel_timer_003 |Ensure definition of a list of timers is allowed as a single declaration |Clause 12 |m |y
+|28 |Syn_12_toplevel_timer_004 |Ensure `timer array initialization` syntax |Clause 12 |m |y
+|29 |Syn_12_toplevel_timer_005 |Ensure timer declaration with expression |Clause 12 |m |y
+|30 |Syn_12_toplevel_timer_006 |Ensure timer declaration with expression |Clause 12 |m |y
+|============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
+
+== Declaring messages
+
+.Declaring messages
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_13_declaring_msg_001 |Ensure received messages can be a combination of value and matching mechanism |Clause 13 |m |y
+|2 |Sem_13_declaring_msg_002 |Ensure received messages can`t be matched with wrong template |Clause 13 |m |y
+|3 |Sem_13_declaring_msg_003 |Ensure instances of messages can be declared by in-line templates |Clause 13 |m |y
+|4 |Sem_13_declaring_msg_004 |Ensure instances of messages can be declared by global templates |Clause 13 |m |y
+|5 |Sem_13_declaring_msg_005 |Ensure instances of messages can be declared and passed via template variables |Clause 13 |m |y
+|6 |Sem_13_declaring_msg_006 |Ensure instances of messages can be declared and passed via inline template |Clause 13 |m |y
+|7 |Sem_13_declaring_msg_007 |Ensure instances of messages can be declared and passed via parameter |Clause 13 |m |y
+|8 |Sem_13_declaring_msg_008 |Ensure instances of messages can be declared and passed via template parameter |Clause 13 |m |y
+|9 |Sem_13_declaring_msg_009 |Ensure instances of messages can be declared and passed via template parameter |Clause 13 |m |y
+|10 |Sem_13_toplevel_declaring_msg_various_types_001 |Port with type anytype can send and receive messages of any basic or structured type: `record' type. |Clause 13 |m |y
+|11 |Sem_13_toplevel_declaring_msg_various_types_002 |Port with type anytype can send and receive messages of any basic or structured type: `record of' type. |Clause 13 |m |y
+|12 |Sem_13_toplevel_declaring_msg_various_types_003 |Port with type anytype can send and receive messages of any basic or structured type: `enum' type. |Clause 13 |m |y
+|13 |Sem_13_toplevel_declaring_msg_various_types_004 |Port with type anytype can send and receive messages of any basic or structured type: `set' type. |Clause 13 |m |y
+|14 |Sem_13_toplevel_declaring_msg_various_types_005 |Port with type anytype can send and receive messages of any basic or structured type: `union' type. |Clause 13 |m |y
+|15 |Sem_13_toplevel_declaring_msg_various_types_006 |Port with type anytype can send and receive messages of any basic or structured type: `bitstring' type. |Clause 13 |m |y
+|16 |Sem_13_toplevel_declaring_msg_various_types_007 |Port with type anytype can send and receive messages of any basic or structured type: `boolean' type. |Clause 13 |m |y
+|17 |Sem_13_toplevel_declaring_msg_various_types_008 |Port with type anytype can send and receive messages of any basic or structured type: `charstring' type. |Clause 13 |m |y
+|18 |Sem_13_toplevel_declaring_msg_various_types_009 |Port with type anytype can send and receive messages of any basic or structured type: `float' type. |Clause 13 |m |y
+|19 |Sem_13_toplevel_declaring_msg_various_types_010 |Port with type anytype can send and receive messages of any basic or structured type: `hexstring' type. |Clause 13 |m |y
+|20 |Sem_13_toplevel_declaring_msg_various_types_011 |Port with type anytype can send and receive messages of any basic or structured type: `integer' type. |Clause 13 |m |y
+|21 |Sem_13_toplevel_declaring_msg_various_types_012 |Port with type anytype can send and receive messages of any basic or structured type: `octetstring' type. |Clause 13 |m |y
+|22 |Sem_13_toplevel_declaring_msg_various_types_013 |Port with type anytype can send and receive messages of any basic or structured type: `universal charstring' type. |Clause 13 |m |n
+|23 |Sem_13_toplevel_declaring_msg_various_types_014 |Port with type anytype can send and receive messages of any basic or structured type: `verdicttype' type. |Clause 13 |m |y
+|========================================================================================================================================================================================
+
+== Declaring procedure signatures
+
+.Declaring procedure signatures
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1400_procedure_signatures_001 |Nonblocking signature contains `in` parameter |Clause 14 |m |y
+|1 |NegSem_1400_procedure_signatures_002 |Blocking calls needs response or exception handling |Clause 14 |m |y
+|2 |Sem_1400_procedure_signatures_001 |The IUT calls signature exception |Clause 14 |m |y
+|3 |Sem_1400_procedure_signatures_002 |With noblock signature the IUT can raise exception |Clause 14 |m |y
+|4 |Sem_1400_procedure_signatures_003 |Non blocking signatures can raise exception |Clause 14 |m |y
+|5 |Sem_1400_procedure_signatures_004 |Multiple calls can be send without ack using non-blocking signature |Clause 14 |m |y
+|==========================================================================================================================
+
+== Declaring templates
+
+.Declaring templates
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_15_TopLevel_001 |A template formed from a union is rejected when the union somehow contains a default type field. |Clause 15 |m |n
+|2 |NegSem_15_TopLevel_002 |A template formed from a union is rejected when the union somehow contains a port type field. |Clause 15 |m |n
+|3 |NegSem_15_TopLevel_003 |A template shall not be of default type. |Clause 15 |m |n
+|4 |NegSem_15_TopLevel_004 |A template shall not be of port type. |Clause 15 |m |n
+|5 |NegSyn_15_TopLevel_001 |The expression or template body initializing a template shall evaluate to a value or template, which is type compatible with the template being declared |Clause 15 |m |y
+|6 |Syn_15_TopLevel_001 |A simple template with a single charstring field is accepted. |Clause 15 |m |y
+|====================================================================================================================================================================================================
+
+== Declaring message templates
+
+.Declaring message templates
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_1501_DeclaringMessageTemplates_001 |A simple record-based message template can be defined. |Clause 15.1 |m |y
+|2 |Syn_1501_DeclaringMessageTemplates_002 |A simple record-based message template with a wildcard ? is accepted. |Clause 15.1 |m |y
+|3 |Syn_1501_DeclaringMessageTemplates_003 |A simple record-based message template can be defined with a pattern in a charstring field. |Clause 15.1 |m |y
+|4 |Syn_1501_DeclaringMessageTemplates_004 |A primitive type template can be defined with a ? wildcard. |Clause 15.1 |m |y
+|5 |Syn_1501_DeclaringMessageTemplates_005 |A primitive type template can be defined with a one-of notation. |Clause 15.1 |m |y
+|6 |Syn_1501_DeclaringMessageTemplates_006 |All port operations are accepted. |Clause 15.1 |m |y
+|=========================================================================================================================================================
+
+== Declaring signature templates
+
+.Declaring signature templates
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_1502_DeclaringSignatureTemplates_001 |Test in-line templates for accepting procedure replies. |Clause 15.2 |m |y
+|2 |Sem_1502_DeclaringSignatureTemplates_002 |Test in-line templates for accepting procedure replies. |Clause 15.2 |m |y
+|3 |Sem_1502_DeclaringSignatureTemplates_003 |Test in-line templates for accepting procedure replies. |Clause 15.2 |m |n
+|4 |Syn_1502_DeclaringSignatureTemplates_001 |Signature templates with explicit values are accepted. |Clause 15.2 |m |y
+|5 |Syn_1502_DeclaringSignatureTemplates_002 |Signature templates with wildcards are accepted. |Clause 15.2 |m |y
+|6 |Syn_1502_DeclaringSignatureTemplates_003 |The basic operations `call` and `getreply` are accepted. |Clause 15.2 |m |y
+|7 |Syn_1502_DeclaringSignatureTemplates_004 |The `raise` and `catch` operations are accepted. |Clause 15.2 |m |y
+|=======================================================================================================================
+
+== Global and local templates
+
+.Global and local templates
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1503_GlobalAndLocalTemplates_001 |There's an error for re-assignment of a global non-parameterized template |Clause 15.3 |m |y
+|2 |NegSem_1503_GlobalAndLocalTemplates_002 |There's an error for re-assignment of a global non-parameterized template |Clause 15.3 |m |y
+|3 |NegSem_1503_GlobalAndLocalTemplates_003 |There's an error for re-assignment of a global parameterized template |Clause 15.3 |m |y
+|4 |NegSem_1503_GlobalAndLocalTemplates_004 |There's an error for re-assignment of a local parameterized template |Clause 15.3 |m |y
+|5 |NegSyn_1503_GlobalAndLocalTemplates_001 |There's an error if no value is assigned in a global non-parameterized template declaration |Clause 15.3 |m |y
+|6 |NegSyn_1503_GlobalAndLocalTemplates_002 |There's an error if no value is assigned in a local non-parameterized template declaration |Clause 15.3 |m |y
+|7 |NegSyn_1503_GlobalAndLocalTemplates_003 |There's an error if no value is assigned in a global parameterized template declaration |Clause 15.3 |m |y
+|8 |NegSyn_1503_GlobalAndLocalTemplates_004 |There's an error if no value is assigned in a local parameterized template declaration |Clause 15.3 |m |y
+|9 |Sem_1503_GlobalAndLocalTemplates_001 |A template values can be accessed with the dot notation as expected. |Clause 15.3 |m |y
+|10 |Sem_1503_GlobalAndLocalTemplates_002 |A template actual parameter is passed through correctly. |Clause 15.3 |m |y
+|11 |Sem_1503_GlobalAndLocalTemplates_003 |A `send` operation with actual parameters of a global parameterized template is accepted. |Clause 15.3 |m |y
+|12 |Sem_1503_GlobalAndLocalTemplates_004 |A parameterized local template in a test case is accepted. |Clause 15.3 |m |n
+|13 |Sem_1503_GlobalAndLocalTemplates_005 |A `send` operation with actual parameters of a global parameterized template is accepted with the actual parameter being a template parameter. |Clause 15.3 |m |y
+|14 |Sem_1503_GlobalAndLocalTemplates_006 |A `send` operation with actual parameters of a global parameterized template is accepted with the actual parameter being an inline template. |Clause 15.3 |m |y
+|15 |Syn_1503_GlobalAndLocalTemplates_001 |A global parameterized template is accepted. |Clause 15.3 |m |y
+|16 |Syn_1503_GlobalAndLocalTemplates_004 |A parameterized local template in the control part is accepted. |Clause 15.3 |m |n
+|17 |Syn_1503_GlobalAndLocalTemplates_005 |A parameterized local template in a function is accepted. |Clause 15.3 |m |n
+|18 |Syn_1503_GlobalAndLocalTemplates_006 |A parameterized local template in an altstep is accepted. |Clause 15.3 |m |n
+|=========================================================================================================================================================================================================
+
+== In-line templates
+
+.In-line templates
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_1504_InlineTemplates_001 |Inline templates are accepted. |Clause 15.4 |m |y
+|2 |Syn_1504_InlineTemplates_002 |Modified parameterized inline templates are accepted. |Clause 15.4 |m |y
+|3 |Syn_1504_InlineTemplates_003 |Modified plain inline templates are accepted. |Clause 15.4 |m |y
+|=========================================================================================================
+
+== Modified templates
+
+.Modified templates
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1505_ModifiedTemplates_001 |A modified template does not refer to itself. |Clause 15.5 |m |y
+|2 |NegSem_1505_ModifiedTemplates_002 |A modified template does not omit possible parameters of the base template. |Clause 15.5 |m |y
+|3 |NegSem_1505_ModifiedTemplates_003 |A modified template does not omit possible parameters introduced in any modification step. |Clause 15.5 |m |y
+|4 |NegSem_1505_ModifiedTemplates_004 |Parameter names in modified templates are the same. |Clause 15.5 |m |y
+|5 |NegSem_1505_ModifiedTemplates_005 |The dash in default parameter values of a modified templates is only accepted when the base template actually has a default value. |Clause 15.5 |m |y
+|6 |NegSem_1505_ModifiedTemplates_006 |The same parameter name is used when modifying the base template. |Clause 15.5 |m |y
+|7 |NegSem_1505_ModifiedTemplates_007 |The same parameter type is used when modifying the base template. |Clause 15.5 |m |y
+|8 |NegSyn_1505_ModifiedTemplates_001 |The base tamplate and modified template cannot be the same |Clause 15.5 |m |y
+|9 |Sem_1505_ModifiedTemplates_001 |The values of plain modified template definitions are as expected. |Clause 15.5 |m |y
+|10 |Sem_1505_ModifiedTemplates_002 |A modified template of a record of type using index notation access works as expected. |Clause 15.5 |m |y
+|11 |Sem_1505_ModifiedTemplates_003 |Default values in formal parameters of modified templates are working as expected. |Clause 15.5 |m |y
+|12 |Sem_1505_ModifiedTemplates_004 |Default values in formal parameters of modified templates are working as expected when the modified template uses the dash for the default value. |Clause 15.5 |m |y
+|13 |Sem_1505_ModifiedTemplates_005 |Default values in formal parameters of modified templates are working as expected |Clause 15.5 |m |y
+|14 |Sem_1505_ModifiedTemplates_006 |Default values in formal parameters of modified templates are working as expected |Clause 15.5 |m |y
+|15 |Sem_1505_ModifiedTemplates_007 |Default values in formal parameters of modified templates are working as expected. |Clause 15.5 |m |y
+|16 |Sem_1505_ModifiedTemplates_008 |The values of plain modified template definitions are as expected. |Clause 15.5 |m |y
+|17 |Sem_1505_ModifiedTemplates_009 |Default values in formal parameters of modified templates are working as expected. |Clause 15.5 |m |y
+|18 |Sem_1505_ModifiedTemplates_010 |Default values in formal parameters of modified templates are working as expected. |Clause 15.5 |m |y
+|19 |Syn_1505_ModifiedTemplates_001 |Plain modified template definitions are accepted. |Clause 15.5 |m |y
+|20 |Syn_1505_ModifiedTemplates_002 |A modified template does not omit possible parameters introduced in any modification step. |Clause 15.5 |m |y
+|21 |Syn_1505_ModifiedTemplates_003 |The default values in formal parameters of modified templates are accepted. |Clause 15.5 |m |y
+|22 |Syn_1505_ModifiedTemplates_004 |Dash as default parameter values are accepted. |Clause 15.5 |m |y
+|========================================================================================================================================================================================================
+
+== Referencing individual string elements
+
+.Referencing individual string elements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_150601_ReferencingIndividualStringElements_001 |The referencing of individual string elements inside templates or template fields is forbidden. |Clause 15.6.1 |m |y
+|==============================================================================================================================================================================
+
+== Referencing record and set fields
+
+.Referencing record and set fields
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_150602_ReferencingRecordAndSetFields_001 |Fields with omit values on the right-hand side of an assignment are rejected. |Clause 15.6.2 |m |y
+|2 |NegSem_150602_ReferencingRecordAndSetFields_002 |Fields with * values on the right-hand side of an assignment are rejected |Clause 15.6.2 |m |n
+|3 |NegSem_150602_ReferencingRecordAndSetFields_003 |Value lists on the right-hand side of an assignment are not accepted. |Clause 15.6.2 |m |y
+|4 |NegSem_150602_ReferencingRecordAndSetFields_004 |Complement lists on the right-hand side of an assignment are not accepted. |Clause 15.6.2 |m |y
+|5 |NegSem_150602_ReferencingRecordAndSetFields_005 |Referencing a template field with the `ifpresent` attribute causes a rejection. |Clause 15.6.2 |m |y
+|6 |NegSem_150602_ReferencingRecordAndSetFields_006 |Referencing a field of an address type, which actual value is `null` shall cause rejection. |Clause 15.6.2 |m |n
+|7 |Sem_150602_ReferencingRecordAndSetFields_001 |? shall be returned for mandatory subfields and * shall be returned for optional subfields. |Clause 15.6.2 |m |y
+|8 |Sem_150602_ReferencingRecordAndSetFields_002 |The recurisve anyvalue expansion is performed correctly when new values are assigned. |Clause 15.6.2 |m |y
+|9 |Sem_150602_ReferencingRecordAndSetFields_003 |? shall be returned for mandatory subfields and * shall be returned for optional subfields. |Clause 15.6.2 |m |n
+|10 |Sem_150602_ReferencingRecordAndSetFields_004 |? shall be returned for mandatory subfields and * shall be returned for optional subfields. |Clause 15.6.2 |m |n
+|==================================================================================================================================================================
+
+== Referencing record of and set of elements
+
+.Referencing record of and set of elements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_150603_ReferencingRecordOfAndSetElements_001 |Referencing an element within a value list causes an error in the context of record of. |Clause 15.6.3 |m |y
+|2 |NegSem_150603_ReferencingRecordOfAndSetElements_002 |Access to unitialized fields in the context of record of is rejected. |Clause 15.6.3 |m |y
+|3 |NegSem_150603_ReferencingRecordOfAndSetElements_003 |Anyvalueornone fields in the context of record of is rejected. |Clause 15.6.3 |m |y
+|4 |NegSem_150603_ReferencingRecordOfAndSetElements_004 |Complement value lists in the context of record of are rejected. |Clause 15.6.3 |m |y
+|5 |NegSem_150603_ReferencingRecordOfAndSetElements_005 |Subset in the context of record of are rejected. |Clause 15.6.3 |m |y
+|6 |NegSem_150603_ReferencingRecordOfAndSetElements_006 |Superset in the context of record of are rejected. |Clause 15.6.3 |m |y
+|7 |NegSem_150603_ReferencingRecordOfAndSetElements_007 |Access into permutation in record of templates is forbidden. |Clause 15.6.3 |m |n
+|8 |NegSem_150603_ReferencingRecordOfAndSetElements_008 |Access to record of indexes is forbidden when a previous index entry is a permutation with a *. |Clause 15.6.3 |m |y
+|9 |NegSem_150603_ReferencingRecordOfAndSetElements_009 |Access to ifpresent fields is not allowed. |Clause 15.6.3 |m |y
+|10 |NegSem_150603_ReferencingRecordOfAndSetElements_010 |Referencing AnyValueOrNone fields is not allowed. |Clause 15.6.3 |m |y
+|11 |NegSem_150603_ReferencingRecordOfAndSetElements_011 |Referencing uninitialized fields is not allowed. |Clause 15.6.3 |m |y
+|12 |NegSem_150603_ReferencingRecordOfAndSetElements_012 |Referencing uninitialized fields is not allowed. |Clause 15.6.3 |m |y
+|13 |NegSem_150603_ReferencingRecordOfAndSetElements_013 |Referencing uninitialized fields is not allowed. |Clause 15.6.3 |m |y
+|14 |NegSem_150603_ReferencingRecordOfAndSetElements_014 |Referencing an element within a value list causes an error in the context of set of. |Clause 15.6.3 |m |y
+|15 |NegSem_150603_ReferencingRecordOfAndSetElements_015 |Referencing an element of an address type, which actual value is `null` shall cause an error. |Clause 15.6.3 |m |n
+|16 |Sem_150603_ReferencingRecordOfAndSetElements_001 |Assignment of an anyvalue on the right hand side yields an anyvalue in the context of record of. |Clause 15.6.3 |m |y
+|17 |Sem_150603_ReferencingRecordOfAndSetElements_002 |Assignment to a anyvalue in the context of record of is handled correctly. |Clause 15.6.3 |m |y
+|18 |Sem_150603_ReferencingRecordOfAndSetElements_003 |Assignment to a anyvalue in the context of record of is handled correctly in two subsequent assignments. |Clause 15.6.3 |m |n
+|19 |Sem_150603_ReferencingRecordOfAndSetElements_004 |Assignment to a anyvalue in the context of record of is handled correctly when the first element is changed. |Clause 15.6.3 |m |y
+|20 |Sem_150603_ReferencingRecordOfAndSetElements_005 |Access outside permutation fields is allowed and works as expected. |Clause 15.6.3 |m |y
+|21 |Sem_150603_ReferencingRecordOfAndSetElements_006 |Referencing an element within a record of, set of or array field to which omit is assigned works as expected |Clause 15.6.3 |m |y
+|22 |Sem_150603_ReferencingRecordOfAndSetElements_007 |Referencing an element within a record of, set of or array field to which omit is assigned works as expected |Clause 15.6.3 |m |n
+|=======================================================================================================================================================================================
+
+== Referencing signature parameters
+
+.Referencing signature parameters
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_150604_ReferencingSignatureParameters_001 |Test modification of signature parameters. |Clause 15.6.4 |m |n
+|2 |Sem_150604_ReferencingSignatureParameters_001 |Test modification of signature parameters. |Clause 15.6.4 |m |y
+|====================================================================================================================
+
+== Referencing union alternatives
+
+.Referencing union alternatives
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_150605_Referencing_union_alternatives_001 |Template variables does not allow referencing alternatives inside an union with omit |Clause 15.6.5 |m |y
+|2 |NegSem_150605_Referencing_union_alternatives_002 |Template variables does not allow referencing alternatives inside an union with AnyValueOrNone |Clause 15.6.5 |m |y
+|3 |NegSem_150605_Referencing_union_alternatives_003 |Template variables does not allow referencing alternatives inside an union with list |Clause 15.6.5 |m |n
+|4 |NegSem_150605_Referencing_union_alternatives_004 |Template variables does not allow referencing alternatives inside an union with complemented list |Clause 15.6.5 |m |n
+|5 |NegSem_150605_Referencing_union_alternatives_005 |Referencing an alternative of a union template field to which the `ifpresent` attribute is attached, shall cause an error |Clause 15.6.5 |m |n
+|6 |NegSem_150605_Referencing_union_alternatives_006 |Referencing an alternative of an address type, which actual value is `null` shall cause |Clause 15.6.5 |m |n
+|7 |Sem_150605_Referencing_union_alternatives_001 |Template variables allow referencing alternatives inside a union template definition |Clause 15.6.5 |m |y
+|8 |Sem_150605_Referencing_union_alternatives_002 |Template variables allow referencing with an Anyvalue union template |Clause 15.6.5 |m |n
+|9 |Sem_150605_Referencing_union_alternatives_003 |Template variables allow referencing with an Anyvalue union template |Clause 15.6.5 |m |y
+|10 |Sem_150605_Referencing_union_alternatives_004 |Template variables allow referencing with an Anyvalue union template |Clause 15.6.5 |m |y
+|=================================================================================================================================================================================================
+
+== Template restrictions
+
+.Template restrictions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1508_TemplateRestrictions_001 |Template(omit) is rejected with anyvalue(?). |Clause 15.8 |m |y
+|2 |NegSem_1508_TemplateRestrictions_002 |Template(omit) is rejected with setof template. |Clause 15.8 |m |y
+|3 |NegSem_1508_TemplateRestrictions_003 |Template(omit) is rejected with anyvalueornone(*). |Clause 15.8 |m |y
+|4 |NegSem_1508_TemplateRestrictions_004 |Template(omit) is rejected with value ranges. |Clause 15.8 |m |y
+|5 |NegSem_1508_TemplateRestrictions_005 |Template(omit) is rejected with supersets. |Clause 15.8 |m |y
+|6 |NegSem_1508_TemplateRestrictions_006 |Template(omit) is rejected with subsets. |Clause 15.8 |m |y
+|7 |NegSem_1508_TemplateRestrictions_007 |Template(omit) is rejected with patterns. |Clause 15.8 |m |y
+|8 |NegSem_1508_TemplateRestrictions_008 |Template(omit) is rejected with anyelement inside values. |Clause 15.8 |m |y
+|9 |NegSem_1508_TemplateRestrictions_009 |Template(omit) is rejected with anyelemenornone inside values. |Clause 15.8 |m |y
+|10 |NegSem_1508_TemplateRestrictions_010 |Template(omit) is rejected with permutation inside values. |Clause 15.8 |m |y
+|11 |NegSem_1508_TemplateRestrictions_011 |Template(omit) is rejected with length restrictions. |Clause 15.8 |m |y
+|12 |NegSem_1508_TemplateRestrictions_012 |Template(omit) is rejected with length restrictions. |Clause 15.8 |m |y
+|13 |NegSem_1508_TemplateRestrictions_013 |Template(omit) is rejected with length restrictions. |Clause 15.8 |m |y
+|14 |NegSem_1508_TemplateRestrictions_014 |Template(value) is rejected with anyvalue(?). |Clause 15.8 |m |y
+|15 |NegSem_1508_TemplateRestrictions_015 |Template(value) is rejected with valuelist. |Clause 15.8 |m |y
+|16 |NegSem_1508_TemplateRestrictions_016 |Template(value) is rejected with anyvalueornone(*). |Clause 15.8 |m |y
+|17 |NegSem_1508_TemplateRestrictions_017 |Template(value) is rejected with value ranges. |Clause 15.8 |m |y
+|18 |NegSem_1508_TemplateRestrictions_018 |Template(value) is rejected with supersets. |Clause 15.8 |m |y
+|19 |NegSem_1508_TemplateRestrictions_019 |Template(value) is rejected with supersets. |Clause 15.8 |m |y
+|20 |NegSem_1508_TemplateRestrictions_020 |Template(value) is rejected with patterns. |Clause 15.8 |m |y
+|21 |NegSem_1508_TemplateRestrictions_021 |Template(value) is rejected with anyelement inside values. |Clause 15.8 |m |y
+|22 |NegSem_1508_TemplateRestrictions_022 |Template(value) is rejected with permutation inside values. |Clause 15.8 |m |y
+|23 |NegSem_1508_TemplateRestrictions_023 |Template(value) is rejected with length restrictions. |Clause 15.8 |m |y
+|24 |NegSem_1508_TemplateRestrictions_024 |Template(value) is rejected with length restrictions. |Clause 15.8 |m |y
+|25 |NegSem_1508_TemplateRestrictions_025 |Template(present) refuses omit value as a whole. |Clause 15.8 |m |y
+|26 |NegSem_1508_TemplateRestrictions_026 |Template(value) refuses omit as a whole. |Clause 15.8 |m |y
+|27 |NegSem_1508_TemplateRestrictions_027 |ensure that symbols created during template expansion are checked against omit template restriction |Clause 15.8 |m |n
+|28 |NegSem_1508_TemplateRestrictions_028 |ensure that symbols created during template expansion are checked against value template restriction |Clause 15.8 |m |n
+|29 |NegSem_1508_TemplateRestrictions_029 |The template(present) with anyvalue(?) can't be assigned to an omit restricted variable template |Clause 15.8 |m |y
+|30 |NegSem_1508_TemplateRestrictions_030 |Unrestricted template with anyvalue(?) can't be assigned to an omit restricted variable template |Clause 15.8 |m |y
+|31 |NegSem_1508_TemplateRestrictions_031 |Template(omit) can't be assigned to a variable template(value) if omit |Clause 15.8 |m |y
+|32 |NegSem_1508_TemplateRestrictions_032 |Template(present) can't be assigned to a template(value) variable if contains anyvalueornone(*) |Clause 15.8 |m |y
+|33 |NegSem_1508_TemplateRestrictions_033 |An unrestricted template can't be assigned to a template(value) variable if contains anyvalueornone(*) |Clause 15.8 |m |y
+|34 |NegSem_1508_TemplateRestrictions_034 |A template with omit restriction can't be assigned to a template(present)variable if omit |Clause 15.8 |m |y
+|35 |NegSem_1508_TemplateRestrictions_035 |An unrestricted template can't be assigned to a template(present)variable if omit |Clause 15.8 |m |y
+|36 |NegSem_1508_TemplateRestrictions_036 |Template(present) can't be parameter to a template(omit) if contains anyvalueornone(*) |Clause 15.8 |m |y
+|37 |NegSem_1508_TemplateRestrictions_037 |Template(present) can't be parameter to template(omit) if contains anyvalue(?) |Clause 15.8 |m |y
+|38 |NegSem_1508_TemplateRestrictions_038 |Template(present) can't be parameter to template(value) if it contains anyvalueornone(*) |Clause 15.8 |m |y
+|39 |NegSem_1508_TemplateRestrictions_039 |Unrestricted template can't be parameter to template(value) if it contains anyvalueornone(*) |Clause 15.8 |m |y
+|40 |NegSem_1508_TemplateRestrictions_040 |Template(present) can't be parameter to a template(omit) |Clause 15.8 |m |y
+|41 |NegSem_1508_TemplateRestrictions_041 |Unrestricted template cannot be parameter to template(value) |Clause 15.8 |m |y
+|42 |NegSem_1508_TemplateRestrictions_042 |Template(present) cannot be parameter to template(value) |Clause 15.8 |m |y
+|43 |NegSem_1508_TemplateRestrictions_043 |Template(present) cannot be parameter to template(omit) |Clause 15.8 |m |y
+|44 |NegSem_1508_TemplateRestrictions_044 |The restrictiveness of parameters template(value)->template(present) is handled correctly. |Clause 15.8 |m |y
+|45 |NegSem_1508_TemplateRestrictions_045 |The restrictiveness of parameters template(value)->template(omit) is handled correctly. |Clause 15.8 |m |y
+|46 |NegSem_1508_TemplateRestrictions_046 |The restrictiveness of parameters template(value)->template is handled correctly. |Clause 15.8 |m |y
+|47 |NegSem_1508_TemplateRestrictions_047 |The restrictiveness of parameters template(omit)->template(present) is handled correctly. |Clause 15.8 |m |y
+|48 |NegSem_1508_TemplateRestrictions_048 |The restrictiveness of parameters template(omit)->template(present) is handled correctly. |Clause 15.8 |m |y
+|49 |NegSem_1508_TemplateRestrictions_049 |The restrictiveness of parameters template(omit)->template(present) is handled correctly. |Clause 15.8 |m |y
+|50 |NegSem_1508_TemplateRestrictions_050 |Decoded content match is not allowed for omit template restriction |Clause 15.8 |m |y
+|51 |NegSem_1508_TemplateRestrictions_051 |Decoded content match is not allowed for omit template restriction |Clause 15.8 |m |y
+|52 |Sem_1508_TemplateRestrictions_001 |A value can be assigned to a template(omit) variable. |Clause 15.8 |m |y
+|53 |Sem_1508_TemplateRestrictions_002 |A template(omit) can be assigned to a template(omit) variable. |Clause 15.8 |m |y
+|54 |Sem_1508_TemplateRestrictions_003 |A template(value) can be assigned to a template(omit) variable. |Clause 15.8 |m |y
+|55 |Sem_1508_TemplateRestrictions_004 |A value can be assigned to a template(value) variable. |Clause 15.8 |m |y
+|56 |Sem_1508_TemplateRestrictions_005 |A template(value) can be assigned to a template(value) variable. |Clause 15.8 |m |y
+|57 |Sem_1508_TemplateRestrictions_006 |A value can be assigned to a template(present) variable. |Clause 15.8 |m |y
+|58 |Sem_1508_TemplateRestrictions_007 |A template(omit) can be assigned to a template(present) variable. |Clause 15.8 |m |y
+|59 |Sem_1508_TemplateRestrictions_008 |A template(value) can be assigned to a template(present) variable. |Clause 15.8 |m |y
+|60 |Sem_1508_TemplateRestrictions_009 |A template(present) can be assigned to a template(present) variable. |Clause 15.8 |m |y
+|61 |Sem_1508_TemplateRestrictions_010 |A value can be assigned to a template variable. |Clause 15.8 |m |y
+|62 |Sem_1508_TemplateRestrictions_011 |A template(omit) can be assigned to a template variable. |Clause 15.8 |m |y
+|63 |Sem_1508_TemplateRestrictions_012 |A template(value) can be assigned to a template variable. |Clause 15.8 |m |y
+|64 |Sem_1508_TemplateRestrictions_013 |A template(present) can be assigned to a template variable. |Clause 15.8 |m |y
+|65 |Sem_1508_TemplateRestrictions_014 |A template can be assigned to a template variable. |Clause 15.8 |m |y
+|66 |Sem_1508_TemplateRestrictions_015 |A base template can be modified without restrictions. |Clause 15.8 |m |y
+|67 |Sem_1508_TemplateRestrictions_016 |A base template can be modified with template(present) restriction. |Clause 15.8 |m |y
+|68 |Sem_1508_TemplateRestrictions_017 |A base template can be modified with template(omit) restriction. |Clause 15.8 |m |y
+|69 |Sem_1508_TemplateRestrictions_018 |A base template can be modified with template(value) restriction. |Clause 15.8 |m |y
+|70 |Sem_1508_TemplateRestrictions_019 |A template(present) base template can be modified with template(present) restriction. |Clause 15.8 |m |y
+|71 |Sem_1508_TemplateRestrictions_020 |A template(present) base template can be modified with template(value) restriction. |Clause 15.8 |m |y
+|72 |Sem_1508_TemplateRestrictions_021 |A template(omit) base template can be modified with template(omit) restriction. |Clause 15.8 |m |y
+|73 |Sem_1508_TemplateRestrictions_022 |A template(omit) base template can be modified with template(value) restriction. |Clause 15.8 |m |y
+|74 |Sem_1508_TemplateRestrictions_023 |A template(value) base template can be modified with template(value) restriction. |Clause 15.8 |m |y
+|75 |Sem_1508_TemplateRestrictions_024 |Template(present) base templates are allowed to be modified to template(omit). |Clause 15.8 |m |y
+|76 |Sem_1508_TemplateRestrictions_025 |Template(omit) base templates are allowed to be modified to template(present). |Clause 15.8 |m |y
+|77 |Sem_1508_TemplateRestrictions_026 |Template(value) base templates are allowed to be modified to template(present). |Clause 15.8 |m |y
+|78 |Sem_1508_TemplateRestrictions_027 |Template(value) base templates are allowed to be modified to template(omit). |Clause 15.8 |m |y
+|79 |Sem_1508_TemplateRestrictions_028 |Template(value) base templates are allowed to be modified to template. |Clause 15.8 |m |y
+|80 |Sem_1508_TemplateRestrictions_029 |Template(omit) base templates are allowed to be modified to template. |Clause 15.8 |m |y
+|81 |Sem_1508_TemplateRestrictions_030 |Template(present) base templates are allowed to be modified to template. |Clause 15.8 |m |y
+|82 |Sem_1508_TemplateRestrictions_031 |Template (omit) can be parameter to template(present) if it contains omit |Clause 15.8 |m |y
+|83 |Sem_1508_TemplateRestrictions_032 |An unrestricted template can't be parameter to template(present) if it contains omit |Clause 15.8 |m |y
+|84 |Sem_1508_TemplateRestrictions_033 |An unrestricted template can be parameter to template(present) |Clause 15.8 |m |y
+|85 |Sem_1508_TemplateRestrictions_034 |Template (omit) can be parameter to template(present) |Clause 15.8 |m |y
+|86 |Sem_1508_TemplateRestrictions_035 |Template(omit) can be parameter to template(value) if it is omit |Clause 15.8 |m |y
+|87 |Sem_1508_TemplateRestrictions_036 |Template(omit) can be parameter to template(value) |Clause 15.8 |m |y
+|88 |Sem_1508_TemplateRestrictions_037 |Decoded content match is allowed for present template restriction |Clause 15.8 |m |y
+|89 |Syn_1508_TemplateRestrictions_001 |Template(omit) is accepted with value omit value. |Clause 15.8 |m |y
+|90 |Syn_1508_TemplateRestrictions_002 |Template(omit) is accepted with a concrete value. |Clause 15.8 |m |y
+|91 |Syn_1508_TemplateRestrictions_003 |Template(value) is accepted with a concrete value. |Clause 15.8 |m |y
+|92 |Syn_1508_TemplateRestrictions_004 |Template(present) is accepted with a concrete value. |Clause 15.8 |m |y
+|===================================================================================================================================================================
+
+== `Match` operation
+
+.`Match` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1509_MatchOperation_001 |The `match` operation refuses two templates as actual parameters. |Clause 15.9 |m |y
+|2 |NegSem_1509_MatchOperation_002 |The `match` operation refuses not initialized operands |Clause 15.9 |m |n
+|3 |NegSem_1509_MatchOperation_003 |The `match` operation works correctly with enums |Clause 15.9 |m |y
+|4 |Sem_1509_MatchOperation_001 |The `match` operation works as expected on a template with range restriction when the tested value is inside the range. |Clause 15.9 |m |y
+|5 |Sem_1509_MatchOperation_002 |The `match` operation works as expected on a template with range restriction when the tested value is outside the range. |Clause 15.9 |m |y
+|6 |Sem_1509_MatchOperation_003 |The `match` operation works correctly on records in the positive case. |Clause 15.9 |m |y
+|7 |Sem_1509_MatchOperation_004 |The `match` operation works correctly on records in the negative case. |Clause 15.9 |m |y
+|8 |Sem_1509_MatchOperation_005 |The `match` operation works correctly if the types are incompatible. |Clause 15.9 |m |n
+|9 |Sem_1509_MatchOperation_006 |The `match` operation works correctly on records with optional fields in the positive case. |Clause 15.9 |m |y
+|10 |Sem_1509_MatchOperation_007 |The `match` operation works correctly on sets in the positive case. |Clause 15.9 |m |y
+|11 |Sem_1509_MatchOperation_008 |The `match` operation works correctly on sets in the negative case. |Clause 15.9 |m |y
+|12 |Sem_1509_MatchOperation_009 |The `match` operation works correctly if the set types are incompatible. |Clause 15.9 |m |n
+|13 |Sem_1509_MatchOperation_010 |The `match` operation works correctly on sets with optional fields in the positive case. |Clause 15.9 |m |y
+|14 |Sem_1509_MatchOperation_011 |Matching a value expression against a template instance which evaluates to the omit matching mechanism shall return false |Clause 15.9 |m |y
+|15 |Sem_1509_MatchOperation_012 |If the `expression`-parameter evaluates to a literal value without explicit or implicit identification of its type, the type of the template `instance`-parameter shall be used as the type governor for the `expression`-parameter. |Clause 15.9 |m |y
+|16 |Sem_1509_MatchOperation_013 |If the `expression`-parameter evaluates to a literal value without explicit or implicit identification of its type, the type of the template instance-parameter shall be used as the type governor for the `expression`-parameter |Clause 15.9 |m |y
+|17 |Sem_1509_MatchOperation_014 |The `match` operation works correctly with enums |Clause 15.9 |m |n
+|18 |Sem_1509_MatchOperation_015 |The `match` operation works correctly with enums |Clause 15.9 |m |y
+|19 |Sem_1509_MatchOperation_016 |The `match` operation works correctly with enums |Clause 15.9 |m |y
+|==================================================================================================================================================================================================================================================================================
+
+== `Valueof` operation
+
+.`Valueof` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1510_ValueOfOperation_001 |The `valueof` function works correctly on omit. |Clause 15.10 |m |y
+|2 |NegSem_1510_ValueOfOperation_002 |The `valueof` function works correctly on templates with wildcards. |Clause 15.10 |m |y
+|3 |NegSem_1510_ValueOfOperation_003 |The `valueof` function works correctly on regular value templates. |Clause 15.10 |m |y
+|4 |NegSem_1510_ValueOfOperation_004 |The `valueof` function works correctly on range templates. |Clause 15.10 |m |y
+|5 |NegSem_1510_ValueOfOperation_005 |check that runtime error occurs if `valueof` is applied to uninitialized template |Clause 15.10 |m |y
+|6 |NegSem_1510_ValueOfOperation_006 |check that runtime error occurs if `valueof` is applied to partially initialized template |Clause 15.10 |m |y
+|7 |Sem_1510_ValueOfOperation_001 |The `valueof` operation works as expected for fully initialized templates. |Clause 15.10 |m |y
+|================================================================================================================================================
+
+== Concatenating templates of string and list types
+
+.Concatenating templates of string and list types
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1511_ConcatenatingTemplatesOfStringAndListTypes_001 |Concatenation of octetstring types yields an even number of digits. |Clause 15.11 |m |y
+|2 |NegSem_1511_ConcatenatingTemplatesOfStringAndListTypes_002 |Concatenation of strings types yields an error if specified ranges are not fixed length. |Clause 15.11 |m |n
+|3 |NegSem_1511_ConcatenatingTemplatesOfStringAndListTypes_003 |A simple concatenation of non-wildcard octetstring must not yield in a non-even number of hexadecimals. |Clause 15.11 |m |y
+|4 |NegSem_1511_ConcatenatingTemplatesOfStringAndListTypes_004 |The inline template definitions are correctly concatenated. |Clause 15.11 |m |y
+|5 |NegSem_1511_ConcatenatingTemplatesOfStringAndListTypes_005 |The inline template definitions are correctly concatenated. |Clause 15.11 |m |y
+|6 |NegSem_1511_ConcatenatingTemplatesOfStringAndListTypes_006 |Concatenation of octetstring types and ? patterns works as expected. |Clause 15.11 |m |n
+|7 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_001 |Concatenation of charstring types works as expected (variant 1). |Clause 15.11 |m |y
+|8 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_002 |Concatenation of octetstring types works as expected (variant 2). |Clause 15.11 |m |y
+|9 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_003 |Concatenation of bitstring types works as expected. |Clause 15.11 |m |n
+|10 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_004 |Concatenation of octetstring types works as expected (variant 1). |Clause 15.11 |m |n
+|11 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_005 |Concatenation of octetstring types works as expected (variant 2). |Clause 15.11 |m |n
+|12 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_006 |A concatenation of charstrings with a fixed length AnyValueOrNone be matched. |Clause 15.11 |m |y
+|13 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_007 |Concatenations of record of charstrings are accepted. |Clause 15.11 |m |n
+|14 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_008 |Concatenations of record of charstrings work when parameterized. |Clause 15.11 |m |n
+|15 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_009 |Concatenations of set of integers are accepted. |Clause 15.11 |m |n
+|16 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_010 |The inline template definitions are correctly concatenated. |Clause 15.11 |m |y
+|17 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_011 |Concatenation of octetstring types works as expected (matching patterns in quotation). |Clause 15.11 |m |n
+|18 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_012 |Concatenation of octetstring types and ? patterns works as expected. |Clause 15.11 |m |y
+|19 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_013 |Concatenation of octetstring types and ? patterns works as expected. |Clause 15.11 |m |y
+|20 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_014 |Concatenation of charstring and universal charsting types are concatenated as expected. |Clause 15.11 |m |y
+|21 |Sem_1511_ConcatenatingTemplatesOfStringAndListTypes_015 |Concatenations of record of charstrings work when parameterized |Clause 15.11 |m |n
+|==========================================================================================================================================================================================
+
+== Functions
+
+.Functions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1601_toplevel_001 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|2 |NegSem_1601_toplevel_002 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|3 |NegSem_1601_toplevel_003 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|4 |NegSem_1601_toplevel_004 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|5 |NegSem_1601_toplevel_005 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|6 |NegSem_1601_toplevel_006 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|7 |Sem_1601_toplevel_001 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|8 |Sem_1601_toplevel_002 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|9 |Sem_1601_toplevel_003 |The IUT correctly handles function definitions |Clause 16.1 |m |y
+|==============================================================================================
+
+== Invoking functions
+
+.Invoking functions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_160101_invoking_functions_001 |The IUT correctly handles function invocations |Clause 16.1.1 |m |y
+|=========================================================================================================
+
+== Predefined functions
+
+.Predefined functions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_160102_predefined_functions_001 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|2 |NegSem_160102_predefined_functions_002 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|3 |NegSem_160102_predefined_functions_003 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|4 |NegSem_160102_predefined_functions_004 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|5 |NegSem_160102_predefined_functions_005 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|6 |NegSem_160102_predefined_functions_006 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|7 |NegSem_160102_predefined_functions_007 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|8 |NegSem_160102_predefined_functions_008 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|9 |NegSem_160102_predefined_functions_009 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|10 |NegSem_160102_predefined_functions_010 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|11 |NegSem_160102_predefined_functions_017 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|12 |NegSem_160102_predefined_functions_018 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|13 |NegSem_160102_predefined_functions_019 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|14 |NegSem_160102_predefined_functions_021 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|15 |NegSem_160102_predefined_functions_022 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|16 |NegSem_160102_predefined_functions_023 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|17 |NegSem_160102_predefined_functions_024 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|18 |NegSem_160102_predefined_functions_025 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|19 |NegSem_160102_predefined_functions_026 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|20 |NegSem_160102_predefined_functions_027 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|21 |NegSem_160102_predefined_functions_028 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|22 |NegSem_160102_predefined_functions_029 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|23 |NegSem_160102_predefined_functions_030 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|24 |NegSem_160102_predefined_functions_031 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|25 |NegSem_160102_predefined_functions_032 |An error is generated when the parameter of the `encvalue` function contains a matching symbol |Clause 16.1.2 |m |y
+|26 |NegSem_160102_predefined_functions_033 |An error is detected when the parameter of the `encvalue` function contains an unitialized value |Clause 16.1.2 |m |y
+|27 |NegSem_160102_predefined_functions_034 |An error is detected when the parameter of the `encvalue` function contains a partially initialized value |Clause 16.1.2 |m |y
+|28 |NegSem_160102_predefined_functions_035 |An error is detected when the first parameter of the `decvalue` function contains an uninitialized value |Clause 16.1.2 |m |y
+|29 |NegSem_160102_predefined_functions_036 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|30 |NegSem_160102_predefined_functions_037 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|31 |NegSem_160102_predefined_functions_038 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|32 |NegSem_160102_predefined_functions_039 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|33 |NegSem_160102_predefined_functions_040 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|34 |Sem_160102_predefined_functions_001 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|35 |Sem_160102_predefined_functions_002 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|36 |Sem_160102_predefined_functions_003 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|37 |Sem_160102_predefined_functions_004 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|38 |Sem_160102_predefined_functions_005 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|39 |Sem_160102_predefined_functions_006 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|40 |Sem_160102_predefined_functions_007 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|41 |Sem_160102_predefined_functions_008 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|42 |Sem_160102_predefined_functions_009 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|43 |Sem_160102_predefined_functions_010 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|44 |Sem_160102_predefined_functions_011 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|45 |Sem_160102_predefined_functions_012 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|46 |Sem_160102_predefined_functions_013 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|47 |Sem_160102_predefined_functions_014 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|48 |Sem_160102_predefined_functions_015 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|49 |Sem_160102_predefined_functions_016 |Predefined `encvalue` function works correctly (as specified in Annex C.5.1) |Clause 16.1.2 |m |y
+|50 |Sem_160102_predefined_functions_017 |Predefined `decvalue` function performs full decoding correctly |Clause 16.1.2 |m |y
+|51 |Sem_160102_predefined_functions_018 |Predefined `decvalue` function performs decoding if there are more bits than needed |Clause 16.1.2 |m |y
+|52 |Sem_160102_predefined_functions_019 |Predefined `decvalue` function works properly in case of decoding failure |Clause 16.1.2 |m |n
+|53 |Sem_160102_predefined_functions_020 |Predefined `decvalue` function works properly in case of not enough bits |Clause 16.1.2 |m |n
+|54 |Sem_160102_predefined_functions_021 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|55 |Sem_160102_predefined_functions_022 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|56 |Sem_160102_predefined_functions_023 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|57 |Sem_160102_predefined_functions_024 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|58 |Sem_160102_predefined_functions_025 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.33) |Clause 16.1.2 |m |y
+|59 |Sem_160102_predefined_functions_026 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|60 |Sem_160102_predefined_functions_027 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|61 |Sem_160102_predefined_functions_028 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|62 |Sem_160102_predefined_functions_029 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|63 |Sem_160102_predefined_functions_030 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|64 |Sem_160102_predefined_functions_031 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|65 |Sem_160102_predefined_functions_032 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|66 |Sem_160102_predefined_functions_033 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|67 |Sem_160102_predefined_functions_034 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|68 |Sem_160102_predefined_functions_035 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|69 |Sem_160102_predefined_functions_036 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|70 |Sem_160102_predefined_functions_037 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|71 |Sem_160102_predefined_functions_038 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|72 |Sem_160102_predefined_functions_039 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|73 |Sem_160102_predefined_functions_040 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|74 |Sem_160102_predefined_functions_041 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|75 |Sem_160102_predefined_functions_042 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|76 |Sem_160102_predefined_functions_043 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|77 |Sem_160102_predefined_functions_044 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|78 |Sem_160102_predefined_functions_045 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|79 |Sem_160102_predefined_functions_046 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|80 |Sem_160102_predefined_functions_047 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|81 |Sem_160102_predefined_functions_048 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|82 |Sem_160102_predefined_functions_049 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|83 |Sem_160102_predefined_functions_050 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|84 |Sem_160102_predefined_functions_051 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|85 |Sem_160102_predefined_functions_052 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|86 |Sem_160102_predefined_functions_053 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|87 |Sem_160102_predefined_functions_054 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|88 |Sem_160102_predefined_functions_055 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|89 |Sem_160102_predefined_functions_056 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |n
+|90 |Sem_160102_predefined_functions_057 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|91 |Sem_160102_predefined_functions_058 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|92 |Sem_160102_predefined_functions_059 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|93 |Sem_160102_predefined_functions_060 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|94 |Sem_160102_predefined_functions_061 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|95 |Sem_160102_predefined_functions_062 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.3.5) |Clause 16.1.2 |m |y
+|96 |Sem_160102_predefined_functions_063 |Predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|97 |Sem_160102_predefined_functions_064 |Predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|98 |Sem_160102_predefined_functions_065 |Predefined `decvalue` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|99 |Sem_160102_predefined_functions_066 |Predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|100 |Sem_160102_predefined_functions_067 |Predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|101 |Sem_160102_predefined_functions_068 |Predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|102 |Sem_160102_predefined_functions_069 |Predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|103 |Sem_160102_predefined_functions_070 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|104 |Sem_160102_predefined_functions_071 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|105 |Sem_160102_predefined_functions_072 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|106 |Sem_160102_predefined_functions_073 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|107 |Sem_160102_predefined_functions_074 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|108 |Sem_160102_predefined_functions_075 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|109 |Sem_160102_predefined_functions_076 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|110 |Sem_160102_predefined_functions_077 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|111 |Sem_160102_predefined_functions_078 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|112 |Sem_160102_predefined_functions_079 |Predefined `decvalue_unichar` function works properly |Clause 16.1.2 |m |y
+|113 |Sem_160102_predefined_functions_080 |Predefined `decvalue` and `decvalue_unichar` function works properly in case of uninitialized encode value is given |Clause 16.1.2 |m |n
+|114 |Sem_160102_predefined_functions_081 |Predefined function `get_stringencoding` works properly |Clause 16.1.2 |m |y
+|115 |Sem_160102_predefined_functions_082 |Predefined function for removing Byte order mark works properly |Clause 16.1.2 |m |y
+|116 |Sem_160102_predefined_functions_083 |Predefined function `isvalue()` works properly |Clause 16.1.2 |m |y
+|117 |Sem_160102_predefined_functions_084 |Predefined function `isvalue()` works properly |Clause 16.1.2 |m |y
+|118 |Sem_160102_predefined_functions_085 |Predefined function `isvalue()` works properly |Clause 16.1.2 |m |n
+|119 |Sem_160102_predefined_functions_086 |Predefined function `isvalue(`) works properly |Clause 16.1.2 |m |y
+|120 |Sem_160102_predefined_functions_087 |Predefined function `isvalue()` works properly |Clause 16.1.2 |m |y
+|121 |Sem_160102_predefined_functions_088 |Predefined function `isvalue()` works properly |Clause 16.1.2 |m |y
+|122 |Sem_160102_predefined_functions_089 |Predefined function `isvalue()` works properly |Clause 16.1.2 |m |y
+|123 |Sem_160102_predefined_functions_090 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C.4.1) |Clause 16.1.2 |m |y
+|124 |Sem_160102_predefined_functions_091 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|125 |Sem_160102_predefined_functions_092 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|126 |Sem_160102_predefined_functions_093 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|127 |Sem_160102_predefined_functions_094 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |n
+|128 |Sem_160102_predefined_functions_095 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|129 |Sem_160102_predefined_functions_096 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|130 |Sem_160102_predefined_functions_097 |The IUT recognizes predefined functions and correctly evaluates them (as specified by Annex C) |Clause 16.1.2 |m |y
+|131 |Sem_160102_predefined_functions_098 |That predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|132 |Sem_160102_predefined_functions_099 |That predefined `encvalue_unichar` function works properly in case of encoding universal charstring |Clause 16.1.2 |m |y
+|==============================================================================================================================================================================
+
+== External functions
+
+.External functions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_160103_external_functions_001 |The IUT recognizes external functions |Clause 16.1.3 |m |n
+|2 |Sem_160103_external_functions_001 |The IUT recognizes external functions |Clause 16.1.3 |m |y
+|3 |Sem_160103_external_functions_002 |The IUT recognizes external functions |Clause 16.1.3 |m |y
+|===================================================================================================
+
+== Invoking function from specific places
+
+.Invoking function from specific places
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_160104_invoking_functions_from_specific_places_001 |The IUT recognizes restrictions described in section 16.1.4. STF409 assumes that the list given in section 16.1.4 describes mandatory restrictions |Clause 16.1.4 |m |n
+|2 |NegSem_160104_invoking_functions_from_specific_places_002 |The IUT recognizes restrictions described in section 16.1.4. STF409 assumes that the list given in section 16.1.4 describes mandatory restrictions |Clause 16.1.4 |m |n
+|3 |NegSem_160104_invoking_functions_from_specific_places_003 |The IUT recognizes restrictions described in section 16.1.4. STF409 assumes that the list given in section 16.1.4 describes mandatory restrictions |Clause 16.1.4 |m |n
+|4 |NegSem_160104_invoking_functions_from_specific_places_004 |The IUT recognizes restrictions described in section 16.1.4. STF409 assumes that the list given in section 16.1.4 describes mandatory restrictions |Clause 16.1.4 |m |n
+|5 |NegSem_160104_invoking_functions_from_specific_places_005 |verify that the `create` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|6 |NegSem_160104_invoking_functions_from_specific_places_006 |verify that the `component.start` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|7 |NegSem_160104_invoking_functions_from_specific_places_007 |verify that the `component.stop` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|8 |NegSem_160104_invoking_functions_from_specific_places_008 |verify that the `kill` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|9 |NegSem_160104_invoking_functions_from_specific_places_009 |verify that the `component.running` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|10 |NegSem_160104_invoking_functions_from_specific_places_010 |verify that the `alive` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|11 |NegSem_160104_invoking_functions_from_specific_places_011 |verify that the `done` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|12 |NegSem_160104_invoking_functions_from_specific_places_012 |verify that the `killed` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|13 |NegSem_160104_invoking_functions_from_specific_places_013 |verify that the `port.start` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|14 |NegSem_160104_invoking_functions_from_specific_places_014 |verify that the `port.stop` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|15 |NegSem_160104_invoking_functions_from_specific_places_015 |verify that the `halt` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|16 |NegSem_160104_invoking_functions_from_specific_places_016 |verify that the `clear` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|17 |NegSem_160104_invoking_functions_from_specific_places_017 |verify that the `checkstate` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|18 |NegSem_160104_invoking_functions_from_specific_places_018 |verify that the `send` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|19 |NegSem_160104_invoking_functions_from_specific_places_019 |verify that the `receive` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|20 |NegSem_160104_invoking_functions_from_specific_places_020 |verify that the `trigger` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|21 |NegSem_160104_invoking_functions_from_specific_places_021 |verify that the `call` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|22 |NegSem_160104_invoking_functions_from_specific_places_022 |verify that the `getcall` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|23 |NegSem_160104_invoking_functions_from_specific_places_023 |verify that the `reply` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|24 |NegSem_160104_invoking_functions_from_specific_places_024 |verify that the `getreply` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|25 |NegSem_160104_invoking_functions_from_specific_places_025 |verify that the `raise` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|26 |NegSem_160104_invoking_functions_from_specific_places_026 |verify that the `catch` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|27 |NegSem_160104_invoking_functions_from_specific_places_027 |verify that the `check` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|28 |NegSem_160104_invoking_functions_from_specific_places_028 |verify that the `connect` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|29 |NegSem_160104_invoking_functions_from_specific_places_029 |verify that the `disconnect` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|30 |NegSem_160104_invoking_functions_from_specific_places_030 |verify that the `map` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|31 |NegSem_160104_invoking_functions_from_specific_places_031 |verify that the `unmap` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|32 |NegSem_160104_invoking_functions_from_specific_places_032 |verify that the `action` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|33 |NegSem_160104_invoking_functions_from_specific_places_033 |verify that the `timer.start` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|34 |NegSem_160104_invoking_functions_from_specific_places_034 |verify that the `timer.stop` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|35 |NegSem_160104_invoking_functions_from_specific_places_035 |verify that the `timer.running` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|36 |NegSem_160104_invoking_functions_from_specific_places_036 |verify that the `read` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|37 |NegSem_160104_invoking_functions_from_specific_places_037 |verify that the `timeout` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|38 |NegSem_160104_invoking_functions_from_specific_places_038 |verify that a non-deterministic external function call cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|39 |NegSem_160104_invoking_functions_from_specific_places_039 |verify that the predefined `rnd` function cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|40 |NegSem_160104_invoking_functions_from_specific_places_040 |verify a function called during receiving operation cannot contain an assignment of a component variable (in templates) |Clause 16.1.4 |m |n
+|41 |NegSem_160104_invoking_functions_from_specific_places_041 |verify a function called during receiving operation cannot contain a component variable used as an actual `out` parameter (in templates) |Clause 16.1.4 |m |n
+|42 |NegSem_160104_invoking_functions_from_specific_places_042 |verify a function called during receiving operation cannot contain a component variable used as an actual `inout` parameter (in templates) |Clause 16.1.4 |m |n
+|43 |NegSem_160104_invoking_functions_from_specific_places_043 |verify that the `setverdict` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|44 |NegSem_160104_invoking_functions_from_specific_places_044 |verify that the `activate` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|45 |NegSem_160104_invoking_functions_from_specific_places_045 |verify that the `deactivate` operation cannot be used in a function called during receiving operation (in templates) |Clause 16.1.4 |m |n
+|46 |NegSem_160104_invoking_functions_from_specific_places_046 |verify that the `create` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|47 |NegSem_160104_invoking_functions_from_specific_places_047 |verify that the `component.start` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|48 |NegSem_160104_invoking_functions_from_specific_places_048 |verify that the `component.stop` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|49 |NegSem_160104_invoking_functions_from_specific_places_049 |verify that the `kill` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|50 |NegSem_160104_invoking_functions_from_specific_places_050 |verify that the `component.running` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|51 |NegSem_160104_invoking_functions_from_specific_places_051 |verify that the `alive` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|52 |NegSem_160104_invoking_functions_from_specific_places_052 |verify that the `done` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|53 |NegSem_160104_invoking_functions_from_specific_places_053 |verify that the `killed` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|54 |NegSem_160104_invoking_functions_from_specific_places_054 |verify that the `port.start` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|55 |NegSem_160104_invoking_functions_from_specific_places_055 |verify that the `port.stop` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|56 |NegSem_160104_invoking_functions_from_specific_places_056 |verify that the `halt` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|57 |NegSem_160104_invoking_functions_from_specific_places_057 |verify that the `clear` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|58 |NegSem_160104_invoking_functions_from_specific_places_058 |verify that the `checkstate` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|59 |NegSem_160104_invoking_functions_from_specific_places_059 |verify that the `send` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|60 |NegSem_160104_invoking_functions_from_specific_places_060 |verify that the `receive` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|61 |NegSem_160104_invoking_functions_from_specific_places_061 |verify that the `trigger` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|62 |NegSem_160104_invoking_functions_from_specific_places_062 |verify that the `call` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|63 |NegSem_160104_invoking_functions_from_specific_places_063 |verify that the `getcall` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|64 |NegSem_160104_invoking_functions_from_specific_places_064 |verify that the `reply` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|65 |NegSem_160104_invoking_functions_from_specific_places_065 |verify that the `getreply` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|66 |NegSem_160104_invoking_functions_from_specific_places_066 |verify that the `raise` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|67 |NegSem_160104_invoking_functions_from_specific_places_067 |verify that the `catch` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|68 |NegSem_160104_invoking_functions_from_specific_places_068 |verify that the `check` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|69 |NegSem_160104_invoking_functions_from_specific_places_069 |verify that the `connect` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|70 |NegSem_160104_invoking_functions_from_specific_places_070 |verify that the `disconnect` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|71 |NegSem_160104_invoking_functions_from_specific_places_071 |verify that the `map` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|72 |NegSem_160104_invoking_functions_from_specific_places_072 |verify that the `unmap` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|73 |NegSem_160104_invoking_functions_from_specific_places_073 |verify that the `action` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|74 |NegSem_160104_invoking_functions_from_specific_places_074 |verify that the `timer.start` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|75 |NegSem_160104_invoking_functions_from_specific_places_075 |verify that the `timer.stop` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|76 |NegSem_160104_invoking_functions_from_specific_places_076 |verify that the `timer.running` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|77 |NegSem_160104_invoking_functions_from_specific_places_077 |verify that the `read` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|78 |NegSem_160104_invoking_functions_from_specific_places_078 |verify that the `timeout` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|79 |NegSem_160104_invoking_functions_from_specific_places_079 |verify that a non-deterministic external function call cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|80 |NegSem_160104_invoking_functions_from_specific_places_080 |verify that the predefined `rnd` function cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|81 |NegSem_160104_invoking_functions_from_specific_places_081 |verify a function called during receiving operation cannot contain an assignment of a component variable (in template fields) |Clause 16.1.4 |m |n
+|82 |NegSem_160104_invoking_functions_from_specific_places_082 |verify a function called during receiving operation cannot contain a component variable used as an actual `out` parameter (in template fields) |Clause 16.1.4 |m |n
+|83 |NegSem_160104_invoking_functions_from_specific_places_083 |verify a function called during receiving operation cannot contain a component variable used as an actual `inout` parameter (in template fields) |Clause 16.1.4 |m |n
+|84 |NegSem_160104_invoking_functions_from_specific_places_084 |verify that the `setverdict` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|85 |NegSem_160104_invoking_functions_from_specific_places_085 |verify that the `activate` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|86 |NegSem_160104_invoking_functions_from_specific_places_086 |verify that the `deactivate` operation cannot be used in a function called during receiving operation (in template fields) |Clause 16.1.4 |m |n
+|87 |NegSem_160104_invoking_functions_from_specific_places_087 |verify that the `create` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|88 |NegSem_160104_invoking_functions_from_specific_places_089 |verify that the `component.start` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|89 |NegSem_160104_invoking_functions_from_specific_places_089 |verify that the `component.stop` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|90 |NegSem_160104_invoking_functions_from_specific_places_090 |verify that the `kill` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|91 |NegSem_160104_invoking_functions_from_specific_places_091 |verify that the `component.running` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|92 |NegSem_160104_invoking_functions_from_specific_places_092 |verify that the `alive` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|93 |NegSem_160104_invoking_functions_from_specific_places_093 |verify that the `done` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|94 |NegSem_160104_invoking_functions_from_specific_places_094 |verify that the `killed` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|95 |NegSem_160104_invoking_functions_from_specific_places_095 |verify that the `port.start` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|96 |NegSem_160104_invoking_functions_from_specific_places_096 |verify that the `port.stop` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|97 |NegSem_160104_invoking_functions_from_specific_places_097 |verify that the `halt` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|98 |NegSem_160104_invoking_functions_from_specific_places_098 |verify that the `clear` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|99 |NegSem_160104_invoking_functions_from_specific_places_099 |verify that the `checkstate` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|100 |NegSem_160104_invoking_functions_from_specific_places_100 |verify that the `send` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|101 |NegSem_160104_invoking_functions_from_specific_places_101 |verify that the `receive` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|102 |NegSem_160104_invoking_functions_from_specific_places_102 |verify that the `trigger` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|103 |NegSem_160104_invoking_functions_from_specific_places_103 |verify that the `call` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|104 |NegSem_160104_invoking_functions_from_specific_places_104 |verify that the `getcall` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|105 |NegSem_160104_invoking_functions_from_specific_places_105 |verify that the `reply` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|106 |NegSem_160104_invoking_functions_from_specific_places_106 |verify that the `getreply` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|107 |NegSem_160104_invoking_functions_from_specific_places_107 |verify that the `raise` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|108 |NegSem_160104_invoking_functions_from_specific_places_108 |verify that the `catch` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|109 |NegSem_160104_invoking_functions_from_specific_places_109 |verify that the `check` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|110 |NegSem_160104_invoking_functions_from_specific_places_110 |verify that the `connect` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|111 |NegSem_160104_invoking_functions_from_specific_places_111 |verify that the `disconnect` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|112 |NegSem_160104_invoking_functions_from_specific_places_112 |verify that the `map` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|113 |NegSem_160104_invoking_functions_from_specific_places_113 |verify that the `unmap` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|114 |NegSem_160104_invoking_functions_from_specific_places_114 |verify that the `action` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|115 |NegSem_160104_invoking_functions_from_specific_places_115 |verify that the `timer.start` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|116 |NegSem_160104_invoking_functions_from_specific_places_116 |verify that the `timer.stop` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|117 |NegSem_160104_invoking_functions_from_specific_places_117 |verify that the `timer.running` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|118 |NegSem_160104_invoking_functions_from_specific_places_118 |verify that the `read` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|119 |NegSem_160104_invoking_functions_from_specific_places_119 |verify that the `timeout` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|120 |NegSem_160104_invoking_functions_from_specific_places_120 |verify that a non-deterministic external function call cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|121 |NegSem_160104_invoking_functions_from_specific_places_121 |verify that the predefined `rnd` function cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|122 |NegSem_160104_invoking_functions_from_specific_places_122 |verify a function called during receiving operation cannot contain an assignment of a component variable (in in-line templates) |Clause 16.1.4 |m |n
+|123 |NegSem_160104_invoking_functions_from_specific_places_123 |verify a function called during receiving operation cannot contain a component variable used as an actual `out` parameter (in in-line templates) |Clause 16.1.4 |m |n
+|124 |NegSem_160104_invoking_functions_from_specific_places_124 |verify a function called during receiving operation cannot contain a component variable used as an actual `inout` parameter (in in-line templates) |Clause 16.1.4 |m |n
+|125 |NegSem_160104_invoking_functions_from_specific_places_125 |verify that the `setverdict` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|126 |NegSem_160104_invoking_functions_from_specific_places_126 |verify that the `activate` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|127 |NegSem_160104_invoking_functions_from_specific_places_127 |verify that the `deactivate` operation cannot be used in a function called during receiving operation (in in-line templates) |Clause 16.1.4 |m |n
+|128 |NegSem_160104_invoking_functions_from_specific_places_128 |verify a function called during receiving operation cannot contain an `out` parameter (in in-line templates) |Clause 16.1.4 |m |n
+|129 |NegSem_160104_invoking_functions_from_specific_places_129 |verify a function called during receiving operation cannot contain an `inout` parameter (in in-line templates) |Clause 16.1.4 |m |n
+|130 |NegSem_160104_invoking_functions_from_specific_places_130 |verify that the `create` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|131 |NegSem_160104_invoking_functions_from_specific_places_131 |verify that the `component.start` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|132 |NegSem_160104_invoking_functions_from_specific_places_132 |verify that the `component.stop` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|133 |NegSem_160104_invoking_functions_from_specific_places_133 |verify that the `kill` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|134 |NegSem_160104_invoking_functions_from_specific_places_134 |verify that the `component.running` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|135 |NegSem_160104_invoking_functions_from_specific_places_135 |verify that the `alive` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|136 |NegSem_160104_invoking_functions_from_specific_places_136 |verify that the `done` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|137 |NegSem_160104_invoking_functions_from_specific_places_137 |verify that the `killed` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|138 |NegSem_160104_invoking_functions_from_specific_places_138 |verify that the `port.start` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|139 |NegSem_160104_invoking_functions_from_specific_places_139 |verify that the `port.stop` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|140 |NegSem_160104_invoking_functions_from_specific_places_140 |verify that the `halt` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|141 |NegSem_160104_invoking_functions_from_specific_places_141 |verify that the `clear` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|142 |NegSem_160104_invoking_functions_from_specific_places_142 |verify that the `checkstate` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|143 |NegSem_160104_invoking_functions_from_specific_places_143 |verify that the `send` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|144 |NegSem_160104_invoking_functions_from_specific_places_144 |verify that the `receive` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|145 |NegSem_160104_invoking_functions_from_specific_places_145 |verify that the `trigger` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|146 |NegSem_160104_invoking_functions_from_specific_places_146 |verify that the `call` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|147 |NegSem_160104_invoking_functions_from_specific_places_147 |verify that the `getcall` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|148 |NegSem_160104_invoking_functions_from_specific_places_148 |verify that the `reply` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|149 |NegSem_160104_invoking_functions_from_specific_places_149 |verify that the `getreply` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|150 |NegSem_160104_invoking_functions_from_specific_places_150 |verify that the `raise` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|151 |NegSem_160104_invoking_functions_from_specific_places_151 |verify that the `catch` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|152 |NegSem_160104_invoking_functions_from_specific_places_152 |verify that the `check` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|153 |NegSem_160104_invoking_functions_from_specific_places_153 |verify that the `connect` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|154 |NegSem_160104_invoking_functions_from_specific_places_154 |verify that the `disconnect` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|155 |NegSem_160104_invoking_functions_from_specific_places_155 |verify that the `map` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|156 |NegSem_160104_invoking_functions_from_specific_places_156 |verify that the `unmap` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|157 |NegSem_160104_invoking_functions_from_specific_places_157 |verify that the `action` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|158 |NegSem_160104_invoking_functions_from_specific_places_158 |verify that the `timer.start` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|159 |NegSem_160104_invoking_functions_from_specific_places_159 |verify that the `timer.stop` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|160 |NegSem_160104_invoking_functions_from_specific_places_160 |verify that the `timer.running` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|161 |NegSem_160104_invoking_functions_from_specific_places_161 |verify that the `read` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|162 |NegSem_160104_invoking_functions_from_specific_places_162 |verify that the `timeout` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|163 |NegSem_160104_invoking_functions_from_specific_places_163 |verify that a non-deterministic external function call cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|164 |NegSem_160104_invoking_functions_from_specific_places_164 |verify that the predefined `rnd` function cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|165 |NegSem_160104_invoking_functions_from_specific_places_165 |verify a function called during receiving operation cannot contain an assignment of a component variable (as actual parameters) |Clause 16.1.4 |m |n
+|166 |NegSem_160104_invoking_functions_from_specific_places_166 |verify a function called during receiving operation cannot contain a component variable used as an actual out parameter (as actual parameters) |Clause 16.1.4 |m |n
+|167 |NegSem_160104_invoking_functions_from_specific_places_167 |verify a function called during receiving operation cannot contain a component variable used as an actual `inout` parameter (as actual parameters) |Clause 16.1.4 |m |n
+|168 |NegSem_160104_invoking_functions_from_specific_places_168 |verify that the `setverdict` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|169 |NegSem_160104_invoking_functions_from_specific_places_169 |verify that the `activate` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|170 |NegSem_160104_invoking_functions_from_specific_places_170 |verify that the `deactivate` operation cannot be used in a function called during receiving operation (as actual parameters) |Clause 16.1.4 |m |n
+|171 |NegSem_160104_invoking_functions_from_specific_places_171 |verify a function called during receiving operation cannot contain an out parameter (as actual parameters) |Clause 16.1.4 |m |n
+|172 |NegSem_160104_invoking_functions_from_specific_places_172 |verify a function called during receiving operation cannot contain an `inout` parameter (as actual parameters) |Clause 16.1.4 |m |n
+|173 |NegSem_160104_invoking_functions_from_specific_places_173 |verify that the `create` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|174 |NegSem_160104_invoking_functions_from_specific_places_174 |verify that the `component.start` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|175 |NegSem_160104_invoking_functions_from_specific_places_175 |verify that the `component.stop` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|176 |NegSem_160104_invoking_functions_from_specific_places_176 |verify that the `kill` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|177 |NegSem_160104_invoking_functions_from_specific_places_177 |verify that the `component.running` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|178 |NegSem_160104_invoking_functions_from_specific_places_178 |verify that the `alive` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|179 |NegSem_160104_invoking_functions_from_specific_places_179 |verify that the `done` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|180 |NegSem_160104_invoking_functions_from_specific_places_180 |verify that the `killed` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|181 |NegSem_160104_invoking_functions_from_specific_places_181 |verify that the `port.start` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|182 |NegSem_160104_invoking_functions_from_specific_places_182 |verify that the `port.stop` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|183 |NegSem_160104_invoking_functions_from_specific_places_183 |verify that the `halt` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|184 |NegSem_160104_invoking_functions_from_specific_places_184 |verify that the `clear` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|185 |NegSem_160104_invoking_functions_from_specific_places_185 |verify that the `checkstate` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|186 |NegSem_160104_invoking_functions_from_specific_places_186 |verify that the `send` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|187 |NegSem_160104_invoking_functions_from_specific_places_187 |verify that the `receive` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|188 |NegSem_160104_invoking_functions_from_specific_places_188 |verify that the `trigger` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|189 |NegSem_160104_invoking_functions_from_specific_places_189 |verify that the `call` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|190 |NegSem_160104_invoking_functions_from_specific_places_190 |verify that the `getcall` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|191 |NegSem_160104_invoking_functions_from_specific_places_191 |verify that the `reply` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|192 |NegSem_160104_invoking_functions_from_specific_places_192 |verify that the `getreply` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|193 |NegSem_160104_invoking_functions_from_specific_places_193 |verify that the `raise` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|194 |NegSem_160104_invoking_functions_from_specific_places_194 |verify that the `catch` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|195 |NegSem_160104_invoking_functions_from_specific_places_195 |verify that the `check` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|196 |NegSem_160104_invoking_functions_from_specific_places_196 |verify that the `connect` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|197 |NegSem_160104_invoking_functions_from_specific_places_197 |verify that the `disconnect` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|198 |NegSem_160104_invoking_functions_from_specific_places_198 |verify that the `map` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|199 |NegSem_160104_invoking_functions_from_specific_places_199 |verify that the `unmap` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|200 |NegSem_160104_invoking_functions_from_specific_places_200 |verify that the `action` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|201 |NegSem_160104_invoking_functions_from_specific_places_201 |verify that the `timer.start` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|202 |NegSem_160104_invoking_functions_from_specific_places_202 |verify that the `timer.stop` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|203 |NegSem_160104_invoking_functions_from_specific_places_203 |verify that the `timer.running` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|204 |NegSem_160104_invoking_functions_from_specific_places_204 |verify that the `read` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|205 |NegSem_160104_invoking_functions_from_specific_places_205 |verify that the `timeout` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|206 |NegSem_160104_invoking_functions_from_specific_places_206 |verify a function called in a guard of an `alt` statement cannot contain an assignment of a component variable |Clause 16.1.4 |m |n
+|207 |NegSem_160104_invoking_functions_from_specific_places_207 |verify a function called in a guard of an `alt` statement cannot contain a component variable used as an actual `out` parameter |Clause 16.1.4 |m |n
+|208 |NegSem_160104_invoking_functions_from_specific_places_208 |verify a function called in a guard of an `alt` statement cannot contain a component variable used as an actual `inout` parameter |Clause 16.1.4 |m |n
+|209 |NegSem_160104_invoking_functions_from_specific_places_209 |verify that the `activate` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|210 |NegSem_160104_invoking_functions_from_specific_places_210 |verify that the `deactivate` operation cannot be used in guards of `alt` statements |Clause 16.1.4 |m |n
+|211 |NegSem_160104_invoking_functions_from_specific_places_211 |verify that a function called from a `guard` statement of an `alt` operation cannot contain `out` parameters |Clause 16.1.4 |m |n
+|212 |NegSem_160104_invoking_functions_from_specific_places_212 |verify that the `create` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|213 |NegSem_160104_invoking_functions_from_specific_places_213 |verify that the `component.start` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|214 |NegSem_160104_invoking_functions_from_specific_places_214 |verify that the `component.stop` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|215 |NegSem_160104_invoking_functions_from_specific_places_215 |verify that the `kill` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|216 |NegSem_160104_invoking_functions_from_specific_places_216 |verify that the `component.running` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|217 |NegSem_160104_invoking_functions_from_specific_places_217 |verify that the `alive` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|218 |NegSem_160104_invoking_functions_from_specific_places_218 |verify that the `done` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|219 |NegSem_160104_invoking_functions_from_specific_places_219 |verify that the `killed` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|220 |NegSem_160104_invoking_functions_from_specific_places_220 |verify that the `port.start` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|221 |NegSem_160104_invoking_functions_from_specific_places_221 |verify that the `port.stop` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|222 |NegSem_160104_invoking_functions_from_specific_places_222 |verify that the `halt` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|223 |NegSem_160104_invoking_functions_from_specific_places_223 |verify that the `clear` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|224 |NegSem_160104_invoking_functions_from_specific_places_224 |verify that the `checkstate` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|225 |NegSem_160104_invoking_functions_from_specific_places_225 |verify that the `send` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|226 |NegSem_160104_invoking_functions_from_specific_places_226 |verify that the `receive` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|227 |NegSem_160104_invoking_functions_from_specific_places_227 |verify that the `trigger` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|228 |NegSem_160104_invoking_functions_from_specific_places_228 |verify that the `call` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|229 |NegSem_160104_invoking_functions_from_specific_places_229 |verify that the `getcall` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|230 |NegSem_160104_invoking_functions_from_specific_places_230 |verify that the `reply` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|231 |NegSem_160104_invoking_functions_from_specific_places_231 |verify that the `getreply` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|232 |NegSem_160104_invoking_functions_from_specific_places_232 |verify that the `raise` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|233 |NegSem_160104_invoking_functions_from_specific_places_233 |verify that the `catch` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|234 |NegSem_160104_invoking_functions_from_specific_places_234 |verify that the `check` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|235 |NegSem_160104_invoking_functions_from_specific_places_235 |verify that the `connect` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|236 |NegSem_160104_invoking_functions_from_specific_places_236 |verify that the `disconnect` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|237 |NegSem_160104_invoking_functions_from_specific_places_237 |verify that the `map` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|238 |NegSem_160104_invoking_functions_from_specific_places_238 |verify that the `unmap` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|239 |NegSem_160104_invoking_functions_from_specific_places_239 |verify that the `action` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|240 |NegSem_160104_invoking_functions_from_specific_places_240 |verify that the `timer.start` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|241 |NegSem_160104_invoking_functions_from_specific_places_241 |verify that the `timer.stop` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|242 |NegSem_160104_invoking_functions_from_specific_places_242 |verify that the `timer.running` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|243 |NegSem_160104_invoking_functions_from_specific_places_243 |verify that the `read` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|244 |NegSem_160104_invoking_functions_from_specific_places_244 |verify that the `timeout` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|245 |NegSem_160104_invoking_functions_from_specific_places_245 |verify that a non-deterministic external function call cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|246 |NegSem_160104_invoking_functions_from_specific_places_246 |verify that the predefined `rnd` function cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|247 |NegSem_160104_invoking_functions_from_specific_places_247 |verify a function called in a guard of an `altstep` cannot contain an assignment of a component variable |Clause 16.1.4 |m |n
+|248 |NegSem_160104_invoking_functions_from_specific_places_248 |verify a function called in a guard of an `altstep` cannot contain a component variable used as an actual `out` parameter |Clause 16.1.4 |m |n
+|249 |NegSem_160104_invoking_functions_from_specific_places_249 |verify a function called in a guard of an `altstep` cannot contain a component variable used as an actual `inout` parameter |Clause 16.1.4 |m |n
+|250 |NegSem_160104_invoking_functions_from_specific_places_250 |verify that the `setverdict` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|251 |NegSem_160104_invoking_functions_from_specific_places_251 |verify that the `activate` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|252 |NegSem_160104_invoking_functions_from_specific_places_252 |verify that the `deactivate` operation cannot be used in guards of altsteps |Clause 16.1.4 |m |n
+|253 |NegSem_160104_invoking_functions_from_specific_places_253 |verify that a function called from a `guard` statement of an altstep cannot contain `out` parameters |Clause 16.1.4 |m |n
+|254 |NegSem_160104_invoking_functions_from_specific_places_254 |verify that a function called from a `guard` statement of an altstep cannot contain `inout` parameters |Clause 16.1.4 |m |n
+|255 |NegSem_160104_invoking_functions_from_specific_places_255 |verify that the `create` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|256 |NegSem_160104_invoking_functions_from_specific_places_256 |verify that the `component.start` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|257 |NegSem_160104_invoking_functions_from_specific_places_257 |verify that the `component.stop` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|258 |NegSem_160104_invoking_functions_from_specific_places_258 |verify that the `kill` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|259 |NegSem_160104_invoking_functions_from_specific_places_259 |verify that the `component.running` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|260 |NegSem_160104_invoking_functions_from_specific_places_260 |verify that the `alive` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|261 |NegSem_160104_invoking_functions_from_specific_places_261 |verify that the `done` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|262 |NegSem_160104_invoking_functions_from_specific_places_262 |verify that the `killed` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|263 |NegSem_160104_invoking_functions_from_specific_places_263 |verify that the `port.start` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|264 |NegSem_160104_invoking_functions_from_specific_places_264 |verify that the `port.stop` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|265 |NegSem_160104_invoking_functions_from_specific_places_265 |verify that the `halt` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|266 |NegSem_160104_invoking_functions_from_specific_places_266 |verify that the `clear` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|267 |NegSem_160104_invoking_functions_from_specific_places_267 |verify that the `checkstate` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|268 |NegSem_160104_invoking_functions_from_specific_places_268 |verify that the `send` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|269 |NegSem_160104_invoking_functions_from_specific_places_269 |verify that the `receive` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|270 |NegSem_160104_invoking_functions_from_specific_places_270 |verify that the `trigger` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|271 |NegSem_160104_invoking_functions_from_specific_places_271 |verify that the `call` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|272 |NegSem_160104_invoking_functions_from_specific_places_272 |verify that the `getcall` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|273 |NegSem_160104_invoking_functions_from_specific_places_273 |verify that the `reply` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|274 |NegSem_160104_invoking_functions_from_specific_places_274 |verify that the `getreply` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|275 |NegSem_160104_invoking_functions_from_specific_places_275 |verify that the `raise` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|276 |NegSem_160104_invoking_functions_from_specific_places_276 |verify that the `catch` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|277 |NegSem_160104_invoking_functions_from_specific_places_277 |verify that the `check` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|278 |NegSem_160104_invoking_functions_from_specific_places_278 |verify that the `connect` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|279 |NegSem_160104_invoking_functions_from_specific_places_279 |verify that the `disconnect` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|280 |NegSem_160104_invoking_functions_from_specific_places_280 |verify that the `map` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|281 |NegSem_160104_invoking_functions_from_specific_places_281 |verify that the `unmap` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|282 |NegSem_160104_invoking_functions_from_specific_places_282 |verify that the `action` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|283 |NegSem_160104_invoking_functions_from_specific_places_283 |verify that the `timer.start` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|284 |NegSem_160104_invoking_functions_from_specific_places_284 |verify that the `timer.stop` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|285 |NegSem_160104_invoking_functions_from_specific_places_285 |verify that the `timer.running` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|286 |NegSem_160104_invoking_functions_from_specific_places_286 |verify that the `read` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|287 |NegSem_160104_invoking_functions_from_specific_places_287 |verify that the `timeout` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|288 |NegSem_160104_invoking_functions_from_specific_places_288 |verify that a non-deterministic external function call cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|289 |NegSem_160104_invoking_functions_from_specific_places_289 |verify that the predefined `rnd` function cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|290 |NegSem_160104_invoking_functions_from_specific_places_290 |verify a function called in an altstep local definition cannot contain an assignment of a component variable |Clause 16.1.4 |m |n
+|291 |NegSem_160104_invoking_functions_from_specific_places_291 |verify a function called in an altstep local definition cannot contain a component variable used as an actual `out` parameter |Clause 16.1.4 |m |n
+|292 |NegSem_160104_invoking_functions_from_specific_places_292 |verify a function called in an altstep local definition cannot contain a component variable used as an actual `inout` parameter |Clause 16.1.4 |m |n
+|293 |NegSem_160104_invoking_functions_from_specific_places_293 |verify that the `setverdict` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|294 |NegSem_160104_invoking_functions_from_specific_places_294 |verify that the `activate` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|295 |NegSem_160104_invoking_functions_from_specific_places_295 |verify that the `deactivate` operation cannot be used in altstep local definitions |Clause 16.1.4 |m |n
+|296 |NegSem_160104_invoking_functions_from_specific_places_296 |verify that a function called in altstep `altstep` local definitions cannot contain `out` parameters |Clause 16.1.4 |m |n
+|297 |NegSem_160104_invoking_functions_from_specific_places_297 |verify that a function called in altstep `altstep` local definitions cannot contain `inout` parameters |Clause 16.1.4 |m |n
+|=====================================================================================================================================================================================================================================
+
+== Altsteps
+
+.Altsteps
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1602_toplevel_001 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |n
+|2 |NegSem_1602_toplevel_002 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |n
+|3 |NegSem_1602_toplevel_003 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |n
+|4 |NegSem_1602_toplevel_004 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |n
+|5 |NegSem_1602_toplevel_005 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |y
+|6 |NegSem_1602_toplevel_006 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |y
+|7 |NegSem_1602_toplevel_007 |Verify that altstep without a `runs on` clause cannot be started as component behaviour |Clause 16.2 |m |n
+|8 |NegSyn_1602_toplevel_001 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |y
+|9 |Sem_1602_toplevel_001 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2 |m |y
+|10 |Sem_1602_toplevel_002 |Verify that altstep with a `runs on` clause can be started as component behaviour |Clause 16.2 |m |n
+|11 |Sem_1602_toplevel_003 |Verify that altstep with a `runs on` clause can be started as component behaviour from a context without a `runs on` clause |Clause 16.2 |m |n
+|=====================================================================================================================================================================
+
+== Invoking altsteps
+
+.Invoking altsteps
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_160201_invoking_altsteps_001 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2.1 |m |y
+|2 |Sem_160201_invoking_altsteps_001 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2.1 |m |y
+|3 |Sem_160201_invoking_altsteps_002 |The IUT recognizes altstep definitions and correctly evaluates them |Clause 16.2.1 |m |y
+|4 |Sem_160201_invoking_altsteps_003 |Altsteps are correctly handled for dynamically mapped ports |Clause 16.2.1 |m |y
+|5 |Sem_160201_invoking_altsteps_004 |Altsteps are correctly handled for dynamically mapped ports |Clause 16.2.1 |m |y
+|================================================================================================================================
+
+== Test cases
+
+.Test cases
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1603_testcases_001 |The IUT properly evaluates invocation of testcases |Clause 16.3 |m |y
+|2 |NegSem_1603_testcases_002 |The IUT properly evaluates invocation of testcases |Clause 16.3 |m |y
+|3 |Syn_1603_testcases_001 |The IUT properly evaluates invocation of testcases with `system` clause |Clause 16.3 |m |y
+|===================================================================================================================
+
+== Assignments
+
+.Assignments
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1901_assignments_001 |The IUT properly evaluates `assignment` statements |Clause 19.1 |m |y
+|2 |NegSem_1901_assignments_002 |The IUT properly evaluates `assignment` statements |Clause 19.1 |m |y
+|3 |NegSem_1901_assignments_003 |The IUT properly evaluates `assignment` statements |Clause 19.1 |m |y
+|4 |NegSem_1901_assignments_004 |Omit assignment to a record non-optional value is not allowed |Clause 19.1 |m |y
+|5 |NegSem_1901_assignments_005 |Omit assignment to set of non-optional value is not allowed |Clause 19.1 |m |y
+|6 |NegSem_1901_assignments_006 |Omit assignment to an array is not allowed |Clause 19.1 |m |y
+|7 |NegSyn_1901_assignments_001 |The IUT properly evaluates `assignment` statements |Clause 19.1 |m |y
+|8 |Sem_1901_assignments_001 |The IUT properly evaluates `assignment` statements |Clause 19.1 |m |y
+|9 |Sem_1901_assignments_002 |Uninitialized at the right-hand side of the assignment shall also become uninitialized at the left-hand side |Clause 19.1 |m |y
+|10 |Sem_1901_assignments_003 |The right-hand side of the assignment of a structured value is evaulted correctly |Clause 19.1 |m |y
+|11 |Sem_1901_assignments_004 |Ensure that the right-hand side of the assignment of a structured value is evaulted correctly |Clause 19.1 |m |n
+|============================================================================================================================================================
+
+== The `if-else` statement
+
+.The `if-else` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_1902_if_else_statement_001 |If statement requires curly brackets for the body |Clause 19.2 |m |y
+|2 |Sem_1902_if_else_statement_001 |The IUT properly evaluates `if-else` statements |Clause 19.2 |m |y
+|3 |Sem_1902_if_else_statement_002 |The IUT properly evaluates `if-else` statements |Clause 19.2 |m |y
+|==========================================================================================================
+
+== The `Select` statements
+
+.The `Select` statements
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_190301_select_case_statement_001 |The IUT properly evaluates `select-case` statements |Clause 19.3 |m |y
+|2 |Sem_190301_select_case_statement_002 |The IUT properly evaluates `select-case` statements |Clause 19.3 |m |y
+|3 |Sem_190301_select_case_statement_003 |The IUT properly evaluates `select-case` statements |Clause 19.3 |m |y
+|4 |Sem_190301_select_case_statement_004 |The IUT properly evaluates `select-case` statements |Clause 19.3 |m |y
+|5 |Sem_190301_select_case_statement_005 |The IUT properly evaluates `select-case` statements |Clause 19.3 |m |y
+|6 |Sem_190301_select_case_statement_006 |The IUT properly evaluates `select-case` statements |Clause 19.3 |m |y
+|=============================================================================================================
+
+== The `select union` statement
+
+.The `select union` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_190302_select_union_statement_001 |verify that header part of `select-union` statements cannot contain anything else than union instances |Clause 19.3.2 |m |y
+|2 |NegSem_190302_select_union_statement_002 |verify that uninitialized value cannot be used in select union header |Clause 19.3.2 |m |y
+|3 |NegSem_190302_select_union_statement_003 |verify that unknown alternatives cannot be use in `case` statements |Clause 19.3.2 |m |y
+|4 |NegSem_190302_select_union_statement_004 |verify that the same alternative cannot be used in two `case` statements (simple case) |Clause 19.3.2 |m |y
+|5 |NegSem_190302_select_union_statement_005 |verify that the same alternative cannot be used in two `case` statements (list item) |Clause 19.3.2 |m |y
+|6 |NegSem_190302_select_union_statement_006 |verify that it is possible to use a `select union` statement with several branches |Clause 19.3.2 |m |y
+|7 |Sem_190302_select_union_statement_001 |verify that it is possible to use a `select union` statement with several branches |Clause 19.3.2 |m |y
+|8 |Sem_190302_select_union_statement_002 |verify that it is possible to use comma separated list of alternatives in case branches |Clause 19.3.2 |m |y
+|9 |Sem_190302_select_union_statement_003 |verify that it is possible to use an else branches |Clause 19.3.2 |m |y
+|10 |Sem_190302_select_union_statement_004 |verify that else branch is executed if no case is defined for the selected alternative |Clause 19.3.2 |m |y
+|11 |Sem_190302_select_union_statement_005 |verify that no branch is executed if there's no suitable case branch |Clause 19.3.2 |m |y
+|12 |Sem_190302_select_union_statement_006 |verify that partially initialized value can be used in select union header |Clause 19.3.2 |m |y
+|13 |Sem_190302_select_union_statement_007 |verify that it is possible to use a `select union` statement with several branches |Clause 19.3.2 |m |y
+|======================================================================================================================================================================
+
+== The `for` statement
+
+.The `for` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1904_for_statement_001 |The IUT properly evaluates `for` statements |Clause 19.4 |m |y
+|2 |Sem_1904_for_statement_001 |The IUT properly evaluates `for` statements |Clause 19.4 |m |y
+|3 |Sem_1904_for_statement_002 |The IUT properly evaluates `for` statements |Clause 19.4 |m |y
+|4 |Sem_1904_for_statement_003 |The IUT properly evaluates `for` statements |Clause 19.4 |m |y
+|==============================================================================================
+
+== The `while` statement
+
+.The `while` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1905_while_statement_001 |The IUT properly evaluates `while` statements |Clause 19.5 |m |y
+|2 |Sem_1905_while_statement_001 |The IUT properly evaluates `while` statements |Clause 19.5 |m |y
+|3 |Sem_1905_while_statement_002 |The IUT properly evaluates `while` statements |Clause 19.5 |m |y
+|4 |Sem_1905_while_statement_003 |The IUT properly evaluates `while` statements |Clause 19.5 |m |y
+|==================================================================================================
+
+== The `do-while` statement
+
+.The `do-while` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1906_do_while_statement_001 |The IUT properly evaluates `do-while` statements |Clause 19.6 |m |y
+|2 |Sem_1906_do_while_statement_001 |The IUT properly evaluates `do-while` statements |Clause 19.6 |m |y
+|3 |Sem_1906_do_while_statement_002 |The IUT properly evaluates `do-while` statements |Clause 19.6 |m |y
+|4 |Sem_1906_do_while_statement_003 |The IUT properly evaluates `do-while` statements |Clause 19.6 |m |y
+|========================================================================================================
+
+== The `label` statement
+
+.The `label` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1907_label_statement_001 |The IUT correctly handles label naming uniqueness. |Clause 19.7 |m |y
+|2 |NegSyn_1907_label_statement_001 |The IUT correctly handles label syntax. |Clause 19.7 |m |y
+|3 |NegSyn_1907_label_statement_002 |The IUT correctly handles label syntax. |Clause 19.7 |m |y
+|4 |Syn_1907_label_statement_001 |The IUT correctly handles label syntax. |Clause 19.7 |m |y
+|=========================================================================================================
+
+== The `goto` statement
+
+.The `goto` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1908_goto_statement_001 |The IUT correctly handles `goto` statements. |Clause 19.8 |m |y
+|2 |NegSem_1908_goto_statement_002 |The IUT correctly handles `goto` statements. |Clause 19.8 |m |y
+|3 |NegSem_1908_goto_statement_003 |The IUT correctly handles `goto` statements. |Clause 19.8 |m |y
+|4 |Sem_1908_goto_statement_001 |The IUT correctly handles `goto` statements. |Clause 19.8 |m |y
+|5 |Sem_1908_goto_statement_002 |The IUT correctly handles `goto` statements. |Clause 19.8 |m |y
+|6 |Sem_1908_goto_statement_003 |The IUT correctly handles `goto` statements. |Clause 19.8 |m |y
+|================================================================================================
+
+== The `stop` execution statement
+
+.The `stop` execution statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_1909_stop_statement_001 |The IUT correctly handles `stop` statements. |Clause 19.9 |m |y
+|2 |Sem_1909_stop_statement_002 |The IUT correctly handles `stop` statements. |Clause 19.9 |m |y
+|3 |Sem_1909_stop_statement_003 |`stop` statement in a function called from a PTC |Clause 19.9 |m |y
+|4 |Sem_1909_stop_statement_004 |`stop` statement in a function called from a PTC |Clause 19.9 |m |y
+|=================================================================================================
+
+== The `return` statement
+
+.The `return` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1910_return_statement_001 |The IUT correctly handles `return` statements. |Clause 19.10 |m |y
+|2 |Sem_1910_return_statement_001 |The IUT correctly handles `return` statements. |Clause 19.10 |m |y
+|3 |Sem_1910_return_statement_002 |The IUT correctly handles `return` statements. |Clause 19.10 |m |y
+|=====================================================================================================
+
+== The `log` statement
+
+.The `log` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_1911_log_statement_001 |The IUT properly evaluates `log` statements |Clause 19.11 |m |y
+|2 |Sem_1911_log_statement_001 |The IUT properly evaluates `log` statements |Clause 19.11 |m |y
+|3 |Sem_1911_log_statement_002 |The IUT properly evaluates `log` statements |Clause 19.11 |m |y
+|4 |Sem_1911_log_statement_003 |The IUT properly evaluates `log` statements |Clause 19.11 |m |y
+|5 |Sem_1911_log_statement_004 |The IUT properly evaluates `log` statements |Clause 19.11 |m |y
+|6 |Sem_1911_log_statement_005 |The IUT properly evaluates `log` statements |Clause 19.11 |m |y
+|===============================================================================================
+
+== The `continue` statement
+
+.The `continue` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_1913_continue_statement_001 |The IUT properly evaluates `continue` statements |Clause 19.13 |m |y
+|======================================================================================================
+
+== Statement and operations for alternative behaviours
+
+.Statement and operations for alternative behaviours
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_20_TopLevel_001 |`Alt`-statements are accepted. |Clause 20 |m |y
+|2 |Syn_20_TopLevel_002 |Repeat in an `alt`-statement is accepted. |Clause 20 |m |y
+|3 |Syn_20_TopLevel_003 |The `interleave`-statement is accepted. |Clause 20 |m |y
+|4 |Syn_20_TopLevel_004 |Defaults and the `activate` statement is accepted. |Clause 20 |m |y
+|5 |Syn_20_TopLevel_005 |Defaults and the `activate` statement is accepted. |Clause 20 |m |y
+|=========================================================================================
+
+== The `alt` statement
+
+.The `alt` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2002_TheAltStatement_001 |dynamic error if a test component is completely blocked |Clause 20.2 |m |y
+|2 |NegSem_2002_TheAltStatement_002 |create in `guard` statements |Clause 20.2 |m |n
+|3 |NegSem_2002_TheAltStatement_003 |running (timer) in `guard` statements |Clause 20.2 |m |n
+|4 |NegSem_2002_TheAltStatement_004 |running (component) in `guard` statements |Clause 20.2 |m |n
+|5 |NegSem_2002_TheAltStatement_005 |alive in `guard` statements |Clause 20.2 |m |n
+|6 |NegSem_2002_TheAltStatement_006 |activate in `guard` statements |Clause 20.2 |m |n
+|7 |NegSem_2002_TheAltStatement_007 |create in `alt` branch event |Clause 20.2 |m |n
+|8 |NegSem_2002_TheAltStatement_008 |running (timer) in `alt` branch event |Clause 20.2 |m |n
+|9 |NegSem_2002_TheAltStatement_009 |running (component) in `alt` branch event |Clause 20.2 |m |n
+|10 |NegSem_2002_TheAltStatement_010 |alive in `alt` branch event |Clause 20.2 |m |n
+|11 |NegSem_2002_TheAltStatement_011 |create in `alt` branch event |Clause 20.2 |m |n
+|12 |NegSem_2002_TheAltStatement_012 |create in altstep branch |Clause 20.2 |m |n
+|13 |NegSem_2002_TheAltStatement_013 |running (timer) in altstep branch |Clause 20.2 |m |n
+|14 |NegSem_2002_TheAltStatement_014 |running (component) in altstep branch |Clause 20.2 |m |n
+|15 |NegSem_2002_TheAltStatement_015 |alive in altstep branch |Clause 20.2 |m |n
+|16 |NegSem_2002_TheAltStatement_016 |create in altstep branch |Clause 20.2 |m |n
+|17 |NegSem_2002_TheAltStatement_017 |verify that the `create` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|18 |NegSem_2002_TheAltStatement_018 |verify that the `component.start` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|19 |NegSem_2002_TheAltStatement_019 |verify that the `component.stop` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|20 |NegSem_2002_TheAltStatement_020 |verify that the `kill` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|21 |NegSem_2002_TheAltStatement_021 |verify that the `component.running` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|22 |NegSem_2002_TheAltStatement_022 |verify that the `alive` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|23 |NegSem_2002_TheAltStatement_023 |verify that the `done` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|24 |NegSem_2002_TheAltStatement_024 |verify that the `killed` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|25 |NegSem_2002_TheAltStatement_025 |verify that the `port.start` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|26 |NegSem_2002_TheAltStatement_026 |verify that the `port.stop` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|27 |NegSem_2002_TheAltStatement_027 |verify that the `halt` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|28 |NegSem_2002_TheAltStatement_028 |verify that the `clear` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|29 |NegSem_2002_TheAltStatement_029 |verify that the `checkstate` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|30 |NegSem_2002_TheAltStatement_030 |verify that the `send` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|31 |NegSem_2002_TheAltStatement_031 |verify that the `receive` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|32 |NegSem_2002_TheAltStatement_032 |verify that the `trigger` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|33 |NegSem_2002_TheAltStatement_033 |verify that the `call` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|34 |NegSem_2002_TheAltStatement_034 |verify that the `getcall` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|35 |NegSem_2002_TheAltStatement_035 |verify that the `reply` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|36 |NegSem_2002_TheAltStatement_036 |verify that the `getreply` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|37 |NegSem_2002_TheAltStatement_037 |verify that the `raise` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|38 |NegSem_2002_TheAltStatement_038 |verify that the `catch` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|39 |NegSem_2002_TheAltStatement_039 |verify that the `check` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|40 |NegSem_2002_TheAltStatement_040 |verify that the `connect` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|41 |NegSem_2002_TheAltStatement_041 |verify that the `disconnect` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|42 |NegSem_2002_TheAltStatement_042 |verify that the `map` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|43 |NegSem_2002_TheAltStatement_043 |verify that the `unmap` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|44 |NegSem_2002_TheAltStatement_044 |verify that the `action` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|45 |NegSem_2002_TheAltStatement_045 |verify that the `timer.start` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|46 |NegSem_2002_TheAltStatement_046 |verify that the `timer.stop` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|47 |NegSem_2002_TheAltStatement_047 |verify that the `timer.running` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|48 |NegSem_2002_TheAltStatement_048 |verify that the `read` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|49 |NegSem_2002_TheAltStatement_049 |verify that the `timeout` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|50 |NegSem_2002_TheAltStatement_050 |verify that a non-deterministic external function call cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|51 |NegSem_2002_TheAltStatement_051 |verify that the predefined `rnd` function cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|52 |NegSem_2002_TheAltStatement_052 |verify a function called in a guard of an `altstep` cannot contain an assignment of a component variable |Clause 20.2 |m |n
+|53 |NegSem_2002_TheAltStatement_053 |verify a function called in a guard of an `altstep` cannot contain a component variable used as an actual `out` parameter |Clause 20.2 |m |n
+|54 |NegSem_2002_TheAltStatement_054 |verify a function called in a guard of an `altstep` cannot contain a component variable used as an actual `inout` parameter |Clause 20.2 |m |n
+|55 |NegSem_2002_TheAltStatement_055 |verify that the `setverdict` operation cannot be used in `guard` statements of altstep |Clause 20.2 |m |n
+|56 |NegSem_2002_TheAltStatement_056 |verify that the `activate` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|57 |NegSem_2002_TheAltStatement_057 |verify that the `deactivate` operation cannot be used in parameters of altsteps invoked from an `alt` branch |Clause 20.2 |m |n
+|58 |NegSem_2002_TheAltStatement_058 |verify that a function used in a parameter of an altstep invoked from an `alt` branch cannot contain out parameters |Clause 20.2 |m |n
+|59 |NegSem_2002_TheAltStatement_059 |verify that a function used in a parameter of an altstep invoked from an `alt` branch cannot contain `inout` parameters |Clause 20.2 |m |n
+|60 |NegSem_2002_TheAltStatement_060 |verify that the `read` operation cannot be used in `guard` statements |Clause 20.2 |m |n
+|61 |NegSem_2002_TheAltStatement_061 |verify that the `checkstate` operation cannot be used in `guard` statements |Clause 20.2 |m |n
+|62 |NegSem_2002_TheAltStatement_062 |verify that the `read` operation cannot be used in `alt` branch events (in inline templates) |Clause 20.2 |m |n
+|63 |NegSem_2002_TheAltStatement_063 |verify that the `checkstate` operation cannot be used in `alt` branch events (in inline templates) |Clause 20.2 |m |n
+|64 |NegSem_2002_TheAltStatement_064 |verify that the `read` operation cannot be used in parameters of `alt` branch events |Clause 20.2 |m |n
+|65 |NegSem_2002_TheAltStatement_065 |verify that the `checkstate` operation cannot be used in parameters of `alt` branch events |Clause 20.2 |m |n
+|66 |NegSem_2002_TheAltStatement_066 |verify that the `create` operation cannot be used in `alt` branch events (in inline template) |Clause 20.2 |m |n
+|67 |NegSem_2002_TheAltStatement_067 |verify that the `component.running` operation cannot be used in `alt` branch events (in templates) |Clause 20.2 |m |n
+|68 |NegSem_2002_TheAltStatement_068 |verify that the `alive` operation cannot be used in `alt` branch events (in templates) |Clause 20.2 |m |n
+|69 |NegSem_2002_TheAltStatement_069 |verify that the `checkstate` operation cannot be used in `alt` branch events (in templates) |Clause 20.2 |m |n
+|70 |NegSem_2002_TheAltStatement_070 |verify that the `timer.running` operation cannot be used in `alt` branch events (in templates) |Clause 20.2 |m |n
+|71 |NegSem_2002_TheAltStatement_071 |verify that the `read` operation cannot be used in `alt` branch events (in templates) |Clause 20.2 |m |n
+|72 |NegSem_2002_TheAltStatement_072 |verify that the `activate` operation cannot be used in `alt` branch events (in templates) |Clause 20.2 |m |n
+|73 |NegSem_2002_TheAltStatement_073 |verify that the `create` operation cannot be used in `alt` branch events (in inline template) |Clause 20.2 |m |n
+|74 |NegSem_2002_TheAltStatement_074 |verify that the `component.running` operation cannot be used in `alt` branch events (in template parameters) |Clause 20.2 |m |n
+|75 |NegSem_2002_TheAltStatement_075 |verify that the `alive` operation cannot be used in `alt` branch events (in template parameters) |Clause 20.2 |m |n
+|76 |NegSem_2002_TheAltStatement_076 |verify that the `checkstate` operation cannot be used in `alt` branch events (in template parameters) |Clause 20.2 |m |n
+|77 |NegSem_2002_TheAltStatement_077 |verify that the `timer.running` operation cannot be used in `alt` branch events (in template parameters) |Clause 20.2 |m |n
+|78 |NegSem_2002_TheAltStatement_078 |verify that the `read` operation cannot be used in `alt` branch events (in template parameters) |Clause 20.2 |m |n
+|79 |NegSem_2002_TheAltStatement_079 |verify that the `activate` operation cannot be used in `alt` branch events (in template parameters) |Clause 20.2 |m |n
+|80 |NegSem_2002_TheAltStatement_080 |verify that the `create` operation cannot be used in `alt` branch events (in inline template) |Clause 20.2 |m |n
+|81 |NegSem_2002_TheAltStatement_081 |verify that the `component.running` operation cannot be used in altstep declarations |Clause 20.2 |m |n
+|82 |NegSem_2002_TheAltStatement_082 |verify that the `alive` operation cannot be used in altstep declarations |Clause 20.2 |m |n
+|83 |NegSem_2002_TheAltStatement_083 |verify that the `checkstate` operation cannot be used in altstep declarations |Clause 20.2 |m |n
+|84 |NegSem_2002_TheAltStatement_084 |verify that the `timer.running` operation cannot be used in altstep declarations |Clause 20.2 |m |n
+|85 |NegSem_2002_TheAltStatement_085 |verify that the `read` operation cannot be used in altstep declarations |Clause 20.2 |m |n
+|86 |NegSem_2002_TheAltStatement_086 |verify that the `activate` operation cannot be used in altstep declarations |Clause 20.2 |m |n
+|87 |Sem_2002_TheAltStatement_001 |The `alt`-statement works as expected (loopback case). |Clause 20.2 |m |y
+|88 |Sem_2002_TheAltStatement_002 |The `alt`-statement with a guard works as expected (loopback case). |Clause 20.2 |m |y
+|89 |Sem_2002_TheAltStatement_003 |The `alt`-statement processes the alternatives in order (loopback case). |Clause 20.2 |m |y
+|90 |Sem_2002_TheAltStatement_004 |Activated defaults are processed in the reverse order (loopback case). |Clause 20.2 |m |y
+|91 |Sem_2002_TheAltStatement_005 |The else branch is executed when nothing else matched (loopback case). |Clause 20.2 |m |y
+|92 |Sem_2002_TheAltStatement_006 |An altstep invocation works as expected (loopback case). |Clause 20.2 |m |y
+|93 |Sem_2002_TheAltStatement_007 |An altstep invocation works as expected and that the `optional` statement block is executed after the altstep staatement block (loopback case). |Clause 20.2 |m |y
+|94 |Sem_2002_TheAltStatement_008 |The done-block in an `alt`-statement is triggered as expected (loopback case). |Clause 20.2 |m |y
+|95 |Sem_2002_TheAltStatement_009 |The killed-block in an `alt`-statement is triggered as expected when the component is killed (loopback case). |Clause 20.2 |m |y
+|96 |Sem_2002_TheAltStatement_010 |The timeout branch is taken as expected (loopback case). |Clause 20.2 |m |y
+|97 |Sem_2002_TheAltStatement_011 |The behaviour continues after the `alt`-statement (loopback case). |Clause 20.2 |m |y
+|98 |Sem_2002_TheAltStatement_012 |`alt` statements are correctly handled for dynamically mapped ports |Clause 20.2 |m |y
+|99 |Sem_2002_TheAltStatement_013 |`alt` statements are correctly handled for dynamically mapped ports |Clause 20.2 |m |y
+|100 |Sem_2002_TheAltStatement_014 |no default activation after else |Clause 20.2 |m |y
+|==================================================================================================================================================================================================
+
+== The `repeat` statement
+
+.The `repeat` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2003_the_repeat_statement_001 |The IUT correctly processes `repeat` statements |Clause 20.3 |m |y
+|2 |Sem_2003_the_repeat_statement_001 |The IUT correctly processes `repeat` statements |Clause 20.3 |m |y
+|3 |Sem_2003_the_repeat_statement_002 |repeat in procedure call block |Clause 20.3 |m |n
+|4 |Sem_2003_the_repeat_statement_003 |repeat in alstep branch of `alt` statements |Clause 20.3 |m |y
+|5 |Sem_2003_the_repeat_statement_004 |repeat in executed default |Clause 20.3 |m |y
+|=========================================================================================================
+
+== The `interleave` statement
+
+.The `interleave` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2004_InterleaveStatement_001 |Validate that `interleave` statements are properly handled. |Clause 20.4 |m |n
+|2 |NegSem_2004_InterleaveStatement_002 |while loop inside interleave |Clause 20.4 |m |n
+|3 |NegSem_2004_InterleaveStatement_003 |do-while loop inside interleave |Clause 20.4 |m |n
+|4 |NegSem_2004_InterleaveStatement_004 |goto inside interleave |Clause 20.4 |m |y
+|5 |NegSem_2004_InterleaveStatement_005 |activate call inside interleave |Clause 20.4 |m |n
+|6 |NegSem_2004_InterleaveStatement_006 |deactivate call inside interleave |Clause 20.4 |m |n
+|7 |NegSem_2004_InterleaveStatement_007 |stop inside interleave |Clause 20.4 |m |n
+|8 |NegSem_2004_InterleaveStatement_008 |repeat inside interleave |Clause 20.4 |m |y
+|9 |NegSem_2004_InterleaveStatement_009 |return inside interleave |Clause 20.4 |m |y
+|10 |NegSem_2004_InterleaveStatement_010 |explicit altstep call inside interleave |Clause 20.4 |m |y
+|11 |NegSem_2004_InterleaveStatement_011 |direct function call containing `reception` statement inside interleave |Clause 20.4 |m |n
+|12 |NegSem_2004_InterleaveStatement_012 |indirect function call containing `reception` statement inside interleave |Clause 20.4 |m |n
+|13 |NegSyn_2004_InterleaveStatement_001 |Validate that `interleave` statements are properly handled. |Clause 20.4 |m |y
+|14 |NegSyn_2004_InterleaveStatement_002 |Validate that `interleave` statements are properly handled. |Clause 20.4 |m |y
+|15 |Sem_2004_InterleaveStatement_001 |Validate that `interleave` statements are properly handled. |Clause 20.4 |m |y
+|16 |Sem_2004_InterleaveStatement_002 |Validate that `interleave` statements are properly handled. |Clause 20.4 |m |y
+|17 |Sem_2004_InterleaveStatement_003 |while loop inside interleave |Clause 20.4 |m |y
+|18 |Syn_2004_InterleaveStatement_001 |Validate that `interleave` statements are properly handled. |Clause 20.4 |m |y
+|===================================================================================================================================
+
+== The default mechanism
+
+.The default mechanism
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_200501_the_default_mechanism_001 |verify unsuccessful default termination |Clause 20.5.1 |m |y
+|2 |Sem_200501_the_default_mechanism_001 |verify that activated default is invoked |Clause 20.5.1 |m |y
+|3 |Sem_200501_the_default_mechanism_002 |verify that default are processed in interleave |Clause 20.5.1 |m |y
+|4 |Sem_200501_the_default_mechanism_003 |verify than default are processed in interleave |Clause 20.5.1 |m |y
+|5 |Sem_200501_the_default_mechanism_004 |verify that default processing order is correct |Clause 20.5.1 |m |y
+|6 |Sem_200501_the_default_mechanism_005 |verify that default processing order is correct |Clause 20.5.1 |m |y
+|7 |Sem_200501_the_default_mechanism_006 |verify repeat command `behaviour` in invoked default |Clause 20.5.1 |m |y
+|8 |Sem_200501_the_default_mechanism_007 |verify break command `behaviour` in invoked default |Clause 20.5.1 |m |y
+|9 |Sem_200501_the_default_mechanism_008 |verify stop command `behaviour` in invoked default |Clause 20.5.1 |m |y
+|10 |NegSem_200503_the_deactivate_operation_001 |verify that deactivate deactivated default causes error |Clause 20.5.3 |m |n
+|11 |NegSem_200503_the_deactivate_operation_002 |verify that deactivate uninitialized default causes error |Clause 20.5.3 |m |y
+|12 |NegSem_200503_the_deactivate_operation_003 |verify that error is generated when deactivated reference is on incorrect type |Clause 20.5.3 |m |y
+|13 |Sem_200503_the_deactivate_operation_001 |verify that deactivate removes default from list of defaults |Clause 20.5.3 |m |y
+|14 |Sem_200503_the_deactivate_operation_002 |verify that deactivate removes default from list of defaults |Clause 20.5.3 |m |y
+|15 |Sem_200503_the_deactivate_operation_003 |verify that deactivate without parameter clear list of defaults |Clause 20.5.3 |m |y
+|16 |Sem_200503_the_deactivate_operation_004 |verify that deactivate `null` works correctly |Clause 20.5.3 |m |y
+|===================================================================================================================================================
+
+== The `activate` operation
+
+.The `activate` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_200502_the_activate_operation_001 |verify error is generated if activated alstep `runs on` incompatible component |Clause 20.5.2 |m |y
+|2 |NegSem_200502_the_activate_operation_002 |verify error is generated when passing local timer |Clause 20.5.2 |m |y
+|3 |NegSem_200502_the_activate_operation_003 |verify error is generated when activating altstep with `out` parameters |Clause 20.5.2 |m |n
+|4 |NegSem_200502_the_activate_operation_004 |verify error is generated when activating altstep with `inout` parameters |Clause 20.5.2 |m |n
+|5 |NegSem_200502_the_activate_operation_005 |verify error is generated when activating function |Clause 20.5.2 |m |y
+|6 |NegSem_200502_the_activate_operation_006 |local timer as a parameter of activated altstep in module control |Clause 20.5.2 |m |y
+|7 |NegSem_200502_the_activate_operation_007 |local timer (referenced through timer parameter) as a parameter of activated altstep in module control |Clause 20.5.2 |m |y
+|8 |Sem_200502_the_activate_operation_001 |verify that `activate` operation can be used as standalone statement |Clause 20.5.2 |m |y
+|9 |Sem_200502_the_activate_operation_002 |verify that parameters are passed at activation time |Clause 20.5.2 |m |y
+|10 |Sem_200502_the_activate_operation_003 |verify that passing component timer to activated altstep |Clause 20.5.2 |m |y
+|11 |Sem_200502_the_activate_operation_004 |verify passing port parameter to activated altstep |Clause 20.5.2 |m |y
+|12 |Sem_200502_the_activate_operation_005 |control block timer as a parameter of activated altstep |Clause 20.5.2 |m |n
+|13 |Sem_200502_the_activate_operation_006 |control block timer (referenced through timer parameter) as a parameter of activated altstep |Clause 20.5.2 |m |n
+|========================================================================================================================================================================
+
+== `Connection` operations
+
+.`Connection` operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2101_TopLevel_001 |Verify that `connect` operation cannot contain a system port |Clause 21.1 |m |y
+|2 |NegSem_2101_TopLevel_002 |Verify that `map` operation fails if both operands are component ports |Clause 21.1 |m |y
+|====================================================================================================================
+
+== The `connect` and `map` operations
+
+.The `connect` and `map` operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210101_connect_and_map_operations_001 |Verify that `connect` operation rejects ports with incompatible message type lists |Clause 21.1.1 |m |y
+|2 |NegSem_210101_connect_and_map_operations_002 |Verify that `connect` operation rejects ports with only partially compatible message type lists |Clause 21.1.1 |m |y
+|3 |NegSem_210101_connect_and_map_operations_003 |Verify that `map` operation rejects ports with incompatible message type lists |Clause 21.1.1 |m |y
+|4 |NegSem_210101_connect_and_map_operations_004 |Verify that `connect` operation rejects ports with only partially compatible message type lists |Clause 21.1.1 |m |y
+|5 |NegSem_210101_connect_and_map_operations_005 |Verify that `map` parameters cannot be used when not declared in the port type |Clause 21.1.1 |m |n
+|6 |NegSem_210101_connect_and_map_operations_006 |Verify that type incompatibility in `map` parameters is detected |Clause 21.1.1 |m |n
+|7 |NegSem_210101_connect_and_map_operations_007 |Verify that parameter count mismatch in `map` param clause is detected |Clause 21.1.1 |m |n
+|8 |NegSem_210101_connect_and_map_operations_008 |violation of strong typing rules for local ports in `connect` operations |Clause 21.1.1 |m |y
+|9 |NegSem_210101_connect_and_map_operations_009 |violation of strong typing rules for MTC ports in `connect` operations |Clause 21.1.1 |m |n
+|10 |NegSem_210101_connect_and_map_operations_010 |violation of strong typing rules for PTC ports in `connect` operations |Clause 21.1.1 |m |y
+|11 |NegSem_210101_connect_and_map_operations_011 |violation of strong typing rules for local ports in `map` operations |Clause 21.1.1 |m |n
+|12 |NegSem_210101_connect_and_map_operations_012 |violation of strong typing rules for MTC ports in `map` operations |Clause 21.1.1 |m |n
+|13 |NegSem_210101_connect_and_map_operations_013 |violation of strong typing rules for PTC ports in `map` operations |Clause 21.1.1 |m |y
+|14 |NegSem_210101_connect_and_map_operations_014 |violation of strong typing rules for system ports in `map` operations |Clause 21.1.1 |m |n
+|15 |NegSem_210101_connect_operation_001 |The the IUT does not allows two output port connection |Clause 21.1.1 |m |y
+|16 |NegSem_210101_connect_operation_002 |The the IUT does not allow connecting incompatible ports |Clause 21.1.1 |m |y
+|17 |NegSem_210101_map_operation_001 |IUT cannot map input port with output port |Clause 21.1.1 |m |n
+|18 |NegSem_210101_map_operation_002 |IUT cannot map input port with output port |Clause 21.1.1 |m |y
+|19 |Sem_210101_connect_and_map_operations_001 |`Connect` operation accepts ports with compatible message type list containing several types |Clause 21.1.1 |m |y
+|20 |Sem_210101_connect_and_map_operations_002 |`Connect` operation accepts ports where `outlist` of the 1st port is a subset of `inlist` of the 2nd port |Clause 21.1.1 |m |y
+|21 |Sem_210101_connect_and_map_operations_003 |`Connect` operation accepts ports where `outlist` of the 2nd port is a subset of `inlist` of the 1st port |Clause 21.1.1 |m |y
+|22 |Sem_210101_connect_and_map_operations_004 |`Connect` operation accepts ports where `outlist` of both ports are subsets of `inlist` of the counterpart ports |Clause 21.1.1 |m |y
+|23 |Sem_210101_connect_and_map_operations_005 |`Map` operation accepts ports with compatible message type list containing several types |Clause 21.1.1 |m |y
+|24 |Sem_210101_connect_and_map_operations_006 |`Map` operation accepts ports with compatible message type list containing several types |Clause 21.1.1 |m |y
+|25 |Sem_210101_connect_and_map_operations_007 |`Map` operation accepts ports with compatible message type list containing several types |Clause 21.1.1 |m |y
+|26 |Sem_210101_connect_and_map_operations_008 |`Map` operation accepts ports with compatible message type list containing several types |Clause 21.1.1 |m |y
+|27 |Sem_210101_connect_and_map_operations_009 |`Map` param statements are allowed in testcase block |Clause 21.1.1 |m |n
+|28 |Sem_210101_connect_and_map_operations_010 |Verify that the param part can be skipped in `map` operations |Clause 21.1.1 |m |n
+|==============================================================================================================================================================================
+
+== The `disconnect` and `unmap` operations
+
+.The `disconnect` and `unmap` operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210102_disconnect_and_unmap_operations_001 |Verify that `unmap` operation cannot contain a system port reference |Clause 21.1.2 |m |y
+|2 |NegSem_210102_disconnect_and_unmap_operations_002 |Verify that disconnecting all ports of all components is not possible in PTC |Clause 21.1.2 |m |n
+|3 |NegSem_210102_disconnect_and_unmap_operations_003 |Verify that unmapping all ports of all components is not possible in PTC |Clause 21.1.2 |m |n
+|4 |NegSem_210102_disconnect_and_unmap_operations_004 |Verify that unmap parameters cannot be used when not declared in the port type |Clause 21.1.2 |m |n
+|5 |NegSem_210102_disconnect_and_unmap_operations_005 |Verify that type incompatibility in `unmap` parameters is detected |Clause 21.1.2 |m |n
+|6 |NegSem_210102_disconnect_and_unmap_operations_006 |Verify that parameter count mismatch in `unmap` param clause is detected |Clause 21.1.2 |m |n
+|7 |NegSem_210102_disconnect_and_unmap_operations_007 |Verify that the param clause cannot be used when `unmap` contains no system port reference |Clause 21.1.2 |m |n
+|8 |NegSem_210102_disconnect_and_unmap_operations_008 |violation of strong typing rules for local ports in `disconnect` operations |Clause 21.1.2 |m |y
+|9 |NegSem_210102_disconnect_and_unmap_operations_009 |violation of strong typing rules for MTC ports in `disconnect` operations |Clause 21.1.2 |m |n
+|10 |NegSem_210102_disconnect_and_unmap_operations_010 |violation of strong typing rules for PTC ports in `disconnect` operations |Clause 21.1.2 |m |y
+|11 |NegSem_210102_disconnect_and_unmap_operations_011 |violation of strong typing rules for local ports in `unmap` operations |Clause 21.1.2 |m |n
+|12 |NegSem_210102_disconnect_and_unmap_operations_012 |violation of strong typing rules for MTC ports in `unmap` operations |Clause 21.1.2 |m |n
+|13 |NegSem_210102_disconnect_and_unmap_operations_013 |violation of strong typing rules for PTC ports in `unmap` operations |Clause 21.1.2 |m |y
+|14 |NegSem_210102_disconnect_and_unmap_operations_014 |violation of strong typing rules for system ports in `unmap` operations |Clause 21.1.2 |m |n
+|15 |NegSem_210102_disconnect_operation_001 |Mapped port cannot disconnect |Clause 21.1.2 |m |y
+|16 |Sem_210102_disconnect_and_unmap_operations_001 |`Disconnect` operation with two parameters works correctly |Clause 21.1.2 |m |y
+|17 |Sem_210102_disconnect_and_unmap_operations_002 |`Disconnect` operation with one parameter works correctly |Clause 21.1.2 |m |n
+|18 |Sem_210102_disconnect_and_unmap_operations_003 |`Disconnect` operation with all ports of a component works correctly |Clause 21.1.2 |m |n
+|19 |Sem_210102_disconnect_and_unmap_operations_004 |`Disconnect` operation with no argument works correctly |Clause 21.1.2 |m |n
+|20 |Sem_210102_disconnect_and_unmap_operations_005 |`Unmap` operation with one system port as a parameter works correctly |Clause 21.1.2 |m |n
+|21 |Sem_210102_disconnect_and_unmap_operations_006 |`Unmap` operation with one component port as a parameter works correctly |Clause 21.1.2 |m |n
+|22 |Sem_210102_disconnect_and_unmap_operations_007 |`Unmap` operation with all ports of a component works correctly |Clause 21.1.2 |m |n
+|23 |Sem_210102_disconnect_and_unmap_operations_008 |`Unmap` operation with no parameters works correctly |Clause 21.1.2 |m |n
+|24 |Sem_210102_disconnect_and_unmap_operations_009 |All component notation works correctly in `unmap` operations |Clause 21.1.2 |m |n
+|25 |Sem_210102_disconnect_and_unmap_operations_010 |Verify that no error is generated when unmapping ports that are not mapped |Clause 21.1.2 |m |y
+|26 |Sem_210102_disconnect_and_unmap_operations_011 |`Unmap` param statements are allowed in testcase block |Clause 21.1.2 |m |n
+|27 |Sem_210102_disconnect_and_unmap_operations_012 |Verify that the param part can be skipped in `unmap` operations |Clause 21.1.2 |m |n
+|28 |Sem_210102_disconnect_and_unmap_operations_013 |Verify that the param clause can be used when `unmap` contains a single system port parameter |Clause 21.1.2 |m |n
+|29 |Sem_210102_disconnect_operation_001 |All component notation work correctly in `disconnect` operation |Clause 21.1.2 |m |n
+|30 |Sem_210102_disconnect_operation_002 |Disconnect has no effect on components that are not connected |Clause 21.1.2 |m |y
+|31 |Sem_210102_unmap_operation_001 |`Umnap` operation of a system and component port works correctly |Clause 21.1.2 |m |y
+|32 |Sem_210102_unmap_operation_002 |`Umnap` operation of a component and system port works correctly |Clause 21.1.2 |m |y
+|====================================================================================================================================================================
+
+== Test case operations
+
+.Test case operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2102_testcase_stop_001 |Stopping test case |Clause 21.2 |m |y
+|==========================================================================
+
+== The `create` operation
+
+.The `create` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210301_CreateOperation_001 |Named components on hosts are accepted |Clause 21.3.1 |m |y
+|2 |NegSem_210301_CreateOperation_002 |Named components on hosts are accepted |Clause 21.3.1 |m |y
+|3 |NegSem_210301_CreateOperation_003 |Named components on hosts are accepted |Clause 21.3.1 |m |y
+|4 |Sem_210301_CreateOperation_001 |Unnamed components can be created |Clause 21.3.1 |m |y
+|5 |Sem_210301_CreateOperation_002 |Named components can be created |Clause 21.3.1 |m |y
+|6 |Sem_210301_CreateOperation_003 |Unnamed alive components on hosts can be created |Clause 21.3.1 |m |y
+|7 |Sem_210301_CreateOperation_004 |Named alive components can be created |Clause 21.3.1 |m |y
+|8 |Syn_210301_CreateOperation_001 |Named components on hosts are accepted |Clause 21.3.1 |m |y
+|========================================================================================================
+
+== The `start test` component operation
+
+.The `start` test component operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210302_Start_test_component_001 |Non-alive ptc cannot start again |Clause 21.3.2 |m |y
+|2 |NegSem_210302_Start_test_component_002 |Only component type is allowed for ptc declaration |Clause 21.3.2 |m |y
+|3 |NegSem_210302_Start_test_component_003 |altstep in test component `start` operation |Clause 21.3.2 |m |y
+|4 |NegSem_210302_Start_test_component_004 |starting behaviour on already running non-alive component |Clause 21.3.2 |m |y
+|5 |NegSem_210302_Start_test_component_005 |starting behaviour on already running non-alive component |Clause 21.3.2 |m |y
+|6 |NegSem_210302_Start_test_component_006 |function invocation in the `start` operation doesn't return a component |Clause 21.3.2 |m |y
+|7 |NegSem_210302_Start_test_component_007 |starting function with incompatible `runs on` clause |Clause 21.3.2 |m |y
+|8 |NegSem_210302_Start_test_component_008 |passing port to started component function |Clause 21.3.2 |m |y
+|9 |NegSem_210302_Start_test_component_009 |passing default to started component function |Clause 21.3.2 |m |y
+|10 |NegSem_210302_Start_test_component_010 |passing timer to started component function |Clause 21.3.2 |m |y
+|11 |NegSem_210302_Start_test_component_011 |passing structured value containing ports to started component function |Clause 21.3.2 |m |y
+|12 |NegSem_210302_Start_test_component_012 |passing default to started component function |Clause 21.3.2 |m |y
+|13 |Sem_210302_Start_test_component_001 |Alive test components are allowed to start another function |Clause 21.3.2 |m |y
+|14 |Sem_210302_Start_test_component_002 |component variable reference in `start` operation |Clause 21.3.2 |m |y
+|15 |Sem_210302_Start_test_component_003 |test component as a result of function invocation in `start` operation |Clause 21.3.2 |m |y
+|16 |Sem_210302_Start_test_component_004 |component variable value reuse in alive component |Clause 21.3.2 |m |y
+|17 |Sem_210302_Start_test_component_005 |timer reuse in alive component |Clause 21.3.2 |m |y
+|18 |Sem_210302_Start_test_component_006 |port reuse in alive component |Clause 21.3.2 |m |y
+|19 |Sem_210302_Start_test_component_007 |verdict value reuse in alive component |Clause 21.3.2 |m |y
+|20 |Sem_210302_Start_test_component_008 |timer reuse in alive component |Clause 21.3.2 |m |y
+|21 |Sem_210302_Start_test_component_009 |deactivation of defaults in alive components |Clause 21.3.2 |m |n
+|22 |Sem_210302_Start_test_component_010 |starting function with compatible `runs on` clause |Clause 21.3.2 |m |y
+|23 |Sem_210302_Start_test_component_011 |altstep in test component `start` operation |Clause 21.3.2 |m |n
+|24 |Sem_210302_Start_test_component_012 |`start` operation works with parametered altsteps |Clause 21.3.2 |m |n
+|25 |Sem_210302_Start_test_component_013 |`inout` parameters will be passed to the function by value, i.e. like `in`-parameters |Clause 21.3.2 |m |y
+|26 |Sem_210302_Start_test_component_014 |`inout` parameters will be passed to the function by value, i.e. like `in`-parameters |Clause 21.3.2 |m |y
+|===============================================================================================================================================
+
+== The `stop` test behaviour operation
+
+.The `stop` test behaviour operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210303_Stop_test_component_001 |restarting explicitly stopped non-alive component |Clause 21.3.3 |m |y
+|2 |NegSem_210303_Stop_test_component_002 |stopping all PTCs from a PTC |Clause 21.3.3 |m |y
+|3 |NegSem_210303_Stop_test_component_003 |applying `stop` operation to a variable of a different than component type |Clause 21.3.3 |m |y
+|4 |NegSem_210303_Stop_test_component_004 |applying `stop` operation to a function call result of a different than component type |Clause 21.3.3 |m |y
+|5 |Sem_210303_Stop_test_component_001 |`Component.stop` causes the stopping of the target component. |Clause 21.3.3 |m |y
+|6 |Sem_210303_Stop_test_component_002 |`Self.stop` stops current component |Clause 21.3.3 |m |y
+|7 |Sem_210303_Stop_test_component_003 |stopping MTC from PTC |Clause 21.3.3 |m |y
+|8 |Sem_210303_Stop_test_component_004 |`stop.self` in MTC |Clause 21.3.3 |m |y
+|9 |Sem_210303_Stop_test_component_005 |alive component restart after explicit stop |Clause 21.3.3 |m |y
+|10 |Sem_210303_Stop_test_component_006 |component variable value reuse in alive component after explicit stop |Clause 21.3.3 |m |y
+|11 |Sem_210303_Stop_test_component_007 |timer reuse in alive component after explicit stop |Clause 21.3.3 |m |y
+|12 |Sem_210303_Stop_test_component_008 |port reuse in alive component after explicit stop |Clause 21.3.3 |m |y
+|13 |Sem_210303_Stop_test_component_009 |verdict value reuse in alive component after explicit stop |Clause 21.3.3 |m |y
+|14 |Sem_210303_Stop_test_component_010 |deactivation of defaults in alive components after explicit stop |Clause 21.3.3 |m |n
+|15 |Sem_210303_Stop_test_component_011 |stopping all PTCs |Clause 21.3.3 |m |y
+|===================================================================================================================================================
+
+== The `kill` test component operation
+
+.The `kill` test component operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210304_kill_test_component_001 |restarting explicitly killed non-alive component |Clause 21.3.4 |m |y
+|15 |NegSem_210304_kill_test_component_002 |restarting explicitly killed alive component |Clause 21.3.4 |m |y
+|2 |NegSem_210304_kill_test_component_003 |killing all PTCs from a PTC |Clause 21.3.4 |m |y
+|3 |NegSem_210304_kill_test_component_004 |applying `kill` operation to a variable of a different than component type |Clause 21.3.4 |m |y
+|4 |NegSem_210304_kill_test_component_005 |applying `kill` operation to a function call result of a different than component type |Clause 21.3.4 |m |y
+|5 |Sem_210304_kill_test_component_001 |Kill operator stops a non alive test components. |Clause 21.3.4 |m |y
+|6 |Sem_210304_kill_test_component_002 |All component kill stop all ptcs |Clause 21.3.4 |m |y
+|7 |Sem_210304_kill_test_component_003 |Kill operator stops only non alive test components |Clause 21.3.4 |m |y
+|8 |Sem_210304_kill_test_component_004 |Self kill called in a functions stops non alive test comp. |Clause 21.3.4 |m |y
+|9 |Sem_210304_kill_test_component_005 |standalone kill in alive PTC |Clause 21.3.4 |m |y
+|10 |Sem_210304_kill_test_component_006 |killing MTC from PTC |Clause 21.3.4 |m |y
+|===================================================================================================================================================
+
+== The `alive` operation
+
+.The `alive` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210305_alive_operation_001 |Verify that error occurs when any from alive is applied to single component |Clause 21.3.5 |m |y
+|2 |NegSem_210305_alive_operation_002 |Verify that error occurs when any from alive is applied to 1D array and index target is array |Clause 21.3.5 |m |y
+|3 |NegSem_210305_alive_operation_003 |Verify that error occurs when any from alive is applied to 1D array and index target has wrong type |Clause 21.3.5 |m |y
+|4 |NegSem_210305_alive_operation_004 |Verify that any from alive index redirection for multi-D arrays requires arrays of correct size |Clause 21.3.5 |m |y
+|5 |NegSem_210305_alive_operation_005 |Verify that any from alive index redirection for multi-D arrays requires arrays |Clause 21.3.5 |m |y
+|6 |NegSem_210305_alive_operation_006 |partially initialized array in any from `ComponentArrayRef.alive` |Clause 21.3.5 |m |n
+|7 |NegSyn_210305_alive_operation_001 |Verify that error occurs when using index redirection in `component.alive` operation |Clause 21.3.5 |m |y
+|8 |NegSyn_210305_alive_operation_002 |Verify that error occurs when using index redirection in any `component.alive` operation |Clause 21.3.5 |m |y
+|9 |NegSyn_210305_alive_operation_003 |Verify that error occurs when using index redirection in all `component.alive` operation |Clause 21.3.5 |m |y
+|10 |NegSyn_210305_alive_operation_004 |Verify that error occurs when using index redirection in function `instance.alive` operation |Clause 21.3.5 |m |y
+|11 |Sem_210305_alive_operation_001 |Testing alive operator with an alive test component |Clause 21.3.5 |m |y
+|12 |Sem_210305_alive_operation_002 |Test all component alive operator with alive test components |Clause 21.3.5 |m |y
+|13 |Sem_210305_alive_operation_003 |Alive operator gives a correct boolean result |Clause 21.3.5 |m |y
+|14 |Sem_210305_alive_operation_004 |Test any component alive operator with multiple test components |Clause 21.3.5 |m |y
+|15 |Sem_210305_alive_operation_005 |Verify that any from alive returns false if no component is alive |Clause 21.3.5 |m |y
+|16 |Sem_210305_alive_operation_006 |Verify that any from alive returns true if at least one component is inactive |Clause 21.3.5 |m |y
+|17 |Sem_210305_alive_operation_007 |Verify that any from alive returns true if at least one component is running |Clause 21.3.5 |m |y
+|18 |Sem_210305_alive_operation_008 |Verify that any from alive doesn't assign index when no component is alive |Clause 21.3.5 |m |y
+|19 |Sem_210305_alive_operation_009 |Verify that any from alive assigns index |Clause 21.3.5 |m |y
+|20 |Sem_210305_alive_operation_010 |Verify that any from alive can be used inside expressions |Clause 21.3.5 |m |y
+|21 |Sem_210305_alive_operation_011 |Verify that any from alive index redirection works for multidimensional arrays |Clause 21.3.5 |m |y
+|22 |Sem_210305_alive_operation_012 |Verify that any from alive doesn't change index variable when no component is alive |Clause 21.3.5 |m |y
+|23 |Sem_210305_alive_operation_013 |Verify any from alive index redirection to lazy variable |Clause 21.3.5 |m |y
+|24 |Sem_210305_alive_operation_014 |Verify any from alive index redirection to fuzzy variable |Clause 21.3.5 |m |y
+|25 |Sem_210305_alive_operation_015 |Alive applied on the `mtc` the operation returns true |Clause 21.3.5 |m |n
+|==============================================================================================================================================================
+
+== The `running` operation
+
+.The `running` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210306_running_operation_001 |Verify that error occurs when any from running is applied to single component |Clause 21.3.6 |m |y
+|2 |NegSem_210306_running_operation_002 |Verify that error occurs when any from running is applied to 1D array and index target is array |Clause 21.3.6 |m |y
+|3 |NegSem_210306_running_operation_003 |Verify that error occurs when any from running is applied to 1D array and index target has wrong type |Clause 21.3.6 |m |y
+|4 |NegSem_210306_running_operation_004 |Verify that any from running index redirection for multi-D arrays requires arrays of correct size |Clause 21.3.6 |m |y
+|5 |NegSem_210306_running_operation_005 |Verify that any from running index redirection for multi-D arrays requires arrays |Clause 21.3.6 |m |y
+|6 |NegSem_210306_running_operation_006 |partially initialized array in any from `ComponentArrayRef.running` |Clause 21.3.6 |m |n
+|7 |NegSyn_210306_running_operation_001 |Verify that error occurs when using index redirection in `component.running` operation |Clause 21.3.6 |m |y
+|8 |NegSyn_210306_running_operation_002 |Verify that error occurs when using index redirection in any `component.running` operation |Clause 21.3.6 |m |y
+|9 |NegSyn_210306_running_operation_003 |Verify that error occurs when using index redirection in all `component.running` operation |Clause 21.3.6 |m |y
+|10 |NegSyn_210306_running_operation_004 |Verify that error occurs when using index redirection in function `instance.running` operation |Clause 21.3.6 |m |y
+|11 |Sem_210306_running_operation_001 |Check that running operator provides information about test components. |Clause 21.3.6 |m |y
+|12 |Sem_210306_running_operation_002 |Any component with running can check the status of the test components |Clause 21.3.6 |m |y
+|13 |Sem_210306_running_operation_003 |Verify that any from running returns false if no component is running |Clause 21.3.6 |m |y
+|14 |Sem_210306_running_operation_004 |Verify that any from running returns true if at least one component is running |Clause 21.3.6 |m |y
+|15 |Sem_210306_running_operation_005 |Verify that any from running doesn't assign index when no component is running |Clause 21.3.6 |m |y
+|16 |Sem_210306_running_operation_006 |Verify that any from running doesn't change index variable when no component is running |Clause 21.3.6 |m |y
+|17 |Sem_210306_running_operation_007 |Verify that any from running assigns index |Clause 21.3.6 |m |y
+|18 |Sem_210306_running_operation_008 |Verify that any from running can be used inside expressions |Clause 21.3.6 |m |y
+|19 |Sem_210306_running_operation_009 |Verify that any from running index redirection works for multidimensional arrays |Clause 21.3.6 |m |y
+|20 |Sem_210306_running_operation_010 |Verify any from running index redirection to lazy variable |Clause 21.3.6 |m |y
+|21 |Sem_210306_running_operation_011 |Verify any from running index redirection to fuzzy variable |Clause 21.3.6 |m |y
+|22 |Sem_210306_running_operation_012 |Verify that all `component.running` produces true if some components haven't been started |Clause 21.3.6 |m |y
+|23 |Sem_210306_running_operation_013 |Check that running operator provides information about `mtc` |Clause 21.3.6 |m |n
+|==================================================================================================================================================================
+
+== The `done` operation
+
+.The `done` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210307_done_operation_001 |Done operator can be used only for ptcs. |Clause 21.3.7 |m |y
+|2 |NegSem_210307_done_operation_002 |Verify that error occurs when any from done is applied to single component |Clause 21.3.7 |m |y
+|3 |NegSem_210307_done_operation_003 |Verify that error occurs when any from done is applied to 1D array and index target is array |Clause 21.3.7 |m |y
+|4 |NegSem_210307_done_operation_004 |Verify that error occurs when any from done is applied to 1D array and index target has wrong type |Clause 21.3.7 |m |y
+|5 |NegSem_210307_done_operation_005 |Verify that any from done index redirection for multi-D arrays requires arrays of correct size |Clause 21.3.7 |m |y
+|6 |NegSem_210307_done_operation_006 |Verify that any from done index redirection for multi-D arrays requires arrays |Clause 21.3.7 |m |y
+|7 |NegSem_210307_done_operation_007 |variable of incorrect type used for storing verdict in `done` operation |Clause 21.3.7 |m |n
+|8 |NegSem_210307_done_operation_008 |storing verdict in any `component.done` operation |Clause 21.3.7 |m |n
+|9 |NegSem_210307_done_operation_009 |storing verdict in all `component.done` operation |Clause 21.3.7 |m |n
+|10 |NegSem_210307_done_operation_010 |partially initialized array in any from `ComponentArrayRef.done` |Clause 21.3.7 |m |y
+|11 |NegSyn_210307_done_operation_001 |Verify that error occurs when using index redirection in `component.done` operation |Clause 21.3.7 |m |y
+|12 |NegSyn_210307_done_operation_002 |Verify that error occurs when using index redirection in any `component.done` operation |Clause 21.3.7 |m |y
+|13 |NegSyn_210307_done_operation_003 |Verify that error occurs when using index redirection in all `component.done` operation |Clause 21.3.7 |m |y
+|14 |NegSyn_210307_done_operation_004 |Verify that error occurs when using index redirection in function `instance.done` operation |Clause 21.3.7 |m |y
+|15 |Sem_210307_done_operation_001 |All component with done can check that at least one test component is not done |Clause 21.3.7 |m |y
+|16 |Sem_210307_done_operation_002 |Verify that any from done is not triggered if no component has been started |Clause 21.3.7 |m |y
+|17 |Sem_210307_done_operation_003 |Verify that any from done matches if at least one component is stopped or killed |Clause 21.3.7 |m |y
+|18 |Sem_210307_done_operation_004 |Verify that any from done doesn't assign index when no component has been stopped or killed |Clause 21.3.7 |m |y
+|19 |Sem_210307_done_operation_005 |Verify that any from done doesn't change index variable when no component has been stopped or killed |Clause 21.3.7 |m |y
+|20 |Sem_210307_done_operation_006 |Verify that any from done assigns index |Clause 21.3.7 |m |y
+|21 |Sem_210307_done_operation_007 |Verify that any from done is not triggered if all components are executing function |Clause 21.3.7 |m |y
+|22 |Sem_210307_done_operation_008 |Verify that any from done index redirection works for multidimensional arrays |Clause 21.3.7 |m |y
+|23 |Sem_210307_done_operation_009 |Verify any from done index redirection to lazy variable |Clause 21.3.7 |m |y
+|24 |Sem_210307_done_operation_010 |Verify any from done index redirection to fuzzy variable |Clause 21.3.7 |m |y
+|25 |Sem_210307_done_operation_011 |Verify that all `component.done` produces true if some components haven't been started |Clause 21.3.7 |m |y
+|26 |Sem_210307_done_operation_012 |storing verdict in `done` operation |Clause 21.3.7 |m |n
+|============================================================================================================================================================
+
+== The ``killed`` operation
+
+.The ``killed`` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_210308_killed_operation_001 |Killed operator is only valid for ptcs. |Clause 21.3.8 |m |y
+|2 |NegSem_210308_killed_operation_002 |Verify that error occurs when any from killed is applied to single component |Clause 21.3.8 |m |y
+|3 |NegSem_210308_killed_operation_003 |Verify that error occurs when any from killed is applied to 1D array and index target is array |Clause 21.3.8 |m |y
+|4 |NegSem_210308_killed_operation_004 |Verify that error occurs when any from killed is applied to 1D array and index target has wrong type |Clause 21.3.8 |m |y
+|5 |NegSem_210308_killed_operation_005 |Verify that any from killed index redirection for multi-D arrays requires arrays of correct size |Clause 21.3.8 |m |y
+|6 |NegSem_210308_killed_operation_006 |Verify that any from killed index redirection for multi-D arrays requires arrays |Clause 21.3.8 |m |y
+|7 |NegSem_210308_killed_operation_007 |variable of incorrect type used for storing verdict in `killed` operation |Clause 21.3.8 |m |n
+|8 |NegSem_210308_killed_operation_008 |storing verdict in any `component.killed` operation |Clause 21.3.8 |m |n
+|9 |NegSem_210308_killed_operation_009 |storing verdict in all `component.killed` operation |Clause 21.3.8 |m |n
+|10 |NegSem_210308_killed_operation_010 |partially initialized array in any from `ComponentArrayRef.killed` |Clause 21.3.8 |m |y
+|11 |NegSyn_210308_killed_operation_001 |Verify that error occurs when using index redirection in `component.killed` operation |Clause 21.3.8 |m |y
+|12 |NegSyn_210308_killed_operation_002 |Verify that error occurs when using index redirection in any `component.killed` operation |Clause 21.3.8 |m |y
+|13 |NegSyn_210308_killed_operation_003 |Verify that error occurs when using index redirection in all `component.killed` operation |Clause 21.3.8 |m |y
+|14 |NegSyn_210308_killed_operation_004 |Verify that error occurs when using index redirection in function `instance.killed` operation |Clause 21.3.8 |m |y
+|15 |Sem_210308_killed_operation_001 |All component kill can be checked with killed operator |Clause 21.3.8 |m |y
+|16 |Sem_210308_killed_operation_002 |check that any component and killed operator can check that at least one test component is running or not |Clause 21.3.8 |m |y
+|17 |Sem_210308_killed_operation_003 |The alive keyword is properly evaluated |Clause 21.3.8 |m |y
+|18 |Sem_210308_killed_operation_004 |Verify that any from killed is not triggered if no component has been started |Clause 21.3.8 |m |y
+|19 |Sem_210308_killed_operation_005 |Verify that any from killed matches if at least one component is stopped or killed |Clause 21.3.8 |m |y
+|20 |Sem_210308_killed_operation_006 |Verify that any from killed doesn't assign index when no component has been killed |Clause 21.3.8 |m |y
+|21 |Sem_210308_killed_operation_007 |Verify that any from killed doesn't change index variable when no component has been killed |Clause 21.3.8 |m |y
+|22 |Sem_210308_killed_operation_008 |Verify that any from killed assigns index |Clause 21.3.8 |m |y
+|23 |Sem_210308_killed_operation_009 |Verify that any from killed is not triggered if all components are executing function |Clause 21.3.8 |m |y
+|24 |Sem_210308_killed_operation_010 |Verify that any from killed index redirection works for multidimensional arrays |Clause 21.3.8 |m |y
+|25 |Sem_210308_killed_operation_011 |Verify any from killed index redirection to lazy variable |Clause 21.3.8 |m |y
+|26 |Sem_210308_killed_operation_012 |Verify any from killed index redirection to fuzzy variable |Clause 21.3.8 |m |y
+|27 |Sem_210308_killed_operation_013 |Verify that any from killed is not triggered if when alive component has stopped execution |Clause 21.3.8 |m |y
+|28 |Sem_210308_killed_operation_014 |storing verdict in `killed` operation |Clause 21.3.8 |m |n
+|===================================================================================================================================================================
+
+== The `send` operation
+
+.The `send` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220201_SendOperation_001 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|2 |NegSem_220201_SendOperation_002 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|3 |NegSem_220201_SendOperation_003 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|4 |NegSem_220201_SendOperation_004 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|5 |NegSem_220201_SendOperation_005 |missing to clause in case of one-to-many connections |Clause 22.2.1 |m |y
+|6 |NegSem_220201_SendOperation_006 |partially initialized template |Clause 22.2.1 |m |y
+|7 |NegSem_220201_SendOperation_007 |no type prefix in inline template |Clause 22.2.1 |m |y
+|8 |NegSem_220201_SendOperation_008 |incompatible address value in `send` operation |Clause 22.2.1 |m |n
+|9 |NegSem_220201_SendOperation_009 |`null` address in the to clause of `send` operation |Clause 22.2.1 |m |n
+|10 |NegSem_220201_SendOperation_010 |`null` component in the to clause of `send` operation |Clause 22.2.1 |m |y
+|11 |NegSem_220201_SendOperation_011 |`send` operation on disconnected and unmapped ports |Clause 22.2.1 |m |y
+|12 |Sem_220201_SendOperation_001 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|13 |Sem_220201_SendOperation_002 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|14 |Sem_220201_SendOperation_003 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|15 |Sem_220201_SendOperation_004 |The IUT correctly handles message sending operations |Clause 22.2.1 |m |y
+|16 |Sem_220201_SendOperation_005 |unicast `send` operation |Clause 22.2.1 |m |y
+|17 |Sem_220201_SendOperation_006 |multicast `send` operation |Clause 22.2.1 |m |n
+|18 |Sem_220201_SendOperation_007 |broadcast `send` operation |Clause 22.2.1 |m |n
+|=============================================================================================================
+
+== The `receive` operation
+
+.The `receive` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220202_ReceiveOperation_001 |The IUT correctly handles message receiving operations |Clause 22.2.2 |m |y
+|2 |NegSem_220202_ReceiveOperation_002 |no type prefix in ambiguous inline template |Clause 22.2.2 |m |y
+|3 |NegSem_220202_ReceiveOperation_003 |type mismatch in redirect value assignment |Clause 22.2.2 |m |y
+|4 |NegSem_220202_ReceiveOperation_004 |type mismatch in redirect assignment of message fields |Clause 22.2.2 |m |y
+|5 |NegSem_220202_ReceiveOperation_005 |applying `@decoded` to a forbidden field |Clause 22.2.2 |m |y
+|6 |NegSem_220202_ReceiveOperation_006 |decoding error in `@decoded` redirect assignment |Clause 22.2.2 |m |y
+|7 |NegSem_220202_ReceiveOperation_007 |invalid format value in `@decoded` redirect assignment |Clause 22.2.2 |m |y
+|8 |NegSem_220202_ReceiveOperation_008 |value of wrong type in `@decoded` redirect assignment |Clause 22.2.2 |m |y
+|9 |NegSem_220202_ReceiveOperation_009 |`encoding` parameter of `@decoded` redirect assignment applied to incorrect type |Clause 22.2.2 |m |y
+|10 |NegSem_220202_ReceiveOperation_010 |attempting to store component name in redirect assignment |Clause 22.2.2 |m |y
+|11 |NegSem_220202_ReceiveOperation_011 |attempting to receive a type missing from the port list |Clause 22.2.2 |m |y
+|12 |NegSem_220202_ReceiveOperation_012 |value redirect assignment in receive any message statement |Clause 22.2.2 |m |y
+|13 |NegSem_220202_ReceiveOperation_013 |trying to store address when receiving on connected port |Clause 22.2.2 |m |n
+|14 |NegSem_220202_ReceiveOperation_014 |type mismatch in sender redirect assignment |Clause 22.2.2 |m |y
+|15 |NegSem_220202_ReceiveOperation_015 |`null` component reference in `from` clause of `receive` operation |Clause 22.2.2 |m |y
+|16 |NegSem_220202_ReceiveOperation_016 |`null` address reference in `from` clause of `receive` operation |Clause 22.2.2 |m |n
+|17 |NegSem_220202_ReceiveOperation_017 |index redirection in standard `port.receive` |Clause 22.2.2 |m |y
+|18 |NegSem_220202_ReceiveOperation_018 |index redirection in any `port.receive` |Clause 22.2.2 |m |n
+|19 |NegSem_220202_ReceiveOperation_019 |insufficient value range of variable in index redirection |Clause 22.2.2 |m |y
+|20 |NegSem_220202_ReceiveOperation_020 |insufficient array dimension of variable in index redirection |Clause 22.2.2 |m |y
+|21 |NegSem_220202_ReceiveOperation_021 |insufficient element value range of variable in index redirection |Clause 22.2.2 |m |y
+|22 |NegSem_220202_ReceiveOperation_022 |incompatible `from` and `sender` clause |Clause 22.2.2 |m |y
+|23 |NegSem_220202_ReceiveOperation_023 |incompatible `decmatch` and `@decoded` value redirect |Clause 22.2.2 |m |n
+|24 |Sem_220202_ReceiveOperation_001 |The IUT correctly handles message receiving operations |Clause 22.2.2 |m |y
+|25 |Sem_220202_ReceiveOperation_002 |The IUT correctly handles message receiving operations |Clause 22.2.2 |m |y
+|26 |Sem_220202_ReceiveOperation_003 |The IUT correctly handles message receiving operations |Clause 22.2.2 |m |y
+|27 |Sem_220202_ReceiveOperation_004 |The IUT correctly handles message receiving operations |Clause 22.2.2 |m |n
+|28 |Sem_220202_ReceiveOperation_005 |The IUT correctly handles message receiving operations |Clause 22.2.2 |m |n
+|29 |Sem_220202_ReceiveOperation_006 |receive with a `from` clause (single item) |Clause 22.2.2 |m |y
+|30 |Sem_220202_ReceiveOperation_007 |receive with a `from` clause (multiple items) |Clause 22.2.2 |m |y
+|31 |Sem_220202_ReceiveOperation_008 |receive with a `from` clause (any component) |Clause 22.2.2 |m |n
+|32 |Sem_220202_ReceiveOperation_009 |redirect assignment of message fields |Clause 22.2.2 |m |y
+|33 |Sem_220202_ReceiveOperation_010 |redirect assignment of message fields |Clause 22.2.2 |m |y
+|34 |Sem_220202_ReceiveOperation_011 |`@decoded` redirect assignment of a bitstring field |Clause 22.2.2 |m |y
+|35 |Sem_220202_ReceiveOperation_012 |`@decoded` redirect assignment of a hexstring field |Clause 22.2.2 |m |y
+|36 |Sem_220202_ReceiveOperation_013 |`@decoded` redirect assignment of an octetstring field |Clause 22.2.2 |m |y
+|37 |Sem_220202_ReceiveOperation_014 |`@decoded` redirect assignment of a charstring field |Clause 22.2.2 |m |y
+|38 |Sem_220202_ReceiveOperation_015 |`@decoded` redirect assignment of a universal charstring field |Clause 22.2.2 |m |y
+|39 |Sem_220202_ReceiveOperation_016 |`@decoded` redirect assignment with `encoding` parameter |Clause 22.2.2 |m |n
+|40 |Sem_220202_ReceiveOperation_017 |redirect assignment storing a component |Clause 22.2.2 |m |y
+|41 |Sem_220202_ReceiveOperation_018 |redirect assignment storing an address |Clause 22.2.2 |m |n
+|42 |Sem_220202_ReceiveOperation_019 |any from `port.receive` statement |Clause 22.2.2 |m |y
+|43 |Sem_220202_ReceiveOperation_020 |single dimensional index redirect in any from `port.receive` statement |Clause 22.2.2 |m |y
+|44 |Sem_220202_ReceiveOperation_021 |multidimensional index redirect in any from `port.receive` statement |Clause 22.2.2 |m |y
+|45 |Sem_220202_ReceiveOperation_022 |standalone receive as a shorthand for `alt` statement |Clause 22.2.2 |m |y
+|46 |Sem_220202_ReceiveOperation_023 |single dimensional index redirect in any from `port.receive` statement |Clause 22.2.2 |m |n
+|47 |Sem_220202_ReceiveOperation_024 |lazy variable in value redirect |Clause 22.2.2 |m |y
+|48 |Sem_220202_ReceiveOperation_025 |lazy variable in sender redirect |Clause 22.2.2 |m |n
+|49 |Sem_220202_ReceiveOperation_026 |lazy variable in index redirect |Clause 22.2.2 |m |y
+|50 |Sem_220202_ReceiveOperation_027 |fuzzy variable in value redirect |Clause 22.2.2 |m |y
+|51 |Sem_220202_ReceiveOperation_028 |fuzzy variable in sender redirect |Clause 22.2.2 |m |n
+|52 |Sem_220202_ReceiveOperation_029 |fuzzy variable in `@index` redirect |Clause 22.2.2 |m |y
+|53 |Sem_220202_ReceiveOperation_030 |verify that a variable of a different but compatible type can be used in a redirect assignment |Clause 22.2.2 |m |y
+|========================================================================================================================================================
+
+== The `trigger` operation
+
+.The `trigger` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220203_TriggerOperation_001 |The IUT correctly handles message `trigger` operations |Clause 22.2.3 |m |y
+|2 |NegSem_220203_TriggerOperation_002 |no type prefix in ambiguous inline template |Clause 22.2.3 |m |y
+|3 |NegSem_220203_TriggerOperation_003 |type mismatch in redirect value assignment |Clause 22.2.3 |m |y
+|4 |NegSem_220203_TriggerOperation_004 |type mismatch in redirect assignment of message fields |Clause 22.2.3 |m |y
+|5 |NegSem_220203_TriggerOperation_005 |applying `@decoded` to a forbidden field |Clause 22.2.3 |m |y
+|6 |NegSem_220203_TriggerOperation_006 |decoding error in `@decoded` redirect assignment |Clause 22.2.3 |m |y
+|7 |NegSem_220203_TriggerOperation_007 |invalid format value in `@decoded` redirect assignment |Clause 22.2.3 |m |y
+|8 |NegSem_220203_TriggerOperation_008 |value of wrong type in `@decoded` redirect assignment |Clause 22.2.3 |m |y
+|9 |NegSem_220203_TriggerOperation_009 |`encoding` parameter of `@decoded` redirect assignment applied to incorrect type |Clause 22.2.3 |m |y
+|10 |NegSem_220203_TriggerOperation_010 |attempting to store component name in redirect assignment |Clause 22.2.3 |m |y
+|11 |NegSem_220203_TriggerOperation_011 |attempting to receive a type missing from the port list |Clause 22.2.3 |m |y
+|12 |NegSem_220203_TriggerOperation_012 |value redirect assignment in receive any message statement |Clause 22.2.3 |m |y
+|13 |NegSem_220203_TriggerOperation_013 |trying to store address with `trigger` operation on connected port |Clause 22.2.3 |m |n
+|14 |NegSem_220203_TriggerOperation_014 |type mismatch in sender redirect assignment |Clause 22.2.3 |m |y
+|15 |NegSem_220203_TriggerOperation_015 |`null` component reference in `from` clause of `trigger` operation |Clause 22.2.3 |m |y
+|16 |NegSem_220203_TriggerOperation_016 |`null` address reference in `from` clause of receive operation |Clause 22.2.3 |m |n
+|17 |NegSem_220203_TriggerOperation_017 |index redirection in standard `port.trigger` |Clause 22.2.3 |m |y
+|18 |NegSem_220203_TriggerOperation_018 |index redirection in any `port.receive` |Clause 22.2.3 |m |n
+|19 |NegSem_220203_TriggerOperation_019 |insufficient value range of variable in index redirection |Clause 22.2.3 |m |y
+|20 |NegSem_220203_TriggerOperation_020 |insufficient array dimension of variable in index redirection |Clause 22.2.3 |m |y
+|21 |NegSem_220203_TriggerOperation_021 |insufficient element value range of variable in index redirection |Clause 22.2.3 |m |y
+|22 |NegSem_220203_TriggerOperation_022 |incompatible from and sender clause |Clause 22.2.3 |m |y
+|23 |NegSem_220203_TriggerOperation_023 |incompatible `decmatch` and `@decoded` value redirect |Clause 22.2.3 |m |n
+|24 |Sem_220203_TriggerOperation_001 |The IUT correctly handles message `trigger` operations |Clause 22.2.3 |m |y
+|25 |Sem_220203_TriggerOperation_002 |The IUT correctly handles message `trigger` operations |Clause 22.2.3 |m |y
+|26 |Sem_220203_TriggerOperation_003 |The IUT correctly handles message `trigger` operations |Clause 22.2.3 |m |y
+|27 |Sem_220203_TriggerOperation_004 |The IUT correctly handles message `trigger` operations |Clause 22.2.3 |m |n
+|28 |Sem_220203_TriggerOperation_005 |The IUT correctly handles message `trigger` operations |Clause 22.2.3 |m |n
+|29 |Sem_220203_TriggerOperation_006 |trigger with a `from` clause (single item) |Clause 22.2.3 |m |y
+|30 |Sem_220203_TriggerOperation_007 |trigger with a `from` clause (multiple items) |Clause 22.2.3 |m |y
+|31 |Sem_220203_TriggerOperation_008 |trigger with a `from` clause (any component) |Clause 22.2.3 |m |n
+|32 |Sem_220203_TriggerOperation_009 |redirect assignment of message fields |Clause 22.2.3 |m |y
+|33 |Sem_220203_TriggerOperation_010 |redirect assignment of message fields |Clause 22.2.3 |m |y
+|34 |Sem_220203_TriggerOperation_011 |`@decoded` redirect assignment of a bitstring field |Clause 22.2.3 |m |y
+|35 |Sem_220203_TriggerOperation_012 |`@decoded` redirect assignment of a hexstring field |Clause 22.2.3 |m |y
+|36 |Sem_220203_TriggerOperation_013 |`@decoded` redirect assignment of an octetstring field |Clause 22.2.3 |m |y
+|37 |Sem_220203_TriggerOperation_014 |`@decoded` redirect assignment of a charstring field |Clause 22.2.3 |m |y
+|38 |Sem_220203_TriggerOperation_015 |`@decoded` redirect assignment of a universal charstring field |Clause 22.2.3 |m |y
+|39 |Sem_220203_TriggerOperation_016 |`@decoded` redirect assignment with `encoding` parameter |Clause 22.2.3 |m |n
+|40 |Sem_220203_TriggerOperation_017 |redirect assignment storing a component |Clause 22.2.3 |m |y
+|41 |Sem_220203_TriggerOperation_018 |redirect assignment storing an address |Clause 22.2.3 |m |n
+|42 |Sem_220203_TriggerOperation_019 |any from `port.trigger` statement |Clause 22.2.3 |m |y
+|43 |Sem_220203_TriggerOperation_020 |single dimensional index redirect in any from `port.trigger` statement |Clause 22.2.3 |m |y
+|44 |Sem_220203_TriggerOperation_021 |multidimensional index redirect in any from `port.trigger` statement |Clause 22.2.3 |m |y
+|45 |Sem_220203_TriggerOperation_022 |standalone trigger as a shorthand for `alt` statement |Clause 22.2.3 |m |y
+|46 |Sem_220203_TriggerOperation_023 |lazy variable in value redirect |Clause 22.2.3 |m |y
+|47 |Sem_220203_TriggerOperation_024 |lazy variable in sender redirect |Clause 22.2.3 |m |n
+|48 |Sem_220203_TriggerOperation_025 |lazy variable in index redirect |Clause 22.2.3 |m |y
+|49 |Sem_220203_TriggerOperation_026 |fuzzy variable in value redirect |Clause 22.2.3 |m |y
+|50 |Sem_220203_TriggerOperation_027 |fuzzy variable in sender redirect |Clause 22.2.3 |m |n
+|51 |Sem_220203_TriggerOperation_028 |fuzzy variable in `@index` redirect |Clause 22.2.3 |m |y
+|========================================================================================================================================
+
+== The `call` operation
+
+.The `call` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220301_CallOperation_001 |The IUT correctly handles procedure `call` operations |Clause 22.3.1 |m |y
+|2 |NegSem_220301_CallOperation_002 |The IUT correctly procedure calls |Clause 22.3.1 |m |y
+|3 |NegSem_220301_CallOperation_003 |`null` component in the `to` clause of the `call` operation |Clause 22.3.1 |m |y
+|4 |NegSem_220301_CallOperation_004 |`null` component in the multicast list of the `to` clause of the `call` operation |Clause 22.3.1 |m |y
+|5 |NegSem_220301_CallOperation_005 |incompatible template in the `to` clause of the `call` operation |Clause 22.3.1 |m |y
+|6 |NegSem_220301_CallOperation_006 |verify that non-blocking calls cannot have a response and exception handling part |Clause 22.3.1 |m |y
+|7 |NegSem_220301_CallOperation_007 |verify that signature that are not listed in the port `inout` and out list cannot be used in `call` operations |Clause 22.3.1 |m |y
+|8 |NegSem_220301_CallOperation_008 |verify that in parameters of a signature used in a `call` operation cannot contain matching symbols |Clause 22.3.1 |m |y
+|9 |NegSem_220301_CallOperation_009 |verify that in parameters of a signature used in a `call` operation cannot be omitted |Clause 22.3.1 |m |y
+|10 |NegSem_220301_CallOperation_010 |verify that `inout` parameters of a signature used in a `call` operation cannot contain matching symbols |Clause 22.3.1 |m |y
+|11 |NegSem_220301_CallOperation_011 |verify that `inout` parameters of a signature used in a `call` operation cannot be omitted |Clause 22.3.1 |m |y
+|12 |NegSem_220301_CallOperation_012 |missing `to` clause in case of one-to-many connections |Clause 22.3.1 |m |y
+|13 |NegSem_220301_CallOperation_013 |verify that type mismatch error is issued for incorrect `call` timer values |Clause 22.3.1 |m |y
+|14 |NegSem_220301_CallOperation_014 |verify that `getreply` signature mismatch in the response and exception handling causes an error |Clause 22.3.1 |m |y
+|15 |NegSem_220301_CallOperation_015 |verify that exception signature mismatch in the response and exception handling causes an error |Clause 22.3.1 |m |y
+|16 |NegSem_220301_CallOperation_016 |verify that forbidden calls cannot appear in response and exception handling part guards |Clause 22.3.1 |m |n
+|17 |NegSem_220301_CallOperation_017 |verify that forbidden functions cannot appear in response and exception handling part guards |Clause 22.3.1 |m |n
+|18 |NegSem_220301_CallOperation_018 |verify that non-blocking procedure calls cannot contain timeout values |Clause 22.3.1 |m |y
+|19 |NegSem_220301_CallOperation_019 |verify that non-blocking procedure calls cannot contain `nowait` parameter |Clause 22.3.1 |m |y
+|20 |NegSem_220301_CallOperation_020 |verify that calls cannot be used on disconnected ports |Clause 22.3.1 |m |y
+|21 |NegSyn_220301_CallOperation_001 |verify that the response and exception handling part cannot contain an `else` clause |Clause 22.3.1 |m |y
+|22 |NegSyn_220301_CallOperation_002 |verify that the response and exception handling part cannot contain an altstep |Clause 22.3.1 |m |y
+|23 |Sem_220301_CallOperation_001 |The IUT correctly handles procedure `call` operations |Clause 22.3.1 |m |y
+|24 |Sem_220301_CallOperation_002 |The IUT correctly handles procedure `call` operations |Clause 22.3.1 |m |y
+|25 |Sem_220301_CallOperation_003 |The IUT correctly handles non-blocking procedure call |Clause 22.3.1 |m |y
+|26 |Sem_220301_CallOperation_004 |The IUT correctly handles non-blocking procedure call |Clause 22.3.1 |m |y
+|27 |Sem_220301_CallOperation_005 |The IUT correctly handles multiple client calls to the same server |Clause 22.3.1 |m |n
+|28 |Sem_220301_CallOperation_006 |The IUT correctly handles broadcast/multicast procedure call |Clause 22.3.1 |m |n
+|29 |Sem_220301_CallOperation_007 |The IUT correctly handles broadcast/multicast procedure call |Clause 22.3.1 |m |n
+|30 |Sem_220301_CallOperation_008 |The IUT correctly handles blocking procedure call |Clause 22.3.1 |m |y
+|31 |Sem_220301_CallOperation_009 |Verify that defaults are not executed in response and exception handling part of a `call` operation |Clause 22.3.1 |m |y
+|32 |Sem_220301_CallOperation_010 |Blocking call with no timeout |Clause 22.3.1 |m |y
+|33 |Sem_220301_CallOperation_011 |Blocking broadcast call with response and exception handling part and subsequent `alt` |Clause 22.3.1 |m |n
+|34 |Sem_220301_CallOperation_012 |Blocking broadcast call with response and exception handling part handling all replies |Clause 22.3.1 |m |n
+|35 |Sem_220301_CallOperation_013 |Blocking multicast call with response and exception handling part and subsequent `alt` |Clause 22.3.1 |m |n
+|36 |Sem_220301_CallOperation_014 |Blocking multicast call with response and exception handling part handling all replies |Clause 22.3.1 |m |n
+|37 |Sem_220301_CallOperation_015 |Non-blocking broadcast call |Clause 22.3.1 |m |n
+|38 |Sem_220301_CallOperation_016 |Non-blocking multicast call |Clause 22.3.1 |m |n
+|39 |Sem_220301_CallOperation_017 |Non-blocking unicast call |Clause 22.3.1 |m |y
+|40 |Sem_220301_CallOperation_018 |Verify that `out` parameters of a signature used in a `call` operation can be omitted |Clause 22.3.1 |m |y
+|41 |Sem_220301_CallOperation_019 |Verify that `out` parameters of a signature used in a `call` operation can contain matching symbols |Clause 22.3.1 |m |y
+|42 |Sem_220301_CallOperation_020 |Verify that replies that are not related to the actual call are ignored in unqualified `getreply` statements |Clause 22.3.1 |m |n
+|43 |Sem_220301_CallOperation_021 |Verify that exceptions that are not related to the actual call are ignored in unqualified `catch` statements |Clause 22.3.1 |m |n
+|===================================================================================================================================================================
+
+== The `getcall` operation
+
+.The `getcall` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220302_GetcallOperation_001 |`Getcall` operations are only used on procedure based ports |Clause 22.3.2 |m |y
+|2 |NegSem_220302_GetcallOperation_002 |`Getcall` operation does not allow value assignment |Clause 22.3.2 |m |y
+|3 |NegSem_220302_GetcallOperation_003 |`Getcall` for any call does not allow param assignment |Clause 22.3.2 |m |y
+|4 |NegSem_220302_GetcallOperation_004 |Verify that error occurs when any from `getcall` is applied to single port |Clause 22.3.2 |m |y
+|5 |NegSem_220302_GetcallOperation_005 |Verify that error occurs when any from `getcall` is applied to 1D array and index target is array |Clause 22.3.2 |m |y
+|6 |NegSem_220302_GetcallOperation_006 |Verify that error occurs when any from `getcall` is applied to 1D array and index target has wrong type |Clause 22.3.2 |m |y
+|7 |NegSem_220302_GetcallOperation_007 |Verify that any from `getcall` index redirection for multi-D arrays requires arrays of correct size |Clause 22.3.2 |m |y
+|8 |NegSem_220302_GetcallOperation_008 |Verify that any from `getcall` index redirection for multi-D arrays requires arrays |Clause 22.3.2 |m |y
+|9 |NegSem_220302_GetcallOperation_009 |`null` component in the `from` clause of the `getcall` operation |Clause 22.3.2 |m |y
+|10 |NegSem_220302_GetcallOperation_010 |`null` component in the multicast list of the `from` clause of the `getcall` operation |Clause 22.3.2 |m |n
+|11 |NegSem_220302_GetcallOperation_011 |applying `@decoded` to a forbidden field |Clause 22.3.2 |m |y
+|12 |NegSem_220302_GetcallOperation_012 |decoding error in `@decoded` redirect assignment |Clause 22.3.2 |m |y
+|13 |NegSem_220302_GetcallOperation_013 |invalid format value in `@decoded` redirect assignment |Clause 22.3.2 |m |y
+|14 |NegSem_220302_GetcallOperation_014 |value of wrong type in `@decoded` redirect assignment |Clause 22.3.2 |m |y
+|15 |NegSem_220302_GetcallOperation_015 |`encoding` parameter of `@decoded` redirect assignment applied to incorrect type |Clause 22.3.2 |m |y
+|16 |NegSem_220302_GetcallOperation_016 |incompatible from and `sender` clause in `getcall` operation |Clause 22.3.2 |m |y
+|17 |NegSem_220302_GetcallOperation_017 |incompatible `decmatch` and `@decoded` value redirect |Clause 22.3.2 |m |n
+|18 |NegSem_220302_GetcallOperation_018 |incompatible template in the `from` clause of the `getcall` operation |Clause 22.3.2 |m |n
+|19 |NegSem_220302_GetcallOperation_019 |trying to store an incompatible component value in the `sender` clause of a `getcall` operation |Clause 22.3.2 |m |n
+|20 |NegSyn_220302_GetcallOperation_001 |Verify that error occurs when using index redirection in `port.getcall` operation |Clause 22.3.2 |m |y
+|21 |NegSyn_220302_GetcallOperation_002 |Verify that error occurs when using index redirection in any `port.getcall` operation |Clause 22.3.2 |m |n
+|22 |Sem_220302_GetcallOperation_001 |`Getcall` operations remove only matching procedure from the queue |Clause 22.3.2 |m |y
+|23 |Sem_220302_GetcallOperation_002 |`Getcall` operations remove the matching procedure from the queue |Clause 22.3.2 |m |y
+|24 |Sem_220302_GetcallOperation_003 |The `getcall` operation can be correctly restricted to a certain client |Clause 22.3.2 |m |y
+|25 |Sem_220302_GetcallOperation_004 |The `getcall` operation can be correctly restricted to a certain client |Clause 22.3.2 |m |y
+|26 |Sem_220302_GetcallOperation_005 |`Getcall` operations work with any port attribute |Clause 22.3.2 |m |n
+|27 |Sem_220302_GetcallOperation_006 |Verify that any from `getcall` is not triggered if there hasn't been any call |Clause 22.3.2 |m |y
+|28 |Sem_220302_GetcallOperation_007 |Verify that any from `getcall` matches if at least one port contains enqueued call |Clause 22.3.2 |m |y
+|29 |Sem_220302_GetcallOperation_008 |Verify that any from `getcall` doesn't assign index when there's no suitable match |Clause 22.3.2 |m |y
+|30 |Sem_220302_GetcallOperation_009 |Verify that any from `getcall` doesn't change index variable when no there's no suitable match |Clause 22.3.2 |m |y
+|31 |Sem_220302_GetcallOperation_010 |Verify that any from done assigns index |Clause 22.3.2 |m |y
+|32 |Sem_220302_GetcallOperation_011 |Verify that any from `getcall` index redirection works for multidimensional arrays |Clause 22.3.2 |m |y
+|33 |Sem_220302_GetcallOperation_012 |Verify any from `getcall` index redirection to lazy variable |Clause 22.3.2 |m |y
+|34 |Sem_220302_GetcallOperation_013 |Verify any from `getcall` index redirection to fuzzy variable |Clause 22.3.2 |m |y
+|35 |Sem_220302_GetcallOperation_014 |`@decoded` redirect assignment of a bitstring field |Clause 22.3.2 |m |y
+|36 |Sem_220302_GetcallOperation_015 |`@decoded` redirect assignment of a hexstring field |Clause 22.3.2 |m |y
+|37 |Sem_220302_GetcallOperation_016 |`@decoded` redirect assignment of an octetstring field |Clause 22.3.2 |m |y
+|38 |Sem_220302_GetcallOperation_017 |`@decoded` redirect assignment of a charstring field |Clause 22.3.2 |m |y
+|39 |Sem_220302_GetcallOperation_018 |`@decoded` redirect assignment of a universal charstring field |Clause 22.3.2 |m |y
+|40 |Sem_220302_GetcallOperation_019 |`@decoded` redirect assignment with `encoding` parameter |Clause 22.3.2 |m |n
+|41 |Sem_220302_GetcallOperation_020 |`getcall` with a `from` clause (single item) |Clause 22.3.2 |m |y
+|42 |Sem_220302_GetcallOperation_021 |`getcall` with a `from` clause (multiple items) |Clause 22.3.2 |m |y
+|43 |Sem_220302_GetcallOperation_022 |`getcall` with a `from` clause (any component) |Clause 22.3.2 |m |n
+|=================================================================================================================================================================
+
+== The `reply` operation
+
+.The `reply` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220303_ReplyOperation_001 |`Reply` operations are only used on procedure based ports |Clause 22.3.3 |m |y
+|2 |NegSem_220303_ReplyOperation_002 |`null` component in the `to` clause of the `reply` operation |Clause 22.3.3 |m |y
+|3 |NegSem_220303_ReplyOperation_003 |`null` component in the multicast list of the `to` clause of the `reply` operation |Clause 22.3.3 |m |n
+|4 |NegSem_220303_ReplyOperation_004 |verify that `reply` operation cannot be used on a message port |Clause 22.3.3 |m |y
+|5 |NegSem_220303_ReplyOperation_005 |verify that signature not listed in the port definition cannot be used in the `reply` operation |Clause 22.3.3 |m |y
+|6 |NegSem_220303_ReplyOperation_006 |verify that matching symbols cannot be used in `out` signature parameters in `reply` operations |Clause 22.3.3 |m |y
+|7 |NegSem_220303_ReplyOperation_007 |verify that matching symbols cannot be used in `inout` signature parameters in `reply` operations |Clause 22.3.3 |m |y
+|8 |NegSem_220303_ReplyOperation_008 |verify that error is issued for a missing `to` clause in a `reply` operation in case of one-to-many connections |Clause 22.3.3 |m |y
+|9 |NegSem_220303_ReplyOperation_009 |verify that values that are not addresses or components cannot be used in the `to` clause of the `reply` operation |Clause 22.3.3 |m |y
+|10 |NegSem_220303_ReplyOperation_010 |verify that `reply` operation on a disconnected port causes an error |Clause 22.3.3 |m |y
+|11 |Sem_220303_ReplyOperation_001 |The IUT correctly handles reply to multiple clients on the same server |Clause 22.3.3 |m |n
+|12 |Sem_220303_ReplyOperation_002 |The IUT correctly handles reply to multiple clients on the same server |Clause 22.3.3 |m |n
+|13 |Sem_220303_ReplyOperation_003 |verify that functionality of a simple `reply` operation (implicit unicast, no return value) |Clause 22.3.3 |m |y
+|14 |Sem_220303_ReplyOperation_004 |verify that functionality of a simple `reply` operation (explicit unicast, return value) |Clause 22.3.3 |m |y
+|15 |Sem_220303_ReplyOperation_005 |verify that in signature parameters of `reply` operations can contain matching symbols |Clause 22.3.3 |m |y
+|========================================================================================================================================================================
+
+== The `getreply` operation
+
+.The `getreply` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220304_getreply_operation_001 |Verify that error occurs when any from `getreply` is applied to single port |Clause 22.3.4 |m |y
+|2 |NegSem_220304_getreply_operation_002 |Verify that error occurs when any from `getreply` is applied to 1D array and index target is array |Clause 22.3.4 |m |y
+|3 |NegSem_220304_getreply_operation_003 |Verify that error occurs when any from `getreply` is applied to 1D array and index target has wrong type |Clause 22.3.4 |m |y
+|4 |NegSem_220304_getreply_operation_004 |Verify that any from `getreply` index redirection for multi-D arrays requires arrays of correct size |Clause 22.3.4 |m |y
+|5 |NegSem_220304_getreply_operation_005 |Verify that any from `getreply` index redirection for multi-D arrays requires arrays |Clause 22.3.4 |m |y
+|6 |NegSem_220304_getreply_operation_006 |`null` component in the `from` clause of the `getreply` operation |Clause 22.3.4 |m |y
+|7 |NegSem_220304_getreply_operation_007 |`null` component in the multicast list of the from clause of the `getreply` operation |Clause 22.3.4 |m |y
+|8 |NegSem_220304_getreply_operation_008 |applying `@decoded` to a forbidden parameter field |Clause 22.3.4 |m |y
+|9 |NegSem_220304_getreply_operation_009 |decoding error in `@decoded` redirect parameter assignment |Clause 22.3.4 |m |y
+|10 |NegSem_220304_getreply_operation_010 |invalid format value in `@decoded` redirect parameter assignment |Clause 22.3.4 |m |y
+|11 |NegSem_220304_getreply_operation_011 |value of wrong type in `@decoded` redirect parameter assignment |Clause 22.3.4 |m |y
+|12 |NegSem_220304_getreply_operation_012 |encoding parameter of `@decoded` redirect parameter assignment applied to incorrect type |Clause 22.3.4 |m |y
+|13 |NegSem_220304_getreply_operation_013 |incompatible `from` and `sender` clause in `getreply` operation |Clause 22.3.4 |m |y
+|14 |NegSem_220304_getreply_operation_014 |incompatible `decmatch` and `@decoded` parameter redirect |Clause 22.3.4 |m |n
+|15 |NegSem_220304_getreply_operation_015 |applying `@decoded` to a forbidden parameter field |Clause 22.3.4 |m |y
+|16 |NegSem_220304_getreply_operation_016 |decoding error in `@decoded` redirect value assignment |Clause 22.3.4 |m |y
+|17 |NegSem_220304_getreply_operation_017 |invalid format value in `@decoded` redirect value assignment |Clause 22.3.4 |m |y
+|18 |NegSem_220304_getreply_operation_018 |value of wrong type in `@decoded` redirect value assignment |Clause 22.3.4 |m |y
+|19 |NegSem_220304_getreply_operation_019 |encoding parameter of `@decoded` redirect value assignment applied to incorrect type |Clause 22.3.4 |m |y
+|20 |NegSem_220304_getreply_operation_020 |incompatible `decmatch` and `@decoded` value redirect |Clause 22.3.4 |m |n
+|21 |NegSem_220304_getreply_operation_021 |incompatible template in the `from` clause of the `getreply` operation |Clause 22.3.4 |m |y
+|22 |NegSem_220304_getreply_operation_022 |trying to store an incompatible component value in the `sender` clause of a `getreply` operation |Clause 22.3.4 |m |n
+|23 |NegSyn_220304_getreply_operation_001 |Verify that error occurs when using index redirection in `port.getreply` operation |Clause 22.3.4 |m |y
+|24 |NegSyn_220304_getreply_operation_002 |Verify that error occurs when using index redirection in any `port.getreply` operation |Clause 22.3.4 |m |n
+|25 |Sem_220304_getreply_operation_001 |Verify that any from `getreply` is not triggered if there hasn't been any reply |Clause 22.3.4 |m |y
+|26 |Sem_220304_getreply_operation_002 |Verify that any from `getreply` matches if at least one port contains enqueued reply |Clause 22.3.4 |m |y
+|27 |Sem_220304_getreply_operation_003 |Verify that any from `getreply` doesn't assign index when there's no suitable match |Clause 22.3.4 |m |y
+|28 |Sem_220304_getreply_operation_004 |Verify that any from `getreply` doesn't change index variable when no there's no suitable match |Clause 22.3.4 |m |y
+|29 |Sem_220304_getreply_operation_005 |Verify that any from done assigns index |Clause 22.3.4 |m |y
+|30 |Sem_220304_getreply_operation_006 |Verify that any from `getreply` index redirection works for multidimensional arrays |Clause 22.3.4 |m |y
+|31 |Sem_220304_getreply_operation_007 |Verify any from `getreply` index redirection to lazy variable |Clause 22.3.4 |m |y
+|32 |Sem_220304_getreply_operation_008 |Verify any from `getreply` index redirection to fuzzy variable |Clause 22.3.4 |m |y
+|33 |Sem_220304_getreply_operation_009 |`@decoded` redirect parameter assignment of a bitstring field |Clause 22.3.4 |m |y
+|34 |Sem_220304_getreply_operation_010 |`@decoded` redirect parameter assignment of a hexstring field |Clause 22.3.4 |m |y
+|35 |Sem_220304_getreply_operation_011 |`@decoded` redirect parameter assignment of an octetstring field |Clause 22.3.4 |m |y
+|36 |Sem_220304_getreply_operation_012 |`@decoded` redirect parameter assignment of a charstring field |Clause 22.3.4 |m |y
+|37 |Sem_220304_getreply_operation_013 |`@decoded` redirect parameter assignment of a universal charstring field |Clause 22.3.4 |m |y
+|38 |Sem_220304_getreply_operation_014 |`@decoded` redirect parameter assignment with encoding parameter |Clause 22.3.4 |m |n
+|39 |Sem_220304_getreply_operation_015 |`@decoded` redirect value assignment of a bitstring field |Clause 22.3.4 |m |y
+|40 |Sem_220304_getreply_operation_016 |`@decoded` redirect value assignment of a hexstring field |Clause 22.3.4 |m |y
+|41 |Sem_220304_getreply_operation_017 |`@decoded` redirect value assignment of an octetstring field |Clause 22.3.4 |m |y
+|42 |Sem_220304_getreply_operation_018 |`@decoded` redirect value assignment of a charstring field |Clause 22.3.4 |m |y
+|43 |Sem_220304_getreply_operation_019 |`@decoded` redirect value assignment of a universal charstring field |Clause 22.3.4 |m |y
+|44 |Sem_220304_getreply_operation_020 |`@decoded` redirect value assignment with encoding parameter |Clause 22.3.4 |m |n
+|45 |Sem_220304_getreply_operation_021 |`getreply` with a `from` clause (single item) |Clause 22.3.4 |m |y
+|46 |Sem_220304_getreply_operation_022 |`getreply` with a `from` clause (multiple items) |Clause 22.3.4 |m |y
+|47 |Sem_220304_getreply_operation_023 |`getreply` with a `from` clause (any component) |Clause 22.3.4 |m |n
+|====================================================================================================================================================================
+
+== The `raise` operation
+
+.The `raise` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220305_raise_operation_001 |raised exception type not in the list of available exceptions |Clause 22.3.5 |m |y
+|2 |NegSem_220305_raise_operation_002 |exception raised for a signature with no exception list |Clause 22.3.5 |m |y
+|3 |NegSem_220305_raise_operation_003 |raised exception type is ambiguous |Clause 22.3.5 |m |y
+|4 |NegSem_220305_raise_operation_004 |missing `to` clause in case of 1 to n connection |Clause 22.3.5 |m |y
+|5 |NegSem_220305_raise_operation_005 |exception on a message port |Clause 22.3.5 |m |y
+|6 |NegSem_220305_raise_operation_006 |exception procedure signature not in the port list |Clause 22.3.5 |m |y
+|7 |NegSem_220305_raise_operation_007 |value of incorrect type in the `to` clause of the `raise` operation |Clause 22.3.5 |m |y
+|8 |NegSem_220305_raise_operation_008 |`null` in the `to` clause of the `raise` operation |Clause 22.3.5 |m |y
+|9 |NegSem_220305_raise_operation_009 |`raise` operation on disconnected and unmapped ports |Clause 22.3.5 |m |y
+|10 |NegSem_220305_raise_operation_010 |exception template not conforming to template(value) restriction |Clause 22.3.5 |m |y
+|11 |Sem_220305_raise_operation_001 |simple `raise` operation |Clause 22.3.5 |m |y
+|12 |Sem_220305_raise_operation_002 |unicast `raise` operation |Clause 22.3.5 |m |y
+|13 |Sem_220305_raise_operation_003 |broadcast `raise` operation |Clause 22.3.5 |m |n
+|14 |Sem_220305_raise_operation_004 |multicast `raise` operation |Clause 22.3.5 |m |n
+|============================================================================================================================
+
+== The `catch` operation
+
+.The `catch` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_220306_catch_operation_001 |Verify that error occurs when any from catch is applied to single port |Clause 22.3.6 |m |y
+|2 |NegSem_220306_catch_operation_002 |Verify that error occurs when any from catch is applied to 1D array and index target is array |Clause 22.3.6 |m |y
+|3 |NegSem_220306_catch_operation_003 |Verify that error occurs when any from catch is applied to 1D array and index target has wrong type |Clause 22.3.6 |m |y
+|4 |NegSem_220306_catch_operation_004 |Verify that any from catch index redirection for multi-D arrays requires arrays of correct size |Clause 22.3.6 |m |y
+|5 |NegSem_220306_catch_operation_005 |Verify that any from catch index redirection for multi-D arrays requires arrays |Clause 22.3.6 |m |y
+|6 |NegSem_220306_catch_operation_006 |`null` component in the ``from`` clause of the `catch` operation |Clause 22.3.6 |m |y
+|7 |NegSem_220306_catch_operation_007 |`null` component in the multicast list of the `from` clause of the `catch` operation |Clause 22.3.6 |m |y
+|8 |NegSem_220306_catch_operation_008 |applying `@decoded` to a forbidden exception field |Clause 22.3.6 |m |y
+|9 |NegSem_220306_catch_operation_009 |decoding error in `@decoded` redirect value assignment |Clause 22.3.6 |m |y
+|10 |NegSem_220306_catch_operation_010 |invalid format value in `@decoded` redirect value assignment |Clause 22.3.6 |m |y
+|11 |NegSem_220306_catch_operation_011 |value of wrong type in `@decoded` redirect value assignment |Clause 22.3.6 |m |y
+|12 |NegSem_220306_catch_operation_012 |encoding parameter of `@decoded` redirect value assignment applied to incorrect type |Clause 22.3.6 |m |y
+|13 |NegSem_220306_catch_operation_013 |incompatible `from` and `sender` clause in `catch` operation |Clause 22.3.6 |m |y
+|14 |NegSem_220306_catch_operation_014 |incompatible `decmatch` and `@decoded` value redirect |Clause 22.3.6 |m |n
+|15 |NegSem_220306_catch_operation_015 |incompatible template in the `from` clause of the `catch` operation |Clause 22.3.6 |m |y
+|16 |NegSem_220306_catch_operation_016 |trying to store an incompatible component value in the ``sender`` clause of a `catch` operation |Clause 22.3.6 |m |n
+|17 |NegSyn_220306_catch_operation_001 |Verify that error occurs when using index redirection in `port.catch` operation |Clause 22.3.6 |m |y
+|18 |NegSyn_220306_catch_operation_002 |Verify that error occurs when using index redirection in any `port.catch` operation |Clause 22.3.6 |m |n
+|19 |NegSyn_220306_catch_operation_003 |Verify that error occurs when any from catch is applied to 1D array and index target has wrong type |Clause 22.3.6 |m |n
+|20 |Sem_220306_catch_operation_001 |Verify that any from catch is not triggered if there hasn't been any exception |Clause 22.3.6 |m |y
+|21 |Sem_220306_catch_operation_002 |Verify that any from catch matches if at least one port contains enqueued reply |Clause 22.3.6 |m |y
+|22 |Sem_220306_catch_operation_003 |Verify that any from catch doesn't assign index when there's no suitable match |Clause 22.3.6 |m |y
+|23 |Sem_220306_catch_operation_004 |Verify that any from catch doesn't change index variable when no there's no suitable match |Clause 22.3.6 |m |y
+|24 |Sem_220306_catch_operation_005 |Verify that any from done assigns index |Clause 22.3.6 |m |y
+|25 |Sem_220306_catch_operation_006 |Verify that any from catch index redirection works for multidimensional arrays |Clause 22.3.6 |m |y
+|26 |Sem_220306_catch_operation_007 |Verify any from catch index redirection to lazy variable |Clause 22.3.6 |m |y
+|27 |Sem_220306_catch_operation_008 |Verify any from catch index redirection to fuzzy variable |Clause 22.3.6 |m |y
+|28 |Sem_220306_catch_operation_009 |`@decoded` redirect value assignment of a bitstring field |Clause 22.3.6 |m |y
+|29 |Sem_220306_catch_operation_010 |`@decoded` redirect value assignment of a hexstring field |Clause 22.3.6 |m |y
+|30 |Sem_220306_catch_operation_011 |`@decoded` redirect value assignment of an octetstring field |Clause 22.3.6 |m |y
+|31 |Sem_220306_catch_operation_012 |`@decoded` redirect value assignment of a charstring field |Clause 22.3.6 |m |y
+|32 |Sem_220306_catch_operation_013 |`@decoded` redirect value assignment of a universal charstring field |Clause 22.3.6 |m |y
+|33 |Sem_220306_catch_operation_014 |`@decoded` redirect value assignment with encoding parameter |Clause 22.3.6 |m |n
+|34 |Sem_220306_catch_operation_015 |catch with a `from` clause (single item) |Clause 22.3.6 |m |y
+|35 |Sem_220306_catch_operation_016 |catch with a `from` clause (multiple items) |Clause 22.3.6 |m |y
+|36 |Sem_220306_catch_operation_017 |catch with a `from` clause (any component) |Clause 22.3.6 |m |n
+|===============================================================================================================================================================
+
+== The `check` operation
+
+.The `check` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2204_the_check_operation_001 |`null` component reference in `from` clause of `check` operation |Clause 22.4 |m |y
+|2 |NegSem_2204_the_check_operation_002 |`null` address reference in `from` clause of `check` operation |Clause 22.4 |m |n
+|3 |NegSem_2204_the_check_operation_003 |incompatible `from` and `sender` clause |Clause 22.4 |m |n
+|4 |NegSem_2204_the_check_operation_004 |incompatible value in the `from` clause |Clause 22.4 |m |n
+|5 |NegSem_2204_the_check_operation_005 |verify that a runtime error is generated if the real sender is incompatible with the variable in sender redirect assignment |Clause 22.4 |m |n
+|6 |Sem_2204_the_check_operation_001 |Verify that `port.check(receive)` works correctly inside `alt` |Clause 22.4 |m |y
+|7 |Sem_2204_the_check_operation_002 |Verify that `port.check(receive)` with assignment works correctly inside `alt` |Clause 22.4 |m |n
+|8 |Sem_2204_the_check_operation_003 |Verify that `port.check(receive)` works correctly as standalone statement |Clause 22.4 |m |y
+|9 |Sem_2204_the_check_operation_004 |Verify that `port.check(receive)` with assignment works correctly as standalone statement |Clause 22.4 |m |n
+|10 |Sem_2204_the_check_operation_005 |Verify that any `port.check(receive)` works correctly inside `alt` |Clause 22.4 |m |y
+|11 |Sem_2204_the_check_operation_006 |Verify that any `port.check(receive)` with assignment works correctly inside `alt` |Clause 22.4 |m |n
+|12 |Sem_2204_the_check_operation_007 |Verify that any `port.check(receive)` works correctly as standalone statement |Clause 22.4 |m |y
+|13 |Sem_2204_the_check_operation_008 |Verify that any `port.check(receive)` with assignment works correctly as standalone statement |Clause 22.4 |m |n
+|14 |Sem_2204_the_check_operation_009 |Verify behaviour of `port.check(receive)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|15 |Sem_2204_the_check_operation_010 |Verify behaviour of `port.check(receive)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|16 |Sem_2204_the_check_operation_011 |Verify `port.check(receive)` behaviour in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|17 |Sem_2204_the_check_operation_012 |Verify behaviour of `port.check(receive)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|18 |Sem_2204_the_check_operation_013 |Verify any `port.check(receive)` behaviour in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|19 |Sem_2204_the_check_operation_014 |Verify behaviour of any `port.check(receive)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|20 |Sem_2204_the_check_operation_015 |Verify any `port.check(receive)` behaviour in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|21 |Sem_2204_the_check_operation_016 |Verify behaviour of any `port.check(receive)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|22 |Sem_2204_the_check_operation_017 |Verify behaviour of `port.check(receive)` in case of successful match inside `alt` |Clause 22.4 |m |y
+|23 |Sem_2204_the_check_operation_018 |Verify behaviour of `port.check(receive)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |n
+|24 |Sem_2204_the_check_operation_019 |Verify behaviour of `port.check(receive)` in case of successful match in standalone statement |Clause 22.4 |m |y
+|25 |Sem_2204_the_check_operation_020 |Verify behaviour of `port.check(receive)` with assignment in case of successful match works correctly as standalone statement |Clause 22.4 |m |y
+|26 |Sem_2204_the_check_operation_021 |Verify behaviour of any `port.check(receive)` in case of successful match inside `alt` |Clause 22.4 |m |n
+|27 |Sem_2204_the_check_operation_022 |Verify behaviour of any `port.check(receive)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |n
+|28 |Sem_2204_the_check_operation_023 |Verify behaviour of any `port.check(receive)` in case of successful match in standalone statement |Clause 22.4 |m |n
+|29 |Sem_2204_the_check_operation_024 |Verify behaviour of any `port.check(receive)` with assignment in case of successful match works correctly as standalone statement |Clause 22.4 |m |n
+|30 |Sem_2204_the_check_operation_025 |Verify that `port.check(getcall)` works correctly inside `alt` |Clause 22.4 |m |y
+|31 |Sem_2204_the_check_operation_026 |Verify that `port.check(getcall)` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|32 |Sem_2204_the_check_operation_027 |Verify that `port.check(getcall)` works correctly as standalone statement |Clause 22.4 |m |y
+|33 |Sem_2204_the_check_operation_028 |Verify that `port.check(getcall)` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|34 |Sem_2204_the_check_operation_029 |Verify that any `port.check(getcall)` works correctly inside `alt` |Clause 22.4 |m |y
+|35 |Sem_2204_the_check_operation_030 |Verify that any `port.check(getcall)` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|36 |Sem_2204_the_check_operation_031 |Verify that any `port.check(getcall)` works correctly as standalone statement |Clause 22.4 |m |y
+|37 |Sem_2204_the_check_operation_032 |Verify that any `port.check(getcall)` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|38 |Sem_2204_the_check_operation_033 |Verify behaviour of `port.check(getcall)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|39 |Sem_2204_the_check_operation_034 |Verify behaviour of `port.check(getcall)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|40 |Sem_2204_the_check_operation_035 |Verify behaviour of `port.check(getcall)` in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|41 |Sem_2204_the_check_operation_036 |Verify behaviour of `port.check(getcall)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|42 |Sem_2204_the_check_operation_037 |Verify behaviour of any `port.check(getcall)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|43 |Sem_2204_the_check_operation_038 |Verify behaviour of any `port.check(getcall)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|44 |Sem_2204_the_check_operation_039 |Verify behaviour of any `port.check(getcall)` in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|45 |Sem_2204_the_check_operation_040 |Verify behaviour of any `port.check(getcall)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|46 |Sem_2204_the_check_operation_041 |Verify behaviour of `port.check(getcall)` in case of successful match inside `alt` |Clause 22.4 |m |y
+|47 |Sem_2204_the_check_operation_042 |Verify behaviour of `port.check(getcall)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |y
+|48 |Sem_2204_the_check_operation_043 |Verify behaviour of `port.check(getcall)` in case of successful match in standalone statement |Clause 22.4 |m |y
+|49 |Sem_2204_the_check_operation_044 |Verify behaviour of `port.check(getcall)` with assignment in case of successful match in standalone statement |Clause 22.4 |m |y
+|50 |Sem_2204_the_check_operation_045 |Verify behaviour of any `port.check(getcall)` in case of successful match inside `alt` |Clause 22.4 |m |n
+|51 |Sem_2204_the_check_operation_046 |Verify behaviour of any `port.check(getcall)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |n
+|52 |Sem_2204_the_check_operation_047 |Verify behaviour of any `port.check(getcall)` in case of successful match in standalone statement |Clause 22.4 |m |n
+|53 |Sem_2204_the_check_operation_048 |Verify behaviour of any `port.check(getcall)` with assignment in case of successful match in standalone statement |Clause 22.4 |m |n
+|54 |Sem_2204_the_check_operation_049 |Verify that `port.check(getreply)` works correctly inside `alt` |Clause 22.4 |m |y
+|55 |Sem_2204_the_check_operation_050 |Verify that `port.check(getreply)` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|56 |Sem_2204_the_check_operation_051 |Verify that `port.check(getreply)` works correctly as standalone statement |Clause 22.4 |m |y
+|57 |Sem_2204_the_check_operation_052 |Verify that `port.check(getreply)` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|58 |Sem_2204_the_check_operation_053 |Verify that any `port.check(getreply)` works correctly inside `alt` |Clause 22.4 |m |y
+|59 |Sem_2204_the_check_operation_054 |Verify that any `port.check(getreply)` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|60 |Sem_2204_the_check_operation_055 |Verify that any `port.check(getreply)` works correctly as standalone statement |Clause 22.4 |m |y
+|61 |Sem_2204_the_check_operation_056 |Verify that any `port.check(getreply)` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|62 |Sem_2204_the_check_operation_057 |Verify behaviour of `port.check(getreply)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|63 |Sem_2204_the_check_operation_058 |Verify behaviour of `port.check(getreply)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|64 |Sem_2204_the_check_operation_059 |Verify behaviour of `port.check(getreply)` in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|65 |Sem_2204_the_check_operation_060 |Verify behaviour of `port.check(getreply)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|66 |Sem_2204_the_check_operation_061 |Verify behaviour of any `port.check(getreply)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|67 |Sem_2204_the_check_operation_062 |Verify behaviour of any `port.check(getreply)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|68 |Sem_2204_the_check_operation_063 |Verify behaviour of any `port.check(getreply)` in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|69 |Sem_2204_the_check_operation_064 |Verify behaviour of any `port.check(getreply)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|70 |Sem_2204_the_check_operation_065 |Verify behaviour of `port.check(getreply)` in case of successful match inside `alt` |Clause 22.4 |m |y
+|71 |Sem_2204_the_check_operation_066 |Verify behaviour of `port.check(getreply)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |y
+|72 |Sem_2204_the_check_operation_067 |Verify behaviour of `port.check(getreply)` in case of successful match in standalone statement |Clause 22.4 |m |y
+|73 |Sem_2204_the_check_operation_068 |Verify behaviour of `port.check(getreply)` with assignment in case of successful match in standalone statement |Clause 22.4 |m |y
+|74 |Sem_2204_the_check_operation_069 |Verify behaviour of any `port.check(getreply)` in case of successful match inside `alt` |Clause 22.4 |m |n
+|75 |Sem_2204_the_check_operation_070 |Verify behaviour of any `port.check(getreply)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |n
+|76 |Sem_2204_the_check_operation_071 |Verify behaviour of any `port.check(getreply)` in case of successful match in standalone statement |Clause 22.4 |m |n
+|77 |Sem_2204_the_check_operation_072 |Verify behaviour of any `port.check(getreply)` with assignment in case of successful match in standalone statement |Clause 22.4 |m |n
+|78 |Sem_2204_the_check_operation_073 |Verify that `port.check(catch)` works correctly inside `alt` |Clause 22.4 |m |y
+|79 |Sem_2204_the_check_operation_074 |Verify that `port.check(catch)` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|80 |Sem_2204_the_check_operation_075 |Verify that `port.check(catch)` works correctly as standalone statement |Clause 22.4 |m |y
+|81 |Sem_2204_the_check_operation_076 |Verify that `port.check(catch)` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|82 |Sem_2204_the_check_operation_077 |Verify that any `port.check(catch)` works correctly inside `alt` |Clause 22.4 |m |y
+|83 |Sem_2204_the_check_operation_078 |Verify that any `port.check(catch)` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|84 |Sem_2204_the_check_operation_079 |Verify that any `port.check(catch)` works correctly as standalone statement |Clause 22.4 |m |y
+|85 |Sem_2204_the_check_operation_080 |Verify that any `port.check(catch)` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|86 |Sem_2204_the_check_operation_081 |Verify behaviour of `port.check(catch)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|87 |Sem_2204_the_check_operation_082 |Verify behaviour of `port.check(catch)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|88 |Sem_2204_the_check_operation_083 |Verify behaviour of `port.check(catch)` in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|89 |Sem_2204_the_check_operation_084 |Verify behaviour of `port.check(catch)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|90 |Sem_2204_the_check_operation_085 |Verify behaviour of any `port.check(catch)` in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|91 |Sem_2204_the_check_operation_086 |Verify behaviour of any `port.check(catch)` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|92 |Sem_2204_the_check_operation_087 |Verify behaviour of any `port.check(catch)` in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|93 |Sem_2204_the_check_operation_088 |Verify behaviour of any `port.check(catch)` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |n
+|94 |Sem_2204_the_check_operation_089 |Verify behaviour of `port.check(catch)` in case of successful match inside `alt` |Clause 22.4 |m |y
+|95 |Sem_2204_the_check_operation_090 |Verify behaviour of `port.check(catch)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |y
+|96 |Sem_2204_the_check_operation_091 |Verify behaviour of `port.check(catch)` in case of successful match in standalone statement |Clause 22.4 |m |y
+|97 |Sem_2204_the_check_operation_092 |Verify behaviour of `port.check(catch)` with assignment in case of successful match in standalone statement |Clause 22.4 |m |y
+|98 |Sem_2204_the_check_operation_093 |Verify behaviour of any `port.check(catch)` in case of successful match inside `alt` |Clause 22.4 |m |n
+|99 |Sem_2204_the_check_operation_094 |Verify behaviour of any `port.check(catch)` with assignment in case of successful match inside `alt` |Clause 22.4 |m |n
+|100 |Sem_2204_the_check_operation_095 |Verify behaviour of any `port.check(catch)` in case of successful match in standalone statement |Clause 22.4 |m |n
+|101 |Sem_2204_the_check_operation_096 |Verify behaviour of any `port.check(catch)` with assignment in case of successful match in standalone statement |Clause 22.4 |m |n
+|102 |Sem_2204_the_check_operation_097 |Verify that `port.check` works correctly inside `alt` |Clause 22.4 |m |y
+|103 |Sem_2204_the_check_operation_098 |Verify that `port.check` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|104 |Sem_2204_the_check_operation_099 |Verify that `port.check` works correctly as standalone statement |Clause 22.4 |m |y
+|105 |Sem_2204_the_check_operation_100 |Verify that `port.check` with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|106 |Sem_2204_the_check_operation_101 |Verify that any `port.check` works correctly inside `alt` |Clause 22.4 |m |y
+|107 |Sem_2204_the_check_operation_102 |Verify that any `port.check` with assignment works correctly inside `alt` |Clause 22.4 |m |y
+|108 |Sem_2204_the_check_operation_103 |Verify that any `port.check` works correctly as standalone statement |Clause 22.4 |m |y
+|109 |Sem_2204_the_check_operation_104 |Verify that any `port.check`(catch) with assignment works correctly as standalone statement |Clause 22.4 |m |y
+|110 |Sem_2204_the_check_operation_105 |Verify behaviour of `port.check` in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|111 |Sem_2204_the_check_operation_106 |Verify behaviour of `port.check` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|112 |Sem_2204_the_check_operation_107 |Verify behaviour of `port.check` in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|113 |Sem_2204_the_check_operation_108 |Verify behaviour of `port.check` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|114 |Sem_2204_the_check_operation_109 |Verify any `port.check` behaviour in case of unsuccessful match inside `alt` |Clause 22.4 |m |n
+|115 |Sem_2204_the_check_operation_110 |Verify behaviour of any `port.check` with assignment in case of unsuccessful match inside `alt` |Clause 22.4 |m |y
+|116 |Sem_2204_the_check_operation_111 |Verify behaviour of any `port.check` in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|117 |Sem_2204_the_check_operation_112 |Verify behaviour of any `port.check` with assignment in case of unsuccessful match in standalone statement |Clause 22.4 |m |y
+|118 |Sem_2204_the_check_operation_113 |Verify behaviour of `port.check` in case of successful match inside `alt` |Clause 22.4 |m |n
+|119 |Sem_2204_the_check_operation_114 |Verify behaviour of `port.check` with assignment in case of successful match inside `alt` |Clause 22.4 |m |y
+|120 |Sem_2204_the_check_operation_115 |Verify behaviour of `port.check` in case of successful match in standalone statement |Clause 22.4 |m |y
+|121 |Sem_2204_the_check_operation_116 |Verify behaviour of `port.check` with assignment in case of successful match in standalone statement |Clause 22.4 |m |y
+|122 |Sem_2204_the_check_operation_117 |Verify behaviour of any `port.check` in case of successful match inside `alt` |Clause 22.4 |m |y
+|123 |Sem_2204_the_check_operation_118 |Verify behaviour of any `port.check` with assignment in case of successful match inside `alt` |Clause 22.4 |m |y
+|124 |Sem_2204_the_check_operation_119 |Verify behaviour of any `port.check` in case of successful match in standalone statement |Clause 22.4 |m |y
+|125 |Sem_2204_the_check_operation_120 |Verify behaviour of any `port.check` with assignment in case of successful match in standalone statement |Clause 22.4 |m |y
+|========================================================================================================================================================================================
+
+== `Timer` operations
+
+.`Timer` operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_23_toplevel_001 |Ensure `timer` operations are not allowed outside of module control, test case, function, altstep |Clause 23 |m |y
+|2 |NegSem_23_toplevel_002 |Ensure `timer` operations are not allowed outside of module control, test case, function, altstep |Clause 23 |m |y
+|3 |NegSyn_23_toplevel_001 |Ensure `timer` operations are not allowed outside of module control, test case, function, altstep |Clause 23 |m |y
+|4 |NegSyn_23_toplevel_002 |Ensure `timer` operations are not allowed outside of module control, test case, function, altstep |Clause 23 |m |y
+|5 |Syn_23_toplevel_001 |Ensure timer allowed in module control, test case, function, altstep |Clause 23 |m |y
+|6 |Syn_23_toplevel_002 |Ensure timer allowed in module control, test case, function, altstep |Clause 23 |m |y
+|===========================================================================================================================================
+
+== The `start` timer operation
+
+.The `start` timer operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2302_timer_start_001 |Ensure infinity is not allowed |Clause 23.2 |m |y
+|2 |NegSem_2302_timer_start_002 |Ensure not_a_number is not allowed |Clause 23.2 |m |y
+|3 |NegSem_2302_timer_start_003 |Ensure negative value is not allowed |Clause 23.2 |m |y
+|4 |NegSem_2302_timer_start_004 |Ensure negative infinity is not allowed |Clause 23.2 |m |y
+|5 |NegSyn_2302_timer_start_001 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|6 |NegSyn_2302_timer_start_002 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|7 |NegSyn_2302_timer_start_003 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|8 |NegSyn_2302_timer_start_004 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|9 |NegSyn_2302_timer_start_005 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|10 |NegSyn_2302_timer_start_006 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|11 |NegSyn_2302_timer_start_007 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|12 |NegSyn_2302_timer_start_008 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|13 |NegSyn_2302_timer_start_009 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|14 |NegSyn_2302_timer_start_010 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|15 |NegSyn_2302_timer_start_011 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|16 |NegSyn_2302_timer_start_012 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|17 |NegSyn_2302_timer_start_013 |Ensure `timer start` syntax |Clause 23.2 |m |y
+|18 |Sem_2302_timer_start_001 |Ensure timer runs from zero to stated value |Clause 23.2 |m |y
+|19 |Sem_2302_timer_start_002 |Ensure timer can be restarted |Clause 23.2 |m |y
+|20 |Sem_2302_timer_start_003 |Ensure timer default value can be modified by start value |Clause 23.2 |m |y
+|21 |Sem_2302_timer_start_004 |Ensure timer with value 0.0 expires immediately |Clause 23.2 |m |y
+|==========================================================================================================
+
+== The `stop` timer operation
+
+.The `stop` timer operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_2303_timer_stop_001 |Ensure `timer stop` syntax |Clause 23.3 |m |y
+|2 |NegSyn_2303_timer_stop_002 |Ensure `timer stop` syntax |Clause 23.3 |m |y
+|3 |NegSyn_2303_timer_stop_003 |Ensure all `timer stop` syntax |Clause 23.3 |m |y
+|4 |NegSyn_2303_timer_stop_004 |Ensure all `timer stop` syntax |Clause 23.3 |m |y
+|5 |NegSyn_2303_timer_stop_005 |Ensure all `timer stop` syntax |Clause 23.3 |m |y
+|6 |NegSyn_2303_timer_stop_006 |Ensure all `timer stop` syntax |Clause 23.3 |m |y
+|7 |Sem_2303_timer_stop_002 |Ensure timer stop sets elapsed time to zero |Clause 23.3 |m |y
+|8 |Sem_2303_timer_stop_003 |Ensure timer all timer identifier |Clause 23.3 |m |y
+|9 |Sem_2303_timer_stop_004 |Ensure can be stopped after timeout |Clause 23.3 |m |y
+|10 |Syn_2303_timer_stop_006 |Ensure `timer stop` syntax |Clause 23.3 |m |y
+|11 |Syn_2303_timer_stop_007 |Ensure all `timer stop` syntax |Clause 23.3 |m |y
+|==========================================================================================
+
+== The `read` timer operation
+
+.The `read` timer operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_2304_timer_read_001 |Ensure `timer read` syntax |Clause 23.4 |m |y
+|2 |NegSyn_2304_timer_read_002 |Ensure `timer read` syntax |Clause 23.4 |m |y
+|3 |NegSyn_2304_timer_read_003 |Ensure `timer read` syntax |Clause 23.4 |m |y
+|4 |NegSyn_2304_timer_read_004 |Ensure `timer read` syntax: disallow any `timer.read` |Clause 23.4 |m |y
+|5 |NegSyn_2304_timer_read_005 |Ensure `timer read` syntax |Clause 23.4 |m |y
+|6 |Sem_2304_timer_read_001 |Ensure `timer read` result of inactive timer is zero |Clause 23.4 |m |y
+|7 |Sem_2304_timer_read_002 |Ensure `timer read` result is non-negative float |Clause 23.4 |m |y
+|8 |Sem_2304_timer_read_003 |Ensure `timer read` result is non-negative float |Clause 23.4 |m |y
+|===================================================================================================
+
+== The `running` timer operation
+
+.The `running` timer operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_2305_timer_running_001 |Ensure `timer running` syntax |Clause 23.5 |m |y
+|2 |NegSyn_2305_timer_running_002 |Ensure `timer running` syntax |Clause 23.5 |m |y
+|3 |NegSyn_2305_timer_running_003 |Ensure `timer running` syntax |Clause 23.5 |m |y
+|4 |NegSyn_2305_timer_running_004 |Ensure `timer running` syntax |Clause 23.5 |m |y
+|5 |NegSyn_2305_timer_running_005 |Ensure `timer running` syntax |Clause 23.5 |m |y
+|6 |NegSyn_2305_timer_running_006 |Ensure `timer running` syntax: disallow all `timer.running` |Clause 23.5 |m |y
+|7 |Sem_2305_timer_running_001 |Ensure timer running any timer identifier works |Clause 23.5 |m |y
+|8 |Sem_2305_timer_running_002 |Ensure `timer running` operation works |Clause 23.5 |m |y
+|9 |Sem_2305_timer_running_003 |Ensure `timer running` operation works |Clause 23.5 |m |y
+|10 |Sem_2305_timer_running_004 |Ensure `timer running` operation works |Clause 23.5 |m |y
+|11 |Sem_2305_timer_running_005 |Correct number of timers from a timer array is still running |Clause 23.5 |m |y
+|12 |Syn_2305_timer_running_001 |Ensure `timer runnig` syntax |Clause 23.5 |m |y
+|===============================================================================================================
+
+== The `timeout` operation
+
+.The `timeout` operation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_2306_timer_timeout_001 |Ensure `timer timeout` syntax |Clause 23.6 |m |y
+|2 |NegSyn_2306_timer_timeout_002 |Ensure `timer timeout` can`t be used in boolean expressions |Clause 23.6 |m |y
+|3 |NegSyn_2306_timer_timeout_003 |Ensure `timer timeout` syntax |Clause 23.6 |m |y
+|4 |NegSyn_2306_timer_timeout_004 |Ensure `timer timeout` syntax |Clause 23.6 |m |y
+|5 |NegSyn_2306_timer_timeout_005 |Ensure `timer timeout` syntax |Clause 23.6 |m |y
+|6 |NegSyn_2306_timer_timeout_006 |Ensure `timer timeout` syntax |Clause 23.6 |m |y
+|7 |NegSyn_2306_timer_timeout_007 |Ensure` timer timeout` syntax |Clause 23.6 |m |y
+|8 |Sem_2306_timer_timeout_001 |Ensure `timer timeout` operations: non-started timer does not timeout |Clause 23.6 |m |y
+|9 |Sem_2306_timer_timeout_002 |Ensure `timer timeout` operations: timed-out timer does not timeout until restarted |Clause 23.6 |m |y
+|10 |Sem_2306_timer_timeout_003 |Ensure `timer timeout` happen in order from the shortest to the longest |Clause 23.6 |m |y
+|11 |Sem_2306_timer_timeout_004 |Ensure any `timer.timeout` operation |Clause 23.6 |m |y
+|12 |Sem_2306_timer_timeout_005 |Ensure any `timer.timeout` operation for timeouts that are not in scope |Clause 23.6 |m |y
+|13 |Sem_2306_timer_timeout_006 |Ensure any `timer.timeout` operation handles timeout of any timer in the component, not only visible from a function or altstep |Clause 23.6 |m |y
+|14 |Sem_2306_timer_timeout_007 |Ensure `timer timeout` happen in order from the shortest to the longest |Clause 23.6 |m |y
+|15 |Sem_2306_timer_timeout_008 |Timeout of a timer from a timer array works correctly |Clause 23.6 |m |y
+|16 |Sem_2306_timer_timeout_009 |removing random timeout when using any `timer.timeout` |Clause 23.6 |m |y
+|================================================================================================================================================================================
+
+== Test `verdict` operations
+
+.Test `verdict` operations
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_24_toplevel_001 |Ensure `getverdict` is not allowed in constant initialization in control part |Clause 24 |m |y
+|2 |NegSem_24_toplevel_002 |Ensure `getverdict` is not allowed in parameter initialization in control part. |Clause 24 |m |y
+|3 |NegSem_24_toplevel_003 |Ensure `getverdict` is not allowed in variable definition in control part. |Clause 24 |m |y
+|4 |NegSem_24_toplevel_004 |Ensure `setverdict` is not allowed in part whithin `compound` statement. |Clause 24 |m |y
+|5 |NegSem_24_toplevel_005 |Ensure `setverdict` is not allowed in control part at the top level. |Clause 24 |m |y
+|6 |Syn_24_toplevel_001 |Ensure `setverdict` and `getverdict` are allowed in functions |Clause 24 |m |n
+|7 |Syn_24_toplevel_002 |Ensure `setverdict` and `getverdict` are allowed in test cases |Clause 24 |m |n
+|8 |Syn_24_toplevel_003 |Ensure `setverdict` and `getverdict` are allowed in altsteps |Clause 24 |m |y
+|=========================================================================================================================
+
+== The verdict mechanism
+
+.The verdict mechanism
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2401_SetverdictError |`Setverdict` can't set error `verdict` |Clause 24.1 |m |y
+|2 |Sem_2401_GlobalVerdict_001 |Ensure overwriting rules for global verdict: `pass` can overwrite `none`. |Clause 24.1 |m |y
+|3 |Sem_2401_GlobalVerdict_002 |Ensure overwriting rules for global verdict: `inconc` can overwrite `none`. |Clause 24.1 |m |y
+|4 |Sem_2401_GlobalVerdict_003 |Ensure overwriting rules for global verdict: `fail` can overwrite `none`. |Clause 24.1 |m |y
+|5 |Sem_2401_GlobalVerdict_004 |Ensure overwriting rules for global verdict: `none` can't overwrite `pass`. |Clause 24.1 |m |y
+|6 |Sem_2401_GlobalVerdict_005 |Ensure overwriting rules for global verdict: `inconc` can overwrite `pass`. |Clause 24.1 |m |y
+|7 |Sem_2401_GlobalVerdict_006 |Ensure overwriting rules for global verdict: `fail` can overwrite `pass`. |Clause 24.1 |m |y
+|8 |Sem_2401_GlobalVerdict_007 |Ensure overwriting rules for global verdict: `none` can't overwrite `inconc`. |Clause 24.1 |m |y
+|9 |Sem_2401_GlobalVerdict_008 |Ensure overwriting rules for global verdict: `pass` can't overwrite `inconc`. |Clause 24.1 |m |y
+|10 |Sem_2401_GlobalVerdict_009 |Ensure overwriting rules for global verdict: `fail` can overwrite `inconc`. |Clause 24.1 |m |y
+|11 |Sem_2401_GlobalVerdict_010 |Ensure overwriting rules for global verdict: `none` can't overwrite `fail`. |Clause 24.1 |m |y
+|12 |Sem_2401_GlobalVerdict_011 |Ensure overwriting rules for global verdict: `pass` can't overwrite `fail`. |Clause 24.1 |m |y
+|13 |Sem_2401_GlobalVerdict_012 |Ensure overwriting rules for global verdict: `inconc` can't overwrite `fail`. |Clause 24.1 |m |y
+|14 |Sem_2401_InitiallyNone_001 |Local verdicts initializes with `none` |Clause 24.1 |m |y
+|15 |Sem_2401_LocalVerdict_001 |Ensure overwriting rules for local verdict: `pass` can overwrite `none`. |Clause 24.1 |m |y
+|16 |Sem_2401_LocalVerdict_002 |Ensure overwriting rules for local verdict: `inconc` can overwrite `none`. |Clause 24.1 |m |y
+|17 |Sem_2401_LocalVerdict_003 |Ensure overwriting rules for local verdict: `fail` can overwrite `none`. |Clause 24.1 |m |y
+|18 |Sem_2401_LocalVerdict_004 |Ensure overwriting rules for local verdict: `none` can't overwrite `pass`. |Clause 24.1 |m |y
+|19 |Sem_2401_LocalVerdict_005 |Ensure overwriting rules for local verdict: `inconc` can overwrite `pass`. |Clause 24.1 |m |y
+|20 |Sem_2401_LocalVerdict_006 |Ensure overwriting rules for local verdict: `fail` can overwrite `pass`. |Clause 24.1 |m |y
+|21 |Sem_2401_LocalVerdict_007 |Ensure overwriting rules for local verdict: `none` can't overwrite `inconc`. |Clause 24.1 |m |y
+|22 |Sem_2401_LocalVerdict_008 |Ensure overwriting rules for local verdict: `pass` can't overwrite `inconc`. |Clause 24.1 |m |y
+|23 |Sem_2401_LocalVerdict_009 |Ensure overwriting rules for local verdict: `fail` can overwrite `inconc`. |Clause 24.1 |m |y
+|24 |Sem_2401_LocalVerdict_010 |Ensure overwriting rules for local verdict: `none` can't overwrite `fail`. |Clause 24.1 |m |y
+|25 |Sem_2401_LocalVerdict_011 |Ensure overwriting rules for local verdict: `pass` can't overwrite `fail`. |Clause 24.1 |m |y
+|26 |Sem_2401_LocalVerdict_012 |Ensure overwriting rules for local verdict: inconc can't overwrite `fail`. |Clause 24.1 |m |y
+|27 |Syn_2401_FiveValues_001 |There are five values of `verdicttype` |Clause 24.1 |m |y
+|============================================================================================================================
+
+== The setverdict mechanism
+
+.Test setverdict mechanism
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2402_setverdict_params_001 |Ensure `setverdict` accepts parameters of `verdicttype` only |Clause 24.2 |m |y
+|2 |NegSem_2402_setverdict_params_002 |Ensure `setverdict` accepts parameters of `verdicttype` only |Clause 24.2 |m |y
+|3 |NegSem_2402_setverdict_params_003 |Ensure `setverdict` accepts values of `verdicttype` only |Clause 24.2 |m |y
+|4 |NegSem_2402_setverdict_params_004 |Ensure `setverdict` accepts values only as the parameter |Clause 24.2 |m |y
+|5 |NegSem_2402_setverdict_params_005 |Ensure `setverdict` accepts values only as the parameter |Clause 24.2 |m |y
+|6 |Sem_2402_setverdict_logging_001 |Ensure logging constraints |Clause 24.2 |m |y
+|7 |Sem_2402_setverdict_params_001 |Ensure `setverdict` accepts values only as the parameter |Clause 24.2 |m |y
+|8 |Sem_2402_setverdict_params_002 |Ensure `setverdict` accepts values only as the parameter |Clause 24.2 |m |y
+|9 |Sem_2402_setverdict_params_003 |Ensure logging constraints |Clause 24.2 |m |n
+|=================================================================================================================
+
+== The getverdict mechanism
+
+.The getverdict mechanism
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_2403_getverdict_001 |Ensure `getverdict` returns the actual verdict `none` |Clause 24.3 |m |y
+|2 |Sem_2403_getverdict_002 |Ensure `getverdict` returns the actual verdict `inconc` |Clause 24.3 |m |y
+|3 |Sem_2403_getverdict_003 |Ensure `getverdict` returns the actual verdict `pass` |Clause 24.3 |m |y
+|4 |Sem_2403_getverdict_004 |Ensure `getverdict` returns the actual verdict `fail` |Clause 24.3 |m |y
+|5 |Sem_2403_getverdict_005 |Ensure `getverdict` `none` for uninitialized verdict |Clause 24.3 |m |y
+|==================================================================================================
+
+== Module control
+
+.Module control
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_26_ModuleControl_001 |Assignments in the control part are accepted. |Clause 26 |m |y
+|2 |Syn_26_ModuleControl_002 |`if-else` constructs in the control part are accepted. |Clause 26 |m |y
+|3 |Syn_26_ModuleControl_003 |`select-case` constructs in the control part are accepted. |Clause 26 |m |y
+|4 |Syn_26_ModuleControl_004 |`for loop` constructs in the control part are accepted. |Clause 26 |m |y
+|5 |Syn_26_ModuleControl_005 |`while loop` constructs in the control part are accepted. |Clause 26 |m |y
+|6 |Syn_26_ModuleControl_006 |`label` and `goto` constructs in the control part are accepted. |Clause 26 |m |y
+|7 |Syn_26_ModuleControl_007 |The `stop` construct in the control part is accepted. |Clause 26 |m |y
+|8 |Syn_26_ModuleControl_008 |The `break` construct in the control part is accepted. |Clause 26 |m |y
+|9 |Syn_26_ModuleControl_009 |The `continue` construct in the control part is accepted. |Clause 26 |m |y
+|10 |Syn_26_ModuleControl_010 |The `continue` construct in the control part is accepted. |Clause 26 |m |y
+|11 |Syn_26_ModuleControl_011 |The `alt/timeout` construct in the control part is accepted. |Clause 26 |m |y
+|12 |Syn_26_ModuleControl_012 |The `repeat` construct in the control part is accepted. |Clause 26 |m |y
+|13 |Syn_26_ModuleControl_013 |The `interleave` construct in the control part is accepted. |Clause 26 |m |y
+|14 |Syn_26_ModuleControl_015 |`start`/`stop`/`read`/`running` timer constructs in the control part are accepted. |Clause 26 |m |y
+|15 |Syn_26_ModuleControl_016 |The `action` construct in the control part is accepted. |Clause 26 |m |y
+|16 |Syn_26_ModuleControl_017 |The `execute` construct in the control part is accepted. |Clause 26 |m |y
+|=========================================================================================================================
+
+== The `execute` statement
+
+.The `execute` statement
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2601_ExecuteStatement_001 |Non-float `timeout` parameters in the `execute` statement are rejected (in this case int). |Clause 26.1 |m |y
+|2 |NegSem_2601_ExecuteStatement_002 |Non-float `timeout` parameters in the `execute` statement are rejected (in this case charstring). |Clause 26.1 |m |y
+|3 |NegSem_2601_ExecuteStatement_003 |Host id can be only charstring. |Clause 26.1 |m |n
+|4 |NegSem_2601_ExecuteStatement_004 |Execution rejects test case execution with infinity timer guard |Clause 26.1 |m |y
+|5 |Sem_2601_ExecuteStatement_001 |Parameters are passed correctly into the test case. |Clause 26.1 |m |y
+|6 |Sem_2601_ExecuteStatement_002 |Multiple parameters of different types are passed correctly into the test case. |Clause 26.1 |m |y
+|7 |Sem_2601_ExecuteStatement_003 |The timeout specified with the `execute` statement is respected. |Clause 26.1 |m |y
+|8 |Sem_2601_ExecuteStatement_004 |The verdict `none` works correctly. |Clause 26.1 |m |y
+|9 |Sem_2601_ExecuteStatement_005 |The verdict `pass` works correctly. |Clause 26.1 |m |y
+|10 |Sem_2601_ExecuteStatement_006 |The verdict `inconc` works correctly. |Clause 26.1 |m |y
+|11 |Sem_2601_ExecuteStatement_007 |The timeout specified with the `execute` statement is respected. |Clause 26.1 |m |n
+|12 |Sem_2601_ExecuteStatement_008 |The user error sets the verdict error correctly. |Clause 26.1 |m |y
+|13 |Sem_2601_ExecuteStatement_009 |Host id restriction is correctly handled. |Clause 26.1 |m |n
+|14 |Sem_2601_ExecuteStatement_010 |verify that test cases can be executed from altsteps called from the control block |Clause 26.1 |m |y
+|=====================================================================================================================================================
+
+== The control part
+
+.The control part
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2602_TheControlPart_001 |`setverdict` statements are not allowed in the control part. |Clause 26.2 |m |y
+|2 |NegSem_2602_TheControlPart_002 |The `create` component is not allowed in the control part. |Clause 26.2 |m |y
+|3 |NegSem_2602_TheControlPart_003 |The `create alive` component is not allowed in the control part. |Clause 26.2 |m |y
+|4 |NegSem_2602_TheControlPart_004 |The `start` statement is not allowed in the control part. |Clause 26.2 |m |y
+|5 |NegSem_2602_TheControlPart_005 |The `stop` statement is not allowed in the control part. |Clause 26.2 |m |y
+|6 |NegSem_2602_TheControlPart_006 |The `kill` statement is not allowed in the control part. |Clause 26.2 |m |y
+|7 |NegSem_2602_TheControlPart_007 |The `alive` operation is not allowed in the control part. |Clause 26.2 |m |y
+|8 |NegSem_2602_TheControlPart_008 |The `running` operation is not allowed in the control part. |Clause 26.2 |m |y
+|9 |NegSem_2602_TheControlPart_009 |The `done` operation is not allowed in the control part. |Clause 26.2 |m |y
+|10 |NegSem_2602_TheControlPart_010 |The `killed` operation is not allowed in the control part. |Clause 26.2 |m |y
+|11 |NegSem_2602_TheControlPart_011 |The `connect` statements are not allowed in the control part. |Clause 26.2 |m |y
+|12 |NegSem_2602_TheControlPart_012 |The `disconnect` statements are not allowed in the control part. |Clause 26.2 |m |y
+|13 |NegSem_2602_TheControlPart_013 |The `map` statements are not allowed in the control part. |Clause 26.2 |m |y
+|14 |NegSem_2602_TheControlPart_014 |The `unmap` statements are not allowed in the control part. |Clause 26.2 |m |y
+|15 |NegSem_2602_TheControlPart_015 |The `send` statements are not allowed in the control part. |Clause 26.2 |m |y
+|16 |NegSem_2602_TheControlPart_016 |The `receive` statements are not allowed in the control part. |Clause 26.2 |m |y
+|17 |NegSem_2602_TheControlPart_017 |The `call` statements are not allowed in the control part. |Clause 26.2 |m |y
+|18 |NegSem_2602_TheControlPart_018 |The `reply` statements are not allowed in the control part. |Clause 26.2 |m |y
+|19 |NegSem_2602_TheControlPart_019 |The `raise` statements are not allowed in the control part. |Clause 26.2 |m |y
+|20 |NegSem_2602_TheControlPart_020 |The `trigger` statements are not allowed in the control part. |Clause 26.2 |m |y
+|21 |NegSem_2602_TheControlPart_021 |The `getcall` statements are not allowed in the control part. |Clause 26.2 |m |y
+|22 |NegSem_2602_TheControlPart_022 |The `getreply` statements are not allowed in the control part. |Clause 26.2 |m |y
+|23 |NegSem_2602_TheControlPart_023 |The `catch` statements are not allowed in the control part. |Clause 26.2 |m |y
+|24 |NegSem_2602_TheControlPart_024 |The `check` statements are not allowed in the control part. |Clause 26.2 |m |y
+|25 |NegSem_2602_TheControlPart_025 |The `clear` statements are not allowed in the control part. |Clause 26.2 |m |y
+|26 |NegSem_2602_TheControlPart_026 |The `start` statements on ports are not allowed in the control part. |Clause 26.2 |m |y
+|27 |NegSem_2602_TheControlPart_027 |The `stop` statements on ports are not allowed in the control part. |Clause 26.2 |m |y
+|28 |NegSem_2602_TheControlPart_028 |The `halt` statements are not allowed in the control part. |Clause 26.2 |m |y
+|29 |NegSem_2602_TheControlPart_029 |Alternative behaviours are only used to control timer behaviour in the control part. |Clause 26.2 |m |y
+|30 |NegSem_2602_TheControlPart_030 |`Getverdict` statements are not allowed in the control part. |Clause 26.2 |m |y
+|31 |NegSem_2602_TheControlPart_031 |`Execute` statements are not executed from test cases. |Clause 26.1 |m |y
+|32 |NegSem_2602_TheControlPart_032 |The `create alive` named component is not allowed in the control part. |Clause 26.2 |m |y
+|33 |NegSem_2602_TheControlPart_033 |The `create` named component is not allowed in the control part. |Clause 26.2 |m |y
+|34 |NegSem_2602_TheControlPart_034 |The `create` named component on host is not allowed in the control part. |Clause 26.2 |m |y
+|35 |NegSem_2602_TheControlPart_035 |Alternative behaviours are only used to control timer behaviour in the control part. |Clause 26.2 |m |y
+|36 |Sem_2602_TheControlPart_001 |The selection/deselection of test cases using boolean conditions works as expected. |Clause 26.2 |m |y
+|37 |Sem_2602_TheControlPart_002 |The execution of test cases works from within a function. |Clause 26.2 |m |y
+|38 |Sem_2602_TheControlPart_003 |The selection of test cases can be achieved based on resulting verdict types. |Clause 26.2 |m |y
+|==========================================================================================================================================
+
+== Scope of attributes
+
+.Scope of attributes
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Syn_270101_ScopeOfAttributes_001 |Attributes for language elements are accepted. |Clause 27.1.1 |m |y
+|2 |Syn_270101_ScopeOfAttributes_002 |Attributes for language elements are accepted. |Clause 27.1.1 |m |y
+|3 |Syn_270101_ScopeOfAttributes_003 |Attributes for individual fields are accepted. |Clause 27.1.1 |m |y
+|4 |Syn_270101_ScopeOfAttributes_004 |Attributes for individual fields are accepted. |Clause 27.1.1 |m |y
+|========================================================================================================
+
+== Optional attributes
+
+.Optional attributes
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_2707_OptionalAttributes_001 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |n
+|2 |NegSem_2707_OptionalAttributes_002 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |n
+|3 |NegSem_2707_OptionalAttributes_003 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |n
+|4 |Sem_2707_OptionalAttributes_001 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|5 |Sem_2707_OptionalAttributes_002 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|6 |Sem_2707_OptionalAttributes_003 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|7 |Sem_2707_OptionalAttributes_004 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|8 |Sem_2707_OptionalAttributes_005 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|9 |Sem_2707_OptionalAttributes_006 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|10 |Sem_2707_OptionalAttributes_007 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|11 |Sem_2707_OptionalAttributes_008 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |n
+|12 |Syn_2707_OptionalAttributes_001 |The IUT correctly handles attribute definitions and their scoping rules |Clause 27.7 |m |y
+|=================================================================================================================================
+
+== Matching specific values
+
+.Matching specific values
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B0101_matching_specific_value_001 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|2 |Sem_B0101_matching_specific_value_002 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|3 |Sem_B0101_matching_specific_value_003 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|4 |Sem_B0101_matching_specific_value_004 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|5 |Sem_B0101_matching_specific_value_005 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|6 |Sem_B0101_matching_specific_value_006 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|7 |Sem_B0101_matching_specific_value_007 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|8 |Sem_B0101_matching_specific_value_008 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|9 |Sem_B0101_matching_specific_value_009 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|10 |Sem_B0101_matching_specific_value_010 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|11 |Sem_B0101_matching_specific_value_011 |The IUT correctly handles template matching of specific values |Clause B.1.1 |m |y
+|12 |NegSem_B010101_omitting_values_001 |Ensure that the IUT correctly handles template matching of omitted values |Clause B.1.1 |m |y
+|13 |Sem_B010101_omitting_values_001 |Ensure that the IUT correctly handles template matching of omitted values |Clause B.1.1 |m |y
+|14 |Sem_B010101_omitting_values_002 |Ensure that the IUT correctly handles template matching of omitted values |Clause B.1.1 |m |y
+|=====================================================================================================================================
+
+== Value list
+
+.Value list
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=============================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010201_value_list_001 |The IUT correctly handles template matching of listed multiple values |Clause B.1.2.1 |m |y
+|3 |NegSem_B010201_value_list_002 |The IUT correctly handles template matching of listed multiple values |Clause B.1.2.1 |m |y
+|4 |NegSem_B010201_value_list_003 |The IUT correctly handles template matching of listed multiple values |Clause B.1.2.1 |m |y
+|5 |NegSem_B010201_value_list_004 |The IUT correctly handles template list corretly |Clause B.1.2.1 |m |y
+|6 |Sem_B010201_value_list_001 |The IUT correctly handles template matching of listed multiple values |Clause B.1.2.1 |m |y
+|7 |Sem_B010201_value_list_002 |The IUT correctly handles template matching with all `from` clause |Clause B.1.2.1 |m |y
+|8 |Sem_B010201_value_list_003 |The IUT correctly handles template matching of listed multiple values |Clause B.1.2.1 |m |y
+|9 |Sem_B010201_value_list_004 |The IUT correctly handles template list corretly |Clause B.1.2.1 |m |y
+|=============================================================================================================================
+
+== Complemented value list
+
+.Complemented value list
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010202_complemented_value_list_001 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |n
+|2 |NegSem_B010202_complemented_value_list_002 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|3 |NegSem_B010202_complemented_value_list_003 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|4 |NegSem_B010202_complemented_value_list_004 |The IUT correctly handles template matching of complemented value omit |Clause B.1.2.2 |m |n
+|5 |Sem_B010202_complemented_value_list_001 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|6 |Sem_B010202_complemented_value_list_002 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|7 |Sem_B010202_complemented_value_list_003 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|8 |Sem_B010202_complemented_value_list_004 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|9 |Sem_B010202_complemented_value_list_005 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|10 |Sem_B010202_complemented_value_list_006 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|11 |Sem_B010202_complemented_value_list_007 |The IUT correctly handles template matching of complemented value listing |Clause B.1.2.2 |m |y
+|12 |Sem_B010202_complemented_value_list_008 |The IUT correctly handles template matching of complemented value omit |Clause B.1.2.2 |m |y
+|==============================================================================================================================================
+
+== Any value
+
+.Any value
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010203_any_value_001 |The IUT correctly handles template matching of ? values |Clause B.1.2.3 |m |y
+|2 |Sem_B010203_any_value_002 |The IUT correctly handles template matching of ? values |Clause B.1.2.3 |m |y
+|===========================================================================================================
+
+== Any value or none
+
+.Any value or none
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010204_any_value_or_none_001 |The IUT correctly handles template matching of * values |Clause B.1.2.4 |m |y
+|2 |NegSem_B010204_any_value_or_none_002 |The IUT correctly handles template matching of * values |Clause B.1.2.4 |m |y
+|3 |Sem_B010204_any_value_or_none_001 |The IUT correctly handles template matching of * values |Clause B.1.2.4 |m |y
+|4 |Sem_B010204_any_value_or_none_002 |AnyValueOrNone can be assigned to top-level template |Clause B.1.2.4 |m |y
+|5 |Sem_B010204_any_value_or_none_003 |AnyValueOrNone can be used for matching optional fields |Clause B.1.2.4 |m |y
+|6 |Sem_B010204_any_value_or_none_004 |AnyValueOrNone cannot be used for matching non-optional value |Clause B.1.2.4 |m |y
+|7 |Sem_B010204_any_value_or_none_005 |AnyValueOrNone cannot be used for matching compulsory fields |Clause B.1.2.4 |m |y
+|=========================================================================================================================
+
+== Value range
+
+.Value range
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010205_value_range_001 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|2 |NegSem_B010205_value_range_002 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|3 |NegSem_B010205_value_range_003 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|4 |Sem_B010205_value_range_001 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|5 |Sem_B010205_value_range_002 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|6 |Sem_B010205_value_range_003 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|7 |Sem_B010205_value_range_004 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|8 |Sem_B010205_value_range_005 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|9 |Sem_B010205_value_range_006 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|10 |Sem_B010205_value_range_007 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|11 |Sem_B010205_value_range_008 |The IUT correctly handles template matching of value range definitions |Clause B.1.2.5 |m |y
+|===============================================================================================================================
+
+== SuperSet
+
+.SuperSet
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010206_superset_001 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|2 |NegSem_B010206_superset_002 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|3 |NegSem_B010206_superset_003 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |n
+|4 |NegSem_B010206_superset_004 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|5 |NegSem_B010206_superset_005 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|6 |NegSem_B010206_superset_006 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|7 |NegSem_B010206_superset_007 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|8 |NegSem_B010206_superset_008 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|9 |Sem_B010206_superset_001 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|10 |Sem_B010206_superset_002 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|11 |Sem_B010206_superset_003 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|12 |Sem_B010206_superset_004 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|13 |Sem_B010206_superset_005 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|14 |Sem_B010206_superset_006 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|15 |Sem_B010206_superset_007 |The IUT correctly handles template matching of superset definitions |Clause B.1.2.6 |m |y
+|16 |Sem_B010206_superset_008 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|17 |Sem_B010206_superset_009 |The IUT correctly handles template matching of superset definition |Clause B.1.2.6 |m |y
+|=========================================================================================================================
+
+== SubSet
+
+.SubSet
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=====================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010207_subset_001 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|2 |NegSem_B010207_subset_002 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|3 |NegSem_B010207_subset_003 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |n
+|4 |NegSem_B010207_subset_004 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|5 |NegSem_B010207_subset_005 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|6 |NegSem_B010207_subset_006 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|7 |NegSem_B010207_subset_007 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|8 |NegSem_B010207_subset_008 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|9 |Sem_B010207_subset_001 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|10 |Sem_B010207_subset_002 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|11 |Sem_B010207_subset_003 |The IUT correctly handles template matching of subset definitions |Clause B.1.2.7 |m |y
+|12 |Sem_B010207_subset_004 |The IUT correctly handles template matching of subset definition |Clause B.1.2.7 |m |y
+|13 |Sem_B010207_subset_005 |The IUT correctly handles template matching of subset definition |Clause B.1.2.7 |m |y
+|14 |Sem_B010207_subset_006 |The IUT correctly handles template matching of subset definition |Clause B.1.2.7 |m |y
+|15 |Sem_B010207_subset_007 |The IUT correctly handles template matching of subset definition |Clause B.1.2.7 |m |y
+|16 |Sem_B010207_subset_008 |The IUT correctly handles template matching of subset definition |Clause B.1.2.7 |m |y
+|=====================================================================================================================
+
+== Omitting optional fields
+
+.Omitting optional fields
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010208_omit_value_001 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |y
+|2 |NegSem_B010208_omit_value_002 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |y
+|3 |NegSem_B010208_omit_value_003 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |n
+|4 |Sem_B010208_omit_value_001 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |y
+|5 |Sem_B010208_omit_value_002 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |y
+|6 |Sem_B010208_omit_value_003 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |y
+|7 |Sem_B010208_omit_value_004 |The IUT correctly handles template matching of omit values |Clause B.1.2.8 |m |y
+|==================================================================================================================
+
+== Decoded content
+
+.Any element
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010209_decoded_content_001 |The IUT correctly handles content decoding |Clause B.1.2.9 |m |y
+|2 |Sem_B010209_decoded_content_002 |The IUT correctly handles content decoding |Clause B.1.2.9 |m |y
+|3 |Sem_B010209_decoded_content_003 |The IUT correctly handles content decoding |Clause B.1.2.9 |m |y
+|4 |Sem_B010209_decoded_content_004 |The IUT correctly handles content decoding |Clause B.1.2.9 |m |y
+|5 |Sem_B010209_decoded_content_005 |The IUT correctly handles content decoding |Clause B.1.2.9 |m |y
+|====================================================================================================
+
+== Enumerated value list
+
+.Enumerated value list
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010210_enumerated_value_list_001 |The IUT correctly handles enum matching |Clause B.1.2.10 |m |n
+|========================================================================================================
+
+== Any element
+
+.Any element
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010301_any_element_001 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|2 |Sem_B010301_any_element_002 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|3 |Sem_B010301_any_element_003 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|4 |Sem_B010301_any_element_004 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|5 |Sem_B010301_any_element_005 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|6 |Sem_B010301_any_element_006 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|7 |Sem_B010301_any_element_007 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|8 |Sem_B010301_any_element_008 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.1 |m |y
+|================================================================================================================================
+
+== Any number of elements of no element
+
+.Any number of elements of no element
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010302_any_number_of_elements_or_none_001 |The IUT correctly handles template matching of * symbols in value elements |Clause B.1.3.2 |m |y
+|2 |Sem_B010302_any_number_of_elements_or_none_002 |The IUT correctly handles template matching of * symbols in value elements |Clause B.1.3.2 |m |y
+|3 |Sem_B010302_any_number_of_elements_or_none_003 |The IUT correctly handles template matching of * symbols in value elements |Clause B.1.3.2 |m |y
+|===================================================================================================================================================
+
+== Permutation
+
+.Permutation
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010303_permutation_001 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.3 |m |y
+|2 |NegSem_B010303_permutation_002 |All from operand can be a record of or set of only |Clause B.1.3.3 |m |y
+|3 |NegSem_B010303_permutation_003 |Type restriction for permutation elements is applied |Clause B.1.3.3 |m |y
+|4 |NegSem_B010303_permutation_004 |Type restriction for all `from` clause in permutation is applied |Clause B.1.3.3 |m |n
+|5 |NegSem_B010303_permutation_005 |Verify restriction on individual members of all from operand in permutation |Clause B.1.3.3 |m |y
+|6 |NegSem_B010303_permutation_006 |Verify restriction on individual members of all from operand in permutation |Clause B.1.3.3 |m |y
+|7 |Sem_B010303_permutation_001 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.3 |m |y
+|8 |Sem_B010303_permutation_002 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.3 |m |y
+|9 |Sem_B010303_permutation_003 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.3 |m |y
+|10 |Sem_B010303_permutation_004 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.3 |m |y
+|11 |Sem_B010303_permutation_005 |The IUT correctly handles template matching of ? symbols in value elements |Clause B.1.3.3 |m |y
+|12 |Sem_B010303_permutation_006 |The IUT correctly handles permutation within arrays |Clause B.1.3.3 |m |y
+|13 |Sem_B010303_permutation_007 |All `from` clause can be used inside permutation |Clause B.1.3.3 |m |y
+|14 |Sem_B010303_permutation_008 |All `from` clause operand can be a set of value |Clause B.1.3.3 |m |y
+|15 |Sem_B010303_permutation_009 |All `from` clause operand can be a set of value |Clause B.1.3.3 |m |y
+|====================================================================================================================================
+
+== Length restrictions
+
+.Length restrictions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010401_length_restrictions_001 |The IUT correctly handles template matching of value length definitions |Clause B.1.4.1 |m |y
+|2 |NegSem_B010401_length_restrictions_002 |The IUT correctly handles template matching of value length definitions |Clause B.1.4.1 |m |y
+|3 |Sem_B010401_length_restrictions_001 |The IUT correctly handles template matching of value length definitions |Clause B.1.4.1 |m |y
+|4 |Sem_B010401_length_restrictions_002 |The IUT correctly handles template matching of value length definitions |Clause B.1.4.1 |m |y
+|5 |Sem_B010401_length_restrictions_003 |The IUT correctly handles template matching of value length definitions |Clause B.1.4.1 |m |y
+|6 |Sem_B010401_length_restrictions_004 |The IUT correctly handles template matching of value length definitions |Clause B.1.4.1 |m |y
+|========================================================================================================================================
+
+== The `ifpresent` indicator
+
+.The `ifpresent` indicator
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|====================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010402_ifPresent_indicator_001 |The IUT correctly handles template matching of `ifpresent` indicators |Clause B.1.4.2 |m |y
+|2 |Sem_B010402_ifPresent_indicator_001 |The IUT correctly handles template matching of `ifpresent` indicators |Clause B.1.4.2 |m |y
+|3 |Sem_B010402_ifPresent_indicator_002 |The IUT correctly handles template matching of `ifpresent` indicators |Clause B.1.4.2 |m |y
+|====================================================================================================================================
+
+== Matching character pattern
+
+.Matching character pattern
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=========================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B0105_toplevel_001 |The IUT correctly handles template matching of character pattern definitions |Clause B.1.5 |m |y
+|2 |Sem_B0105_toplevel_002 |The IUT correctly handles template quadruple and USI-like syntax matching of character pattern definitions |Clause B.1.5 |m |y
+|=========================================================================================================================================================
+
+== Set expression
+
+.Set expression
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|============================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010501_set_expression_001 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|2 |Sem_B010501_set_expression_001 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|3 |Sem_B010501_set_expression_002 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|4 |Sem_B010501_set_expression_003 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|5 |Sem_B010501_set_expression_004 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|6 |Sem_B010501_set_expression_005 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|7 |Sem_B010501_set_expression_006 |The IUT correctly handles template matching of character pattern set expressions |Clause B.1.5.1 |m |y
+|============================================================================================================================================
+
+== Reference expression
+
+.Reference expression
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010502_reference_expression_001 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|2 |Sem_B010502_reference_expression_002 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|3 |Sem_B010502_reference_expression_003 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|4 |Sem_B010502_reference_expression_004 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|5 |Sem_B010502_reference_expression_005 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|6 |Sem_B010502_reference_expression_006 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|7 |Sem_B010502_reference_expression_007 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|8 |Sem_B010502_reference_expression_008 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|9 |Sem_B010502_reference_expression_009 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|10 |Sem_B010502_reference_expression_010 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |n
+|11 |Sem_B010502_reference_expression_011 |The IUT correctly handles template matching of character pattern reference expressions |Clause B.1.5.2 |m |y
+|======================================================================================================================================================
+
+== Match expression n times
+
+.Match expression n times
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010503_match_n_times_001 |The IUT correctly handles template matching of character pattern expression multiplicity |Clause B.1.5.3 |m |y
+|2 |Sem_B010503_match_n_times_002 |The IUT correctly handles template matching of character pattern expression multiplicity |Clause B.1.5.3 |m |y
+|3 |Sem_B010503_match_n_times_003 |The IUT correctly handles template matching of character pattern expression multiplicity |Clause B.1.5.3 |m |y
+|4 |Sem_B010503_match_n_times_004 |The IUT correctly handles template matching of character pattern expression multiplicity |Clause B.1.5.3 |m |y
+|5 |Sem_B010503_match_n_times_005 |The IUT correctly handles template matching of character pattern expression multiplicity |Clause B.1.5.3 |m |y
+|================================================================================================================================================
+
+== Match a referenced character set
+
+.Match a referenced character set
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|==============================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSem_B010504_match_referenced_characters_001 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|2 |Sem_B010504_match_referenced_characters_001 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|3 |Sem_B010504_match_referenced_characters_002 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|4 |Sem_B010504_match_referenced_characters_003 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|5 |Sem_B010504_match_referenced_characters_004 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |
+|6 |Sem_B010504_match_referenced_characters_005 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|7 |Sem_B010504_match_referenced_characters_006 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|8 |Sem_B010504_match_referenced_characters_007 |The IUT correctly handles template matching of character pattern reference characters |Clause B.1.5.4 |m |y
+|==============================================================================================================================================================
+
+== Type compatibility rules for patterns
+
+.Type compatibility rules for patterns
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|======================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |NegSyn_B010505_pattern_compatibility_001 |The IUT correctly handles character pattern metacharacters compatibility rules of template matching |Clause B.1.5.5 |m |y
+|2 |Sem_B010505_pattern_compatibility_001 |The IUT correctly handles character pattern compatibility rules of template matching |Clause B.1.5.5 |m |y
+|3 |Sem_B010505_pattern_compatibility_002 |The IUT correctly handles character pattern compatibility rules of template matching |Clause B.1.5.5 |m |n
+|======================================================================================================================================================================
+
+== Case insensitive pattern matching
+
+.Case insensitive pattern matching
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|=======================================================================================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_B010506_case_sensitive_pattern_matching_001 |The IUT correctly handles character pattern compatibility rules of template case sensitive matching (`@nocase`) |Clause B.1.5.6 |m |y
+|2 |Sem_B010506_case_sensitive_pattern_matching_002 |The IUT correctly handles character pattern compatibility rules of template case sensitive matching (`@nocase`) |Clause B.1.5.6 |m |y
+|=======================================================================================================================================================================================
+
+== Other functions
+
+.Other functions
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|===============================================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_C0602_The_hostid_function_001 |Ensure that the IUT correctly handles the hostid function |Clause C.6.3 |m |y
+|2 |Sem_C0602_The_testcasename_function_001 |Ensure that the IUT correctly handles the testcasename function |Clause C.6.2 |m |y
+|===============================================================================================================================
+
+== Preprocessing macros
+
+.Preprocessing macros
+
+[width="99%",cols="20%,16%,28%,16%,10%,10%",options="header",]
+|========================================================================================================
+|Item |TC/TP reference |purpose |Reference in ES 201 873-1 |Status |Support
+|1 |Sem_D01_macro_module_001 |*MODULE* replaces the module name |Clause D |m |y
+|2 |Sem_D02_macro_file_001 |*FILE* macro stores the path and file name in a charstring |Clause D |m |y
+|3 |Sem_D03_macro_bfile_001 |The *BFILE* macro replaces the actual file name |Clause D |m |y
+|4 |Sem_D04_macro_line_001 |*LINE* macro stores the actual line number when it is called |Clause D |m |y
+|5 |NegSem_D05_macro_scope_001 |*SCOPE* replaces the actual higher named basic scope unit |Clause D |m |y
+|6 |Sem_D05_macro_scope_001 |*SCOPE* replaces the actual higher basic unit |Clause D |m |y
+|7 |Sem_D05_macro_scope_002 |*SCOPE* replaces the actual higher basic unit |Clause D |m |y
+|========================================================================================================
diff --git a/usrguide/SoC_TITAN/images/titan_logo.png b/usrguide/SoC_TITAN/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..502c9ebdba29a8120952c1e20ea2db44c8232cd5
Binary files /dev/null and b/usrguide/SoC_TITAN/images/titan_logo.png differ
diff --git a/usrguide/SoC_XML_TITAN.docx b/usrguide/SoC_XML_TITAN.docx
deleted file mode 100644
index 6656c7aeda5353bdbe8367d3fbf7d7723d839c46..0000000000000000000000000000000000000000
Binary files a/usrguide/SoC_XML_TITAN.docx and /dev/null differ
diff --git a/usrguide/SoC_XML_TITAN/SoC_XML_TITAN.adoc b/usrguide/SoC_XML_TITAN/SoC_XML_TITAN.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..28cbaa6574850a80ef2ef890761deb64ccb79886
--- /dev/null
+++ b/usrguide/SoC_XML_TITAN/SoC_XML_TITAN.adoc
@@ -0,0 +1,1365 @@
+---
+Author: Adrien Kirjak
+Version: 2/174 02- CRL 113 200/6, Rev. PE1
+Date: 2018-06-18
+
+---
+= Statement of Compliance for use of XML Schema in Eclipse Titan
+:author: Adrien Kirjak
+:revnumber: 2/174 02- CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-18
+:title-logo-image: images/titan_logo.png
+:toc:
+
+ifdef::env-github,backend-html5[]
+image::images/titan_logo.png[alt]
+endif::[]
+
+*Abstract*
+
+The present document provides the Implementation Conformance Statement (ICS) proforma for the conformance test suite for the Eclipse Titan TTCN-3 implementation.
+
+*Copyright*
+
+Copyright (c) 2000-2018 Ericsson Telecom AB +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution, and is available at +
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
+
+*Disclaimer*
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
+
+= Description
+
+The present document provides the Implementation Conformance Statement (ICS) proforma for the conformance test suite for using XML Schema with TTCN-3 as defined in  link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.09.01_60/es_20187301v040901p.pdf[ETSI ES 201 873-1]. In the present document only XML related features, specified in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 873 9] have been considered but not the core language features (see link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.09.01_60/es_20187301v040901p.pdf[ETSI ES 201 873-1]), nor tool implementation (see link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187305/04.08.01_60/es_20187305v040801p.pdf[ETSI ES 201 873-5] and link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.06.01_60/es_20187307v040601p.pdf[ETSI ES 201 873-6]), language mapping (see link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.06.01_60/es_20187307v040601p.pdf[ETSI ES 201 873-7] and link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187308/04.05.01_60/es_20187308v040501p.pdf[ETSI ES 201 873-8]) and language extension (see e.g. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.05.01_60/es_202781v010501p.pdf[ETSI ES 202 781], link:https://www.etsi.org/deliver/etsi_es/202700_202799/202784/01.06.01_60/es_202784v010601p.pdf[ETSI ES 202 784] and  link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.02.01_60/es_202785v010201p.pdf[ETSI ES 202 785]) aspects.
+
+= References
+
+== Normative references
+
+The following referenced documents are necessary for the application of the present document.
+
+1. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 873-9 (V4.6.1): "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3".]
+
+2. [[_2]]ISO/IEC 9646-7 (1994): "Conformance testing methodology and framework – Part 7: Implementation Conformance Statement".
+
+
+3. [[_3]]ISO/IEC 9646-1 (1992): "Information Technology – Open Systems Interconnection – Conformance Testing Methodology and Framework – Part 1: General concepts".
+
+4. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.02.01_60/es_202785v010201p.pdf[ETSI ES 202 785: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Behaviour Types".]
+
+== Informative references
+
+The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
+
+[start=5]
+5. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.09.01_60/es_20187301v040901p.pdf[ETSI ES 201 873-1: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language".]
+
+6. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187305/04.08.01_60/es_20187305v040801p.pdf[ETSI ES 201 873-5: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)".]
+
+7. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187306/04.09.01_60/es_20187306v040901p.pdf[ETSI ES 201 873-6: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI").]
+
+8. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.06.01_60/es_20187307v040601p.pdf[ETSI ES 201 873-7: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 7: Using ASN.1 with TTCN-3".]
+
+9. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187308/04.05.01_60/es_20187308v040501p.pdf[ETSI ES 201 873-8: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 8: The IDL to TTCN-3 Mapping".]
+
+10. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.05.01_60/es_202781v010501p.pdf[ETSI ES 202 781: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support".]
+
+11. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202784/01.06.01_60/es_202784v010601p.pdf[ETSI ES 202 784: "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Advanced Parameterization".]
+
+= Definitions and abbreviations
+
+== Definitions
+
+*Abstract Test Suite (ATS):* +
+Test suite composed of abstract test cases
+
+*Implementation Conformance Statement (ICS):* +
+Statement made by the supplier of an implementation claimed to conform to a given specification, stating which capabilities have been implemented
+
+*ICS proforma:* +
+Document, in the form of a questionnaire, which when completed for an implementation or system becomes an ICS
+
+*Implementation eXtra Information for Testing (IXIT):* +
+Statement made by a supplier or implementor of an IUT which contains or references all of the information related to the IUT and its testing environment, which will enable the test laboratory to run an appropriate test suite against the IUT
+
+*IXIT proforma:* +
+Document, in the form of a questionnaire, which when completed for the IUT becomes the IXIT
+
+*Implementation Under Test (IUT):* +
+Implementation of one or more OSI protocols in an adjacent user/provider relationship, being part of a real open system which is to be studied by testing
+
+== Abbreviations
+
+ASCI:: American Standard Code for Information Interchange
+
+ATS:: Abstract Test Suite
+
+BNF:: Backus Naur Form
+
+ICS:: Implementation Conformance Statement
+
+IUT:: Implementation under Test
+
+IXIT:: Implementation eXtra Information for Testing
+
+SUT:: System Under Test
+
+TC:: Test Case
+
+TCI:: TTCN-3 Control Interface
+
+TP:: Test Purpose
+
+TRI:: TTCN-3 Runtime Interface
+
+TS:: Test System
+
+TSS:: Test Suite Structure
+
+TSS&TP:: Test Suite Structure and Test Purposes
+
+TTCN:: Testing and Test Control Notation
+
+TTCN-3:: Testing and Test Control Notation edition 3
+
+URI:: Uniform Resource Identifier
+
+URL:: Uniform Resource Locator
+
+XML:: eXtensible Markup Language
+
+XSD:: W3C XML Schema Definition
+
+= Instructions for completing the ICS proforma
+
+== Other information
+
+More detailed instructions are given at the beginning of the different clauses of the ICS proforma.
+
+The supplier of the implementation shall complete the ICS proforma in each of the spaces provided. If necessary, the supplier may provide additional comments separately in Clause A.4.
+
+=== Purposes and structure
+
+The purpose of this ICS proforma is to provide a mechanism whereby a TTCN-3 tool vendor of the link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[TTCN-3 core language] may provide information about the implementation in a standardized manner.
+
+The ICS proforma is subdivided into clauses for the following categories of information:
+
+* instructions for completing the ICS proforma;
+* identification of the implementation;
+* ICS proforma tables (containing the global statement of conformance).
+
+=== Conventions
+The ICS proforma is composed of information in tabular form in accordance with the guidelines presented in <<_2,ISO/IEC 96467>> .
+
+Item column::
+
+It contains a number that identifies the item in the table.
+
+Item description column::
+
+It describes each respective item (e.g. parameters, timers, etc.).
+
+Reference column::
+
+It gives reference to the link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[TTCN-3 core language], except where explicitly stated otherwise.
+
+Status column::
+
+The following notations, defined in <<_2,ISO/IEC 96467>>, are used for the status column:
+
+* m mandatory - the capability is required to be supported.
+
+* n/a not applicable - in the given context, it is impossible to use the capability. No answer in the support column is required.
+
+* u undecided
+
+* o optional - the capability may be supported or not.
+
+* o.i qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which identifies a unique group of related optional items and the logic of their selection which is defined immediately following the table.
+
+* ci conditional - the requirement on the capability ("m", "o" or "n/a") depends on the support of other optional or conditional items. "i" is an integer identifying a unique conditional status expression that is defined immediately following the table. For nested conditional expressions, the syntax `IF … THEN (IF … THEN … ELSE…) ELSE …` shall be used to avoid ambiguities. If an ELSE clause is omitted, `ELSE n/a` shall be implied.
+
+NOTE: Support of a capability means that the capability is implemented in conformance to the link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[TTCN-3 core language].
+
+Support column::
+
+The support column shall be filled in by the supplier of the implementation. The following common notations, defined in <<_2,ISO/IEC 96467>>, are used for the support column:
+
+* Y or y supported by the implementation.
+
+* N or n not supported by the implementation.
+
+* N/A or n/a or "no answer required" (allowed only if the status is N/A, directly or after evaluation of a conditional status).
+
+Values allowed column::
+
+This column contains the values or the ranges of values allowed.
+
+Values supported column::
+
+The support column shall be filled in by the supplier of the implementation. In this column the values or the ranges of values supported by the implementation shall be indicated.
+
+References to items::
+
+For each possible item answer (answer in the support column) within the ICS proforma, a unique reference exists. It is defined as the table identifier, followed by a slash character "/", followed by the item number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters (a, b, etc.) respectively.
+
+EXAMPLE: 5/4 is the reference to the answer of item 4 in Table 5.
+
+== Identification of the implementation
+
+Identification of the Implementation under Test (IUT) and the system in which it resides - the System Under Test (SUT) should be filled in so as to provide as much detail as possible regarding version numbers and configuration options.
+
+The product supplier information and client information should both be filled in if they are different.
+
+A person who can answer queries regarding information supplied in the ICS should be named as the contact person.
+
+=== Date of the statement
+
+[cols=",",options="header",]
+|==================================
+|Date of the statement: |2016.07.19
+|==================================
+
+=== Implementation under Test (IUT) identification
+
+[cols=",",options="header",]
+|===============================
+|IUT name: |Eclipse Titan
+|IUT version: |CRL 113 200/5 R5B
+|===============================
+
+=== ICS contact person
+
+[cols=",",options="header",]
+|==========================================
+|Name: |Elemer Lelik
+|Telephone number: |
+|Facsimile number: |
+|E-mail address: |Elemer.Lelik@ericsson.com
+|Additional information: |
+|==========================================
+
+= ICS proforma tables
+
+== Global statement of conformance
+
+[cols="70%,30%",options="header",]
+|=============================================
+| |(Yes/No)
+|Are all mandatory capabilities implemented? |
+|=============================================
+
+== Mapping XML Schemas
+
+.Mapping XML Schemas
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=====================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_05_top_level_001 |Verify that error is generated for missing XSD language tag in import clause |Clause 5 |m |n
+|=====================================================================================================================
+
+== Namespaces
+
+.Namespaces
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=====================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_050101_namespaces_001 |Verify that schema with target namespace is correctly translated into single module |Clause 5.1.1 |m |y
+|2 |Pos_050101_namespaces_002 |Verify schema with no target namespace is correctly translated into single module |Clause 5.1.1 |m |y
+|3 |Pos_050101_namespaces_003 |Verify that two schemas with the same target namespace are correctly translated |Clause 5.1.1 |m |y
+|4 |Pos_050101_namespaces_004 |Verify that two schemas with no target namespace are correctly translated |Clause 5.1.1 |m |y
+|=====================================================================================================================================
+
+== Includes
+
+.Includes
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_050102_includes_001 |Test inclusion of a schema with the same namespace |Clause 5.1.2 |m |y
+|2 |Pos_050102_includes_002 |Verify that included schema with no target namespace is transformed twice (inclusion) |Clause 5.1.2 |m |y
+|3 |Pos_050102_includes_003 |Verify that included schema with no target namespace is transformed twice (no namespace) |Clause 5.1.2 |m |y
+|========================================================================================================================================
+
+== Imports
+
+.Imports
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===============================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_050103_imports_001 |Verify that it is not allowed to import imports from XSD schemas |Clause 5.1.3 |m |y
+|2 |Pos_050103_imports_001 |Verify that XSD import statement is handled correctly |Clause 5.1.3 |m |y
+|===============================================================================================================
+
+== Attributes of the XSD schema element
+
+.Attributes of the XSD schema element
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_050104_attributes_of_the_xsd_schema_element_001 |Verify that qualified default element form is correctly processed (no namespace prefix) |Clause 5.1.4 |m |y
+|2 |Pos_050104_attributes_of_the_xsd_schema_element_002 |Verify that qualified default element form is correctly processed (namespace prefix used) |Clause 5.1.4 |m |y
+|3 |Pos_050104_attributes_of_the_xsd_schema_element_003 |Verify that unqualified default element form is correctly processed |Clause 5.1.4 |m |y
+|4 |Pos_050104_attributes_of_the_xsd_schema_element_004 |Verify that qualified default attribute form is correctly processed (no namespace prefix) |Clause 5.1.4 |m |y
+|5 |Pos_050104_attributes_of_the_xsd_schema_element_005 |Verify that qualified default attribute form is correctly processed (namespace prefix used) |Clause 5.1.4 |m |y
+|6 |Pos_050104_attributes_of_the_xsd_schema_element_006 |Verify that unqualified default attribute form is correctly processed |Clause 5.1.4 |m |y
+|=======================================================================================================================================================================
+
+== Name conversion rules
+
+.Name conversion rules
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_050202_name_conversion_rules_001 |Verify conversion of symbols into U+005f (low line) |Clause 5.2.2 |m |y
+|2 |Pos_050202_name_conversion_rules_002 |Verify that non-ASCI letters are not present in transforming identifiers |Clause 5.2.2 |m |y
+|3 |Pos_050202_name_conversion_rules_003 |Verify that multiple "_" are simplified in transforming identifiers |Clause 5.2.2 |m |y
+|4 |Pos_050202_name_conversion_rules_004 |Verify that leading and trailing low lines are removed |Clause 5.2.2 |m |y
+|5 |Pos_050202_name_conversion_rules_005 |Verify that type names are capitalized |Clause 5.2.2 |m |y
+|6 |Pos_050202_name_conversion_rules_006 |Verify that prefixing type names with "X" works correctly |Clause 5.2.2 |m |y
+|7 |Pos_050202_name_conversion_rules_007 |Verify that names of field of structure types are uncapitalized |Clause 5.2.2 |m |y
+|8 |Pos_050202_name_conversion_rules_008 |Verify that names of enumerated items are uncapitalized |Clause 5.2.2 |m |y
+|9 |Pos_050202_name_conversion_rules_009 |Verify that prefixing field names of structured types with "x" works correctly |Clause 5.2.2 |m |y
+|10 |Pos_050202_name_conversion_rules_010 |Verify that prefixing enumerated items with "x" works correctly |Clause 5.2.2 |m |y
+|11 |Pos_050202_name_conversion_rules_011 |Check transformation of empty type identifier into "X" |Clause 5.2.2 |m |y
+|12 |Pos_050202_name_conversion_rules_012 |Check transformation of empty structured field identifier into "x" |Clause 5.2.2 |m |y
+|13 |Pos_050202_name_conversion_rules_013 |Check transformation of empty enumerated value into "x" |Clause 5.2.2 |m |y
+|14 |Pos_050202_name_conversion_rules_014 |Verify that additional suffices are attached in case of name clashes between types |Clause 5.2.2 |m |y
+|15 |Pos_050202_name_conversion_rules_015 |Verify that suffix is attached in case of name clash between types and local module |Clause 5.2.2 |m |y
+|16 |Pos_050202_name_conversion_rules_016 |Verify that suffix is attached in case of name clash between types and imported module |Clause 5.2.2 |m |y
+|17 |Pos_050202_name_conversion_rules_017 |Verify that suffix is attached in case of name clash between field names |Clause 5.2.2 |m |y
+|18 |Pos_050202_name_conversion_rules_018 |Verify that suffix is attached in case of name clash between field name and keyword |Clause 5.2.2 |m |y
+|19 |Pos_050202_name_conversion_rules_019 |Verify that suffix is attached in case of name clash between field name and predefined function |Clause 5.2.2 |m |y
+|20 |Pos_050202_name_conversion_rules_020 |Verify that suffix is attached in case of name clash between enumerated items |Clause 5.2.2 |m |y
+|21 |Pos_050202_name_conversion_rules_021 |Verify that suffix is attached in case of name clash between enumerated item and keyword |Clause 5.2.2 |m |y
+|22 |Pos_050202_name_conversion_rules_022 |Verify that suffix is attached in case of name clash between enumerated item and predefined function |Clause 5.2.2 |m |y
+|23 |Pos_050202_name_conversion_rules_023 |Verify that name clash between module names is resolved using suffix |Clause 5.2.2 |m |y
+|==================================================================================================================================================================
+
+== Order of the mapping
+
+.Order of the mapping
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_050203_order_of_the_mapping_001 |Verify order of top-level schema components |Clause 5.2.3 |m |y
+|2 |Pos_050203_order_of_the_mapping_002 |Verify that alphabetical sorting is based on character ordinal numbers |Clause 5.2.3 |m |y
+|3 |Pos_050203_order_of_the_mapping_003 |Verify that alphabetical sorting is done only inside sets of items |Clause 5.2.3 |m |y
+|4 |Pos_050203_order_of_the_mapping_004 |Assure that namespaces are ordered lexically |Clause 5.2.3 |m |y
+|5 |Pos_050203_order_of_the_mapping_005 |Assure that namespaces are ordered lexically |Clause 5.2.3 |m |y
+|==================================================================================================================================
+
+== Built-in data types
+
+.Built-in data types
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_06_top_level_001 |Verify conversion of simpleType based on built-in XSD type |Clause 6 |m |y
+|===================================================================================================
+
+== Length
+
+.Length
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|========================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060101_length_001 |Verify that a length-restricted XSD type shall be mapped to a corresponding length restricted TTCN-3 type. |Clause 6.1.1 |m |y
+|2 |Pos_060101_length_001 |Verify that a length-restricted XSD type shall be mapped to a corresponding length restricted TTCN-3 type. |Clause 6.1.1 |m |y
+|3 |Pos_060101_length_002 |Verify that a length-restricted XSD type shall be mapped to a corresponding length restricted TTCN-3 type. |Clause 6.1.1 |m |y
+|========================================================================================================================================================
+
+== Enumeration
+
+.Enumeration
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060105_enumeration_001 |Verify if tool rejects validation in case of restricted value due xsd type declaration. |Clause 6.1.5 |m |y
+|2 |Neg_060105_enumeration_002 |Verify if tool rejects validation in case of restricted enumerated value length due xsd type declaration. |Clause 6.1.5 |m |y
+|3 |Neg_060105_enumeration_003 |Verify if tool rejects validation in case of restricted value due xsd type declaration. |Clause 6.1.5 |m |y
+|4 |Neg_060105_enumeration_004 |Disallow enumeration values removed by restriction |Clause 6.1.5 |m |y
+|5 |Pos_060105_enumeration_001 |Verify mapping of simple type definition that is a restriction of string type with an enumeration facet |Clause 6.1.5 |m |y
+|6 |Pos_060105_enumeration_002 |Verify mapping of simple type definition that is a restriction of integer type with an enumeration facet |Clause 6.1.5 |m |y
+|7 |Pos_060105_enumeration_003 |Verify mapping of simple type definition that is a restriction of integer type with a minInclusive and a maxInclusive facet |Clause 6.1.5 |m |y
+|8 |Pos_060105_enumeration_004 |Verify mapping of simple type definition that is a restriction of another simple type of definition, derived by restriction from integer type with the addition of a minInclusive and a maxInclusive facet |Clause 6.1.5 |m |y
+|9 |Pos_060105_enumeration_005 |Verify mapping of simple type definition that is a restriction of another type definition, derived by restriction from string with the addition of an enumeration facet |Clause 6.1.5 |m |y
+|10 |Pos_060105_enumeration_006 |Verify mapping of simple type definition that is a restriction of another simple type definition, derived by restriction from string with the addition of an enumeration facet |Clause 6.1.5 |m |y
+|=============================================================================================================================================================================================================================================================
+
+== MinInclusive
+
+.MinInclusive
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060107_mininclusive_001 |Verify mapping of an integer element with a minInclusive facet |Clause 6.1.7 |m |y
+|2 |Pos_060107_mininclusive_002 |Verify mapping of a float element with a numeric minInclusive value |Clause 6.1.7 |m |y
+|3 |Pos_060107_mininclusive_003 |Verify mapping of a float element with special minInclusive values |Clause 6.1.7 |m |y
+|4 |Pos_060107_mininclusive_004 |Verify mapping of a float element with special minInclusive values |Clause 6.1.7 |m |y
+|5 |Pos_060107_mininclusive_005 |Verify mapping of a float element with special minInclusive values |Clause 6.1.7 |m |y
+|=======================================================================================================================
+
+== MaxInclusive
+
+.MaxInclusive
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|======================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060108_maxinclusive_001 |Verify mapping of elements of type integer with maxInclusive facet |Clause 6.1.8 |m |y
+|2 |Pos_060108_maxinclusive_002 |Verify mapping of a float type with a numeric maxInclusive facet |Clause 6.1.8 |m |y
+|3 |Pos_060108_maxinclusive_003 |Verify mapping of a float type with a numeric maxInclusive facet |Clause 6.1.8 |m |y
+|4 |Pos_060108_maxinclusive_004 |Verify mapping of a float type with a numeric maxInclusive facet |Clause 6.1.8 |m |y
+|======================================================================================================================
+
+== MinExclusive
+
+.MinExclusive
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060109_minexclusive_001 |Verify if tool rejects validation in case of restricted value due xsd type declaration. |Clause 6.1.9 |m |y
+|2 |Neg_060109_minexclusive_002 |Verify if tool rejects validation in case of restricted value due xsd type declaration. |Clause 6.1.9 |m |y
+|3 |Pos_060109_minexclusive_001 |Verify if tool accepts values restricted by xsd type declaration. |Clause 6.1.9 |m |y
+|4 |Pos_060109_minexclusive_002 |Verify if tool accepts values restricted by xsd type declaration. |Clause 6.1.9 |m |y
+|===========================================================================================================================================
+
+== MaxExclusive
+
+.MaxExclusive
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060110_maxexclusive_001 |Verify that INF (negative infinity) or NaN (not-a-number), this type shall not be translated to TTCN-3 |Clause 6.1.10 |m |y
+|2 |Pos_060110_maxexclusive_001 |Verify mapping of a maxExclusive facet applied to a type, which is derivative of integer |Clause 6.1.10 |m |y
+|3 |Pos_060110_maxexclusive_002 |Verify mapping of a maxExclusive facet applied to the float type |Clause 6.1.10 |m |y
+|4 |Pos_060110_maxexclusive_003 |Verify mapping of a maxExclusive facet applied to the float type |Clause 6.1.10 |m |y
+|===========================================================================================================================================================
+
+== Total digits
+
+.Total digits
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060111_total_digits_001 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|2 |Neg_060111_total_digits_002 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|3 |Neg_060111_total_digits_003 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|4 |Neg_060111_total_digits_004 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|5 |Pos_060111_total_digits_001 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|6 |Pos_060111_total_digits_002 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|7 |Pos_060111_total_digits_003 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|8 |Pos_060111_total_digits_004 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|9 |Pos_060111_total_digits_005 |Check that totalDigits are converted to value boundaries |Clause 6.1.11 |m |y
+|=============================================================================================================
+
+== Fraction digits
+
+.Fraction digits
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060112_fraction_digits_001 |Check that floats having same accuracy as fractionDigits are converted correctly |Clause 6.1.12 |m |y
+|2 |Pos_060112_fraction_digits_002 |Check that floats having higher accuracy than fractionDigits are converted correctly |Clause 6.1.12 |m |y
+|============================================================================================================================================
+
+== Not specifically mapped facets
+
+.Not specifically mapped facets
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==========================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060113_not_mapped_001 |Handle not mapped facets to transparent |Clause 6.1.13 |m |n
+|==========================================================================================
+
+== String
+
+.String
+
+[width="100%",cols="25%,10%,60%,15%,5%,5%",options="header",]
+|===================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060201_string_001 |Verify mapping of a string type |Clause 6.2.1 |m |y
+|===================================================================================
+
+== Name
+
+.Name
+
+[cols=",,,,,",options="header",]
+|==================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060204_name_001 |Verify mapping of a Name type |Clause 6.2.4 |m |y
+|==================================================================================
+
+== Any URI
+
+.Any URI
+
+[cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060212_any_uri_001 |Verify mapping of an anyURI type |Clause 6.2.12 |m |y
+|2 |Neg_060212_any_uri_002 |Verify mapping of an anyURI type |Clause 6.2.12 |m |y
+|3 |Pos_060212_any_uri_001 |Verify mapping of an anyURI type |Clause 6.2.12 |m |y
+|==================================================================================
+
+== Integer
+
+.Integer
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|============================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060301_integer_001 |Verify that the integer type shall be translated to TTCN-3 as a plain integer |Clause 6.3.1 |m |y
+|============================================================================================================================
+
+== Positive integer
+
+.Positive integer
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060302_positive_integer_001 |Verify that the integer type shall be translated to TTCN-3 as the range-restricted integer |Clause 6.3.2 |m |y
+|==================================================================================================================================================
+
+== Non-positive integer
+
+.Non-positive integer
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060303_non_positive_integer_001 |Verify that the non positive integer type shall be translated to TTCN-3 as the range-restricted integer |Clause 6.3.3 |m |y
+|===================================================================================================================================================================
+
+== Negative integer
+
+.Negative integer
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060304_negative_integer_001 |Verify that the negative integer type shall be translated to TTCN-3 as the range-restricted integer |Clause 6.3.4 |m |y
+|===========================================================================================================================================================
+
+== Non-negative integer
+
+.Non-negative integer
+
+[width="99%",cols="20%,16%,16%,16%,16%,16%",options="header",]
+|===================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060305_non_negative_integer_001 |Verify that the non negative integer type shall be translated to TTCN-3 as the range-restricted integer |Clause 6.3.5 |m |y
+|===================================================================================================================================================================
+
+== Long
+
+.Long
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060306_long_001 |Verify that long type (64bit) shall be translated to TTCN-3 as a plain long |Clause 6.3.6 |m |y
+|=======================================================================================================================
+
+== Unsigned long
+
+.Unsigned long
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060307_unsigned_long_001 |Verify that unsigned long type (64bit) shall be translated to TTCN-3 as a plain unsigned long |Clause 6.3.7 |m |y
+|==================================================================================================================================================
+
+== Int
+
+.Int
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==========================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060308_int_001 |Verify that int type (32 bit) shall be translated to TTCN-3 as a plain long as defined in clause 6.3.8 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.3.8 |m |y
+|==========================================================================================================================================================================
+
+== Unsigned int
+
+.Unsigned int
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=====================================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060309_unsigned_int_001 |Verify that unsigned int type (32 bit) shall be translated to TTCN-3 as a plain unsigned long as defined in clause 6.3.9 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.3.9 |m |y
+|=====================================================================================================================================================================================================
+
+== Short
+
+.Short
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060310_short_001 |Verify that short type (16 bit) shall be translated to TTCN-3 as a plain short as defined in clause 6.3.10 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.3.10 |m |y
+|=================================================================================================================================================================================
+
+== Unsigned Short
+
+.Unsigned Short
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|============================================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060311_unsigned_short_001 |Verify that unsigned short type (16 bit) shall be translated to TTCN-3 as a plain unsigned short as defined in clause 6.3.11 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.3.11 |m |y
+|============================================================================================================================================================================================================
+
+== Byte
+
+.Byte
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060312_byte_001 |Verify that byte type (8 bit) shall be translated to TTCN-3 as a plain byte as defined in clause 6.3.12 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.3.12 |m |y
+|=============================================================================================================================================================================
+
+== Unsigned byte
+
+.Unsigned byte
+
+[width="100%",cols="25%,10%,60%,15%,5%,5%",options="header",]
+|========================================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060313_unsigned_byte_001 |Verify that unsigned byte type (8 bit) shall be translated to TTCN-3 as a plain unsigned byte as defined in clause 6.3.13 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.3.13 |m |y
+|========================================================================================================================================================================================================
+
+== Decimal
+
+.Decimal
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|======================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060401_decimal_001 |Verify that decimal type shall be translated to TTCN-3 as a plain float |Clause 6.4.1 |m |y
+|======================================================================================================================
+
+== Float
+
+.Float
+
+[cols=",,,,,",options="header",]
+|==================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060402_float_001 |Verify conversion of XSD float type |Clause 6.4.2 |m |y
+|==================================================================================
+
+== Double
+
+.Double
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_060403_double_001 |Verify that double type shall be translated to TTCN-3 as an IEEE754double as defined in clause 6.4.3 of ETSI ES 201 873 9 link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 9: Using XML schema with TTCN-3] |Clause 6.4.3 |m |y
+|===========================================================================================================================================================================
+
+== Date and time
+
+.Date and time
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|========================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060502_date_and_time_001 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|2 |Neg_060502_date_and_time_002 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|3 |Neg_060502_date_and_time_003 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|4 |Neg_060502_date_and_time_004 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|5 |Pos_060502_date_and_time_001 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|6 |Pos_060502_date_and_time_002 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|7 |Pos_060502_date_and_time_003 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|8 |Pos_060502_date_and_time_004 |Verify that the dateTime type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.2 |m |y
+|========================================================================================================================================================
+
+== Date
+
+.Date
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060504_date_001 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|2 |Neg_060504_date_002 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|3 |Neg_060504_date_003 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|4 |Neg_060504_date_004 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|5 |Pos_060504_date_001 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|6 |Pos_060504_date_002 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|7 |Pos_060504_date_003 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|8 |Pos_060504_date_004 |Verify that the date type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.4 |m |y
+|===========================================================================================================================================
+
+== Gregorian year and month
+
+.Gregorian year and month
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=====================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060505_gregorian_year_and_month_001 |Verify that the gYearMonth type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.5 |m |y
+|2 |Neg_060505_gregorian_year_and_month_002 |Verify that the gYearMonth type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.5 |m |y
+|3 |Neg_060505_gregorian_year_and_month_003 |Verify that the gYearMonth type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.5 |m |y
+|4 |Neg_060505_gregorian_year_and_month_004 |Verify that the gYearMonth type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.5 |m |y
+|5 |Pos_060505_gregorian_year_and_month_001 |Verify that the gYearMonth type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.5 |m |y
+|6 |Pos_060505_gregorian_year_and_month_002 |Verify that the gYearMonth type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.5 |m |y
+|=====================================================================================================================================================================
+
+== Gregorian year
+
+.Gregorian year
+
+[width="100%",cols="25%,10%,60%,15%,5%,5%",options="header",]
+|======================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_060506_gregorian_year_001 |Verify that the gYear type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.6 |m |y
+|2 |Pos_060506_gregorian_year_001 |Verify that the gYear type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.6 |m |y
+|3 |Pos_060506_gregorian_year_002 |Verify that the gYear type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.6 |m |y
+|4 |Pos_060506_gregorian_year_003 |Verify that the gYear allows year 0 |Clause 6.5.6 |m |y
+|5 |Pos_060506_gregorian_year_004 |Verify that the gYear type shall be translated to TTCN-3 using the pattern-restricted charstring |Clause 6.5.6 |m |y
+|6 |Pos_060506_gregorian_year_005 |Verify that the gYear accepts negative years |Clause 6.5.6 |m |y
+|7 |Pos_060506_gregorian_year_006 |Verify that the gYear allows negative year with more than 4 digits |Clause 6.5.6 |m |y
+|======================================================================================================================================================
+
+== Boolean type
+
+.Boolean type
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_0607_boolean_type_001 |Verify that the XSD boolean type shall be mapped to the TTCN-3 boolean type |Clause 6.7 |m |y
+|2 |Pos_0607_boolean_type_002 |Verify that the XSD boolean type shall be mapped to the TTCN-3 boolean type |Clause 6.7 |m |y
+|===========================================================================================================================
+
+== AnyType and anySimpleType types
+
+.AnyType and anySimpleType types
+
+[width="99%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=====================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_0608_anytype_and_anysimpletype_types_001 |Verify conversion of anySimpleType |Clause 6.8 |m |y
+|2 |Pos_0608_anytype_and_anysimpletype_types_002 |Verify conversion of anyType |Clause 6.8 |m |y
+|=====================================================================================================
+
+== Id
+
+.Id
+
+[width="99%",cols="25%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070101_id_001 |Verify conversion of id attribute of global element |Clause 7.1.1 |m |n
+|2 |Pos_070101_id_002 |verify conversion of id attribute of local element |Clause 7.1.1 |m |n
+|=============================================================================================
+
+== MinOccurs and maxOccurs
+
+.MinOccurs and maxOccurs
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_070104_minoccurs_and_maxoccurs_001 |a list with minOccurs 0 should not be mapped optional in TTCN-3 |Clause 7.1.4 |m |y
+|2 |Neg_070104_minoccurs_and_maxoccurs_002 |A restricted length list [5, 10] should not allow less than 5 elements |Clause 7.1.4 |m |y
+|3 |Neg_070104_minoccurs_and_maxoccurs_003 |A restricted length list [5, 10] should not allow more than 10 elements |Clause 7.1.4 |m |y
+|4 |Pos_070104_minoccurs_and_maxoccurs_001 |Optional field defined by minOccurs has to be mapped as optional in TTCN-3 |Clause 7.1.4 |m |y
+|5 |Pos_070104_minoccurs_and_maxoccurs_002 |Optional field defined by minOccurs has to exist in TTCN-3 and match the value |Clause 7.1.4 |m |y
+|6 |Pos_070104_minoccurs_and_maxoccurs_003 |a list with minOccurs 0 should allow zero elements |Clause 7.1.4 |m |y
+|7 |Pos_070104_minoccurs_and_maxoccurs_004 |A restricted length list (0, unbounded) should allow elements |Clause 7.1.4 |m |y
+|8 |Pos_070104_minoccurs_and_maxoccurs_005 |A restricted length list [5, 10] should allow 5 elements |Clause 7.1.4 |m |y
+|9 |Pos_070104_minoccurs_and_maxoccurs_006 |A restricted length list [5, 10] should allow 10 elements |Clause 7.1.4 |m |y
+|10 |Pos_070104_minoccurs_and_maxoccurs_007 |A restricted length list [5, 10] should allow 7 elements |Clause 7.1.4 |m |y
+|=============================================================================================================================================
+
+== Default and Fixed
+
+.Default and Fixed
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_070105_default_and_fixed_001 |Verify constraint of type based on XSD definition with fixed attribute |Clause 7.1.5 |m |y
+|2 |Pos_070105_default_and_fixed_001 |Verify conversion of fixed attribute |Clause 7.1.5 |m |y
+|3 |Pos_070105_default_and_fixed_002 |Verify conversion of default attribute |Clause 7.1.5 |m |y
+|4 |Pos_070105_default_and_fixed_003 |Verify that default value is automatically assigned to empty element by decoder |Clause 7.1.5 |m |y
+|5 |Pos_070105_default_and_fixed_004 |Verify that fixed value is automatically assigned to empty element by decoder |Clause 7.1.5 |m |y
+|========================================================================================================================================
+
+== Form
+
+.Form
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_070106_form_001 |check correct namespace prefix encoding for elementFormDefault |Clause 7.1.6 |m |n
+|2 |Neg_070106_form_002 |check correct namespace prefix encoding for elementFormDefault |Clause 7.1.6 |m |n
+|3 |Neg_070106_form_003 |check correct namespace prefix encoding for attributeFormDefault |Clause 7.1.6 |m |n
+|4 |Neg_070106_form_004 |check correct namespace prefix encoding for attributeFormDefault |Clause 7.1.6 |m |n
+|5 |Pos_070106_form_001 |Verify that unqualified attribute form is correctly converted (unqualified attributeFormDefault) |Clause 7.1.6 |m |y
+|6 |Pos_070106_form_002 |Verify that unqualified attribute form is correctly converted (qualified attributeFormDefault) |Clause 7.1.6 |m |y
+|7 |Pos_070106_form_003 |Verify that qualified attribute form is correctly converted (unqualified attributeFormDefault) |Clause 7.1.6 |m |y
+|8 |Pos_070106_form_004 |Verify that qualified attribute form is correctly converted (qualified attributeFormDefault) |Clause 7.1.6 |m |y
+|9 |Pos_070106_form_005 |Verify that unqualified element form is correctly converted (unqualified elementFormDefault) |Clause 7.1.6 |m |y
+|10 |Pos_070106_form_006 |Verify that unqualified element form is correctly converted (qualified elementFormDefault) |Clause 7.1.6 |m |y
+|11 |Pos_070106_form_007 |Verify that qualified element form is correctly converted (unqualified elementFormDefault) |Clause 7.1.6 |m |y
+|12 |Pos_070106_form_008 |Verify that qualified element form is correctly converted (qualified elementFormDefault) |Clause 7.1.6 |m |y
+|13 |Pos_070106_form_009 |check correct namespace prefix encoding for elementFormDefault |Clause 7.1.6 |m |y
+|14 |Pos_070106_form_010 |check correct namespace prefix encoding for elementFormDefault |Clause 7.1.6 |m |y
+|15 |Pos_070106_form_011 |check correct namespace prefix encoding for attributeFormDefault |Clause 7.1.6 |m |y
+|16 |Pos_070106_form_012 |check correct namespace prefix encoding for attributeFormDefault |Clause 7.1.6 |m |y
+|============================================================================================================================================
+
+== Type
+
+.Type
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==============================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070107_type_001 |Verify conversion of type attribute referencing global simpleType |Clause 7.1.7 |m |y
+|2 |Pos_070107_type_002 |Verify conversion of type attribute referencing global complexType |Clause 7.1.7 |m |y
+|3 |Pos_070107_type_003 |Verify conversion of type attribute referencing built-in type |Clause 7.1.7 |m |y
+|==============================================================================================================
+
+== Use
+
+.Use
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==========================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_070112_use_001 |Verify that attribute with required use cannot be omitted |Clause 7.1.12 |m |y
+|2 |Pos_070112_use_001 |Verify that attribute with required use is correctly converted |Clause 7.1.12 |m |y
+|3 |Pos_070112_use_002 |Verify that attribute with optional use is correctly converted |Clause 7.1.12 |m |y
+|4 |Pos_070112_use_003 |Verify that attribute with prohibited use is not converted |Clause 7.1.12 |m |y
+|==========================================================================================================
+
+== Final
+
+.Final
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070114_final_001 |Verify conversion of elements with final attribute |Clause 7.1.14 |m |y
+|================================================================================================
+
+== Element component
+
+.Element component
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|======================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_0703_element_component_001 |Verify conversion of global element of simple type |Clause 7.3 |m |y
+|2 |Pos_0703_element_component_002 |Verify conversion of global element of user defined type |Clause 7.3 |m |y
+|3 |Pos_0703_element_component_003 |Verify conversion of global element of locally defined complex type |Clause 7.3 |m |y
+|4 |Pos_0703_element_component_004 |Verify conversion of local elements defined by reference with different namespace |Clause 7.3 |m |y
+|======================================================================================================================================
+
+== Attribute element definitions
+
+.Attribute element definitions
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070401_attribute_element_definitions_001 |Verify mapping of a globally defined attribute |Clause 7.4.1 |m |y
+|===================================================================================================================
+
+== Attribute group definitions
+
+.Attribute group definitions
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070402_attribute_group_definitions_001 |Verify mapping of a globally defined attribute group |Clause 7.4.2 |m |y
+|=======================================================================================================================
+
+== Derivation by restriction
+
+.Derivation by restriction
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070501_derivation_by_restriction_001 |Verify that it is possible to convert anonymously |Clause 7.5.1 |m |y
+|==================================================================================================================
+
+== Derivation by list
+
+.Derivation by list
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_070502_derivation_by_list_001 |Verify length constraint imposed on type derived by list |Clause 7.5.2 |m |y
+|2 |Neg_070502_derivation_by_list_002 |Verify constraint imposed on inner type defined inside XSD list |Clause 7.5.2 |m |y
+|3 |Pos_070502_derivation_by_list_001 |Verify that derivation by list is converted to record of |Clause 7.5.2 |m |y
+|4 |Pos_070502_derivation_by_list_002 |Verify mapping of facets connected applied to derivation by list |Clause 7.5.2 |m |y
+|5 |Pos_070502_derivation_by_list_003 |Verify conversion of facets defined inside XSD list |Clause 7.5.2 |m |y
+|6 |Pos_070502_derivation_by_list_004 |Verify transformation of derivation by list with enumerated facets inside |Clause 7.5.2 |m |y
+|7 |Pos_070502_derivation_by_list_005 |Verify transformation of list containing union content |Clause 7.5.2 |m |y
+|===================================================================================================================================
+
+== Derivation by union
+
+.Derivation by union
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070503_derivation_by_union_001 |Verify transformation of union with memberTypes attribute |Clause 7.5.3 |m |y
+|2 |Pos_070503_derivation_by_union_002 |Verify transformation of union with unnamed member types |Clause 7.5.3 |m |y
+|3 |Pos_070503_derivation_by_union_003 |Verify transformation of union with memberTypes attribute and unnamed member types |Clause 7.5.3 |m |y
+|4 |Pos_070503_derivation_by_union_004 |Verify transformation of union with memberTypes attribute and unnamed enumeration |Clause 7.5.3 |m |y
+|5 |Pos_070503_derivation_by_union_005 |Verify transformation of union content containing enumeration facets |Clause 7.5.3 |m |y
+|6 |Pos_070503_derivation_by_union_006 |Verify transformation of union containing list content |Clause 7.5.3 |m |y
+|=============================================================================================================================================
+
+== Extending simple content
+
+.Extending simple content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==============================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060101_extending_simple_content_001 |Verify extension of a built-in type by adding an attribute |Clause 7.6.1.1 |m |y
+|==============================================================================================================================
+
+== Restricting simple content
+
+.Restricting simple content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_07060102_restricting_simple_content_001 |Verify restriction of a base type |Clause 7.6.1.2 |m |y
+|2 |Pos_07060102_restricting_simple_content_001 |Verify restriction of a base type |Clause 7.6.1.2 |m |y
+|=======================================================================================================
+
+== Complex content derived by extension
+
+.Complex content derived by extension
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===================================================================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060201_derived_by_extension_001 |Verify mapping of complex type where both the base and the extending types have the compositor sequence |Clause 7.6.2.1 |m |y
+|2 |Pos_07060201_derived_by_extension_002 |Verify mapping of complex type where both the base and the extending types have the compositor sequence and multiple occurrences are allowed |Clause 7.6.2.1 |m |y
+|3 |Pos_07060201_derived_by_extension_003 |Verify mapping of complex type where both the base and the extending types have the compositor sequence and multiple occurrences are allowed |Clause 7.6.2.1 |m |y
+|4 |Pos_07060201_derived_by_extension_004 |Verify mapping of complex type where both the base and the extending types have the compositor sequence and multiple occurrences are allowed |Clause 7.6.2.1 |m |y
+|5 |Pos_07060201_derived_by_extension_005 |Verify mapping of complex type where both the base and the extending types have the compositor sequence and multiple occurrences are allowed |Clause 7.6.2.1 |m |y
+|6 |Pos_07060201_derived_by_extension_006 |Verify mapping of complex type where both the base and the extending types have the compositor choice |Clause 7.6.2.1 |m |y
+|7 |Pos_07060201_derived_by_extension_007 |Verify mapping of complex type where extension of a sequence base type by a choice model group |Clause 7.6.2.1 |m |y
+|8 |Pos_07060201_derived_by_extension_008 |Verify mapping of complex type: extending of a base type with choice model group by a sequence model group |Clause 7.6.2.1 |m |y
+|9 |Pos_07060201_derived_by_extension_009 |Verify mapping of complex type: Recursive extension of an anonymous inner type is realized using the TTCN-3 dot notation (starts from the name of the outmost type) |Clause 7.6.2.1 |m |y
+|===================================================================================================================================================================================================================================
+
+== Complex content derived by restriction
+
+.Complex content derived by restriction
+
+[width="100%",cols="25%,10%,60%,15%,5%,5%",options="header",]
+|==========================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060202_derived_by_restriction_001 |Verify mapping of complex content derived by restriction |Clause 7.6.2.2 |m |y
+|==========================================================================================================================
+
+== Referencing group components
+
+.Referencing group components
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070603_referencing_group_components_001 |Verify conversion of group reference occurring as child of complex type (sequence, one occurrence) |Clause 7.6.3 |m |y
+|2 |Pos_070603_referencing_group_components_002 |Verify conversion of group reference occurring inside sequence |Clause 7.6.3 |m |y
+|3 |Pos_070603_referencing_group_components_003 |Verify conversion of group reference occurring as child of complex type (sequence, optional occurrence) |Clause 7.6.3 |m |y
+|4 |Pos_070603_referencing_group_components_004 |Verify conversion of group reference occurring as child of complex type (sequence, 0..N) |Clause 7.6.3 |m |y
+|5 |Pos_070603_referencing_group_components_005 |Verify conversion of group reference occurring as child of complex type (all, one occurrence) |Clause 7.6.3 |m |y
+|6 |Pos_070603_referencing_group_components_006 |Verify conversion of group reference occurring as child of complex type (all, 0..1) |Clause 7.6.3 |m |y
+|7 |Pos_070603_referencing_group_components_007 |Verify conversion of group reference occurring as child of complex type (choice, one occurrence) |Clause 7.6.3 |m |y
+|8 |Pos_070603_referencing_group_components_008 |Verify conversion of group reference occurring as child of complex type (choice, 0..1) |Clause 7.6.3 |m |y
+|9 |Pos_070603_referencing_group_components_009 |Verify conversion of group reference occurring as child of complex type (choice, 0..N) |Clause 7.6.3 |m |y
+|10 |Pos_070603_referencing_group_components_010 |Verify conversion of group reference occurring inside choice |Clause 7.6.3 |m |y
+|===========================================================================================================================================================================
+
+== All content
+
+.All content
+
+[width="99%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070604_all_content_001 |Verify conversion of all content containing mandatory fields |Clause 7.6.4 |m |y
+|2 |Pos_070604_all_content_002 |Verify conversion of all content with minOccurs=``0'' |Clause 7.6.4 |m |y
+|3 |Pos_070604_all_content_003 |Verify transformation of elements with minOccurs attribute occurring inside all content |Clause 7.6.4 |m |y
+|4 |Pos_070604_all_content_004 |Verify transformation of all content containing attributes |Clause 7.6.4 |m |y
+|==========================================================================================================================================
+
+== Choice content
+
+.Choice content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|====================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070605_top_level_001 |Verify that choice content with minOccurs different than 1 is correctly transformed |Clause 7.6.5 |m |y
+|2 |Pos_070605_top_level_002 |Verify that choice content with maxOccurs larger than 1 is correctly transformed |Clause 7.6.5 |m |y
+|====================================================================================================================================
+
+== Choice with nested elements
+
+.Choice with nested elements
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060501_choice_with_nested_elements_001 |Verify that choice content with nested elements is correctly transformed |Clause 7.6.5.1 |m |y
+|===============================================================================================================================================
+
+== Choice with nested group
+
+.Choice with nested group
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060502_choice_with_nested_group_001 |Verify that choice content with nested group is correctly transformed |Clause 7.6.5.2 |m |y
+|=========================================================================================================================================
+
+== Choice with nested choice
+
+.Choice with nested choice
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===========================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060503_choice_with_nested_choice_001 |Verify that choice content with nested choice is correctly transformed |Clause 7.6.5.3 |m |y
+|===========================================================================================================================================
+
+== Choice with nested sequence
+
+.Choice with nested sequence
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=========================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060504_choice_with_nested_sequence_001 |Verify that choice content with nested sequence is correctly transformed |Clause 7.6.5.4 |m |y
+|2 |Pos_07060504_choice_with_nested_sequence_002 |Verify that choice content with multiple nested sequences is correctly transformed |Clause 7.6.5.4 |m |y
+|=========================================================================================================================================================
+
+== Choice with nested any
+
+.Choice with nested any
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=====================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060505_choice_with_nested_any_001 |Verify that choice content with nested any is correctly transformed |Clause 7.6.5.5 |m |y
+|=====================================================================================================================================
+
+== Sequence with nested element content
+
+.Sequence with nested element content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060601_sequence_with_nested_element_001 |Verify that sequence content with nested elements is correctly transformed |Clause 7.6.6.1 |m |y
+|==================================================================================================================================================
+
+== Sequence with nested group content
+
+.Sequence with nested group content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060602_sequence_with_nested_group_001 |Verify that sequence content with group reference is correctly transformed |Clause 7.6.6.2 |m |y
+|================================================================================================================================================
+
+== Sequence with nested choice content
+
+.Sequence with nested choice content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|===============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060603_sequence_with_nested_choice_001 |Verify that sequence content with nested choice is correctly transformed |Clause 7.6.6.3 |m |y
+|===============================================================================================================================================
+
+== Sequence with nested sequence content
+
+.Sequence with nested sequence content
+
+[width="100%",cols="25%,10%,60%,15%,5%,5%",options="header",]
+|============================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060604_sequence_with_nested_sequence_001 |Verify that sequence content with sequence is correctly transformed |Clause 7.6.6.4 |m |y
+|2 |Pos_07060604_sequence_with_nested_sequence_002 |Verify that sequence content with various nested particles is correctly transformed |Clause 7.6.6.4 |m |y
+|============================================================================================================================================================
+
+== Sequence with nested any content
+
+.Sequence with nested any content
+
+[width="100%",cols="20%,16%,16%,16%,16%,16%",options="header",]
+|=========================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060605_sequence_with_nested_any_content_001 |Verify that sequence content with nested any content is correctly transformed |Clause 7.6.6.5 |m |y
+|=========================================================================================================================================================
+
+== Effect of the minOccurs and maxOccurs attributes on the mapping
+
+.Effect of the minOccurs and maxOccurs attributes on the mapping
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_07060606_effect_of_minoccurs_and_maxoccurs_001 |Verify that sequences with minOccurs=0 are correctly converted to optional fields |Clause 7.6.6.6 |m |y
+|2 |Pos_07060606_effect_of_minoccurs_and_maxoccurs_002 |Verify that nested sequences are correctly converted to optional fields |Clause 7.6.6.6 |m |y
+|3 |Pos_07060606_effect_of_minoccurs_and_maxoccurs_003 |Verify that sequences with minOccurs=unbounded are correctly converted to record of fields |Clause 7.6.6.6 |m |y
+|4 |Pos_07060606_effect_of_minoccurs_and_maxoccurs_004 |Verify that nested sequences are correctly converted to record of fields |Clause 7.6.6.6 |m |y
+|=======================================================================================================================================================================
+
+== Attribute definitions, attribute and attributeGroup references
+
+.Attribute definitions, attribute and attributeGroup references
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=========================================================================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070607_attribute_definitions_attribute_and_attributegroup_references_001 |Verify referencing an attributeGroup in a complexType |Clause 7.6.7 |m |y
+|2 |Pos_070607_attribute_definitions_attribute_and_attributegroup_references_002 |Verify mapping of a local attributes, attribute references and attribute group references without a target namespace |Clause 7.6.7 |m |y
+|3 |Pos_070607_attribute_definitions_attribute_and_attributegroup_references_003 |Verify mapping of a local attributes, attribute references and attribute group references with a target namespace |Clause 7.6.7 |m |y
+|=========================================================================================================================================================================================================================
+
+== Mixed content
+
+.Mixed content
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==============================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070608_mixed_content_001 |Verify transformation of complex type with sequence constructor and mixed content type |Clause 7.6.8 |m |y
+|2 |Pos_070608_mixed_content_002 |Verify transformation of complex type definition with sequence constructor of multiple occurrences and mixed content type |Clause 7.6.8 |m |n
+|3 |Pos_070608_mixed_content_003 |Verify transformation of complex type definition with all constructor and mixed content type |Clause 7.6.8 |m |y
+|4 |Pos_070608_mixed_content_004 |Verify transformation of complex type definition with all constructor, optional elements and mixed content type |Clause 7.6.8 |m |n
+|5 |Pos_070608_mixed_content_005 |Verify transformation of complex type definition with all constructor, optional elements and mixed content type |Clause 7.6.8 |m |y
+|==============================================================================================================================================================================
+
+== The any element
+
+.The any element
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070701_the_any_element_001 |Verify conversion of the any element without namespace attribute |Clause 7.7.1 |m |y
+|2 |Pos_070701_the_any_element_002 |Verify conversion of the any element with ##any namespace |Clause 7.7.1 |m |y
+|3 |Pos_070701_the_any_element_003 |Verify conversion of the any element with ##local namespace |Clause 7.7.1 |m |y
+|4 |Pos_070701_the_any_element_004 |Verify conversion of the any element with ##other namespace |Clause 7.7.1 |m |y
+|5 |Pos_070701_the_any_element_005 |Verify conversion of the any element with ##targetNamespace namespace |Clause 7.7.1 |m |y
+|6 |Pos_070701_the_any_element_006 |Verify conversion of the any element with URL as namespace into record of |Clause 7.7.1 |m |y
+|================================================================================================================================
+
+== The anyAttribute element
+
+.The anyAttribute element
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=======================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_070702_the_anyattribute_element_001 |Verify conversion of anyAttribute element |Clause 7.7.2 |m |y
+|2 |Pos_070702_the_anyattribute_element_002 |Verify that anyAttribute is converted into optional field |Clause 7.7.2 |m |y
+|3 |Pos_070702_the_anyattribute_element_003 |Verify that the naming rules apply to converted anyAttribute field |Clause 7.7.2 |m |y
+|4 |Pos_070702_the_anyattribute_element_004 |Verify that conversion of anyAttribute present both in extended type and extension base |Clause 7.7.2 |m |y
+|5 |Pos_070702_the_anyattribute_element_005 |Verify that converted anyAttribute field is in correct place |Clause 7.7.2 |m |y
+|=======================================================================================================================================================
+
+== Annotation
+
+.Annotation
+
+[width="99%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=========================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_0708_annotation_001 |Verify that XSD annotation can be processed |Clause 7.8 |m |y
+|=========================================================================================
+
+== Group components
+
+.Group components
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|======================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_0709_group_components_001 |Verify conversion of group definition with sequence compositor |Clause 7.9 |m |y
+|2 |Pos_0709_group_components_002 |Verify transformation of group definition with sequence compositor |Clause 7.9 |m |y
+|3 |Pos_0709_group_components_003 |Verify conversion of group definition with all compositor |Clause 7.9 |m |y
+|======================================================================================================================
+
+== Identity-constraint definition schema components
+
+.Identity-constraint definition schema components
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|==============================================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_0710_identity_constraint_definition_schema_components_001 |Verify that unique elements (and nested selector and field) are ignored during conversion |Clause 7.10 |m |y
+|2 |Pos_0710_identity_constraint_definition_schema_components_002 |Verify that key elements (and nested selector and field) are ignored during conversion |Clause 7.10 |m |y
+|3 |Pos_0710_identity_constraint_definition_schema_components_003 |Verify that keyRef elements (and nested selector and field) are ignored during conversion |Clause 7.10 |m |y
+|==============================================================================================================================================================================
+
+== Head elements of substitution groups
+
+.Head elements of substitution groups
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|====================================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Pos_080101_head_elements_of_substitution_groups_001 |Generic substitution group example |Clause 8.1.1 |m |y
+|2 |Pos_080101_head_elements_of_substitution_groups_002 |Show effect of the block and abstract attributes on element substitution |Clause 8.1.1 |m |y
+|3 |Neg_080101_head_elements_of_substitution_groups_002 |Show effect of the block and abstract attributes on element substitution |Clause 8.1.1 |m |y
+|4 |Pos_080101_head_elements_of_substitution_groups_003 |Blocking substitution |Clause 8.1.1 |m |y
+|5 |Neg_080101_head_elements_of_substitution_groups_003 |Blocking substitution |Clause 8.1.1 |m |y
+|====================================================================================================================================================
+
+== TTCN-3 module XSD
+
+.TTCN-3 module XSD
+
+[width="100%",cols="5%,10%,60%,15%,5%,5%",options="header",]
+|=============================================================================================================================================
+|Item |TC/TP reference |Purpose |Reference in link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.06.01_60/es_20187309v040601p.pdf[ETSI ES 201 8739] |Status |Support
+|1 |Neg_A_ttcn3_module_xsd_001 |Ensure the builtin XSD type AnySimpleType allows only valid values |Annex A |m |y
+|2 |Neg_A_ttcn3_module_xsd_002 |Ensure the builtin XSD type AnyType allows only valid values |Annex A |m |y
+|3 |Neg_A_ttcn3_module_xsd_003 |Ensure the builtin XSD type String allows only valid values |Annex A |m |y
+|4 |Neg_A_ttcn3_module_xsd_004 |Ensure the builtin XSD type NormalizedString allows only valid values |Annex A |m |y
+|5 |Neg_A_ttcn3_module_xsd_005 |Ensure the builtin XSD type Token allows only valid values |Annex A |m |y
+|6 |Neg_A_ttcn3_module_xsd_006 |Ensure the builtin XSD type Name allows only valid values |Annex A |m |y
+|7 |Neg_A_ttcn3_module_xsd_007 |Ensure the builtin XSD type NMTOKEN allows only valid values |Annex A |m |y
+|8 |Neg_A_ttcn3_module_xsd_008 |Ensure the builtin XSD type NCName allows only valid values |Annex A |m |y
+|9 |Neg_A_ttcn3_module_xsd_009 |Ensure the builtin XSD type ID allows only valid values |Annex A |m |y
+|10 |Neg_A_ttcn3_module_xsd_010 |Ensure the builtin XSD type IDREF allows only valid values |Annex A |m |y
+|11 |Neg_A_ttcn3_module_xsd_011 |Ensure the builtin XSD type ENTITY allows only valid values |Annex A |m |y
+|12 |Neg_A_ttcn3_module_xsd_012 |Ensure the builtin XSD type HexBinary allows only valid values |Annex A |m |y
+|13 |Neg_A_ttcn3_module_xsd_013 |Ensure the builtin XSD type Base64Binary allows only valid values |Annex A |m |y
+|14 |Neg_A_ttcn3_module_xsd_014 |Ensure the builtin XSD type AnyURI allows only valid values |Annex A |m |y
+|15 |Neg_A_ttcn3_module_xsd_015 |Ensure the builtin XSD type Language allows only valid values |Annex A |m |y
+|16 |Neg_A_ttcn3_module_xsd_016 |Ensure the builtin XSD type Integer allows only valid values |Annex A |m |y
+|17 |Neg_A_ttcn3_module_xsd_017 |Ensure the builtin XSD type PositiveInteger allows only valid values |Annex A |m |y
+|18 |Neg_A_ttcn3_module_xsd_018 |Ensure the builtin XSD type NonPositiveInteger allows only valid values |Annex A |m |y
+|19 |Neg_A_ttcn3_module_xsd_019 |Ensure the builtin XSD type NegativeInteger allows only valid values |Annex A |m |y
+|20 |Neg_A_ttcn3_module_xsd_020 |Ensure the builtin XSD type NonNegativeInteger allows only valid values |Annex A |m |y
+|21 |Neg_A_ttcn3_module_xsd_021 |Ensure the builtin XSD type Long allows only valid values |Annex A |m |y
+|22 |Neg_A_ttcn3_module_xsd_022 |Ensure the builtin XSD type UnsignedLong allows only valid values |Annex A |m |y
+|23 |Neg_A_ttcn3_module_xsd_023 |Ensure the builtin XSD type Int allows only valid values |Annex A |m |y
+|24 |Neg_A_ttcn3_module_xsd_024 |Ensure the builtin XSD type UnsignedInt allows only valid values |Annex A |m |y
+|25 |Neg_A_ttcn3_module_xsd_025 |Ensure the builtin XSD type Short allows only valid values |Annex A |m |y
+|26 |Neg_A_ttcn3_module_xsd_026 |Ensure the builtin XSD type UnsignedShort allows only valid values |Annex A |m |y
+|27 |Neg_A_ttcn3_module_xsd_027 |Ensure the builtin XSD type Byte allows only valid values |Annex A |m |y
+|28 |Neg_A_ttcn3_module_xsd_028 |Ensure the builtin XSD type UnsignedByte allows only valid values |Annex A |m |y
+|29 |Neg_A_ttcn3_module_xsd_029 |Ensure the builtin XSD type Decimal allows only valid values |Annex A |m |y
+|30 |Neg_A_ttcn3_module_xsd_030 |Ensure the builtin XSD type Float allows only valid values |Annex A |m |y
+|31 |Neg_A_ttcn3_module_xsd_031 |Ensure the builtin XSD type Double allows only valid values |Annex A |m |y
+|32 |Neg_A_ttcn3_module_xsd_032 |Ensure the builtin XSD type Duration allows only valid values |Annex A |m |y
+|33 |Neg_A_ttcn3_module_xsd_033 |Ensure the builtin XSD type DateTime allows only valid values |Annex A |m |y
+|34 |Neg_A_ttcn3_module_xsd_034 |Ensure the builtin XSD type Time allows only valid values |Annex A |m |y
+|35 |Neg_A_ttcn3_module_xsd_035 |Ensure the builtin XSD type Date allows only valid values |Annex A |m |y
+|36 |Neg_A_ttcn3_module_xsd_036 |Ensure the builtin XSD type GYearMonth allows only valid values |Annex A |m |y
+|37 |Neg_A_ttcn3_module_xsd_037 |Ensure the builtin XSD type GYear allows only valid values |Annex A |m |y
+|38 |Neg_A_ttcn3_module_xsd_038 |Ensure the builtin XSD type GMonthDay allows only valid values |Annex A |m |y
+|39 |Neg_A_ttcn3_module_xsd_039 |Ensure the builtin XSD type GDay allows only valid values |Annex A |m |y
+|40 |Neg_A_ttcn3_module_xsd_040 |Ensure the builtin XSD type GMonth allows only valid values |Annex A |m |y
+|41 |Neg_A_ttcn3_module_xsd_041 |Ensure the builtin XSD type NMTOKENS allows only valid values |Annex A |m |y
+|42 |Neg_A_ttcn3_module_xsd_042 |Ensure the builtin XSD type IDREFS allows only valid values |Annex A |m |y
+|43 |Neg_A_ttcn3_module_xsd_043 |Ensure the builtin XSD type ENTITIES allows only valid values |Annex A |m |y
+|44 |Neg_A_ttcn3_module_xsd_044 |Ensure the builtin XSD type QName allows only valid values |Annex A |m |y
+|45 |Neg_A_ttcn3_module_xsd_045 |Ensure the builtin XSD type Boolean allows only valid values |Annex A |m |y
+|46 |Neg_A_ttcn3_module_xsd_046 |Ensure the builtin XSD type XMLCompatibleString allows only valid values |Annex A |m |y
+|47 |Neg_A_ttcn3_module_xsd_047 |Ensure the builtin XSD type XMLStringWithNoWhitespace allows only valid values |Annex A |m |y
+|48 |Neg_A_ttcn3_module_xsd_048 |Ensure the builtin XSD type XMLStringWithNoCRLFHT allows only valid values |Annex A |m |y
+|49 |Pos_A_ttcn3_module_xsd_001 |Ensure the module XSD is available and contains the builtin XSD type AnySimpleType |Annex A |m |y
+|50 |Pos_A_ttcn3_module_xsd_002 |Ensure the module XSD is available and contains the builtin XSD type AnyType |Annex A |m |y
+|51 |Pos_A_ttcn3_module_xsd_003 |Ensure the module XSD is available and contains the builtin XSD type String |Annex A |m |y
+|52 |Pos_A_ttcn3_module_xsd_004 |Ensure the module XSD is available and contains the builtin XSD type NormalizedString |Annex A |m |y
+|53 |Pos_A_ttcn3_module_xsd_005 |Ensure the module XSD is available and contains the builtin XSD type Token |Annex A |m |y
+|54 |Pos_A_ttcn3_module_xsd_006 |Ensure the module XSD is available and contains the builtin XSD type Name |Annex A |m |y
+|55 |Pos_A_ttcn3_module_xsd_007 |Ensure the module XSD is available and contains the builtin XSD type NMTOKEN |Annex A |m |y
+|56 |Pos_A_ttcn3_module_xsd_008 |Ensure the module XSD is available and contains the builtin XSD type NCName |Annex A |m |y
+|57 |Pos_A_ttcn3_module_xsd_009 |Ensure the module XSD is available and contains the builtin XSD type ID |Annex A |m |y
+|58 |Pos_A_ttcn3_module_xsd_010 |Ensure the module XSD is available and contains the builtin XSD type IDREF |Annex A |m |y
+|59 |Pos_A_ttcn3_module_xsd_011 |Ensure the module XSD is available and contains the builtin XSD type ENTITY |Annex A |m |y
+|60 |Pos_A_ttcn3_module_xsd_012 |Ensure the module XSD is available and contains the builtin XSD type HexBinary |Annex A |m |y
+|61 |Pos_A_ttcn3_module_xsd_013 |Ensure the module XSD is available and contains the builtin XSD type Base64Binary |Annex A |m |y
+|62 |Pos_A_ttcn3_module_xsd_014 |Ensure the module XSD is available and contains the builtin XSD type AnyURI |Annex A |m |y
+|63 |Pos_A_ttcn3_module_xsd_015 |Ensure the module XSD is available and contains the builtin XSD type Language |Annex A |m |y
+|64 |Pos_A_ttcn3_module_xsd_016 |Ensure the module XSD is available and contains the builtin XSD type Integer |Annex A |m |y
+|65 |Pos_A_ttcn3_module_xsd_017 |Ensure the module XSD is available and contains the builtin XSD type PositiveInteger |Annex A |m |y
+|66 |Pos_A_ttcn3_module_xsd_018 |Ensure the module XSD is available and contains the builtin XSD type NonPositiveInteger |Annex A |m |y
+|67 |Pos_A_ttcn3_module_xsd_019 |Ensure the module XSD is available and contains the builtin XSD type NegativeInteger |Annex A |m |y
+|68 |Pos_A_ttcn3_module_xsd_020 |Ensure the module XSD is available and contains the builtin XSD type NonNegativeInteger |Annex A |m |y
+|69 |Pos_A_ttcn3_module_xsd_021 |Ensure the module XSD is available and contains the builtin XSD type Long |Annex A |m |y
+|70 |Pos_A_ttcn3_module_xsd_022 |Ensure the module XSD is available and contains the builtin XSD type UnsignedLong |Annex A |m |y
+|71 |Pos_A_ttcn3_module_xsd_023 |Ensure the module XSD is available and contains the builtin XSD type Int |Annex A |m |y
+|72 |Pos_A_ttcn3_module_xsd_024 |Ensure the module XSD is available and contains the builtin XSD type UnsignedInt |Annex A |m |y
+|73 |Pos_A_ttcn3_module_xsd_025 |Ensure the module XSD is available and contains the builtin XSD type Short |Annex A |m |y
+|74 |Pos_A_ttcn3_module_xsd_026 |Ensure the module XSD is available and contains the builtin XSD type UnsignedShort |Annex A |m |y
+|75 |Pos_A_ttcn3_module_xsd_027 |Ensure the module XSD is available and contains the builtin XSD type Byte |Annex A |m |y
+|76 |Pos_A_ttcn3_module_xsd_028 |Ensure the module XSD is available and contains the builtin XSD type UnsignedByte |Annex A |m |y
+|77 |Pos_A_ttcn3_module_xsd_029 |Ensure the module XSD is available and contains the builtin XSD type Decimal |Annex A |m |y
+|78 |Pos_A_ttcn3_module_xsd_030 |Ensure the module XSD is available and contains the builtin XSD type Float |Annex A |m |y
+|79 |Pos_A_ttcn3_module_xsd_031 |Ensure the module XSD is available and contains the builtin XSD type Double |Annex A |m |y
+|80 |Pos_A_ttcn3_module_xsd_032 |Ensure the module XSD is available and contains the builtin XSD type Duration |Annex A |m |y
+|81 |Pos_A_ttcn3_module_xsd_033 |Ensure the module XSD is available and contains the builtin XSD type DateTime |Annex A |m |y
+|82 |Pos_A_ttcn3_module_xsd_034 |Ensure the module XSD is available and contains the builtin XSD type Time |Annex A |m |y
+|83 |Pos_A_ttcn3_module_xsd_035 |Ensure the module XSD is available and contains the builtin XSD type Date |Annex A |m |y
+|84 |Pos_A_ttcn3_module_xsd_036 |Ensure the module XSD is available and contains the builtin XSD type GYearMonth |Annex A |m |y
+|85 |Pos_A_ttcn3_module_xsd_037 |Ensure the module XSD is available and contains the builtin XSD type GYear |Annex A |m |y
+|86 |Pos_A_ttcn3_module_xsd_038 |Ensure the module XSD is available and contains the builtin XSD type GMonthDay |Annex A |m |y
+|87 |Pos_A_ttcn3_module_xsd_039 |Ensure the module XSD is available and contains the builtin XSD type GDay |Annex A |m |y
+|88 |Pos_A_ttcn3_module_xsd_040 |Ensure the module XSD is available and contains the builtin XSD type GMonth |Annex A |m |y
+|89 |Pos_A_ttcn3_module_xsd_041 |Ensure the module XSD is available and contains the builtin XSD type NMTOKENS |Annex A |m |y
+|90 |Pos_A_ttcn3_module_xsd_042 |Ensure the module XSD is available and contains the builtin XSD type IDREFS |Annex A |m |y
+|91 |Pos_A_ttcn3_module_xsd_043 |Ensure the module XSD is available and contains the builtin XSD type ENTITIES |Annex A |m |y
+|92 |Pos_A_ttcn3_module_xsd_044 |Ensure the module XSD is available and contains the builtin XSD type QName |Annex A |m |y
+|93 |Pos_A_ttcn3_module_xsd_045 |Ensure the module XSD is available and contains the builtin XSD type Boolean |Annex A |m |y
+|94 |Pos_A_ttcn3_module_xsd_046 |Ensure the module XSD is available and contains the builtin XSD type XMLCompatibleString |Annex A |m |y
+|95 |Pos_A_ttcn3_module_xsd_047 |Ensure the module XSD is available and contains the builtin XSD type XMLStringWithNoWhitespace |Annex A |m |y
+|96 |Pos_A_ttcn3_module_xsd_048 |Ensure the module XSD is available and contains the builtin XSD type XMLStringWithNoCRLFHT |Annex A |m |y
+|=============================================================================================================================================
+
+= Notes
diff --git a/usrguide/SoC_XML_TITAN/images/titan_logo.png b/usrguide/SoC_XML_TITAN/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..3c480d030a9cdf274ca97f28c1564ea345067ba2
Binary files /dev/null and b/usrguide/SoC_XML_TITAN/images/titan_logo.png differ
diff --git a/usrguide/apiguide.doc b/usrguide/apiguide.doc
deleted file mode 100644
index 4d22654975d101b197d23fbd6265492616dd3b6d..0000000000000000000000000000000000000000
Binary files a/usrguide/apiguide.doc and /dev/null differ
diff --git a/usrguide/apiguide/1-introduction.adoc b/usrguide/apiguide/1-introduction.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..60756626951d572ba69aa27a79598e67224444d6
--- /dev/null
+++ b/usrguide/apiguide/1-introduction.adoc
@@ -0,0 +1,31 @@
+= Introduction
+
+== Overview
+
+This document describes the TITAN API on C\++ level. It is intended for users who write test port implementation, external function implementation in language C++ and want to use the available resources of TITAN.
+
+Detailed information can be found on the following topics:
+
+* test ports, the communication link between the TITAN Executor and System Under Test (SUT);
+
+* built-in encoding and decoding functions;
+
+* TTCN-3 data mapping to C++ constructs;
+
+* troubleshooting for common TTCN-3 related issues and problems.
+
+== Target Groups
+
+This document is intended for advanced users of the TITAN API on C++ level.
+
+== Typographical Conventions
+
+This document uses the following typographical conventions:
+
+*Bold* is used to represent graphical user interface (GUI) components such as buttons, menus, menu items, dialog box options, fields and keywords, as well as menu commands. Bold is also used with ’+’ to represent key combinations. For example, *Ctrl+Click*
+
+The '*/*' character is used to denote a menu and sub-menu sequence. For example, *File / Open*.
+
+`Monospaced` font is used represent system elements such as command and parameter names, program names, path names, URLs, directory names and code examples.
+
+`*Bold monospaced*` font is used for commands that must be entered at the Command Line Interface (CLI), For example, `*ttcn3_start*`
diff --git a/usrguide/apiguide/2-test_ports.adoc b/usrguide/apiguide/2-test_ports.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..462a0bea1fed07b662c1bc3f983d2919810fa3d4
--- /dev/null
+++ b/usrguide/apiguide/2-test_ports.adoc
@@ -0,0 +1,914 @@
+= Test Ports
+:table-number: 0
+:toc:
+
+The C++ source code generated by the Compiler is protocol independent, that is, it does not contain any device specific operations. To provide the connection between the executable test suite and SUT, that is, the physical interface of the test equipmentfootnote:[The test equipment not necessarily requires a special hardware; it can even be a simple PC with an Ethernet interface.], a so-called Test Port is needed.
+
+The Test Port is a software library written in C++ language, which is linked to the executable test program. It maps the device specific operations to function calls specified in an API. This chapter describes the Test Port API in details.
+
+== Generating the Skeleton
+
+The functions of Test Ports must be written by the user who knows the interface between the executable test suite and the test equipment. In order to make this development easier, the Compiler can generate Test Port skeletons. A Test Port belongs to one certain TTCN–3 port type, so the skeleton is generated based on port type definitions.
+
+A Test Port consists of two parts. One part is generated automatically by the Compiler, and it is put into the generated C++ code. The user has nothing to do with this part.
+
+The other part is a C\++ class, which is written mainly by the user. This class can be found in a separate C++ header and source file (their suffixes are `.hh` and `.cc`, respectively). The names of the source files and the C++ class are identical to the name of the port type. Please note that the name mapping rules described in <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc#mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> also apply to these class and file names.
+
+During the translation, when the Compiler encounters a port type definition and the `*–t*` command line switch is used, it checks whether the header and source files of Test Port exist in its working directory. If none of them can be found there, the compiler generates the skeleton header and source files for the corresponding test port automatically. This means, once you have generated (and possibly modified) a skeleton, it will never be overwritten. If you want to re-generate the skeleton, you must rename or remove the existing one.
+
+If the list of message types/signatures of a TTCN-3 port type changes, the list of the Test Port class member functions also needs to change. If the Test Port skeleton has been generated, it will not be modified, resulting in build errors (C++ compile errors like "cannot declare variable of abstract type"/"virtual functions are pure", or linker errors). In this case, the Test Port skeleton files should be renamed/moved, the skeleton generated, and any user-written code should be copied back into the newly generated source files.
+
+If you have defined a TTCN–3 port type that you intend to use for internal communication only (that is, for sending and receiving messages between TTCN–3 test components), you do not need to generate and compile an empty Test Port skeleton for that port type. Adding the attribute with `{extension "internal"}` to the port type definition in the TTCN–3 module disables the generation and use of a Test Port for the port type.
+
+WARNING: In this case you must not link the object file obtained from a previous Test Port skeleton to your executable test suite.
+
+In the following we introduce two port type definitions: one for a message based and another one for a procedure based port. In our further examples we will refer to the test port skeletons generated according to these definitions given within the module called `MyModule`.
+
+== Message-based Example
+
+The definition of `MyMessagePort`:
+[source]
+----
+type port MyMessagePort message
+{
+  in octetstring;
+  out integer;
+  inout charstring;
+};
+----
+That is, the types integer and charstring can be sent, and octetstring and charstring can be received on port `MyMessagePort`.
+
+The generated skeleton header file (that is, `MyMessagePort.hh`) will look as follows:
+[source]
+----
+// This Test Port skeleton header file was generated by the
+// TTCN-3 Compiler of the TTCN-3 Test Executor version 1.7.pre4 build 4
+// for Csaba Feher (ecsafeh@ehubuux110) on Tue Jul 29 18:45:10 2008
+
+// Copyright Ericsson Telecom AB 2000-2014
+
+// You may modify this file. Add your attributes and prototypes of your
+// member functions here.
+
+#ifndef MyMessagePort_HH
+#define MyMessagePort_HH
+
+#include "MyModule.hh"
+
+namespace MyModule {
+
+class MyMessagePort : public MyMessagePort_BASE {
+public:
+	MyMessagePort(const char *par_port_name = NULL);
+	~MyMessagePort();
+
+	void set_parameter(const char *parameter_name,
+		const char *parameter_value);
+
+private:
+	/* void Handle_Fd_Event(int fd, boolean is_readable,
+		boolean is_writable, boolean is_error); */
+	void Handle_Fd_Event_Error(int fd);
+	void Handle_Fd_Event_Writable(int fd);
+	void Handle_Fd_Event_Readable(int fd);
+	/* void Handle_Timeout(double time_since_last_call); */
+protected:
+	void user_map(const char *system_port);
+	void user_unmap(const char *system_port);
+
+	void user_start();
+	void user_stop();
+
+	void outgoing_send(const INTEGER& send_par);
+	void outgoing_send(const CHARSTRING& send_par);
+};
+
+} /* end of namespace */
+
+#endif
+----
+
+And the generated skeleton source file, that is, `MyMessagePort.cc`, will be the following:
+
+[source]
+----
+// This Test Port skeleton source file was generated by the
+// TTCN-3 Compiler of the TTCN-3 Test Executor version 1.7.pre4 build 4
+// for Csaba Feher (ecsafeh@ehubuux110) on Tue Jul 29 18:45:10 2008
+
+// Copyright Ericsson Telecom AB 2000-2014
+
+// You may modify this file. Complete the body of empty functions and
+// add your member functions here.
+
+#include "MyMessagePort.hh"
+
+namespace MyModule {
+
+MyMessagePort::MyMessagePort(const char *par_port_name)
+	: MyMessagePort_BASE(par_port_name)
+{
+
+}
+
+MyMessagePort::~MyMessagePort()
+{
+
+}
+
+void MyMessagePort::set_parameter(const char *parameter_name,
+	const char *parameter_value)
+{
+
+}
+
+/*void MyMessagePort::Handle_Fd_Event(int fd, boolean is_readable,
+	boolean is_writable, boolean is_error) {}*/
+
+void MyMessagePort::Handle_Fd_Event_Error(int fd)
+{
+
+}
+
+void MyMessagePort::Handle_Fd_Event_Writable(int fd)
+{
+
+}
+
+void MyMessagePort::Handle_Fd_Event_Readable(int fd)
+{
+
+}
+
+/*void MyMessagePort::Handle_Timeout(double time_since_last_call) {}*/
+
+void MyMessagePort::user_map(const char *system_port)
+{
+
+}
+
+void MyMessagePort::user_unmap(const char *system_port)
+{
+
+}
+
+void MyMessagePort::user_start()
+{
+
+}
+
+void MyMessagePort::user_stop()
+{
+
+}
+
+void MyMessagePort::outgoing_send(const INTEGER& send_par)
+{
+
+}
+
+void MyMessagePort::outgoing_send(const CHARSTRING& send_par)
+{
+
+}
+
+} /* end of namespace */
+----
+
+=== Procedure-based Example
+
+The definition of `MyProcedurePort` in module `MyModule`:
+[source]
+----
+type port MyProcedurePort procedure
+{
+  in inProc;
+  out outProc;
+  inout inoutProc;
+};
+----
+
+The signature definitions are imported from a module called `MyModule2`, `noblock` is not used and exceptions are used so that every member function of the port class is generated for this example. If the keyword `noblock` is used the compiler will optimize code generation by not generating outgoing reply, incoming reply member functions and their argument types. If the signature has no exception outgoing raise, incoming exception member functions and related types will not be generated.
+
+The port type `MyProcedurePort` can handle `call`, `getreply` and `catch` operations referencing the signatures `outProc` and `inoutProc`, and it can handle `getcall`, `reply` and `raise` operations referencing the signatures `inProc` and `inoutProc`.
+
+The generated skeleton header file (that is, `MyProcedurePort.hh`) will look as follows:
+
+[source]
+----
+// This Test Port skeleton header file was generated by the
+// TTCN-3 Compiler of the TTCN-3 Test Executor version 1.7.pre4 build 4
+// for Csaba Feher (ecsafeh@ehubuux110) on Tue Jul 29 18:53:35 2008
+
+// Copyright Ericsson Telecom AB 2000-2014
+
+// You may modify this file. Add your attributes and prototypes of your
+// member functions here.
+
+#ifndef MyProcedurePort_HH
+#define MyProcedurePort_HH
+
+#include "MyModule.hh"
+
+namespace MyModule {
+
+class MyProcedurePort : public MyProcedurePort_BASE {
+public:
+	MyProcedurePort(const char *par_port_name = NULL);
+	~MyProcedurePort();
+
+	void set_parameter(const char *parameter_name,
+		const char *parameter_value);
+
+private:
+	/* void Handle_Fd_Event(int fd, boolean is_readable,
+		boolean is_writable, boolean is_error); */
+	void Handle_Fd_Event_Error(int fd);
+	void Handle_Fd_Event_Writable(int fd);
+	void Handle_Fd_Event_Readable(int fd);
+	/* void Handle_Timeout(double time_since_last_call); */
+protected:
+	void user_map(const char *system_port);
+	void user_unmap(const char *system_port);
+
+	void user_start();
+	void user_stop();
+
+	void outgoing_call(const outProc_call& call_par);
+	void outgoing_call(const inoutProc_call& call_par);
+	void outgoing_reply(const inProc_reply& reply_par);
+	void outgoing_reply(const inoutProc_reply& reply_par);
+};
+
+} /* end of namespace */
+
+#endif
+----
+
+The generated skeleton source file for `MyProcedurePort` (that is, `MyProcedurePort.cc`) will be the following:
+[source]
+----
+// This Test Port skeleton source file was generated by the
+// TTCN-3 Compiler of the TTCN-3 Test Executor version 1.7.pre4 build 4
+// for Csaba Feher (ecsafeh@ehubuux110) on Tue Jul 29 18:53:35 2008
+
+// Copyright Ericsson Telecom AB 2000-2014
+
+// You may modify this file. Complete the body of empty functions and
+// add your member functions here.
+
+#include "MyProcedurePort.hh"
+
+namespace MyModule {
+
+MyProcedurePort::MyProcedurePort(const char *par_port_name)
+	: MyProcedurePort_BASE(par_port_name)
+{
+
+}
+
+MyProcedurePort::~MyProcedurePort()
+{
+
+}
+
+void MyProcedurePort::set_parameter(const char *parameter_name,
+	const char *parameter_value)
+{
+
+}
+
+/*void MyProcedurePort::Handle_Fd_Event(int fd, boolean is_readable,
+	boolean is_writable, boolean is_error) {}*/
+
+void MyProcedurePort::Handle_Fd_Event_Error(int fd)
+{
+
+}
+
+void MyProcedurePort::Handle_Fd_Event_Writable(int fd)
+{
+
+}
+
+void MyProcedurePort::Handle_Fd_Event_Readable(int fd)
+{
+
+}
+
+/*void MyProcedurePort::Handle_Timeout(double time_since_last_call) {}*/
+
+void MyProcedurePort::user_map(const char *system_port)
+{
+
+}
+
+void MyProcedurePort::user_unmap(const char *system_port)
+{
+
+}
+
+void MyProcedurePort::user_start()
+{
+
+}
+
+void MyProcedurePort::user_stop()
+{
+
+}
+
+void MyProcedurePort::outgoing_call(const outProc_call& call_par)
+{
+
+}
+
+void MyProcedurePort::outgoing_call(const inoutProc_call& call_par)
+{
+
+}
+
+void MyProcedurePort::outgoing_reply(const inProc_reply& reply_par)
+{
+
+}
+
+void MyProcedurePort::outgoing_reply(const inoutProc_reply& reply_par)
+{
+
+}
+
+} /* end of namespace */
+----
+
+[[test-port-functions]]
+== Test Port Functions
+
+This section summarizes all possible member functions of the Test Port class. All of these functions exist in the skeleton, but their bodies are empty.
+
+The identical functions of both port types are:
+
+* the constructor and the destructor
+
+* the parameter setting function
+
+* the map and unmap function
+
+* the start and stop function
+
+* descriptor event and timeout handler(s)
+
+* some additional functions and attributes
+
+The functions above will be described using an example of message based ports (`MyMessagePort`, also introducing the functions specific to message based port types). Using these functions is identical (or very similar) in procedure based Test Ports.
+
+Functions specific to message based ports:
+
+* send functions: outgoing send
+
+* incoming functions: incoming message
+
+* Functions specific to procedure based ports:
+
+* outgoing functions: outgoing call, outgoing reply, outgoing raise
+
+* incoming functions: incoming call, incoming reply, incoming exception
+
+Both test port types can use the same logging and error handling mechanism, and the handling of incoming operations on port `MyProcedurePort` is similar to receiving messages on port `MyMessagePort` (regarding the event handler).
+
+=== Constructor and Destructor
+
+The Test Port class belongs to a TTCN–3 port type, and its instances implement the functions of the port instances. That is, each Test Port instance belongs to the port of a TTCN–3 test component. The number of TTCN–3 component types, port types and port instances is not limited; you may have several Test Port classes and several instances of a given Test Port class in one test suite.
+
+The Test Port instances are global and static objects. This means, their constructor and destructor is called before and after the test execution (that is, before the main function starts and after the main function finishes). The name of a Test Port object is composed of the name of the corresponding component type and the name of the port instance within the component type.
+
+In case of parallel test execution, each TTCN–3 test component process has its own Test Port instances of all ports defined in all component types within the entire test suite. Of course, only the Test Ports of the active component type are used, the member functions of other inactive Test Port instances (except constructor and destructor) will never be called. Since all Test Port instances are static, their constructor and destructor is called only once on each host and in the Host Controller process (outside its main function). The test component processes (that is, the child processes of Host Controller) will get a copy of the initialized Test Port instances and no constructor will be called again.
+
+The Test Port class is derived from an abstract base class which can be found in the generated code. The base class implements, for instance, the queue of incoming messages.
+
+The constructor takes one parameter containing the name of the port instance in a NUL character terminated string. This string shall be passed further to the constructor of the base class as it can be found in the skeleton code. The default argument for the test port name is a NULL pointer, which is used when the test port object is a member of a port array.
+
+WARNING: In case of port arrays the name of the test port is set after the constructor is completed. So the name of the test port should not be used in the constructor. The port name is always set correctly when any other member function is called.
+
+The destructor does nothing by default. If some dynamically allocated attributes are added to the test port class, one should free the memory and release all resources in the destructor.
+
+WARNING: As the constructor and the destructor are called outside of main function, be careful when writing them. For instance, there is no way for error recovery; `exit(3)` call may result in a segmentation fault. If file descriptors are opened (and kept opened) here, the `fork(2)` system call of Host Controller will only multiply the file descriptors and not the kernel file structure. Therefore system and library calls should be avoided here.
+
+=== Parameter Setting Function
+
+Test Port parametersfootnote:[Test Port parameters have been introduced in version 1.1.pl3] shall contain information which is independent from the TTCN3 test suite. These values shall not be used in the test suite at all. You can define them as TTCN–3 constants or module parameters, but these definitions are useless and redundant, and they must always be present when the Test Port is used.
+
+For instance, using Test Port parameters can be used to convey configuration data (that is, some options or extra information that is necessary for correct operation) or lower protocol layer addresses (for example, IP addresses).
+
+Test Port parameters shall be specified by the user of executable tests in section `[TESTPORT_PARAMETERS]` of the run-time configuration file (see section `[TESTPORT_PARAMETERS]` in link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference]). The parameters are maintained for each test port instance separately; wildcards can be used as well. In the latter case the parameter is passed to all Test Port matching the wildcard.
+
+Each Test Port parameter must have a name, which must be unique within the Test Port only. The name must be a valid identifier, that is, it must begin with a letter and must contain alphanumerical characters only.
+
+All Test Port parameter values are interpreted by the test executor as character strings. Quotation marks must be used when specifying the parameter values in the configuration file. The interpretation of parameter values is up to you: you can use some of them as symbolic values, numbers, IP addresses or anything that you want.
+
+Before the test execution begins, all parameters belonging to the Test Port are passed to the Test Port by the runtime environment of the test executor using the function `set_parameter`. It is a virtual function, that is, this function may be removed from the header and source file if there are no parameters. Its default ancestor does nothing and ignores all parameters.
+
+Each parameter is passed to the Test Port one-by-one separatelyfootnote:[If the same parameter of the same port instance is specified several times in the configuration file, the function `set_parameter` will also be called several times.], the two arguments of `set_parameter` contain the name and value of the corresponding parameter, respectively, in NUL character terminated strings. If the parameter values are needed in further operations, backup copies must be made of them because the string will disappear after the calling function returns.
+
+It is warmly recommended that the Test Port parameter handling functions be fool-proof. For instance, the Test Port should produce a proper error message (for example by calling `TTCN_error`) if a mandatory parameter is missing instead of causing segmentation fault. Repeated setting of the same parameter should produce warnings for the user (for example by using the function `TTCN_warning`) and not memory leaks.
+
+NOTE: On the MTC, in both single and parallel modes, the handling of Test Port parameters is a bit different from that on PTCs. The parameters are passed only to active ports, but the component type of MTC (thus the set of active ports) depends on the `runs on` clause of the test case that is currently being executed. It would be difficult for the runtime environment to check at the beginning of each test case whether the corresponding MTC component type has already been active during a previous test case run. Therefore all Test Port parameters belonging to the active ports of the MTC are passed to the `set_parameter` function at the beginning of every test case. The Test Ports of MTC shall be prepared to receive the same parameters several times (with the same values, of course) if more than one test case is being executed.
+
+If system related Test Port parameters are used in the run-time configuration file (that is, the keyword `system` is used as component identifier), the parameters are passed to your Test Port during the execution of TTCN–3 `map` operations, but before calling your `user_map` function. Please note that in this case the port identifier of the configuration file refers to the port of the test system interface that your port is mapped to and not the name of your TTCN–3 port.
+
+The name and exact meaning of all supported parameters must be specified in the user documentation of the Test Port.
+
+=== Map and Unmap Functions
+
+The run-time environment of the TTCN–3 executor knows nothing about the communication towards SUT, thus, it is the user’s responsibility to establish and terminate the connection with SUT. The TTCN–3 language uses two operations to control these connections, `map` and `unmap`.
+
+For this purpose, the Test Port class provides two member functions, `user_map` and `user_unmap`. These functions are called by the test executor environment when performing TTCN–3 `map` and `unmap` operations, respectively.
+
+The `map` and `unmap` operations take two pairs of component references and ports as arguments. These operations are correct only if one of the arguments refer to a port of a TTCN–3 test component while the other port corresponds to SUT. This aspect of correctness is verified by the run-time environment, but the existence of a system port is not checked.
+
+The port names of the system are converted to `NUL` character terminated strings and passed to functions `user_map` and `user_unmap` as parameters. Unlike other identifiers, the underscore characters in these port names are not translated.
+
+If these system port names should be reused later, the entire strings (and not only the pointers) must be saved in the internal memory structures since the string values will disappear after the `user_map` or `user_unmap` finishes.
+
+NOTE: in TTCN–3 it is not allowed to map a test component port to several system ports at the same time. The run-time environment, however, is not so strict and allows this to handle transient states during configuration changes. In this case messages can not be sent to SUT even with explicit addressing, but the reception of messages is permitted. When putting messages into the input queue of the port, it is not important for the test executor (even for the TTCN–3 language) which port of the system the message is received from.
+
+The execution of TTCN–3 test component that requested the mapping or unmapping is suspended until your `user_map` or `user_unmap` functions finish. Therefore it is not allowed to block unnecessarily the test execution within these functions.
+
+When the Test Port detects an error situation during the establishment or termination of the physical connection towards the SUT, the function `TTCN_error` shall be used to indicate the failure. If the error occurs within `user_map` the run-time environment will assume that the connection with SUT is not established thus it will not call `user_unmap` to destroy the mapping during the error recovery procedure. If `user_map` fails, it is the Test Port writer’s responsibility to release all allocated resources and bring the object variables into a stable state before calling `TTCN_error`. Within `user_unmap` the errors should be handled in a more robust way. After a minor failure it is better to issue a warning and continue the connection termination instead of panicking. `TTCN_error` shall be called only to indicate critical errors. If `user_unmap` is interrupted with an error the run-time environment assumes that the mapping has been terminated, that is, `user_unmap` will not be called again.
+
+NOTE: if either `user_map` or `user_unmap` fails, the error is indicated on the initiator test component as well; that is, the respective map or `unmap` operation will also fail and error recovery procedure will start on that component.
+
+=== Start and Stop Functions
+
+The Test Port class has two member functions: `user_start` and `user_stop`. These functions are called when executing `port start` and `port stop` operations, respectively. The functions have no parameters and return types.
+
+These functions are called through a stub in the base class, which registers the current state of the port (whether it is started or not). So `user_start` will never be called twice without calling `user_stop` or vice versa.
+
+WARNING: From version 1.2.pl0 on (according to the latest TTCN–3 standard) all ports of test components are started implicitly immediately after creation. Such operations must not be put in a `user_start` function blocking the execution for a longer period. This not only hangs the new PTC but the also component that performed the `create` operation (usually the MTC). All ports are stopped at the end of test cases or at PTC termination, even if `stop` statements are missing.
+
+In functions `user_start` and `user_stop` the device should be initialized or shut down towards SUT (that is, the communications socket). Also the event handler should be installed or uninstalled (see later).
+
+=== Outgoing Operations
+
+Outgoing operations are `send` (specific to message based ports); `call`, `reply`, and `raise` (specific to procedure based ports).
+
+==== Send Functions
+
+The Test Port class has an overloaded function called `outgoing_send` for each outgoing message type. This function will be called when a message is sent on the port and it should be routed to the system (that is, SUT) according to the addressing semanticsfootnote:[That is, the port has exactly one mapping and either the port has no connections or the message is explicitly addressed by a `send (…) to system` statement.] of TTCN–3. The messages (implicitly or explicitly) addressed to other test components are handled inside the test executor; the Test Ports have nothing to do with them. The function `outgoing_send` will be also called if the port has neither connections nor mappings, but a message is sent on it.
+
+The only parameter of `outgoing_send` contains a read-only reference to the message in the internal data representation format of the test executor. The access methods for internal data types are described in <<4-encoding_and_decoding.adoc#xml-encoding-xer, XML Encoding (XER)>>. The test port writer should encode and send the message towards SUT. For information on how to use the standard encoding functions like BER, please consult <<3-logger_plug-ins.adoc, Logger Plug-ins>>. Sending a message on a not started port causes a dynamic test case error. In this case outgoing_send will not be called.
+
+==== Call, Reply and Raise Functions
+
+The procedure based Test Port class has overloaded functions called `outgoing_call`, `outgoing_reply` and `outgoing_raise` for each `call`, `reply` and `raise` operations, respectively. One of these functions will be called when a port-operation is addressing the system (that is, SUT using the to `system` statement).
+
+The only parameter of these functions is an internal representation of the signature parameters (and possibly its return value) or the exceptions it may raise. The signature classes are described in <<5-mapping_ttcn3_data_types_to_c++_constructs.adoc#using-the-signature-classes,Using the Signature Classes>>.
+
+=== Incoming Operations
+
+Incoming operations are `receive` incoming messages (specific to message based ports); `call`, `reply` and `exception` (specific to procedure based ports).
+
+==== Descriptor Event and Timeout Handlers
+
+The handling of incoming messages (or operations) is more difficult than sending. The executable test program has two states. In the first state, it executes the operations one by one as specified in the test suite (for example, it evaluates expressions, calls functions, sends messages, etc.). In the other state it waits for the response from SUT or for a timer to expire. This happens when the execution reaches a blocking statement, that is, one of a stand-alone `receive`, `done`, `timeout` statements or an `alt` construct.
+
+After reaching a blocking statement, the test executor evaluates the current snapshot of its timer and port queues and tries to match it with the reached statements and templates. If the matching fails, the executor sleeps until something happens to its timers or ports. After waking up, it re-evaluates its snapshot and tries to match it again. The last two steps are repeated until the executor finds the first matching statement. If the test executor realizes that its snapshot can never match the reached TTCN–3 statements, it causes a dynamic test case error. This mechanism prevents it from infinite blocking.
+
+The test executor handles its timers itself, but it does not know anything about the communication with SUT. So each Test Port instance should inform the snapshot handler of the executor what kind of event the Test Port is waiting for. The event can be either the reception of data on one or more file descriptors or a timeout (when polling is used) or both of them.
+
+When the test executor reaches a blocking statement and any condition – for which the Test Port waits – is fulfilled, the event handler will be called. First one has to get the incoming message or operation from the operating system. After that, one has to decode it (and possibly decide its type). Finally, if the internal data structure is built, one has to put it into the queue of the port. This can be done using the member function `incoming_message` if it is a message, and using `incoming_call`, `incoming_reply` or `incoming_exception` if it is an operation.
+
+The execution must not be blocked in event handler functions; these must return immediately when the message or operation processing is ready. In other words, always use non-blocking `recv()` system calls. In the case when the messages are fragmented (for instance, when testing TCP based application layer protocols, such as HTTP), intermediate buffering should be performed in the Test Port class.
+
+===== Event and timeout handling interface introduced in TITAN version 1.7.pl4
+
+This descriptor event and timeout handling interface is the preferred interface for new Test Port development.
+
+There are two possibilities to be notified about available events:
+
+* Either the `Handle_Fd_Event` function has to be implemented, or
+
+* `Handle_Fd_Event_Readable`, `Handle_Fd_Event_Writable`, and `Handle_Fd_Event_Error`.
+
+Using `Handle_Fd_Event` allows receiving all events of a descripor in one function call. Using the other three event handler functions allows creating a more structured code.
+
+All these functions are virtual. The unused event handler functions have to be left un-overridden. (When using the second alternative and the Test Port does not wait for all types of events (readable, writable, error) the handlers of the events – for which the Test Port does not wait – can be left un-overridden.)
+
+The following functions can be used to add events to and remove events from the set of events for which the Test Port waits:
+[source]
+----
+void Handler_Add_Fd(int fd, Fd_Event_Type event_mask = EVENT_ALL);
+void Handler_Add_Fd_Read(int fd);
+void Handler_Add_Fd_Write(int fd);
+void Handler_Remove_Fd(int fd, Fd_Event_Type event_mask = EVENT_ALL);
+void Handler_Remove_Fd_Read(int fd);
+void Handler_Remove_Fd_Write(int fd);
+----
+
+The first parameter in all of these functions is the file descriptor. Possible values of the `event_mask` are `EVENT_RD`, `EVENT_WR`, `EVENT_ERR` and combinations of these using bitwise or: "|".
+
+Timeout notification can be received with the `Handle_Timeout` function. The parameter of the function indicates the time elapsed in seconds since its last call of this function or the latest modification of the timer (whichever occurred later).
+
+The timer can be set with the following function:
+[source, subs="+quotes"]
+void Handler_Set_Timer(double call_interval, boolean is_timeout = TRUE,
+    boolean call_anyway = TRUE, boolean is_periodic = TRUE);
+
+`call_interval` is measured in seconds and specifies the time after which the `Handle_Timeout` function will be called. To stop the timer `call_interval` value: 0.0 has to be given.
+
+`is_timeout` specifies if the timer has to be stopped when event handler is called. `call_anyway` is meaningful when `is_timeout` is set to `TRUE`. In this case `call_anyway` indicates if the `Handle_Timeout` function has to be called when event handler is called before the timer would expire. If `call_anyway` is `TRUE` the timeout handler will be called after the call of the event handlers and the timer will be stopped. `is_periodic` indicates if the timer has to be restarted instead of stopping when timer expires or event handler is called and `is_timeout` and `call_anyway` are both `TRUE`.
+
+===== Event handler for Test Ports developed for 1.7pl3 and earlier versions of TITAN
+
+There is only one event handler function in each Test Port class called `Event_Handler`, which is a virtual member function. The run-time environment calls it when an incoming event arrives. You can install or uninstall the event handler by calling the following inherited member functions:
+[source, subs="+quotes"]
+void Install_Handler(const fd_set *read_fds, const fd_set *write_fds,
+                     const fd_set *error_fds, double call_interval);
+void Uninstall_Handler();
+
+`Install_Handler` installs the event handler according to its parameters. It takes four arguments, three pointers pointing to bitmasks of file descriptors and a timeout value. Some of the parameters can be ignored, but ignoring all at the same time is not permitted.
+
+The bitmasks are interpreted in the same way as in the select system call. They can be set using the macros `FD_ZERO`, `FD_SET` and `FD_CLR`. If the pointer is NULL, the bitmask is treated as zero. For further details see the manual page of `select(2)` or `select(3)`.
+
+The call interval value is measured in seconds. It means that the event handler function will be called when the time elapsed since its last call reaches the given value. This parameter is ignored when its value is set to zero or negative.
+
+If you want to change your event mask parameters, you may simply call the function `Install_Handler` again (calling of `Uninstall_Handler` is not necessary).
+
+`Uninstall_Handler` will uninstall your previously installed event handler. The `stop` port operation also uninstalls the event handler automatically. The event handler may be installed or uninstalled in any Test Port member function, even in the event handler itself.
+
+The prototype of the event handler function is the following:
+[source, subs="+quotes"]
+void Event_Handler(const fd_set *r_fds, const fd_set *w_fds,
+                   const fd_set *e_fds, double time_since_last_call);
+
+The function `Event_Handler` has four parameters. The first three of them are pointers to bitmasks of file descriptors as described above. They are the bitwise AND combination of bitmasks you have given to `Install_Handler` and the bitmasks given back by the last call of select. They can be useful when waiting for data from many file descriptors, for example when handling more than one SUT mappings simultaneously, because there is no need to issue a select call again within the event handler. +
+
+NOTE: the pointers can be never NULL, they point to a valid memory area even if there are no file descriptors set in the bitmask. The last parameter contains the time elapsed since the last call of the event handler measured in seconds. This value is always calculated even if the call interval has not been set. If the `Event_Handler` is called the first time since its last installation, the time is measured from the call of `Install_Handler`.footnote:[In versions of Test Executor older than 1.1 the event handler function had no parameters. If you want to upgrade a test port developed for older versions, you should insert this formal parameter list to your event handler both in Test Port header and source file. Otherwise the compilation of Test Port will fail.]
+
+==== Receiving messages
+
+The member function `incoming_message` of message based ports can be used to put an incoming message in the queue of the port. There are different polymorphic functions for each incoming message type. These functions are inherited from the base class. The received messages are logged when they are put into the queue and not when they are processed by the test suitefootnote:[Note that if the port has connections as well, the messages coming from other test components will also be inserted into the same queue independently from the event handler.].
+
+In our example the class `MyMessagePort_BASE` has the following member functions:
+[source, subs="+quotes"]
+incoming_message(const OCTETSTRING& incoming_par);
+incoming_message(const CHARSTRING& incoming_par);
+
+==== Receiving calls, replies and exceptions
+
+Receiving operations on procedure based ports is similar to receiving messages on message based ports. The difference is that there are different overloaded incoming functions for call, reply and raise operations called `incoming_call`, `incoming_reply` and `incoming_exception`, respectively. The event handler (when called) must recognize the type of operation on receiving and call one of these functions accordingly with one of the internal representations of the signature (see <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc #additional-non-standard-functions, Additional Non-Standard Functions>>).
+
+In the examplefootnote:[In the example the signatures were defined in a different TTCN–3 module named MyModule2, as a consequence all types defined in that module must be prefixed with the C++ namespace name of that module.] the class `MyProcedurePort_BASE` has the following member functions for incoming operations:
+[source]
+----
+incoming_call(const MyModule2::inProc_call& incoming_par);
+incoming_call(const MyModule2::inoutProc_call& incoming_par);
+incoming_reply(const MyModule2::outProc_reply& incoming_par);
+incoming_reply(const MyModule2::inoutProc_reply& incoming_par);
+incoming_exception(const MyModule2::outProc_exception& incoming_par);
+incoming_exception(const MyModule2::inoutProc_exception& incoming_par);
+----
+For example, if the event handler receives a call operation that refers to the signature called `inoutProc`, it has to fill the parameters of an instance of the class `inoutProc_call` with the received data. Then it has to call the function `incoming_call` with this object to place the operation into the queue of the port.
+
+The following table shows the relation between the direction of the message type or signature in the port type definition and the incoming/outgoing functions that can be used. `MyPort` in the table header refers to `MyMessagePort` or `MyProcedurePort` in the example depending on the type of the port (message based or procedure based).
+
+.Outgoing and incoming operations
+
+[cols=" ",options="header",]
+|===
+| | 4+^.^|`MyPort::outgoing_` 4+^.^| `MyPort BASE::incoming_`
+| | |send |call |reply |raise |message |call |reply |exception
+.3+^.^|message type |in |○ |○ |○ |○ |● |○ |○ |○
+|out |● |○ |○ |○ |○ |○ |○ |○
+|inout |● |○ |○ |○ |● |○ |○ |○
+.3+^.^|signature |in |○ |○ |● |● |○ |● |○ |○
+|out |○ |● |○ |○ |○ |○ |● |●
+|inout |○ |● |● |● |○ |● |● |●
+|===
+
+● supported
+
+â—‹ not supported
+
+=== Additional Functions and Attributes
+
+Any kind of attributes or member functions may be added to the Test Port. A file descriptor, which you communicate on, is almost always necessary. Names not interfering with the identifiers generated by the Compiler can be used in the header file (for example, the names containing one underscore character). Avoid using global variables because you may get confused when more than one instances of the Test Port run simultaneously. Any kind of software libraries may be used in the Test Port as well, but included foreign header files may cause name clashes between the library and the generated code.
+
+In addition, the following `protected` attributes of ancestor classes are available:
+
+.Protected attributes
+
+[width="100%",cols="34%,33%,33%",options="header",]
+|======================================================================================================
+|Name ^.^|Type |Meaning
+|`is_started` ^.^|boolean |Indicates whether the Test Port is started.
+|`handler_installed` ^.^|boolean |Indicates whether the event handler is installed.
+|`port_name` ^.^|const char* |Contains the name of the Test Port instance. (NUL character terminated string)
+|======================================================================================================
+
+Underscore characters are not duplicated in port name. In case of port array member instances the name string looks like this: `"Myport_array[5]"`.
+
+== Support of `address` Type
+
+The special user-defined TTCN–3 type `address` can be used for addressing entities inside the SUT on ports mapped to the `system` component. Since the majority of Test Ports does not need TTCN–3 addressing and in order to keep the Test Port API backward compatible the support of `address` type is disabled by default. To enable addressing on a particular port type the extension attribute `"address"` must be added to the TTCN–3 port type definition. In addition to component references this extension will allow the usage `address` values or variables in the `to` or `from` clauses and `sender` redirects of port operations.
+
+In order to use addressing, a type named `address` shall be defined in the same TTCN–3 module as the corresponding port type. Address types defined in other modules of the test suite do not affect the operation of the port type. It is possible to link several Test Ports that use different types for addressing SUT into the same executable test suite.
+
+Test Ports that support SUT addressing have a slightly different API, which is considered when generating Test Port skeleton. This section summarizes only the differences from the normal API.
+
+In the communication operations the test port author is responsible for handling the address information associated with the message or the operation. In case of an incoming message or operation the value of the received address will be stored in the port queue together with the received message or operation.
+
+The generated code for the port skeleton of message based ports will be the same, except `outgoing_send` member function, which has an extra parameter pointing to an `ADDRESS` value. With the example given in <<test-port-functions, Test Port Functions>>:
+[source]
+----
+void outgoing_send(const INTEGER& send_par,
+                   const ADDRESS *destination_address);
+void outgoing_send(const CHARSTRING& send_par,
+                   const ADDRESS *destination_address);
+----
+
+If an `address` value was specified in the `to` clause of the corresponding TTCN–3 `send` operation the second argument of `outgoing_send` points to that value. Otherwise it is set to the `NULL` pointer. The Test Port code shall be prepared to handle both cases.
+
+The outgoing operations of procedure based ports are also generated in the same way if the `address` extension is specified. These functions will also have an extra parameter. Based on our example, these will have the following form:
+[source]
+----
+void outgoing_call(const MyModule2::outProc_call& call_par,
+                   const ADDRESS *destination_address);
+void outgoing_call(const MyModule2::inoutProc_call& call_par,
+                   const ADDRESS *destination_address);
+void outgoing_reply(const MyModule2::inProc_reply& reply_par,
+                    const ADDRESS *destination_address);
+void outgoing_reply(const MyModule2::inoutProc_reply& reply_par,
+                    const ADDRESS *destination_address);
+void outgoing_raise(const MyModule2::inProc_exception& raise_exception,
+                    const ADDRESS *destination_address);
+void outgoing_raise(const MyModule2::inoutProc_exception& raise_exception,
+                    const ADDRESS *destination_address);
+----
+
+The other difference is in the `incoming_message` member function of class `MyMessagePort_BASE`, and in the incoming member functions of class `MyProcedurePort_BASE`. These have an extra parameter, which is a pointer to an `ADDRESS` value. The default value is set the NULL pointer. In our example of `MyMessagePort_BASE`:
+[source]
+----
+void incoming_call(const MyModule2::inProc_call& incoming_par,
+                   const ADDRESS *sender_address = NULL);
+void incoming_call(const MyModule2::inoutProc_call& incoming_par,
+                   const ADDRESS *sender_address = NULL);
+void incoming_reply(const MyModule2::outProc_reply& incoming_par,
+                    const ADDRESS *sender_address = NULL);
+void incoming_reply(const MyModule2::inoutProc_reply& incoming_par,
+                    const ADDRESS *sender_address = NULL);
+void incoming_exception(const MyModule2::outProc_exception& incoming_par,
+                        const ADDRESS *sender_address = NULL);
+void incoming_exception(const MyModule2::inoutProc_exception& incoming_par,
+                        const ADDRESS *sender_address = NULL);
+----
+
+If the event handler of the Test Port can determine the source address where the message or the operation is coming from, it shall pass a pointer to the incoming function, which points to a variable that stores the `address` value. The given address value is not modified by the run-time environment and a copy of it is created when the message or the operation is appended to the port queue. If the event handler is unable to determine the sender address the default `NULL` pointer shall be passed as second argument.
+
+The address value stored in the port queue is used in `receive`, `trigger`, `getcall`, `getreply`, `catch` and `check` port operations: it is matched with the `from` clause and/or stored into the variable given in the `sender` redirect. If the receiving operation wants to use the address information of the first element in the port queue, but the Test Port has not supplied it a dynamic testcase error will occur.
+
+== Provider Port Types
+
+Test Ports that belong to port types marked with `extension` attribute `"provider"` have a slightly different API. Such port types are used to realize dual-faced ports, the details of which can be found in section "Dual-faced ports" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference].
+
+The purpose of this API is to allow the re-use of the Test Port class with other port types marked with attribute `user` or with ports with translation capability (link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.04.01_60/es_202781v010401p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support]). The user port types may have different lists of incoming and outgoing message types. The transformations between incoming and outgoing messages, which are specified entirely by the attribute of the user port type, are done independently of the Test Port. The Test Port needs to support the sending and reception of message types that are listed in the provider port type.
+
+The provider port can be accessed through the port which maps to the port with provider attribute. The `get_provider_port()` is a member function of the PORT class:
+[source, subs="+quotes"]
+PORT* get_provider_port();
+
+This function is useful when a reference to the provider type is needed. It returns the provider port type for user ports and ports with translation capability. Otherwise returns NULL. The function causes dynamic testcase error when the port has more than one mapping, or the port has both mappings and connections. The function’s return value must be manually cast to the correct provider port type.
+
+This section summarizes only the differences from the normal Test Port API:
+
+* The name of the Test Port class is suffixed with the string `_PROVIDER` (for example `MyMessagePort_PROVIDER` instead of `MyMessagePort`).
+
+* The base class of the Test Port is class `PORT`, which is part of the Base Library. Please note that normal Test Ports are also derived from class PORT, but indirectly through an intermediate class with suffix `_BASE`.
+
+* The member functions that handle incoming messages and procedure-based operations (that is `incoming_message`, `incoming_call`, `incoming_reply` and `incoming_exception`) must be defined in the header file as pure virtual functions. These functions will be implemented in various descendant classes differently.
+
+* The Test Port header file must not include the generated header file of the corresponding TTCN–3 module. The common header file of the Base Library called TTCN3.hh shall be included instead. The source file of the Test Port may include any header file without restriction.
+
+* The member functions of the Test Port may refer to C++ classes that are generated from user-defined message types and signatures. To avoid compilation failures the declarations of the referenced classes must be added to the beginning of the header file. At the moment the Test Port skeleton generator has a limitation that it cannot collect the class declarations from the port type, so they must be added manually. Please note that if a message type or signature is imported from another module the corresponding class declaration must be put into the appropriate namespace.
+
+The following example shows the generated Test Port skeleton of a provider port type.
+
+Port type definition in TTCN–3 :
+[source]
+----
+type port MyProviderPort mixed {
+  inout MyMessage, MySignature;
+} with { extension "provider" }
+----
+
+Header file `MyMessagePort.hh`:
+[source]
+----
+// This Test Port skeleton header file was generated by the
+// TTCN-3 Compiler of the TTCN-3 Test Executor version 1.7.pl0
+// for Janos Zoltan Szabo (ejnosza@EG70E00202E46JR)
+// on Wed Mar 7 18:14:33 2007
+
+
+// Copyright Ericsson Telecom AB 2000-2014
+
+// You may modify this file. Add your attributes and prototypes of your
+// member functions here.
+
+
+#ifndef MyProviderPort_HH
+#define MyProviderPort_HH
+
+
+#include <TTCN3.hh>
+
+// Note: Header file MyModule.hh must not be included into this file!
+// Class declarations were added manually
+
+namespace MyOtherModule {
+  // type MyMessageType was imported from MyOtherModule
+  class MyMessageType;
+}
+
+namespace MyModule {
+
+// signature MySignature was defined locally
+class MySignature_call;
+class MySignature_reply;
+class MySignature_exception;
+class MyProviderPort_PROVIDER : public PORT {
+public:
+  MyProviderPort_PROVIDER(const char *par_port_name = NULL);
+  ~MyProviderPort_PROVIDER();
+
+  void set_parameter(const char *parameter_name,
+    const char *parameter_value);
+
+  void Event_Handler(const fd_set *read_fds,
+    const fd_set *write_fds, const fd_set *error_fds,
+    double time_since_last_call);
+
+protected:
+  void user_map(const char *system_port);
+  void user_unmap(const char *system_port);
+
+  void user_start();
+  void user_stop();
+
+  void outgoing_send(const MyOtherModule::MyMessage& send_par);
+  void outgoing_call(const MySignature_call& call_par);
+  void outgoing_reply(const MySignature_reply& reply_par);
+  void outgoing_raise(const MySignature_exception& raise_exception);
+  virtual void incoming_message(
+    const MyOtherModule::MyMessage& incoming_par) = 0;
+  virtual void incoming_call(const MySignature_call& incoming_par) = 0;
+  virtual void incoming_reply(const MySignature_reply& incoming_par) = 0;
+  virtual void incoming_exception(
+    const MySignature_exception& incoming_par) = 0;
+};
+
+} /* end of namespace */
+----
+
+Source file `MyMessagePort.cc`:
+[source]
+----
+// This Test Port skeleton source file was generated by the
+// TTCN-3 Compiler of the TTCN-3 Test Executor version 1.7.pl0
+// for Janos Zoltan Szabo (ejnosza@EG70E00202E46JR)
+// on Wed Mar 7 18:14:33 2007
+// Copyright Ericsson Telecom AB 2000-2014
+// You may modify this file. Complete the body of empty functions and
+// add your member functions here.
+
+#include "MyProviderPort.hh"
+#include "MyModule.hh"
+
+namespace MyModule {
+
+MyProviderPort_PROVIDER::MyProviderPort_PROVIDER(const char *par_port_name)
+  : PORT(par_port_name)
+{
+}
+
+MyProviderPort_PROVIDER::~MyProviderPort_PROVIDER()
+{
+}
+
+void MyProviderPort_PROVIDER::set_parameter(const char *parameter_name,
+  const char *parameter_value)
+{
+}
+
+void MyProviderPort_PROVIDER::Event_Handler(const fd_set *read_fds,
+  const fd_set *write_fds, const fd_set *error_fds,
+  double time_since_last_call)
+{
+}
+
+void MyProviderPort_PROVIDER::user_map(const char *system_port)
+{
+}
+
+void MyProviderPort_PROVIDER::user_unmap(const char *system_port)
+{
+}
+
+void MyProviderPort_PROVIDER::user_start()
+{
+}
+
+void MyProviderPort_PROVIDER::user_stop()
+{
+}
+
+void MyProviderPort_PROVIDER::outgoing_send(
+  const MyOtherModule::MyMessage& send_par)
+{
+}
+
+void MyProviderPort_PROVIDER::outgoing_call(
+  const MySignature_call& call_par)
+{
+}
+
+void MyProviderPort_PROVIDER::outgoing_reply(
+  const MySignature_reply& reply_par)
+{
+}
+
+void MyProviderPort_PROVIDER::outgoing_raise(
+  const MySignature_exception& raise_exception)
+{
+}
+
+} /* end of namespace */
+----
+
+== Tips and Tricks
+
+The following sections deal with logging and error handling in Test Ports.
+
+=== Logging
+
+Test Ports may record important events in the Test Executor log during sending/receiving or encoding/decoding messages. Such log messages are also good for debugging fresh code.
+
+The Test Port member functions may call the functions of class `TTCN_Logger`. These functions are detailed in <<6-tips_&_troubleshooting.adoc#logging-in-test-ports-or-external-functions, Logging in Test Ports or External Functions>>.
+
+If there are many points in the Test Port code that want to log something, it can be a good practice to write a common log function in the Test Port class. We show here an example function, which takes its arguments as the standard C function `printf` and forwards the message to the Test Executor’s logger:
+
+[source]
+----
+#include <stdarg.h>
+// using in other member functions:
+// log("The value of i: %d", i);
+void MyPortType::log(const char *fmt, ...)
+{
+  // this flag can be a class member, which is configured through a
+  // test port parameter
+  if (logging_is_enabled) {
+    va_list ap;
+    va_start(ap, fmt);
+    TTCN_Logger::begin_event(TTCN_DEBUG);
+    TTCN_Logger::log_event("Example Test Port (%s): ", get_name());
+    TTCN_Logger::log_event_va_list(fmt, ap);
+    TTCN_Logger::end_event();
+    va_end(ap);
+  }
+}
+----
+
+=== Error Handling
+
+None of the Test Port member functions have return value like a status code. If a function returns normally, the run-time environment assumes that it has performed its task successfully. The handling of run-time errors is done in a special way, using C++ exceptions. This simplifies the program code because the return values do not have to be checked everywhere and dynamically created complex error messages can be used if necessary.
+
+If any kind of fatal error is encountered anywhere in the Test Port, the following function should be called:
+[source, subs="+quotes"]
+void TTCN_error(const char *err_msg, …);
+
+Its parameter should contain the description of the error in a `NUL` terminated string in the format of `printf(3)`. You may pass further parameters to `TTCN_error`, if necessary. The function throws an exception, so it never returns. The exception is usually caught at the end of the test case or PTC function that is being executed. In case of error, the verdict of the component is set to `error` and the execution of the test case or PTC function terminates immediately.
+
+The exception class is called `TC_Error`. For performance reasons this is a trivial (empty) class, that is, it does not contain the error message in a string. The error string is written into the log file by `TTCN_error` immediately. Such type of exception should never be caught or thrown directly. If you want to implement your own error handling and error recovery routines you had better use your own classes as exceptions.
+
+If you write your own error reporting function you can add automatically the name of the port instance to all of your error messages. This makes the fault analysis for the end-users easier. In the following example the error message will occupy two consecutive lines in the log since we can pass only one format string to `TTCN_error`.
+[source]
+----
+void MyPortType::error(const char *msg, ...)
+{
+  va_list ap;
+  va_start(ap, msg);
+  TTCN_Logger::begin_event(TTCN_ERROR);
+  TTCN_Logger::log_event("Example Test Port (%s): ", get_name());
+  TTCN_Logger::log_event_va_list(msg, ap);
+  TTCN_Logger::end_event();
+  va_end(ap);
+  TTCN_error("Fatal error in Example Test Port %s (see above).",
+    get_name());
+}
+----
+
+There is another function for denoting warnings (that is, events that are not so critical) with the same parameter list as TTCN_error:
+[source, subs="+quotes"]
+void TTCN_warning(const char *warning_msg, …);
+
+This function puts an entry in the executor’s log with severity `TTCN_WARNING`. In contrast to `TTCN_error`, after logging the given message `TTCN_warning` returns and your test port can continue running.
diff --git a/usrguide/apiguide/3-logger_plug-ins.adoc b/usrguide/apiguide/3-logger_plug-ins.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..ac1fab3ac47d0aebea0b2761f9308b1a49352afa
--- /dev/null
+++ b/usrguide/apiguide/3-logger_plug-ins.adoc
@@ -0,0 +1,87 @@
+= Logger Plug-ins
+:toc:
+
+== Implementing Logger Plug-ins
+
+All logger plug-ins must implement the `ILoggerPlugin` interface class in `ILoggerPlugin.hh` in `${TTCN3_DIR}/include`. Each plug-in should provide some essential information on itself and should implement some basic functions:
+
+The name `(name_, plugin_name())` of the plugin. To be able to reference the plugin (for example for configuration). Additional information about the plug-in `(help_, plugin_help())`.
+
+The minimum API version number the plug-in is compatible with `(major_version_, major_version()`, `minor_version_, minor_version())`.
+
+Each plug-in must have an initialization `(init())` and deinitialization `(fini())` routine, which are called at the begin and end of the plug-in’s lifecycle. The same functionality can be implemented in the plug-in’s constructor and destructor as well.
+
+The plug-in could be asked, whether it’s configured or not `(is_configured())`. For example the file is already opened, the database connection is set up etc. Depending on this information event buffering can be enabled or disabled.
+
+One plug-in should provide `log2str()` functionality. The `is_log2str_capable()` function should be overridden to return true. At the moment it’s not possible to change the default behavior and returning true will not have an effect except a warning.
+
+The logger plug-ins receive the log events via the `log()` function. The details about event handling can be found in 3.3.
+
+The generated, runtime specific (load-test or function-test) header file `TitanLoggerApi.hh` needs to be included by every logger plug-in depending on the runtime it is compiled for. These header files can be found in `${TTCN3_DIR}/include/{RT1/RT2}`. An example to handle these include files in a logger plug-in’s code:
+[source]
+----
+#ifndef TITAN_RUNTIME_2
+
+#include ``RT1/TitanLoggerApi.hh''
+
+#else
+
+#include ``RT2/TitanLoggerApi.hh''
+
+#endif
+----
+Unfortunately, the `dlopen()` API is a C API, not a C\++ API, but each logger plug-in is a class, which needs to be instantiated. To resolve this, the logger plug-ins are always instantiated and destroyed through C factory functions. These functions are mandatory for all logger plug-ins and they must follow C-style linkage rules. Otherwise, the function names would be mangled by the C++ compiler, using its own, implementation dependent mangling mechanism, and `dlsym()` and such functions would not be able to locate the correct symbol in the SOs of the logger plug-ins. These functions look pretty simple:
+[source]
+----
+#ifdef __cplusplus
+extern "C"
+{
+  ILoggerPlugin *create_plugin()
+    { return new MyPlugin(); }
+  void destroy_plugin(ILoggerPlugin *plugin)
+    { delete plugin; plugin = NULL; }
+}
+#endif
+----
+
+== Building Logger Plug-ins
+
+The generated, runtime specific (load-test or function-test) header file `TitanLoggerApi.hh` needs to be included by every logger plug-in depending on the runtime it is compiled for. These header files can be found in `${TTCN3_DIR}/include/{RT1/RT2}` and this directory must be present (for example as part of `CPPFLAGS` in the `Makefile`) while compiling the logger plug-ins.
+
+To make logger plug-ins dynamically loadable at runtime the logger plug-ins need to be built as shared libraries. Physically SOs `(.so)` on Unix and Linux platforms, DLLs `(.dll)` on Cygwin and Windows platforms. A HOWTO on building shared libraries can be found at http://tldp.org/HOWTO/Program-Library-HOWTO/index.html[David A. Wheeler, Program Library HOWTO]. A quick summary:
+
+All the sources of the logger plug-ins need to be compiled with `–fPIC`, for example add `CXXFLAGS += -fPIC` into the `Makefile` or command line.
+
+The linker should be instructed to create a shared library instead of an executable with the `–shared` flag. `–fPIC` is necessary here as well, for example add `LDFLAGS += -fPIC –shared` in the `Makefile` or command line.
+
+Another thing to keep in mind is that logger plug-ins need to be linked with the dynamically linked TITAN runtime libraries (for example `libttcn3-dynamic.so/libttcn3-parallel-dynamic.so` or `libttcn3-rt2-dynamic.so/libttcn3-rt2-parallel-dynamic.so`) instead of the static ones (for example `libttcn3.a/libttcn3-parallel.a` or `libttcn3-rt2.a/libttcn3-rt2-parallel.a`). So, if all possible combinations need to be supported by a logger plug-in, all of the four versions need to be built, additionally there are naming rules to simplify making a distinction between them:
+
+* Single mode, load test runtime. File name must end with ".so".
+
+* Single mode, function test runtime. File name must end with "-rt2.so".
+
+* Parallel mode, load test runtime. File name must end with "-parallel.so".
+
+* Parallel mode, function test runtime. File name must end with "-parallel-rt2.so".
+
+The runtime library linked with a logger plug-in must be selected to match the runtime linked with the test executable that loads it: if the test executable is linked to `libttcn3-dynamic.so`, then any logger plug-ins must also be linked to `libttcn3-dynamic.so` and not `libttcn3-parallel-dynamic.so` or `libttcn3-rt2-dynamic.so`. To ensure consistency, only a dynamic runtime library will load a logger plug-in (because a plug-in is always linked to a dynamic runtime library). If a non-dynamic runtime library is configured to load a logger plug-in, it will cause a runtime error.
+
+Please note that linking a plug-in or any TTCN-3 project with the object files generated from the `TitanLoggerApi` or `TitanLoggerControl` internal modules and using the dynamic libraries of TITAN at the same time is not recommended and it can lead to various runtime errors.
+
+== Event Handling
+
+The log events are distributed to all active logger plug-ins via a four-parameter callback function with the following signature:
+[source]
+----
+void log(const TitanLoggerApi::TitanLogEvent& event, bool
+  log_buffered, bool separate_file, bool use_emergency_mask);
+----
+
+The first parameter event is the event itself, the second parameter `log_buffered` indicates, whether the event is coming from an internal buffer or not, `separate_file` and `use_emergency_mask` are configuration options for emergency logging. The `use_emergency_mask` flag indicates that the given event is an emergency event and should be handled in a special way by the plug-ins, the `separate_file` flag indicates that all the emergency events should be handled separately (for example written into a separate file). For more details on emergency logging please check link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference]. In this function, the plug-in can handle the log events individually depending on the event’s type (that is, the alternative selected in the union `event.logEvent().choice()).`
+
+`TitanLoggerApi::TitanLogEvent` is a generated type defined in TitanLoggerApi.xsd, which can be found in `${TTCN3_DIR}/include`. This file contains all the necessary type definitions a logger plug-in should be aware of. The corresponding header files generated from this XSD file can be found in `${TTCN3_DIR}/include/{RT1/RT2}`. The mapping between TTCN-3 types and C\++ types is defined in link:5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc[Mapping TTCN–3 Data Types to C++ Constructs].
+//The mapping between XSD and TTCN-3 types is defined in *Error! Reference source not found.*
+
+== Execution
+
+When a logger plug-in is compiled (the SO is ready) it should be configured in the configuration file. For details check link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference]. Additionally, `LD_LIBRARY_PATH` should contain the directory of the plug-in and `${TTCN3_DIR}/lib` as well. If the runtime linker (the loader) is unable to find any of the given logger plug-ins an error will be given.
diff --git a/usrguide/apiguide/4-encoding_and_decoding.adoc b/usrguide/apiguide/4-encoding_and_decoding.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..eb2e664fcdeb36bb3dc011541f37c29eaa7813a7
--- /dev/null
+++ b/usrguide/apiguide/4-encoding_and_decoding.adoc
@@ -0,0 +1,804 @@
+= Encoding and Decoding
+
+:table-number: 2
+:toc:
+
+This tool is equipped with several standard encoding/decoding mechanisms. A part of these functions reside in the core library, but the type-dependent part must be generated by the compiler. In order to reduce the code size and compilation time, the code generation for encoding functions (separately for different encoders) can be switched off if they are not needed. For details, see section "Command line syntax" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference].
+
+To make it easier to use the encoding features, a unified common API was developed. With help of this API the behaviour of the test executor in different error situations can be set during coding. There is also a common buffer class. The details of the above mentioned API as well as the specific features of the certain encoders are explained in the following sections.
+
+[[the-common-API]]
+== The Common API
+
+The common API for encoders consists of three main parts:
+
+* A dummy class named `TTCN_EncDec` which encapsulates functions regarding error handling.
+
+* A buffer class named `TTCN_Buffer` which is used by the encoders to put data in, decoders to get data from.
+
+* The functions needed to encode and decode values.
+
+[[ttcn-encdec]]
+=== TTCN_EncDec
+
+`TTCN_EncDec` implements error handling functions.
+
+==== Setting Error Behavior
+
+There are lot of error situations during encoding and decoding. The coding functions can be told what to do if an error arises. To set the behaviour of test executor in a certain error situation the following function is to be invoked:
+[source, subs="+quotes"]
+void TTCN_EncDec::set_error_behavior(error_type_t, error_behavior_t);
+
+WARNING: As error_type_t and error_behavior_t are enums defined in TTCN_EncDec class, they have to prefixed with the class name and the scope operator (that is `TTCN_EncDec::`).
+
+The possible values of `error_type_t` are detailed in the sections describing the different codings. Some common error types are shown in the table below:
+
+.Common error types
+[width="100%",cols="30%,70%",options="header",]
+|=========================================================================================
+|ET_UNDEF |Undefined/unknown error.
+|ET_UNBOUND |Encoding of an unbound value.
+|ET_REPR |Representation error (for example, internal representation of integral numbers).
+|ET_ENC_ENUM |Encoding of an unknown enumerated value.
+|ET_DEC_ENUM |Decoding of an unknown enumerated value.
+|ET_INCOMPL_MSG |Decode error: incomplete message.
+|ET_INVAL MSG |Decode error: invalid message.
+|ET_CONSTRAINT |The value breaks some constraint.
+|ET_INTERNAL |Internal error. Error behaviour cannot be set for this.
+|ET_ALL |All error type. Usable only when setting error behaviour.
+|ET_NONE |No error.
+|=========================================================================================
+
+The possible values of `error_behavior_t` are shown in the table below:
+
+.Possible values of `error_behavior_t`
+
+[cols="30%,70%"]
+|=========================================================================
+|EB_DEFAULT |Sets the default error behaviour for the selected error type.
+|EB_ERROR |Raises an error if the selected error type occurs.
+|EB_WARNING |Gives a warning message but tries to continue the operation.
+|EB_IGNORE |Like warning but without the message.
+|=========================================================================
+
+==== Getting Error Behavior
+
+There are two functions: one for getting the current setting and one for getting the default setting for a particular error situation.
+[source]
+----
+error_behavior_t TTCN_EncDec::get_error_behavior(error_type_t);
+error_behavior_t TTCN_EncDec::get_default_error_behavior(error_type_t);
+----
+The using of these functions are straightforward: giving a particular `error_type_t` the function returns the current or default `error_behavior_t` for that error situation, respectively.
+
+==== Checking if an Error Occurred
+
+The last coding-related error and its textual description can be retrieved anytime. Before using a coding function, it is advisable to clear the "last error". This can be achieved by the following method:
+[source, subs="+quotes"]
+void TTCN_EncDec::clear_error();
+
+After using some coding functions, it can be checked if an error occurred with this function:
+[source, subs="+quotes"]
+error_type_t TTCN_EncDec::get_last_error_type();
+
+This returns the last error, or `ET_NONE` if there was no error. The string representation of the error can be requested with the help of this:
+[source, subs="+quotes"]
+const char* TTCN_EncDec::get_error_str();
+
+WARNING: The above two functions do not clear the "last error" flag.
+
+[[ttcn-buffer]]
+=== TTCN_Buffer
+
+TTCN Buffer objects are used to store encoded values and to communicate with the coding functions. If encoding a value, the result will be put in a buffer, from which can be get. In the other hand, to decode a value, the encoded octet string must be put in a TTCN_Buffer object, and the decoding functions get their input from that.
+[source, subs="+quotes"]
+void TTCN_Buffer::clear();
+
+Resets the buffer, cleaning up its content, setting the pointers to the beginning of buffer.
+[source, subs="+quotes"]
+void TTCN_Buffer::rewind();
+
+Rewinds the buffer, that is, sets its reading pointer to the beginning of the buffer.
+[source, subs="+quotes"]
+size_t TTCN_Buffer::get_pos() const;
+
+Returns the (reading) position of the buffer.
+[source, subs="+quotes"]
+void TTCN_Buffer::set_pos(size_t pos);
+
+Sets the (reading) position to pos, or to the end of buffer, if `pos > get_len()`.
+[source, subs="+quotes"]
+size_t TTCN_Buffer::get_len() const;
+
+Returns the amount of bytes in the buffer.
+[source, subs="+quotes"]
+const unsigned char* TTCN_Buffer::get_data() const;
+
+Returns a pointer that points to the beginning of the buffer. You can read out `count` bytes beginning from this address, where `count` is the value returned by the `get_len()` member function.
+[source, subs="+quotes"]
+size_t TTCN_Buffer::get_read_len() const;
+
+Returns how many bytes are in the buffer to read.
+[source, subs="+quotes"]
+const unsigned char* TTCN_Buffer::get_read_data() const;
+
+Returns a pointer which points to the read position of data in the buffer. `count` bytes can be read out beginning from this address, where count is the value returned by the `get_read_len()` member function.
+[source, subs="+quotes"]
+void TTCN_Buffer::put_c(const unsigned char c);
+
+Appends the byte `c` to the end of buffer.
+[source, subs="+quotes"]
+void TTCN_Buffer::put_s(const size_t len, const unsigned char *s);
+
+Writes a string of bytes to the end of buffer, where len is the amount of bytes, `s` is a pointer to the data to be written.
+[source, subs="+quotes"]
+void TTCN_Buffer::put_os(const OCTETSTRING& os);
+
+Appends the content of the octet string to the buffer.
+
+Sometimes it is useful to copy data directly into a buffer. In this case, the buffer must be told the maximum number of bytes to be written. So the buffer can resize its data area. This can be done with the following function:
+[source, subs="+quotes"]
+void TTCN_Buffer::get_end(unsigned char*& end_ptr, size_t& end_len);
+
+Parameter `end_len` is an in-out parameter: you tell how many bytes you want to write, and the returned value is equal to or greater than the requested. Parameter `end_ptr` is an out parameter. So up to `end_len` bytes can be written beginning from `end_ptr`. After writing also `increase_length()` must be called.
+[source, subs="+quotes"]
+void TTCN_Buffer::increase_length(size_t count);
+
+After writing bytes directly to the end of buffer using the pointer returned by `get_end()` method, the buffer must be told how many bytes have been written. This can be done by this function.
+[source, subs="+quotes"]
+void TTCN_Buffer::cut();
+
+Cuts (removes) the bytes between the beginning of the buffer and the read position. After calling this, the read position will be the beginning of buffer. As this function manipulates the internal data, pointers referencing to data inside the buffer will be invalid.
+[source, subs="+quotes"]
+void TTCN_Buffer::cut_end();
+
+Cuts (removes) the bytes between the read position and the end of the buffer. After calling this, the read position remains unchanged (that is, it will point to the end of the truncated buffer). As this function manipulates the internal data, pointers referencing to data inside the buffer will be invalid.
+[source, subs="+quotes"]
+boolean TTCN_Buffer::contains_complete_TLV();
+
+Returns `TRUE` if the buffer contains a complete TLV, otherwise it returns `FALSE`. Useful when decoding BER streams, and the data is coming in chunks. With the help of this, you can check before decoding whether the message is complete.
+
+=== Invoking the Coding Functions
+
+Every type class has members like these:
+
+[source]
+----
+void encode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+	TTCN_EncDec::coding_t p_cod, ...) const;
+void decode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+	TTCN_EncDec::coding_t p_cod, ...);
+----
+
+Parameter `p_td` is a special type descriptor. Each type has its own descriptor, which contains the name of the type, and a lot of information used by the different encoding mechanisms. The names of the descriptors come from the name of the types: the appropriate type descriptor for type `XXX is XXX_descr_`.
+
+Parameter `p_buf` contains the encoded value. For details about using it, please consult the previous subsection.
+
+Parameter `p_cod` is the desired coding mechanism. As `coding_t` is defined in `TTCN_EncDec`, its value must be prefixed with `TTCN_EncDec::`. For the time being, this parameter may have one of the following values:
+
+* CT_BER - BER coding
+* CT_RAW RAW - coding;
+* CT_TEXT TEXT - coding;
+* CT_XER XML - coding.
+
+The optional … parameter(s) are depending on the chosen coding.
+
+== BER
+
+The encoding rules defined in link:https://www.itu.int/rec/T-REC-X.690-200811-S[Information TechnologyASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished] can be used to encode and/or decode the values of ASN.1 types. There are three methods defined in the referenced document: BER, CER and DER (Basic, Canonical and Distinguished Encoding Rules). While the BER gives a lot of options to the sender (that is, to the encoder), the CER and DER select just one encoding from those allowed by the BER, eliminating all of the sender options. In other words, CER (and also DER) is a subset of BER. Any value encoded by CER or DER can be decoded using BER, but it is not true in the other direction.
+
+In this section it is assumed that the reader has basic knowledge about BER, TLVs, tags, length forms and other items defined in link:https://www.itu.int/rec/T-REC-X.690-200811-S[Information TechnologyASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished].
+
+This tool is capable of encoding values in CER or DER, and uses the BER while decodingfootnote:[Though the decoder can be forced to accept only certain length forms (short, long, indefinite or any combination of these.]. The tags are handled quite separated from the types, giving extra freedom to the user when encoding only one component of a compound type. Let us suppose we have a large SEQUENCE with automatic tags (that is, context-specific implicit tags 1, 2, …), the third component is `"‎[3] Other-sequence"`. Then we have the possibility to encode only this field using SEQUENCE-tag. (Implementation details and examples follow in next sections.)
+
+=== Error Situations
+
+In addition to error situations mentioned in <<the-common-API, The Common API>>, these can occur during BER-coding:
+
+.BER-coding errors
+
+[width="100%",cols="30%,70%",options=" ",]
+|===================================================================================================================================================
+|ET_INCOMPL_ANY |Encoding of an ASN ANY value which does not contain a valid BER TLV.
+|ET_LEN_FORM |During decoding: the received message has a non-acceptable length form.
+|ET_TAG |During decoding: unexpected tag.
+|ET_SUPERFL |During decoding: superfluous part detected. This can be superfluous TLV at the end of a constructed TLV.
+|ET_EXTENSION |During decoding: there was something in the extension (for example: in ASN.1 ellipsis). This is not supported in the current version.
+|ET_DEC_DUPFLD |While decoding a SET: duplicated field (value for the given field already received).
+|ET_DEC_MISSFLD |While decoding a SET: missing field (value for the given field not received).
+|ET_DEC_OPENTYPE |Cannot decode an opentype (broken component relation constraint).
+|ET_DEC_UCSTR |While decoding a universal charstring: Malformed sequence.
+|===================================================================================================================================================
+
+=== API
+
+The Application Programming Interface for ASN.1 type encoding and decoding is described in the following.
+
+==== Encoding
+
+[source, subs="+quotes"]
+void encode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+	TTCN_EncDec::coding_t p_cod, unsigned int p_BER_coding) const;
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_BER`. The parameter `p_BER_coding` is used to choose between CER and DER.
+
+`BER_ENCODE_CER` = CER coding.
+
+`BER_ENCODE_DER` = DER coding.
+
+==== Decoding
+
+[source, subs="+quotes"]
+void decode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+	TTCN_EncDec::coding_t p_cod, unsigned int p_len_form);
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_BER`. The parameter `p_len_form` determines which length forms are accepted.
+
+* `BER_ACCEPT_SHORT`
++
+Short form.
+
+* `BER_ACCEPT_LONG`
++
+Long form.
+
+* `BER_ACCEPT_INDEFINITE`
++
+Indefinite form.
+
+* `BER_ACCEPT_DEFINITE`
++
+Short and long form.
+
+* `BER_ACCEPT_ALL`
++
+All form.
+
+=== Example
+
+Let us assume that we have an ASN.1 module named `MyASN` which contains a type named `ErrorReturn`, and we have a TTCN–3 module which imports this type. This module contains also two ports:
+
+type port MyPort1 message
+
+[source]
+----
+type port MyPort1 message
+{
+  out ErrorReturn;
+  in octetstring;
+}
+
+type port MyPort2 message
+{
+  out octetstring;
+  in ErrorReturn;
+}
+----
+
+Then we can complete the port skeleton generated by the compiler:
+
+[source]
+----
+void MyPort1::outgoing_send(const MyASN::ErrorReturn& send_par)
+{
+  TTCN_Buffer buf;
+  send_par.encode(MyASN::ErrorReturn_descr_, buf,
+                  TTCN_EncDec::CT_BER, BER_ENCODE_DER);
+  OCTETSTRING encodeddata(buf.get_len(), buf.get_data());
+  incoming_message(encodeddata);
+}
+
+void MyPort2::outgoing_send(const OCTETSTRING& send_par)
+{
+  TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_ALL,
+                                  TTCN_EncDec::EB_WARNING);
+  TTCN_Buffer buf;
+  buf.put_os(send_par);
+  MyASN::ErrorReturn pdu;
+  pdu.decode(MyASN::ErrorReturn_descr_, buf, TTCN_EncDec::CT_BER,
+             BER_ACCEPT_ALL);
+  incoming_message(pdu);
+}
+----
+
+== RAW
+
+You can use the encoding rules defined in the section "RAW encoder and decoder" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference] to encode and decode the following TTCN–3 types:
+
+* boolean
+
+* integer
+
+* float
+
+* bitstring
+
+* octetstring
+
+* charstring
+
+* hexstring
+
+* enumerated
+
+* record
+
+* set
+
+* union
+
+* record of
+
+* set of
+
+The compiler will produce code capable of RAW encoding/decoding for compound types if they have at least one `variant` attribute. +
+When a compound type is only used internally or it is never RAW encoded/decoded then the attribute `variant` has to be omitted. +
+ When a type can be RAW encoded/decoded but with default specification then the empty variant specification can be used: `variant ""`.
+
+[[error-situations-0]]
+=== Error Situations
+
+.RAW-coding errors
+
+[width="100%",cols="30%,70%",options="",]
+|============================================================================================================================================================
+|ET_LEN_ERR |During encoding: Not enough length specified in FIELDLENGTH to encode the value. During decoding: the received message is shorter than expected.
+|ET_SIGN_ERR |Unsigned encoding of a negative number.
+|ET_FLOAT_NAN |Not a Number float value has been received.
+|ET_FLOAT_TR |The float value will be truncated during double to single precision conversion.
+|============================================================================================================================================================
+
+[[api-0]]
+=== API
+
+The C++ Application Programming Interface for RAW encoding and decoding is described in the following. It can be used for example in test port implementation, in external function implementation.
+
+[[encoding-0]]
+==== Encoding
+
+[source]
+----
+void encode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+            TTCN_EncDec::coding_t p_cod) const;
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_RAW`.
+
+[[decoding-0]]
+==== Decoding
+
+[source]
+----
+void decode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+            TTCN_EncDec::coding_t p_cod);
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_RAW`.
+
+[[example-0]]
+=== Example
+
+Let us assume that we have a TTCN–3 module which contains a type named `ProtocolPdu`, and this module contains also two ports:
+[source]
+----
+type port MyPort1 message
+{
+  out ProtocolPdu;
+  in octetstring;
+}
+
+type port MyPort2 message
+{
+  out octetstring;
+  in ProtocolPdu;
+}
+----
+
+Then we can complete the port skeleton generated by the compiler as follows:
+[source]
+----
+void MyPort1::outgoing_send(const ProtocolPdu& send_par)
+{
+  TTCN_Buffer buf;
+  send_par.encode(ProtocolPdu_descr_, buf,
+                  TTCN_EncDec::CT_RAW);
+  OCTETSTRING encodeddata(buf.get_len(), buf.get_data());
+
+  incoming_message(encodeddata);
+}
+
+void MyPort2::outgoing_send(const OCTETSTRING& send_par)
+{
+  TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_ALL,
+                                  TTCN_EncDec::EB_WARNING);
+  TTCN_Buffer buf;
+  buf.put_os(send_par);
+  ProtocolPdu pdu;
+  pdu.decode(ProtocolPdu_descr_, buf, TTCN_EncDec::CT_RAW);
+
+  incoming_message(pdu);
+}
+----
+
+== TEXT
+
+You can use the encoding rules defined in the section "TEXT encoder, decoder" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference] to encode and decode the following TTCN–3 types:
+
+* boolean
+
+* integer
+
+* charstring
+
+* enumerated
+
+* record
+
+* set
+
+* union
+
+* record of
+
+* set of
+
+The compiler will produce code capable of TEXT encoding/decoding for compound types if they have at least one variant attribute or it is used within a compound type which has a TEXT attribute. If you need a compound type that is only used internally or it is never RAW encoded/decoded then you have to omit the variant attribute. If you need a type which can be TEXT encoded/decoded but with default specification then the empty variant specification can be used: `variant "TEXT_CODING()"`.
+
+[[error-situations-1]]
+=== Error Situations
+
+`ET_TOKEN_ERR` - The specified token is not found during decoding
+
+[[api-1]]
+=== API
+
+The Application Programming Interface for TEXT encoding and decoding is described in the following.
+
+[[encoding-1]]
+==== Encoding
+
+[source]
+----
+void encode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+            TTCN_EncDec::coding_t p_cod) const;
+----
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_TEXT`.
+
+[[decoding-1]]
+==== Decoding
+
+[source]
+----
+void decode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+            TTCN_EncDec::coding_t p_cod);
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_TEXT`.
+
+[[example-1]]
+=== Example
+
+Let us assume that we have a TTCN–3 module which contains a type named `ProtocolPdu`, and this module contains also two ports:
+[source]
+----
+type port MyPort1 message
+{
+  out ProtocolPdu;
+  in charstring;
+}
+
+type port MyPort2 message
+{
+  out charstring;
+  in ProtocolPdu;
+}
+----
+
+Then we can complete the port skeleton generated by the compiler:
+
+[source]
+----
+void MyPort1::outgoing_send(const ProtocolPdu& send_par)
+{
+  TTCN_Buffer buf;
+  send_par.encode(ProtocolPdu_descr_, buf,
+                  TTCN_EncDec::CT_TEXT);
+  CHARSTRING encodeddata(buf.get_len(), buf.get_data());
+
+  incoming_message(encodeddata);
+}
+
+void MyPort2::outgoing_send(const CHARSTRING& send_par)
+{
+  TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_ALL,
+                                  TTCN_EncDec::EB_WARNING);
+  TTCN_Buffer buf;
+  buf.put_cs(send_par);
+  ProtocolPdu pdu;
+  pdu.decode(ProtocolPdu_descr_, buf, TTCN_EncDec::CT_TEXT);
+
+  incoming_message(pdu);
+}
+----
+
+[[xml-encoding-xer]]
+== XML Encoding (XER)
+
+The encoding rules defined by link:https://www.etsi.org/deliver/etsi_ES/201800_201899/20187309/04.05.01_60/es_20187309v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN–3 European] can be used to encode and/or decode values of ASN.1 and TTCN-3 types. This tool is capable of encoding and decoding Basic XER (BXER), Canonical XER (CXER) and Extended XER (EXER). Values of all ASN.1 types can be encoded, but only BXER and CXER are available for them because parsing XML Encoding Instructions in ASN.1 files is not implemented.
+
+The following built-in TTCN-3 types can be encoded in XML:
+
+* boolean
+
+* integer
+
+* float
+
+* bitstring
+
+* octetstring
+
+* hexstring
+
+* objid
+
+* charstring
+
+* universal charstring
+
+* verdicttype
+
+The following user-defined types can be encoded in XML:
+
+* enumerated types
+
+* record, set and union types, if all components can be encoded.
+
+* record of and set of types, if the type of the element can be encoded.
+
+The encoder and the decoder are working with XML data encoded in UTF-8 (described in link:https://tools.ietf.org/html/rfc3629[UTF-8, a transformation format of ISO 10646]), stored in an object of type `TTCN_buffer`. Although the contents of this object can be retrieved (using the overloads of the get_string function) as an instance of `OCTETSTRING`, `CHARSTRING` or `UNIVERSAL_CHARSTRING`, it is recommended to use only the `OCTETSTRING` representation. `CHARSTRING` is not recommended, because UTF-8 is an 8-bit encoding so the buffer may contain bytes with values over 127, which are not valid characters for a TTCN-3 `charstring` (which is implemented by `CHARSTRING`, see <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc#Charstring, Charstring>>). `UNIVERSAL_CHARSTRING` must not be used because its internal representation is not UTF-8.
+
+[[error-situations-2]]
+=== Error Situations
+
+In addition to error situations mentioned in <<the-common-API, The Common API>>, the following can occur during XMLcoding:
+
+.XER coding errors
+
+[cols=",",options=" ",]
+|============================================================
+|ET_TAG |Incorrect (unexpected) XML tag found during decoding
+|============================================================
+
+[[api-2]]
+=== API
+
+The Application Programming Interface for XML encoding and decoding is described in the following.
+
+[[encoding-2]]
+==== Encoding
+
+[source]
+----
+void encode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+	TTCN_EncDec::coding_t p_cod, unsigned int p_XER_coding) const;
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_XER`. The parameter `p_XER_coding` is used to choose between BXER, CXER and EXER:
+
+`XER_BASIC` = Basic XER (BXER)
+
+`XER_CANONICAL` = Canonical XER (CXER)
+
+`XER_EXTENDED` = Extended XER (EXER)
+
+[[decoding-2]]
+==== Decoding
+
+[source]
+----
+void decode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+	TTCN_EncDec::coding_t p_cod, unsigned int p_XER_coding);
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_XER`. The parameter `p_XER_coding` is used to choose between BXER, CXER and EXER:
+
+`XER_BASIC` = Basic XER (BXER)
+
+`XER_CANONICAL` = Canonical XER (CXER)
+
+`XER_EXTENDED` = Extended XER (EXER)
+
+[[example-2]]
+=== Example
+
+Let us assume that we have a TTCN–3 module which contains a type named `ProtocolPdu`, and this module contains also two ports:
+
+[source]
+----
+void MyPort1::outgoing_send(const ProtocolPdu& send_par)
+{
+  TTCN_Buffer buf;
+  send_par.encode(ProtocolPdu_descr_, buf,
+                  TTCN_EncDec::CT_XER, XER_EXTENDED);
+  OCTETSTRING encodeddata(buf.get_len(), buf.get_data());
+
+  incoming_message(encodeddata);
+}
+
+void MyPort2::outgoing_send(const OCTETSTRING& send_par)
+{
+  TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_ALL,
+                                  TTCN_EncDec::EB_WARNING);
+  TTCN_Buffer buf;
+  buf.put_os(send_par);
+  ProtocolPdu pdu;
+  pdu.decode(ProtocolPdu_descr_, buf, TTCN_EncDec::CT_XER, XER_EXTENDED);
+
+  incoming_message(pdu);
+}
+----
+== JSON
+
+The encoding rules defined in the section "JSON Encoder and Decoder" of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference] can be used to encode and decode the following TTCN–3 types:
+
+* anytype
+
+* array
+
+* bitstring
+
+* boolean
+
+* charstring
+
+* enumerated
+
+* float
+
+* hexstring
+
+* integer
+
+* objid
+
+* octetstring
+
+* record`, set
+
+* record of`, set of
+
+* union
+
+* universal charstring
+
+* verdicttype
+
+The rules also apply to the following ASN.1 types (if imported to a TTCN-3 module):
+
+* ANY
+
+* BIT STRING
+
+* BOOLEAN
+
+* BMPString
+
+* CHOICE, open type (in instances of parameterized types)
+
+* ENUMERATED
+
+* GeneralString
+
+* GraphicString
+
+* IA5String
+
+* INTEGER
+
+* NULL
+
+* NumericString
+
+* OBJECT IDENTIFIER
+
+* OCTET STRING
+
+* PrintableString
+
+* RELATIVE`-OID
+
+* SEQUENCE, SET
+
+* SEQUENCE OF, SET OF
+
+* TeletexString
+
+* UniversalString
+
+* UTF8String
+
+* VideotexString
+
+* VisibleString
+
+The compiler will produce code capable of JSON encoding/decoding for compound types if they have at least one JSON variant attribute or the `encode "JSON"` attribute (and, for compound types, all fields and elements of compound types also have a JSON variant attribute or the `encode "JSON"` attribute).
+
+The encoder and the decoder work with JSON data encoded in UTF-8 (described in link:https://tools.ietf.org/html/rfc3629[UTF-8, a transformation format of ISO 10646]), stored in an object of type `TTCN_buffer`. Although the contents of this object can be retrieved (using the overloads of the `get_string` function) as an instance of `OCTETSTRING`, `CHARSTRING` or `UNIVERSAL_CHARSTRING`, it is recommended to use only the `OCTETSTRING` representation. `CHARSTRING` is not recommended, because UTF-8 is an 8-bit encoding so the buffer may contain bytes with values over 127, which are not valid characters for a TTCN-3 `charstring` (which is implemented by `CHARSTRING`, see <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc#Charstring, Charstring>>). `UNIVERSAL_CHARSTRING` must not be used because its internal representation is not UTF-8.
+
+[[error-situations-3]]
+=== Error Situations
+
+There are no extra error situations apart from the ones in <<the-common-API, The Common API>>.
+
+[[api-3]]
+=== API
+
+The Application Programming Interface for JSON encoding and decoding is described in the following.
+
+[[encoding-3]]
+==== Encoding
+
+[source]
+----
+void encode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+            TTCN_EncDec::coding_t p_cod) const;
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_JSON`.
+
+[[decoding-3]]
+==== Decoding
+
+[source]
+----
+void decode(const TTCN_Typedescriptor_t& p_td, TTCN_Buffer& p_buf,
+            TTCN_EncDec::coding_t p_cod);
+----
+
+The parameter `p_cod` must be set to `TTCN_EncDec::CT_JSON`.
+
+[[example-3]]
+=== Example
+
+Let us assume that we have a TTCN–3 module which contains a type named `ProtocolPdu`, and this module also contains two ports:
+[source]
+----
+type port MyPort1 message
+{
+  out ProtocolPdu;
+  in octetstring;
+}
+
+type port MyPort2 message
+{
+  out octetstring;
+  in ProtocolPdu;
+}
+----
+
+Then we can complete the port skeleton generated by the compiler:
+[source]
+----
+void MyPort1::outgoing_send(const ProtocolPdu& send_par)
+{
+  TTCN_Buffer buf;
+  send_par.encode(ProtocolPdu_descr_, buf,
+                  TTCN_EncDec::CT_JSON);
+  OCTETSTRING encodeddata(buf.get_len(), buf.get_data());
+
+  incoming_message(encodeddata);
+}
+
+void MyPort2::outgoing_send(const OCTETSTRING& send_par)
+{
+  TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_ALL,
+                                  TTCN_EncDec::EB_WARNING);
+  TTCN_Buffer buf;
+  buf.put_os(send_par);
+  ProtocolPdu pdu;
+  pdu.decode(ProtocolPdu_descr_, buf, TTCN_EncDec::CT_JSON);
+
+  incoming_message(pdu);
+}
+----
diff --git a/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc b/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..850e6dd2f6b8ac4e4d0731558e297f157d209fd1
--- /dev/null
+++ b/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc
@@ -0,0 +1,1940 @@
+[[mapping-ttcn-3-data-types-to-c-constructs]]
+= Mapping TTCN–3 Data Types to C++ Constructs
+:table-number: 7
+:toc:
+
+The TTCN–3 language elements of the test suite are individually mapped into more or less equivalent C\++ constructs. The data types are mapped to C++ classes, the test cases become C++ functions, and so on. In order to write a Test Port, it is inevitable to be familiar with the internal representation format of TTCN–3 data types and values. This section gives an overview about the data types and their equivalent C++ constructs.
+
+[[mapping-of-names-and-identifiers]]
+== Mapping of Names and Identifiers
+
+In order to identify the TTCN–3 language elements in the generated C\++ program properly, the names of test suite are translated to C++ identifiers according to the following simple rules.
+
+If the TTCN–3 identifier does not contain any underscore (_) character, its equivalent C\++ identifier will be the same. For example, the TTCN–3 variable `MyVar` will be translated to a C++ variable called `MyVar`.
+
+If the TTCN–3 identifier contains one or more underscore characters, each underscore character will be duplicated in the C\++ identifier. So the TTCN–3 identifier `My_Long_Name` will be mapped to a C++ identifier called `My\__Long__Name`.
+
+The idea behind this name mapping is that we may freely use the C\++ identifiers containing one underscore character in the generated code and in the Test Ports as well. Otherwise name clashes can always happen because the name space of TTCN–3 and C++ is identical. Furthermore, the generated C\++ language elements fulfill the condition that the scope of a translated C++ identifier is identical as the scope of the original TTCN–3 identifier.
+
+The identifiers that are keywords of C or C\++ but not keywords in TTCN–3 are mapped to themselves, but a single underscore character is appended at the end (for example `typedef` becomes `typedef_`). The same rule applies to the all-uppercase identifiers that are used in the Base Library: identifier `INTEGER` in TTCN–3 becomes `INTEGER_` in C++, `TRUE` footnote:[The built-in `verdict` and `boolean` constants in TTCN–3 shall be written with all lowercase letters, such as true or pass. Although previous compiler versions have accepted `TRUE` or `PASS` as well, these words are treated by the compiler as regular identifiers as specified in the standard.] is mapped to `TRUE_`, etc.
+
+Here is the complete list (in alphabetical order) of the identifiers that are handled in such special way:asm, auto, bitand, bitor, bool, break, case, class, compl, continue, delete, double, enum, explicit, export, friend, inline, int, ischosen, long, main, mutable, namespace, new, operator, private, protected, public, register, short, signed, static, stderr, stdin, stdout, struct, switch, this, throw, try, typedef, typeid, typename, unsigned, using, virtual, void, volatile, ADDRESS, BITSTRING, BOOLEAN, CHAR, CHARSTRING, COMPONENT, DEFAULT, ERROR, FAIL, FALSE, FLOAT, HEXSTRING, INCONC, INTEGER, NONE, OBJID, OCTETSTRING, PASS, PORT, TIMER, TRUE, VERDICTTYPE.
+
+The identifiers that are the names of common preprocessor macros of the C library (such as `putchar`, `errno` or `NULL`) should be avoided in TTCN–3 modules. The name clashes with macros can cause mysterious compilation error messages.
+
+Note that these name mapping rules apply to *all* TTCN–3 identifiers, including module, Test Port, type, field, variable and function names.
+
+WARNING: By default, from version 1.2.pl0 the compiler does NOT duplicate the underscores in output file names and file references (for example when handling imports).
+
+== Namespaces
+
+The compiler generates a C++ namespace for every TTCN–3 and ASN.1 module. All C++ definitions that belong to the module (including Test Port classes and external functions) are placed in that namespace. The name of the namespace is derived from the module identifier according to the rules described in <<mapping-of-names-and-identifiers, Mapping of Names and Identifiers>>.
+
+The definitions of the TTCN–3 Base Library do not use any namespace.
+
+When accessing a C\++ entity that belongs to a different module than the referring Test Port or external function is in the reference has to be prefixed with the namespace of the referenced module. For example, to access the C++ class that realizes type `MyType` defined in `MyModule1` from a Test Port that belongs to module `MyModule2` the reference shall be written as `MyModule1::MyType`.
+
+[[predefined-ttcn-3-data-types]]
+== Predefined TTCN–3 Data Types
+
+There are some basic data types in TTCN–3 that have no equivalent data types in language C/C\++ (for example bitstring, verdicttype). Other types have C++ equivalent, but the TTCN–3 executor must know whether a variable has a valid value or not because sending an unbound value must result in a dynamic test case error. Thus, in the TTCN–3 Base Library all basic data types of TTCN–3 were implemented as C++ classes. This section describes the member functions of these classes.
+
+=== `Integer`
+
+The TTCN–3 type `integer` is implemented in class `INTEGER`. +
+The class `INTEGER` has the following public member functions:
+
+.Public member functions of the class `INTEGER`
+[cols=",,",]
+|==================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Constructors_
+|`INTEGER()` |Initializes to unbound value.
+|`INTEGER(int)` |Initializes to a given value.
+|`INTEGER(const INTEGER&`) |Copy constructor.
+|`explicit INTEGER(const char *)` |Initializes with the (NUL terminated) string representation of an integer.
+^.^|_Destructor_
+|`ËœINTEGER()` |
+.2+^.^|_Assignment operators_
+|`INTEGER()` |Initializes to unbound value.
+|`INTEGER()` |Initializes to unbound value.
+.12+^.^|_Comparison operators_
+| boolean operator==(int) const | Returns TRUE if equals
+| boolean operator==(const INTEGER&) const | and FALSE otherwise.
+| boolean operator!=(int) const  |
+| boolean operator!=(const INTEGER&) const  |
+| boolean operator<(int) const  |
+| boolean operator<(const INTEGER&) const  |
+| boolean operator<=(int) const  |
+| boolean operator<=(const INTEGER&) const  |
+| boolean operator>(int) const  |
+| boolean operator>(const INTEGER&) const  |
+| boolean operator>=(int) const  |
+| boolean operator>=(const INTEGER&) const  |
+.12+^.^|_Arithmetic operators_
+| INTEGER operator+() const |Unary plus.
+| INTEGER operator-() const |Unary minus.
+| INTEGER operator+(int) const |Addition.
+| INTEGER operator+(const INTEGER&) const |
+| INTEGER operator-(int) const |Subtraction.
+| INTEGER operator-(const INTEGER&) const |
+| INTEGER operator*(int) const |Multiplication.
+| INTEGER operator*(const INTEGER&) const |
+| INTEGER operator/(int) const |Integer division.
+| INTEGER operator/(const INTEGER&) const |
+| INTEGER& operator++() |Incrementation (prefix).
+| INTEGER& operator—() |Decrementation (prefix).
+^.^|_Casting operator_
+| operator int() const |Returns the value.
+.5+^.^|_Other member functions_
+| `void log() const` |Puts the value into log.
+| `boolean is_bound() const` |Returns whether the value is bound.
+| `void clean_up()` |Deletes the value, setting it to unbound.
+| `long long int get_long_long_val() const` |Returns the value as a long long `int`.
+| `void set_long_long_val(long long int)` |Sets the given long long `int` value.
+|==================================================
+
+The comparison, arithmetic and shifting operators are also available as global functions for that case when the left side is `int` and the right side is `INTEGER`. Using the value of an unbound variable for anything will cause dynamic test case error.
+
+The casting operator `int()` is applicable only to `INTEGER` objects holding a signed value with at most 31 useful bits, since in C/C++ the native `int` type is 32-bit large including the sign bit. Casting an `INTEGER` object holding a bigger (for example a 32-bit unsigned) value will result in run-time error.
+
+Please note that if the value stored in an `INTEGER` object is too big (that is, it cannot be represented as a `long long int`) the value returned by `get_long_long_val()` will contain only the lowest `sizeof(long long int)` bytes of the original value. Another way to obtain a value of a number having more useful bits than 31 is to convert the INTEGER object to its string representation using the `int2str()` predefined function. Then the string value can be converted to any native integer type using the `sscanf()` library function or such. The following example demonstrates a common scenario:
+[source]
+----
+unsigned int get_unsigned_int_val(const INTEGER& other_value)
+{
+  unsigned int ret_val = 0;
+  sscanf((const char *)int2str(), “%u”, &ret_val);
+  return ret_val;
+}
+----
+
+In addition, the following global functions are available for modulo division. These functions return the result of `mod` and `rem` operations according to TTCN–3 semantics.
+[source]
+----
+INTEGER mod(const INTEGER& left_operand, const INTEGER& right_operand);
+INTEGER mod(const INTEGER& left_operand, int right_operand);
+INTEGER mod(int left_operand, const INTEGER& right_operand);
+INTEGER mod(int left_operand, int right_operand);
+
+INTEGER rem(const INTEGER& left_operand, const INTEGER& right_operand);
+INTEGER rem(const INTEGER& left_operand, int right_operand);
+INTEGER rem(int left_operand, const INTEGER& right_operand);
+INTEGER rem(int left_operand, int right_operand);
+----
+
+Other operators (global functions):
+[source]
+----
+INTEGER operator+(int int_value, const INTEGER& other_value);  // Add
+INTEGER operator-(int int_value, const INTEGER& other_value);  // Subtract
+INTEGER operator*(int int_value, const INTEGER& other_value);  // Multiply
+INTEGER operator/(int int_value, const INTEGER& other_value);  // Divide
+boolean operator==(int int_value, const INTEGER& other_value); // Equal
+boolean operator!=(int int_value, const INTEGER& other_value); // Not equal
+boolean operator<(int int_value, const INTEGER& other_value);  // Less than
+boolean operator>(int int_value, const INTEGER& other_value);  // More than
+----
+
+=== `Float`
+
+The TTCN–3 type `float` is implemented in class `FLOAT`. +
+The class `FLOAT` has the following public member functions:
+
+.Public member functions of the class `FLOAT`
+
+[width="100%",cols=",,"]
+|=================================================================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`FLOAT()` |Initializes to unbound value.
+|`FLOAT(double)` |Initializes to a given value.
+|`FLOAT(const FLOAT&`) |Copy constructor.
+^.^|_Destructor_
+|`ËœFLOAT()` |
+.2+^.^|Assignment operators
+|`FLOAT& operator=(double)`  |Assigns the given value
+|`FLOAT& operator=(const FLOAT&)` |and sets the bound flag.
+.12+^.^|_Comparison operators_
+|boolean operator==(double) const |Returns TRUE if equals
+|boolean operator==(const FLOAT&) const  |and FALSE otherwise.
+|boolean operator!=(double) const  |
+|boolean operator!=(const FLOAT&) const  |
+|boolean operator<(double) const  |
+|boolean operator<(const FLOAT&) const  |
+|boolean operator<=(double) const  |
+|boolean operator<=(const FLOAT&) const  |
+|boolean operator>(double) const  |
+|boolean operator>(const FLOAT&) const  |
+|boolean operator>=(double) const  |
+|boolean operator>=(const FLOAT&) const  |
+.10+^.^|_Arithmetic operators_
+|double operator+() const  |Unary plus.
+|double operator-() const  |Unary minus.
+|double operator+(double) const |Addition.
+|double operator+(const FLOAT&) const  |
+|double operator-(double) const  |Subtraction.
+|double operator-(const FLOAT&) const  |
+|double operator*(double) const  |Multiplication.
+|double operator*(const FLOAT&) const  |
+|double operator/(double) const  |Division.
+|double operator/(const FLOAT&) const  |
+^.^|_Casting operator_
+|operator double() const |Returns the value.
+.3+^.^|_Other member functions_
+|`void log() const`|Puts the value into log, either in exponential or decimal dot notation.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|=================================================================================================
+
+The comparison and arithmetic operators are also available as global functions for that case when the left side is `double` and the right side is `FLOAT`. Using the value of an unbound variable for anything will cause dynamic test case error.
+
+Other operators (global functions):
+[source]
+----
+FLOAT operator+(double double_value, const FLOAT& other_value);    // Add
+FLOAT operator-(double double_value, const FLOAT& other_value);    // Subtract
+FLOAT operator*(double double_value, const FLOAT& other_value);    // Multiply
+FLOAT operator/(double double_value, const FLOAT& other_value);    // Divide
+boolean operator==(double double_value, const FLOAT& other_value); // Equal
+boolean operator!=(double double_value, const FLOAT& other_value); // Not equal
+boolean operator<(double double_value, const FLOAT& other_value);  // Less than
+boolean operator>(double double_value, const FLOAT& other_value);  // More than
+----
+
+=== `Boolean`
+
+The TTCN–3 type `boolean` is implemented in class `BOOLEAN`.We have introduced an ancillary C enumerated type called `boolean` to set and get values. It may have two predefined values: `TRUE` or `FALSE`. You may use `boolean` values in C conditions since `FALSE` equals to zero and `TRUE` is not zero. +
+The class `BOOLEAN` has the following public member functions:
+
+.Public member functions of the class `BOOLEAN`
+
+[cols=",,",,]
+|==================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`BOOLEAN()` |Initializes to unbound value.
+|`BOOLEAN(boolean)` |Initializes to a given value.
+|`BOOLEAN(const BOOLEAN&)` | Copy constructor.
+^.^|_Destructor_
+|`ËœBOOLEAN()` |
+.2+^.^|_Assignment operators_
+|`BOOLEAN& operator=(boolean)` |Assigns the given value
+|`BOOLEAN& operator=(const BOOLEAN&)` |and sets the bound flag.
+.4+^.^|_Comparison operators_
+|boolean operator==(boolean) const |Returns TRUE if equals
+|boolean operator==(const BOOLEAN&) const |and FALSE otherwise.
+|boolean operator!=(boolean) const |Same as XOR.
+|boolean operator!=(const BOOLEAN&) const |
+.8+^.^|_Logical operators_
+|boolean operator!() const |Negation (NOT).
+|boolean operator&&(boolean) const |Logical AND.
+|boolean operator&&(const BOOLEAN&) const |
+|boolean operator|(boolean) const |Logical OR.
+|boolean operator|(const BOOLEAN&) const |
+|boolean operatorˆ(boolean) const |Exclusive or (XOR).
+|boolean operatorˆ(const BOOLEAN&) const |
+^.^|_Casting operator_
+|operator boolean() const |Returns the value.
+.3+^.^|_Other member functions_
+|`void log() const` |Puts the value into log. Like “TRUE” or “FALSE”.
+|`boolean is_bound() const` |Returns whether the value is bound
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|==================================================
+
+The comparison and logical operators are also available as global functions for that case when the left side is `boolean` and the right side is `BOOLEAN`. Using the value of an unbound variable for anything will cause dynamic test case error.
+
+Other operators (global functions):
+[source]
+----
+BOOLEAN operator&&(boolean bool_value, const BOOLEAN& other_value); // And
+BOOLEAN operator^(boolean bool_value, const BOOLEAN& other_value);  // Not
+BOOLEAN operator||(boolean bool_value, const BOOLEAN& other_value); // Or
+boolean operator==(boolean bool_value, const BOOLEAN& other_value); // Equal
+boolean operator!=(boolean bool_value, const BOOLEAN& other_value);// Not equal
+----
+
+=== `Verdicttype`
+
+The TTCN–3 type `verdicttype` is implemented in class `VERDICTTYPE`. We have introduced an ancillary C enumerated type called `verdicttype` to set and get values. It may have five predefined values: `NONE`, `PASS`, `INCONC`, `FAIL` or `ERROR`.
+The order of these values is `NONE < PASS < INCONC < FAIL < ERROR`. The class `VERDICTTYPE` has the following public member functions:
+
+.Public member functions of the class `VERDICTTYPE`
+
+[cols=",,",,]
+|==================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`VERDICTTYPE()` |Initializes to unbound value.
+|`VERDICTTYPE(verdicttype)`  |Initializes to a given value.
+|`VERDICTTYPE(const VERDICTTYPE&)`  |Copy constructor.
+^.^|_Destructor_
+|`ËœVERDICTTYPE()` |
+.2+^.^|_Assignment operators_
+|`VERDICTTYPE& operator=(verdicttype)` |Assigns the given value
+|`VERDICTTYPE& operator= (const VERDICTTYPE&)`  |and sets the bound flag.
+.4+^.^|_Comparison operators_
+|boolean operator==(verdicttype) const |Returns TRUE if equals
+|boolean operator==(const VERDICTTYPE&) const  |and FALSE otherwise.
+|boolean operator!=(verdicttype) const  |
+|boolean operator!=(const VERDICTTYPE&) const  |
+^.^|_Casting operator_ |Returns the value.
+|operator verdicttype() const  |Returns the value.
+.3+^.^|_Other member functions_ |Puts the value into log.
+|`void log() const`|Puts the value into log. |Like “pass” or “fail”.
+|`boolean is_bound() const` | Returns whether the value is bound.
+|`void clean_up()` | Deletes the value, setting it to unbound.
+|==================================================
+
+The comparison operators are also available as global functions for that case when the left side is `verdicttype` and the right side is `VERDICTTYPE`. Using the value of an unbound `VERDICTTYPE` variable for anything will cause dynamic test case error.
+
+From version 1.2.pl0 there are the following three static member functions in class `TTCN_Runtime` defined in the Base Library for getting or modifying the local verdict of the current test components:
+[source]
+----
+void TTCN_Runtime::setverdict(verdicttype);
+void TTCN_Runtime::setverdict(const VERDICTTYPE&);
+verdicttype TTCN_Runtime::getverdict();
+----
+
+These functions are the C\++ equivalents of TTCN–3 `setverdict` and `getverdict` operations. Use them only if your Test Port or C++ function encounters a low-level failure, but it can continue its normal operation (that is, error recovery is not necessary).
+
+Other operators (global functions):
+[source]
+----
+boolean operator==(verdicttype par_value,
+                     const VERDICTTYPE& other_value); // Equal
+boolean operator!=(verdicttype par_value,
+                     const VERDICTTYPE& other_value); // Not equal
+----
+
+=== `Bitstring`
+
+The equivalent C++ class of TTCN–3 type `bitstring` is called `BITSTRING`. The bits of the bit string are stored in an array of unsigned characters. In order to reduce the wasted memory space the bits are packed together, so each character contains eight bits. The first character contains the first eight bits of the bit string; the second byte contains the bits from the 9th up to the 16th, and so on. The first bit of the bit string is the LSB of the first character; the second bit is the second least significant bit of the first character, and so on. The character array is not terminated with a `NUL` character and if the length of the bit string is not a multiple of eight, the unused bits of the last character can contain any value. So the length of the bit string must be always given.
+
+The class `BITSTRING` has the following public member functions:
+
+.Public member functions of the class `BITSTRING`
+
+[width="100%",cols=",,"]
+|==============================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Constructors_
+|`BITSTRING()` |Initializes to unbound value.
+|`BITSTRING(int n_bits, unsigned char *bits_ptr)` |Initializes from a given length
+and pointer to character array.
+|`BITSTRING(const BITSTRING&)` |Copy constructor.
+|`BITSTRING(const BITSTRING_ELEMENT&)` |Initializes from a single bitstring element.
+^.^|_Destructor_
+|`ËœBITSTRING()` |
+.2+^.^|_Assignment operators_
+|`BITSTRING& operator=(const BITSTRING&)` |Assigns the given value and sets the bound flag.
+|`BITSTRING& operator=(const BITSTRING_ELEMENT&`) |Assigns the given single bitstring element.
+.4+^.^|_Comparison operators_
+|boolean operator==(const BITSTRING&) const |Returns TRUE if equals
+|boolean operator==(const BITSTRING_ELEMENT&) const |and FALSE otherwise.
+|boolean operator!=(const BITSTRING&) const |
+|boolean operator!=(const BITSTRING_ELEMENT&) const |
+.2+^.^|_Concatenation operator_
+|BITSTRING operator+(const BITSTRING&) const |Concatenates two bitstrings.
+|BITSTRING operator+(const BITSTRING_ELEMENT&) const |Concatenates a bitstring and a bitstring element.
+.4+^.^|_Index operator_
+|BITSTRING_ELEMENT operator[](int) |Gives access to the given element. Indexing begins from zero. Index overflow causes dynamic test case error.
+|BITSTRING_ELEMENT operator[](const INTEGER&) |
+|const BITSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
+|const BITSTRING_ELEMENT operator[](const INTEGER&) const |
+.8+^.^|_Bitwise operators_
+|BITSTRING operator~() const |C++ equivalent of operator not4b. (bitwise negation)
+|BITSTRING operator&(const BITSTRING&) const |C++ equivalent of operator
+and4b. (bitwise and)
+|BITSTRING operator&(const BITSTRING_ELEMENT&) const |
+|BITSTRING operator|(const BITSTRING&) const |C++ equivalent of operator
+or4b. (bitwise or)
+|BITSTRING operator|(const BITSTRING_ELEMENT&) const |
+|BITSTRING operatorˆ(const BITSTRING&) const |C++ equivalent of operator
+xor4b. (bitwise xor)
+|BITSTRING operator^(const BITSTRING_ELEMENT&) const |
+.8+^.^|_Shifting and rotating operators_
+|BITSTRING operator<<(int) const |C++ equivalent of operator
+|BITSTRING operator<<(const INTEGER&) const |<<.(shift left)
+|BITSTRING operator>>(int) const |C++ equivalent of operator
+|BITSTRING operator>>(const INTEGER&) const |>>. (shift right)
+|BITSTRING operator<<=(int) const |C++ equivalent of operator
+|BITSTRING operator<<=(const INTEGER&) const |< @. (rotate left)
+|BITSTRING operator>>=(int) const |C++ equivalent of operator
+|BITSTRING operator>>=(const INTEGER&) const |@ >. (rotate right)
+^.^|_Casting operator_
+|operator const unsigned char*() const |Returns a pointer to the character array.
+.4+^.^|_Other member functions_
+|`int lengthof() const` |Returns the length measured in bits.
+|`void log() const` |Puts the value into log.
+Example: ’100011’B.
+|`boolean is_bound() const` |Deletes the value, setting it to unbound
+|`void clean_up()` |
+
+|==============================================================================================================================
+
+Using the value of an unbound `BITSTRING` variable for anything will cause dynamic test case error.
+
+==== `Bitstring element`
+
+The C++ class `BITSTRING_ELEMENT` is the equivalent of the TTCN-3 `bitstring`’s element type (the result of indexing a `bitstring` value). The class does not store the actual bit, only a reference to the original `BITSTRING` object, an index value and a bound flag.
+
+Note: changing the value of the `BITSTRING_ELEMENT` (through the assignment operator) changes the referenced bit in the original `bitstring` object.
+
+The class `BITSTRING_ELEMENT` has the following public member functions:
+
+.Public member functions of the class `BITSTRING_ELEMENT`
+
+[width="100%",cols=,,",,]
+|========================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+|_Constructor_
+|`BITSTRING_ELEMENT`(boolean par_bound_flag, BITSTRING& par_str_val, int par_bit_pos) |Initializes the object with an unbound value or a reference to a bit in an existring BITSTRING object.
+.2+^.^|_Assignment operators_
+|`BITSTRING_ELEMENT& operator=(const BITSTRING&)` |Sets the referenced bit to the given bitstring of length 1.
+|`BITSTRING_ELEMENT& operator=(const BITSTRING_ELEMENT&)` |Sets the referenced bit to the given bitstring element.
+.4+^.^|_Comparison operators_
+|boolean operator==(const BITSTRING&) const |Comparison with a bitstring or a bitstring element (the value of the referenced bits is compared, not the references and indexes).
+|boolean operator==(const BITSTRING_ELEMENT&) const |
+|boolean operator!=(const BITSTRING&) const |
+|boolean operator!=(const BITSTRING_ELEMENT&) const |
+.2+^.^|_Concatenation operator_
+|BITSTRING operator+(const BITSTRING&) const |Concatenates a bitstring element with a bitstring, or two bitstring elements.
+|BITSTRING operator+(const BITSTRING_ELEMENT&) const |
+.8+^.^|_Bitwise operators_
+|BITSTRING operator~() const |C++ equivalent of operator not4b. (bitwise negation)
+|BITSTRING operator&(const BITSTRING&) const |C++ equivalent of operator
+and4b. (bitwise and)
+|BITSTRING operator&(const BITSTRING_ELEMENT&) const  |
+|BITSTRING operator|(const BITSTRING&) const  | C++ equivalent of operator
+or4b. (bitwise or)
+|BITSTRING operator|(const BITSTRING_ELEMENT&) const  |
+|BITSTRING operatorˆ(const BITSTRING&) const | C++ equivalent of operator
+xor4b. (bitwise xor)
+|BITSTRING operatorˆ(const BITSTRING_ELEMENT&) const |
+.4+^.^|_Other member functions_
+|`boolean get_bit() const` |Returns the referenced bit.
+|`void log() const` | Puts the value into log.
+Example: '1'B.
+|`boolean is_bound() const` | Returns whether the value is bound.
+|========================================================================================================================================================
+
+Using the value of an unbound `BITSTRING_ELEMENT` variable for anything will cause dynamic test case error.
+
+=== `Hexstring`
+
+The equivalent C++ class of TTCN–3 type `hexstring` is called `HEXSTRING`. The hexadecimal digits (nibbles) are stored in an array of unsigned characters. In order to reduce the wasted memory space two nibbles are packed into one character. The first character contains the first two nibbles of the `hexstring`, the second byte contains the third and fourth nibbles, and so on. The hexadecimal digits at odd (first, third, fifth, etc.) positions occupy the lower 4 bits in the characters; the even ones use the upper 4 bits. The character array is never terminated with a `NUL` character, so the length must be always given with the pointer. If the `hexstring` has odd length the unused upper 4 bits of the last character may contain any value.
+
+The class `HEXSTRING` has the following public member functions:
+
+.Public member functions of the class `HEXSTRING`
+
+[width="100%",cols=",,",options="header",]
+|==============================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Constructors_
+|`HEXSTRING()` |Initializes to unbound value.
+|`HEXSTRING(int n_nibbles, const unsigned char *nibbles_ptr)` |Initializes from a given length and pointer to the character array.
+|`HEXSTRING(const HEXSTRING&)`|
+|`HEXSTRING(const HEXSTRING_ELEMENT&)`|
+^.^|_Destructor_
+|`ËœHEXSTRING()`  |
+.2+^.^|_Assignment operators_
+|`HEXSTRING& operator=(const HEXSTRING&)` |Assigns the given value
+|`HEXSTRING& operator=(const HEXSTRING_ELEMENT&)` |
+.4+^.^|_Comparison operators_
+|boolean operator==(const HEXSTRING&) const  |Returns TRUE if equals and FALSE otherwise.
+|boolean operator==(const HEXSTRING_ELEMENT&) const |
+|boolean operator!=(const HEXSTRING&) const  |
+|boolean operator!=(const HEXSTRING_ELEMENT&) const |
+.2+^.^|_Concatenation operator_
+|HEXSTRING operator+(const HEXSTRING&) const |Concatenates two hexstrings.
+|HEXSTRING operator+(const HEXSTRING_ELEMENT&) const |Concatenates a hexstring and a hexstring element.
+.4+^.^|_Index operator_
+|HEXSTRING_ELEMENT operator[](int) |Gives access to the given element. Indexing begins from zero. Index overflow causes dynamic test case error.
+|HEXSTRING_ELEMENT operator[](const INTEGER&) |
+|const HEXSTRING_ELEMENT operator[](int) const |
+|const HEXSTRING_ELEMENT operator[](const INTEGER&) const |
+.8+^.^|_Bitwise operators_
+|HEXSTRING operator~() const  |C++ equivalent of operator not4b. (bitwise negation)
+|HEXSTRING operator&(const HEXSTRING&) const  |C++ equivalent of operator
+and4b. (bitwise and)
+|HEXSTRING operator&(const HEXSTRING_ELEMENT&) const  |
+|HEXSTRING operator|(const HEXSTRING&) const  |C++ equivalent of operator
+or4b. (bitwise or)
+|HEXSTRING operator|(const HEXSTRING_ELEMENT&) const  |
+|HEXSTRING operatorˆ(const HEXSTRING&) const  |C++ equivalent of operator
+xor4b. (bitwise xor)
+|HEXSTRING operator^(const HEXSTRING_ELEMENT&) const  |
+.8+^.^|_Shifting and rotating operators_
+|HEXSTRING operator<<(int) const  |C++ equivalent of operator
+|HEXSTRING operator<<(const INTEGER&) const  |<<.(shift left)
+|HEXSTRING operator>>(int) const  |C++ equivalent of operator
+|HEXSTRING operator>>(const INTEGER&) const  |>>. (shift right)
+|HEXSTRING operator<<=(int) const  |C++ equivalent of operator
+|HEXSTRING operator<<=(const INTEGER&) const  |< @. (rotate left)
+|HEXSTRING operator>>=(int) const |C++ equivalent of operator
+|HEXSTRING operator>>=(const INTEGER&) const  |@ >. (rotate right)
+^.^|_Casting operator_
+|operator const unsigned char*() const |Returns a pointer to the character array. The pointer might be NULL if the length is 0.
+.4+^.^|_Other member functions_
+|`int lengthof() const` |Returns the length measured in nibbles.
+|`void log() const` |Puts the value into log. Example: ’5A7’H.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+|==============================================================================================================================
+
+Using the value of an unbound `HEXSTRING` variable for anything will cause a dynamic test case error.
+
+==== `Hexstring` element
+
+The C++ class `HEXSTRING_ELEMENT` is the equivalent of the TTCN-3 `hexstring`’s element type (the result of indexing a `hexstring` value). The class does not store the actual hexadecimal digit (nibble), only a reference to the original HEXSTRING object, an index value and a bound flag.
+
+Note: changing the value of the `HEXSTRING_ELEMENT` (through the assignment operator) changes the referenced nibble in the original `hexstring` object.
+
+The class `HEXSTRING_ELEMENT` has the following public member functions:
+
+.Public member functions of the class `HEXSTRING_ELEMENT`
+
+[width="100%",cols=",,",options="",]
+|===========================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+^.^|_Constructor_
+| `HEXSTRING_ELEMENT(boolean par_bound_flag`, `HEXSTRING& par_str_val`, `int par_nibble_pos)` |Initializes the object with an unbound value or a reference to a nibble in an existring HEXSTRING object.
+.2+^.^|_Assignment operators_
+|`HEXSTRING_ELEMENT& operator=(const HEXSTRING&)` |Sets the referenced nibble to the given hexstring of length 1.
+|`HEXSTRING_ELEMENT& operator=(const HEXSTRING_ELEMENT&)` | Sets the referenced nibble to the given hexstring element.
+.4+^.^|_Comparison operators_
+|boolean operator==(const HEXSTRING&) const |Comparison with a hexstring or a hexstring element (the value of the referenced nibbles is compared, not the references and indexes).
+|boolean operator==(const HEXSTRING_ELEMENT&) const  |
+|boolean operator!=(const HEXSTRING&) const |
+|boolean operator!=(const HEXSTRING_ELEMENT&) const  |
+.2+^.^|_Concatenation operator_
+|HEXSTRING operator+(const HEXSTRING&) const  |Concatenates a hexstring element with a hexstring, or two hexstring elements.
+|HEXSTRING operator+(const HEXSTRING_ELEMENT&) const |
+.8+^.^|_Bitwise operators_
+|HEXSTRING operator~() const  |C++ equivalent of operator not4b. (bitwise negation)
+|HEXSTRING operator&(const HEXSTRING&) const |C++ equivalent of operator
+and4b. (bitwise and)
+|HEXSTRING operator&(const HEXSTRING_ELEMENT&) const  |
+|HEXSTRING operator|(const HEXSTRING&) const  |C++ equivalent of operator
+or4b. (bitwise or)
+|HEXSTRING operator|(const HEXSTRING_ELEMENT&) const  |
+|HEXSTRING operatorˆ(const HEXSTRING&) const |C++ equivalent of operator
+xor4b. (bitwise xor)
+|HEXSTRING operatorˆ(const HEXSTRING_ELEMENT&) const |
+.3+^.^|_Other member functions_
+|`unsigned char get_nibble() const` |Returns the referenced nibble (stored in the lower 4 bits of the returned character).
+|`void log() const` |Puts the value into log.
+Example: '8'H.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|===========================================================================================================================================================
+
+Using the value of an unbound `HEXSTRING_ELEMENT` variable for anything will cause dynamic test case error.
+
+=== `Octetstring`
+
+The equivalent C++ class of TTCN–3 type `octetstring` is called `OCTETSTRING`. The octets are stored in an array of unsigned characters. Each character contains one octet; the first character is the first octet of the string. The character array is not terminated by a `NUL` character, so the length of the octet string must be always given.
+
+The class `OCTETSTRING` has the following public member functions:
+
+.Public member functions of the class `OCTETSTRING`
+
+[width="100%",cols=",,",options="header",]
+|==============================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Constructors_
+|`OCTETSTRING()` |Initializes to unbound value.
+|`OCTETSTRING(int n_octets, const unsigned char *octets_ptr)` |Initializes from a given length and pointer to character array.
+|`OCTETSTRING(const OCTETSTRING&)` |Copy constructor.
+|`OCTETSTRING(const OCTETSTRING_ELEMENT&)` |Initializes from a single octetstring element.
+^.^|_Destructor_
+|`ËœOCTETSTRING()` |
+.2+^.^|_Assignment operators_
+|`OCTETSTRING& operator=(const OCTETSTRING&)` |Assigns the given value and sets the bound flag.
+|`OCTETSTRING& operator=(const OCTETSTRING_ELEMENT&)` |Assigns the given octetstring element.
+.4+^.^|_Comparison operators_
+| boolean operator==(const OCTETSTRING&) const  |Returns TRUE if equals
+| boolean operator==(const OCTETSTRING_ELEMENT&) const  |and FALSE otherwise.
+| boolean operator!=(const OCTETSTRING&) const  |
+| boolean operator!=(const OCTETSTRING_ELEMENT&) const  |
+.4+^.^|_Concatenation operator_
+|OCTETSTRING operator+(const OCTETSTRING&) const |Concatenates two octetstrings.
+|OCTETSTRING operator+(const OCTETSTRING_ELEMENT&) const |Concatenates an octetstring and an octetstring element.
+|OCTETSTRING& operator+=(const OCTETSTRING&) const |Appends an octetstring to this one.
+|OCTETSTRING& operator+=(const OCTETSTRING_ELEMENT&) const |Appends an octetstring element to this octetstring.
+.4+^.^|_Index operator_
+|OCTETSTRING_ELEMENT operator[](int) |Gives access to the given element. Indexing begins from zero. Index overflow causes dynamic test case error.
+|OCTETSTRING_ELEMENT operator[](const INTEGER&) |
+|const OCTETSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
+|const OCTETSTRING_ELEMENT operator[](const INTEGER&) const |
+.8+^.^|_Bitwise operators_
+|OCTETSTRING operator˜() const  |C++ equivalent of operator not4b.(bitwise negation)
+|OCTETSTRING operator&(const OCTETSTRING&) const |C++ equivalent of operator and4b.
+(bitwise and)
+|OCTETSTRING operator&(const OCTETSTRING_ELEMENT&) const |
+|OCTETSTRING operator|(const OCTETSTRING&) const  |C++ equivalent of operator or4b.
+(bitwise or)
+|OCTETSTRING operator|(const OCTETSTRING_ELEMENT&) const |
+|OCTETSTRING operatorˆ(const OCTETSTRING&) const |C++ equivalent of operator xor4b.
+(bitwise xor)
+|OCTETSTRING operator^(const OCTETSTRING_ELEMENT&) const |
+.8+^.^|_Shifting and rotating operators_
+|OCTETSTRING operator<<(int) const |C++ equivalent of operator <<.
+|OCTETSTRING operator<<(const INTEGER&) const |(shift left)
+|OCTETSTRING operator>>(int) const  |C++ equivalent of operator >>.
+|OCTETSTRING operator>>(const INTEGER&) const  |(shift right)
+|OCTETSTRING operator<<=(int) const  |C++ equivalent of operator < @.
+|OCTETSTRING operator<<=(const INTEGER&) const  |(rotate left)
+|OCTETSTRING operator>>=(int) const  |C++ equivalent of operator @ >.
+|OCTETSTRING operator>>=(const INTEGER&) const  |(rotate right)
+^.^|_Casting operator_
+|operator const unsigned char*() const |Returns a pointer to the character array. The pointer might be NULL if the length is 0.
+.4+^.^|_Other member functions_
+|`int lengthof() const`  |Returns the length measured in octets.
+|`void log() const` |Puts the value into log.
+Like ’073CF0’O.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|==============================================================================================================================
+
+Using the value of an unbound `OCTETSTRING` variable for anything will cause dynamic test case error.
+
+==== `Octetstring` element
+
+The C++ class `OCTETSTRING_ELEMENT` is the equivalent of the TTCN-3 `octetstring`’s element type (the result of indexing an `octetstring` value). The class does not store the actual octet, only a reference to the original OCTETSTRING object, an index value and a bound flag.
+
+Note: changing the value of the OCTETSTRING_ELEMENT (through the assignment operator) changes the referenced octet in the original `octetstring` object.
+
+The class `OCTETSTRING_ELEMENT` has the following public member functions:
+
+.Public member functions of the class `OCTETSTRING_ELEMENT`
+
+[width="100%",cols=",,",options="header",]
+|================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+^.^|_Constructor_
+|`OCTETSTRING_ELEMENT(boolean par_bound_flag`, `OCTETSTRING& par_str_val`, `int par_octet_pos)` |Initializes the object with an unbound value or a reference to an octet in an existring OCTETSTRING object.
+.2+^.^|_Assignment operators_
+|`OCTETSTRING_ELEMENT& operator=(const OCTETSTRING&)` |Sets the referenced octet to the given octetstring of length 1.
+|`OCTETSTRING_ELEMENT& operator=(const OCTETSTRING_ELEMENT&)` |Sets the referenced octet to the given octetstring element.
+.4+^.^|_Comparison operators_
+|boolean operator==(const OCTETSTRING&) const |Comparison with an octetstring or an octetstring element (the value of the referenced octets is compared, not the references and indexes).
+|boolean operator==(const OCTETSTRING_ELEMENT&) const  |
+|boolean operator!=(const OCTETSTRING&) const |
+|boolean operator!=(const OCTETSTRING_ELEMENT&) const  |
+.2+^.^|_Concatenation operator_
+| OCTETSTRING operator+(const OCTETSTRING&) const |Concatenates an octetstring element with an octetstring, or two octetstring elements.
+| OCTETSTRING operator+(const OCTETSTRING_ELEMENT&) const |
+.8+^.^|_Bitwise operators_
+|OCTETSTRING operator~() const |C++ equivalent of operator (bitwise negation)
+|OCTETSTRING operator&(const OCTETSTRING&) const |C++ equivalent of operator
+and4b. (bitwise and)
+|OCTETSTRING operator&(const OCTETSTRING_ELEMENT&) const  |
+|HEXSTRING operator|(const OCTETSTRING&) const  | C++ equivalent of operator
+or4b. (bitwise or)
+|OCTETSTRING operator|(const OCTETSTRING_ELEMENT&) const  |
+|OCTETSTRING operatorˆ(const OCTETSTRING&) const |C++ equivalent of operator
+xor4b. (bitwise xor)
+|OCTETSTRING operatorˆ(const OCTETSTRING_ELEMENT&) const |
+.3+^.^|_Other member functions_
+|`unsigned char get_octet() const` |Returns the referenced octet.
+|`void log() const` |Puts the value into log.
+Example: '3C'O.
+|`boolean is_bound() const` |Returns whether the value is bound.
+
+|================================================================================================================================================================
+
+Using the value of an unbound `OCTETSTRING_ELEMENT` variable for anything will cause dynamic test case error.
+
+=== `Char`
+
+The `char` type, which has been removed from the TTCN–3 standard, is no longer supported by the run-time environment. The compiler substitutes all occurrences of `char` type with type `charstring` automatically.
+
+To provide partial backward compatibility for older Test Ports that might have used the type `char`, `CHAR` is a typedef alias to class `CHARSTRING` in C++.
+
+[[Charstring]]
+=== `Charstring`
+
+The equivalent C++ class of TTCN–3 type `charstring` is called `CHARSTRING`. The characters are stored in a `NUL` character terminated array; thus, giving the length in the constructor and other operations is optional.
+
+The class `CHARSTRING` has the following public member functions:
+
+.Public member functions of the class `CHARSTRING`
+
+[width="100%",cols=",,",,]
+|==============================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.6+^.^|_Constructors_
+|`CHARSTRING()`|Initializes to unbound value.
+|`CHARSTRING(char)`|Initializes from a single character.
+|`CHARSTRING(int n_chars, const char *chars_ptr)`|Initializes from a given length and pointer to character array.
+|`CHARSTRING(const char *chars_ptr)`|Initializes from a given character array. The end is noted by a NUL character.
+|`CHARSTRING(const CHARSTRING&)`|Copy constructor.
+|`CHARSTRING(const CHARSTRING_ELEMENT&)`|Initializes from a charstring element.
+^.^|_Destructor_
+|`ËœCHARSTRING()` |
+.4+^.^|_Assignment operators_
+|`CHARSTRING& operator=(const CHARSTRING&)`|Assigns the given value and sets the bound flag.
+|`CHARSTRING& operator=(const char *)`|Assigns the NUL terminated string.
+|`CHARSTRING& operator=(const CHARSTRING_ELEMENT&)`|Assigns the given charstring element.
+|`CHARSTRING& operator=(const UNIVERSAL_CHARSTRING&)`|Assigns the given universal charstring value.
+.8+^.^|_Comparison operators_
+|boolean operator==(const CHARSTRING&) const  |Returns TRUE if equals and FALSE otherwise.
+|boolean operator==(const char *) const |Compares to the NUL terminated string.
+|boolean operator==(const CHARSTRING_ELEMENT&) const |Comparison with a charstring element.
+|boolean operator==(const UNIVERSAL_CHARSTRING&) const |Comparison with a universal charstring.
+|boolean operator==(const UNIVERSAL_CHARSTRING_ELEMENT&) const |Comparison with a universal charstring element.
+|boolean operator!=(const CHARSTRING&) const  |
+|boolean operator!=(const char *) const |
+|boolean operator!=(const CHARSTRING_ELEMENT&) const |
+.9+^.^|_Concatenation operator_
+|CHARSTRING operator+(const CHARSTRING&) const  |Concatenates two charstrings.
+|CHARSTRING operator+(const char *) const |Concatenates with a NUL terminated string.
+|CHARSTRING operator+(const CHARSTRING_ELEMENT) const |Concatenates with a charstring element.
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING&) const |Concatenates with a universal charstring.
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING_ELEMENT&) const |Concatenates with a universal charstring element.
+|CHARSTRING operator+=(char) |Appends a character.
+|CHARSTRING operator+=(const char *) |Appends a NUL terminated string.
+|CHARSTRING operator+=(const CHARSTRING&) |Appends a charstring.
+|CHARSTRING operator+=(const CHARSTRING_ELEMENT&) |Appends a charstring element.
+.4+^.^|_Index operator_
+|CHARSTRING_ELEMENT operator[](int) |Gives access to the given element. Indexing begins from zero. Index overflow causes dynamic test case error.
+|CHARSTRING_ELEMENT operator[](const INTEGER&) |
+|const CHARSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
+|const CHARSTRING_ELEMENT operator[](const INTEGER&) const |
+.4+^.^|_Rotating operators_
+|CHARSTRING operator<<=(int) const |C++ equivalent of operator < @.(rotate left)
+|CHARSTRING operator<<=(const INTEGER&) const |
+|CHARSTRING operator>>=(int) const  |C++ equivalent of operator @ >.
+(rotate right)
+|CHARSTRING operator>>=(const INTEGER&) const |
+^.^|_Casting operator_
+|operator const char*() const |Returns a pointer to the character array. The string is always terminated by NUL.
+.3+^.^|_Other member functions_
+|`int lengthof() const` |Returns the length measured in characters not including the terminator NUL.
+|`void log() const` |Puts the value into log.
+Example: ”abc”.
+|`boolean is_bound() const`|Returns whether the value is bound.
+|`void clean_up()`|Deletes the value, setting it to unbound.
+
+|==============================================================================================================================
+
+The comparison, concatenation and rotating operators are also available as global functions for that case when the left side is `const char*` and the right side is `CHARSTRING`.
+
+The log() member function uses single character output for regular characters, but special characters (such as the quotation mark, backslash or newline characters) are printed using the escape sequences of the C language. Non-printable control characters are printed in TTCN–3 quadruple notation, where the first three octets are always zero. The concatenation operator (`&`) is used between the fragments when necessary. Note that the output does not always conform to TTCN–3 Core Language syntax, but it is always recognized by both our compiler and the configuration file parser.
+
+Using the value of an unbound `CHARSTRING` variable for anything will cause dynamic test case error.
+
+Other operators (global functions):
+[source]
+----
+boolean operator==(const char* string_value,
+                     const CHARSTRING& other_value);            // Equal
+boolean operator==(const char* string_value,
+                     const CHARSTRING_ELEMENT& other_value);    // Equal
+boolean operator!=(const char* string_value,
+                     const CHARSTRING& other_value);            // Not equal
+boolean operator!=(const char* string_value,
+                     const CHARSTRING_ELEMENT& other_value);    // Not equal
+CHARSTRING operator+(const char* string_value,
+                       const CHARSTRING& other_value);          // Concatenation
+CHARSTRING operator+(const char* string_value,
+                       const CHARSTRING_ELEMENT& other_value);  // Concatenation
+----
+
+==== `Charstring` element
+
+The C++ class `CHARSTRING_ELEMENT` is the equivalent of the TTCN-3 `charstring`’s element type (the result of indexing a `charstring` value). The class does not store the actual character, only a reference to the original CHARSTRING object, an index value and a bound flag.
+
+Note: changing the value of the `CHARSTRING_ELEMENT` (through the assignment operator) changes the referenced character in the original `charstring` object.
+
+The class `CHARSTRING_ELEMENT` has the following public member functions:
+
+.Public member functions of the class `CHARSTRING_ELEMENT`
+
+[width="100%",cols=",,",options="",]
+|================================================================================================================================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+^.^|_Constructor_
+|`CHARSTRING_ELEMENT(boolean par_bound_flag`, `CHARSTRING& par_str_val`, `int par_char_pos)` |Initializes the object with an unbound value or a reference to a character in an existring CHARSTRING object.
+.3+^.^|_Assignment operators_
+|`CHARSTRING_ELEMENT& operator=(const char*)` |Sets the referenced character to the given null-terminated string of length 1.
+|`CHARSTRING_ELEMENT& operator=(const CHARSTRING&)` |Sets the referenced character to the given charstring of length 1.
+|`CHARSTRING_ELEMENT& operator=(const CHARSTRING_ELEMENT&)` |Sets the referenced character to the given charstring element.
+.8+^.^|_Comparison operators_
+|boolean operator==(const char*) const |Comparison with a null-terminated string, a charstring, a universal charstring, a charstring element or a universal charstring element (when comparing element types, the value of the referenced characters is compared, not the references and indexes).
+|boolean operator==(const CHARSTRING&) const |
+|boolean operator==(const CHARSTRING_ELEMENT&) const  |
+|boolean operator==(const UNIVERSAL_CHARSTRING&) const |
+|boolean operator==(const UNIVERSAL_CHARSTRING_ELEMENT&) const |
+|boolean operator!=(const char*) const  |
+|boolean operator!=(const CHARSTRING&) const |
+|boolean operator!=(const CHARSTRING_ELEMENT&) const  |
+.5+^.^|_Concatenation operator_
+|CHARSTRING operator+(const char*) const  |Concatenates this object with a null-terminated string, a charstring, a charstring element, a universal charstring or a universal charstring element.
+|CHARSTRING operator+(const CHARSTRING&) const |
+|CHARSTRING operator+(const CHARSTRING_ELEMENT&) const |
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING&) const |
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING_ELEMENT&) const  |
+.3+^.^|_Other member functions_
+|`char get_char() const` |Returns the referenced character.
+|`void log() const` |Puts the value into log. Example: “a”.
+|`boolean is_bound() const` |Returns whether the value is bound.
+
+|================================================================================================================================================================================================================================================================================
+
+Using the value of an unbound `CHARSTRING_ELEMENT` variable for anything will cause dynamic test case error.
+
+=== `Universal char`
+
+This obsolete TTCN–3 type is converted automatically to `universal charstring` in the parser.
+
+=== `Universal charstring`
+
+Each character of a `universal charstring` value is represented in the following C structure defined in the Base Library:
+[source]
+----
+struct universal_char {
+  unsigned char uc_group, uc_plane, uc_row, uc_cell;
+};
+----
+
+The four components of the quadruple (that is, group, plane, row and cell) are stored in fields `uc_group`, `uc_plane`, `uc_row` and `uc_cell`, respectively. All fields are 8bit unsigned numeric values with the possible value range 0 .. 255.
+
+In case of single-octet characters, which can be also given in TTCN–3 charstring notation (between quotation marks), the fields `uc_group`, `uc_plane`, `uc_row` are set to zero. If tuple notation was used for an ASN.1 string value fields `uc_row` and `uc_cell` carry the tuple and the others are set to zero.
+
+Except when performing encoding or decoding, the run-time environment does not check whether the quadruples used in the following API represent valid character positions according to <<7-references.adoc#_8,[8]>>. Moreover, if ASN.1 multi-octet character string values are used, it is not verified whether the elements of such strings are permitted characters of the corresponding string type.
+
+The C++ equivalent of TTCN–3 type `universal charstring` is implemented in class `UNIVERSAL_CHARSTRING`. The characters of the string are stored in an array of structure `universal_char`. The array returned by the casting operator is not terminated with a special character, thus, the length of the string must be always considered when doing operations with the array. The length of the string, which can be obtained by using member function `lengthof()`, is measured in characters (quadruples) and not bytes.
+
+For the more convenient usage the strings containing only single-octet characters can also be used with class `UNIVERSAL_CHARSTRING`. Therefore some polymorphic member functions and operators have variants that take `const char*` as argument. In these member functions the characters of the `NUL` character terminated string are implicitly converted to quadruples with group, plane and row fields set to zero. `NULL` pointer as argument means the empty string for these functions.
+
+The class `UNIVERSAL_CHARSTRING` has the following public member functions:
+
+.Public member functions of the class `UNIVERSAL_CHARSTRING`
+
+[width="100%",cols=",,",options="",]
+|==============================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.10+^.^|_Constructors_
+|`UNIVERSAL_CHARSTRING()`|Initializes to unbound value.
+|`UNIVERSAL_CHARSTRING (unsigned char group, unsigned char plane, unsigned char row, unsigned char cell)`| Constructs a string containing one character formed from the given quadruple.
+|`UNIVERSAL_CHARSTRING (const universal_char&)`| Constructs a string containing the given single character.
+|`UNIVERSAL_CHARSTRING (int n_uchars, const universal_char *uchars_ptr)`| Constructs a string from an array by taking the given number of single-octet characters.
+|`UNIVERSAL_CHARSTRING (const char *chars_ptr)`| Constructs a string from a NUL terminated array of single-octet characters.
+|`UNIVERSAL_CHARSTRING (int n_chars, const char *chars_ptr)`| Constructs a string from a given number of single-octet characters.
+|`UNIVERSAL_CHARSTRING (const CHARSTRING&)`| Constructs a universal charstring from a charstring value.
+|`UNIVERSAL_CHARSTRING (const CHARSTRING_ELEMENT&)`| Constructs a string containing the given singe charstring element.
+|`UNIVERSAL_CHARSTRING (const UNIVERSAL_CHARSTRING&)`| Copy constructor.
+|`UNIVERSAL_CHARSTRING (const UNIVERSAL_CHARSTRING_ELEMENT&)`| Constructs a string containing the given singe universal charstring element.
+^.^|_Destructor_
+|`ËœUNIVERSAL_CHARSTRING()` |
+.6+^.^|_Assignment operators_
+|`UNIVERSAL_CHARSTRING& operator= (const UNIVERSAL_CHARSTRING&)`  |Assigns another string.
+|`UNIVERSAL_CHARSTRING& operator= (const universal_char&)` |Assigns a single character.
+|`UNIVERSAL_CHARSTRING& operator= (const char*)` |Assigns a NUL terminated
+single-octet string.
+|`UNIVERSAL_CHARSTRING& operator= (const CHARSTRING&)` |Assigns a charstring.
+|`UNIVERSAL_CHARSTRING& operator= (const CHARSTRING_ELEMENT&)` |Assigns a single charstring element.
+|`UNIVERSAL_CHARSTRING& operator= (const UNIVERSAL_CHARSTRING_ELEMENT&)` |Assigns a single universal charstring element.
+.12+^.^|_Comparison operators_
+|boolean operator==(const UNIVERSAL_CHARSTRING&) const  |Returns TRUE if the strings are identical or FALSE otherwise.
+|boolean operator==(const universal_char&) const  |Compares to a single character.
+|boolean operator==(const char*) const |Compares to a NUL terminated printable string.
+|boolean operator==(const CHARSTRING&) const |Compares to a charstring.
+|boolean operator==(const CHARSTRING_ELEMENT&) const |Compares to a charstring element.
+|boolean operator==(const UNIVERSAL_CHARSTRING_ELEMENT&) const |Compares to a universal charstring element.
+|boolean operator!=(const UNIVERSAL_CHARSTRING&) const  |
+|boolean operator!= (const universal_char&) const  |
+|boolean operator!=(const char*) const  |
+|boolean operator!=(const CHARSTRING&) |
+|boolean operator!=(const CHARSTRING_ELEMENT&) const |
+|boolean operator!=(const UNIVERSAL_CHARSTRING_ELEMENT&) const |
+.6+^.^|_Concatenation operator_
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING&) const  |Concatenates two strings.
+|UNIVERSAL_CHARSTRING operator+(const universal_char&) const  |Concatenates a single character.
+|UNIVERSAL_CHARSTRING operator+(const char*) const  |Concatenates a NUL terminated single-octet string.
+|UNIVERSAL_CHARSTRING operator+(const CHARSTRING&) const |Concatenates a charstring.
+|UNIVERSAL_CHARSTRING operator+(const CHARSTRING_ELEMENT&) const |Concatenates a charstring element.
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING_ELEMENT&) const  |Concatenates a universal charstring element.
+.4+^.^|_Index operator_
+|UNIVERSAL_CHARSTRING_ELEMENT operator[](int) |Gives access to the given element. Indexing begins from zero. Index overflow causes dynamic test case error.
+|UNIVERSAL_CHARSTRING_ELEMENT operator[](const INTEGER&) |
+|const UNIVERSAL_CHARSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
+|const UNIVERSAL_CHARSTRING_ELEMENT operator[](const INTEGER&) const |
+.4+^.^|_Rotating operators_
+|UNIVERSAL_CHARSTRING operator<<=(int) const |C++ equivalent of operator < @(rotate left).
+|UNIVERSAL_CHARSTRING operator<<=(const INTEGER&) const |
+|UNIVERSAL_CHARSTRING operator>>=(int) const |C++ equivalent of operator @ >
+(rotate right).
+|UNIVERSAL_CHARSTRING operator>>=(const INTEGER&) const |
+^.^|_Casting operator_
+|operator const universal_char*() const |Returns a pointer to the array of characters. There is no terminator character at the end.
+.2+^.^|_UTF-8 encoding and decoding_
+|void encode_utf8(TTCN_Buffer& buf) const |Appends the UTF-8 representation of the string to the given buffer
+|void decode_utf8(int n_octets, const unsigned char *octets_ptr) |
+.4+^.^|_Other member functions_
+|`int lengthof() const` |Returns the length measured in characters.
+|`boolean is_bound() const ` |Returns whether the value is bound.
+|`void log() const` |Puts the value into log. See below.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|==============================================================================================================================
+
+The comparison and concatenation operators are also available as global functions for that case when the left operand is a single-octet string (`const char*`) or a single character (`const universal_char&`) and the right side is `UNIVERSAL_CHARSTRING` value. Using the value of an unbound `UNIVERSAL_CHARSTRING` variable for anything causes dynamic test case error.
+
+The `UNIVERSAL_CHARSTRING` variable used with the `decode_utf8()` method must be newly constructed (unbound) or `clean_up()` must have been called, otherwise a memory leak will occur.
+
+The logged printout of universal charstring values is compatible with the TTCN–3 notation for such strings. The format to be used depends on the contents of the string. Each character (quadruple) is classified whether it is directly printable or not. The string is fragmented based on this classification. Each fragment consists of either a single non-printable character or a maximal length contiguous sequence of printable characters. The fragments are logged one after another separated by an `&` character (concatenation operator). The printable fragments use the normal charstring notation; the non-printable characters are logged in the TTCN–3 quadruple notation. An empty universal charstring value is represented by a pair of quotation marks (like in case of empty charstring values).
+
+An example printout in the log can be the following. The string consists of two fragments of printable characters and a non-printable quadruple, which stands for Hungarian letter "ű":
+[source, subs="+quotes"]
+"Character " & char(0, 0, 1, 113) & " is a letter of Hungarian alphabet"
+
+Other operators (global functions):
+[source]
+----
+boolean operator==(const universal_char& left_value,
+                     const universal_char& right_value);                 // Equal
+boolean operator==(const universal_char& uchar_value,
+                     const UNIVERSAL_CHARSTRING& other_value);           // Equal
+boolean operator==(const char* string_value,
+                     const UNIVERSAL_CHARSTRING& other_value);           // Equal
+boolean operator==(const universal_char& uchar_value,
+                     const UNIVERSAL_CHARSTRING_ELEMENT& other_value);   // Equal
+boolean operator==(const char* string_value,
+                     const UNIVERSAL_CHARSTRING_ELEMENT& other_value);   // Equal
+boolean operator!=(const universal_char& left_value,
+                     const universal_char& right_value);             // Not equal
+boolean operator!=(const universal_char& uchar_value,
+                     const UNIVERSAL_CHARSTRING& other_value);       // Not equal
+boolean operator!=(const char* string_value,
+                     const UNIVERSAL_CHARSTRING& other_value);       // Not equal
+boolean operator!=(const universal_char& uchar_value,
+              const UNIVERSAL_CHARSTRING_ELEMENT& other_value);      // Not equal
+boolean operator!=(const char* string_value,
+              const UNIVERSAL_CHARSTRING_ELEMENT& other_value);      // Not equal
+boolean operator<(const universal_char& left_value,
+         const universal_char& right_value& other_value); // Character comparison
+UNIVERSAL_CHARSTRING operator+(const universal_char& uchar_value,
+             const UNIVERSAL_CHARSTRING& other_value);           // Concatenation
+UNIVERSAL_CHARSTRING operator+(const char* string_value,
+             const UNIVERSAL_CHARSTRING& other_value);           // Concatenation
+UNIVERSAL_CHARSTRING operator+(const universal_char& uchar_value,
+             const UNIVERSAL_CHARSTRING_ELEMENT& other_value);   // Concatenation
+UNIVERSAL_CHARSTRING operator+(const char* string_value,
+             const UNIVERSAL_CHARSTRING_ELEMENT& other_value);   // Concatenation
+----
+
+==== `Universal charstring` element
+
+The C++ class `UNIVERSAL_CHARSTRING_ELEMENT` is the equivalent of the TTCN-3 `universal charstring`’s element type (the result of indexing a `universal charstring` value). The class does not store the actual character, only a reference to the original `UNIVERSAL_CHARSTRING` object, an index value and a bound flag.
+
+Note: changing the value of the `UNIVERSAL_CHARSTRING_ELEMENT` (through the assignment operator) changes the referenced character in the original `universal charstring` object.
+
+The class `UNIVERSAL_CHARSTRING_ELEMENT` has the following public member functions:
+
+.Public member functions of the class `UNIVERSAL_CHARSTRING_ELEMENT`
+
+[width="100%",cols=",,",options="",]
+|=======================================================================================================================================================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+^.^|_Constructor_
+|`UNIVERSAL_CHARSTRING_ELEMENT(boolean par_bound_flag`, `UNIVERSAL_CHARSTRING& par_str_val, int par_uchar_pos)` |Initializes the object with an unbound value or a reference to a character in an existring UNIVERSAL_CHARSTRING object.
+.6+^.^|_Assignment operators_
+|`UNIVERSAL_CHARSTRING_ELEMENT& operator=(const universal_char&)` |Sets the referenced character to the given universal character.
+|`UNIVERSAL_CHARSTRING_ELEMENT& operator=(const char*)` |
+|`UNIVERSAL_CHARSTRING_ELEMENT& operator=(const CHARSTRING&)` |
+|`UNIVERSAL_CHARSTRING_ELEMENT& operator=(const CHARSTRING_ELEMENT&)` |
+|`UNIVERSAL_CHARSTRING_ELEMENT& operator=(const UNIVERSAL_CHARSTRING&)` |
+|`UNIVERSAL_CHARSTRING_ELEMENT& operator=(const UNIVERSAL_CHARSTRING_ELEMENT&)` |
+.12+^.^|_Comparison operators_
+|boolean operator==(const universal_char&) const |Comparison with a universal character, a null-terminated string, a charstring, a universal charstring, a charstring element or a universal charstring element (when comparing element types, the value of the referenced characters is compared, not the references and indexes).
+|boolean operator==(const char*) const |
+|boolean operator==(const CHARSTRING&) const |
+|boolean operator==(const CHARSTRING_ELEMENT&) const  |
+|boolean operator==(const UNIVERSAL_CHARSTRING&) const |
+|boolean operator==(const UNIVERSAL_CHARSTRING_ELEMENT&) const |
+|boolean operator!=(const universal_char&) const |
+|boolean operator!=(const char*) const |
+|boolean operator!=(const CHARSTRING&) const |
+|boolean operator!=(const CHARSTRING_ELEMENT&) const  |
+|boolean operator!=(const UNIVERSAL_CHARSTRING&) const |
+|boolean operator!=(const UNIVERSAL_CHARSTRING_ELEMENT&) const |
+.6+^.^|_Concatenation operator_
+|CHARSTRING operator+(const universal_char&) const |Concatenates this object with a universal character, a null-terminated string, a charstring, a charstring element, a universal charstring or a universal charstring element.
+|CHARSTRING operator+(const char*) const |
+|CHARSTRING operator+(const CHARSTRING&) const |
+|CHARSTRING operator+(const CHARSTRING_ELEMENT&) const |
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING&) const |
+|UNIVERSAL_CHARSTRING operator+(const UNIVERSAL_CHARSTRING_ELEMENT&) const  |
+.3+^.^|_Other member functions_
+|`const universal_char& get_char() const` |Returns the referenced character.
+|`void log() const` |Puts the value into log. Example: “a” or char(0, 0, 1, 113).
+|`boolean is_bound() const` |Returns whether the value is bound.
+|=======================================================================================================================================================================================================================================================================================================
+
+Using the value of an unbound `UNIVERSAL_CHARSTRING_ELEMENT` variable for anything will cause dynamic test case error.
+
+=== Object Identifier Type
+
+The object identifier type of TTCN–3 (`objid`) is implemented in class OBJID. In the run-time environment the components of object identifier values are represented in NumberForm, that is, in integer values. The values of components are stored in an array with a given length. The type of the components is specified with a `typedef`, `objid_element`. Class `OBJID` has the following member functions.
+
+.Public member functions of the class `OBJID`
+
+[width="100%",cols=",,",options="header",]
+|=====================================================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Constructors_
+|`OBJID()` |Initializes to unbound value.
+|`OBJID(int n_components, const objid_element *components_ptr)` |Initializes the number of components to n components and copies all components from an array of integers starting at components_ptr.
+|`OBJID(int n_components, ...)` |Initializes the number of components to n_components. The components themselves shall be given as additional integer arguments after each other, starting with the first one.
+|OBJID(const OBJID&) |Copy constructor.
+^.^|_Destructor_
+|`ËœOBJID()` |
+^.^|_Assignment operator_
+|`OBJID& operator=(const OBJID&)` |Assigns the given value and sets the bound flag.
+.2+^.^|_Comparison operators_
+|boolean operator==(const OBJID&) const |Returns TRUE if the two values are equal and FALSE otherwise.
+|boolean operator!=(const OBJID&) const |
+.2+^.^|_Indexing operators_
+|objid_element& operator[](int i)  |Returns a reference to the _i th_ component.
+|const objid_element & operator[](int i) const |Returns a read-only reference to the i th component.
+^.^|_Casting operator_
+|operator const objid_element *() const  |Returns a pointer to the read-only array of components.
+|_Other member functions_
+|`int lengthof() const` |Returns the number of components.
+|`void log() const` |Puts the value into log in NumberForm. Like this: “objid 0 4 0 ”.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|=====================================================================================
+
+NOTE: The constructor with variable number of arguments is useful in situations when the number of components is constant and known at compile time.
+
+Using the value of an unbound `OBJID` variable for anything will cause dynamic test case error.
+
+=== Component References
+
+TTCN–3 variables the types of which are defined as component types are used for storing component references to PTCs. The internal representation of component references are test tool dependent, our test executor handles them as small integer numbers.
+
+All TTCN–3 component types are mapped to the same C++ class, which is called COMPONENT, using `typedef` aliases. We also use an ancillary C type called `component`, which is defined as an alias for `int`:
+[source, subs="+quotes"]
+typedef int component;
+
+There are some predefined constants of component references in TTCN–3. These are defined as C preprocessor macros in the following way:
+
+.Predefined component references
+
+[cols=",,",options="header",]
+|===================================================
+|TTCN–3 constant |Preprocessor symbol |Numeric value
+|null |NULL |COMPREF 0
+|mtc |MTC |COMPREF 1
+|system |SYSTEM |COMPREF 2
+|===================================================
+
+The class `COMPONENT` has the following public member functions:
+
+.Public member functions of the class `COMPONENT`
+
+[width="100%",cols=",,",options="",]
+|===========================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`COMPONENT()` |Initializes to unbound value.
+|`COMPONENT(component)` |Initializes to a given value.
+|`COMPONENT(const COMPONENT&)` |Copy constructor.
+^.^|_Destructor_
+|`COMPONENT()`|
+.2+^.^|_Assignment_ _operators_
+|`COMPONENT& operator=(component)`|Assigns the given value
+|`COMPONENT& operator=(const COMPONENT&)`|and sets the bound flag.
+.4+^.^|_Comparison operators_
+|boolean operator==(component) const  |Returns TRUE if equals
+|boolean operator==(const COMPONENT&) const |and FALSE otherwise.
+|boolean operator!=(component) const |
+|boolean operator!=(const COMPONENT&) const |
+^.^|_Casting operator_
+|operator component() const |Returns the value.
+.3+^.^|Other member functions
+|`void log() const` |Puts the value into log in decimal form or in symbolic format for special constants. Like 3 or mtc.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|===========================================================================================================================
+
+Component references are managed by MC. All new test components are given a unique reference that was never used in the test campaign before (not even in a previous test case). The new numbers are increasing monotonously. The reference of the firstly created component is 3; the next one will be 4, and so on.
+
+Using the value of an unbound component reference for anything will cause dynamic test case error.
+
+Other operators (global functions):
+[source]
+----
+boolean operator==(component component_value,
+                     const COMPONENT& other_value); // Equal
+boolean operator!=(component component_value,
+                     const COMPONENT& other_value); // Not equal
+----
+[[empty-types]]
+=== Empty Types
+
+Empty `record` and `set` types are not real built-in types in TTCN–3, but the C++ realization of these types also differs from regular records or sets. The empty types are almost identical to each other, only their names are different. That is why we treat them as predefined types.
+
+Each empty type is defined in a C\++ class, which is generated by the compiler. Using separate classes enables us to differentiate among them in C++ type polymorphism. For example, several empty types can be defined as incoming or outgoing types on the same TTCN–3 port type.
+
+Let us consider the following TTCN–3 type definition as an example:
+[source, subs="+quotes"]
+type record Dummy {};
+
+The generated class will rely on an enumerated C type null_type, which is defined as follows:
+[source, subs="+quotes"]
+enum null type {NULL VALUE };
+
+The only possible value stands for the TTCN–3 empty record or array value (that is for "{}"), which is the only possible value of TTCN–3 type `Dummy`. Note that this type and value is also used in the definition of `record` of and `set of` type construct.
+
+The generated C++ class `Dummy` will have the following member functions:
+
+.Public member functions of the class `Dummy`
+
+[width="100%",cols=",,",options="header",]
+|================================================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`Dummy()` |Initializes to unbound value.
+|`Dummy(null type)` |Initializes to the only possible value.
+|`Dummy(const Dummy&)` |Copy constructor.
+^.^|_Destructor_
+|`ËœDummy()` |
+.2+^.^|_Assignment operators_
+|`Dummy& operator=(null type)` |Assigns the only possible value and sets the bound flag.
+|`Dummy& operator=(const Dummy&)` |
+.4+^.^|_Comparison operators_
+|boolean operator==(Dummy) const  |Returns TRUE if both arguments are bound.
+|boolean operator==(const Dummy&) const |
+|boolean operator!=(address) const | Returns FALSE if both arguments are bound.
+|boolean operator!=(const Dummy&) const |
+.3+^.^|_Other member functions_
+|`void log() const` |Puts the value, that is, {}, into log.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+
+|================================================================================
+
+Setting the only possible value is important, because using the value of an unbound variable for anything will cause dynamic test case error.
+
+Other operators (global functions):
+[source]
+----
+boolean operator==(null_type null_value, const Dummy& other_value);// Equal
+boolean operator!=(null_type null_value, const Dummy& other_value);// Not equal
+----
+
+== Compound Data Types
+
+The user-defined compound data types are implemented in C++ classes. These classes are generated by the compiler according to type definitions. In contrast with the basic types, these classes can be found in the generated code.
+
+=== Record and Set Type Constructs
+
+The TTCN–3 type constructs `record` and `set` are mapped in an identical way to C\++. There will be a C++ class for each record type in the generated code. This class builds up the record from its fields.footnote:[This section deals with the record and set types that have at least one field. See <<empty-types, Empty Types>> for the C++ mapping of empty record and set types.] The fields can be either basic or compound types.
+
+Let us consider the following example type definition. The types `t1` and `t2` can be arbitrary.
+[source]
+----
+type record t3 {
+  t1 f1,
+  t2 f2
+}
+----
+
+The generated class `t3` will have the following public member functions:
+
+.Public member functions of the class `t3`
+
+[width="100%",cols=",,",options="",]
+|=====================================================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`t3()` |Initializes all fields to unbound value.
+|`t3(const t1& par_f1, const t2& par_f2)` |Initializes from given field values. The number of arguments equals to the number of fields.
+|`t3(const t3&)` |Copy constructor.
+^.^|_Destructor_
+|`Ëœt3()` |
+^.^|_Assignment operator_
+|`t3& operator=(const t3&)`  |Assigns the given value and setsthe bound flag for each field.
+.2+^.^|_Comparison operators_
+|boolean operator==(const t3&) const |Returns TRUE if all fields are equal and FALSE otherwise.
+|boolean operator!=(const t3&) const |
+.2+^.^|_Field access functions_
+|t1& f1();                     t2& f2(); |Gives access to the first/second field.
+|const t1& f1() const; const t2& f2() const; |The same, but it gives read-only access.
+.4+^.^|_Other member functions_
+|`int size_of() const` |Returns the size (number of fields).
+|`void log() const` |Puts the value into log. Like { f1 := 5, f2 := ”abc”}.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+|=====================================================================================
+
+The record value is unbound if one or more fields of it are unbound. Using the value of an unbound variable for anything (even for comparison) will cause dynamic test case error.
+
+==== Optional Fields in Records and Sets
+
+TTCN–3 permits optional fields in record and set type definitions. An optional field does not have to be always present, it can be omitted. But the omission must be explicitly denoted. Let us change our last example to this.
+[source]
+----
+type record t3 {
+  t1 f1,
+  t2 f2 optional
+}
+----
+
+The optional fields are implemented using a C++ template class called `OPTIONAL` that creates an optional value from any type. In the definition of the generated class `t3` the type `t2` will be replaced by `OPTIONAL<t2>` everywhere and anything else will not be changed.
+
+The instantiated template class `OPTIONAL<t2>` will have the following member functions:
+
+.Table Public member functions of the class `OPTIONAL<t2>`
+
+[width="100%",cols=",,",options="",]
+|================================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.8+^.^|_Constructors_
+|`OPTIONAL()` |Initializes to unbound value.
+|`OPTIONAL(template_sel init_val)` |Initializes to omit value, if the argument is OMIT VALUE.
+|`OPTIONAL(const t2& init_val)`  |Initializes to given value.
+|`OPTIONAL(const OPTIONAL& init_val)`  |Copy constructor.
+|`template <typename T_tmp> `|Initializes to given value of different (compatible) type.
+|`OPTIONAL(const OPTIONAL<T_tmp>&)` |
+|`template <typename T_tmp>` |Initializes to given optional value of different (compatible) type.
+|`OPTIONAL(const T_tmp&)` |
+^.^|_Destructor_
+|`ËœOPTIONAL()` |
+.6+^.^|_Assignment operators_
+|`OPTIONAL& operator=(template_sel)` |Assigns omit value, if the right value is OMIT VALUE.
+|`OPTIONAL& operator=(const OPTIONAL&)` |Assigns the given optional value.
+|`template <typename T_tmp>`|Assigns the given optional value of different (compatible) type.
+|`OPTIONAL& operator=(const OPTIONAL<T_tmp>&)`|
+|`template <typename T_tmp>` |Assigns the given value of different (compatible) type.
+|`OPTIONAL& operator=(const T_tmp&)` |
+.7+^.^|_Comparison operators_
+|boolean operator==(template_sel) const |Returns TRUE if the value is omit and the right side is OMIT VALUE or FALSE otherwise.
+|boolean operator==(const OPTIONAL&) const |Returns TRUE if the two values are equal or FALSE otherwise.
+|template <typename T_tmp> |Returns TRUE if the two values of different (compatible) types are equal or FALSE otherwise.
+|boolean operator!=(template_sel) const  |
+|boolean operator!=(const OPTIONAL&) const |
+|template <typename T_tmp> |
+|boolean operator!=(const OPTIONAL<T_tmp>&) const |
+.2+^.^|_Casting operators_
+|operator t2&() |Gives read-write access to the value. If the value was not previously present, sets the bound flag true and the value will be initialized to unbound.
+|operator const t2&() const |Gives read-only access to the value. If the value is not present, causes a dynamic test case error.
+.2+^.^|_Function call operators_
+|t2& operator()() |Gives read-write access to the value. If the value was not previously present, sets the bound flag true and the value will be initialized to unbound.
+|const t2& operator()() const |Gives read-only access to the value. If the value is not present, causes a dynamic test case error.
+.4+^.^|_Other member functions_
+|`boolean ispresent() const` |Returns TRUE if the value is present, FALSE if the value is omit or causes dynamic test case error if the value is unbound.
+|`void log() const` |Puts the optional value into log. Either ”omit” or the value of t2.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+|================================================================================================================================================================================
+
+In some member functions of the template class `OPTIONAL` the enumerated C type `template_sel` is used. It has many possible values, but in the optional class only `OMIT_VALUE` can be used, which stands for the TTCN–3 omit. Usage of other predefined values of `template_sel` will cause dynamic test case error.
+
+Using the value of an unbound optional field for anything will also cause dynamic test case error.
+
+=== Union Type Construct
+
+The TTCN–3 type construct union is implemented in a C++ class for each union type in the generated code. This class may contain any, but exactly one of its fields. The fields can be either basic or compound types or even identical types.
+
+Let us consider the following example type definition. The types `t1` and `t2` can be arbitrary.
+[source]
+----
+type union t3 {
+  t1 f1,
+  t2 f2
+}
+----
+
+An ancillary enumerated type is created in the generated class `t3`, which represents the selection:
+[source, subs="+quotes"]
+enum union_selection_type { UNBOUND_VALUE = 0, ALT_f1 = 1, ALT_f2 = 2 };
+
+The type `t3::union_selection_type` is used to distinguish the fields of the union. The predefined constant values are generated as `t3::ALT_`<field name>.
+
+The generated class `t3` will have the following public member functions:
+
+.Public member functions of the class `t3`
+
+[width="100%",cols=",,",options="header",]
+|=========================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.2+^.^|_Constructors_
+|`t3()` |Initializes to unbound value.
+|`t3(const t3&)` |Copy constructor.
+^.^|_Destructor_
+|`Ëœt3()` |
+^.^|_Assignment operator_
+|`t3& operator=(const t3&)` |Assigns the given value.
+.2+^.^|_Comparison operators_
+|boolean operator==(const t3&) const |Returns TRUE if the selections and field values are equal and FALSE otherwise.
+|boolean operator!=(const t3&) const |
+.4+^.^|_Field access functions_
+|const t1& f1() const  |Selects and gives access to the first field. If other field was previously selected, its value will be destroyed.
+|t1& f1() |Gives read-only access to the first field. If other field is selected, this function will cause a dynamic test case error. So use get_selection() first.
+|t2& f2() |
+|const t2& f2() const |
+.4+^.^|_Other member functions_
+|`union_selection_type get_selection() const` |Returns the current selection. It will return t3::UNBOUND VALUE if the value is unbound, t3::ALT_f1 if the first field was selected, and so on.
+|`void log() const` |Puts the value into log. Example: { f1 := 5 } or { f2 := "abc" }.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+|=========================================================================================================================================================================
+
+Using the value of an unbound `union` variable for anything will cause dynamic test case error.
+
+==== The anytype
+
+The TTCN-3 anytype is implemented as a C\++ class named anytype. The class is generated only if an actual anytype access is present in the module. It has the same interface as any other C++ class generated for a union, with a few differences:
+
+If a field is a built-in type or the address type, the name used in `union_selection_type` is the name of the runtime class implementing the type (usually the name of the type in all uppercase).
+
+If a field is a user-defined type, the mapping rules in <<mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> above apply.
+
+The names of field accessor functions are prefixed with AT_. This is necessary, because otherwise the accessor function looks like a constructor to C++.
+
+For example, for the following module
+[source]
+----
+module anyuser {
+  type record myrec {}
+
+  control {
+    var anytype v_at;
+  }
+}
+with {
+  extension “anytype integer, myrec, charstring”
+}
+----
+
+The generated class name will be "anytype". The union_selection_type enumerated type will be:
+[source, subs="+quotes"]
+enum union_selection_type { UNBOUND_VALUE = 0, ALT_INTEGER = 1, ALT_myrec = 2, ALT_CHARSTRING = 3 };
+
+The field accessor methods will be:
+[source]
+----
+INTEGER&    AT_INTEGER();
+myrec&      AT_myrec();
+CHARSTRING& AT_CHARSTRING();
+----
+
+=== Record of Type Construct
+
+The TTCN–3 type construct `record` of makes a variable length sequence from one given type. This construct is implemented as a C++ class.
+
+Let us consider the following example type definition. The type t1 can be arbitrary.
+[source, subs=+quotes]
+type record of t1 t2;
+
+This definition will be translated to a C++ class that will be called t2.
+
+There is an `enum` type called `null_type` defined in the Base Library that has only one possible value. NULL_VALUE stands for the empty `"record of"` value, that is, for {}.
+
+Class `t2` will have the following public member functions:
+
+.Public member functions of the class `t2`
+
+[width="100%",cols=",,",options="",]
+|==================================================================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.3+^.^|_Constructors_
+|`t2()` |Initializes to unbound value.
+|`t2(null type)` |Initializes to the empty value.
+|`t2(const t2&)` |Copy constructor.
+^.^|_Destructor_
+|`Ëœt2()` |
+.2+^.^|_Assignment operator_
+|`t2& operator=(null type)` |Assigns the empty value.
+|`t2& operator=(const t2&)` |Assigns the given value.
+.4+^.^|_Comparison operators_
+|boolean operator==(null type) const  |Returns TRUE if the two values are equal and FALSE otherwise.
+|boolean operator==(const t2&) const |
+|boolean operator!=(null type) const |
+|boolean operator!=(const t2&) const |
+.4+^.^|_Index operators_
+|t1& operator[](int) |Gives access to the given element. Indexing begins from zero. If this element of the variable was never used before, new (unbound) elements will be allocated up to (and including) this index.
+|t1& opetator[](const INTEGER&) |
+|const t1& operator[](int) const |Gives read-only access to the given element. Index overflow causes dynamic test case error.
+|const t1& opetator[](const INTEGER&) const |
+.4+^.^|_Rotating operators_
+|t2 operator<<=(int) |C++ equivalent of operator <@. (rotate left)
+|t2 operator<<=(const INTEGER&) |
+|t2 operator>>=(int) |C++ equivalent of operator @>. (rotate right)
+|t2 operator>>=(const INTEGER&) |
+^.^|_Concatenation operator_
+|t2 operator+(const t2&) const |Concatenates two arrays.
+.7+^.^|_Other member functions_
+|`int size_of() const` |Returns the number of elements, that is, the largest used index plus one and zero for the empty value.
+|`void set_size(int new_size)` |Sets the number of elements to the given value. If the value has fewer elements new (unbound) elements are allocated at the end. The excess elements at the end are erased if the value has more elements than necessary.
+|`t2 substr(int index, int returncount) const` |Returns the section of the array specified by the given start index and length.
+|`t2 replace(int index, int len, const t2& repl) const` |Returns a copy of the array, where the section indicated by the given start index and length is replaced by the given array.
+|`void log() const` |Puts the value into log. Like {1, 2, 3 }.
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+|==================================================================================================================================================================================================================
+
+A `record of` value is unbound if no value has been assigned to it or it has at least one unbound element. Using the value of an unbound `record of` variable for anything will cause dynamic test case error.
+
+Starting with the largest index improves performance when filling a `record of value`.
+
+Other operators (global functions):
+[source]
+----
+boolean operator==(null_type null_value, const t2& other_value); // Equal
+boolean operator!=(null_type null_value, const t2& other_value); // Not equal
+----
+
+==== Pre-generated `record of` and `set of` constructs
+
+The C\++ classes for the `record of` and `set of` constructs of most predefined TTCN-3 types are pre-generated and part of the TITAN runtime. Only a type alias (C++ `typedef`) is generated for instances of these types declared in TTCN-3 and ASN.1 modules. There is a class with regular memory allocation and one with optimized memory allocation pre-generated for each type. These classes are located in the `PreGenRecordOf` namespace.
+
+.Pre-generated classes for `record of`/`set of` predefined types
+
+[width="100%",cols="50%,50%",options="header",]
+|====================================================================================================================================
+|C++ class name |Equivalent type in TTCN-3
+|`PREGEN\__RECORD__OF__BOOLEAN` |`record of boolean`
+|`PREGEN\__RECORD__OF__INTEGER` |`record of integer`
+|`PREGEN\__RECORD__OF__FLOAT` |`record of float`
+|`PREGEN\__RECORD__OF__BITSTRING` |`record of bitstring`
+|`PREGEN\__RECORD__OF__HEXSTRING` |`record of hexstring`
+|`PREGEN\__RECORD__OF__OCTETSTRING` |`record of octetstring`
+|`PREGEN\__RECORD__OF__CHARSTRING` |`record of charstring`
+|`PREGEN\__RECORD__OF\__UNIVERSAL__CHARSTRING` |`record of universal charstring`
+|`PREGEN\__RECORD__OF\__BOOLEAN__OPTIMIZED` |`record of boolean with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__INTEGER__OPTIMIZED` |`record of integer with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__FLOAT__OPTIMIZED` |`record of float with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__BITSTRING__OPTIMIZED` |`record of bitstring with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__HEXSTRING__OPTIMIZED` |`record of hexstring with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__OCTETSTRING__OPTIMIZED` |`record of octetstring with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__CHARSTRING__OPTIMIZED` |`record of charstring with { extension "optimize:memalloc" }`
+|`PREGEN\__RECORD__OF\__UNIVERSAL__CHARSTRING__OPTIMIZED` |`record of universal charstring with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF__BOOLEAN` |`set of boolean`
+|`PREGEN\__SET__OF__INTEGER` |`set of integer`
+|`PREGEN\__SET__OF__FLOAT` |`set of float`
+|`PREGEN\__SET__OF__BITSTRING` |`set of bitstring`
+|`PREGEN\__SET__OF__HEXSTRING` |`set of hexstring`
+|`PREGEN\__SET__OF__OCTETSTRING` |`set of octetstring`
+|`PREGEN\__SET__OF__CHARSTRING` |`set of charstring`
+|`PREGEN\__SET__OF\__UNIVERSAL__CHARSTRING` |`set of universal charstring`
+|`PREGEN\__SET__OF\__BOOLEAN__OPTIMIZED` |`set of boolean with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__INTEGER__OPTIMIZED` |`set of integer with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__FLOAT__OPTIMIZED` |`set of float with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__BITSTRING__OPTIMIZED` |`set of bitstring with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__HEXSTRING__OPTIMIZED` |`set of hexstring with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__OCTETSTRING__OPTIMIZED` |`set of octetstring with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__CHARSTRING__OPTIMIZED` |`set of charstring with { extension "optimize:memalloc" }`
+|`PREGEN\__SET__OF\__UNIVERSAL__CHARSTRING__OPTIMIZED` |`set OF\ universal charstring with { extension "optimize:memalloc" }`
+|====================================================================================================================================
+
+=== `Set of` Type Construct
+
+The `set of` construct of TTCN–3 is implemented similarly to `record of`. The external interface of this class is exactly the same as in case of `record of`. For more details please see the previous section.
+
+In the internal implementation only the equality operator differs. Unlike in `record of`, it considers the unordered property of the `set of` type construct, that is, it returns `TRUE` if it is able to find exactly one pair for each element.
+
+The index is a unique identifier for a `set of` element because the C++ class does not reorder the elements when a new element is added or an element is modified. The copy constructor also keeps the original order of elements.
+
+=== Enumerated Types
+
+The TTCN–3 `enumerated` type construct is implemented as a C++ class with an embedded enum type.
+[source, subs="+quotes"]
+type enumerated Day { Monday (1), Tuesday, Wednesday (3) };
+
+The example above will result in the following, very similar C `enum` type definition which is embedded in the C++ class `Day`:
+[source, subs="+quotes"]
+
+enum enum_type { Monday = 1, Tuesday = 0, Wednesday = 3,
+       UNKNOWN_VALUE = 2, UNBOUND_VALUE = 4 };
+
+The automatic assignment of numeric values is done according to the standard. Note that there are two extra enumerated values in C, which stand for the unknown and unbound values. They are used in the conversion functions described below. The compiler assigns the smallest two non-negative integer numbers that are not used by the user-defined enumerated values to the unknown and unbound values.
+
+When using the C `enum` type and its values from user code the names must be prefixed with the C++ class name. The `enum` type in the above example can be referenced with `Day::enum_type`, its values can be accessed as `Day::Monday, Day::Tuesday`, and so on.
+
+The class `Day` will have the following public member functions:
+
+.Public member functions of the class `Day`
+
+[width="100%",cols=",,",options="",]
+|=========================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Constructors_
+|`Day()` |Initializes to unbound value.
+|`Day(int)` |Converts the given numeric value to Day::enum_type and initializes to it.
+Only valid values are accepted.
+|`Day(enum_type)` |Initializes to a given value.
+|`Day(const Day&)`  |Copy constructor.
+^.^|_Destructor_
+|`ËœDay()` |
+.3+^.^|_Assignment operator_
+|`Day& operator=(int)` |Converts the given numeric value to Day::enum_type and assigns it. Only valid values are accepted.
+|`Day& operator=(enum_type)` |Assigns the given value.
+|`Day& operator=(const Day&)` |
+.12+^.^|_Comparison operators_
+|boolean operator==(enum_type) const |Returns TRUE if the two values are equal and FALSE otherwise.
+|boolean operator==(const Day&) const |
+|boolean operator!=(enum_type) const |
+|boolean operator!=(const Day&) const |
+|boolean operator<(enum_type) const |
+|boolean operator<(const Day&) const |
+|boolean operator<=(enum_type) const |
+|boolean operator<=(const Day&) const |
+|boolean operator>(enum_type) const |
+|boolean operator>(const Day&) const |
+|boolean operator>=(enum_type) const |
+|boolean operator>=(const Day&) const |
+^.^|_Casting operator_
+|operator enum_type() const |Returns the enum_value.
+.5+^.^|_Static conversion functions_
+|static const char *enum_to_str(enum_type) |See below.
+|static enum_type str_to_enum(const char *)  |
+|static boolean is_valid_enum(int) |
+|static int enum2int(enum_type); |
+|static int enum2int(const Day&); |
+.3+^.^|_Non-static conversion functions_
+|int as_int() const; |See below
+|void from_int(int); |
+|void int2enum(int); |
+.3+^.^|_Other member functions_
+|`void log() const` |Puts the value into log. Like this: Monday
+|`boolean is_bound() const` |Returns whether the value is bound.
+|`void clean_up()` |Deletes the value, setting it to unbound.
+|=========================================================================================================================
+
+The static member function `Day::enum_to_str` converts the given parameter of type `Day::enum_type` to a NULL terminated C character string. It returns the string "<unknown>", if the input is not a valid value of the TTCN–3 enumerated type. The returned string is read-only, it must not be modified.
+
+The function `Day::str_to_enum` does the conversion in the reverse direction. It converts the symbolic enumerated identifier represented by a C character string back to the `Day::enum_type` equivalent. It returns the value `Day::UNKNOWN_VALUE` if the input string is not the equivalent of any of the possible values in the enumerated type. The behavior of this function is undefined if the input parameter does not point to an addressable memory area.
+
+In the above two functions the strings are treated case sensitive and they shall not contain any whitespace or other characters that are not part of the enumerated value. In case of ASN.1 `ENUMERATED` types the strings used by `enum_to_str`, `str_to_enum` and log represent the TTCN–3 view of the enumerated value, that is, the hyphenation characters are mapped to a single underscore character. For example, if an ASN.1 enumerated type has a value with name `my-enum-value` and numeric value 2, the function `enum_to_str` will return the string `"my_enum_value"` if the input parameter equals to 2. Of course, its C++ equivalent will be `my_enum_value` with numeric value 2.
+
+Static member function `Day::is_valid_enum` returns the Boolean value `TRUE` if there is a defined enumerated value having numeric value equal to the `int` parameter and `FALSE` otherwise.
+
+The static member function `Day::enum_to_int` converts the given parameter of type Day or `Day::enum_type` to its numeric value. The member function `as_int` does the same thing for the enumerated instance.
+
+The member function `int_to_enum` initializes the enumerated instance with the enumerated value having numeric value equal to the given `int` parameter. A dynamic test case error is displayed if there is no such enumerated value. The member function `from_int` does the same thing.
+
+If a value of type `int` is passed to the constructor or assignment operator the value is accepted only if it is a numerical representation of a valid enumerated value, that is, the function `is_valid_enum` returns `TRUE`. A dynamic test case error occurs otherwise.
+
+To avoid run-time errors at the decoding of invalid messages the Test Port writer should use the constructor or assignment operator in this way:
+[source]
+----
+Day myDayVar;
+int myIntVar = buffer[position];
+if (Day::is_valid_enum(myIntVar)) myDayVar = myIntVar;
+else myDayVar = Day::UNKNOWN_VALUE;
+----
+
+Using the value of an unbound enumerated variable for anything will cause dynamic test case error.
+
+=== The `address` Type
+
+The special TTCN–3 data type `address` is represented in C\++ as if it was a regular data type. The name of the equivalent C++ class is `ADDRESS`. If it is an alias to another (either built-in or user-defined) type then a C++ `typedef` is used.
+
+== Predefined Functions
+
+Annex C of link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.05.01_60/es_20187301v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards] and Annex B of link:https://pdfs.semanticscholar.org/33b5/877c85f7fd4f35c7f58c39121358c3652966.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN–3 European Telecommunications] define a couple of predefined functions. Most of them perform conversion between the built-in types of TTCN–3. In our test executor these functions are implemented in the Base Library in C++ language. They are available not only in TTCN–3 , but they can be called directly from Test Ports as well.
+
+The prototypes for these functions can be found in `*$TTCN3_DIR/include/Addfunc.hh*`, but for easier navigation we list them also in the present document.
+
+The majority of these functions have more than one polymorphic version: when appropriate, one of them takes literal (built-in) C\++ types as arguments instead of the objects of equivalent C++ classes. For instance, if the incoming argument is stored in an `int` variable in your C++ code, you should not construct a temporary object of class `INTEGER` because passing an `int` is faster and produces smaller binary code. Similarly, the returned type is also literal when it is possible.
+
+=== `Integer` to character
+
+[source]
+----
+extern CHARSTRING int2char(int value);
+extern CHARSTRING int2char(const INTEGER& value);
+----
+=== Character to `integer`
+
+[source]
+----
+extern int char2int(char value);
+extern int char2int(const char *value);
+extern int char2int(const CHARSTRING& value);
+----
+=== `Integer` to universal character
+
+[source]
+----
+extern UNIVERSAL_CHARSTRING int2unichar(int value);
+extern UNIVERSAL_CHARSTRING int2unichar(const INTEGER& value);
+----
+=== Universal character to `integer`
+
+[source]
+----
+extern int unichar2int(const universal_char& value);
+extern int unichar2int(const UNIVERSAL_CHARSTRING& value);
+----
+=== `Bitstring` to `integer`
+
+[source]
+----
+extern INTEGER bit2int(const BITSTRING& value);
+----
+=== `Hexstring` to `integer`
+
+[source]
+----
+extern INTEGER hex2int(const HEXSTRING& value);
+----
+=== `Octetstring` to `integer`
+
+[source]
+----
+extern INTEGER oct2int(const OCTETSTRING& value);
+----
+=== `Charstring` to `integer`
+
+[source]
+----
+extern INTEGER str2int(const char *value);
+extern INTEGER str2int(const CHARSTRING& value);
+----
+=== `Integer` to `bitstring`
+
+[source]
+----
+extern BITSTRING int2bit(const INTEGER& value, const INTEGER& length);
+----
+=== `Integer` to `hexstring`
+
+[source]
+----
+extern HEXSTRING int2hex(const INTEGER& value, const INTEGER& length);
+----
+=== `Integer` to `octetstring`
+
+[source]
+----
+extern OCTETSTRING int2oct(const INTEGER& value, const INTEGER& length);
+----
+=== `Integer` to `charstring`
+
+[source]
+----
+extern CHARSTRING int2str(int value);
+extern CHARSTRING int2str(const INTEGER& value);
+----
+=== Length of string Type
+
+This function is built into the equivalent C++ classes of all TTCN–3 string types:
+[source]
+----
+int <any_string_type>::lengthof() const;
+----
+=== Number of elements in a structured type
+
+This function is built into the C++ template classes of `record of` and `set of` types:
+[source]
+----
+int <any_record_of_or_set_of_type>::size_of() const;
+----
+This function is currently not implemented for `record` and `set` types.
+
+=== The `IsPresent` Function
+
+This function is built into the wrapper C++ template class `OPTIONAL`:
+[source]
+----
+boolean <any_optional_field>::ispresent() const;
+----
+=== The `IsChosen` Function
+
+These functions are built into the equivalent C++ classes of TTCN–3 union types:
+[source]
+----
+boolean <union_type>::ischosen(
+<union_type>::union_selection_type checked_selection) const;
+----
+=== The `regexp` Function
+
+[source]
+----
+extern CHARSTRING regexp(const CHARSTRING& instr,
+const CHARSTRING& expression, const INTEGER& groupno);
+----
+=== `Bitstring` to `charstring`
+
+[source]
+----
+extern CHARSTRING bit2str(const BITSTRING& value);
+----
+=== `Hexstring` to `charstring`
+
+[source]
+----
+extern CHARSTRING hex2str(const HEXSTRING& value);
+----
+=== `Octetstring` to character string
+
+[source]
+----
+extern CHARSTRING oct2str(const OCTETSTRING& value);
+----
+=== Character string to `octetstring`
+
+[source]
+----
+extern OCTETSTRING str2oct(const char *value);
+extern OCTETSTRING str2oct(const CHARSTRING& value);
+----
+=== `Bitstring` to `hexstring`
+
+[source]
+----
+extern HEXSTRING bit2hex(const BITSTRING& value);
+----
+=== `Hexstring` to `octetstring`
+
+[source]
+----
+extern OCTETSTRING hex2oct(const HEXSTRING& value);
+----
+=== `Bitstring` to `octetstring`
+
+[source]
+----
+extern OCTETSTRING bit2oct(const BITSTRING& value);
+----
+=== `Hexstring` to `bitstring`
+
+[source]
+----
+extern BITSTRING hex2bit(const HEXSTRING& value);
+----
+=== `Octetstring` to `hexstring`
+
+[source]
+----
+extern HEXSTRING oct2hex(const OCTETSTRING& value);
+----
+=== `Octetstring` to `bitstring`
+
+[source]
+----
+extern BITSTRING oct2bit(const OCTETSTRING& value);
+----
+=== `Integer` to `float`
+
+[source]
+----
+extern double int2float(int value);
+extern double int2float(const INTEGER& value);
+----
+=== `Float` to `integer`
+
+[source]
+----
+extern INTEGER float2int(double value);
+extern INTEGER float2int(const FLOAT& value);
+----
+=== The Random Number Generator Function
+
+The implementation is based on functions `srand48` and `drand48` of `libc`.
+[source]
+----
+extern double rnd();
+extern double rnd(double seed);
+extern double rnd(const FLOAT& seed);
+----
+=== The Substring Function
+
+Implemented for all string types.
+[source]
+----
+extern BITSTRING substr(const BITSTRING& value, const INTEGER& index,
+  const INTEGER& returncount);
+extern HEXSTRING substr(const HEXSTRING& value, const INTEGER& index,
+  const INTEGER& returncount);
+extern OCTETSTRING substr(const OCTETSTRING& value, const INTEGER& index,
+  const INTEGER& returncount);
+extern CHARSTRING substr(const CHARSTRING& value, const INTEGER& index,
+  const INTEGER& returncount);
+extern UNIVERSAL_CHARSTRING substr(const UNIVERSAL_CHARSTRING& value,
+  const INTEGER& index, const INTEGER& returncount);
+----
+
+=== Character string to `float`
+
+[source]
+----
+extern double str2float(const char *value);
+extern double str2float(const CHARSTRING& value);
+----
+=== The Replace Function
+
+Implemented for all string types.
+[source]
+----
+extern BITSTRING replace(const BITSTRING& value, const INTEGER& index,
+  const INTEGER& len, const BITSTRING& repl);
+extern HEXSTRING replace(const HEXSTRING& value, const INTEGER& index,
+  const INTEGER& len, const HEXSTRING& repl);
+extern OCTETSTRING replace(const OCTETSTRING& value, const INTEGER& index,
+  const INTEGER& len, const OCTETSTRING& repl);
+extern CHARSTRING replace(const CHARSTRING& value, const INTEGER& index,
+  const INTEGER& len, const CHARSTRING& repl);
+extern UNIVERSAL_CHARSTRING replace(const UNIVERSAL_CHARSTRING& value,
+  const INTEGER& index, const INTEGER& len, const UNIVERSAL_CHARSTRING& repl);
+----
+
+[[octetstring-to-character-string-0]]
+=== Octetstring to character string
+
+[source]
+----
+extern CHARSTRING oct2char(const OCTETSTRING& value);
+----
+[[character-string-to-octetstring-0]]
+=== Character string to octetstring
+
+[source]
+----
+extern OCTETSTRING char2oct(const char *value);
+extern OCTETSTRING char2oct(const CHARSTRING& value);
+----
+=== The `Decompose` Function
+
+Not implemented yet.
+
+[[additional-non-standard-functions]]
+=== Additional Non-Standard Functions
+
+[source]
+----
+extern BITSTRING str2bit(const char *value);
+extern BITSTRING str2bit(const CHARSTRING& value);
+extern HEXSTRING str2hex(const char *value);
+extern HEXSTRING str2hex(const CHARSTRING& value);
+extern CHARSTRING float2str(double value);
+extern CHARSTRING float2str(const FLOAT& value);
+
+template<typename TTCN_TYPE>
+CHARSTRING ttcn_to_string(const TTCN_TYPE& ttcn_data)
+
+template<typename TTCN_TYPE>
+void string_to_ttcn(const CHARSTRING& ttcn_string, TTCN_TYPE& ttcn_value)
+
+extern UNIVERSAL_CHARSTRING oct2unichar(const OCTETSTRING& invalue);
+extern UNIVERSAL_CHARSTRING oct2unichar(const OCTETSTRING& invalue,
+  const CHARSTRING& string_encoding);
+
+extern OCTETSTRING unichar2oct(const UNIVERSAL_CHARSTRING& invalue);
+extern OCTETSTRING unichar2oct(const UNIVERSAL_CHARSTRING& invalue,
+  const CHARSTRING& string_encoding);
+
+extern CHARSTRING get_stringencoding(const OCTETSTRING& encoded__value);
+extern OCTETSTRING remove_bom(const OCTETSTRING& encoded__value);
+
+extern CHARSTRING encode_base64(const OCTETSTRING& msg, bool use_linebreaks);
+extern CHARSTRING encode_base64(const OCTETSTRING& msg);
+extern OCTETSTRING decode_base64(const CHARSTRING& b64);
+----
+
+See the section "Additional predefined functions" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[ Programmer"s Technical Reference] for more details.
+
+[[using-the-signature-classes]]
+== Using the Signature Classes
+
+A Test Port has three outgoing and three incoming types of operation that require the usage of signatures. These are `call` (`getcall`), `reply` (`getreply`) and `raise` (`catch`). Because of this, there are three representation formats (classes generated by the compiler) of a signature the Test Port writer should be familiar with. This section describes these classes using an example.
+
+Let us suppose the following signature definition:
+[source]
+----
+signature MyProc(in integer inPar, out float outPar,
+	inout bitstring inoutPar)
+		return hexstring
+		exception(charstring, integer, boolean);
+----
+
+The classes generated and needed to write a Test Port using this signature are `MyProc_call`, `MyProc_reply` and `MyProc_exception`. These represent the parameters, the return value and the exception type and value of the signature needed by a call, reply or raise.
+
+For example, if a port uses the signature `MyProc` as an output remote procedure, the Test Port gets the outgoing parameters for a call operation towards the system in an instance of the class `MyProc_call`. In this case the classes `MyProc_reply` and `MyProc_exception` are used for placing an incoming reply or raise operation in the queue of the port (using the functions `incoming_reply` and `incoming_exception` of the port class).
+
+=== The Representation of the Input Parameters
+
+The class `MyProc_call` (using the above example) represents all incoming parameters of the signature `MyProc`. It temporary stores the parameters inPar and inoutPar.
+
+The generated class `MyProc_call` will have the following public member functions:
+
+.Public member functions of the class `MyProc_call`
+
+[cols=",,",options="",]
+|==============================================================
+2+^.^|*Member functions* |*Notes*
+.4+^.^|_Parameter access functions_
+|INTEGER& inPar() |Gives access to parameter inPar.
+|const INTEGER& inPar() const  |
+|BITSTRING& inoutPar() |The same, but it gives read-only access.
+|const BITSTRING& inoutPar() const  |
+^.^|_Other member functions_
+|`void log() const` |Puts the parameters into log.
+|==============================================================
+
+The parameters can be accessed via their access functions that have the same names as the parameters (name mapping also applies to these functions).
+
+=== The Output Parameters and Return Value
+
+The output parameters and return value (if defined) are represented by the class `MyProc_reply` that has the following public member functions:
+
+.Public member functions of the class `MyProc_reply`
+
+[cols=",,",options="",]
+|=====================================================================
+2+^.^|*Member functions* |*Notes*
+.2+^.^|_Parameter access functions_
+|FLOAT& outPar()const FLOAT& outPar() const |Gives access to parameter outPar.
+|BITSTRING& inoutPar() const BITSTRING& inoutPar() const |The same, but it gives read-only access.
+.2+^.^|_Access function for return value_
+|HEXSTRING& return value() |Gives access to the return value.
+|const HEXSTRING& return value() const |
+^.^|_Other member functions_
+|`void log() const` |Puts the parameters into log.
+|=====================================================================
+
+The parameters can be accessed by their access functions, and the return value can be accessed via the function `return_value()`.
+
+=== Representation of Signature Exceptions
+
+The class representing the exceptions of a signature (remote procedure) is similar to the representation of the union data type. Using the above example this class is called `MyProc_exception`. This class is generated only if the signature has at least one exception type.
+
+.Public member functions of the class `MyProc_exception`
+
+[width="100%",cols=",,",options="",]
+|===================================================================================================================================================================================================================================
+2+^.^|*Member functions* |*Notes*
+.2+^.^|_Constructors_
+|`MyProc_exception()` |Initializes to unbound value.
+|`MyProc_exception(const MyProc_exception&)` |Copy constructor.
+^.^|_Destructor_
+|`ËœMyProc_exception()` |
+^.^|_Assignment_ _operator_
+|`MyProc_exception& operator=(const MyProc_exception&)` |Assigns the given value.
+.4+^.^|_Field access functions_
+|CHARSTRING& CHARSTRING_field() |Selects and gives access to the CHARSTRING field. If other field was previously selected, its value will be destroyed.
+|const CHARSTRING&CHARSTRING_field() cons |Gives read-only access to the CHARSTRING field. If other field is selected, this function will cause dynamic test case error. So use get selection() first.
+|INTEGER& INTEGER_field() const INTEGER& INTEGER_field() const |
+|BOOLEAN& BOOLEAN_field()const BOOLEAN& BOOLEAN_field() const  |
+.2+^.^|_Other member functions_
+|`MyProc_exception::exception_selection_type 	get_selection() const` |Returns the current selection. It will return MyProc exception::UNBOUND VALUE if the exception is unbound, MyProc exception::ALT CHARSTRING if a charstring value is present in the exception, and so on.
+|`void log() const` |Puts the contents of the exception into the log.
+|===================================================================================================================================================================================================================================
+
+If an exception type is a user-defined type the field name will be constructed from the C\++ namespace name of the module that the exception type resides in and the name of the C++ class that realizes the exception type. The two identifiers are glued together using a single underscore character. Please note that the namespace name is always present in the identifiers, even if the exception type is defined in the same module as the signature.
+
+For example, if exception type `My_Record` is defined in module `My_Module` the respective field access functions will be named as `My\__Module_My__Record_field` and the associated enum value will be `MyProc_exception::ALT_My__Module_My__Record`.
diff --git a/usrguide/apiguide/6-tips_&_troubleshooting.adoc b/usrguide/apiguide/6-tips_&_troubleshooting.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..4fda65ec898667e6a64e36f2cefc0538e12d63c4
--- /dev/null
+++ b/usrguide/apiguide/6-tips_&_troubleshooting.adoc
@@ -0,0 +1,293 @@
+= Tips & Troubleshooting
+:table-number: 34
+:toc:
+
+Information not fitting in any of the previous chapters is given in this chapter.
+
+[[migrating-existing-c-code-to-the-naming-rules-of-version-1-7]]
+== Migrating Existing C++ Code to the Naming Rules of Version 1.7
+
+When using the new naming rulesfootnote:[The new naming rules are used by default; the naming rules can be changed using the compiler command line switch -N.] the compiler generates a C\++ namespace for each TTCN–3 and ASN.1 module. The name of the namespace corresponds to the module. The generated C++ entities of a module are all placed in its namespace; therefore all the test port or protocol module code must use these namespaces.
+
+Rules to follow when writing C++ code:
+
+* When referencing an entity located in a different module its C++ name has to be prefixed with the namespace name of that module.
+
+* A test port class must be placed into the namespace of its module.
+
+* Encoding and decoding functions must be placed into the namespace of the TTCN–3 module in which the external function was defined.
+
+* All C\++ entities have to be placed into namespace. An exception to this may be C++ entities used only locally; these are defined with the keyword `static`.
+
+* For convenience the `using namespace` directive can be used in C++ source files. It is forbidden to use this directive in header files!
+
+* C++ enum types are placed in the scope of their value class; enum types have to be prefixed by the C++ name of the value class.footnote:[The enum hack option has become obsolete with the new naming rules.]
+
+[[using-external-c-functions-in-ttcn-3-test-suites]]
+== Using External C++ Functions in TTCN–3 Test Suites
+
+Sometimes standard library functionsfootnote:[C language functions cannot be called directly from TTCN–3; you need at least a wrapper function for them.] are called in the test suite or there is a need for efficiently implemented "bit-crunching" functions in the TTCN–3 ATS. In these cases functions to be called from the test suite can be developed in C++.
+
+There are the standard library functions as well as other libraries in the C++ functions. The logging and error handling facilities of the run-time environment are also available as in case of Test Ports.
+
+Since version 1.4.pl1 the semantic analyzer of the compiler checks the import statements thoroughly. Therefore one cannot use the virtual C++ modules as before: C++ functions must be defined as external functions to be accessible from TTCN–3 modules.
+
+For example, the following definitions make two C++ functions accessible from TTCN–3 module `MyModule` and from any other module that imports `MyModule`.
+
+[[example-ttcn-3-module-mymodule-ttcn]]
+=== Example TTCN–3 Module (MyModule.ttcn)
+
+[source]
+----
+module MyModule {
+[...]
+  external function MyFunction(integer par1, in octetstring par2)
+    return bitstring;
+  external function MyAnotherFunction(inout My_Type par1,
+    out MyAnotherType par2);
+[...]
+}
+----
+
+The compiler will translate those external function definitions to C++ function prototypes in the generated header file `MyModule.hh`:
+
+[source]
+----
+[...]
+  extern BITSTRING MyFunction(const INTEGER& par1, const OCTETSTRING& par2);
+  extern void MyAnotherFunction(My__Type& par1, MyAnotherType& par2);
+[...]
+----
+
+Both pre-defined and user-defined TTCN–3 data types can be used as parameters and/or return types of the C\++ functions. The detailed description of the equivalent C++ classes as well as the name mapping rules are described in chapter <<4-encoding_and_decoding.adoc#xml-encoding-xer,XML Encoding (XER)>>.
+
+Using templates as formal parameters in external functions is possible, but not recommended because the API of the classes realizing templates is not documented and subject to change without notice.
+
+The formal parameters of external TTCN–3 functions are mapped to C++ function parameters according to the following table:
+
+.TTCN–3 formal parameters and their C++ equivalents
+
+[cols=",",options="header",]
+|==============================================
+|TTCN–3 formal parameter |Its C++ equivalent
+|`[in] MyType myPar` |`const MyType& myPar`
+|`out MyType myPar` |`MyType& myPar`
+|`inout MyType myPar` |`MyType& myPar`
+|`[in] template MyType myPar` |_Not recommended._
+|==============================================
+
+NOTE: In versions 1.6.pl3 and earlier the in keyword had an extra meaning in formal parameter lists. According to the TTCN–3 standard the parameter definitions `MyType myPar` and in `MyType myPar` are totally equivalent, but the earlier versions of the compiler distinguished them. Unless the keyword `in` was present the compiler passed the parameter by value (involving a copy constructor call) instead of using a const reference. That is why it was recommended to use an explicit in keyword in parameter lists of external functions.
+
+Due to the strictness of the TTCN–3 semantic analyzer one cannot use C/C++ data types with external functions as formal parameters or return types, only TTCN–3 and ASN.1 data types are allowed. Similarly, one cannot use pointers as parameters or return values because they have no equivalents in TTCN–3 .
+
+The external functions can be implemented in one or more C\++ source files. The generated header file that contains the prototypes of the external functions shall be included into each C++ source file. This file makes accessible all built-in data types, the user-defined types of the corresponding TTCN–3 module and all available services of the run-time environment (logging, error handling, etc.).
+
+The name, return type and the parameters of the implemented C++ functions must match exactly the generated function prototypes or the compilation will fail. The generated function prototype is in the namespace of the module, therefore the implementation of the function has to be placed in that namespace, too.
+[[logging-in-test-ports-or-external-functions]]
+== Logging in Test Ports or External Functions
+
+When developing Test Ports or external functions the need may arise for debug messages. Instead of using `printf` or `fprintf`, there is a simple way to put these messages into the log file of test executor. This feature can be also useful in case when an error or warning situation is encountered in the Test Port, especially when decoding an incoming message.
+
+There is a class called `TTCN_Logger` in the Base Library, which takes care of logging. For historical reasons it has a static instance (object), which is called `TTCN_logger`. Since all member functions of `TTCN_Logger` are static, they can be and should be called without the logger object. The usage of object `TTCN_logger` should be avoided in newly written code.
+
+The class `TTCN_Logger` provides some public member functions. Using them any kind of message can be put into the log file. There are two ways to log a single message, the unbuffered and the buffered mode.
+
+=== Unbuffered Mode
+
+In unbuffered mode the message will be put into log immediately as a separate line together with a time stamp. Thus, the entire message must be passed to the logger class at one function call. The log member function of the logger class should be used. Its prototype is:
+[source, subs="+quotes"]
+static void TTCN_Logger::log(int severity, const char *fmt, …);
+
+The parameter severity is used for filtering the log messages. The allowed values of the parameter are listed in table "First level (coarse) log filtering" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference]. We recommend using in Test Ports only `TTCN_WARNING`, `TTCN_ERROR` and `TTCN_DEBUG`. The parameter `fmt` is a pointer to a format string, which is interpreted as in `printf(3)`. The dots represent the optional additional parameters that are referred in format string. There is no need to put a newline character at the end of format string; otherwise the log file will contain an empty line after your entry.
+
+Here is an example, which logs an integer value:
+[source]
+----
+int myVar = 5;
+TTCN_Logger::log(TTCN_WARNING, ``myVar = %d'', myVar);
+----
+
+Sometimes the string to be logged is static. In such cases there is no need for `printf`-style argument processing, which may introduce extra risks if the string contains the character `%`. The logger class offers a function for logging a static (or previously assembled) string:
+[source, subs="+quotes"]
+static void TTCN_Logger::log_str(int severity, const char *str);
+
+The function `log_str` runs significantly faster than log because it bypasses the interpretation of the argument string.
+
+There is another special function for unbuffered mode:
+[source]
+----
+static void TTCN_Logger::log_va_list(int severity, const char *fmt,
+	va_list ap);
+----
+The function `log_va` list resembles to log, but it takes the additional `printf` arguments in one va_list structure; va_list is defined in the standard C header file `stdarg.h` and used in functions with variable number of arguments.
+
+This function (and especially its buffered mode version, `log_event_va_list`) is useful if there is a need for a wrapper function with `printf`-like syntax, but the message should be passed further to `TTCN_Logger`. With these functions one can avoid the handling of temporary buffers, which could be a significant performance penalty.
+
+=== Buffered Mode
+
+As opposite to the unbuffered operation, in buffered mode the logger class stores the message fragments in a temporary buffer. New fragments can be added after the existing ones. When finished, the fragments can be flushed after each other to the log file as a simple message. This mode is useful when assembling the message in many functions since the buffer management of logger class is more efficient than passing the fragments as parameters between the functions.
+
+In buffered mode, the following member functions are available.
+
+[[begin-event]]
+==== begin_event
+
+`begin_event` creates a new empty event buffer within the logger. You have to pass the severity value, which will be valid for all fragments (the list of possible values can be found in the table "First level (coarse) log filtering" in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[ Technical Reference]. If the logger already has an unfinished event when begin event is called the pending event will be pushed onto an internal stack of the logger. That event can be continued and completed after finishing the newly created event.
+[source, subs="+quotes"]
+static void TTCN_Logger::begin_event(int severity);
+
+[[log-event]]
+==== log_event
+
+`log_event` appends a new fragment at the end of current buffer. The parameter `fmt` contains a `printf` format string like in unbuffered mode. If you try to add a fragment without initializing the buffer by calling begin event, your fragment will be discarded and a warning message will be logged.
+[source, subs="+quotes"]
+static void TTCN_Logger::log_event(const char *fmt, …);
+
+[[log-char]]
+==== log_char
+
+`log_char` appends the character c at the end of current buffer. Its operation is very fast compared to `log_event`.
+[source, subs="+quotes"]
+static void TTCN_Logger::log_char(char c);
+
+[[log-event-str-and-log-event-va-list]]
+==== log_event_str and log_event_va_list
+
+The functions `log_str` and `log_va_list` also have the buffered versions called `log_event_str` and `log_event_va_list`, respectively. Those interpret the parameters as described in case of unbuffered mode.
+[source]
+----
+static void TTCN_Logger::log_event_str(const char *str);
+static void TTCN_Logger::log_event_va_list(const char *fmt, va_list ap);
+----
+[[os-error]]
+==== OS_error
+
+The function `OS_error` appends the textual description of the error code stored in global variable `errno` at the end of current buffer. Thereafter that variable `errno` will be set to zero. The function does nothing if the value of `errno` is already zero. For further information about possible error codes and their textual descriptions please consult the manual page of `errno(3)` and `strerror(3)`.
+[source, subs="+quotes"]
+static void TTCN_Logger::OS_error();
+
+==== log
+
+The C++ classes of predefined and compound data types are equipped with a member function called `log`. This function puts the actual value of the variable at the end of current buffer. Unbound variables and fields are denoted by the symbol `<unbound>`. The contents of TTCN–3 value objects can be logged only in buffered mode.
+[source, subs="+quotes"]
+void <any TTCN-3 type>::log() const;
+
+[[end-event]]
+==== end_event
+
+The function `end_event` flushes the current buffer into the log file as a simple message, then it destroys the current buffer. If the stack of pending events is not empty the topmost event is popped from the stack and becomes active. The time stamp of each log entry is generated at the end and not at the beginning. If there is no active buffer when `end_event` is called, a warning message will be logged.
+[source, subs="+quotes"]
+static void TTCN_Logger::end_event();
+
+If an unbuffered message is sent to the logger while the buffer contains a pending event the unbuffered message will be printed to the log immediately and the buffer remains unchanged.
+
+=== Logging Format of TTCN-3 Values and Templates
+
+TTCN-3 values and templates can be logged in the following formats:
+
+TITAN legacy logger format: this is the default format which has always been used in TITAN
+
+TTCN-3 format: this format has ttcn-3 syntax, thus it can be copied into TTCN-3 source files.
+
+Differences between the formats:
+
+[cols=",,",options="header",]
+|==========================================================
+|Value/template |Legacy format output |TTCN-3 format output
+|Unbound value |"<unbound>" |"-"
+|Uninitialized template |"<uninitialized template>" |"-"
+|Enumerated value |name (number) |name
+|==========================================================
+
+The "-" symbol is the NotUsedSymbol which can be used inside compound values, but when logging an unbound value which is not inside a record or record of the TTCN-3 output format of the logger is actually not a legal TTCN-3 value/template because a value or template cannot be set to be unbound. Thus this output format can be copy-pasted from a log file into a ttcn-3 file or to a module parameter value in a configuration file only if it semantically makes sense.
+
+The C++ API extensions to change the logging format: +
+A new enum type for the format in TTCN_Logger class:+
+`enum data_log_format_t { LF_LEGACY, LF_TTCN }`; +
+Static functions to get/set the format globally: +
+`data_log_format_t TTCN_Logger::get_log_format();void` `TTCN_Logger::set_log_format(data_log_format_t p_data_log_format)`; +
+A helper class to use a format until the end of the scope, when used as local variable. This can be used as follows: +
+[source]
+----
+{
+    Logger_Format_Scope lfs(TTCN_Logger::LF_TTCN); // sets TTCN-3 log format
+    <log some values and templates>
+} // end of scope -> the original format is restored
+----
+It is recommended to use this helper class because using directly the format setting functions of `TTCN_Logger` is more error prone, if the globally used logging format is not restored properly then log files might contain values/templates in a mixed/unexpected format.
+
+=== Examples
+
+The example below demonstrates the combined usage of buffered and unbuffered modes as well as the working mechanism of the event stack:
+[source]
+----
+TTCN_Logger::begin_event(TTCN_DEBUG);
+TTCN_Logger::log_event_str("first ");
+TTCN_Logger::begin_event(TTCN_DEBUG);
+TTCN_Logger::log_event_str("second ");
+TTCN_Logger::log_str(TTCN_DEBUG, "third message");
+TTCN_Logger::log_event_str("message");
+TTCN_Logger::end_event();
+TTCN_Logger::log_event_str("message");
+TTCN_Logger::end_event();
+----
+
+The above code fragment will produce three lines in the log in the following order:
+
+`third message`
+`second message`
+`first message`
+
+If the code calls a C++ function that might throw an exception while the logger has an active event buffer care must be taken that event is properly finished during stack unwinding. Otherwise the stack of the logger and the call stack of the program will get out of sync. The following example illustrates the proper usage of buffered mode with exceptions:
+[source]
+----
+TTCN_Logger::begin_event(TTCN_DEBUG);
+try {
+  TTCN_Logger::log_event_str("something");
+  // a function is called from here
+  // that might throw an exception (for example TTCN_error())
+  TTCN_Logger::log_event_str("something else");
+  TTCN_Logger::end_event();
+} catch (...) {
+  // don’t forget about the pending event
+  TTCN_Logger::end_event();
+  throw;
+}
+----
+
+== Error Recovery during Test Execution
+
+If a fatal error is encountered in the Test Port, you should call the function `TTCN_error` must be called to do the error handling. It has the following prototype in the Base Library:
+[source, subs="+quotes"]
+void TTCN_error(const char *fmt, …);
+
+The parameter `fmt` contains the reason of the error in a NUL terminated character string in the format of a `printf` format string. If necessary, additional values should be passed to `TTCN_error` as specified in the format string. The error handling in the executable test program is implemented using C++ exceptions so the function `TTCN_error` never returns; instead, it throws an exception. The exception value contains an instance of the empty class called `TC_Error`. This exception is normally caught at the end of each test case and module control part. After logging the reason `TTCN_Logger::OS error()` is called. Finally, the verdict is set to error and the test executor performs an error recovery, so it continues the execution with the next test case.
+
+It is not recommended to use own error recovery combined with the default method (that is, catching this exception).
+
+== Using UNIX Signals
+
+The UNIX signals may interrupt the normal execution of programs. This may happen when the program executes system calls. In this case, when the signal handler is finished the system call will fail and return immediately with an error code.
+
+In the executable test program there are system calls not only in the Base Library, but in Test Ports as well. Since the other Test Ports that you are using may have been written by many developers, one cannot be sure that they are prepared to the effects of signals. So it is recommended to avoid using signals in Test Ports.
+
+== Mixing C and C++ Modules
+
+Modules written in C language may be used in the Test Ports. In this case the C header files must be included into the Test Port source code and the object files of the C module must be linked to the executable. Using a C compiler to compile the C modules may lead to errors when linking the modules together. This is because the C and C\++ compilers use different rules for mapping function names to symbol names of the object file to avoid name clashes caused by the C++ polymorphism. There are two possible solutions to solve this problem:
+
+1.  Use the same C++ compiler to compile all of your source code (including C modules).
+2.  If the first one is impossible (when using a third party software that is available in binary format only), the definitions of the C header file must be put into an `extern "C"` block like this.
+[source]
+----
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+<... your C definitions ...>
+
+#ifdef __cplusplus
+};
+#endif
+----
+
+The latter solution does not work with all C\++ compilers; it was tested on GNU C++ compiler only.
diff --git a/usrguide/apiguide/7-references.adoc b/usrguide/apiguide/7-references.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..8115e23dcd86e424aacad8ef3f9653224a76ec60
--- /dev/null
+++ b/usrguide/apiguide/7-references.adoc
@@ -0,0 +1,31 @@
+= References
+
+1. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.05.01_60/es_20187301v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards Institute ES 201 873-1 Version 4.5.1, April 2013]
+
+2. Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN–3 Operational SemanticsEuropean Telecommunications Standards Institute. ES 201 873-4 Version 4.4.1, April 2012
+
+3. link:https://pdfs.semanticscholar.org/33b5/877c85f7fd4f35c7f58c39121358c3652966.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN–3 European Telecommunications Standards Institute. ES 201 873-7 Version 4.5.1, April 2013]
+
+4. link:https://www.etsi.org/deliver/etsi_ES/201800_201899/20187309/04.05.01_60/es_20187309v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN–3 European Telecommunications Standards Institute. ES 201 873-9 Version 4.5.1, April 2013]
+
+5. link:https://www.itu.int/rec/T-REC-X.690-200811-S[ITU-T, X.690, Information TechnologyASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)International Telecommunication Union, November 2008]
+
+6. ITU-T, X.693, Information TechnologyASN.1 encoding rules: XML Encoding Rules (XER), November 2008
+
+7. ITU-T, X.693 amendment 1, Information TechnologyASN.1 encoding rules: XER encoding instructions and EXTENDED-XER, November 2008
+[[_8]]
+8. ISO/IEC 10646-1, Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane, Second edition, 200009-15
+
+9. link:https://tools.ietf.org/html/rfc3629[RFC3629: UTF-8, a transformation format of ISO 10646]
+
+10.link:https://github.com/eclipse/titan.core/blob/master/usrguide/userguide/README.adoc[User Guide for TITAN TTCN-3 Test Executor]
+
+11. link:https://github.com/eclipse/titan.core/blob/master/usrguide/installationguide.adoc[Installation guide for TITAN TTCN-3 Test Executor]
+
+12. link:https://github.com/eclipse/titan.core/blob/master/usrguide/releasenotes.adoc[Release Notes for TITAN TTCN-3 Test Executor]
+
+13. link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Technical Reference for TITAN TTCN-3 Test Executor]
+
+14. link:http://tldp.org/HOWTO/Program-Library-HOWTO/index.html[David A. Wheeler, Program Library HOWTO]
+
+15. link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.04.01_60/es_202781v010401p.pdf[ETSI ES 202 781 V1.4.1. (2015-06 Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support)]
diff --git a/usrguide/apiguide/8-abbreviations.adoc b/usrguide/apiguide/8-abbreviations.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..6aab4e211dbe625c450de9989850f27dddb556f5
--- /dev/null
+++ b/usrguide/apiguide/8-abbreviations.adoc
@@ -0,0 +1,74 @@
+= Abbreviations
+
+API:: Application Programming Interface
+
+ASN.1:: Abstract Syntax Notation One
+
+ATS:: Abstract Test Suite
+
+BER:: Basic Encoding Rules (of ASN.1)
+
+BXER:: Basic XER
+
+BNF:: Backus–Naur Formalism
+
+CER:: Canonical Encoding Rules (of ASN.1)
+
+CXER:: Canonical XER
+
+DER:: Distinguished Encoding Rules (of ASN.1)
+
+ETS:: Executable Test Suite
+
+ETSI:: European Telecommunications Standards Institute
+
+EXER:: Extended XER
+
+GUI:: Graphical User Interface
+
+HC:: Host Controller
+
+HTML:: Hypertext Markup Language
+
+HTTP:: HyperText Transfer Protocol
+
+IP:: Internet Protocol
+
+LSB:: Least Significant Byte
+
+MC:: Main Controller
+
+MTC:: Main (or Master) Test Component
+
+PDU:: Protocol Data Unit
+
+pl:: Patch Level
+
+PTC:: Parallel Test Component
+
+PT:: Port Type
+
+SO:: Shared Object
+
+SUT:: System Under Test
+
+TC:: Test Component (either MTC or PTC)
+
+TCC:: Test Competence Center
+
+TCP:: Transmission Control Protocol
+
+TLV:: Tag, Length, Value
+
+TTCN:: Tree and Tabular Combined Notation
+
+TTCN–2:: Tree and Tabular Combined Notation
+
+TTCN–3:: Tree and Tabular Combined Notation version 3 (formerly) +
+Testing and Test Control Notation (new resolution)
+
+URL:: Universal Resource Locator
+
+XER:: XML Encoding Rules for ASN.1
+
+XML:: Extensible Markup Language
diff --git a/usrguide/apiguide/README.adoc b/usrguide/apiguide/README.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..c83e69da95251a86e804e61151fb8293e156e48d
--- /dev/null
+++ b/usrguide/apiguide/README.adoc
@@ -0,0 +1,54 @@
+---
+Author: Jenő Balaskó
+Version: 6/198 17-CRL 113 200/6, Rev. PE1
+Date: 2018-06-18
+
+---
+= API Technical Reference for TITAN TTCN-3 Test Executor
+:author: Jenő Balaskó
+:revnumber: 6/198 17-CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-18
+:title-logo-image: images/titan_logo.png
+:toc:
+
+image::images/titan_logo.png[alt]
+
+== Abstract
+
+This document describes detailed information on the TITAN Application Programming Interface (API) on C++ level, advanced TTCN–3 programming, and background information on the TITAN TTCN–3 Test Executor project.
+
+== Copyright
+
+Copyright (c) 2000-2018 Ericsson Telecom AB +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution, and is available at
+
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html.
+
+== Disclaimer
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
+
+== Contents
+
+ifdef::env-github,backend-html5[]
+* link:1-introduction.adoc[Introduction]
+* link:2-test_ports.adoc[Test Ports]
+* link:3-logger_plug-ins.adoc[Logger Plug-ins]
+* link:4-encoding_and_decoding.adoc[Encoding and Decoding]
+* link:5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc[Mapping TTCN–3 Data Types to C++ Constructs]
+* link:6-tips_&_troubleshooting.adoc[Tips & Troubleshooting]
+* link:7-references.adoc[References]
+* link:8-abbreviations.adoc[Abbreviations]
+endif::[]
+
+
+ifndef::env-github,backend-html5[]
+include::1-introduction.adoc[]
+include::2-test_ports.adoc[]
+include::3-logger_plug-ins.adoc[]
+include::4-encoding_and_decoding.adoc[]
+include::5-mapping_ttcn3_data_types_to_c++_constructs.adoc[]
+include::6-tips_&_troubleshooting.adoc[]
+include::7-references.adoc[]
+include::8-abbreviations.adoc[]
+endif::[]
\ No newline at end of file
diff --git a/usrguide/apiguide/images/titan_logo.png b/usrguide/apiguide/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..b807b492556016f30f606666323eb566b5e11262
Binary files /dev/null and b/usrguide/apiguide/images/titan_logo.png differ
diff --git a/usrguide/installationguide.doc b/usrguide/installationguide.doc
deleted file mode 100644
index abf45665eb2579cfa066ca6abbee8dccbea69031..0000000000000000000000000000000000000000
Binary files a/usrguide/installationguide.doc and /dev/null differ
diff --git a/usrguide/installationguide/images/titan_logo.png b/usrguide/installationguide/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..91d5104f5f4328314a68569143a3b645509d7fb2
Binary files /dev/null and b/usrguide/installationguide/images/titan_logo.png differ
diff --git a/usrguide/installationguide/installationguide.adoc b/usrguide/installationguide/installationguide.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..e77209a73b7efbf4fb29153d743cd2b7688752d8
--- /dev/null
+++ b/usrguide/installationguide/installationguide.adoc
@@ -0,0 +1,350 @@
+---
+Author: Jenő Balaskó
+Version: 1/1531-CRL 113 200/6, Rev. PE1
+Date: 2018-06-18
+
+---
+= Installation Guide for the TITAN TTCN-3 Test Executor
+:author: Jenő Balaskó
+:revnumber: 1/1531-CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-18
+:title-logo-image: images/titan_logo.png
+:toc:
+
+image::images/titan_logo.png[alt]
+
+*Abstract*
+
+This document describes the detailed information of installing TITAN TTCN-3 Test Executor and all of its components.
+
+*Copyright*
+
+Copyright (c) 2000-2018 Ericsson Telecom AB. +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution, and is available at +
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
+
+*Disclaimer*
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
+
+= Introduction
+
+== Overview
+
+This document describes obtaining the TITAN TTCN-3 Test Executor software, installing the Test Executor and all of its components, setting the user environment, and licensing mechanism.
+
+== Target Groups
+
+This document is for all audience who intend to create and execute simulations.
+
+== Typographical Conventions
+
+This document uses the following typographical conventions:
+
+* *Bold* is used to represent graphical user interface (GUI) components such as buttons, menus, menu items, dialog box options, fields and keywords, as well as menu commands. Bold is also used with ’+’ to represent key combinations. For example, *Ctrl+Click*
+* The "*/*" character is used to denote a menu and sub-menu sequence. For example, *File / Open*.
+* `Monospaced` font is used represent system elements such as command and parameter names, program names, path names, URLs, directory names and code examples.
+* *`Bold monospaced font`* is used for commands that must be entered at the Command Line Interface (CLI), For example, *`ttcn3_start`*
+
+== Prerequisites
+
+The supported platforms are Solaris, Linux and Cygwin (on Windows platforms).
+
+The following are required for proper operation of the TITAN:
+
+* Openssl-devel 0.9.8k or higher
+* Libxml2-devel 2.7.1 or higher
+* JDK 1.5.0_10 or later (only required if the JNI-based executor in the Executor plug-in is used. JNI cannot be used on Cygwin.)
+
+NOTE: If the platform has other, but compatible, version of above tools, TITAN will be built with those.
+
+On Linux, the platform-supplied versions of OpenSSL-devel and libxml2-devel are used. OpenSSL is usually installed by default. The libxml2 package and the development packages may need to be installed manually.
+
+The development packages should be called openssldev (or devel) or libopenssldev (or devel) and libxml2dev (or devel) respectively.
+
+To deploy the prerequisites is special on Cygwin therefore it is discussed below.
+
+== Installing Prerequisites on Cygwin (on Windows)
+
+To deploy the prerequisites is special on Cygwin therefore it is discussed below.
+
+Titan is always built on the newest Cygwin version available.
+
+* If Cygwin has been installed already, refresh your Cygwin installation. Start the Cygwin setup utility (see below). It will refresh your installed Cygwin packages to the newest versions.
+
+* If Cygwin hasn’t been installed yet:
+
+. Download and execute the latest Cygwin installer utility depending on your platform and the Titan package to be downloaded:32-bit version: https://cygwin.com/setup-x86.exe64-bit version: https://cygwin.com/setup-x86_64.exe
+
+. Select Install from Internet (recommended to save local disk place)
+
+. Choose Cygwin installation root directory (C: is recommended).
+
+. Select All users or Just Me.
+
+. Select "Local Package Directory" (typically the same directory, where the setup…exe Cygwin installer utility is stored).
+
+. Use Internet Explorer Proxy Settings (recommended).
+
+. Select a download mirror site.
+
+. In the package selection dialog you can select different views to find the required packages easier and you can search the packages via the search field. The Cygwin installer will automatically select the packages which the manually selected ones are depending on. Do not deselect any automatically selected package! There are three hierarchical levels of minimally required packages, depending on Your task:
+
+.. test execution only (from command line or from Eclipse Titan Executor): +
+Base: <All packages> (Default setting of the installer) +
+Net: openssl +
+Tcl: expect
+.. Test case development: in addition to the above select the following packages: +
+Devel: binutils +
+Devel: gcc-g++ +
+Devel: make +
+Libs: libxml2-devel +
+Net: openssl-devel (automatically installs Net:openssl as well, if selected
+.. To compile your own Titan Cygwin binary: in addition to the above, select the following packages: +
+Devel: bison +
+Devel: ctags (optional) +
+Devel: diffstat +
+Devel: flex +
+Devel: gcc-core +
+Devel: perl +
+Devel: git +
+Editors: <any editor of your preference> e.g vi, nedit, xemacs, gedit, nano and so on +
+Libs: libncurses-devel +
+Libs: libreadline-devel +
+Libs: libexpat1 +
+Libs: libiconv, libiconv-devel, libiconv2
+.. To contribute to Titan, test port or protocol module development: Devel: git-review If, after selecting the required packages and clicking on the "Next" button, a "Resolving Dependencies" window lists further required packages, ensure that the "Select required packages (RECOMMENDED)" checkbox is checked and click on the "Next" button.
+
+. Select the ``Create'' icon on the Desktop checkbox
+
+. Optional +
+Your "unix" home directory, by default is: <your cygwin installation directory>/home/<yourUserId>. If you are (also) working in command line mode, it is a good practice to change this to the folder where your TTCN-3 projects are located. Edit the file <your cygwin installation directory>/etc/passw: In the line: ourUserId>:unused:<xxxxxx>:<yyyyy>:U-<yourDomain>&lt;yourUserId>, S-1-5-21-nnnnnn…nnnnnn:/home/<yourUserId>:/bin/bash replace ``/home/<yourUserId>'' with the folder of your preference.
++
+NOTE: you can access all Windows drives from Cygwin as /cygdrive/<windowsDriveLetter>. Example: to set your "unix" home directory to the "My_Home" folder within your Windows Documents folder, you should replace "/home/<yourUserId>" by /cygdrive/c/Users/<yourUserId>/Documents/My_Home''WARNING: The path of your "unix" home directory shall not contain any space! It is not a requirement, but is a kind of best practice to place Titan into a subfolder within your "unix" home directory.
+
+. When installation is finished, add the +
+$CYGWIN_INSTALL_DIRECTORY\bin and +
+$CYGWIN_INSTALL_DIRECTORY\usr\bin directories to the PATH +
+environment variable of Windows, so Eclipse will access the shell commands. +
+For example, if the cygwin root is ``C:64'' then ``Path'' should contain ``C:64;C:64''.
+
+. To check if your installation is correct, open either a Cygwin shell (use the desktop icon created during Cygwin installation or start bash.exe from the Windows Start menu) or start cmd.exe from the Windows Start menu and type:bash.exe
+
+= Installing from a pre-built binary package
+
+This chapter describes obtaining the software and installing it.
+
+== Downloading the Software
+
+The Titan package can be installed from the provided download sites.
+
+Download the Titan package for your platform, OS and GCC version from the provided download sites:
+
+* For Ericsson users only: http://ttcn.ericsson.se/download. The usage of this version is conditioned by the presence of a license file and supported by the Titan support team.
+
+* For users outside Ericsson: https://projects.eclipse.org/projects/tools.titan/downloads. This version is licensed under the Eclipse Public License.
+
+A binary distribution, suitable for the used operating system (Solaris, Linux, FreeBSD), and for a C++ compiler, in a tar-gzip archive will be received. For Windowsfootnote:[For using TITAN on Windows platforms, installing the Cygwin programming environment is required see chapter 1.5 Installing Prerequisites on Cygwin (on Windows)] users there is no pre-built version, but compiling the open-source version is possible.
+
+WARNING: the version of C++ compiler used is important. If the version difference between the system’s compiler and the compiler that the basic TTCN–3 library was built with is large enough, the linking of executable test suites will fail with strange error messages. The reason is the different mapping of C++ class and (polymorphic) member function names into linker symbols.For example, this problem persists between versions 2.8.x and 2.95.x of GCC. Different C++ compilers (e.g. Sun Workshop and GCC) are, of course, totally incompatible. The solution for this problem is to use nearly the same version of the C++ compiler as the binary package was built with.
+
+Binaries for other operating systems or C++ compilers are available only on request.
+
+== Installing the Package
+
+No administrator (root) privileges are required for installation, but the install directory must be readable for all users of the test executor. Perform the following steps to install TITAN:
+
+. Create an empty directory, for example, `/usr/local/TTCN3` or `/home/<UserId>/TTCN3`. This directory will be referred as `$TTCN3_DIR` in the further sections of this document.
+. Copy the `.tgz` file into this directory.
+. Unpack all files from the archive using any of the following commands (assuming GNU tar): +
+`tar xvzf ttcn3-<version>-<platform>-<compiler>.tgz` +
+or +
+`gzip -dc ttcn3-<version>-<platform>-<compiler>.tgz | tar -xvf-`
+
+The following sub-directories are created:
+
+* `bin` contains the executable programs: The Compiler, the Makefile Generator, the Main Controller for parallel test execution and two log formatter utilities.
+* `etc` contains a demo license key, which enables to use the parser parts of the Compiler by any user on any host, that is, without C++ code generation. The installation can be tested with this demo key until the personalized license key is received.
+* `include` contains the C+/+ header files needed to compile the generated C++ code.
+* `lib` contains the pre-compiled Base Library for use with the generated C++ code both for single and parallel mode in static and dynamic linkingfootnote:[Note that not all platforms support dynamic linking.] formats.
+* `man` contains UNIX manual pages (for the Compiler and the Makefile Generator).
+* `demo` contains a simple TTCN–3 test suite ("Hello, world!") together with a sample test port and a compiled executable.
+* `doc` contains this documentation in PostScript and PDF formats.
+
+To complete the TITAN TTCN–3 Test Executor installation, some environmental variables should be set and the login script should be modified.
+
+NOTE: The C++ source code generated by this version (patch level) of Compiler is not compatible with older versions of TTCN–3 Base Library and vice versa.footnote:[Sometimes even the linking fails; but a successful linking does not mean that everything is correct at all.]If upgrading TITAN from an older version, all modules of existing test suites must be re-translated with the new compiler in order to make them running with the new libraries.
+
+It is recommended to make a backup copy of the older version of the distribution. There are some minor incompatibilities in the compiler’s grammar that may cause many syntax errors in TTCN–3 modules that were translated correctly with earlier versions.
+
+== Install TITAN with Clang
+
+Currently it is experimental to use TITAN with clang on Ubuntu operating system. It was tested only on Ubuntu. In order to use TITAN with clang on Ubuntu some steps must be done:
+
+. Install *clang-3.8* (3.8 is the required version).
+. Go into your TITAN installation directory and open (or create) the Makefile.personal file and add the following lines: +
+*CXX := clang++-3.8* +
+*CC := clang-3.8*
+. If TITAN is already compiled run *make distclean* command
+. To compile TITAN with clang run *make* and *make install* commands.
+
+There are some important notes about using clang with TITAN:
+
+* The C++ source code generated and TITAN must be compiled with the same version of clang. See section 2.2 note.
+* Makefiles of TTCN-3 projects must be modified by hand(replace *CXX = g++* with *CXX = clang++3.8*). Or regenerated using *makefilegen*, to use clang compiler. TITAN’s *makefilegen* can detect if it was compiled with clang and will generate makefiles with clang as default C++ compiler.
+* Required clang version is *3.8*.
+
+= Building Titan from source code
+
+== Obtaining the source code to your local machine
+
+The name of the source code repository of Titan is titan.core in the github. Follow steps as follows.
+
+. First time execute these commands: +
+`cd ~/git +
+git clone https://github.com/eclipse/titan.core.git` +
+This way a folder "titan.core", the "titan repository" will be created with the TITAN source code and build system. +
+To update the already existing repository execute these commands: +
+`cd ~/git/titan.core +
+git pull https://github.com/eclipse/titan.core.git`
+. Follow the instructions in the file "`titan.core/README.<your platform>`"
+. Continue with the next paragraph of this document.
+
+= Setting the User Environment
+
+This chapter describes the environment variables that must be set, and the modification of the user login scripts.
+
+== Environment Variables
+
+The following environment variables should be set:
+
+* With system administrator privileges, set the `$TTCN3_DIR` environment variable in the common `/etc/profile` and add the `$TTCN3_DIR/bin` directory to the system paths.
+* All tools of TITAN, including the Executable Test Suites, require a shared library of OpenSSL (`libcrypto.so`) for execution. To avoid incompatibilities, the suitable shared object file is provided in `$TTCN3_DIR/lib`, so add `$TTCN3_DIR/lib` to the `LD_LIBRARY_PATH` environment variable.
++
+WARNING: If this step is not performed, the compiler will not start!
+* Add `$TTCN3_DIR/man` to the `$MANPATH` environment variable to reach the manual pages directly.
+* If there is no valid license key, refer to link:5-licensing.md[Licensing]. If upgrading from an older version with a license key valid for this version, skip this step.
+* To run TITAN, ensure that the `$TTCN3_DIR` environmental variable has been set, for example, assuming a tcsh as login shell: `setenv TTCN3_DIR /usr/local/TTCNv3`
+* To use the TTCN–3 keyword help feature in the GUI with a web browser other than the default Netscape, it is necessary to set the `$TTCN3_BROWSER `environmental variable, for example, to specify Opera, type the following at the C-shell: `setenv $TTCN3_BROWSER opera`
+
+After setting the environmental variables, the TITAN TTCN–3 Test Executor installation is complete.
+
+== Modification of the User Login Script
+
+The following examples provide some help in modifying the login scripts.
+
+*Example modifications of login script* assuming bash as login shell:
+....
+TTCN3_DIR=/usr/local/TTCNv3
+PATH=$TTCN3_DIR/bin:$PATH
+LD_LIBRARY_PATH=$TTCN3_DIR/lib:$LD_LIBRARY_PATH
+MANPATH=$MANPATH:$TTCN3_DIR/man
+TTCN3_LICENSE_FILE=/home/tmpusr/license.dat
+export TTCN3_DIR PATH LD_LIBRARY_PATH MANPATH TTCN3_LICENSE_FILE
+....
+
+*Example modifications of login script* assuming tcsh as login shell:
+....
+setenv TTCN3_DIR /usr/local/TTCNv3
+setenv PATH ${TTCN3_DIR}/bin:${PATH}
+setenv LD_LIBRARY_PATH ${TTCN3_DIR}/lib:${LD_LIBRARY_PATH}
+setenv MANPATH ${MANPATH}:${TTCN3_DIR}/man
+setenv TTCN3_LICENSE_FILE /home/tmpusr/license.dat
+....
+
+== Modifying Makefile Library
+
+Make sure that the Makefile contains the following highlighted part:
+....
+SOLARIS8_LIBS = -lxnet -lxml2 -lresolv -lnsl -lsocket
+LINUX_LIBS = -lxml2 -lpthread -lrt
+....
+
+= Licensing
+
+This chapter describes how to obtain and install a TITAN license key.
+
+From version 1.1.pl8, TITAN can be used only with a valid license key.
+
+== Obtaining License Key (Only for Ericsson users)
+
+The license keys are *free of charge* and can be ordered via an HTML form on the following URL: Request a Titan licence at:
+
+https://ericoll.internal.ericsson.com/sites/Titan/Pages/TitanLicenses.aspx
+
+The personalized license key is a simple ASCII text file, which is sent as an e-mail attachment.
+
+Example of license file:
+....
+—–BEGIN TTCN-3 LICENSE FILE—–
+AAAAAUrhbm9zIFpvbHThbiBTemFi8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAFN6YWJvLkphbm9zQGV0aC5lcmljc3Nvbi5zZQAAAAAAAAAAAAAAAAAAAAAA
+AAAAAENvbmZvcm1hbmNlIExhYiwgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuAAAAAAAA
+AAAAAEVUSC9STC9TAAAAAAAAAAA7ygrgPayP34CzP9B0bXBqc3oAAAAAAAEAAAAB
+AAAAAAAAAAEAAABjAAAAYwAAAIEAAAAAAAAAADAsAhRmeNSqfy5/3iEHFsBi1miR
++imw2AIUdRN/V3m6gDQzVeMS+wFUl3UEeKgAAA==
+—–END TTCN-3 LICENSE FILE—–
+....
+
+The license key contains the following information encoded in PEM format of OpenSSL library:
+
+A unique identifier (integer number). If the license needs to be renewed or there are problems with licensing, refer to this `Unique ID`.
+
+* Personal data: user’s name, e-mail address, company’s name and department.
+* The time interval of the license key validity.
+* The host ID of the computer where the license is valid on (optional).
+* The login name that is allowed to use the tool with this key (optional).
+* The type of limitation, that is, host ID, login name or both.
+* The version interval of the Test Executor that the license key is valid for.
+* The list of features that are enabled by this key (in a bitmask).
+* DSA digital signaturefootnote:[The public key required to check the DSA signature is compiled into all tools and libraries.], which is calculated on all information fields to protect data integrity and make it impossible to modify license information by the user.
+
+== Installing the License Key
+
+Perform the following steps to install the license key:
+
+* Save the license key somewhere in the user home directory. The recommended name for it is `license.dat`, but it can be named alternatively
+* It is advised to change its permissions to read-only in order to avoid accidental modification or erasing.
+* Set the `TTCN3_LICENSE_FILE` environment variable to point to the license file with full path name. Add this command to the login script to do this step automatically for each login.
+* Check the validity of the license by issuing `$TTCN3_DIR/bin/compiler -v`. The compiler will print its version and the information contained in the license file. Also it checks the validity of the license key. Example printout:
+
+....
+TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
+Product number: CRL 113 200/4 R2A
+Build date: Sep 19 2014 10:17:18
+Compiled with: GCC 4.8.2
+
+Copyright Ericsson Telecom AB 2000-2014
+
+License information:
+--------------------------------------------------------
+License file : /home/ethbaat/license_98.dat
+Unique ID : 98
+Licensee : Attila Balasko
+E-mail : jeno.balasko@ericsson.com
+Company : Ericsson Hungary
+Department : ETH/XZR
+Valid from : Fri Sep 20 00:00:00 2002
+Valid until : Tue Aug 25 23:59:59 2015
+Limitation : USER
+Host ID : 00000000
+Login name : ethbaat
+Versions : from 1.1.pl0 until 1.99.pl99
+Languages : TTCN3 ASN1
+Encoders : RAW TEXT BER PER XER
+Applications : CODEGEN TPGEN SINGLE MCTR HC LOGFORMAT
+Max PTCs : 10000
+--------------------------------------------------------
+The license key is valid.
+Using OpenSSL 1.0.1e 11 Feb 2013
+....
+
+The last line of the printout indicates the success or the problems with the license key.
+
+If a host-limited key is needed, perform it in the same way but do it as system administrator. Copy it into a common directory, for example `$TTCN3_DIR/etc`, and set `TTCN3_LICENSE_FILE` in the common login script of all users, for example, in `/etc/profile`.
+
+= References
+
+* link:https://github.com/eclipse/titan.core/blob/master/usrguide/userguide/README.adoc[User Guide for TITAN TTCN-3 Test Executor]
+
+* link:https://github.com/eclipse/titan.core/blob/master/usrguide/referenceguide/README.adoc[Programmers Technical Reference for TITAN TTCN-3 Test Executor]
diff --git a/usrguide/pdfgen.sh b/usrguide/pdfgen.sh
deleted file mode 100755
index 6c65ac1b43968c0c1e71664cbd1ab41fe7611e1d..0000000000000000000000000000000000000000
--- a/usrguide/pdfgen.sh
+++ /dev/null
@@ -1,15 +0,0 @@
-###############################################################################
-# Copyright (c) 2000-2018 Ericsson Telecom AB
-# All rights reserved. This program and the accompanying materials
-# are made available under the terms of the Eclipse Public License v2.0
-# which accompanies this distribution, and is available at
-# https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
-#
-# Contributors:
-#   Balasko, Jeno
-#   Ormandi, Matyas
-#
-###############################################################################
-scp *.doc esekilxxen1843.rnd.ericsson.se:/home/titanrt/jenkins/usrguide_pdf/
-ssh esekilxxen1843.rnd.ericsson.se "make -C /home/titanrt/jenkins/usrguide_pdf && exit"
-scp esekilxxen1843.rnd.ericsson.se:/home/titanrt/jenkins/usrguide_pdf/*.pdf .
diff --git a/usrguide/referenceguide/1-about_the_document.adoc b/usrguide/referenceguide/1-about_the_document.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..b010f08f1bd11a8ecee6b8ab1fa7851cbc12f004
--- /dev/null
+++ b/usrguide/referenceguide/1-about_the_document.adoc
@@ -0,0 +1,22 @@
+= About the Document
+:toc:
+
+== Purpose
+
+The purpose of this document is to provide detailed information on writing components, for example, test ports, and so on, for executable test suites.
+
+== Target Groups
+
+This document is intended for programmers of TTCN–3 test suites with information in addition to that provided in the <<_13, TITAN User Guide>>. It is recommended that the programmer reads the TITAN User Guide before reading this document.
+
+== Typographical Conventions
+
+This document uses the following typographical conventions:
+
+*Bold* is used to represent graphical user interface (GUI) components such as buttons, menus, menu items, dialog box options, fields and keywords, as well as menu commands. Bold is also used with ’+’ to represent key combinations. For example, *Ctrl+Click*
+
+The character `**/**' is used to denote a menu and sub-menu sequence. For example, *File / Open*.
+
+`Monospaced` font is used represent system elements such as command and parameter names, program names, path names, URLs, directory names and code examples.
+
+*`Bold monospaced`* font is used for commands that must be entered at the Command Line Interface (CLI).
diff --git a/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc b/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..5be86a222180871ebd67d95da0a06333b893ee7d
--- /dev/null
+++ b/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
@@ -0,0 +1,89 @@
+= Code Coverage of TTCN-3 Modules
+
+Note: the feature described here is deprecated; please use instead the coverage tool described in <<4-ttcn3_language_extensions.adoc#profiling-and-code-coverage, Profiling and code coverage>>.
+
+The TTCN-3 compiler is able to instrument the generated C/C++ code for a set of TTCN-3 modules (= or files) to generate code coverage information during runtime. To enable this feature the `-K file` option needs to be used. For convenience this option is available for `ttcn3_makefilegen` as well. It’s possible to generate code coverage information only for a given set of TTCN-3 modules listed on the command line. In that case the set of files in `file` needs to be a subset of the files listed on the command line. If `file` contains a file which is not listed on the command line an error will be issued.
+
+== Generating Code Coverage
+
+Assuming a project with the following files: `a.ttcn`, `b.ttcn`, `c.ttcn` in parallel mode and some PTCs during runtime were created. The scenario is the following:
+
+. Install LCOV. It’s an external tool necessary to generate HTML output. Available here: http://ltp.sourceforge.net/coverage/lcov.php or can be installed using the package manager of your OS. This step needs to be performed only once.
+
+. Create an ASCII text file listing all the TTCN-3 modules to generate code coverage data for, one file name in a line. In this case we want to generate code coverage data for `a.ttcn` and `b.ttcn` and we’re not interested in `c.ttcn`. Our `tcov_file_list.txt` will look like: `a.ttcn, b.ttcn`
+
+. Generate a `Makefile` using `tcov_file_list.txt`:
++
+[source]
+ttcn3_makefilegen -K tcov_file_list.txt -g -e mytest *.ttcn
+
+. Run: make
+
+. Then: `ttcn3_start ./mytest`
++
+(During runtime some .tcd XML files will be generated. Namely a `tcov-<component_id>.tcd` file per PTC and one for MTC.)
+
+. Collect and merge all .tcd files using `tcov2lcov` with default parameters:
++
+[source]
+tcov2lcov
++
+(An `output.info` file will be generated in the current working directory. For more detailed information about `tcov2lcov` see <<command-line-syntax-of-tcov2lcov, here>>.)
+
+. Generate HTML using LCOV’s `genhtml` and the generated `output.info` (see <<converting-code-coverage-data-from-xml-to-html, here>> for more information):
++
+[source]
+genhtml –no-branch-coverage –t "Titan Coverage" –legend output.info –o titan_coverage
+
+. Open `titan_coverage/index.html` in a browser.
+
+[[converting-code-coverage-data-from-xml-to-html]]
+== Converting Code Coverage Data from XML to HTML
+
+The `tcov2lcov` tool (binary tool) shipped with Titan and LCOV’s `genhtml` tool (Perl script) are provided to generate human readable HTML from the Titan generated .tcd XML code coverage data files. LCOV’s `genhtml` is not part of the Titan distribution and needs to be installed separately. The basic process is the following:
+
+. Execute `tcov2lcov` to collect and merge all the .tcd files generated during test execution. One .tcd file per component. By default an `output.info` file will be generated in the current working directory, which can be processed directly by LCOV’s `genhtml`. More detailed information about `tcov2lcov` can be found in 10.3.
+. Execute `genhtml` with `output.info` as its input parameter. The recommended parameters are the following:` genhtml –no-branch-coverage -t "Titan Coverage" –legend output.info -o titan_coverage`. For more detailed introduction to `genhtml` and LCOV in general please read their user manuals at http://ltp.sourceforge.net/coverage/lcov.php.
+
+[[command-line-syntax-of-tcov2lcov]]
+== Command Line Syntax of tcov2lcov
+
+[source]
+tcov2lcov [-h][-b dir][-d dir][-o file][-x xsd]
+
+or
+
+[source]
+tcov2lcov -v
+
+The Titan code coverage data to LCOV coverage data converter collects all valid .tcd XML files from a given directory recursively and generates a single ASCII text file suitable to be further processed by LCOV’s `genhtml` tool to produce human readable HTML output. Please note that the output format generated by `tcov2lcov` is also human readable ASCII, but its only purpose is to provide an input for LCOV’s `genhtml` tool. This format is LCOV specific and not documented here.
+
+The following command line options are available (listed in alphabetical order):
+
+* `-b dir` (optional)
++
+Set code base directory for source files. `dir` is usually the absolute path to the directory of the source files. This path is used as a common prefix for `genhtml`. The default value is the absolute path of the current working directory.
+
+* `-d dir` (optional)
++
+`.tcd` files will be collected from `dir` recursively. By default the current working directory will be examined.
+
+* `-h` (optional)
++
+Display help.
+
+* `-o file` (optional)
++
+Set the name of the output file. The default file name is `output.info`.
+
+* `-x xsd` (optional)
++
+Path to an XSD to validate all .tcd XML files found against. By default `$TTCN3_DIR/include/tcov.xsd` is used. This XSD file is part of the Titan distribution. If any of the .tcd files doesn’t conform to the XSD an error will be given.
+
+== Limitations
+
+The Titan compiler implements some optimizations which can affect the accuracy of the generated code coverage information. These optimizations cannot be turned off. The compile time evaluation of constant expressions can lead to untracked lines and statements (white in LCOV’s HTML output) invisible to the code coverage information generator. These lines and statements are not counted as never-executed lines and statements (orange in LCOV’s HTML output), so the statistics are not affected, but the end result can be confusing.
+
+External functions are not yet supported and they’re not shown in the statistics.
+
+The Titan code coverage implementation is based on Titan’s internal location tracking mechanism enabled by the `–L` compiler flag, which must be used together with `-K`. Sometimes it can lead to a little bit confusing or strange code coverage output. E.g. multiple location objects are generated when multiple variable declarations appear on the same line in the TTCN-3 source code. In this case the code coverage output will show that the given line is executed twice. For more complex statements like `for` three location objects are generated etc.
diff --git a/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc b/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..8929682a13fb668645a5b5ef5197b92fa3231630
--- /dev/null
+++ b/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
@@ -0,0 +1,643 @@
+= The TTCN-3 Debugger
+:toc:
+:table-number: 42
+
+The TTCN-3 debugger is a feature in TITAN, which allows the user to pause (halt) the execution of a TTCN-3 program and print (or in some cases overwrite) information about the current state of the program.
+
+The compiler option `–n` activates the debugger and augments the generated C++ code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
+
+== Gathered information
+
+This section details the various types of information gathered by the debugger.
+
+NOTE: The debugger refers to the following TTCN-3 entities as "functions": `functions`, `external` `functions`, `testcases`, `altsteps`, `control` parts and parameterized templates. The debugger refers to the following TTCN-3 entities as "variables": constants (including those imported from ASN.1 modules), external constants, templates, variables, template variables, module parameters, timers and function parameters.
+
+=== The call stack
+
+The debugger maintains a stack of the currently called functions. The bottom entry in the stack is the oldest (first) function call, while the top-most entry in the stack is the newest function call.
+
+A separate call stack is maintained for each component.
+
+For each entry in the call stack the debugger stores the function name (or the module name in case of control parts), function type (the TTCN-3 keywords used when defining the function) and the current values of the function’s parameters.
+
+[[variables]]
+=== Variables
+
+The debugger keeps track of all variables (that are currently alive). Each variable’s name, type, current value, module name (where the variable was declared) and scope are stored.
+
+A variable’s scope refers to which functions and code blocks the variable is visible from. Variables can be grouped into 3 categories based on their scope:
+
+* *Global variables* are the ones that are declared outside of all functions and component types. These are visible from all functions declared in the same module as the variable and from all functions declared in modules that import the variable’s module.
+* *Component variables* are the one declared in component types. The variables of a specific component type (including variables of component types that the component in question extends) are visible from all functions that run on that component type.
+* *Local variables* are the variables declared within a function, and they are only visible inside that function.
+
+NOTE: The names of variables defined in ASN.1 code are converted to TTCN-3 format before being stored (hyphens are replaced with underscores, and an additional underscore is added to the end of the name if it clashes with a TTCN-3 keyword).
+
+=== Function call data
+
+The debugger stores data about which functions were called since the beginning of the program’s execution. A snapshot is taken of each function call at the beginning and end of its execution. The amount of function calls stored can be limited by the user.
+
+These snapshots contain a time stamp, the function’s name (or the module name in case of control parts), its type (the TTCN-3 keywords used when defining the function), the value of its parameters (`in` and `inout` parameters for starting snapshots, `inout` and `out` parameters for ending snapshots) and its return value (only for ending snapshots).
+
+== Breakpoints
+
+The debugger provides several ways to halt a TTCN-3 program:
+
+* user breakpoints – breakpoints can be set by the user to any line or function in the TTCN-3 code;
+* automatic breakpoints – certain events can be set to halt the program automatically;
+* stepping – the user can step to the next line of code (when the program is already halted), or to a specific line or function;
+* manual halt – the user can halt the program manually (regardless of which line is currently being executed).
+
+When the program is halted, no further TTCN-3 code is executed, until the user manually resumes the program’s execution.
+
+User breakpoints halt the program before the associated line of code starts executing. If a breakpoint is set at a function, then it would halt the program before the first line in the function (that contains executable code) begins execution.
+
+When the program is halted in parallel mode, the execution of all components is halted, not just the component that triggered the halt. The component that triggers the breakpoint (or reaches the stepping point) is halted immediately. The other components are halted with a slight delay. If the program was halted manually, then all components are halted with a slight delay. Resuming a halted program also has a slight delay on all components.
+
+NOTE: Timers are not paused when the program is halted. They continue ticking, and may time out, if the program is halted long enough.External programs that communicate with the TTCN program (e.g. the SUT) are also not halted, and not receiving any messages from the TTCN program might cause them to behave differently than if the program wasn’t halted.
+
+== User interface and list of commands
+
+The user communicates with the debugger through a command line interface. In parallel mode this interface is the Main Controller’s user interface (details about the MC can be found in <<13-references.adoc#_13, [13]>>). In single mode a similar interface is displayed whenever the program is halted.
+
+An answer or result is displayed through the user interface for all debugger commands (even erroneous ones). In parallel mode certain debugger commands are sent to multiple components. In this case an answer is displayed from each component the command was sent to.
+
+Both user interfaces support the execution of debugger commands from a text file (batch file). Details about batch files can be found <<batch-files, here>>.
+
+The various commands available through the user interface are grouped into 4 categories, detailed in subsections <<settings, Settings>> through <<batch-files, Bacth Files>>.
+
+=== Debugging with the Main Controller
+
+Debugger commands are given to the MC’s interface the same way as regular MC commands (all debugger commands start with 'd').
+
+No special settings are needed for the MC to execute debugger commands (like the `-n` switch for the compiler). The MC always knows all debugger commands, and will redirect the commands to the appropriate HCs, PTCs and/or the MTC.
+
+If debugging was activated on an HC, then it and its test components (PTCs and/or the MTC) will process the received command and return an answer to the MC. The MC displays all answers received from the MTC and PTCs, which means that one debugger command can result in multiple answers (one from each affected test component). The HC is always silent; it never returns textual answers to the MC. The debugger on the HC only stores settings for future PTCs.
+
+If debugging is deactivated on an HC, then it and its test components will ignore all debugger commands from the MC.
+
+Example:
+
+One HC is connected to the MC with debugging activated. The MTC and 2 PTCs are running on the one HC. The MC receives the following command:
+
+[source,subs="+quotes"]
+----
+*dsetbp MyModule 123*
+----
+
+See subsection <<settings, Settings>> for details about this command.
+
+Results:
+[source]
+----
+MTC@hostname: Breakpoint added in module ‘MyModule’ at line 123 with no batch file.
+ptc1(3)@hostname: Breakpoint added in module ‘MyModule’ at line 123 with no batch file.
+ptc2(4)@hostname: Breakpoint added in module ‘MyModule’ at line 123 with no batch file.
+----
+
+=== Debugging with the single mode UI
+
+The debugger has its own command line user interface in single mode. This interface only knows debugger commands.
+
+The interface becomes active whenever the debugger halts test execution, displaying the prompt '`DEBUG>`'.
+
+NOTE: Two command line options, `-h` and `-b`, are available to initialize the debugger (otherwise it would never cause a halt) when running a TTCN-3 executable in single mode. These are described in the User Guide (<<13-references.adoc#_13, [13]>>).
+
+By default, this user interface is only capable of reading strings one line at a time. This can be upgraded to know command completion and command history, like the Main Controller’s user interface, by rebuilding the TITAN runtime libraries with the `ADVANCED_DEBUGGER_UI := yes` setting (in the personal Makefile). This requires the `libcurses` or `libncurses` (depending on platform) library to be added to the TTCN-3 executable’s linking command in the Makefile. If the Makefile was generated by the `ttcn3_makefilegen` tool, then regenerating it will update the linking command with this new library.
+
+Another solution to using command completion and command history is to build the TTCN-3 executable in parallel mode and use the Main Controller’s UI.
+
+[[settings]]
+=== Settings
+
+*On/off switch*
+
+Command syntax: `debug (on | off)`
+
+Default setting: off
+
+Description: This is a separate on/off switch for the debugger, which can be changed at runtime (and thus does not require the program to be rebuild every time it is changed).
+
+When switched off the debugger does not track local variables, does not store function call data and does not halt the program. It still maintains the current call stack and tracks global and component variables.
+
+*Global batch file*
+
+Command syntax: `dglobbatch (off | (on <batch file>))`
+
+Default setting: off
+
+Description: Activates or deactivates the global batch file, or changes the file it refers to.
+
+The global batch file is executed automatically whenever the program is halted. If the program was halted by a user or automatic breakpoint that has a batch file associated with it, then the global batch file is not executed, only the breakpoint’s own batch file.
+
+*Set breakpoint*
+
+Command syntax: `dsetbp <module> (<line> | <function>) [<batch file>]`
+
+Default setting: -
+
+Description: Creates a new user breakpoint at the specified location (module name and either line number or function name) with or without a batch file, or changes the batch file setting of an existing breakpoint.
+
+NOTE: The first argument is the name of the module, not the name of the TTCN-3 file.
+
+If the breakpoint has a batch file set, then this batch file is automatically executed when the breakpoint is triggered.
+
+If the breakpoint has no batch file of its own set, and a global batch file is set, then the global batch file is executed when the breakpoint is triggered (i.e. the local batch file overwrites the global batch file).
+
+The validity of the command’s parameters is not checked. A breakpoint set at a line, function or module that does not exist or does not contain executable code (e.g. a line containing only '}') will never be triggered.
+
+*Remove breakpoint*
+
+Command syntax: `drembp (all | (<module> (all | <line> | <function>)))`
+
+Default setting: -
+
+Description: Removes the breakpoint at the specified location (if it exists), or removes all breakpoints in the specified module, or removes all breakpoints in all modules.
+
+Examples:
+[source]
+----
+Example 1 – removing one breakpoint, from module MyModule, line 114:
+drembp MyModule 114
+
+Example 2 – removing all breakpoints from module MyModule:
+drembp MyModule all
+
+Example 3 – removing all breakpoints:
+drembp all
+----
+
+*Automatic breakpoint*
+
+Command syntax: `dautobp (error | fail) (off | (on [<batch file>]))`
+
+Default setting: all automatic breakpoints are switched off
+
+Description: Activates or deactivates an automatic breakpoint, or changes the batch file settings of an activated automatic breakpoint.
+
+Automatic breakpoints are breakpoints triggered by specific events. The first argument indicates which automatic breakpoint to change:
+
+* *error* – triggered when the component’s verdict is set to `error` by a dynamic test case error (not all dynamic test case errors trigger this breakpoint, only those that actually change the local verdict to `error`);
+* *fail* – triggered when the component’s verdict is set to `fail` (by a `setverdict` operation.
+
+If the automatic breakpoint has a batch file set, then this batch file is automatically executed when the breakpoint is triggered.
+
+If the breakpoint has no batch file of its own set, and a global batch file is set, then the global batch file is executed when the breakpoint is triggered (i.e. the local batch file overwrites the global batch file).
+
+*Set output*
+
+Command syntax: `doutput (console | ((file | both) <file name>))`
+
+Default setting: console
+
+Description: Changes the destination of the debugger’s output (notifications and results of commands). The debugger’s output can be displayed by the user interface (`console'), or it can be written to a text file ('file'). The option `both' writes the debugger’s output to both the user interface and the specified file.
+
+The file name may contain special metacharacters, which are substituted dynamically during test execution (these are a subset of the metacharacters usable in log file names).
+
+NOTE: In parallel mode output files are created in the host’s working directory (not the MC’s).
+
+.Available metacharacters for setting output file names
+[cols="m,",options="header",]
+|===
+|Meta-character |Substituted with . . .
+|%e |the name of the TTCN–3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%h |the name of the computer returned by the `gethostname`(2) system call. This usually does not include the domain name.
+|%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
+|%n a|* the name of the test component if the PTC has been given a name with the command `create` in the TTCN-3 `create` operation; an empty string otherwise. +
+* the string `MTC` if the component is the Main Test Component (both in parallel and in single mode)
+| %p | the process ID (`pid`) of the UNIX process that implements the current test component. The `pid` is written in decimal notation.
+| %r | the component reference or component identifier. On PTCs it is the component reference (an integer number greater or equal to 3) in decimal notation. On the Main Test Component or in single mode the strings `mtc` or `single` are substituted, respectively.
+| %% | a single % character. |
+|===
+
+*Function call data configuration*
+
+Command syntax: `dcallcfg (all | <buffer size> | (file <file name>))`
+
+Default setting: all
+
+Description: Changes the method of storing function call data. The new configuration is specified by the command’s first argument:
+
+* 'all' – In this case all function calls are stored by the debugger. This option damages the program’s performance the most (specifically its memory consumption), since two long strings are stored every time a function is called and they are not deleted until the program’s execution ends.
+* _buffer size_ – This option sets an upper limit to the amount of function call snapshots stored (equal to `<buffer size>`). The function calls are stored in a ring buffer. If the buffer is full, then storing a new snapshot will cause the oldest stored snapshot to be erased. The buffer size can also be set to zero, in which case no function call data is stored.
+* 'file' – In this case the function call data is sent directly to a file and not stored by the debugger. The file is specified by the second argument.
++
+The file name may contain special metacharacters, which are substituted dynamically during test execution.
+
+NOTE: In parallel mode output files are created in the host’s working directory (not the MC’s).
+This commands also erases all previously stored function call data (unless the new setting is exactly the same as the old one).
+
+[[commands-related-to-printing-and-overwriting-data]]
+=== Commands related to printing and overwriting data
+
+*Print settings*
+
+Command syntax: `dsettings`
+
+Prerequisites: none
+
+Description: Prints the current states of all settings listed in the previous section.
+
+*Set component*
+
+Command syntax: `dsetcomp (<component name> | <component reference>)`
+
+Prerequisites: parallel mode
+
+Description: Changes the currently active test component to the one specified by the component name or reference.
+
+The active component is the component that receives all of the debugger commands related to printing and overwriting data. Only components that are currently running code are valid candidates.
+
+The active component is automatically set to the MTC when the MC is started. If the active component was set to a PTC that is no longer running anything, then it is set back to the MTC. Whenever the debugger halts the program, the active component is set to the component that triggered the halt (halting the program manually does not change the active component).
+
+*List components*
+
+Command syntax: `dlistcomp`
+
+Prerequisites: parallel mode
+
+Description: Lists the name and reference of the MTC and the names and references of all PTCs that are currently executing a function (i.e. all test components that can be the target of the `dsetcomp' command).
+
+The active component is marked with an asterisk (*) in the resulting list.
+
+*Set stack level*
+
+Command syntax: `dstacklevel <level>`
+
+Prerequisites: call stack is not empty
+
+Description: Sets the current stack level to the specified level. The new level must be a valid index in the call stack (from 1 to the size of the call stack).
+
+The current stack level is the level where variables are listed, printed and overwritten from.
+
+The current stack level is automatically set to 1 whenever the program is halted.
+
+*Print call stack*
+
+Command syntax: `dprintstack`
+
+Prerequisites: call stack is not empty
+
+Description: Prints the current call stack. The function at the top of the call stack is printed first (with the index of '1'). For each function its index, type, name and current value of parameters are printed (together with the parameters’ names and directions).
+
+The function at the current stack level is marked with an asterisk (*).
+
+*List variables*
+
+Command syntax: `dlistvar [(local | global | comp | all)] [<pattern>]`
+
+Prerequisites: call stack is not empty
+
+Description: Lists the names of all variables visible in the function at the current stack level. The variable names are separated by spaces.
+
+The command’s two optional arguments can be used to filter the resulting list.
+
+The first argument can reduce the list to only variables of a certain type (with the values 'local', 'global' and 'comp'; their meanings are explained in section <<variables, Variables>>). Setting the argument to 'all' or omitting it does not filter the list, and displays all variables of all types.
+
+The second argument is a pattern string, which can be used to filter the list. It has the same syntax as a TTCN-3 pattern.
+
+NOTE: The names of imported global variables are prefixed with their module name.
+
+*Print variable*
+
+Command syntax: `dprintvar { (<variable name> | $) }`
+
+Prerequisites: call stack is not empty
+
+Description: Prints the types, names and values of the specified variables. Each printed line contains one variable (or a notification if the variable was not found).
+
+The variables are searched for via their name. The searched names of global variables may also be prefixed with the module name (i.e. <module>.<variable>).
+
+The printed value of a variable has the same format as when logged using the `log` function.
+
+The metacharacter `$' is automatically substituted with the result of the last executed `dlistvar' command (on the active component).
+
+*Overwrite variable*
+
+Command syntax: `dsetvar <variable name> <new value>`
+
+Prerequisites: call stack is not empty
+
+Description: Overwrites the value of the specified variable.
+
+The variable is searched for via its name. The searched name of a global variable may also be prefixed with the module name (i.e. <module>.<variable>).
+
+The syntax of the new value is the same as the syntax of a module parameter or the `text2ttcn` predefined function (this entire command is essentially a `text2ttcn` call on the specified variable with the specified new value string).
+
+If the new value is incomplete (e.g. the assignment notation is used, and not all fields of the `record`/`set` or not all elements of the `record` `of`/`set` `of` are specified), then the rest of the variable is not changed.
+
+Variables that are constant in TTCN-3 (i.e. `consts`, `templates`, `modulepars`, `modulepar` `templates` and external `consts`) cannot be overwritten by this command either.
+
+Timers, ports and signatures cannot be overwritten.
+
+*Print function call data*
+
+Command syntax: `dprintcalls [(all | <limit>)]`
+
+Prerequisites: none
+
+Description: Prints the stored function call data (detailed in section 11.1.3).
+
+The first argument (integer number) can be used to limit the amount of snapshots to print. In this case only the last (newest) function calls are printed. Setting the argument to 'all' or omitting it prints all stored function calls.
+
+Each printed line contains the called function’s type, whether it’s a starting or ending snapshot, the function’s name, parameters (including the parameter’s directionfootnote:[in, inout or out], name and value) and the returned value.
+
+[[commands-related-to-the-halted-state]]
+=== Commands related to the halted state
+
+*Halt*
+
+Command syntax: `dhalt`
+
+Prerequisites: parallel mode, program is not halted, the MTC’s call stack is not empty
+
+Description: Halts the program’s execution.
+
+This cannot be used in single mode, since the debugger’s user interface only appears if the program is already halted.
+
+*Continue*
+
+Command syntax: `dcont`
+
+Prerequisites: program is halted
+
+Description: Resumes the program’s execution.
+
+*Exit*
+
+Command syntax: `dexit (test | all)`
+
+Prerequisites: none
+
+Description: Stops the execution of the current program. If the argument is `test', then only the current test case or control part is stopped. If the argument is 'all', then the entire program is terminated.
+
+In parallel mode this does not exit the MC nor does it terminate the MTC. Test execution can be restarted after this with the 'smtc' command.
+
+*Step over*
+
+Command syntax: `dstepover`
+
+Prerequisites: program is halted
+
+Description: Steps onto the next line of code. This type of stepping does not enter functions. If the current line is the last line in the function, then this steps onto the line that called the function.
+
+NOTE: This command is interrupted if the program is halted for any reason before the next line is reached (this will not cause the program to be halted a second time, when the next line is eventually reached).
+
+*Step into*
+
+Command syntax: `dstepinto`
+
+Prerequisites: program is halted
+
+Description: Steps onto the next line of code. If there is a function call in the current line, then this steps onto the called function’s first line. If the current line is the last line in the function, then this steps onto the line that called the function.
+
+NOTE: This command is interrupted if the program is halted for any reason before the next line is reached (this will not cause the program to be halted a second time, when the next line is eventually reached).
+
+*Step out*
+
+Command syntax: `dstepout`
+
+Prerequisites: program is halted
+
+Description: Steps out of the current function and onto the line that called the function.
+
+NOTE: This command is interrupted if the program is halted for any reason before the specified line is reached (this will not cause the program to be halted a second time, when the specified line is eventually reached).
+
+*Run to cursor*
+
+Command syntax: `drunto <module> (<line> | <function>)`
+
+Prerequisites: program is halted
+
+Description: Resumes the program’s execution until the specified line or function is reached.
+
+NOTE: This command is interrupted if the program is halted for any reason before the specified location is reached (this will not cause the program to be halted a second time, when the specified location is eventually reached).
+
+[[batch-files]]
+=== Batch files
+
+Both the MC’s user interface and the debugger’s user interface in single mode support the execution of commands from a text file (batch file).
+
+Each line in the batch file is treated as one command. Empty lines are ignored. Encountering an erroneous command does not stop the batch file’s execution.
+
+Execution of batch files can be initiated manually using the `batch' command.
+
+Syntax: `batch <file name>`
+
+Batch files may contain any of the debugger commands listed in this section, including the `batch' command. In parallel mode they may also contain any of the MC’s commands.
+
+Certain debugger settings (such as breakpoints) can initiate the execution of a batch file automatically. In this case the program’s execution remains halted after the execution of the batch file, unless the batch file contains a command that ends the halted state (e.g. dcont).
+
+The entire debugging process can be automated with the use of batch files that end with the `dcont' command. An initial batch file could initialize the debugger’s settings, set all breakpoints to automatically execute a batch file, and/or set a global batch file, and start the program. This way whenever the program would be halted, the automatically executed batch file would resume it.
+
+NOTE: In parallel mode batch files are searched for in the MC’s working directory.
+
+== Example
+
+This section contains an example for some of the debugger’s features. The example contains one TTCN-3 module with one test case, executed in single mode. Two tests are run. In both cases the debugging process is fully automated with the use of batch files. The executable’s –b command line option is used to run the first batch file.
+
+The TTCN-3 module (demo.ttcn):
+[source]
+----
+module demo {
+
+type component CT {
+  // component variables
+  const integer ct_int := 4;
+  var charstring ct_str := "abc";
+}
+
+type record Rec {
+  integer num,
+  charstring str
+}
+
+type record of integer IntList;
+
+// global variable
+template integer t_int := (1..10);
+
+function f_fact(in integer n) return integer {
+  if (n == 0 or n == 1) {
+    return 1; // line 21
+  }
+  return n * f_fact(n - 1);
+}
+
+testcase tc_demo() runs on CT {
+  // local variables
+  var Rec v_rec := { num := ct_int, str := ct_str };
+  var template IntList vt_list := { [0] := 1, [2] := * };
+
+  if (match(f_fact(v_rec.num), t_int)) {
+    v_rec.str := v_rec.str & "!";
+  }
+  else {
+    v_rec.str := v_rec.str & "?";
+  }
+
+  var IntList v_list := { 1, 2, 9 };
+
+  if (match(v_list, vt_list)) { // dynamic test case error, line 40
+    action("matched");
+  }
+}
+
+} // end of module
+----
+The makefile for the example is generated with the following command:
+
+[source,subs="+quotes"]
+*ttcn3_makefilegen -sgn demo.ttcn*
+
+Both tests use the following configuration file (cfg.cfg):
+[source]
+----
+[EXECUTE]
+demo.tc_demo
+----
+
+=== Test 1
+
+Initializer batch file (start1.bat):
+[source]
+----
+debug on
+dautobp error on error.bat
+dsetbp demo 21 bp21.bat
+----
+
+Batch file for the breakpoint at line 21 (bp21.bat):
+[source]
+----
+dprintstack
+dlistvar all
+dstacklevel 5
+dlistvar comp
+dprintvar ct_int
+dlistvar local
+dprintvar $
+dcont
+----
+
+Batch file for the automatic breakpoint for error verdicts (error.bat):
+[source]
+----
+dprintss
+dlistvar local v_*
+dprintvar $
+dcont
+----
+
+Results of running `./demo -b start1.bat cfg.cfg` (debugger output highlighted in [yellow-background]#yellow#, echoed debugger commands highlighted in [aqua-background]#turquoise#):
+
+[source,subs="+quotes"]
+----
+TTCN-3 Test Executor (single mode), version CRL 113 200/5 R5A
+Using configuration file: `cfg.cfg'
+[yellow-background]#Test execution halted.
+Executing batch file 'start1.bat'.#
+[aqua-background]#debug on#
+[yellow-background]#Debugger switched on.#
+[aqua-background]#dautobp error on error.bat#
+[yellow-background]#Automatic breakpoint at error verdict switched on with batch file 'error.bat'.#
+[aqua-background]#dsetbp demo 21 bp21.bat#
+[yellow-background]#Breakpoint added in module 'demo' at line 21 with batch file 'bp21.bat'.
+Test execution resumed.#
+Test case tc_demo started.
+[yellow-background]#User breakpoint reached at line 21 in module 'demo'.
+Test execution halted.
+Executing batch file 'bp21.bat'.#
+[aqua-background]#dprintstack#
+[yellow-background]#1.	[function]	f_fact([in] n := 1)
+2.	[function]	f_fact([in] n := 2)
+3.	[function]	f_fact([in] n := 3)
+4.	[function]	f_fact([in] n := 4)
+5.	[testcase]	tc_demo()#
+[aqua-background]#dlistvar all#
+[yellow-background]#n t_int#
+[aqua-background]#dstacklevel 5#
+[yellow-background]#Stack level set to:
+5.	[testcase]	tc_demo()#
+[aqua-background]#dlistvar comp#
+[yellow-background]#ct_int ct_str#
+[aqua-background]#dprintvar ct_int#
+[yellow-background]#[integer] ct_int := 4#
+[aqua-background]#dlistvar local#
+[yellow-background]#v_rec vt_list#
+[aqua-background]#dprintvar $#
+[yellow-background]#[Rec] v_rec := { num := 4, str := "abc" }
+[IntList template] vt_list := { 1, <uninitialized template>, * }#
+[aqua-background]#dcont#
+[yellow-background]#Test execution resumed.#
+demo.ttcn:40: Dynamic test case error: Matching with an uninitialized/unsupported integer template.
+[yellow-background]#Automatic breakpoint (error verdict) reached at line 40 in module 'demo'.
+Test execution halted.
+Executing batch file 'error.bat'.#
+[aqua-background]#dprintss#
+[yellow-background]#[testcase]	started 	tc_demo()
+[function]	started 	f_fact([in] n := 4)
+[function]	started 	f_fact([in] n := 3)
+[function]	started 	f_fact([in] n := 2)
+[function]	started 	f_fact([in] n := 1)
+[function]	finished	f_fact([in] n := -) returned 1
+[function]	finished	f_fact([in] n := -) returned 2
+[function]	finished	f_fact([in] n := -) returned 6
+[function]	finished	f_fact([in] n := -) returned 24#
+[aqua-background]#dlistvar local v_*#
+[yellow-background]#v_rec v_list#
+[aqua-background]#dprintvar $#
+[yellow-background]#[Rec] v_rec := { num := 4, str := "abc?" }
+[IntList] v_list := { 1, 2, 9 }#
+[aqua-background]#dcont#
+[yellow-background]#Test execution resumed.#
+Test case tc_demo finished. Verdict: error
+Verdict statistics: 0 none (0.00 %), 0 pass (0.00 %), 0 inconc (0.00 %), 0 fail (0.00 %), 1 error (100.00 %).
+Test execution summary: 1 test case was executed. Overall verdict: error
+----
+
+=== Test 2
+
+Initializer batch file (start2.bat):
+[source]
+----
+debug on
+dsetbp demo 40 bp40.bat
+----
+
+Batch file for the breakpoint at line 40 (bp40.bat):
+[source]
+----
+dprintvar vt_list
+dsetvar vt_list { [1] := 2 }
+dcont
+----
+
+Results of running ./demo -b start2.bat cfg.cfg (debugger output highlighted in [yellow-background]#yellow#, echoed debugger commands highlighted in [aqua-background]#turquoise#):
+
+[source,subs="+quotes"]
+----
+TTCN-3 Test Executor (single mode), version CRL 113 200/5 R5A
+Using configuration file: `cfg.cfg'
+Test execution halted.
+Executing batch file 'start2.bat'.
+[aqua-background]#debug on#
+[yellow-background]#Debugger switched on.#
+[aqua-background]#dsetbp demo 40 bp40.bat#
+[yellow-background]#Breakpoint added in module 'demo' at line 40 with batch file 'bp40.bat'.
+Test execution resumed.#
+Test case tc_demo started.
+[yellow-background]#User breakpoint reached at line 40 in module 'demo'.
+Test execution halted.
+Executing batch file 'bp40.bat'.#
+[aqua-background]#dprintvar vt_list#
+[yellow-background]#[IntList template] vt_list := { 1, <uninitialized template>, * }#
+[aqua-background]#dsetvar vt_list { [1] := 2 }#
+[yellow-background]#[IntList template] vt_list := { 1, 2, * }#
+[aqua-background]#dcont#
+[yellow-background]#Test execution resumed.#
+Action: matched
+Test case tc_demo finished. Verdict: none
+Verdict statistics: 1 none (100.00 %), 0 pass (0.00 %), 0 inconc (0.00 %), 0 fail (0.00 %), 0 error (0.00 %).
+Test execution summary: 1 test case was executed. Overall verdict: none
+----
diff --git a/usrguide/referenceguide/12-tips_&_troubleshooting.adoc b/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..bc3463da85d57d9129a6d4bebd17d5f306581124
--- /dev/null
+++ b/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
@@ -0,0 +1,408 @@
+= Tips & Troubleshooting
+:toc:
+
+This chapter deals with various topics, which could not have been assigned to any of the previous chapters.
+
+== Type Aliasing
+
+Type aliasing in TTCN–3 means that you can assign an alternative name to an existing type. The syntax is similar to a subtype definition, but the subtype restriction tag (value list or length restriction) is missing.
+
+`type MyType MyAlternativeName;`
+
+The type aliasing is implemented in the test executor, but it translates this TTCN–3 definition to a C `typedef` statement.
+
+`typedef MyType MyAlternativeName;`
+
+The limitation of the C typedef is that the C\++ compiler cannot distinguish between the original and alias name in polymorphism (i.e. the identically named functions with parameter type `MyType` and `MyAlternativeName` are treated as same). That is, if you define a port type that allows the sending or receiving both of the original and aliased type, the generated C++ code cannot be compiled because the Test Port class contains two identical send/receive function.
+
+As a work-around to this problem you can repeat the definition of the original type using the alternative name instead of type aliasing. In this case two differently named, but identical classes will be generated and the polymorphism problem will not occur.
+
+[[reusing-logged-values-or-templates-in-ttcn-3-code]]
+== Reusing Logged Values or Templates in TTCN–3 Code
+
+Writing templates can be time-consuming task. To save some time and work, you can use the logs of the messages already sent or received to write templates.
+
+If you would like to use a logged value in TTCN–3 code, then using the `logformat` utility (see the section 13.3 of the TITAN User Guide [13] about this utility) you have to follow these steps:
+
+. Start a text editor and open the (formatted) log file and the TTCN–3 source file.
+. Select and copy the desired value from the log file.
+. Paste the value at the corresponding position in the TTCN–3 code.
+. Finally, make the following changes:
++
+* The enumerated values are followed by their numerical equivalents within parentheses. Delete them including the parentheses.
++
+* If an octetstring value contains only visible ASCII characters, then the hexadecimal octetstring notation is followed by its character string representation between quotation marks and parentheses. Delete the character string (including the parentheses).
++
+* If a `record`, `set`, `record of` or set of value contains no fields or elements, then the logformat utility changes the value from `{}` to `{(empty)}` in the log. Delete the word (empty) (including parentheses).
+
+[[using-the-ttcn-3-preprocessing-functionality]]
+== Using the TTCN-3 Preprocessing Functionality
+
+NOTE: This feature, as preprocessors in general, should be avoided if not absolutely necessary.
+
+Tips for the `Makefile` generated using the option `-p:`
+
+* All the options for the C precompiler can be specified using the variable `CPPFLAGS_TTCN3`. Do not confuse it with the variable `CPPFLAGS`, which is used on the generated C++ code. If standard TTCN-3 output is needed the flag `-P` has to be added manually to the variable `CPPFLAGS_TTCN3`. The resulting `ttcn` files can be compiled with any TTCN-3 compiler (if other special language extensions are not used). Globally used preprocessor symbols can be defined here with the option `-D`. For example to compile the debug version of a project a `DEBUG` symbol can be specified with `-DDEBUG`.
+
+* Files which are included in the `.ttcnpp` source files (with `#include`) and do not need to be translated can be specified in the `TTCN3_INCLUDES` variable. These files will be checked for modification when the `.ttcnpp` files are processed by `make`; any modification will trigger preprocessing of all the `.ttcnpp` files and the recompilation of the affected modules. If the suffix of a file is `.ttcnin` the Makefile Generator will add it to `TTCN3_INCLUDES`; in all other cases the file has to be added manually.
+
+* Do not use any file name identical to the name of the intermediate file produced by the C preprocessor. The intermediate file name is generated by replacing the suffix `.ttcnpp` with `.ttcn`. Use the naming convention of naming the file as the module name avoiding such name collisions.
+
+* The default C preprocessor used to preprocess TTCN-3 files can be replaced by editing the CPP variable.
+
+There are minor issues when precompiling TTCN-3 code with a C preprocessor, these are resulting from the differences between the C and TTCN-3 languages. Tips for writing the `.ttcnpp` files:
+
+* Do not define the B, O and H macros, these letters are used as part of the bitstring, octetstring and hexstring tokens in TTCN-3, but the C preprocessor will replace them.
+
+* There are some predefined macros in the C preprocessor which will be always replaced, do not use any TTCN-3 identifier identical to these. These macros start with double underscore followed by uppercase letters. Some of the most common macros which might be useful:
+
+** – *FILE* This macro expands to the name of the current input file, in the form of a C string constant.
+** – *LINE* This macro expands to the current input line number, in the form of a decimal integer constant.
+** – *DATE* This macro expands to a string constant that describes the date on which the preprocessor is being run.
+** – *TIME* This macro expands to a string constant that describes the time at which the preprocessor is being run.
+
+When writing preprocessor directives keep in mind that within the directive the C preprocessor syntax is in use, not the TTCN-3. Operators such as `defined` or || can be used.
+
+Watch out for macro pitfalls, some well known are: side effects, misnesting, and operator precedence problems.
+
+== More Efficient Implementation of the Types record of and set of
+
+The new implementation of the mentioned TTCN types and their ASN counterparts was introduced in TITAN version 1.7.pl2 (R7C). The performance of assigning record of/set of typed variables improved significantly since TITAN version 1.7.pl1 (R7B). The new implementation uses reference counting when an assignment is made. The whole data structure is copied only when necessary, for example, the user wants to modify its value. Using temporary variables improves the quality of the code.
+
+== Workflow for Native XML Support
+
+In this very short and simple example we are presenting and explaining the procedure of using the XML encoding / decoding. Through the steps of the workflow you can understand the XML related possibilities of TITAN.
+
+First look at data types. These are the base of every test. If you have data representation in XML format (XSD is the standard for defining data types), you have to convert it into the equivalent TTCN-3 data types using the XSD converter. This is a shortened variant of the commonly used SOAP protocol.
+[source]
+----
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.ericsson.com/cai3g1.2/" targetNamespace="http://schemas.ericsson.com/cai3g1.2/" elementFormDefault="qualified" attributeFormDefault="unqualified">
+
+    <xs:element name="Set">
+        <xs:complexType>
+            <xs:sequence>
+                <xs:element name="MOType" type="MoType" />
+                <xs:element name="MOId" type="AnyMOIdType" />
+                <xs:element name="MOAttributes">
+                    <xs:complexType>
+                        <xs:sequence>
+                            <xs:element ref="SetMODefinition" />
+                        </xs:sequence>
+                    </xs:complexType>
+                </xs:element>
+                <xs:element name="extension" type="AnySequenceType"
+                    minOccurs="0" />
+            </xs:sequence>
+        </xs:complexType>
+    </xs:element>
+
+    <xs:complexType name="AbstractSetAttributeType" abstract="true"/>
+
+<xs:element name="SetMODefinition"
+type="AbstractSetAttributeType" abstract="true"/>
+
+    <xs:complexType name="AnyMOIdType">
+        <xs:sequence>
+            <xs:any namespace="##any"
+processContents="lax" maxOccurs="unbounded"/>
+        </xs:sequence>
+    </xs:complexType>
+
+    <xs:complexType name="AnySequenceType">
+        <xs:sequence>
+            <xs:any namespace="##any"
+processContents="lax" maxOccurs="unbounded"/>
+        </xs:sequence>
+    </xs:complexType>
+
+    <xs:simpleType name="MoType">
+        <xs:restriction base="xs:string">
+            <xs:pattern value="[A-Za-z][_A-Za-z0-9]*@.*"/>
+        </xs:restriction>
+    </xs:simpleType>
+
+</xs:schema>
+----
+
+After conversion you have a TTCN-3 module whose name is derived from the targetNamespace attribute of <schema> element. This module contains only data types. Two other files are generated also with standardized base datatypes:
+
+* UsefulTtcn3Types.ttcn
+
+* XSD.ttcn
+
+The content of the generated TTCN-3 file:
+[source]
+----
+module schemas_ericsson_com_cai3g1_2 {
+
+import from XSD all;
+
+type record Set
+{
+    MoType mOType,
+    AnyMOIdType mOId,
+    record {
+        SetMODefinition setMODefinition
+    } mOAttributes,
+    AnySequenceType extension_ optional
+}
+with {
+variant (mOType) "name as capitalized";
+variant (mOId) "name as capitalized";
+variant (mOAttributes) "name as capitalized";
+variant (mOAttributes.setMODefinition) "name as capitalized";
+variant (extension_) "name as 'extension'";
+};
+
+type record AbstractSetAttributeType
+{};
+
+type AbstractSetAttributeType SetMODefinition;
+
+type record AnyMOIdType
+{
+    record length(1 .. infinity) of XSD.String elem_list
+}
+with {
+variant (elem_list) "untagged";
+variant (elem_list[-]) "anyElement";
+};
+
+type record AnySequenceType
+{
+    record length(1 .. infinity) of XSD.String elem_list
+}
+with {
+variant (elem_list) "untagged";
+variant (elem_list[-]) "anyElement";
+};
+
+type XSD.String MoType /* (pattern "[A-Za-z][_A-Za-z0-9]*@.*") */;
+
+}
+with {
+encode "XML";
+variant "namespace as 'http://schemas.ericsson.com/cai3g1.2/'";
+variant "controlNamespace 'http://www.w3.org/2001/XMLSchema-instance' prefix 'xsi'";
+variant "elementFormQualified";
+}
+----
+
+Also manually created type definitions can be used and combined together. This example shows the next module containing also data types.
+[source]
+----
+module SOAP {
+
+import from XSD all;
+import from schemas_ericsson_com_cai3g1_2 all;
+
+type record ApplicationHeaderContent
+{};
+
+type record ApplicationBodyContent {
+    Set setRequest
+};
+
+type record SoapEnvelope {
+    SoapHeader header optional,
+    SoapBody body
+}
+with {
+variant "name as 'Envelope'";
+variant (header) "name as capitalized";
+variant (body) "name as capitalized";
+};
+
+type record of ApplicationHeaderContent SoapHeader;
+
+type union SoapBody {
+    XSD.String fault,
+    record of ApplicationBodyContent content
+}
+with {
+variant (fault) "name as capitalized";
+variant (content) "untagged";
+variant (content[-]) "untagged";
+};
+
+}
+with {
+encode "XML";
+variant "controlNamespace 'http://www.w3.org/2001/XMLSchema-instance' prefix 'xsi'";
+variant "namespace as 'http://schemas.xmlsoap.org/soap/envelope/' prefix 'SOAP-ENV'";
+variant "namespace as 'http://schemas.xmlsoap.org/soap/encoding/' prefix 'SOAP-ENC'";
+variant "namespace as 'http://schemas.ericsson.com/cai3g1.1/' prefix 'ns3'";
+}
+----
+
+The XML encoding/decoding can be accessed via external functions. To encode a value of the SoapEnvelope type (the top-level record type in our example) to XML, or to decode XML data into a value of SoapType, we can use external functions like the following:
+[source]
+----
+module SOAP_ExternalFunctions {
+
+import from SOAP all;
+
+external function enc_SOAP(in SoapEnvelope pdu) return octetstring
+with { extension "prototype (convert) encode(XER:XER_EXTENDED)" }
+
+external function dec_SOAP(in octetstring stream) return SoapEnvelope
+with { extension "prototype (convert) decode(XER:XER_EXTENDED)" }
+
+}
+----
+
+The "prototype (convert)" attribute instructs the compiler to generate a C++ implementation for each of the external functions (see section 4.22.4 above). This permits the use of the encoding/decoding functions directly from TTCN-3 code.
+
+In case more sophisticated processing is required (or some form of pre/postprocessing), the encoder/decoder functions can be reimplemented in C++. The basic functionality provided by the compiler can be used as a starting point.
+
+NOTE: In this case all the ``with'' attributes in the example above must be removed from the external function declaration (otherwise the compiler will generate the functions again with the same signature and duplicate symbol errors will appear at link time).
+
+For representing the usage of encoding and decoding we created this demo module that contains one template definition and in the testcase we will apply encoding and decoding.
+[source]
+----
+module demo {
+
+import from SOAP all;
+import from SOAP_ExternalFunctions all;
+
+template SoapEnvelope SoapTemplate :=
+{
+  header := omit,
+  body := {
+    content := { {
+        setRequest := {
+          mOType       := "JB007",
+          mOId         := {
+            elem_list := {
+             "<catalog><books count='3'/></catalog>",
+             "<catalog><movies count='1'/></catalog>"
+            }
+          },
+          mOAttributes := {
+            setMODefinition := {
+            }
+          },
+          extension_ := omit
+        }
+      } }
+  }
+}
+
+
+type component SOAP_CT
+{
+  var octetstring v_encodedPDU, v_decodePDU;
+  var SoapEnvelope v_decodedPDU;
+}
+
+testcase tc_encdec() runs on SOAP_CT
+{
+  v_encodedPDU := enc_SOAP(valueof(SoapTemplate));
+
+  v_decodedPDU := dec_SOAP(v_encodedPDU);
+
+  log("Encoded set request (SoapEnvelope): ", v_encodedPDU);
+  log("Decoded set request (SoapEnvelope): ", v_decodedPDU);
+}
+
+control
+{
+  execute(tc_encdec());
+}
+
+}
+----
+
+The complete demo project is now ready. If running the test case a log file will be generated in which we can find the encoded representation of the value and the decoded variant.
+
+The resulting XML encoding:
+[source]
+----
+<ns3:Envelope xmlns:ns3='http://schemas.ericsson.com/cai3g1.1/'>
+  <ns3:Body>
+    <ns3:ApplicationBodyContent>
+      <ns3:setRequest>
+        <ns3:MOType>JB007</ns3:MOType>
+        <ns3:MOId>
+          <catalog><books count='3'/></catalog>
+          <catalog><movies count='1'/></catalog>
+        </ns3:MOId>
+        <ns3:MOAttributes>
+          <ns3:SetMODefinition/>
+        </ns3:MOAttributes>
+      </ns3:setRequest>
+    </ns3:ApplicationBodyContent>
+  </ns3:Body>
+</ns3:Envelope>
+The decoded format (a TTCN-3 value of type SoapEnvelope)
+
+{
+  header := omit,
+  body := {
+    content := { {
+        setRequest := {
+          mOType       := "JB007",
+          mOId         := {
+            elem_list := {
+             "<catalog><books count='3'/></catalog>",
+             "<catalog><movies count='1'/></catalog>"
+            }
+          },
+          mOAttributes := {
+            setMODefinition := {
+            }
+          },
+          extension_ := omit
+        }
+      } }
+  }
+}
+----
+
+[[debug-memory-use-of-record-set-of-types]]
+== Debug Memory Use of Record/set of Types
+
+One of the common source of the memory leakage in the TTCN test suite is the ever-growing record/set of’s. In order to help the debug of such issue, the test suite should be compiled with `-DTITAN_MEMORY_DEBUG_SET_RECORD_OF` flag added to `CPPFLAGS` in the Makefile.
+
+That flag activates a WARNING log statement, issued after every 1000th element added to the record/set of.
+
+Example:
+[source]
+----
+module test {
+
+type component test_CT {}
+type record of charstring roc
+
+testcase tc_test() runs on test_CT
+{
+    var roc r:={}
+    var integer k
+
+    for(k:=0;k<10001;k:=k+1){
+      r[sizeof(r)]:="a";
+    }
+}
+
+control
+{
+  execute(tc_test())
+}
+
+}
+----
+
+Running of the example test above will produce the following log:
+[source]
+----
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 1000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 2000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 3000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 4000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 5000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 6000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 7000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 8000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 9000
+MTC@esekilxxen1844: Warning: New size of type @test.roc: 10000
+----
diff --git a/usrguide/referenceguide/13-references.adoc b/usrguide/referenceguide/13-references.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..2d8e2d22f6f8e2709b6d8313854cd69d4a7dbdd7
--- /dev/null
+++ b/usrguide/referenceguide/13-references.adoc
@@ -0,0 +1,76 @@
+= References
+
+[[_1]]
+* [1] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards Institute ES 201 873-1 Version 4.1.1, July 2009]
+
+[[_2]]
+* [2] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187304/04.01.01_60/es_20187304v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN–3 Operational Semantics European Telecommunications Standards Institute. ES 201 873-4 Version 4.1.1, June 2009]
+
+[[_3]]
+* [3] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/04.01.01_60/es_20187307v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN–3 European Telecommunications Standards Institute. ES 201 873-7 Version 4.1.1, July 2009]
+
+[[_4]]
+* [4] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187309/04.01.01_60/es_20187309v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 9: Using XML Schema with TTCN–3 European Telecommunications Standards Institute. ES 201 873-9 Version 4.1.1, June 2009]
+
+[[_5]]
+* [5] link:https://www.etsi.org/deliver/etsi_es/202700_202799/202785/01.05.01_60/es_202785v010501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. TTCN-3 Language Extensions: Behaviour Types European Telecommunications Standards Institute. ES 202 785 Version 1.5.1, Aug 2017]
+
+[[_6]]
+* [6] link:https://www.itu.int/rec/T-REC-X.680-200207-S[ITU-T, X.680, Information TechnologyAbstract Syntax Notation One (ASN.1): Specification of basic notation International Telecommunication Union, July 2002]
+
+[[_7]]
+* [7] link:https://www.itu.int/rec/T-REC-X.681-200207-S[ITU-T, X.681, Information TechnologyAbstract Syntax Notation One (ASN.1): Information object specification International Telecommunication Union, July 2002]
+
+[[_8]]
+* [8] link:https://www.itu.int/rec/T-REC-X.682-200207-S[ITU-T, X.682, Information Technology Abstract Syntax Notation One (ASN.1): Constraint specification International Telecommunication Union, July 2002]
+
+[[_9]]
+* [9] link:https://www.itu.int/rec/T-REC-X.683-200207-S[ITU-T, X.683, Information TechnologyAbstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specification International Telecommunication Union, July 2002]
+
+[[_10]]
+* [10] link:https://www.itu.int/rec/T-REC-X.690-200207-S[ITU-T, X.690, Information TechnologyASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)International Telecommunication Union, July 2002]
+
+[[_11]]
+* [11] ISO/IEC 10646-1, Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane, Second edition, 200009-15
+
+[[_12]]
+* [12] link:https://tools.ietf.org/html/rfc3629[RFC3629: UTF-8, a transformation format of ISO 10646]
+
+[[_13]]
+* [13] link:https://github.com/eclipse/titan.core/blob/master/usrguide/userguide/README.adoc[User Guide for TITAN TTCN-3 Test Executor]
+
+[[_14]]
+* [14] link:https://github.com/eclipse/titan.core/blob/master/usrguide/installationguide.adoc[Installation guide for TITAN TTCN-3 Test Executor]
+
+[[_15]]
+* [15] link:https://github.com/eclipse/titan.core/blob/master/usrguide/releasenotes.adoc[Release Notes for TITAN TTCN-3 Test Executor]
+
+[[_16]]
+* [16] link:https://github.com/eclipse/titan.core/blob/master/usrguide/apiguide/README.doc[API Technical Reference for TITAN TTCN-3 Test Executor]
+
+[[_17]]
+* [17] link:https://github.com/eclipse/titan.EclipsePlug-ins/blob/master/Eclipse_Designer_userguide/README.doc[User Guide for the TITAN Designer for the Eclipse]
+
+[[_18]]
+* [18] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.03.01_60/es_20187301v040301p.pdf[ETSI ES 201 373-1 V4.3.1 (2011-06)]
+
+[[_19]]
+* [19] link:http://gask2web.ericsson.se/service/get?DocNo=1092-212&Lang=EN&Rev=N&Format=PDFV1R2[1092-212 Uen (EN/LZB 101 01/1D) Product Changes]
+
+[[_20]]
+* [20] link:https://www.itu.int/rec/T-REC-X.696-201508-I[ITU-T, X.696, Information TechnologyASN.1 encoding rules: Specification of Octet Encoding Rules (OERInternational Telecommunication Union, August 2015]
+
+[[_21]]
+* [21] link:https://www.etsi.org/deliver/etsi_es/202700_202799/202781/01.04.01_60/es_202781v010401p.pdf[ETSI ES 202 781 V1.4.1. (2015-06 Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; TTCN-3 Language Extensions: Configuration and Deployment Support)]
+
+[[_22]]
+* [22] link:https://tools.ietf.org/html/rfc7049[RFC7049: Concise Binary Object Representation (CBOR) (October 2013)]
+
+[[_23]]
+* [23] link:http://bsonspec.org/spec.html[BSON specification version 1.1]
+
+[[_24]]
+* [24] link:https://docs.mongodb.com/manual/reference/mongodb-extended-json/#bson-data-types-and-associated-representations[MongoDB Extended JSON document]
+
+[[_25]]
+* [25] link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187311/04.07.01_60/es_20187311v040701p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 11: Using JSON with TTCN–3 European Telecommunications Standards Institute. ES 201 873-11 Version 4.7.1, June 2017]
diff --git a/usrguide/referenceguide/14-abbreviations.adoc b/usrguide/referenceguide/14-abbreviations.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..dfa4c5d9da32a7785fa46f9ffa911ab9980cc611
--- /dev/null
+++ b/usrguide/referenceguide/14-abbreviations.adoc
@@ -0,0 +1,105 @@
+= Abbreviations
+
+API:: Application Programming Interface
+
+ASCII:: American Standard Code for Information Interchange
+
+ASN.1:: Abstract Syntax Notation One
+
+ATS:: Abstract Test Suite
+
+BER:: Basic Encoding Rules (of ASN.1)
+
+BNF:: Backus–Naur Formalism
+
+CER:: Canonical Encoding Rules (of ASN.1)
+
+CPP:: Cello Packet Platform
+
+CR:: Change Request
+
+DER:: Distinguished Encoding Rules (of ASN.1)
+
+DNS:: Domain Name Server
+
+DTD:: Document Type Description
+
+ETS:: Executable Test Suite
+
+ETSI:: European Telecommunications Standards Institute
+
+FIFO:: First In, First Out
+
+GCC:: GNU Compiler Collection
+
+GUI:: Graphical User Interface
+
+HC:: Host Controller
+
+HTML:: Hypertext Markup Language
+
+HTTP:: HyperText Transfer Protocol
+
+IDL:: Interface Description Language
+
+IE:: Information Element
+
+IP:: Internet Protocol
+
+ISO:: International Organization for Standardization
+
+JSON:: JavaScript Object Notation
+
+LCOV:: A graphical front-end for GCC’s coverage testing tool
+
+LSB:: Least Significant Bit
+
+MC:: Main Controller
+
+MSB:: Most Significant Bit
+
+MTC:: Main (or Master) Test Component
+
+OSE:: Open System Environment
+
+PDU:: Protocol Data Unit
+
+pl:: Patch Level
+
+PTC:: Parallel Test Component
+
+PT:: Port Type
+
+SOAP:: Simple Object Access Protocol
+
+SUT:: System Under Test
+
+TC:: Test Component (either MTC or PTC)
+
+TCC:: Test Competence Center
+
+TCP:: Transmission Control Protocol
+
+TLV:: Tag, length, value
+
+TPD:: Titan Project Descriptor
+
+TR:: Trouble Report
+
+TTCN:: Testing and Test Control Notation
+
+TTCN–2:: Tree and Tabular Combined Notation version 2
+
+TTCN–3:: Tree and Tabular Combined Notation version 3 (formerly)Testing and Test Control Notation (new resolution)
+
+UDP:: User Datagram Protocol
+
+URL:: Universal Resource Locator
+
+URI:: Uniform Resource Identifier
+
+W3C:: World Wide Web Consortium
+
+XML:: W3C Extensible Markup Language
+
+XSD:: W3C XML Schema Definition
diff --git a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..2e2e4e29446863f63009ffc0954ab4218d4a8e36
--- /dev/null
+++ b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
@@ -0,0 +1,80 @@
+= TTCN-3 Limitations in this Version
+:toc:
+
+The present Test Executor is an implementation of TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>) with support of ASN.1 (<<13-references.adoc#_3, [3]>>). However, the following TTCN–3 language constructs are not supported in the current version of the Test Executor. When applicable, the relevant clause of the standard text (<<13-references.adoc#_1, [1]>>) is given within parentheses after each limitation. The list of ASN.1 related limitations can be found in chapter *4.25*.
+
+* C++ code generation for parameterized local templates is not supported.footnote:[The semantic analyzer is able to verify modules with such definitions, but the generated C++ code will be incomplete or erroneous.] (5.0, relevant cells of Table 1)
+* Parameterized TTCN–3 `record`, `set` and `union types`. (5.4 in <<13-references.adoc#_1, [1]>>))
+* TTCN–3 sub-typing constraints are checked only at compilation time. In the run-time environment the restricted types are substituted with the corresponding base type and no run-time error is produced if the assigned value violates the subtype constraint.
+* The special TTCN–3 type `anytype` is supported with restrictions. (6.2.6 in <<13-references.adoc#_1, [1]>>)
+* Type compatibility of structured types.footnote:[Type compatibility for structured types is enabled only in the function test run-time due to performance considerations (except record of/set of types for certain element types, see section 4.32.2). In the load test run-time aliased types and sub-types are treated to be equivalent to their unrestricted root types. Different structured types are incompatible to each other. Two array types are compatible if both have the same size and index offset and the element types are compatible according to the rules above.] (6.3 in <<13-references.adoc#_1, [1]>>)
+* Two (non-empty) component types are considered to be compatible only if the compatibility relation is explicitly specified by the test suite writer. Details can be found in section 4.21. (6.3.3 and 9.3 in <<13-references.adoc#_1, [1]>>)
+* Selective import statements. All TTCN–3 imports are treated as `import all`.footnote:[Recursive and non-recursive import means exactly the same when importing all definitions from a module.] (8.2.3 and F.2 in <<13-references.adoc#_1, [1]>>)
+* Type `address` must not be an external type specified outside TTCN–3. The special value `null` cannot be assigned to variables of type `address`. (9.6 in <<13-references.adoc#_1, [1]>>)
+* The compiler does not check whether a TTCN–3 function invoked from within a `template`, Boolean guard expression of an alt construct, local variable initializer of an `altstep` or an `interleave` statement has side-effects. The run-time behavior is undefined if a function with side-effects (e.g. communication operations) is called while one of the above statements is being executed. (20 in <<13-references.adoc#_1, [1]>>)
+* The `disconnect` and `unmap` operations cannot refer to multiple connections or mappings. (21.1.2, relevant parts in <<13-references.adoc#_1, [1]>>)
+* The `send` and `call` operations cannot be used for multicast or broadcast communication. (22.2.1 and 22.3.1 in <<13-references.adoc#_1, [1]>>)
+* Attributes of type definitions cannot be changed when they are being imported. (27.1.2.1 in <<13-references.adoc#_1, [1]>>)
+* Template instances cannot be used in the to clause of communication operations. Only values of `component` and `address` types are allowed. (stated only in BNF)
+* The additional predefined function `decomp` is not implemented. (D.2 of <<13-references.adoc#_3, [3]>>)
+* In `port type` definitions the list of incoming and outgoing message types or signatures must be explicitly specified, the `all` keyword is ignored by the compiler. (G.3 in <<13-references.adoc#_1, [1]>>)
+* The TTCN–3 and ASN.1 modules are identified only by their names. Object identifiers in module headers are ignored. Module object identifiers in `import` statements and references are skipped without any checking, the semantic analyzer uses the module identifier only. (7.2.3 of <<13-references.adoc#_3, [3]>>, 8.1 in <<13-references.adoc#_1, [1]>>)
+* The comparison operators do not work on `objid` values. Only the equality (==) and non-equality (!=) operators are allowed. (7.2.5.2 of <<13-references.adoc#_3, [3]>>, 7.1.3 in <<13-references.adoc#_1, [1]>>)
+* Templates can not be used in the parameter of `encvalue` built-in function. (C.38 in <<13-references.adoc#_1, [1]>>)
+* The declaration of object identifiers can only point to constant values and integer variables, references to `objid` variables are not supported.
+* The Configuration and Deployment Support and the Advanced Parameterization packages of the TTCN-3 standard are not supported yet, except the Port with translation capability clause. ([21]).
+* In contrast to the standard, TITAN does not allow applying the same name to a structured type and to an element of the same type.
+* From version 1.8.pl3 (or R8D) the logging machinery uses an internal TTCN-3 module, named `TitanLoggerApi`, hence using this module name in user code is not allowed.
+* Referencing into an omitted field of any non-const variable/template of record/set type is allowed and it will expand the structure to the level of reference. All the expanded fields under `omit` will be unbound. This behavior is TITAN specific. According to the TTCN-3 standard (15.6.2 of <<13-references.adoc#_1, [1]>>), the proper behavior would be a dynamic test case error in this situation.In case of variable templates referencing into a matching mechanism will change the template regardless of it being a left hand side or a right hand side value.In case of non-variable templates referencing into a matching mechanism will cause an error. According to the TTCN-3 standard the proper behavior for right hand side templates would be to return an expanded value but not change it’s own value in case of AnyValue matching mechanism or stop with an error in case of other matching mechanisms.
+* According to the standard, before matching the tools have to make sure that the template being used is completely initialized, with no fields or elements left unbound. For performance reasons this check is not done before the matching is done. Instead the matching will report the error, when it tries to use an unbound field or elements.
+* In case the compiler is not able to decide at compile time, if all possible execution branches contain a return statement, that is, in cases of alt statements, loops and branching statement like if-else, select case, and so on, it will report an error without generating code. For example:
++
+....
+function f_check() return boolean {
+  for (var integer i:=0; i < some_variable; i := i + 1) {
+    return true;
+    }
+  }
+....
++
+In this case the compiler will report an error as it can not evaluate, if the loop will be executed at least once, and if the loop is not executed, the end of the function would be reached without a return statement. The workaround for this kind of problem is easy, the user needs to insert an extra return statement at the end of the function, like:
++
+....
+function f_check() return boolean {
+  for (var integer i:=0; i < some_variable; i := i + 1) {
+    return true;
+    } return false
+  }
+....
+* The language specification, after the "language" keyword, is ignored by the compiler.
+* For record of/set of types of fixed size, which have a length restriction of one concrete value, and arrays the `sizeof()` and `lengthof()` predefined functions are not standard compliant: `sizeof()` returns the number of elements, `lengthof()` returns the index of the last initialized element plus one.
+* IPv6 networking between the MC, HC and Parallel Test Components is supported only on Linux and Cygwin 1.7.
+* The `optional "implicit omit"` attribute is not applied recursively.
+* Templates using the `decmatch` (decoded content match, B.1.2.9 in <<13-references.adoc#_1, [1]>>) matching mechanism cannot be sent through test ports (doing so will result in a dynamic test case error). Template module parameters using `decmatch` are also not supported.
+* Since TITAN version R5B the matching symbol "*" (AnyValueOrNone, B.1.2.4 in <<13-references.adoc#_1, [1]>>) causes a compile time error when assigned to a mandatory field of a record or set template, as it is stated in the standard. This breaks backwards compatibility because in the older versions of TITAN only a warning was emitted.
+* When assigning a value to a structure using the value list notation, assignment notation or index notation (but not when assigning values to fields or elements one at a time), if the structure’s old value (or part of it) is referenced on the right hand side, the structure’s new value will only contain the fields or elements set in that assignment. All other fields or elements that may have been initialized in prior assignments will be set to unbound.
++
+If the structure’s old value is not referenced on the right hand side of the assignment, then only the fields or elements mentioned in the assignment will be overwritten. All other fields or elements will retain their previous values. Example:
++
+[source]
+----
+type record R {
+  integer i1,
+  integer i2,
+  integer i3
+}
+
+…
+
+var R x := { 1, 2, 3 };
+
+x := { i2 := 3 }; // assignment notation with no self-reference (OK)
+// result: x := { i1 := 1, i2 := 3, i3 := 3 }
+
+x := { i1 := x.i2 }; // assignment notation with self-reference (not OK)
+// result: x := { i1 := 3, i2 := <unbound>, i3 := <unbound> }
+
+x.i3 := x.i1; // individual field assignment with self-reference (OK)
+// result: x := { i1 := 3, i2 := <unbound>, i3 := 3 }
+----
+
diff --git a/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc b/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..52b0393159991ca59d1d9fd381f2a05e630848d5
--- /dev/null
+++ b/usrguide/referenceguide/3-clarifications_to_the_ttcn-3_standard.adoc
@@ -0,0 +1,210 @@
+= Clarifications to the TTCN-3 Standard
+:toc:
+
+The TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>) and its Operational Semantics (<<13-references.adoc#_1, [1]>>) give ambiguous description for some language constructs. This section specifies our resolution for these ambiguities that was followed during the implementation of our compiler and run-time environment.
+
+== Predefined Function Identifiers
+
+The standard does not clarify the status of predefined function identifiers, that is, the names of functions defined in Annex C of <<13-references.adoc#_1, [1]>>. In our interpretation these words cannot be used to identify userdefined TTCN3 entities because such a definition would hide the predefined function completely. Thus our compiler treats these identifiers in the same way as the normal keywords of the language. Therefore the inappropriate use of predefined functions, for example wrong number of arguments, will result in syntax errors rather than semantic errors.
+
+== Meaning of any and all
+
+The meaning of the keywords is only loosely defined in the standard. The resulting equivocality concerns timer, port and component operations.
+
+=== Timer and Port Operations
+
+The meaning of keywords `any` and `all` in timer and port operations is unclear. These constructs might be resolved statically at compilation time by applying the operation on all visible timers and ports of the given scope unit. Our run-time environment, however, implements a dynamic resolution, that is, it walks through the list of active timers and ports and applies the respective operation. As a consequence of this, such operations are also applicable in scope units without visible timers and ports, for example in functions without `runs on` clause. Because of the run-time evaluation there is one limitation, which is verified by our semantic analyzer: the receiving port operations, that is, `receive`, `trigger`, `getcall`, `getreply`, `catch` and `check`) that refer to any port cannot have template parameter and `value` or `param` redirect. To avoid incompatibilities with future versions it is not recommended to use `any` or `all` in timer and port operations.
+
+=== Component Operations
+
+The standard does not specify explicitly the behavior of the component operations that refer to `all component` when only the MTC exists, that is, no PTC had been created during the testcase. In our implementation both `all component.running` and `all component.alive` return `true` and the operations `all component.done` and `all component.killed` succeed immediately in this situation. Operations `all component.stop` and `all component.kill` do nothing; instead, a warning is issued. The same rules are applied in single mode, when it is impossible to create PTCs, as well.
+
+== Response and Exception Handling Parts
+
+The behavior of the response and exception handling part of a `call` operation is not clearly specified in the standard. The allowed `getreply` and `catch` operations can handle only the possible responses and exceptions of the previous signature call. In our implementation if any other event arrives into the port queue during the execution of the response and exception handling part it may block the execution forever. The runtime environment generates a dynamic test case error in such a situation. If the test suite writer expects any other event on the same port during the outstanding call, for example a simultaneous incoming call initiated by the other side, a non-blocking call operation with the keyword `nowait` should be used. The response and the possible incoming calls should be handled in a forthcoming regular alt construct using the appropriate `getreply` and `getcall` operations.
+
+== Variable Lists in param Redirect
+
+In the standard, it is not clear that the `VariableList` notation in the `param` redirect of `getcall` and `getreply` operations should refer to *all* parameters of the respective signature or to the *relevant* parametersfootnote:[Relevant parameters are the in and inout parameters in case of getcall operation as well as out and inout ones in case of getreply.] only. Our compiler expects variable entries only for the relevant parameters and ignores the irrelevant ones. This is because otherwise the test writer should use `NotUsedSymbols` for all irrelevant parameters, which would be a redundant notation. For example, if a signature has one `in`, one `out` and one `inout` parameter the compiler expects two variable entries in both `getcall` and `getreply` operations.
+
+== References between Language Elements
+
+The TTCN–3 standard does not specify clearly the permitted references between different kinds of language elements. The following table shows our interpretation.
+
+.References between TTCN-3 elements
+[cols=",,,,,",options="header",]
+|===
+|Referred element Referring element |Literal value |Constant |External constant |Module parameter |Template
+|Constant |Y |Y* |N |N |N
+|Array size |Y |Y |N |N |N
+|Subtype constraint |Y |Y |N |N |N
+|Default value of module parameter |Y |Y |Y |N |N
+|Actual value of module parameter (in configuration file) |Y |N |N |N |N
+|Default duration of timer |Y |Y |Y |Y |N
+|Template (non-parameterized) |Y |Y |Y |Y |Y*
+|===
+
+Legend:
+
+* N Not allowed by the TTCN–3 language.
+
+* Y Allowed and fully supported by the current version of this TTCN–3 tool.
+
+* Y* Allowed and fully supported, but circular reference chains must be avoided.
+
+[NOTE]
+====
+* The above table implies that the value of all constants and the attributes of all type constructs (type constraints, array sizes, etc.) shall be known at compilation time.
+* ASN.1 value assignments are treated as TTCN–3 constants.
+* The value of constants shall refer only to built-in operators or additional predefined functions.
+* The body of non-parameterized templates and the default duration of timers shall be known at test startup (load) time when all module parameters are known.
+* The actual parameters of templates or the actual duration of timers shall be determined run-time because the actual value of variables may be referred.
+* The rules for a language element do not depend on its scope unit. For example the same rules apply on module, component and local (function, testcase, altstep) constants.
+====
+
+== Encoding Rules
+
+The standard does not specify clearly some of the encoding rules.
+
+* The encoding of fields in `record`, `set` and `union` types is supported.
+* The order of attributes of the same type in a `with` statement is important. The second variant might override the first, or an overriding attribute will override all the following attributes of the same type.
+* Encode attributes are an exception to this as they are not really attributes, but "contexts". It cannot be determined to which encode "contexts" the variants of the same `with` statement should belong if there are several. As having several encode "contexts" in the same `with` statement would be a bad coding practice, a warning is generated and the last encode is used as the statement’s encode "contexts".
+* As encodes are contexts, an encode is only overridden if the overriding context is not the same.
+* The order of attributes of different type in a `with` statement is not important, they do not affect each other.
+* In case of structured types, the encode context of the type is the encode context of its fields too, if the fields do not override this attribute. The other attribute types are handled separately for the structured type and its fields. Attributes inherited from higher level (module/group/structured type) might change the encoding of a record and that of its fields.
+* Attributes with qualifiers referring to the same field are handled as if they were separate `with` statements. The same rules apply to them. For example, the last encode from the ones referring to the same field is taken as the encoding context of the field.
+* Attributes belonging to a field of a structured type or a type alias have the following overwriting rules. A new `variant` attribute together with the directive `override` clears all current attributes defined for the type of the field. A new `variant` attribute without the directive override overwrites only the current `variant` attribute, all other attributes remain unchanged.
+
+== Address Type
+
+The standard does not specify clearly the status of special TTCN–3 type `address`. Our implementation is based on the rules below.
+
+The test suite writer can assign the name `address` to a regular data type. There can be at most one type named `address` in each TTCN–3 module. It is allowed that different modules of the test suite assign the name `address` to different types.
+
+The name `address` cannot be assigned to the following TTCN–3 types:
+
+* port types
+* component typesfootnote:[If component types were allowed for addressing the compiler would not be able to decide whether a component reference in the to or from clause of a communication operation denotes a test component, which is reachable through a port connection or an address inside the SUT, which is reachable through a port mapping.]
+* signatures
+* the built-in type defaultfootnote:[The values of type default (i.e. the TTCN–3 default references) cannot be passed outside the test component by any means.]
+
+Whenever the word `address` is used as a type, it is assumed to be a reference to the type named `address` in the current module. The type named `address` cannot be imported into another TTCN–3 module, that is, it can be referenced using the name `address` only within its own module. If one wants to use this type in other modules a regular alternate name must be assigned to it with type aliasing.
+
+Addressing the SUT in communication operations is allowed only if the `address` type is defined in the same module as the corresponding port type. In addition, the port type must have a special `extension` attribute to support `address` values (See section "Support of address type" in <<13-references.adoc#_16, [16]>> for more details).
+
+Note that it is possible to use different address types on different ports in the same TTCN–3 module if the respective port types are imported from different modules, but neither address type may be referenced with name `address` by the importing module.
+
+[[importing-import-statement-from-ttcn-3-modules]]
+== Importing import Statement from TTCN-3 Modules
+
+See <<13-references.adoc#_18, [18]>> standard for detailed description. Additional information for better understanding:
+
+* Import (see following chapters of the <<13-references.adoc#_18, [18]>> standard 8.2.3.1-8.2.3.6, and 8.2.5, only applies for global definitions (see <<13-references.adoc#_18, [18]>> table 8. in 8.2.3.1), therefore import functionality is not interfered by import of import statement.
+* Import statement can be imported by only import of import statement (chapter 8.2.5 and 8.2.3.7).
+* Import statements are by default private, importing of import statement with public or friend visibility is recursively resolved, and thus importing of importing of import statement is possible.
+* Importing of import statement - in case of friend visibility -recursive resolving is broken, if the import chain has a member that is not friend of the exporting module.
+* Importing of import statement circular import chain causes error.
+* Example for friend type and importing of import statement
++
+----
+B.ttcn // friend template
+friend module C, E;
+
+friend template integer t_B_i_fr := 0;
+
+C.ttcn // public import and importing of import statement, friend of B
+public import from B all;
+public import from B {import all};
+
+D.ttcn // public import and importing of import statement, NOT friend of B
+public import from C all;
+public import from C { import all };
+
+E.ttcn // public import and importing of import statement, friend of B
+public import from D { import all };
+public import from D all;
+
+testcase tc_B() runs on MTC {
+var integer i:=valueof(t_B_i_fr); //Visible!
+setverdict(pass);
+}
+----
+
+== Description of Behavior Types Syntax
+
+TITAN supports the behaviour type package of the TTCN-3 standard,but with a different syntax. For details of the behaviour types see <<13-references.adoc#_5, [5]>>.
+
+.Behaviour types - refers shows the different syntax of the function behaviour type.
+[cols=",",options="header",]
+|===
+|*Standard (6.2.13.2 in <<13-references.adoc#_5, [5])* |*Titan specific syntax*
+|type function MyFunc3 ( in integer p1 ) return charstring; |var MyFunc3 myVar1 := refers(int2char);
+|===
+
+NOTE: The functionality is same as in the standard, only the syntax is different.
+
+The syntax of the apply operation is different,  Table 3 Behaviour types - apply and derefers
+
+Standard:
+
+.Behaviour types - apply and derefers
+[cols=",",options="header",]
+|===
+|*Standard (6.2.13.2 in <<13-references.adoc#_5, [5])* |*Titan specific syntax*
+|type function MyFuncType (); |v_func.apply(MyVar2)
+|type function t_functionstartTests(); |vl_comp.start(derefers(vl_function2)());
+|===
+
+== Partially initialized structure values
+
+According to the standard TTCN-3 variables and module parameters (of structured types) can be in 3 different states during their initialization:
+
+* _uninitialized_ (or unbound) - none of the value's fields or elements has been initialized - values in this state cannot be copied or used on the right hand side of an operation;
+* _partially initialized_ - some of the value's fields or elements have been initialized, but not all of them (or at least not enough to meet the minimum type restrictions) - these values can be copied, but cannot be used on the right hand side of an operation;
+* _fully initialized_ (or bound) - all of the value's fields or elements have been initialized - these values are ready to be used on the right hand side of an operation.
+
+The `isbound` operation should only return `true` if the value is in the 3rd (fully initialized) state.
+
+This isn't the case in the TITAN runtime. Values only have 2 states: _bound_ and _unbound_, which is what the `isbound` operation returns. This can be any combination of the previously mentioned 3 states, depending on the type:
+
+* `record` / `set`: unbound = uninitialized, bound = at least partially initialized, meaning that a `record` / `set` is bound if at least one of its fields is boundfootnote:[The bound state of fields or elements is also determined by using the isbound operation on the field or element.];
+* `record of` / `set of`: unbound = uninitialized, bound = at least partially initialized, meaning that the record of is only unbound if it has never received an initial value (even initializing with {} creates a bound `record of` / `set of` value);
+* `array`: unbound = uninitialized or partially initialized, bound = fully initialized, meaning that the array is only bound if all of its elements are bound;
+* `unions` can't be partially initialized, so TITAN stores their bound state correctly (although it’s still possible to create `union` values, where the selected alternative is unbound, with the legacy command line option `–B`; these values would be considered bound by TITAN).
+
+There is a workaround in TITAN’s implementation of `records` / `sets` to allow the copying of partially initialized values (`union` values with unbound selected alternatives can also be copied when the compiler option `–B` is set). In all other cases the user is responsible for making sure the value is usable on the right hand side of an operation. The `isbound` function is usually not enough to ensure, that the value is usable.
+
+== Concatenation of templates
+
+TITAN supports the concatenation of templates and template variables of string types (`bitstring`, `hexstring`, `octetstring`, `charstring`, `universal charstring`) and list types (`record of`, `set of`) with the following limitations:
+
+* templates can only be concatenated in the Function Test runtime;
+* valid concatenation operands (for binary string and list types):
+** specific values (i.e. literal values),
+** any value ("?"") with no length restriction or with a fixedfootnote:[In this case a range length restriction, whose upper and lower bounds are equal, is also considered as a `fixed' length restrictione.g.: ? length(2..2) is a valid operand, but ? length(2..3) is not] length restriction,
+** any value or none ("*") with a fixed length restriction,
+** references to constants, templates, variables, or template variables;
+* operands of `charstring` and `universal charstring` template concatenation cannot contain matching mechanisms (not even patterns), only specific values and references;
+* reference operands of binary string (`bitstring`, `hexstring`, `octetstring`) template concatenation can also refer to binary string templates with wildcards in addition to the template types listed as valid operands (these cannot be used in template concatenations directly, because of parser limitations);
+* similarly, reference operands of `record of` or `set of` template concatenation can also refer to template lists containing matching mechanisms (but these cannot appear in template concatenations directly due to parser limitations);
+* the first operand of a `record of` or `set of` template concatenation can only be a reference (because of parser limitations);
+* template module parameters cannot be concatenated in the configuration file.
+
+== The predefined function replace
+
+In TITAN the predefined function `replace` cannot be used on arrays.
+
+If the fourth parameter of `replace` is an empty string or sequence, then it acts as a delete function (the specified substring or subsequence is simply removed from the input value and nothing is inserted in its stead).
+
+Example:
+
+[source]
+----
+type record of integer IntList;
+...
+var IntList vl_myList := { 1, 2, 3 };
+var IntList vl_emptyList := {};
+replace(vl_myList, 1, 2, vl_emptyList); // returns { 1 }
+replace("abcdef", 2, 1, ""); // returns "abdef"
+replace(‘12FFF’H, 3, 2, ‘’H); // returns ‘12F’H
+----
diff --git a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..80039216a6c03324e0c340fc2b09ae94d1162c84
--- /dev/null
+++ b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
@@ -0,0 +1,8622 @@
+[[ttcn-3-language-extensions]]
+= TTCN–3 Language Extensions
+:toc:
+:table-number: 3
+
+The Test Executor supports the following non-standard additions to TTCN–3 Core Language in order to improve its usability or provide backward compatibility with older versions.
+
+== Syntax Extensions
+
+The compiler does not report an error or warning if the semi-colon is missing at the end of a TTCN–3 definition although the definition does not end with a closing bracket.
+
+The statement block is optional after the guard operations of `altsteps`, `alt` and `interleave` constructs and in the response and exception handling part of `call` statements. A missing statement block has the same meaning as an empty statement block. If the statement block is omitted, a terminating semi-colon must be present after the guard statement.
+
+The standard escape sequences of C/C++ programming languages are recognized and accepted in TTCN–3 character string values, that is, in literal values of `charstring` and `universal` `charstring` types, as well as in the arguments of built-in operations `log()` and `action()`.
+
+NOTE: As a consequence of the extended escape sequences and in contrast with the TTCN–3 standard, the backslash character itself has to be always duplicated within character string values.
+
+The following table summarizes all supported escape sequences of TTCN–3 character string values:
+
+.Character string escape sequences
+[cols=",,",options="header",]
+|===
+|*Escape sequence* |*Character code (decimal)* |*Meaning*
+| |7 |bell
+| |8 |backspace
+| |12 |new page
+| |10 |line feed
+| |13 |carriage return
+| |9 |horizontal tabulator
+| 11 |vertical tabulator |
+|\ |92 |backslash
+|&quot; |34 |quotation mark
+|’ |39 |apostrophe
+|? |63 |question mark
+| <newline> |nothing |line continuation
+| |NNN |octal notation (NNN is the character code in at most 3 octal digits)
+| |NN |hexadecimal notation (NN is the character code in at most 2 hexadecimal digits)
+|"" |34 |quotation mark (standard notation of TTCN–3 )
+|===
+
+NOTE: Only the standardized escape sequences are recognized in matching patterns of character string templates because they have special meaning there. For example, inside string patterns `\n` denotes a set of characters rather than a single character.
+
+Although the standard requires that characters of TTCN–3 `charstring` values must be between 0 and 127, TITAN allows characters between 0 and 255. The printable representation of characters with code 128 to 255 is undefined.
+
+The compiler implements an ASN.1-like scoping for TTCN–3 enumerated types, which means it allows the re-use of the enumerated values as identifiers of other definitions. The enumerated values are recognized only in contexts where enumerated values are expected; otherwise the identifiers are treated as simple references. However, using identifiers this way may cause misleading error messages and complicated debugging.
+
+The compiler allows the local definitions (constants, variables, timers) to be placed in the middle of statement blocks, that is, after other behavior statements. The scope of such definitions extends from the statement following the definition to the end of the statement block. Forward-referencing of local definitions and jumping forward across them using `goto` statements are not allowed.
+
+The compiler accepts in-line compound values in the operands of TTCN–3 expressions although the BNF of the standard allows only single values. The only meaningful use of the compound operands is with the comparison operators, that is, == and !=. Two in-line compound values cannot be compared with each other because their types are unknown; at least one operand of the comparison must be a referenced value. This feature has a limitation: In the places where in-line compound templates are otherwise accepted by the syntax (e.g. in the right-hand side of a variable assignment or in the actual parameter of a function call) the referenced value shall be used as the left operand of the comparison. Otherwise the parser gets confused when seeing the comparison operator after the compound value.
+
+Examples:
+[source]
+----
+// invalid since neither of the operands is of known type
+if ({ 1, 2 } == { 2, 1 }) { }
+
+// both are valid
+while (v_myRecord == { 1, omit }) { }
+if ({ f1 :=1, f2 := omit } != v_mySet) {}
+
+// rejected because cannot be parsed
+v_myBooleanFlag := { 1, 2, 3 } == v_myRecordOf;
+f_myFunctionTakingBoolean({ 1, 2, 3 } != v_mySetOf);
+
+// in reverse order these are allowed
+v_myBooleanFlag := v_myRecordOf == { 1, 2, 3 };
+f_myFunctionTakingBoolean(v_mySetOf != { 1, 2, 3 });
+----
+
+[[visibility-modifiers]]
+== Visibility Modifiers
+
+TITAN defines 3 visibility modifiers for module level definitions, and component member definitions: public, private, friend (8.2.5 in <<13-references.adoc#_1, [1]>>).
+
+On module level definitions they mean the following:
+
+* The public modifier means that the definition is visible in every module importing its module.
+* The private modifier means that the definition is only visible within the same module.
+* The friend modifier means that the definition is only visible within modules that the actual module declared as a friend module.
+
+If no visibility modifier is provided, the default is the public modifier.
+
+In component member definitions they mean the followings:
+
+* The public modifier means that any function/testcase/altstep running on that component can access the member definition directly.
+* The private modifier means that only those functions/testcases/altsteps can access the definition which runs on the component type directly. If they run on a component type extending the one containing the definition, it will not be directly visible.
+
+The friend modifier is not available within component types.
+
+Example:
+[source]
+----
+module module1
+{
+import from module2 all;
+import from module3 all;
+import from module4 all;
+
+const module2Type akarmi1 := 1; //OK, type is implicitly public
+const module2TypePublic akarmi2 := 2; //OK, type is explicitly public
+const module2TypeFriend akarmi3 := 3; //OK, module1 is friend of module2
+const module2TypePrivate akarmi4 := 4; //NOK, module2TypePrivate is private to module2
+
+const module3Type akarmi5 := 5; //OK, type is implicitly public
+const module3TypePublic akarmi6 := 6; //OK, type is explicitly public
+const module3TypeFriend akarmi7 := 7; //NOK, module1 is NOT a friend of module3
+const module3TypePrivate akarmi8 := 8; //NOK, module2TypePrivate is private to module2
+
+type component User_CT extends Lib4_CT {};
+function f_set3_Lib4_1() runs on User_CT { v_Lib4_1 := 0 } //OK
+function f_set3_Lib4_2() runs on User_CT { v_Lib4_2 := 0 } //OK
+function f_set3_Lib4_3() runs on User_CT { v_Lib4_3 := 0 } //NOK, v_Lib4_3 is private
+}
+
+module module2
+{
+
+friend module module1;
+
+type integer module2Type;
+public type integer module2TypePublic;
+friend type integer module2TypeFriend;
+private type integer module2TypePrivate;
+} // end of module
+
+module module3
+{
+type integer module3Type;
+public type integer module3TypePublic;
+friend type integer module3TypeFriend;
+private type integer module3TypePrivate;
+} // end of module
+
+module module4 {
+type component Lib4_CT {
+var integer v_Lib4_1;
+public var integer v_Lib4_2;
+private var integer v_Lib4_3;
+}
+----
+
+== The `anytype`
+
+The special TTCN-3 type `anytype` is defined as shorthand for the union of all known data types and the address type (if defined) in a TTCN-3 module. This would result in a large amount of code having to be generated for the `anytype`, even if it is not actually used. For performance reasons, Titan only generates this code if a variable of `anytype` is declared or used, and does not create fields in the `anytype` for all data types. Instead, the user has to specify which types are needed as `anytype` fields with an extension attribute at module scope.
+
+Examples:
+
+[source]
+----
+module elsewhere {
+  type float money;
+  type charstring greeting;
+  }
+  module local {
+    import from elsewhere all;
+    type integer money;
+type record MyRec {
+  integer i,
+  float f
+}
+
+control {
+  var anytype v_any;
+  v_any.integer := 3;
+  // ischosen(v_any.integer) == true
+
+ v_any.charstring := "three";
+ // ischosen(v_any.charstring) == true
+
+ v_any.greeting := "hello";
+ // ischosen(v_any.charstring) == false
+ // ischosen(v_any.greeting) == true
+
+ v_any.MyRec := { i := 42, f := 0.5 }
+ // ischosen(v_any.MyRec) == true
+
+ v_any.integer := v_any.MyRec.i – 2;
+ // back to ischosen(v_any.integer) == true v_any.money := 0;
+ // local money i.e. integer
+ // not elsewhere.money (float)
+ // ischosen(v_any.integer) == false
+ // ischosen(v_any.money) == true
+
+ // error: no such field (not added explicitly)
+ // v_any.float := 3.1;
+
+ // error: v_any.elsewhere.money
+ }
+}
+
+with {
+
+extension "anytype integer, charstring" // adds two fields
+extension "anytype MyRec" // adds a third field
+extension "anytype money" // adds the local money type
+//not allowed: extension "anytype elsewhere.money"
+extension "anytype greeting" // adds the imported type}
+----
+
+In the above example, the `anytype` behaves as a union with five fields named "integer", "charstring", "MyRec", "money" and "greeting". The anytype extension attributes are cumulative; the effect is the same as if a single extension attribute contained all five types.
+
+NOTE: Field "greeting" of type charstring is distinct from the field "charstring" even though they have the same type (same for "integer" and "money").
+
+Types imported from another module (elsewhere) can be added to the anytype of the importing module (local) if the type can be accessed with its unqualified name, which requires that it does not clash with any local type. In the example, the imported type "greeting" can be added to the anytype of module local, but "money" (a float) clashes with the local type "money" (an integer). To use the imported "money", it has to be qualified with its module name, for example a variable of type elsewhere.money can be declared, but elsewhere.money can not be used as an anytype field.
+
+== Ports and Test Configurations
+
+If all instances of a TTCN–3 port type are intended to be used for internal communication only (i.e. between two TTCN–3 test components) the generation and linking of an empty Test Port skeleton can be avoided. If the attribute `with { extension "internal" }` is appended to the port type definition, all C++ code that is needed for this port will be included in the output modules.<<13-references.adoc#_9, [9]>>
+
+If the user wants to use `address` values in `to` and `from` clause and sender redirect of TTCN–3 port operations the `with { extension "address" }` attribute shall be used in the corresponding port type definition(s) to generate proper C++ code.
+
+NOTE: When address is used in port operations the corresponding port must have an active mapping to a port of the test system interface, otherwise the operation will fail at runtime. Using of address values in to and from clauses implicitly means system as component reference. (See section "Support of address type" in <<13-references.adoc#_16, [16]>> for more details).<<13-references.adoc#_10, [10]>>
+
+Unlike the latest TTCN–3 standard, our run time environment allows to connect a TTCN–3 port to more than one ports of the same remote test component. When these connections persist (usually in transient states), only receiving is allowed from that remote test component, because the destination cannot be specified unambiguously in the `to` clause of the `send` operation. Similarly, it is allowed to map a TTCN–3 port to more than one ports of the system, although it is not possible to send messages to the SUT.
+
+[[parameters-of-create-operation]]
+== Parameters of create Operation
+
+The built-in TTCN–3 `create` operation can take a second, optional argument in the parentheses. The first argument, which is the part of the standard, can assign a name to the newly created test component. The optional, non-standard second argument specifies the location of the component. Also the second argument is a value or expression of type `charstring`.
+
+According to the standard the component name is a user-defined attribute for a test component, which can be an arbitrary string value containing any kind of characters including whitespace. It is not necessary to assign a unique name for each test component; several active test components can have the same name at the same time. The component name is not an identifier; it cannot be used to address test components in configuration operations as component references can. The name can be assigned only at component creation and it cannot be changed later.
+
+Component name is useful for the following purposes:
+
+* it appears in the printout when logging the corresponding component reference;
+* it can be incorporated in the name of the log file (see the metacharacter `%n`);
+* it can be used to identify the test component in the configuration file (when specifying test port parameters (see section <<7-the_run-time_configuration_file.adoc#logging, `[LOGGING]`>>), component location constraints (see section <<7-the_run-time_configuration_file.adoc#components-parallel-mode, [COMPONENTS] (Parallel mode)>>) and logging options (see sections <<7-the_run-time_configuration_file.adoc#filemask, `FileMask`>> and <<7-the_run-time_configuration_file.adoc#consolemask, `ConsoleMask`>>).
+
+Specifying the component location is useful when performing distributed test execution. The value used as location must be a host name, a fully qualified domain name, an IP address or the name of a host group defined in the configuration file (see section <<7-the_run-time_configuration_file.adoc#groups-parallel-mode, [GROUPS] (Parallel mode)>>). The explicit specification of the location overrides the location constraints given in the configuration file (see section <<7-the_run-time_configuration_file.adoc#components-parallel-mode, [COMPONENTS] (Parallel mode)>> for detailed description). If no suitable and available host is found the `create` operation fails with a dynamic test case error.
+
+If only the component name is to be specified, the second argument may be omitted. If only the component location is specified a `NotUsedSymbol` shall be given in the place of the component name.
+
+Examples:
+
+[source]
+----
+//create operation without arguments
+var MyCompType v_myCompRef := MyCompType.create;
+
+// component name is assigned
+v_myCompRef := MyCompType.create("myCompName");
+
+// component name is calculated dynamically
+v_myCompArray[i] := MyCompType.create("myName" & int2str(i));
+
+// both name and location are specified (non-standard notation)
+v_myCompRef := MyCompType.create("myName", "heintel");
+
+// only the location is specified (non-standard notation)
+v_myCompRef := MyCompType.create(-, "159.107.198.97") alive;
+----
+
+== Altsteps and Defaults
+
+According to the TTCN–3 standard an `altstep` can be activated as `default` only if all of its value parameters are `in` parameters. However, our compiler and run-time environment allows the activation of altsteps with `out` or `inout` value or template parameters as well. In this case the actual parameters of the activated `default` shall be the references of variables or template variables that are defined in the respective component type. This restriction is in accordance with the rules of the standard about timer parameters of activated defaults.
+
+NOTE: Passing local variables or timers to defaults is forbidden because the lifespan of local definitions might be shorter than the `default` itself, which might lead to unpredictable behavior if the `default` is called after leaving the statement block that the local variable is defined in. Since ports can be defined only in component types, there is no restriction about the `port` parameters of `altsteps`. These restrictions are not applicable to direct invocations of `altsteps` (e.g. in `alt` constructs).
+
+The compiler allows using a statement block after `altstep` instances within `alt` statements. The statement block is executed if the corresponding `altstep` instance was chosen during the evaluation of the alt statement and the `altstep` has finished without reaching a `repeat` or `stop` statement. This language feature makes the conversion of TTCN–2 test suites easier.
+
+NOTE: This construct is valid according to the TTCN–3 BNF syntax, but its semantics are not mentioned anywhere in the standard text.
+
+The compiler accepts `altsteps` containing only an `[else]` branch. This is not allowed by the BNF as every `altstep` must have at least one regular branch (which can be either a guard statement or an `altstep` instance). This construct is practically useful if the corresponding `altstep` is instantiated as the last branch of the alternative.
+
+== Interleave Statements
+
+The compiler realizes TTCN–3 `interleave` statements using a different approach than it is described in section 7.5 of <<13-references.adoc#_1, [1]>>. The externally visible behavior of the generated code is equivalent to that of the canonical mapping, but our algorithm has the following advantages:
+
+* Loop constructs `for`, `while` and `do-whil`e loops are accepted and supported without any restriction in `interleave` statements. The transformation of statements is done in a lower level than the TTCN–3 language, which does not restrict the embedded loops.
+* Statements `activate`, `deactivate` and `stop` can also be used within `interleave`. The execution of these statements is atomic so we did not see the reason why the standard forbids them.
+* The size of our generated code is linear in contrast to the exponential code growth of the canonical algorithm. In other words, the C++ equivalent of every embedded statement appears exactly once in the output.
+* The run-time realization does not require any extra operating system resources, such as multi-threading.
+
+== Logging Disambiguation
+
+The TTCN–3 log statement provides the means to write logging information to a file or display on console (standard error). Options <<7-the_run-time_configuration_file.adoc#filemask, `FileMask`>> and <<7-the_run-time_configuration_file.adoc#consolemask, `ConsoleMask`>> determine which events will appear in the file and on the console, respectively. The generated logging messages are of type `USER_UNQUALIFIED`.
+
+The `log` statement accepts among others fixed character strings TTCN–3 constants, variables, timers, functions, templates and expressions; for a complete list please refer to the table 18 in <<13-references.adoc#_1, [1]>>. It is allowed to pass multiple arguments to a single `log` statement, separated by commas.
+
+The TTCN-3 standard does not specify how logging information should be presented. The following sections describe how TITAN implemented logging.
+
+The arguments of the TTCN-3 statement `action` are handled according to the same rules as `log`.
+
+=== Literal Free Text String
+
+Strings entered between quotation marks (") <<13-references.adoc#_11, [11]>> and the results of special macros given in section <<ttcn3-macros, TTCN-3 Macros>> in the argument of the `log` statement are verbatim copied to the log. The escape sequences given in Table 4 are interpreted and the resulting non-printable characters (such as newlines, tabulators, etc.) will influence the printout.
+
+Example:
+
+[source]
+----
+log("foo");//The log printout will look like this:
+ 12:34:56.123456 foo
+ bar
+----
+
+=== TTCN-3 Values and Templates
+
+Literal values, referenced values or templates, wildcards, compound values, in-line (modified) templates, etc. (as long as the type of the expression is unambiguous) are discussed in this section.
+
+These values are printed into the log using TTCN-3 Core Language syntax so that the printout can be simply copied into a TTCN-3 module to initialize an appropriate constant/variable/template, etc.
+
+In case of (`universal`) `charstring` values the delimiter quotation marks ("") are printed and the embedded non-printable characters are substituted with the escape sequences in the first 9 rows of Table 4. All other non-printable characters are displayed in the TTCN-3 quadruple notation.
+
+If the argument refers to a constant of type `charstring`, the actual value is not substituted to yield a literal string.
+
+Example:
+
+[source]
+----
+const charstring c_string := "foo\000";
+log(c_string);
+//The log printout will look like this:
+12:34:56.123456 "foo" & char(0, 0, 0, 0)
+----
+
+=== Built-in Function match()
+
+For the built-in `match()` function the printout will contain the detailed matching process field-by-field (similarly to the failed `receive` statements) instead of the Boolean result.
+
+This rule is applied only if the` match()` operation is the top-level expression to be logged, see the example below:
+
+[source]
+----
+ // this will print the detailed matching process
+log(match(v_myvalue, t_template));
+ // this will print only a Boolean value (true or false)
+log(not not match(v_myvalue, t_template));
+----
+All the other predefined and user-defined functions with actual arguments will print the return value of the function into the log according to the TTCN-3 standard.
+
+=== Special TTCN-3 Objects
+
+If the argument refers to a TTCN-3 `port`, `timer` or array (slice) of the above, then the actual properties of the TTCN-3 object is printed into the log.
+
+For ports the name and the state of the port is printed.
+
+In case of timers the name of the timer, the default duration, the current state (`inactive`, `started` or `expired`), the actual duration and the elapsed time (if applicable) is printed in a structured form.
+
+== Value Returning done
+
+The compiler allows starting TTCN–3 functions having return type on PTCs. Those functions must have the appropriate `runs on` clause. If such a function terminates normally on the PTC, the returned value can be matched and retrieved in a `done` operation.
+
+According to the TTCN-3 standard, the value redirect in a `done` operation can only be used to store the local verdict on the PTC that executed the behavior function. In TITAN the value redirect can also be used to store the behavior function’s return value with the help of an optional template argument.
+
+If this template argument is present, then the compiler treats it as a value returning done operation, otherwise it is treated as a verdict returning `done`.
+
+The following rules apply to the optional template argument and the value redirect:
+
+* The syntax of the template and value redirect is identical with that of the `receive` operation.
+* If the template is present, then the type of the template and the variable used in the value redirect shall be identical. If the template is not present, then the type of the value redirect must be `verdicttype`.
+* In case of a value returning done the return type shall be a TTCN–3 type marked with the following attribute: `with { extension "done" }`. It is allowed to mark and use several types in done statements within one test suite. If the type to be used is defined in ASN.1 then a type alias shall be added to one of the TTCN–3 modules with the above attribute.
+* In case of a value returning done the type of the template or variable must be visible from the module where the `done` statement is used.
+* Only those done statements can have a template or a value redirect that refer to a specific PTC component reference. That is, it is not allowed to use this construct with `any component.done` or `all component.done`.
+
+A value returning `done` statement is successful if all the conditions below are fulfilled:
+
+* The corresponding PTC has terminated.
+* The function that was started on the PTC has terminated normally. That is, the PTC was stopped neither by itself nor by other component and no dynamic test case error occurred.
+* The return type of the function that was started on the PTC is identical to the type of the template used in the `done` statement.
+* The value returned by the function on the PTC matches the given template.
+
+If the `done` operation was successful and the value redirect is present the value returned by the PTC (if there was a matching template), or the local verdict on the PTC (if there was no matching template) is stored in the given variable or variable field.
+
+The returned value can be retrieved from `alive` PTCs, too. In this case the `done` operation always refers to the return value of the lastly started behavior function of the PTC. Starting a new function on the PTC discards the return value of the previous function automatically (i.e. it cannot be retrieved or matched after the start component operation anymore).
+
+Example:
+
+[source]
+----
+type integer MyReturnType with { extension "done" };
+
+function ptcBehavior() runs on MyCompType return MyReturnType
+{
+  setverdict(inconc);
+  return 123;
+}
+
+// value returning ‘done’
+testcase myTestCase() runs on AnotherCompType
+{
+  var MyReturnType myVar;
+  var MyCompType ptc := MyCompType.create;
+  ptc.start(ptcBehavior());
+  ptc.done(MyReturnType : ?) -> value myVar;
+  // myVar will contain 123
+}
+
+// verdict returning ‘done’
+testcase myTestCase2() runs on AnotherCompType
+{
+  var verdicttype myVar;
+  var MyCompType ptc := MyCompType.create;
+  ptc.start(ptcBehavior());
+  ptc.done -> value myVar;
+  // myVar will contain inconc
+}
+----
+
+== Dynamic Templates
+
+Dynamic templates (template variables, functions returning templates and passing template variables by reference) are now parts of the TTCN–3 Core Language standard (<<13-references.adoc#_1, [1]>>). These constructs have been added to the standard with the same syntax and semantics as they were supported in this Test Executor. Thus dynamic templates are not considered language extensions anymore.
+
+However, there is one extension compared to the supported version of Core Language. Unlike the standard, the compiler and the run-time environment allow the external functions to return templates.
+
+Example:
+
+[source]
+----
+// this is not valid according to the standard
+external function MyExtFunction() return template octetstring;
+----
+
+== Template Module Parameters
+
+The compiler accepts template module parameters by inserting an optional "template" keyword into the standard modulepar syntax construct between the modulepar keyword and the type reference. The extended BNF rule:
+
+[source,subs="+quotes"]
+ModuleParDef ::= "modulepar" (ModulePar | (“{“MultiTypedModuleParList "}"))ModulePar ::= *["template"]* Type ModuleParList
+
+Example:
+
+[source]
+----
+modulepar template charstring mp_tstr1 := ( "a" .. "f") ifpresent
+modulepar template integer mp_tint := complement (1,2,3)
+----
+
+== Predefined Functions
+
+The built-in predefined functions `ispresent`, `ischosen`, `lengthof` and `sizeof` are applicable not only to value-like language elements (constants, variables, etc.), but template-like entities (templates, template variables, template parameters) as well. If the function is allowed to be called on a value of a given type it is also allowed to be called on a template of that type with the meaning described in the following subchapters.
+
+NOTE: "dynamic test case error" does not necessarily denote here an error situation: it may well be a regular outcome of the function.
+
+=== `sizeof`
+
+The function `sizeof` is applicable to templates of `record`, `set`, `record` of, `set` `of` and `objid` types. The function is applicable only if the `sizeof` function gives the same result on all values that match the template.<<13-references.adoc#_12, [12]>> In case of `record of` and `set of` types the length restrictions are also considered. Dynamic test case error occurs if the template can match values with different sizes or the length restriction contradicts the number of elements in the template body.
+
+Examples:
+
+[source]
+----
+type record of integer R;
+type set S { integer f1, bitstring f2 optional, charstring f3 optional }
+template R tr_1 := { 1, permutation(2, 3), ? }
+template R tr_2 := {1, *, (2, 3) }
+template R tr_3 := { 1, *, 10 } length(5)
+template R tr_4 := { 1, 2, 3, * } length(1..2)
+template S tr_5 := { f1 := (0..99), f2 := omit, f3 := ? }
+template S tr_6 := { f3 := *, f1 := 1, f2 := ’00’B ifpresent }
+template S tr_7 := ({ f1 := 1, f2 := omit, f3 := "ABC" },
+                  { f1 := 2, f3 := omit, f2 := ’1’B })
+template S tr_8 := ?
+
+//sizeof(tr_1) → 4
+//sizeof(tr_2) → error
+//sizeof(tr_3) → 5
+//sizeof(tr_4) → error
+//sizeof(tr_5) → 2
+//sizeof(tr_6) → error
+//sizeof(tr_7) → 2
+//sizeof(tr_8) → error
+----
+
+=== `ispresent`
+
+The predefined function `ispresent` has been extended; its parameter can now be any valid TemplateInstance. It is working according to the following ETSI CRs: http://forge.etsi.org/mantis/view.php?id=5934 and http://forge.etsi.org/mantis/view.php?id=5936.
+
+=== `oct2unichar`
+
+The function `oct2unichar` (`in octetstring invalue`, `in charstring string_encoding := "UTF-8"`) `return universal charstring` converts an octetstring `invalue` to a universal charstring by use of the given `string_encoding`. The octets are interpreted as mandated by the standardized mapping associated with the given `string_encoding` and the resulting characters are appended to the returned value. If the optional `string_encoding` parameter is omitted, the default value "UTF-8".
+
+The following values are allowed as `string_encoding` actual parameters: `UTF8`, `UTF-16`, `UTF-16BE`, `UTF-16LE`, `UTF-32`, `UTF-32BE`, `UTF-32LE`.
+
+DTE occurs if the `invalue` does not conform to UTF standards. The `oct2unichar` checks if the Byte Order Mark (BOM) is present. If not a warning will be appended to the log file. `oct2unichar` will `decode` the invalue even in absence of the BOM.
+
+Any code unit greater than 0x10FFFF is ill-formed.
+
+UTF-32 code units in the range of 0x0000D800 – 0x0000DFFF are ill-formed.
+
+UTF-16 code units in the range of 0xD800 – 0xDFFF are ill-formed.
+
+UTF-8 code units in the range of 0xD800 – 0xDFFF are ill-formed.
+
+Example:
+----
+oct2unichar('C384C396C39CC3A4C3B6C3BC'O)="ÄÖÜäöü";oct2unichar('00C400D600DC00E400F600FC'O,"UTF-16LE") = "ÄÖÜäöü";
+----
+
+=== `unichar2oct`
+
+The function `unichar2oct` (`in universal charstring invalue, in charstring string_encoding := "UTF-8"`) `return octetstring` converts a universal charstring `invalue` to an octetstring. Each octet of the octetstring will contain the octets mandated by mapping the characters of `invalue` using the standardized mapping associated with the given `string_encoding` in the same order as the characters appear in inpar. If the optional `string_encoding` parameter is omitted, the default encoding is "UTF-8".
+
+The following values are allowed as `string_encoding` actual parameters: UTF-8, UTF-8 BOM, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE.
+
+The function `unichar2oct` adds the Byte Order Mark (BOM) to the beginning of the `octetstring` in case of `UTF-16` and `UTF-32` encodings. The `remove_bom` function helps to remove it, if it is not needed. The presence of the BOM is expected at the inverse function `oct2unichar` because the coding type (without the BOM) can be detected only in case of `UTF-8` encoded `octetstring`. By default UTF-8 encoding does not add the BOM to the `octetstring`, however `UTF-8` `BOM` encoding can be used to add it.
+
+DTE occurs if the `invalue` does not conform to UTF standards.
+
+Any code unit greater than 0x10FFFF is ill-formed.
+
+Example:
+
+[source]
+----
+unichar2oct("ÄÖÜäöü") = 'EFBBBFC384C396C39CC3A4C3B6C3BC'O;
+unichar2oct("ÄÖÜäöü","UTF-16LE") = 'FFFE00C400D600DC00E400F600FC'O;
+----
+
+[[get-stringencoding]]
+=== `get_stringencoding`
+
+The function `get_stringencoding (in octetstring encoded_value) return charstring` identifies the encoding of the `encoded_value`. The following return values are allowed as charstring: ASCII, UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE.
+
+If the type of encoding could not been identified, it returns the value: <unknown>
+
+Example:
+
+[source]
+----
+var octetstring invalue := 'EFBBBFC384C396C39CC3A4C3B6C3BC'O;
+var charstring codingtype := get_stringencoding(invalue);
+the resulting codingtype is "UTF-8"
+----
+
+[[remove-bom]]
+=== `remove_bom`
+
+The function `remove_bom (in octetstring encoded_value) return octetstring` strips the BOM if it is present and returns the original octetstring otherwise.
+
+Example:
+
+[source]
+----
+var octetstring invalue := 'EFBBBFC384C396C39CC3A4C3B6C3BC'O;
+var octetstring nobom := remove_bom(invalue);
+the resulting nobom contains: 'C384C396C39CC3A4C3B6C3BC'O;
+----
+
+== Additional Predefined Functions
+
+In addition to standardized TTCN–3 predefined functions given in Annex C of <<13-references.adoc#_1, [1]>> and Annex B of <<13-references.adoc#_3, [3]>> the following built-in conversion functions are supported by our compiler and run-time environment:
+
+=== `str2bit`
+
+The function `str2bit (charstring value) return bitstring` converts a `charstring` value to a `bitstring`, where each character represents the value of one bit in the resulting bitstring. Its argument may contain the characters "0" or "1" only, otherwise the result is a dynamic test case error.
+
+NOTE: This function is the reverse of the standardized `bit2str`.
+
+Example:
+
+[source]
+str2bit ("1011011100") = ’1011011100’B
+
+=== `str2hex`
+
+The function `str2hex (charstring value)` `return hexstring` converts a `charstring` value to a `hexstring`, where each character in the character string represents the value of one hexadecimal digit in the resulting `hexstring`. The incoming character string may contain any number of characters. A dynamic test case error occurs if one or more characters of the charstring are outside the ranges "0" .. "9", "A" .. "F" and "a" .. "f".
+
+NOTE: This function is the reverse of the standardized `hex2str`.
+
+Example:
+
+[source]
+----
+str2hex ("1D7") = ’1D7’H
+----
+
+=== float2str
+
+The function `float2str (float value) return charstring` converts a `float` value to a `charstring`. If the input is zero or its absolute value is between 10^-4^ and 10^10^, the decimal dot notation is used in the output with 6 digits in the fraction part. Otherwise the exponential notation is used with automatic (at most 6) digits precision in the mantissa.
+
+Example:
+
+[source]
+----
+float2str (3.14) = "3.140000"
+----
+
+=== unichar2char
+
+The function `unichar2char (universal charstring value) return charstring` converts a` universal charstring` value to a `charstring`. The elements of the input string are converted one by one. The function only converts universal characters when the conversion result lies between 0 end 127 (that is, the result is an ISO 646 character).
+
+NOTE: The inverse conversion is implicit, that is, the `charstring` values are converted to `universal charstring` values automatically, without the need for a conversion function.
+
+Example:
+
+[source]
+----
+unichar2char(char(0,0,0,64)) = "@"
+----
+
+=== `log2str`
+
+The function `log2str` can be used to log into `charstring` instead of the log file.
+
+Syntax:
+
+[source]
+log2str (…) return charstring
+
+This function can be parameterized in the same way as the `log` function, it returns a charstring value which contains the log string for all the provided parameters, but it does not contain the timestamp, severity and call stack information, thus the output does not depend on the runtime configuration file. The parameters are interpreted the same way as they are in the log function: their string values are identical to what the log statement writes to the log file. The extra information (timestamp, severity, call stack) not included in the output can be obtained by writing external functions which use the runtime’s Logger class to obtain the required data.
+
+=== `testcasename`
+
+The function `testcasename` returns the unqualified name of the actually executing test case. When it is called from the control part and no test case is being executed, it returns the empty string.
+
+Syntax:
+
+[source]
+testcasename () return charstring
+
+=== `isbound`
+
+The function `isbound` behaves identically to the `isvalue` function with the following exception: it returns true for a record-of value which contains both initialized and uninitialized elements.
+
+[source]
+----
+type record of integer rint;
+var rint r_u; // uninitialized
+isvalue(r_u); // returns false
+isbound(r_u); // returns false also
+//lengthof(r_u) would cause a dynamic testcase error
+
+var rint r_0 := {} // zero length
+isvalue(r_3); // returns true
+isbound(r_3); // returns true
+lengthof(r_3); // returns 0
+
+var rint r_3 := { 0, -, 2 } // has a "hole"
+isvalue(r_3); // returns false
+isbound(r_3); // returns true
+lengthof(r_3); // returns 3
+
+var rint r_3full := { 0, 1, 2 }
+isvalue(r_3full); // returns true
+isbound(r_3full); // returns true
+lengthof(r_3full); // returns 3
+----
+
+The introduction of `isbound` permits TTCN-3 code to distinguish between r_u and r_3; `isvalue` alone cannot do this (it returns false for both).
+
+Syntax:
+[source]
+isbound (in template any_type i) return boolean;
+
+=== `ttcn2string`
+
+Syntax:
+[source]
+ttcn2string(in <TemplateInstance> ti) return charstring
+
+This predefined function returns its parameter’s value in a string which is in TTCN-3 syntax. The returned string has legal ttcn-3 with a few exceptions such as unbound values. Unbound values are returned as “-“, which can be used only as fields of assignment or value list notations, but not as top level assignments (e.g. `x:=- is illegal`). Differences between the output format of `ttcn2string()` and `log2str()`:
+
+[cols=",,",options="header",]
+|===
+|Value/template |`log2str()` |`ttcn2string()`
+|Unbound value |`"<unbound>"` |“-“
+|Uninitialized template |`"<uninitialized template>"` |“-“
+|Enumerated value |`name (number)` |name
+|===
+
+=== `string2ttcn`
+
+Syntax:
+
+[source]
+string2ttcn(in charstring ttcn_str, inout <reference> ref)
+
+This predefined function does not have a return value, thus it is a statement. Any error in the input string will cause an exception that can be caught using @try - @catch blocks. The message string of the exception contains the exact cause of the error. There might be syntax and semantic errors. This function uses the module parameter parser of the TITAN runtime, it accepts the same syntax as the module parameters of the configuration file. Check the documentation chapters for the module parameters section. There are differences between the ttcn-3 syntax and the configuration file module parameters syntax, these are described in the documentation chapter of the module parameters. The second parameter must be a reference to a value or template variable.
+
+Example code:
+
+[source]
+----
+type record MyRecord { integer a, boolean b }
+…
+var template MyRecord my_rec
+@try {
+  string2ttcn("complement ({1,?},{(1,2,3),false}) ifpresent", my_rec)
+  log(my_rec)
+  }
+  @catch (err_str) {
+    log(“string2ttcn() failed: “, err_str)
+  }
+
+The log output will look like this:
+complement ({ a := 1, b := ? }, { a := (1, 2, 3), b := false }) ifpresent
+----
+
+[[encode-base64]]
+=== `encode_base64`
+
+Syntax:
+
+[source]
+----
+encode_base64(in octetstring ostr, in boolean
+  use_linebreaks := false) return charstring
+----
+
+The function `encode_base64 (in octetstring ostr, in boolean use_linebreaks := false) return charstring `converts an octetstring `ostr` to a charstring. The charstring will contain the Base64 representation of `ostr`. The `use_linebreaks` parameter adds newlines after every 76 output characters, according to the MIME specs, if it is omitted, the default value is false.
+
+Example:
+
+[source]
+----
+encode_base64('42617365363420656E636F64696E6720736368656D65'O) ==
+"QmFzZTY0IGVuY29kaW5nIHNjaGVtZQ=="
+----
+
+[[decode-base64]]
+=== `decode_base64`
+
+Syntax:
+
+[source]
+----
+decode_base64(in charstring str) return octetstring
+----
+
+The function `decode_base64 (in charstring str) return octetstring` converts a chartstring `str` encoded in Base64 to an octetrstring. The octetstring will contain the decoded Base64 string of `str`.
+
+Example:
+
+[source]
+----
+decode_base64("QmFzZTY0IGVuY29kaW5nIHNjaGVtZQ==") ==
+'42617365363420656E636F64696E6720736368656D65'O
+----
+
+=== `json2cbor`
+
+Syntax:
+
+[source]
+----
+json2cbor(in universal charstring us) return octetstring
+----
+
+The function `json2cbor(in universal charstring us) return octetstring` converts a TITAN encoded json document into the binary representation of that json document using a binary coding called CBOR. The encoding follows the recommendations written in the CBOR standard <<13-references.adoc#_22, [22]>> section 4.2.
+
+Example:
+
+[source]
+----
+json2cbor("{"a":1,"b":2}") == ‘A2616101616202’O
+----
+
+=== `cbor2json`
+
+Syntax:
+[source]
+----
+cbor2json(in octetstring os) return universal charstring
+----
+
+The function `cbor2json(in octetstring os) return universal charstring` converts a CBOR encoded bytestream into a json document which can be decoded using the built in JSON decoder. The decoding follows the recommendations written in the CBOR standard <<13-references.adoc#_22, [22]>> section 4.1 except that the indefinite-length items are not made definite before conversion and the decoding of indefinite-length items is not supported.
+
+Example:
+[source]
+----
+cbor2json(‘A2616101616202’O) == "{"a":1,"b":2}"
+----
+
+=== `json2bson`
+
+Syntax:
+[source]
+----
+json2bson(in universal charstring us) return octetstring
+----
+
+The function `json2bson(in universal charstring us) return octetstring` converts a TITAN encoded json document into the binary representation of that json document using a binary coding called BSON. Only top level json objects and arrays can be encoded. (Note that an encoded top level json array will be decoded as a json object) The encoding follows the rules written in the BSON standard <<13-references.adoc#_23, [23]>>. The encoding handles the extension rules written in the MongoDB Extended JSON document <<13-references.adoc#_24, [24]>>. The encoding of 128-bit float values is not supported.
+
+Example:
+[source]
+----
+json2bson("{"a":1,"b":2}") == ‘13000000106100010000001062000200000000’O
+----
+
+=== `bson2json`
+
+Syntax:
+[source]
+----
+bson2json(in octetstring os) return universal charstring
+----
+
+The function `bson2json(in octetstring os) return universal charstring` converts a BSON encoded bytestream into a json document which can be decoded using the built in JSON decoder. The decoding follows the extension rules written in the BSON standard <<13-references.adoc#_23, [23]>>. The decoding handles the rules written in the MongoDB Extended JSON document <<13-references.adoc#_24, [24]>>. The decoding of 128-bit float values is not supported.
+
+Example:
+[source]
+----
+bson2json(‘13000000106100010000001062000200000000’O) == "{"a":1,"b":2}"
+----
+
+== Exclusive Boundaries in Range Subtypes
+
+The boundary values used to specify range subtypes can be preceded by an exclamation mark. By using the exclamation mark the boundary value itself can be excluded from the specified range. For example integer range (!0..!10) is equivalent to range (1..9). In case of float type open intervals can be specified by using excluded boundaries, for example (0.0..!1.0) is an interval which contains 0.0 but does not contain 1.0.
+
+[[special-float-values-infinity-and-not-a-number]]
+== Special Float Values Infinity and not_a_number
+
+The keyword infinity (which is also used to specify value range and size limits) can be used to specify the special float values –infinity and +infinity, these are equivalent to MINUS-INFINITY and PLUS-INFINITY used in ASN.1. A new keyword not_a_number has been introduced which is equivalent to NOT-A-NUMBER used in ASN.1. The -infinity and +infinity and not_a_number special values can be used in arithmetic operations. If an arithmetic operation’s operand is not_a_number then the result of the operation will also be not_a_number. The special value not_a_number cannot be used in a float range subtype because it’s an unordered value, but can be added as a single value, for example subtype (0.0 .. infinity, not_a_number) contains all positive float values and the not_a_number value.
+
+[[ttcn-3-preprocessing]]
+== TTCN–3 Preprocessing
+
+Preprocessing of the TTCN-3 files with a C preprocessor is supported by the compiler. External preprocessing is used: the Makefile Generator generates a `Makefile` which will invoke the C preprocessor to preprocess the TTCN-3 files with the suffix `."ttcnpp`. The output of the C preprocessor will be generated to an intermediate file with the suffix `."ttcn`. The intermediate files contain the TTCN-3 source code and line markers. The compiler can process these line markers along with TTCN-3. If the preprocessing is done with the `-P` option <<13-references.adoc#_13, [13]>>, the resulting code will not contain line markers; it will be compatible with any standard TTCN-3 compiler. The compiler will use the line markers to give almost <<13-references.adoc#_14, [14]>> correct error or warning messages, which will point to the original locations in the `.ttcnpp` file. The C preprocessor directive `#"include` can be used in .ttcnpp files; the Makefile Generator will treat all files with suffix `."ttcnin` as TTCN-3 include files. The `."ttcnin` files will be added to the Makefile as special TTCN-3 include files which will not be translated by the compiler, but will be checked for modification when building the test suite.
+
+Extract from the file:
+[source]
+----
+Example.ttcnpp:
+module Example {
+function func()
+{
+#ifdef DEBUG
+log("Example: DEBUG");
+#else
+log("Example: RELEASE");
+#endif
+
+}
+
+…
+----
+
+The output is a preprocessed intermediate file `Example.ttcn`. The resulting output from the above code:
+[source]
+----
+…
+# 1 "Example.ttcnpp"
+module Example {
+function func()
+{
+log("Example: RELEASE");
+}
+----
+
+The line marker (`# 1 "Example.ttcnpp"`) tells the compiler what the origin of the succeeding code is.
+
+== Parameter List Extensions
+
+In addition to standardized TTCN-3 parameter handling described in 5.4.2 of <<13-references.adoc#_1, [1]>> TITAN also supports the mixing of list notation and assignment notation in an actual parameter list.
+
+=== Missing Named and Unnamed Actual Parameters
+
+To facilitate handling of long actual parameter lists in the TITAN implementation, the actual parameter list consists of two optional parts: an unnamed part followed by a named part, in this order. In the actual parameter list a value must be assigned to every mandatory formal parameter either in the named part or in the unnamed part. (Mandatory parameter is one without default value assigned in the formal parameter list.) Consequently, the unnamed part, the named part or both may be omitted from the actual parameter list. Omitting the named part from the actual parameter lists provides backward compatibility with the standard notation.
+
+The named and unnamed parts are separated by a comma as are the elements within both lists. It is not allowed to assign value to a given formal parameter in both the named and the unnamed part of the actual parameter list.
+
+There can be at most one unnamed part, followed by at most one named part. Consequently, an unnamed actual parameter may not follow a named parameter.
+
+Named actual parameters must follow the same relative order as the formal parameters. It is not allowed to specify named actual parameters in an arbitrary order.
+
+Examples
+
+The resulting parameter values are indicated in brackets in the comments:
+
+[source]
+----
+function myFunction(integer p_par1, boolean p_par2 := true) { … }
+control {
+*// the actual parameter list is syntactically correct below:*
+myFunction(1, p_par2 := false); // (1, false)
+myFunction(2); // (2, true)
+myFunction(p_par1 := 3, p_par2 := false); // (3, false)
+*// the actual parameter list is syntactically erroneous below:*
+myFunction(0, true, -); // too many parameters
+myFunction(1, p_par1 := 1); // p_par1 is given twice
+myFunction(); // no value is assigned to mandatory p_par1
+myFunction(p_par2 := false, p_par1 := 3); // out of order
+myFunction(p_par2 := false, 1); // unnamed part cannot follow
+// named part
+}
+----
+
+== `function`, `altstep` and `testcase` References
+
+Although TITAN supports the behaviour type package (<<13-references.adoc#_5, [5]>>) of the TTCN-3 standard, but this feature was included in the standard with a different syntax.
+
+It is allowed to create TTCN–3 types of `functions`, `altsteps` and `testcases`. Values, for example variables, of such types can carry references to the respective TTCN–3 definitions. To facilitate reference using, three new operations (`refers`, `derefers` and `apply`) were introduced. This new language feature allows to create generic algorithms inTTCN–3 with late binding, (i.e. code in which the function to be executed is specified only at runtime).
+
+[[function-types-with-a-runson-self-clause]]
+== Function Types with a RunsOn_self Clause
+
+A function type or an altstep type, defined with a standard `runs on` clause, can use all constants, variables, timers and ports given in the component type definition referenced by the `runs on` clause (see chapter 16 of <<13-references.adoc#_1, [1]>>).
+
+A function type or an altstep type, defined with the TITAN-introduced `runs on self` clause, similarly, makes use of the resources of a component type; however, the component type in question is not given in advance. When an altstep or a function is called via a function variable, that is, a reference, using the `apply` operation, it can use the resources defined by the component type indicated in the `runs on` clause of the actually referenced function or altstep.
+
+The "runs on self" construct is permitted only for `function` and `altstep` types. Any actual function or altstep must refer to a given component type name in their `runs on` clause.
+
+A variable with type of function type is called a *function variable*. Such variables can contain references to functions or altsteps. At function variable assignment, component type compatibility checking is performed with respect to the component context of the assignment statement and the "runs on" clause of the assigned function or altstep. When the `apply()` operator is applied to a function variable, no compatibility checking is performed.
+
+The rationale for this distinction is the following: due to type compatibility checking at the time of value assignment to the function variable, the TTCN-3 environment can be sure that any non-`null` value of the variable is a function reference that is component-type-compatible with that component that is actually executing the code using the `apply()` operator.
+
+As a consequence of this, it is forbidden to use values of function variables as arguments to the TTCN-3 operators `start()` or `send()`.
+
+Example of using the clause `runs on self` in a library
+
+A component type may be defined as an extension of another component type (using the standard `extends` keyword mentioned in chapter 6.2.10.2 of <<13-references.adoc#_1, [1]>>). The effect of this definition is that the extended component type will implicitly contain all constant, variable, port and timer definitions from the parent type as well. In the example below, the component type `User_CT` aggregates its own constant, variable, port and timer definitions (resources) with those defined in the component type `Library_CT` (see line a).
+
+The library developer writes a set of library functions that have a `runs on Library_CT` clause (see line h). Such library functions may offer optional references to other functions that are supposed to be specified by the user of the library (see line e). We say in this case that the library function may call user-provided *callback functions* via function variables. These function variables must have a type specified; optionally with a runs on clause. If this `runs on` clause refers to an actual component type name, then this actual type name must be known at the time of writing the library.
+
+Library functions that runs on `Library_CT` can run on other component types as well, provided that the actual component type is compatible with `Library_CT` (see chapter 6.3.3 of <<13-references.adoc#_1, [1]>>). An obvious design goal for the library writer is to permit references to any callback function that has a component-type-compatible `runs on` clause. However, the cardinality of compatible component types is infinitely large; therefore, they *cannot* be explicitly referenced by the function type definitions of the library.
+
+The "runs on self" concept provides a remedy for this contradiction and allows conceiving library components prepared to take up user-written "plug-ins".
+
+In the code excerpt below, function `f_LibraryFunction` (which has the clause `runs on Library_CT`) uses the function reference variable `v_callBackRef_self` (defined in `Library_CT`).The function `f_MyCallbackFunction` (see line b) has a `runs on User_CT` clause. `User_CT` (see line a) extends `Library_CT`, therefore it is suitable for running library function with runs on `Library_CT` clause, for example.
+
+When the assignment to the function variable `v_CallbackRef_self` is performed (see line c) inside `f_MyUserFunction` (that is, inside the context `User_CT`), then compatibility checking is performed. Since `User_CT` is compatible with `Library_CT`, the assignment is allowed.
+
+Direct call to `f_MyCallbackFunction()` with `runs on User_CT` from a `runs on Library_CT` context (see line g) would cause semantic error according to the TTCN3 language. However, calling the function via `v_CallBackRef_self` is allowed (see line d).
+
+[source]
+----
+module RunsOn_Self
+{
+//=========================================================================
+// Function Types
+//=========================================================================
+
+//---- line f)
+type function CallbackFunctionRefRunsonSelf_FT () runs on self;
+
+//=========================================================================
+//Component Types
+//=========================================================================
+type component Library_CT
+{
+//---- line e)
+  var CallbackFunctionRefRunsonSelf_FT v_CallbackRef_self := null;
+  var integer v_Lib;
+}
+//---- line a)
+type component User_CT extends Library_CT
+{
+  var integer v_User;
+}
+
+//---- line h)
+function f_LibraryFunction () runs on Library_CT
+{
+//---- line g)
+  // Direct call of the callback function would cause semantic ERROR
+//f_MyCallbackFunction();
+
+  if (v_CallbackRef_self != null)
+  {
+    // Calling a function via reference that has a "runs on self" in its header
+    // is always allowed with the exception of functions/altsteps without runs
+    // on clause
+//---- line d)
+    v_CallbackRef_self.apply();
+  }
+}// end f_LibraryFunction
+
+function f_MyUserFunction () runs on User_CT
+{
+  // This is allowed as f_MyCallbackFunction has runs on clause compatible
+  // with the runs on clause of this function (f_MyUserFunction)
+  // The use of function/altstep references with "runs on self" in their
+  // headers is limited to call them on the given component instance; i.e.
+  // allowed: assignments, parameterization and activate (the actual function's
+  //          runs on is compared to the runs on of the function in which
+  //          the operation is executed)
+  // not allowed: start, sending and receiving
+  // no check is needed for apply!
+//---- line c)
+  v_CallbackRef_self := refers (f_MyCallbackFunction);
+
+  // This is allowed as Library_CT is a parent of User_CT
+  // Pls. note, as the function is executing on a User_CT
+  // instance, it shall never cause a problem of calling
+  // a callback function with "runs on User_CT" from it.
+  f_LibraryFunction();
+
+}//end f_MyUserFunction
+
+//---- line b)
+function f_MyCallbackFunction () runs on User_CT
+{/*application/dependent behaviour*/}
+
+} // end of module RunsOn_Self
+----
+
+[[ttcn3-macros]]
+== TTCN–3 Macros
+
+The compiler and the run-time environment support the following non-standard macro notation in TTCN–3 modules. All TTCN–3 macros consist of a percent (%) character followed by the macro identifier. Macro identifiers are case sensitive. The table below summarizes the available macros and their meaning. Macro identifiers not listed here are reserved for future extension.
+
+.TTCN-3 macros
+[cols=",",options="header",]
+|===
+|Macro |Meaning
+|`%moduleId` |name of the TTCN–3 module
+|`%definitionId` |name of the top-level TTCN–3 definition
+|`%testcaseId` |name of the test case that is currently being executed
+|`%fileName` |name of the TTCN–3 source file
+|`%lineNumber` |number of line in the source file
+|===
+
+The following rules apply to macros:
+
+* All macros are substituted with a value of type `charstring`. They can be used as operands of complex expressions (concatenation, comparison, etc.).
+* All macros except `%testcaseId` are evaluated during compilation and they can be used anywhere in the TTCN–3 module.
+* Macro `%testcaseId` is evaluated at runtime. It can be used only within functions and altsteps that are being run on test components (on the MTC or PTCs) and within testcases. It is not allowed to use macro `%testcaseId` in the module control part. If a function or altstep that contains macro `%testcaseId` is called directly from the control part the evaluation of the macro results in a dynamic test case error.
+* The result of macro `%testcaseId` is not a constant thus it cannot be used in the value of TTCN–3 constants. It is allowed only in those contexts where TTCN–3 variable references are permitted.
+* Macro `%definitionId` is always substituted with the name of the top-level module definition that it is used in. <<13-references.adoc#_15, [15]>> For instance, if the macro appears in a constant that is defined within a function then the macro will be substituted with the function’s name rather than the one of the constant. When used within the control part macro `%definitionId` is substituted with the word "`control`".
+* Macro `%fileName` is substituted with the name of the source file in the same form as it was passed to the compiler. This can be a simple file name, a relative or an absolute path name.
+* The result of macro `%lineNumber` is always a string that contains the current line number as a decimal number. Numbering of lines starts from 1. All lines of the input file (including comments and empty lines) are counted. When it needs to be used in an integer expression a conversion is necessary: `str2int(%lineNumber)`. The above expression is evaluated during compilation without any runtime performance penalty.
+* Source line markers are considered when evaluating macros `%fileName` and `%lineNumber`. In preprocessed TTCN–3 modules the macros are substituted with the original file name and line number that the macro comes from provided that the preprocessor supports it.
+* When macros are used in `log()` statements, they are treated like literal strings rather than charstring value references. That is, quotation marks around the strings are not used and special characters within them are not escaped in the log file.
+* For compatibility with the C preprocessor the compiler also recognizes the following C style macros: \\__FILE__ is identical to `%fileName` and \\__LINE__ is identical to `str2int(%lineNumber)`.
+* Macros are not substituted within quotation marks (i.e. within string literals and attributes).
+* The full power of TTCN–3 macros can be exploited in combination with the C preprocessor.
+
+Example:
+[source]
+----
+module M {
+// the value of c_MyConst will be "M"
+const charstring c_MyConst := %moduleId;
+// MyTemplate will contain 28
+template integer t_MyTemplateWithVeryLongName := lengthof(%definitionId);
+function f_MyFunction() {
+// the value of c_MyLocalConst1 will be "f_MyFunction"
+const charstring c_MyLocalConst1 := %definitionId;
+// the value of c_MyLocalConst2 will be "%definitionId"
+const charstring c_MyLocalConst2 := "%definitionId";
+// the value of c_MyLocalConst3 will be "12"
+const charstring c_MyLocalConst3 := %lineNumber; //This is line 12
+// the value of c_MyLocalConst4 will be 14
+const integer c_MyLocalConst4 := str2int(%lineNumber);//This is line 14
+// the line below is invalid because %testcaseId is not a constant
+const charstring c_MyInvalidConst := %testcaseId;
+// this is valid, of course
+var charstring v_MyLocalVar := %testcaseId;
+// the two log commands below give different output in the log file
+log("function:", %definitionId, " testcase: “, %testcaseId);
+// printout: function: f_MyFunction testcase: tc_MyTestcase
+log("function:", c_MyLocalConst1, " testcase: “, v_MyLocalVar);
+// printout: function: "f_MyFunction" testcase: "tc_MyTestcase"
+}
+}
+----
+
+== Component Type Compatibility
+
+The ETSI standard defines type compatibility of component types for component reference values and for functions with "`runs on`" clause. In order to be compatible, both component types are required to have identical definitions (cf. <<13-references.adoc#_1, [1]>>, chapter 6.3.3).
+
+NOTE: Compatibility is an asymmetric relation, if component type B is compatible with component type A, the opposite is not necessarily true. (E.g., component type B may contain definitions absent in component type A.)
+
+All definitions from the parent type are implicitly contained when the keyword `extends` appears in the type definition (cf. <<13-references.adoc#_1, [1]>>, chapter 6.2.10.2) and so the required identity of the type definitions is ensured. The compiler considers component type B to be compatible with A if B has an `extends` clause, which contains A or a component type that is compatible with A.
+
+Example:
+[source]
+----
+type component A { var integer i; }
+type component B extends A {
+// extra definitions may be added here
+}
+----
+
+In order to provide support for existing TTCN–3 code (e.g. standardized test suites) it is allowed to explicitly signal the compatibility relation between component types using a special `extension` attribute. Using such attributes shall be avoided in newly written TTCN–3 modules. Combining component type inheritance and the attribute `extension` is possible, but not recommended.
+
+Thus, the compiler considers component type B to be compatible with A if B has an `extension` attribute that points to A as base component type and all definitions of A are present and identical in B.
+
+[source]
+----
+type component A { var integer i; }
+type component B {
+var integer i; // definitions of A must be repeated
+var octetstring o; // new definitions may be added
+} with {
+extension "extends A"
+}
+----
+
+=== Implementation Restrictions
+
+The list of definitions shared with different compatible component types shall be distinct. If component type Z is compatible with both X and Y and neither X is compatible with Y nor Y is compatible with X then X and Y shall not have definitions with identical names but different origin. If both X and Y are compatible with component type C then all definitions in X and Y which are originated from C are inherited by Z on two paths.
+
+Example: According to the standard component type Z should be compatible with both X and Y, but the compatibility relation cannot be established because X and Y have a definition with the same name.
+
+[source]
+----
+type component X { timer T1, T2; }
+type component Y { timer T1, T3; }
+type component Z { timer T1, T2, T3; }
+with { extension "extends X, Y" }
+// invalid because the origin of T1 is ambiguous
+----
+
+The situation can be resolved by introducing common ancestor C for X and Y, which holds the shared definition.
+
+[source]
+----
+type component C { timer T1; }
+type component X { timer T1, T2; } with { extension "extends C" }
+type component Y { timer T1, T3; } with { extension "extends C" }
+type component Z {
+timer T1, // origin is C
+T2, // origin is X
+T3; // origin is Y
+} with { extension "extends X, Y" }
+----
+
+Circular compatibility chains between component types are not allowed. If two component types need to be defined as identical, type aliasing must be used instead of compatibility.
+
+The following code is invalid:
+
+[source]
+----
+type component A {
+…
+// the same definitions as in B
+} with { extension "extends B" }
+type component B {
+…
+// the same definitions as in A
+} with { extension "extends A" }
+----
+
+When using the non-standard extension attribute the initial values of the corresponding definitions of compatible components should be identical. The compiler does not enforce this for all cases; however, in the case of different initial values the resulting run-time behavior is undefined. If the initial values cannot be determined at compile time (module parameters) the compiler will remain silent. In other situations the compiler may report an error or a warning.
+
+All component types are compatible with each empty component type. Empty components are components which have neither own nor inherited definitions.
+
+== Implicit Message Encoding
+
+The TTCN–3 standard <<13-references.adoc#_1, [1]>> does not specify a standard way of data encoding/decoding. TITAN has a common C\++ API for encoding/decoding; to use this API external functions are usually needed. The common solution is to define a TTCN–3 external function and write the C++ code containing the API calls. In most cases the C++ code explicitly written to an auxiliary C++ file contains only simple code patterns which call the encoding/decoding API functions on the specified data. In TITAN there is a TTCN–3 language extension which automatically generates such external functions.
+
+Based on this automatic encoding/decoding mechanism, dual-faced ports are introduced. Dual-faced ports have an external and an internal interface and can automatically transform messages passed through them based on mapping rules defined in TTCN–3 source files. These dual-faced ports eliminate the need for simple port mapping components and thus simplify the test configuration.
+
+[[dual-faced-ports]]
+=== Dual-faced Ports
+
+In the TTCN–3 standard (<<13-references.adoc#_1, [1]>>), a port type is defined by listing the allowed incoming and outgoing message types. Dual-faced ports have on the other hand two different message lists: one for the external and one for the internal interface. External and internal interfaces are given in two distinct port type definitions. The dual-faced concept is applicable to message based ports and the message based part of mixed ports.
+
+Dual-faced port types must have `user` attribute to designate its external interface. The internal interface is given by the port type itself. A port type can be the external interface of several different dual-faced port types.
+
+The internal interface is involved in communication operations (`send`, `receive`, etc.) and the external interface is used when transferring messages to/from other test components or the system under test. The operations `connect` and `map` applied on dual-faced ports will consider the external port type when checking the consistency of the connection or mapping.<<13-references.adoc#_16, [16]>>
+
+==== Dual-faced Ports between Test Components
+
+Dual-faced ports used for internal communication must have the attributes `internal` in addition to `user` (see section <<visibility-modifiers, Visibility Modifiers>>). The referenced port type describing the external interface may have any attributes.
+
+==== Dual-faced Ports between Test Components and the SUT
+
+The port type used as external interface must have the attribute `provider`. These dual-faced port types do not have their own test port; instead, they use the test port belonging to the external interface when communicating to SUT. Using the attribute `provider` implies changes in the Test Port API of the external interface. For details see the section "Provider port types" in <<13-references.adoc#_16, [16]>>.
+
+If there are several entities within the SUT to be addressed, the dual-faced port type must have the attribute `address` in addition to `user`. In this case the external interface must have the attribute `address` too. For more details see section <<visibility-modifiers, Visibility Modifiers>>.
+
+=== Type Mapping
+
+Mapping is required between the internal and external interfaces of the dual-faced ports because the two faces are specified in different port type definitions, thus, enabling different sets of messages.
+
+Messages passing through dual-faced ports will be transformed based on the mapping rules. Mapping rules must be specified for the outgoing and incoming directions separately. These rules are defined in the attribute `user` of the dual-faced port type.
+
+An outgoing mapping is applied when a `send` operation is performed on the dual-faced port. The outcome of the mapping will be transmitted to the destination test component or SUT. The outgoing mappings transform each outgoing message of the internal interface to the outgoing messages of the external interface.
+
+An incoming mapping is applied when a message arrives on a dual-faced port from a test component or the SUT. The outcome of the mapping will be inserted into the port queue and it will be extracted by the `receive` operation. The incoming mappings transform each incoming messages of the external interface to the incoming message of the internal interface.
+
+==== Mapping Rules
+
+A mapping rule is an elementary transformation step applied on a message type (source type) resulting in another message type (target type). Source type and target type are not necessarily different.
+
+Mapping rules are applied locally in both directions, thus, an error caused by a mapping rule affects the test component owning the dual-faced port, not its communication partner.
+
+Mappings are given for each source type separately. Several mapping targets may belong to the same source type; if this is the case, all targets must be listed immediately after each other (without repeating the source type).
+
+The following transformation rules may apply to the automatic conversion between the messages of the external and internal interfaces of a dual-faced port:
+
+* No conversion. Applicable to any message type, this is a type preserving mapping, no value conversion is performed. Source and target types must be identical. This mapping does not have any options. For example, control or status indication massages may transparently be conveyed between the external and the internal interfaces.Keyword used in attribute `user` of port type definition: `simple`.
+* Message discarding. This rule means that messages of the given source type will not be forwarded to the opposite interface. Thus, there is no destination type, which must be indicated by the not used symbol (-). This mapping does not have any options. For example, incoming status indication massages of the external interface may be omitted on the internal interface. Keyword used in attribute `user` of port type definition: `discard`.
+* Conversion using the built-in codecs. Here, a corresponding encoding or decoding subroutine of the built-in codecs (for example RAW, TEXT or BER) is invoked. The conversion and error handling options are specified with the same syntax as used for the encoding/decoding functions, see section <<attribute-syntax, Attribute Syntax>>. Here, source type corresponds to input type and target type corresponds to output type of the encoding. Keyword used in attribute `user` of port type definition: `encode` or `decode`; either followed by an optional `errorbehavior`.
+* Function or external function. The transformation rule may be described by an (external) function referenced by the mapping. The function must have the attribute `extension` specifying one of the prototypes given in section <<encoder-decoder-function-prototypes, Encoder/decoder Function Prototypes>>. The incoming and the outgoing type of the function must be equal to the source and target type of the mapping, respectively. The function may be written in TTCN-3, C++ or generated automatically by the compiler. This mapping does not have any options. Keyword used in attribute `user` of port type definition: `function`.
+
+==== Mapping with One Target
+
+Generally speaking, a source type may have one or more targets. Every mapping target can be used alone. However, only one target can be designated with the following rules if
+
+* no conversion takes place (keyword `simple`);
+* encoding a structured message (keyword `encode`) <<13-references.adoc#_17, [17]>>;
+* an (external) function with prototype `convert` or `fast` is invoked
+
+==== Mapping with More Targets
+
+On the other hand, more than one target is needed, when the type of an encoded message must be reconstructed. An octetstring, for example, can be decoded to a value of more than one structured PDU type. It is not necessary to specify mutually exclusive decoder rules. It is possible and useful to define a catch-all rule at the end to handle invalid messages.
+
+The following rules may be used with more than one target if
+
+* an (external) function with prototype `backtrack` is invoked;
+* decoding a structured message (keyword `decode`);
+* (as a last alternative) the source message is `discarded`
+
+The conversion rules are tried in the same order as given in the attribute until one of them succeeds, that is, the function returns `0 OK` or decoding is completed without any error. The outcome of the successful conversion will be the mapped result of the source message. If all conversion rules fail and the last alternative is `discard`, then the source message is discarded. Otherwise dynamic test case error occurs.
+
+==== Mapping from Sliding Buffer
+
+Using sliding buffers is necessary for example, if a stream-based transport, like TCP, is carrying the messages. A stream-based transport is destroying message boundaries: a message may be torn apart or subsequent messages may stick together.
+
+The following rules may be used with more than one target when there is a sliding buffer on the source side if
+
+* an (external) function with prototype `sliding` is invoked;
+* decoding a structured message (keyword `decode`)
+
+Above rules imply that the source type of this mapping be either `octetstring` or `charstring`. The run-time environment maintains a separate buffer for each connection of the dual-faced port. Whenever data arrives to the buffer, the conversion rules are applied on the buffer in the same order as given in the attribute. If one of the rules succeeds (that is, the function returns `0` or decoding is completed without any error) the outcome of the conversion will appear on the destination side. If the buffer still contains data after successful decoding, the conversion is attempted again to get the next message.If one of the rules indicates that the data in the buffer is insufficient to get an entire message (the function returns `2 INCOMPLETE_MESSAGE` or decoding fails with error code `ET_INCOMPL_MSG`), then the decoding is interrupted until the next fragment arrives in the buffer.If all conversion rules fail (the function returns `1 NOT_MY_TYPE` or decoding fails with any other error code than `ET_INCOMPL_MSG`), dynamic test case error occurs.
+
+[[encoder-decoder-function-prototypes]]
+=== Encoder/decoder Function Prototypes
+
+Encoder/decoder functions are used to convert between different data (message) structures. We can consider e.g. an octet string received from the remote system that should be passed to the upper layer as a TCP message.
+
+Prototypes are attributes governing data input/output rules and conversion result indication. In other words, prototypes are setting the data interface types. The compiler will verify that the parameters and return value correspond to the given prototype. Any TTCN–3 function (even external ones) may be defined with a prototype. There are four prototypes defined as follows:
+
+* prototype `convert`
++
+Functions of this prototype have one parameter (i.e. the data to be converted), which shall be an `in` value parameter, and the result is obtained in the return value of the function.
++
+Example:
+[source]
+----
+external function f_convert(in A param_ex) return B
+with { extension "prototype(convert)" }
+----
++
+The input data received in the parameter `param_ex` of type A is converted. The result returned is of type B.
+
+* prototype `fast`
++
+Functions of this prototype have one input parameter (the same as above) but the result is obtained in an `out` value parameter rather than in return value. Hence, a faster operation is possible as there is no need to copy the result if the target variable is passed to the function. The order of the parameters is fixed: the first one is always the input parameter and the last one is the output parameter.
++
+Example:
+[source]
+----
+external function f_fast(in A param_1, out B param_2)
+with { extension "prototype(fast)" }
+----
++
+The input data received in the parameter `param_1` of type A is converted. The resulting data of type B is contained in the output parameter `param_2` of type B.
+
+* prototype `backtrack`
++
+Functions of this prototype have the same data input/output structure as of prototype `fast`, but there is an additional integer value returned to indicate success or failure of the conversion process. In case of conversion failure the contents of the output parameter is undefined. These functions can only be used for decoding. The following return values are defined to indicate the outcome of the decoding operation:
++
+--
+** 0 (`OK`). Decoding was successful; the result is stored in the out parameter.
+
+** 1 (`NOT_MY_TYPE`). Decoding was unsuccessful because the input parameter does not contain a valid message of type `B`. The content of the out parameter is undefined.
+--
++
+Example:
+[source]
+----
+external function f_backtrack(in A param_1, out B param_2) return integer
+with { extension "prototype(backtrack)" }
+----
+
+The input data received in the parameter `param_1` of type A is converted. The resulting data of type B is contained in the output parameter `param_2` of type B. The function return value (an integer) indicates success or failure of the conversion process.
+
+* prototype `sliding`
++
+Functions of this prototype have the same behavior as the one of prototype backtrack, consequently, these functions can only be used for decoding. The difference is that there is no need for the input parameter to contain exactly one message: it may contain a fragment of a message or several concatenated messages stored in a FIFO buffer. The first parameter of the function is an `inout` value parameter, which is a reference to a buffer of type `octetstring` or `charstring`. The function attempts to recognize an entire message. It if succeeds, the message is removed from the beginning of the FIFO buffer, hence the name of this prototype: sliding (buffer). In case of failure the contents of the buffer remains unchanged. The return value indicates success or failure of the conversion process or insufficiency of input data as follows:
++
+--
+** 0 (`OK`). Decoding was successful; the result is stored in the out parameter. The decoded message was removed from the beginning of the inout parameter which is used as a sliding buffer.
+
+** 1 (`NOT_MY_TYPE`). Decoding was unsuccessful because the input parameter does not contain or start with a valid message of type B. The buffer (`inout` parameter) remains unchanged. The content of out parameter is undefined.
+
+** 2 (`INCOMPLETE_MESSAGE`). Decoding was unsuccessful because the input stream does not contain a complete message (i.e. the end of the message is missing). The input buffer (inout parameter) remains unchanged. The content of out parameter is undefined.
+--
++
+Example:
+[source]
+----
+external function f_sliding(inout A param_1, out B param_2) return integer
+with { extension "prototype(sliding)" }
+----
++
+The first portion of the input data received in the parameter `param_1` of type `A` is converted. The resulting data of type B is contained in the output parameter `param_2` of type `B`. The return value indicates the outcome of the conversion process.
+
+[[automatic-generation-of-encoder-decoder-functions]]
+=== Automatic Generation of Encoder/decoder Functions
+
+Encoding and decoding is performed by C++ external functions using the built-in codecs. These functions can be generated automatically by the complier. The present section deals with attributes governing the function generation.
+
+==== Input and Output Types
+
+Automatically generated encoder/decoder functions must have an attribute `prototype` assigned. If the encoder/decoder function has been written manually, only the attribute `prototype` may be given. Automatically generated encoder/decoder functions must have either the attribute `encode` or the attribute `decode`. In the case of encoding, the input type of the function must be the (structured) type to be encoded, which in turn must have the appropriate encoding attributes needed for the specified encoding method. The output type of the encoding procedure must be `octetstring` (BER, RAW, XER and JSON coding) or `charstring` (TEXT coding). In case of decoding the functions work the other way around: the input type is `octetstring` or `charstring` and the output type can be any (structured) type with appropriate encoding attributes.
+
+[[attribute-syntax]]
+==== Attribute Syntax
+
+The syntax of the `encode` and `decode` attributes is the following:
+
+[source]
+----
+("encode"|"decode") "("("RAW"|"BER"|"TEXT"|"XER"|"JSON") [":" <codec_options>] ")"
+----
+
+BER encoding can be applied only for ASN.1 types.
+
+The <`codec_options`> part specifies extra options for the particular codec. Currently it is applicable only in case of BER and XML encoding/decoding. The `codec_options` are copied transparently to the parameter list of the C++ encoder/decoder function call in the generated function body without checking the existence or correctness of the referenced symbols.
+
+Example of prototype `convert`, BER encoding and decoding (the PDU is an ASN.1 type):
+[source]
+----
+external function encode_PDU(in PDU pdu) return octetstring
+with { extension "prototype(convert) encode(BER:BER_ENCODE_DER)" }
+external function decode_PDU(in octetstring os) return PDU
+with { extension "prototype(convert) decode(BER:BER_ACCEPT_ALL)" }
+----
+
+Example of prototype `convert`, XML encoding and decoding (the PDU is a TTCN-3 type):
+[source]
+----
+external function encode_PDU(in PDU pdu) return octetstring
+with { extension "prototype(convert) encode(XER:XER_EXTENDED)" }
+external function decode_PDU(in octetstring os) return PDU
+with { extension "prototype(convert) decode(XER:XER_EXTENDED)" }
+----
+
+[[codec-error-handling]]
+==== Codec Error Handling
+
+The TITAN codec API has some well defined function calls that control the behavior of the codecs in various error situations during encoding and decoding. An error handling method is set for each possible error type. The default error handling method can be overridden by specifying the `errorbehavior` attribute:
+
+[source]
+----
+"errorbehavior" "(" <error_type> ":" <error_handling>
+{ "," <error_type> ":" <error_handling> } ")"
+----
+
+Possible error types and error handlings are defined in <<13-references.adoc#\_16, [16]>>, section "The common API". The value of `<error_type>` shall be a value of type `error_type_t` without the prefix `ET_`. The value of `<error_handling>` shall be a value of type `error_behavior_t` without the prefix `EB_`.
+
+The TTCN–3 attribute `errorbehavior(INCOMPL_ANY:ERROR)`, for example, will be mapped to the following C++ statement:
+[source]
+----
+TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_INCOMPL_ANY,
+  TTCN_EncDec::EB_ERROR);
+----
+
+When using the `backtrack` or `sliding` decoding functions, the default error behavior has to be changed in order to avoid a runtime error if the `in` or `inout` parameter does not contain a type we could decode. With this change an integer value is returned carrying the fault code. Without this change a dynamic test case error is generated. Example:
+
+[source]
+----
+external function decode_PDU(in octetstring os, out PDU pdu) return integer
+with {
+extension "prototype(backtrack)"
+extension "decode(BER:BER_ACCEPT_LONG|BER_ACCEPT_INDEFINITE)"
+extension "errorbehavior(ALL:WARNING)"
+}
+----
+
+=== Handling of encode and variant attributes
+
+The TITAN compiler offers two different ways of handling encoding-related attributes:
+
+* the new (standard compliant) handling method, and
+* the legacy handling method, for backward compatibility.
+
+==== New codec handling
+
+This method of handling `encode` and `variant` attributes is active by default. It supports many of the newer encoding-related features added to the TTCN-3 standard.
+
+Differences from the legacy method:
+
+* `encode` and `variant` attributes can be defined for types as described in the TTCN-3 standard (although the type restrictions for built-in codecs still apply);
+* a type can have multiple `encode` attributes (this provides the option to choose from multiple codecs, even user-defined ones, when encoding values of that type);
+* ASN.1 types automatically have `BER`, `JSON`, `PER` (see section <<PER-encoding, PER encoding and decoding through user defined functions>>), and XML (if the compiler option `-a` is set) encoding (they are treated as if they had the corresponding `encode` attributes);
+* encoding-specific `variant` attributes are supported(e.g.: `variant "XML"."untagged"`);
+* the parameters `encoding_info/decoding_info` and `dynamic_encoding` of predefined functions `encvalue`, `decvalue`, `encvalue_unichar` and `decvalue_unichar` are supported (the `dynamic_encoding` parameter can be used for choosing the codec to use for values of types with multiple encodings; the `encoding_info`/`decoding_info` parameters are currently ignored);
+* the `self.setencode` version of the `setencode` operation is supported (it can be used for choosing the codec to use for types with multiple encodings within the scope of the current component);
+* the `@local` modifier is supported for `encode` attributes;
+* a type’s the default codec (used by `decmatch` templates, the @decoded modifier, and the predefined functions `encvalue`, `decvalue`, `encvalue_unichar` and `decvalue_unichar` when no dynamic encoding parameter is given) is:
+* its one defined codec, if it has exactly one codec defined; or
+* unspecified, if it has multiple codecs defined (the mentioned methods of encoding/decoding can only be used in this case, if a codec was selected for the type using `self.setencode`).
+
+Differences from the TTCN-3 standard:
+
+* switching codecs during the encoding or decoding of a structure is currently not supported (the entire structure will be encoded or decoded using the codec used at top level);
+* the port-specific versions of the `setencode` operation are not supported (since messages sent through ports are not automatically encoded; see also dual-faced ports in section <<dual-faced-ports, Dual-faced Ports>>);
+* the `@local` modifier only affects encode attributes, it does not affect the other attribute types;
+* `encode` and `variant` attributes do not affect `constants`, `templates`, `variables`, `template` `variables` or `import` statements (these are accepted, but ignored by the compiler);
+* references to multiple definitions in attribute qualifiers is not supported(e.g.: `encode` (`template all except` (`t1`)) "`RAW`");
+* retrieving attribute values is not supported (e.g.: `var universal charstring x := MyType.encode`).
+
+[[legacy-codec-handling]]
+==== Legacy codec handling
+
+This is the method of handling encode and variant attributes that was used before version 6.3.0 (/6 R3A). It can be activated through the compiler command line option `-e`.
+
+Differences from the new method:
+
+* each codec has its own rules for defining `encode` and `variant` attributes;
+* a type can only have one `encode` attribute (if more than one is defined, then only the last one is considered), however, it can have `variant` attributes that belong to other codecs (this can make determining the default codec tricky);
+* ASN.1 types automatically have `BER`, `JSON`, `PER` (see section <<PER-encoding, PER encoding and decoding through user defined functions>>), and `XML` (if the compiler option -a is set) encoding, however the method of setting a default codec (for the predefined functions `encvalue`, `decvalue`, encvalue_unichar, `decvalue_unichar`, for `decmatch` templates, and for the `@decoded` modifier) is different (see section <<setting-the-default-codec-for-asn-1-types, Setting the default codec for ASN.1 types>>);
+* encoding-specific `variant` attributes are not supported(e.g.: `variant "XML"."untagged"`);
+* the parameters `encoding_info/decoding_info` and `dynamic_encoding` of predefined functions `encvalue`, `decvalue`, `encvalue_unichar` and `decvalue_unichar` are ignored;
+* the `setencode` operation is not supported;
+* the  @local` modifier is not supported.
+
+The differences from the TTCN-3 standard listed in the previous section also apply to the legacy method.
+
+[[setting-the-default-codec-for-asn-1-types]]
+===== Setting the default codec for ASN.1 types
+
+Since ASN.1 types cannot have `encode` or `variant` attributes, the compiler determines their encoding type by checking external encoder or decoder functions (of built-in encoding types) declared for the type.
+
+The TITAN runtime does not directly call these external functions, they simply indicate which encoding type to use when encoding or decoding the ASN.1 type in question through predefined functions `encvalue` and `decvalue`, decoded content matching (`decmatch` templates) and in value and parameter redirects with the `@decoded` modifier.
+
+These external functions can be declared with any prototype, and with the regular stream type of either `octetstring` or `charstring` (even though `encvalue` and `decvalue` have `bitstring` streams).
+
+The ASN.1 type cannot have several external encoder or decoded functions of different (built-in or PER) encoding types, as this way the compiler won’t know which encoding to use. Multiple encoder or decoder functions of the same encoding type can be declared for one type.
+
+NOTE: These requirements are only checked if there is at least one `encvalue`, `decvalue`, `decmatch` template or decoded parameter or value redirect in the compiled modules. They are also checked separately for encoding and decoding (meaning that, for example, multiple encoder functions do not cause an error if only `decvalues` are used in the modules and no `encvalues`). +
+The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the encvalue, decvalue, decmatch or @decoded is located).
+
+Example:
+[source]
+----
+external function f_enc_seq(in MyAsnSequenceType x) return octetstring
+with { extension "prototype(convert) encode(JSON)" }
+
+external function f_dec_seq(in octetstring x, out MyAsnSequenceType y)
+with { extension "prototype(fast) decode(JSON)" }
+
+…
+
+var MyAsnSequenceType v_seq := { num := 10, str := "abc" };
+var bitstring v_enc := encvalue(v_seq); // uses the JSON encoder
+
+var MyAsnSequenceType v_seq2;
+var integer v_result := decvalue(v_enc, v_seq2); // uses the JSON decoder
+----
+
+[[calling-user-defined-encoding-functions-with-encvalue-and-decvalue]]
+=== Calling user defined encoding functions with encvalue and decvalue
+
+The predefined functions `encvalue` and `decvalue` can be used to encode and decode values with user defined external functions (custom encoding and decoding functions).
+
+These functions must have the `encode`/`decode` and `prototype` extension attributes, similarly to built-in encoder and decoder functions, except the name of the encoding (the string specified in the `encode` or `decode` extension attribute) must not be equal to any of the built-in encoding names (e.g. BER, TEXT, XER, etc.).
+
+The compiler generates calls to these functions whenever `encvalue` or `decvalue` is called, or whenever a matching operation is performed on a `decmatch` template, or whenever a redirected value or parameter is decoded (with the `@decoded` modifier), if the value’s type has the same encoding as the encoder or decoder function (the string specified in the type’s `encode` attribute is equivalent to the string in the external function’s `encode` or `decode` extension attribute).
+
+Restrictions:
+
+* only one custom encoding and one custom decoding function can be declared per user-defined codec (only checked if `encvalue`, `decvalue`, `decmatch` or `@decoded` are used at least once on the type)
+* the prototype of custom encoding functions must be `convert`
+* the prototype of custom decoding functions must be `sliding`
+* the stream type of custom encoding and decoding functions is `bitstring`
+
+NOTE: Although theoretically variant attributes can be added for custom encoding types, their coding functions would not receive any information about them, so they would essentially be regarded as comments. If custom variant attributes are used, the variant attribute parser’s error level must be lowered to warnings with the compiler option `-E`. +
+The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the `encvalue`, `decvalue`, `decmatch` or `@decoded` is located; if this is the case, then an extra include statement is added in the generated C++ code to the header generated for the coder function’s module).
+
+Example:
+[source]
+----
+type union Value {
+  integer intVal,
+  octetstring byteVal,
+  charstring strVal
+  }
+with {
+  encode "abc";
+}
+
+external function f_enc_value(in Value x) return bitstring
+ with { extension "prototype(convert) encode(abc)" }
+
+external function f_dec_value(inout bitstring b, out Value x) return integer
+with { extension "prototype(sliding) decode(abc)" }
+
+…
+
+var Value x := { intVal := 3 };
+var bitstring bs := encvalue(x); // equivalent to f_enc_value(x)
+
+var integer res := decvalue(bs, x); // equivalent to f_dec_value(bs, x)
+----
+
+[[PER-encoding]]
+=== PER encoding and decoding through user defined functions
+
+TITAN does not have a built-in PER codec, but it does provide the means to call user defined PER encoder and decoder external functions when using `encvalue`, `decvalue`, `decmatch` templates, and value and parameter redirects with the `@decoded` modifier.
+
+This can be achieved the same way as the custom encoder and decoder functions described in section <<calling-user-defined-encoding-functions-with-encvalue-and-decvalue, Calling user defined encoding functions with encvalue and decvalue>>, except the name of the encoding (the string specified in the encode or decode extension attribute) must be PER.
+
+This can only be done for ASN.1 types, and has the same restrictions as the custom encoder and decoder functions. There is one extra restriction when using legacy codec handling (see section <<setting-the-default-codec-for-asn-1-types, Setting the default codec for ASN.1 types>>): an ASN.1 type cannot have both a PER encoder/decoder function and an encoder/decoder function of a built-in type set (this is checked separately for encoding and decoding).
+
+NOTE: The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the `encvalue`, `decvalue`, `decmatch` or `@decoded` is located; if this is the case, then an extra include statement is added in the generated C++ code to the header generated for the coder function’s module).
+
+Example:
+[source]
+----
+external function f_enc_per(in MyAsnSequenceType x) return bitstring
+with { extension "prototype(convert) encode(PER)" }
+
+external function f_dec_per(in bitstring x, out MyAsnSequenceType y)
+with { extension "prototype(fast) decode(PER)" }
+
+…
+
+var MyAsnSequenceType x := { num := 10, str := "abc" };
+var bitstring bs := encvalue(x); // equivalent to f_enc_per(x)
+
+var MyAsnSequenceType y;
+var integer res := decvalue(bs, y); // equivalent to f_dec_per(bs, y);
+----
+
+=== Common Syntax of Attributes
+
+All information related to implicit message encoding shall be given as `extension` attributes of the relevant TTCN–3 definitions. The attributes have a common basic syntax, which is applicable to all attributes given in this section:
+
+* Whitespace characters (spaces, tabulators, newlines, etc.) and TTCN–3 comments are allowed anywhere in the attribute text. Attributes containing only comments, whitespace or both are simply ignored +
+Example: +
+`with { extension “/* this is a comment */" }`
+* When a definition has multiple attributes, the attributes can be given either in one attribute text separated by whitespace or in separate TTCN–3 attributes. +
+Example: +
+`with { extension "address provider" }` means exactly the same as +
+`with { extension "address"; extension "provider" }`
+* Settings for a single attribute, however, cannot be split in several TTCN–3 attributes. +
+Example of an invalid attribute: +
+`with { extension "prototype("; extension "convert)" }`
+* Each kind of attribute can be given at most once for a definition. +
+Example of an invalid attribute: +
+`with { extension "internal internal" }`
+* The order of attributes is not relevant. +
+Example: +
+`with { extension "prototype(fast) encode(RAW)" }` means exactly the same as +
+`with { extension "encode(RAW) prototype(fast)" }`
+* The keywords introduced in this section, which are not TTCN–3 keywords, are not reserved words. The compiler will recognize the word properly if it has a different meaning (e.g. the name of a type) in the given context. +
+Example: the attribute +
+`with { extension "user provider in(internal -> simple: function(prototype))" }` can be a valid if there is a port type named `provider`; `internal` and `simple` are message types and `prototype` is the name of a function.
+
+=== API describing External Interfaces
+
+Since the default class hierarchy of test ports does not allow sharing of C++ code with other port types, an alternate internal API is introduced for port types describing external interfaces. This alternate internal API is selected by giving the appropriate TTCN–3 extension attribute to the port. The following extension attributes or attribute combinations can be used:
+
+.Port extension attributes
+[cols=",,,,,",options="header",]
+|===
+|*Attribute(s)* |*Test Port* |*Communication with SUT allowed* |*Using of SUT addresses allowed* |*External interface* |*Notes*
+|nothing |normal |yes |no |own |
+|internal |none |no |no |own |
+|address |see <<13-references.adoc#_16, [16]>> "Support of address type" |yes |yes |own |
+|provider |see <<13-references.adoc#_16, [16]>> "Provider port types" |yes |no |own |
+|internal provider |none |no |no |own |means the same as internal
+|address provider |see <<13-references.adoc#_16, [16]>> "Support of address type" and "Provider port types" |yes |yes |own |
+|user PT … |none |yes |depends on PT |PT |PT must have attribute provider
+|internal user PT … |none |no |no |PT |PT can have any attributes
+|address user PT … |none |yes |yes |PT |PT must have attributes address and provider
+|===
+
+=== BNF Syntax of Attributes
+
+[source]
+----
+FunctionAttributes ::= {FunctionAttribute}
+FunctionAttribute ::= PrototypeAttribute | TransparentAttribute
+
+ExternalFunctionAttributes ::= {ExternalFunctionAttribute}
+ExternalFunctionAttribute ::= PrototypeAttribute | EncodeAttribute | DecodeAttribute | ErrorBehaviorAttribute
+
+PortTypeAttributes ::= {PortTypeAttribute}
+PortTypeAttribute ::= InternalAttribute | AddressAttribute | ProviderAttribute | UserAttribute
+
+PrototypeAttribute ::= "prototype" "(" PrototypeSetting ")"
+PrototypeSetting ::= "convert" | "fast" | "backtrack" | "sliding"
+
+TransparentAttribute ::= "transparent"
+
+EncodeAttribute ::= "encode" "(" EncodingType [":" EncodingOptions] ")"
+EncodingType ::= "BER" | "RAW" | "TEXT"| "XER" | "JSON"
+EncodingOptions ::= {ExtendedAlphaNum}
+
+DecodeAttribute ::= "decode" "(" EncodingType [":" EncodingOptions] ")"
+
+ErrorBehaviorAttribute ::= "errorbehavior" "(" ErrorBehaviorSetting {"," ErrorBehaviorSetting} ")"
+ErrorBehaviorSetting ::= ErrorType ":" ErrorHandling
+ErrorType ::= ErrorTypeIdentifier | "ALL"
+ErrorHandling ::= "DEFAULT" | "ERROR" | "WARNING" | "IGNORE"
+
+InternalAttribute ::= "internal"
+
+AddressAttribute ::= "address"
+
+ProviderAttribute ::= "provider"
+
+UserAttribute ::= "user" PortTypeReference {InOutTypeMapping}
+PortTypeReference ::= [ModuleIdentifier "."] PortTypeIdentifier
+InOutTypeMapping ::= ("in" | "out") "(" TypeMapping {";" TypeMapping} ")"
+TypeMapping ::= MessageType "->" TypeMappingTarget {"," TypeMappingTarget}
+TypeMappingTarget ::= (MessageType ":" (SimpleMapping | FunctionMapping | EncodeMapping | DecodeMapping)) | ("-" ":" DiscardMapping)
+
+MessageType ::= PredefinedType | ReferencedMessageType
+ReferencedMessageType ::= [ModuleIdentifier "."] (StructTypeIdentifier | EnumTypeIdentifier | SubTypeIdentifier | ComponentTypeIdentifier)
+
+SimpleMapping ::= "simple"
+
+FunctionMapping ::= "function" "(" FunctionReference ")"
+FunctionReference ::= [ModuleIdentifier "."] (FunctionIdentifier | ExtFunctionIdentifier)
+
+EncodeMapping ::= EncodeAttribute [ErrorBehaviorAttribute]
+
+DecodeMapping ::= DecodeAttribute [ErrorBehaviorAttribute]
+
+DiscardMapping ::= "discard"
+----
+
+Non-terminal symbols in bold are references to the BNF of the TTCN-3 Core Language (Annex A, <<13-references.adoc#_1, [1]>>)
+
+Example:
+[source]
+----
+type record ControlRequest { }
+type record ControlResponse { }
+type record PDUType1 { }
+type record PDUType2 { }
+// the encoder/decoder functions are written in C++
+external function enc_PDUType1(in PDUType1 par) return octetstring
+with { extension "prototype(convert)" }
+external function dec_PDUType1(in octetstring stream,
+out PDUType1 result) return integer
+with { extension "prototype(backtrack)" }
+
+// port type PT1 is the external interface of the dual-faced port
+// with its own Test Port. See section "The purpose of Test Ports" in the API guide.
+
+type port PT1 message {
+out ControlRequest;
+in ControlResponse;
+inout octetstring;
+} with { extension "provider" }
+
+// port type PT2 is the internal interface of the dual-faced port
+// This port is communicating directly with the SUT using the Test Port of PT1.
+
+type port PT2 message {
+out ControlRequest;
+inout PDUType1, PDUType2;
+} with { extension “user PT1
+
+out(ControlRequest -> ControlRequest: simple;
+PDUType1 -> octetstring: function(enc_PDUType1);
+PDUType2 -> octetstring: encode(RAW))
+in(ControlResponse -> - : discard;
+octetstring -> PDUType1: function(dec_PDUType1),
+
+PDUType2: decode(RAW),
+* : discard)"
+}
+
+type component MTC_CT {
+port PT2 MTC_PORT;
+}
+
+type component SYSTEM_SCT {
+port PT1 SYSTEM_PORT;
+}
+testcase tc_DUALFACED () runs on MTC_CT system SYSTEM_SCT
+
+{
+map(mtc:MTC_PORT, system:SYSTEM_PORT);
+MTC_PORT.send(PDUType1:{…});
+MTC_PORT.receive(PDUType1:?);
+}
+----
+
+The external face of the dual-faced port (defined by `PT1`) sends and receives the protocol massages as octetstrings. On the internal face of the same dual-faced port (defined by `PT2`) the octetstring is converted to two message types (`PDUType1`, `PDUType2`). The conversion happens both when sending and when receiving messages.
+
+When sending messages, messages of type `PDUType1` will be converted as defined by the function `enc_PDUType1`; whereas messages of type `PDUType2` will be converted using the built-in conversion rules RAW.
+
+When a piece of octetstring is received, decoding will first be attempted using the function `dec_PDUType1`; in successful case the resulting structured type has `PDUType1`. When decoding using the function `dec_PDUType1` is unsuccessful, the octetstring is decoded using the built-in conversion rules RAW; the resulting message is of type `PDUType2`. When none of the above conversion succeeds, the octetstring will be discarded.
+
+`ControlRequest` and `ControlResponse` will not be affected by a conversion in either direction.
+
+image::images/dualfaced.png[Dual-faced port]
+
+== RAW Encoder and Decoder
+
+The RAW encoder and decoder are general purpose functionalities developed originally for handling legacy protocols.
+
+The encoder converts abstract TTCN-3 structures (or types) into a bitstream suitable for serial transmission.
+
+The decoder, on the contrary, converts the received bitstream into values of abstract TTCN-3 structures.
+
+This section covers the <<general-rules-and-restrictions, coding rules in general>>, the <<attributes, attributes controlling them>> and the <<ttcn-3-types-and-their-attributes, attributes allowed for a particular type>>.
+
+You can use the encoding rules defined in this section to encode and decode the following TTCN–3 types:
+
+* bitstring
+* boolean
+* charstring
+* enumerated
+* float
+* hexstring
+* integer
+* octetstring
+* record
+* record of, set of
+* set
+* union
+* universal charstring
+
+The compiler will produce code capable of RAW encoding/decoding if
+
+. The module has attribute 'encode "RAW", in other words at the end of the module there is a text +
+`with { encode "RAW" }`
+
+. Compound types have at least one `variant` attribute. When a compound type is only used internally or it is never RAW encoded/decoded then the attribute `variant` has to be omitted.
+
+[NOTE]
+====
+When a type can be RAW encoded/decoded but with default specification then the empty variant specification can be used: variant "". +
+In order to reduce the code size the TITAN compiler only add the RAW encoding if
+
+a. Either the type has a RAW variant attribute OR +
+b. The type is used by an upper level type definition with RAW variant attribute.
+====
+
+Example: In this minimal introductory example there are two types to be RAW encoded: OCT2 and CX_Frame but only the one of them has RAW variant attribute.
+[source]
+----
+module Frame {
+external function enc_CX_frame( in CX_Frame cx_message ) return octetstring
+with { extension "prototype(convert) encode(RAW)" }
+
+external function dec_CX_frame( in octetstring stream ) return CX_Frame
+with { extension "prototype(convert) decode(RAW)" }
+
+type octetstring OCT2 length(2);
+type record CX_Frame
+
+{
+OCT2 data_length,
+octetstring data_stream
+} with { variant "" }
+} with { encode "RAW" }
+----
+
+[[general-rules-and-restrictions]]
+=== General Rules and Restrictions
+
+The TTCN-3 standard defines a mechanism using `attributes` to define, among others, encoding variants (see <<13-references.adoc#_1, [1]>>, chapter 27 "Specifying attributes"). However, the `attributes` to be defined are implementation specific. This and the following chapters describe each `attribute` available in TITAN.
+
+==== General Rules
+
+If an `attribute` can be assigned to a given type, it can also almost always be assigned to the same type of fields in a `record`, set or `union`. Attributes belonging to a `record` or `set` field overwrites the effect of the same attributes specified for the type of the field.
+
+The location of an attribute is evaluated before the attribute itself. This means that if an attribute is overwritten thanks to its qualification or the overwriting rules, or both, its validity at the given location will not be checked.
+
+It is not recommended to use the attributes `LENGTHTO`, `LENGTHINDEX`, `TAG`, `CROSSTAG`, `PRESENCE`, `UNIT`, `POINTERTO`, `PTROFFSET` with dotted qualifiers as it may lead to confusion.
+
+Octetstrings and records with extension bit shall be octet aligned. That is, they should start and end in octet boundary.
+
+Error encountered during the encoding or decoding process are handled as defined in section "Setting error behavior" in <<13-references.adoc#_16, [16]>>.
+
+=== Rules Concerning the Encoder
+
+The encoder doesn’t modify the data to be encoded; instead, it substitutes the value of calculated fields (`length`, `pointer`, `tag`, `crosstag` and `presence` fields) with the calculated value in the encoded bitfield if necessary.
+
+The value of the `pointer` and `length` fields are calculated during encoding and the resulting value will be used in sending operations. During decoding, the decoder uses the received length and pointer information to determine the length and the place of the fields.
+
+During encoding, the encoder sets the value of the `presence`, `tag` and `crosstag` fields according to the presence of the `optional` and `union` fields.
+
+=== Rule Concerning the Decoder
+
+The decoder determines the presence of the optional fields on the basis of the value of the `tag`, `crosstag` and `presence` fields.
+
+[[attributes]]
+=== Attributes
+
+An `attribute` determines coding and encoding rules. In this section the `attributes` are grouped according to their function.
+
+==== Attributes Governing Conversion of TTCN-3 Types into Bitfields
+
+This section defines the attributes describing how a TTCN-3 type is converted to a bitfield.
+
+*BITORDERINFIELD*
+
+Attribute syntax: `BITORDERINFIELD(<parameter>)`
+
+Parameters allowed: `msb`, `lsb`
+
+Default value: `lsb`
+
+Can be used with: stand-alone types, or a field of a `record` or `set`.
+
+Description: This attribute specifies the order of the bits within a field. When set to `msb`, the first bit sent will be the most significant bit of the original field. When set to `lsb`, the first bit sent will be the least significant bit of the original field.
+
+Comment: The effect of `BITORDERINFIELD(msb)` is equal to the effect of `BITORDER(msb) BYTORDER(last)`.
+
+Example:
+[source]
+----
+type bitstring BITn
+with {
+variant "BITORDERINFIELD(lsb)"
+}
+
+const BITn c_bits := ’10010110’B
+//Encoding of c_bits gives the following result: 10010110
+
+type bitstring BITnreverse
+with {
+variant "BITORDERINFIELD(msb)"
+}
+
+const BITnreverse c_bitsrev := ’10010110’B
+//Encoding of c_bitsrev gives the following result: 01101001
+----
+
+*COMP*
+
+Attribute syntax: `COMP(<parameter>)`
+
+Parameters allowed: `nosign`, `2scompl`, `signbit`
+
+Default value: `nosign`
+
+Can be used with: stand-alone types or the field of a `record` or `set`.
+
+Description: This attribute specifies the type of encoding of negative integer numbers as follows: +
+`nosign`: negative numbers are not allowed; +
+`2scompl`: 2’s complement encoding; +
+`signbit`: sign bit and the absolute value is coded. (Only with integer and enumerated types.)
+
+Examples:
+[source]
+----
+//Example number 1): coding with sign bit
+type integer INT1
+with {
+variant "COMP(signbit)";
+variant "FIELDLENGTH(8)"
+}
+
+const INT1 c_i := -1
+//Encoded c_i: 10000001 ’81’O
+// sign bitˆ
+//Example number 2): two's complement coding
+type integer INT2 with {variant "COMP(2scompl)";
+variant "FIELDLENGTH(8)"
+}
+
+const INT2 c_i2 := -1
+//Encoded c_i2: 11111111 ’FF’O
+----
+
+*FIELDLENGTH*
+
+Attribute syntax: `FIELDLENGTH(<parameter>)`
+
+Parameters allowed: `variable`, `null_terminated` (for `charstrin` and universal `charstring` types only) positive integer
+
+Default value: `variable`, 8 (for `integer` type only)
+
+Can be used with:
+
+* `integer`;
+* `enumerated`;
+* `octetstring`;
+* `charstring`;
+* `bitstring`;
+* `hexstring`;
+* `universal charstring`;
+* `record` fields;
+* `set` fields;
+* `record of` types;
+* `set of` types.
+
+Description: `FIELDLENGTH` specifies the length of the encoded type. The units of the parameter value for specific types are the following:
+
+* `integer, enumerated, bitstring:` bits;
+* `octetstring, universal charstring:` octets;
+* `charstring:` characters;
+* `hexstring:` hex digits;
+* `set of/record of:` elements.
+
+The value 0 means variable length or, in case of the enumerated type, the minimum number of bits required to display the maximum `enumerated` value. `Integer` cannot be coded with variable length.
+
+NOTE: If `FIELDLENGTH` is not specified, but a TTCN–3 length restriction with a fixed length is, then the restricted length will be used as `FIELDLENGTH`.
+
+Examples:
+[source]
+----
+//Example number 1): variable length octetstring
+type octetstring OCTn
+with {
+variant "FIELDLENGTH(variable)"
+}
+
+//Example number 2): 22 bit length bitstrings
+type bitstring BIT22
+with {
+variant "FIELDLENGTH(22)"
+}
+
+type record SomeRecord {
+bitstring field
+}
+
+with {
+variant (field) "FIELDLENGTH(22)"
+}
+
+// Null terminated strings
+type charstring null_str with {variant "FIELDLENGTH(null_terminated)"}
+type universal charstring null_ustr with { variant "FIELDLENGTH(null_terminated)"}
+----
+
+*N bit / unsigned N bit*
+
+Attribute syntax: `[unsigned] <parameter> bit`
+
+Parameters allowed: positive integer
+
+Default value: -
+
+Can be used with:
+
+* `integer`;
+* `enumerated`;
+* `octetstring`;
+* `charstring`;
+* `bitstring`;
+* `hexstring`;
+* `record` fields;
+* `set` fields.
+
+Description: This attribute sets the `FIELDLENGTH`, `BYTEORDER` and `COMP` attributes to the following values:
+
+* `BYTEORDER` is set to `last`.
+* `N bit` sets `COMP` to `signbit`, while `unsigned` `N` `bit` sets `COMP` to `nosign` (its default value).
+* Depending on the encoded value’s type `FIELDLENGTH` is set to: +
+`integer, enumerated, bitstring, boolean:` N; +
+`octetstring, charstring:` N / 8; +
+`hexstring:` N / 4.
+
+NOTE: If `FIELDLENGTH` is not specified, but a TTCN–3 length restriction with a fixed length is, then the restricted length will be used as `FIELDLENGTH`.
+
+The `[unsigned] <parameter> bits` syntax is also supported but the usage of `bit` keyword is preferred.
+
+Examples:
+[source]
+----
+//Example number 1): integer types
+type integer Short (-32768 .. 32767)
+with { variant "16 bit" };
+
+// is equal to:
+type integer ShortEq (-32768 .. 32767)
+with { variant "FIELDLENGTH(16), COMP(signbit), BYTEORDER(last)" };
+
+type integer UnsignedLong (0 .. 4294967295)
+with { variant "unsigned 32 bit" };
+
+// is equal to:
+type integer UnsignedLongEq (0 .. 4294967295)
+with { variant "FIELDLENGTH(32), COMP(nosign), BYTEORDER(last)" };
+
+//Example number 2): string types
+type hexstring HStr20
+with { variant "unsigned 20 bit" };
+
+// 20 bits = 5 hex nibbles, `unsigned' is ignored
+type hexstring HStr20Eq
+with { variant "FIELDLENGTH(5), BYTEORDER(last)" };
+
+type octetstring OStr32
+with { variant "32 bit" };
+
+// 32 bits = 4 octets
+type octetstring OStr32Eq
+with { variant "FIELDLENGTH(4), BYTEORDER(last)" };
+
+type charstring CStr64 with
+{ variant "64 bit" };
+
+// 64 bits = 8 characters
+type charstring CStr64Eq
+with { variant "FIELDLENGTH(8), BYTEORDER(last)" };
+----
+
+*FORMAT*
+
+Attribute syntax: `FORMAT(<parameter>)`
+
+Parameters allowed: `IEEE754 double`, `IEEE754 float`
+
+Default value: `IEEE754 double`
+
+Can be used with: `float` type.
+
+Description: `FORMAT` specifies the encoding format of `float` values. +
+`IEEE754 double:` The `float` value is encoded as specified in standard IEEE754 using 1 sign bit, 11 exponent bits and 52 bits for mantissa. +
+`IEEE754 float:` The `float` value is encoded as specified in standard IEEE754 using 1 sign bit, 8 exponent bits and 23 bits for mantissa.
+
+Examples:
+[source]
+----
+//Example number 1): single precision float
+type float Single_float
+with {
+variant "FORMAT(IEEE754 float)"
+}
+
+//Example number 2): double precision float
+type float Double_float
+with {
+variant "FORMAT(IEEE754 double)"
+}
+----
+
+==== Attributes Controlling Conversion of Bitfields into a Bitstream
+
+This section defines the attributes describing how bits and octets are put into the buffer.
+
+*BITORDER*
+
+Attribute syntax: `BITORDER(<parameter>)`
+
+Parameters allowed: `msb`, `lsb`
+
+Default value: `lsb`
+
+Can be used with: stand-alone types or the field of a `record` or `set`.
+
+Description: This attribute specifies the order of the bits within an octet. When set to `lsb`, the first bit sent will be the least significant bit of the original byte. When set to `msb`, the first bit sent will be the most significant bit of the original byte. When applied to an `octetstring` using the extension bit mechanism, only the least significant 7 bits are reversed, the 8th bit is reserved for the extension bit.
+
+Examples:
+[source]
+----
+// Example number 1)
+type octetstring OCT
+with {
+variant "BITORDER(lsb)"
+}
+
+const OCT c_oct := ’123456’O
+
+//The encoded bitfield: 01010110 00110100 00010010
+// last octet^ ^first octet
+// The buffer will have the following content:
+// 00010010
+// 00110100
+// 01010110
+
+//The encoding result in the octetstring ’123456’O
+
+//Example number 2)
+type octetstring OCTrev
+with {
+variant "BITORDER(msb)"
+}
+
+const OCTrev c_octr := ’123456’O
+
+//The encoded bitfield: 01010110 00110100 00010010
+
+// last octet^ ^first octet
+
+//The buffer will have the following content:
+// 01001000
+// 00101100
+// 01101010
+
+//The encoding results in the octetstring ’482C6A’O
+
+//Example number 3)
+
+type bitstring BIT12 with {
+variant "BITORDER(lsb), FIELDLENGTH(12)"
+}
+
+const BIT12 c_bits:=’101101101010’B
+//The encoded bitfield: 1011 01101010
+
+// last octet^ ^first octet
+
+The buffer will have the following content:
+// 01101010
+// ….1011
+// ^ next field
+
+//The encoding will result in the octetstring ’6A.9’O
+
+//Example number 4)
+type bitstring BIT12rev with {
+variant "BITORDER(msb), FIELDLENGTH(12)"
+}
+
+const BIT12 c_BIT12rev:=’101101101010’B
+//The encoded bitfield: 1011 01101010
+// last octet^ ^first octet
+//The buffer will have the following content:
+// 01010110
+// ….1101
+// ^ next field
+//The encoding will result in the octetstring ’56.D’O
+----
+
+*BYTEORDER*
+
+Attribute syntax: `BYTEORDER(<parameter>)`
+
+Parameters allowed: `first`, `last`
+
+Default value: `first`
+
+Can be used with: stand-alone types or the field of a `record` or `set`.
+
+Description: The attribute determines the order of the bytes in the encoded data.
+
+* `first`: The first octet placed first into the buffer.
+* `last`: The last octet placed first into the buffer.
+
+Comment: The attribute has no effect on a single octet field.
+
+NOTE: The attribute works differently for `octetstring` and `integer` types. The ordering of bytes is counted from left-to-right (starting from the MSB) in an `octetstring` but right-to-left (starting from the LSB) in an `integer`. Thus, the attribute `BYTEORDER(first)` for an `octetstring` results the same encoded value than `BYTEORDER(last)` for an `integer` having the same value.
+
+Examples:
+[source]
+----
+//Example number 1)
+type octetstring OCT
+with {
+variant "BYTEORDER(first)"
+}
+
+const OCT c_oct := ’123456’O
+//The encoded bitfield: 01010110 00110100 00010010
+// last octet^ ^first octet
+
+The buffer will have the following content:
+// 00010010
+// 00110100
+// 01010110
+
+//The encoding will result in the octetstring ’123456’O
+
+//Example number 2)
+type octetstring OCTrev
+with {variant "BYTEORDER(last)"
+}
+
+const OCTrev c_octr := ’123456’O
+//The encoded bitfield: 01010110 00110100 00010010
+// last octet^ ^first octet
+
+//The buffer will have the following content:
+
+// 01010110
+
+// 00110100
+
+// 00010010
+
+The encoding will result in the octetstring ’563412’O
+//Example number 3)
+type bitstring BIT12 with {
+variant "BYTEORDER(first), FIELDLENGTH(12)"
+}
+
+const BIT12 c_bits:=’100101101010’B
+//The encoded bitfield: 1001 01101010
+// last octet^ ^first octet
+The buffer will have the following content:
+// 01101010
+// ….1001
+// ^ next field
+
+//The encoding will result in the octetstring ’6A.9’O
+//Example number 4)
+type bitstring BIT12rev with {
+variant "BYTEORDER(last), FIELDLENGTH(12)"
+}
+
+const BIT12rev c_bits:=’100101101010’B
+//The encoded bitfield: 1001 01101010
+// last octet^ ^first octet
+//The buffer will have the following content:
+// 10010110
+// ….1010
+// ^ next field
+//The encoding will result in the octetstring ’96.A’O
+
+----
+
+*FIELDORDER*
+
+Attribute syntax: `FIELDORDER(<parameter>)`
+
+Parameters allowed: `msb`, `lsb`
+
+Default value: `lsb`
+
+Can be used with: `record` or `set` types. It can also be assigned to a group of fields of a `record`.
+
+Description: The attribute specifies the order in which consecutive fields of a structured type are placed into octets.
+* `msb:` coded bitfields are concatenated within an octet starting from MSB, when a field stretches the octet boundary, it continues at the MSB of next the octet.
+* `lsb:` coded bitfields are concatenated within an octet starting from LSB, when a field stretches the octet boundary, it continues at the LSB of next the octet.
+
+Comment: Fields within an octet must be coded with the same `FIELDORDER`. +
+Fields are always concatenated in increasing octet number direction. +
+`FIELDORDER` has a slightly different effect than order attributes. While the `FIELDORDER` shifts the location of coded bitfields inside octets, the order attributes describes the order of the bits within a bitfield. +
+There is NO connection between the effect of the `FIELDORDER` and the effects of the other order attributes.
+
+Examples:
+[source]
+----
+//Example number 1)
+type record MyRec_lsb {
+BIT1 field1,
+BIT2 field2,
+BIT3 field3,
+BIT4 field4,
+BIT6 field5
+}
+
+with { variant "FIELDORDER(lsb)" }
+const MyRec_lsb c_pdu := {
+field1:=’1’B // bits of field1: a
+field2:=’00’B // bits of field2: b
+field3:=’111’B // bits of field3: c
+field4:=’0000’B // bits of field4: d
+field5:=’111111’B // bits of field5: e
+}
+
+//Encoding of c_pdu will result in:
+// 00111001 ddcccbba
+// 11111100 eeeeeedd
+//Example number 2)
+
+type record MyRec_msb {
+BIT1 field1,
+BIT2 field2,
+BIT3 field3,
+BIT4 field4,
+BIT6 field5
+}
+
+with { variant "FIELDORDER(msb)" }
+const MyRec_msb c_pdu2 := {
+field1:=’1’B // bits of field1: a
+field2:=’00’B // bits of field2: b
+field3:=’111’B // bits of field3: c
+field4:=’0000’B // bits of field4: d
+field5:=’111111’B // bits of field5: e
+}
+
+//Encoding of c_pdu2 will result in:
+// 10011100 abbcccdd
+// 00111111 ddeeeeee
+----
+
+*HEXORDER*
+
+Attribute syntax: `HEXORDER(<parameter>)`
+
+Parameters allowed: `low`, `high`
+
+Default value: `low`
+
+Can be used with: `hexstring` or `octetstring` type.
+
+Description: Order of the hexs in the encoded data.
+* `low:` The hex digit in the lower nibble of the octet is put in the lower nibble of the octet in the buffer.
+* `high:` The hex digit in the higher nibble of the octet is put in the lower nibble of the octet in the buffer. (The value is swapped)
+
+NOTE: Only the whole octet is swapped if necessary. For more details see the example.
+
+Examples:
+[source]
+----
+//Example number 1)
+type hexstring HEX_high
+with {variant "HEXORDER(high)"}
+
+const HEX_high c_hexs := ’12345’H
+//The encoded bitfield: 0101 00110100 00010010
+// last octet^ ^first octet
+
+//The buffer will have the following content:
+// 00010010 12
+// 00110100 34
+// ….0101 .5
+// ^ next field
+//The encoding will result in the octetstring ’1234.5’O
+
+//Example number 2)
+type hexstring HEX_low
+with {variant "HEXORDER(low)"}
+const HEX_low c_hexl := ’12345’H
+
+//The encoded bitfield: 0101 00110100 00010010
+// last octet^ ^first octet
+//The buffer will have the following content:
+// 00100001 21
+// 01000011 43
+// ….0101 .5 ←not twisted!
+// ^ next field
+//The encoding will result in the octetstring ’2143.5’O
+
+//Example number 3)
+type octetstring OCT
+with {variant "HEXORDER(high)"}
+
+const OCT c_hocts := ’1234’O
+//The encoded bitfield: 00110100 00010010
+// last octet^ ^first octet
+//The buffer will have the following content:
+// 00100001 21
+// 01000011 43
+//The encoding will result in the octetstring ’2143’O
+----
+
+==== Extension Bit Setting Attributes
+
+This section defines the attributes describing the extension bit mechanism.
+
+The extension bit mechanism allows the size of an Information Element (IE) to be increased by using the most significant bit (MSB, bit 7) of an octet as an extension bit. When an octet within an IE has bit 7 defined as an extension bit, then the value `0' in that bit position indicates that the following octet is an extension of the current octet. When the value is `1', the octet is not continued.
+
+*EXTENSION_BIT*
+
+Attribute syntax: `EXTENSION_BIT(<parameter>)`
+
+Parameters allowed: `no`, `yes`, `reverse`
+
+Default value: none
+
+Can be used with:
+
+* `octetstring`,
+* (fields of a) `record`,
+* `set`,
+* `record of`,
+* `set of`.
+
+Description: When `EXTENSION_BIT` is set to `yes`, then each MSB is set to 0 except the last one which is set to 1. When `EXTENSION_BIT` is set to `reverse`, then each MSB is set to 1 and the MSB of the last octet is set to 0 to indicate the end of the Information Element. When `EXTENSION_BIT` is set to `no`, then no changes are made to the MSBs.
+
+NOTE: In case of the types `record` of and `set of` the last bit of the element of the structured type will be used as `EXTENSION_BIT`. The data in the MSBs will be overwritten during the encoding. When `EXTENSION_BIT` belongs to a record, the field containing the `EXTENSION_BIT` must explicitly be declared in the type definition. Also the last bit of the element of `record of` and `set of` type shall be reserved for `EXTENSION_BIT` in the type definition.
+
+Examples:
+[source]
+----
+//Example number 1)
+octetstring OCTn
+with {variant "EXTENSION_BIT(reverse)"}
+const OCTn c_octs:=’586211’O
+
+//The encoding will have the following result:
+// 11011000
+// 11100010
+// 00010001
+// ˆ the overwritten EXTENSION_BITs
+
+//The encoding will result in the octetstring ’D8E211’O
+//Example number 2)
+
+type record Rec3 {
+BIT7 field1,
+BIT1 extbit1,
+BIT7 field2 optional,
+BIT1 extbit2 optional
+}
+
+with { variant "EXTENSION_BIT(yes)" }
+const Rec3 c_MyRec{
+field1:=’1000001’B,
+extbit1:=’1’B,
+field2:=’1011101’B,
+extbit2:=’0’B
+}
+
+//The encoding will have the following result:
+// 01000001
+// 11011101
+// ˆ the overwritten EXTENSION_BITs
+
+The encoding will result in the octetstring ’41DD’O
+
+//Example number 3)
+type record Rec4{
+BIT11 field1,
+BIT1 extbit
+}
+
+type record of Rec4 RecList
+with { variant "EXTENSION_BIT(yes)"}
+const RecList c_recs{
+{ field1:=’10010011011’B, extbit:=’1’B}
+{ field1:=’11010111010’B, extbit:=’0’B}
+}
+
+//The encoding will have the following result:
+// 10011011
+// 10100100
+// 11101011
+// ˆ the overwritten EXTENSION_BITs
+
+//The encoding will result in the octetstring ’9BA4EB’O
+----
+
+*EXTENSION_BIT_GROUP*
+
+Attribute syntax: `EXTENSION_BIT_GROUP(<param1, param2, param3>)`
+
+Parameters allowed: `param1: no, yes, reverse` +
+                    `param2: first_field_name`, +
+                    `param3: last_field_name`
+
+Default value: none
+
+Can be used with: a group of `record` fields
+
+Description: The `EXTENSION_BIT_GROUP` limits the extension bit mechanism to a group of the fields of a `record` instead of the whole `record`. +
+`first_field_name`: the name of the first field in the +
+`grouplast_field_name`: the name of the last field in the group
+
+NOTE: Multiple group definition is allowed to define more groups within one `record`. Every group must be octet aligned and the groups must not overlap.
+
+Example:
+[source]
+----
+type record MyPDU{
+OCT1 header,
+BIT7 octet2info,
+BIT1 extbit1,
+BIT7 octet2ainfo optional,
+BIT1 extbit2 optional,
+OCT1 octet3,
+BIT7 octet4info,
+BIT1 extbit3,
+BIT7 octet4ainfo optional,
+BIT1 extbit4 optional,
+} with {
+variant "EXTENSION_BIT_GROUP(yes,octet2info,extbit2)";
+variant "EXTENSION_BIT_GROUP(yes,octet4info,extbit4)"
+}
+
+const MyPDU c_pdu:={
+header:=’0F’O,
+octet2info:=’1011011’B,
+extbit1:= ’0’B,
+octet2ainfo:= omit,
+extbit2:= omit,
+octet3:=’00’O,
+octet4info:=’0110001’B,
+extbit3:=’1’B,
+octet4ainfo:=’0011100’B,
+extbit4:=’0’B,
+}
+
+//The encoding will have the following result:
+// 00001111
+// **1**1011011
+// 00000000
+// **0**0110001
+// **1**0011100
+// ˆ the overwritten extension bits
+//The encoding will result in the octetstring: ’0FDB00319C’O
+----
+
+==== Attributes Controlling Padding
+
+This section defines the attributes that describe the padding of fields.
+
+*ALIGN*
+
+Attribute syntax: `ALIGN(<parameter>)`
+
+Parameters allowed: `left`, `right`
+
+Default value: `right`
+
+Can be used with: stand-alone types or the field of a `record` or `set`.
+
+Description: This attribute has meaning when the length of the actual value can be determined and is less than the specified `FIELDLENGTH`. In such cases the remaining bits/bytes will be padded with zeros. The attribute `ALIGN` specifies the sequence of the actual value and the padding within the encoded bitfield. +
+`right`: The LSB of the actual value is aligned to the LSB of coded bitfield +
+`left`: The MSB of the actual value is aligned to the MSB of coded bitfield
+
+NOTE: It has no meaning during decoding except if the length of the actual value can be determined from the length restriction of the type. In this case the `ALIGN` also specifies the order of the actual value and the padding within the encoded bitfield.
+
+Examples:
+[source]
+----
+//Example number 1)
+type octetstring OCT10
+with {
+variant "ALIGN(left)";
+variant "FIELDLENGTH(10)"
+}
+
+const OCT10 c_oct := ’0102030405’O
+//Encoded value: ’01020304050000000000’O
+//The decoded value: ’01020304050000000000’O
+//Example number 2)
+type octetstring OCT10length5 length(5)
+with {
+variant "ALIGN(left)";
+variant "FIELDLENGTH(10)"
+}
+
+const OCT10length5 c_oct5 := ’0102030405’O
+//Encoded value: ’01020304050000000000’O
+//The decoded value: ’0102030405’O
+----
+
+*PADDING*
+
+Attribute syntax: `PADDING(<parameter>)`
+
+Parameters allowed:
+
+* `no`
+* `yes`
+* `octet`
+* `nibble`
+* `word16`
+* `dword32`
+* integer to specify the padding unit and allow padding.
+
+Default value: none
+
+Can be used with: This attribute can belong to any types.
+
+Description: This attribute specifies that an encoded type shall *end* at a boundary fixed by a multiple of `padding` unit bits counted from the beginning of the message. The default padding unit is 8 bits. If `PADDING` is set to `yes`, then unused bits of the last octets of the encoded type will be filled with padding pattern. If `PADDING` is set to `no`, the next field will use the remaining bits of the last octet. If padding unit is specified, then the unused bits between the end of the field and the next padding position will be filled with padding pattern.
+
+NOTE: It is possible to use different padding for every field of structured types. The padding unit defined by `PADDING` and `PREPADDING` attributes can be different for the same type.
+
+Examples:
+[source]
+----
+//Example number 1)
+type BIT5 Bit5padded with { variant "PADDING(yes)"}
+
+const Bit5padded c_bits:=’10011’B
+
+//The encoding will have the following result:
+// 00010011
+// ˆ the padding bits
+//The encoding will result in the octetstring ’13’O
+
+//Example number 2)
+type record Paddedrec{
+BIT3 field1,
+BIT7 field2
+} with { variant "PADDING(yes)"}
+
+const Paddedrec c_myrec:={
+field1:=’101’B,
+field2:=’0110100’B
+}
+
+//The encoding will have the following result:
+// 10100101
+// 00000001
+// ˆ the padding bits
+
+//The encoding will result in the octetstring ’A501’O
+
+//Example number 3): padding to 32 bits
+type BIT5 Bit5padded_dw with { variant "PADDING(dword32)"}
+const Bit5padded_dw c_dword:=’10011’B
+//The encoding will have the following result:
+// 00010011
+// 00000000
+// 00000000
+// 00000000
+// ˆ the padding bits
+
+The encoding will result in the octetstring ’13000000’O
+
+//Example number 4)
+type record Paddedrec_dw{
+BIT3 field1,
+BIT7 field2
+} with { variant "PADDING(dword32)"}
+const Paddedrec_dw c_dwords:={
+field1:=’101’B,
+field2:=’0110100’B
+}
+
+//The encoding will have the following result:
+// 10100101
+// 00000001
+// 00000000
+// 00000000
+// ˆ the padding bits
+The encoding will result in the octetstring ’A5010000’O
+----
+
+*PADDING_PATTERN*
+
+Attribute syntax: `PADDING_PATTERN(<parameter>)`
+
+Parameters allowed: bitstring
+
+Default value: `’0’B`
+
+Can be used with: any type with attributes `PADDING` or `PREPADDING`.
+
+Description: This attribute specifies padding pattern used by padding mechanism. The default padding pattern is ’0’B.If the specified padding pattern is shorter than the padding space, then the padding pattern is repeated.
+
+Comment: For a particular field or type only one padding pattern can be specified for `PADDING` and `PREPADDING`.
+
+Examples:
+[source]
+----
+//Example number 1)
+type BIT8 Bit8padded with {
+variant "PREPADDING(yes), PADDING_PATTERN(’1’B)"
+}
+
+type record PDU {
+BIT3 field1,
+Bit8padded field2
+} with {variant ""}
+
+const PDU c_myPDU:={
+field1:=’101’B,
+field2:=’10010011’B
+}
+
+//The encoding will have the following result:
+// 11111101
+// 10010011
+//the padding bits are indicated in bold
+//The encoding will result in the octetstring ’FD93’O
+//Example number 2): padding to 32 bits
+
+type BIT8 Bit8pdd with {
+variant "PREPADDING(dword32), PADDING_PATTERN(’10’B)"
+}
+
+type record PDU{
+BIT3 field1,
+Bit8pdd field2
+} with {variant ""}
+const PDU c_myPDUplus:={
+field1:=’101’B,
+field2:=’10010011’B
+}
+
+//The encoding will have the following result:
+// 01010101
+// 01010101
+// 01010101
+// 01010101
+// 10010011
+//The padding bits are indicated in bold
+
+//The encoding will result in the octetstring ’5555555593’O
+----
+
+*PADDALL*
+
+Attribute syntax: PADDALL(<parameter>)
+
+Can be used with: `record` or `set`.
+
+Description: If `PADDALL` is specified, the padding parameter specified for a whole `record` or `set` will be valid for every field of the structured type in question.
+
+NOTE: If a different padding parameter is specified for any fields it won’t be overridden by the padding parameter specified for the record.
+
+Examples:
+[source]
+----
+//Example number 1)
+type record Paddedrec{
+BIT3 field1,
+BIT7 field2
+} with { variant "PADDING(yes)"}
+const Paddedrec c_myrec:={
+field1:=’101’B,
+field2:=’0110100’B
+}
+
+//The encoding will have the following result:
+// 10100101
+// 00000001
+// ˆ the padding bits
+//The encoding will result in the octetstring ’A501’O
+
+//Example number 2)
+
+type record Padddd{
+BIT3 field1,
+BIT7 field2
+} with { variant "PADDING(yes), PADDALL"}
+
+const Padddd c_myrec:={
+field1:=’101’B,
+field2:=’0110100’B
+}
+
+//The encoding will have the following result:
+// 00000101
+// 00110100
+// ˆ the padding bits
+
+//The encoding will result in the octetstring ’0534’O
+
+//Example number 3)
+
+type record Padded{
+BIT3 field1,
+BIT5 field2,
+BIT7 field3
+} with { variant "PADDING(yes), PADDALL"}
+
+const Padded c_ourrec:={
+field1:=’101’B,
+field2:=’10011’B,
+field3:=’0110100’B
+}
+
+//The encoding will have the following result:
+// 00000101
+// 00010011
+// 00110100
+// ˆ the padding bits
+
+//The encoding will result in the octetstring ’051334’O
+
+//Example number 4): field1 shouldn’t be padded
+
+type record Paddd{
+BIT3 field1,
+BIT5 field2,
+BIT7 field3
+} with { variant "PADDING(yes), PADDALL";
+variant (field1) "PADDING(no)" }
+const Paddd c_myrec:={
+field1:=’101’B,
+field2:=’10011’B,
+field3:=’0110100’B
+}
+
+//The encoding will have the following result:
+// 10011101 < field1 is not padded!!!
+// 00110100
+// ˆ the padding bit
+//The encoding will result in the octetstring ’9D34’O
+----
+
+*PREPADDING*
+
+Attribute syntax: `PREPADDING(<parameter>)`
+
+Parameters allowed:
+
+* `no`
+* `yes`
+* `octet`
+* `nibble`
+* `word16`
+* `dword32`
+* integer to specify the padding unit and allow padding.
+
+Default value: none
+
+Can be used with: any type.
+
+Description: This attribute specifies that an encoded type shall *start* at a boundary fixed by a multiple of padding unit bits counted from the beginning of the message. The default padding unit is 8 bits. If `PREPADDING` is set to `yes`, then unused bits of the last octets of the previous encoded type will be filled with padding pattern and the actual field starts at octet boundary. If `PREPADDING` is set to `no`, the remaining bits of the last octet will be used by the field. If padding unit specified, then the unused bits between the end of the last field and the next padding position will be filled with padding pattern and the actual field starts at from this point.
+
+NOTE: It is possible to use different padding for every field of structured types. The padding unit defined by `PADDING` and `PREPADDING` attributes can be different for the same type.
+
+Examples:
+[source]
+----
+//Example number 1)
+
+type BIT8 bit8padded with { variant "PREPADDING(yes)"}
+type record PDU{
+BIT3 field1,
+bit8padded field2
+} with {variant ""}
+const PDU c_myPDU:={
+field1:=’101’B,
+field2:=’10010011’B
+}
+
+//The encoding will have the following result:
+// 00000101
+// 10010011
+//The padding bits are indicated in bold
+//The encoding will result in the octetstring ’0593’O
+//Example number 2): padding to 32 bits
+
+type BIT8 bit8padded_dw with { variant "PREPADDING(dword32)"}
+type record PDU{
+BIT3 field1,
+bit8padded_dw field2
+} with {variant ""}
+const PDU myPDU:={
+field1:=’101’B,
+field2:=’10010011’B
+}
+
+//The encoding will have the following result:
+// 00000101
+// 00000000
+// 00000000
+// 00000000
+// 10010011
+
+//The padding bits are indicated in bold
+
+//The encoding will result in the octetstring ’0500000093’O
+----
+
+==== Attributes of Length and Pointer Field
+
+This section describes the coding attributes of fields containing length information or serving as pointer within a `record`.
+
+The length and pointer fields must be of TTCN–3 `integer` type and must have fixed length.
+
+The attributes described in this section are applicable to fields of a `record`.
+
+*LENGTHTO*
+
+Attribute syntax: `LENGTHTO(<parameter>) [ (`+' | `-') <offset> ]`
+
+Parameters allowed: list of TTCN–3 field identifiers
+
+Parameter value: any field name
+
+Offset value: positive integer
+
+Default value: none
+
+Can be used with: fields of a `record`.
+
+Description: The encoder is able to calculate the encoded length of one or several fields and put the result in another field of the same record. Consider a record with the fields `lengthField`, `field1`, `field2` and `field3`. Here `lengthField` may contain the encoded length of either one field (for example, `field2`), or sum of the lengths of multiple fields ((for example, that of `field2` + `field3`). The parameter is the field identifier (or list of field identifiers) of the `record` to be encoded.
+
+If the offset is present, it is added to or subtracted from (the operation specified in the attribute is performed) the calculated length during encoding. During decoding, the offset is subtracted from or added to (the opposite operation to the one specified in the attribute is performed) the decoded value of the length field.
+
+NOTE: The length is expressed in units defined by the attribute UNIT The default unit is octet. The length field should be a TTCN–3 `integer` or `union` type. Special union containing only integer fields can be used for variable length field. It must not be used with `LENGTHINDEX`. The length field can be included in to the sum of the lengths of multiple fields (e.g.` lengthField` + `field2` + `field3`). The `union` field is NOT selected by the encoder. So the suitable field must be selected before encoding! The fields included in the length computing need not be continuous.
+
+Examples:
+[source]
+----
+//Example number 1)
+type record Rec {
+INT1 len,
+OCT3 field1,
+octetstring field2
+}
+
+with {
+variant (len) “LENGTHTO(field1);
+variant (len) "UNIT(bits)"
+}
+
+//Example number 2)
+
+type record Rec2 {
+INT1 len,
+OCT3 field1,
+octetstring field2
+}
+
+with {
+variant (len) “LENGTHTO(len, field1, field2)
+}
+
+//Example number 3)
+
+type record Rec3 {
+INT1 len,
+OCT3 field1,
+OCT1 field2
+octetstring field3
+}
+
+with {
+variant (len) “LENGTHTO(field1, field3)
+// field2 is excluded!
+}
+
+//Example number 4): using union as length field
+type union length_union{
+integer short_length_field,
+integer long_length_field
+} with {
+variant (short_length_field) "FIELDLENGTH(7)";
+variant (long_length_field) "FIELDLENGTH(15)";
+}
+
+type record Rec4{
+BIT1 flag,
+length_union length_field,
+octetstring data
+} with {
+variant (length_field)
+“CROSSTAG(short_length_field, flag = ’0’B
+long_length_field, flag = ’1’B)“;
+variant (length_field) "LENGTHTO(data)"
+}
+
+//Const for short data. Data is shorter than 127 octets:
+
+const Rec4(octetstring oc):={
+flag :=’0’B,
+length_field:={short_length_field:=0},
+data := oc
+}
+
+//Const for long data. Data is longer than 126 octets:
+
+const Rec4(octetstring oc):={
+flag :=’1’B,
+length_field:={long_length_field:=0},
+data := oc
+}
+
+//Example number 5): with offset
+type record Rec5 {
+integer len,
+octetstring field
+}
+
+with {
+variant (len) "LENGTHTO(field) + 1"
+}
+
+// { len := 0, field := '12345678'O } would be encoded into '0512345678'O
+// (1 is added to the length of `field')
+// and '0512345678'O would be decoded into { len := 4, field := '12345678'O }
+// (1 is subtracted from the decoded value of `len')
+
+//Example number 6): with offset
+
+type record Rec6 {
+integer len,
+octetstring field
+}
+
+with {
+variant (len) "LENGTHTO(field) - 2"
+}
+
+// { len := 0, field := '12345678'O } would be encoded into '0212345678'O
+// (1 is added to the length of `field')
+// and '0212345678'O would be decoded into { len := 4, field := '12345678'O }
+// (1 is subtracted from the decoded value of `len')
+----
+
+*LENGTHINDEX*
+
+Attribute syntax: `LENGTHINDEX(<parameter>)`
+
+Parameters allowed: TTCN–3 field identifier
+
+Allowed values: any nested field name
+
+Default value: none
+
+Can be used with: fields of a `record`.
+
+Description: This attribute extends the `LENGTHTO` attribute with the identification of the nested field containing the length value within the field of the corresponding `LENGTHTO` attribute.
+
+Comment: See also the description of the `LENGTHTO` attribute.
+NOTE: The field named by `LENGTHINDEX` attribute should be a TTCN–3 integer type.
+
+Example (see also example of `LENGTHTO` attribute).
+[source]
+----
+type integer INT1
+with {
+variant "FIELDLENGTH(8)"
+}
+
+type record InnerRec {
+INT1 length
+}
+
+with { variant "" }
+type record OuterRec {
+InnerRec lengthRec,
+octetstring field
+}
+
+with {
+variant (lengthRec) "LENGTHTO(field)";
+variant (lengthRec) "LENGTHINDEX(length)"
+}
+----
+
+*POINTERTO*
+
+Attribute syntax: `POINTERTO(<parameter>)`
+
+Parameters allowed: TTCN–3 field identifier
+
+Default value: none
+
+Can be used with: fields of a `record`.
+
+Description: Some record fields contain the distance to another encoded field. Records can be encoded in the form of: `ptr1`, `ptr2`, `ptr3`, `field1`, `field2`, `field3`, where the position of fieldN within the encoded stream can be determined from the value and position of field ptrN. The distance of the pointed field from the base field will be `ptrN` * `UNIT` + `PTROFFSET`. The default base field is the pointer itself. The base field can be set by the PTROFFSET attribute. When the pointed field is optional, the pointer value 0 indicates the absence of the pointed field.
+
+Comment: See also the description of `UNIT` (0) and `PTROFFSET` (0) attributes.
+NOTE: Pointer fields should be TTCN–3 `integer` type.
+
+Examples:
+[source]
+----
+type record Rec {
+INT1 ptr1,
+INT1 ptr2,
+INT1 ptr3,
+OCT3 field1,
+OCT3 field2,
+OCT3 field3
+}
+
+with {
+variant (ptr1) "POINTERTO(field1)";
+variant (ptr2) "POINTERTO(field2)";
+variant (ptr3) "POINTERTO(field3)"
+}
+
+const Rec c_rec := {
+ptr1 := <any value>,
+ptr2 := <any value>,
+ptr3 := <any value>,
+field1 := ’010203’O,
+field2 := ’040506’O,
+field3 := ’070809’O
+}
+
+//Encoded c_rec: ’030507010203040506070809’O//The value of ptr1: 03
+//PTROFFSET and UNIT are not set, so the default (0) is being //using.
+//The starting position of ptr1: 0th bit
+//The starting position of field1= 3 * 8 + 0 = 24th bit.
+----
+
+*PTROFFSET*
+
+Attribute syntax: `PTROFFSET(<parameter>)`
+
+Parameters allowed: `integer`, TTCN–3 field identifier
+
+Default value: 0
+
+Can be used with: fields of a `record`.
+
+Description: This attribute specifies where the pointed field area starts and the base field of pointer calculating. The distance of the pointed field from the base field will equal `ptr_field * UNIT + PTROFFSET`.
+
+Comment: It can be specified a base field and pointer offset for one field. See also the description of the attributes `POINTERTO` (0) and `UNIT` (0).
+
+Examples:
+[source]
+----
+type record Rec {
+INT2 ptr1,
+INT2 ptr2
+OCT3 field1,
+OCT3 field2
+}
+
+with {
+variant (ptr1) "POINTERTO(field1)";
+variant (ptr1) "PTROFFSET(ptr2)";
+variant (ptr2) "POINTERTO(field2)";
+variant (ptr2) "PTROFFSET(field1)"
+}
+
+//In the example abovethe distance will not include//the pointer itself.
+----
+
+*UNIT*
+
+Attribute syntax: `UNIT(<parameter>)`
+
+Parameters allowed:
+
+* bits
+* octets
+* nibble
+* word16
+* dword32
+* elements
+* integer
+
+Default value: octets
+
+Can be used with: fields of a `record`.
+
+Description: `UNIT` attribute is used in conjunction with the `LENGTHTO` (0) or `POINTERTO` (0) attributes. Length indicator fields may contain length expressed in indicated number of bits.
+
+Comment: See also description of the `LENGTHTO` and `POINTERTO` attributes. The elements can be used with `LENGTHTO` only if the length field counts the number of elements in a `record`/`set` of field.
+
+Examples:
+[source]
+----
+//Example number 1): measuring length in 32 bit long units
+type record Rec {
+INT1 length,
+octetstring field
+}
+
+with {
+variant (length) "LENGTHTO(field)";
+variant (length) "UNIT(dword32)"
+}
+
+//Example number 2): measuring length in 2 bit long units
+type record Rec {
+INT1 length,
+octetstring field
+}
+
+with {
+variant (length) "LENGTHTO(field)";
+variant (length) "UNIT(2)"
+}
+
+//Example number 3): counting the number of elements of record of field
+type record of BIT8 Bitrec
+type record Rec{
+integer length,
+Bitrec data
+}
+
+with{
+variant (length) "LENGTHTO(data)";
+variant (length) "UNIT(elements)"
+}
+----
+
+==== Attributes to Identify Fields in Structured Data Types
+
+This section describes the coding attributes which during decoding identifies the fields within structured data types such as record, set or union.
+
+*PRESENCE*
+
+Attribute syntax: `PRESENCE(<parameter>)`
+
+Parameters allowed: a `presence_indicator` expression (see Description)
+
+Default value: none
+
+Can be used with: `optional` fields of a `record` or `set`.
+
+Description: Within records some fields may indicate the presence of another optional field. The attribute `PRESENCE` is used to describe these cases. Each optional field can have a `PRESENCE` definition. The syntax of the `PRESENCE` attribute is the following: a `PRESENCE` definition is a presence_indicator expression. `Presence_indicators` are of form `<key> = <constant> or {<key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN>}` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (for example, `22`, `’25’O` or `’1001101’B`).
+
+NOTE: The PRESENCE attribute can identify the presence of the whole record. In that case the field reference must be omitted.
+
+Examples:
+[source]
+----
+type record Rec {
+BIT1 presence,
+OCT3 field optional
+}
+
+with {
+variant (field) "PRESENCE(presence = ’1’B)"
+}
+
+type record R2{
+OCT1 header,
+OCT1 data
+} with {variant "PRESENCE(header=’11’O)"}
+----
+
+*TAG*
+
+Attribute syntax: `TAG(<parameter>)`
+
+Parameters allowed: list of `field_identifications` (see Description)
+
+Default value: none
+
+Can be used with: `record` or `set`.
+
+Description: The purpose of the attribute `TAG` is to identify specific values in certain fields of the `set`, `record` elements or `union` choices. When the `TAG` is specified to a `record` or a `set`, the presence of the given element can be identified at decoding. When the `TAG` belongs to a `union`, the union member can be identified at decoding. The attribute is a list of `field_identifications`. Each `field_identification` consists of a record, set or union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{ <key1> = <constant1>, <key2> = <constant2>, … <keyN> = <constantN> }` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (e.g.` 22`, `’25’O` or `’1001101’B`).There is a special presence_indicator: `OTHERWISE`. This indicates the default union member in a union when the TAG belongs to union.
+
+NOTE: `TAG` works on non-optional fields of a record as well.It is recommended to use the attributes `CROSSTAG` or `PRESENCE` leading to more effective decoding.
+
+Examples:
+[source]
+----
+//Example number 1): set
+type record InnerRec {
+INT1 tag,
+OCT3 field
+}
+
+with { variant "" }
+type set SomeSet {
+InnerRec field1 optional,
+InnerRec field2 optional,
+InnerRec field3 optional
+}
+
+with {
+variant “TAG(field1, tag = 1;
+field2, tag = 2;
+field3, tag = 3)"
+}
+
+//Example number 2): union
+type union SomeUnion {
+InnerRec field1,
+InnerRec field2,
+InnerRec field3
+}
+
+with {
+variant “TAG(field1, tag = 1;
+field2, tag = 2;
+field3, OTHERWISE)"
+}
+
+If neither tag=1 in field1 nor tag=2 in field2 are matched, field3 is selected.
+
+//Example number 3): record
+type record MyRec{
+OCT1 header,
+InnerRec field1 optional
+}
+
+with{
+variant (field1) "TAG(field1, tag = 1)"
+}
+
+//field1 is present when in field1 tag equals 1.
+----
+
+*CROSSTAG*
+
+Attribute syntax: `CROSSTAG(<parameter>)`
+
+Parameters allowed: list of union "field_identifications" (see Description)
+
+Default value: none
+
+Can be used with: `union` fields of `records`.
+
+Description: When one field of a `record` specifies the union member of another field of a record, CROSSTAG definition is used. The syntax of the CROSSTAG attribute is the following. Each union field can have a `CROSSTAG` definition. A `CROSSTAG` definition is a list of union `field_identifications`. Each `field_identification` consists of a union field name and a `presence_indicator` expression separated by a comma (,). `Presence_indicators` are of form `<key> = <constant>` or `{<key1> = <constant1>`, `<key2> = <constant2>`, `… <keyN> = <constantN>}` where each key is a field(.nestedField) of the `record`, `set` or `union` and each constant is a TTCN–3 constant expression (for example, `22`, `’25’O` or `’1001101’B`).There is a special `presence_indicator`: `OTHERWISE`. This indicates the default union member in union.
+
+NOTE: The difference between the `TAG` and `CROSSTAG` concept is that in case of `TAG` the field identifier is inside the field to be identified. In case of `CROSSTAG` the field identifier can either precede or succeed the union field it refers to. If the field identifier succeeds the union, they must be in the same record, the union field must be mandatory and all of its embedded types must have the same fixed size.
+
+Examples:
+[source]
+----
+type union AnyPdu {
+PduType1 type1,
+PduType2 type2,
+PduType3 type3
+}
+
+with { variant "" }
+type record PduWithId {
+INT1 protocolId,
+AnyPdu pdu
+}
+
+with {
+variant (pdu) “CROSSTAG( type1, { protocolId = 1,
+protocolId = 11 };
+type2, protocolId = 2;
+type3, protocolId = 3)"
+}
+----
+
+*REPEATABLE*
+
+Attribute syntax: `REPEATABLE(<parameter>)`
+
+Parameters allowed: `yes`, `no`
+
+Default value: none
+
+Can be used with: `record/set` of type fields of a `set`.
+
+Description: The element of the set can be in any order. The `REPEATABLE` attribute controls whether the element of the `record` or `set` `of` can be mixed with other elements of the `set` or they are grouped together.
+
+NOTE: It has no effect during encoding.
+
+Examples:
+[source]
+----
+// Three records and a set are defined as follows:
+
+type record R1{
+OCT1 header,
+OCT1 data
+} with {variant "PRESENCE(header=’AA’O)"}
+
+type record of R1 R1list;
+
+type record R2{
+OCT1 header,
+OCT1 data
+} with {variant "PRESENCE(header=’11’O)"}
+
+type record R3{
+OCT1 header,
+OCT1 data
+} with {variant "PRESENCE(header=’22’O)"}
+
+type set S1 {
+R2 field1,
+R3 field2,
+R1list field3
+}
+
+with {variant (field3) "REPEATABLE(yes)"}
+
+//The following encoded values have equal meaning:
+// (The value of R1 is indicated in bold.)
+//example1: 1145**AA01AA02AA03**2267
+//example2: 114**5AA01**2267**AA02AA03**
+//example3: **AA01**2267**AA02**1145*AA03*
+
+The decoded value of S1 type:
+
+{
+field1:={
+header:=’11’O,
+data:=’45’O
+},
+
+field2:={
+header:=’22’O,
+data:=’67’O
+},
+
+field3:={
+{header:=’AA’O,data:=’01’O},
+{header:=’AA’O,data:=’02’O},
+{header:=’AA’O,data:=’03’O}
+}
+}
+
+type set S2 {
+R2 field1,
+R3 field2,
+R1list field3
+}
+
+with {variant (field3) "REPEATABLE(no)"}
+
+//Only the example1 is a valid encoded value for S2, because
+//the elements of the field3 must be groupped together.
+----
+
+==== Type-specific attributes
+
+*IntX*
+
+Attribute syntax: `IntX`
+
+Default value: none
+
+Can be used with: `integer` types
+
+Description: Encodes an integer value as the IntX type in the ETSI Common Library (defined in ETSI TS 103 097).
+
+This is a variable length encoding for integers. Its length depends on the encoded value (but is always a multiple of 8 bits).
+
+The data starts with a series of ones followed by a zero. This represents the length of the encoded value: the number of ones is equal to the number of additional octets needed to encode the value besides those used (partially) to encode the length. The following bits contain the encoding of the integer value (as it would otherwise be encoded).
+
+Comment: Since the length of the encoding is variable, attribute `FIELDLENGTH` is ignored. Furthermore, `IntX` also sets `BITORDER` and `BITORDERINFIELD` to `msb`, and `BYTEORDER` to first, overwriting any manual settings of these attributes.
+
+Only attribute `COMP` can be used together with `IntX` (if it’s set to `signbit`, then the sign bit will be the first bit after the length).
+
+Restrictions: Using `IntX` in a `record` or `set` with `FIELDORDER` set to `lsb` is only supported if the `IntX` field starts at the beginning of a new octet. A compiler error is displayed otherwise. The `IntX` field may start anywhere if the parent `record`/`set’s` `FIELDORDER` is set to `msb`.
+
+Examples:
+[source]
+----
+// Example 1: Standalone IntX integer type with no sign bit:
+type integer IntX_unsigned with { variant "IntX" }
+
+// Encoding integer 10:
+// 00001010
+// ^ length bit (there are no ones as no additional octets are needed)
+
+// Encoding integer 2184:
+// 10001000 10001000
+// ^^ length bits (one extra octet is needed after the partial length octet)
+
+// Example 2: Standalone IntX integer type with sign bit:
+type integer IntX_signed with { variant "IntX, COMP(signbit)" }
+// Encoding integer -2184:
+// 10101000 10001000
+// length bits ^^
+// ^ sign bit
+
+// Example 3: Standalone IntX integer type with 2’s complement:
+type integer IntX_compl with { variant "IntX, COMP(2scompl)" }
+// Encoding integer -2184:
+// 10110111 01111000
+// ^^ length bits
+
+// Example 4: IntX integer record field (starting in a partial octet):
+type record RecIntXPartial {
+integer i,
+integer ix,
+bitstring bs
+}
+
+with {
+variant "FIELDORDER(msb)";
+variant (i) "FIELDLENGTH(12), BITORDER(msb)";
+variant (i) "BYTEORDER(first), BITORDERINFIELD(msb)";
+variant (ix) "IntX";
+variant (bs) "FIELDLENGTH(8)";
+}
+
+// Encoding record value { i := 716, ix := 716, bs := ‘10101010’B }:
+// 00101100 11001000 00101100 11001010 10100000
+// ^^^^^^^^ ^^^^ field `i' (same encoding as `ix', but with no length bits)
+// field `ix' ^^^^ ^^^^^^^^ ^^^^ (the first 2 bits are the length bits)
+// field `bs' ^^^^ ^^^^
+// Note: setting the record’s FIELDORDER to `lsb' in this case is not supported
+// and would cause the mentioned compiler error.
+----
+
+==== Obsolete Attributes
+
+This section describes the obsolete attributes. These attributes are kept for compatibility reason. The usage of the obsolete attributes is not recommended in new developments.
+
+*BITORDERINOCTET*
+
+The attribute has the same meaning and syntax as `BITORDER`. In new developments only the attribute `BITORDER` may be used.
+
+*TOPLEVEL BITORDER*
+
+Attribute syntax: `TOPLEVEL( BITORDER(<parameter>))`
+
+Parameters allowed: `msb`, `lsb`
+
+Default value: `msb`
+
+Can be used with: a toplevel type.
+
+Description: This attribute specifies the order of the bits within an octet. When set to `lsb`, the first bit sent will be the least significant bit of the original byte.
+
+Comment:
+
+Example:
+[source]
+----
+type record WholePDU {
+Field1 field1,
+Field2 field2
+}
+
+with { variant "TOPLEVEL( BITORDER(lsb) )" }
+const WholePDU c_pdu := {
+’12’O,
+’12’O
+}
+
+//Encoding of c_pdu will result in ’4848’O.
+----
+
+[[ttcn-3-types-and-their-attributes]]
+=== TTCN-3 Types and Their Attributes
+
+This section lists the TTCN-3 types along with the attributes allowed to be used with the types.
+
+*BITSTRING*
+
+Coding: The `bitstring` is represented by its binary value. The LSB of the binary form of a bitstring is concatenated to the LSB of the bitfield. If the length of the `bitstring` is shorter than the specified `FIELDLENGTH`, aligning is governed by the attribute `ALIGN. The FIELDLENGTH` default value for `bitstring` type is `variable`.
+
+Attributes allowed:
+
+* `ALIGN (0)`,
+* `BITORDER (0)`,
+* `BITORDERINFIELD (0)`,
+* `BYTEORDER (0)`,
+* `FIELDLENGTH (0)`,
+* `N bit / unsigned N bit` (0).
+
+Example:
+[source]
+----
+*//Example number 1): variable length bitstring*
+const bitstring c_mystring:=’1011000101’B
+//The resulting bitfield: 1011000101
+//The encoding will have the following result:
+// 11000101
+// ……10
+
+*//Example number 2): fixed length bitstring*
+type bitstring BIT7 with { variant "FIELDLENGTH(7)" }
+const BIT7 c_ourstring:=’0101’B
+//The resulting bitfield: 0000101
+
+*//Example number 3): left aligned bitstring*
+type bitstring BIT7align with {
+variant "FIELDLENGTH(7), ALIGN(left)" }
+const BIT7align c_yourstring:=’0101’B
+//The resulting bitfield: 0101000
+----
+
+*BOOLEAN*
+
+Coding: The `boolean` value `true` coded as ’1’B,the `boolean` value `false` coded as ’0’B.If `FIELDLENGTH` is specified, the given number of ones (`true`) or zeros (`false`) is coded. If the decoded bitfield is zero the decoded value will be false otherwise true.The default `FIELDLENGTH` for `boolean` type is 1.
+
+Attributes allowed: `FIELDLENGTH (0)`, `N bit` (0).
+
+Examples:
+[source]
+----
+*//Example number 1): boolean coded with default length*
+const boolean c_myvar:=true
+//The resulting bitfield: 1
+*//Example number 2): boolean coded with fixed length*
+type boolean Mybool with { variant "FIELDLENGTH(8)"}
+const Mybool c_ourvar:=true
+//The resulting bitfield: 11111111
+----
+
+*CHARSTRING*
+
+Coding: The characters are represented by their ASCII binary value. The first character is put into the first octet of the bitfield. The second character is put into the second octet of the bitfield and so on. Thus, the first character is put first into the buffer. If the actual value of `charstring` is shorter than the specified `FIELDLENGTH`, aligning is governed by the attribute `ALIGN`. The default `FIELDLENGTH` for bitstring type is variable. The `FIELDLENGTH` is measured in chars.
+
+Attributes allowed:
+
+* `ALIGN (0)`,
+* `BITORDER (0)`,
+* `BITORDERINFIELD (0)`,
+* `BYTEORDER (0)`,
+* `FIELDLENGTH (0)`,
+* `N bit (0)`
+
+Examples:
+[source]
+----
+*//Example number 1): variable length charstring*
+const charstring c_mystring:="Hello"
+//The resulting bitfield: 01101111 01101100 01101100
+// 01100101 01001000
+//The encoding will have the following result:
+// 01001000 "H"
+// 01100101 "e"
+// 01101100 "l"
+// 01101100 "l"
+// 01101111 "o"
+
+*//Example number 2): fixed length charstring*
+type charstring CHR6 with { variant "FIELDLENGTH(6)" }
+const CHR6 c_yourstring:="Hello"
+//The resulting bitfield: 00000000 01101111 01101100 01101100
+// 01100101 01001000
+
+//The encoding will have the following result:
+// 01001000 "H"
+// 01100101 "e"
+// 01101100 "l"
+// 01101100 "l"
+// 01101111 "o"
+// 00000000 " "
+
+*//Example number 3): left aligned charstring*
+type charstring CHR6align with {
+variant "FIELDLENGTH(6), ALIGN(left)" }
+const CHR6align c_string:="Hello"
+
+//The resulting bitfield: 01101111 01101100 01101100 01100101
+// 01001000 00000000
+//The encoding will have the following result:
+// 00000000 " "
+// 01001000 "H"
+// 01100101 "e"
+// 01101100 "l"
+// 01101100 "l"
+// 01101111 "o"
+----
+
+*ENUMERATED*
+
+Coding: The `enumerated` type is coded as an integer value. This numerical value is used during encoding. The default `FIELDLENGTH` for `enumerated` type is the minimum number of bits required to display the highest `enumerated` value.
+
+Attributes allowed:
+
+* `BITORDER (0)`,
+* `BITORDERINFIELD (0)`,
+* `BYTEORDER (0)`,
+* `COMP (0)`,
+* `FIELDLENGTH (0)`,
+* `N bit / unsigned N bit` (0).
+
+Example:
+[source]
+----
+type enumerated Enumm {zero, one, two, three, four, five}
+
+const Enumm myenum:=two
+
+//The maximum enumerated value: 5 (five)
+//Minimum 3 to represent 5.
+//The FIELDLENGTH will be 3
+//The resulting bitfield: 010
+
+type enumerated Enum { zero(2), one(23), two(4), three(1), four(0), five(5) }
+const Enum c_myenum:=two
+
+//The maximum enumerated value: 23 (one)
+//Minimum 5 bits are needed to represent 23.
+//The FIELDLENGTH will be 5
+//The resulting bitfield: 00010
+----
+
+*FLOAT*
+
+Coding: The `float` value is represented according to IEEE 754 standard. The `FORMAT` attribute specifies the number of the bits used in exponent and mantissa. `IEEE754 double`: The float value is encoded as specified in IEEE754 standard using 1 sign bit, 11 exponent bits and 52 bits for mantissa. `IEEE754 float`: The float value is encoded as specified in IEEE754 standard using 1 sign bit, 8 exponent bits and 23 bits for mantissa. The default `FORMAT` for float is IEEE754 double.
+
+Attributes allowed:
+
+* `BITORDER (0)`,
+* `BITORDERINFIELD (0)`,
+* `BYTEORDER (0)`,
+* `FORMAT (0)`
+
+Example:
+[source]
+----
+//S - sign bit
+//E - exponent bits
+//M - mantissa bits
+
+*//Example number 1): single precision float*
+type float SingleFloat
+with {
+variant "FORMAT(IEEE754 float)"
+}
+
+const SingleFloat c_float:=1432432.125
+//The resulting bitfield: 10000001 11011011 10101110 01001001
+// MMMMMMMM MMMMMMMM EMMMMMMM SEEEEEEE
+
+//The encoding will have the following result:
+// 01001001 SEEEEEEE
+// 10101110 EMMMMMMM
+// 11011011 MMMMMMMM
+// 10000001 MMMMMMMM
+
+//The encoding will result in the octetstring ’49AEDB81’O
+
+*//Example number 2): double precision float*
+type float DoubleFloat
+with {
+variant "FORMAT(IEEE754 double)"
+}
+
+const DoubleFloat c_floatd:=1432432.112232
+
+//The resulting bitfield:
+//82 3c bb 1c70 db 35 41
+//10000010 00111100 10111011 00011100
+//01110000 11011011 00110101 01000001
+//MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM
+//MMMMMMMM MMMMMMMM EEEEMMMM SEEEEEEE
+
+//The encoding will have the following result:
+
+// 01000001 SEEEEEEE
+// 00110101 EEEEMMMM
+// 11011011 MMMMMMMM
+// 01110000 MMMMMMMM
+// 00011100 MMMMMMMM
+// 10111011 MMMMMMMM
+// 00111100 MMMMMMMM
+// 10000010 MMMMMMMM
+
+//The encoding will result in the octetstring
+
+// ’4135DB701CBB3C82’O
+----
+
+*HEXSTRING*
+
+Coding: The hexadecimal digit is represented by its binary value. The first hexadecimal digit is put into the lower nibble of first octet of the bitfield. The second hexadecimal digit is put into the higher nibble of first octet of the bitfield. The 3^rd^ hexadecimal digit is put into the lower nibble of second octet of bitfield and so on. Thus, the first hexadecimal digit is put first into the buffer. Is the actual length of hexstring shorter than the specified by `FIELDLENGTH`, aligning is governed by the attribute `ALIGN`. The default `FIELDLENGTH` value for `hexstring` type is `variable`. In this case, `FIELDLENGTH` is measured in hexdigits.
+
+Attributes allowed:
+
+* `ALIGN (0)`,
+* `BITORDER (0)`,
+* `BITORDERINFIELD (0)`,
+* `BYTEORDER (0)`,
+* `FIELDLENGTH (0)`,
+* `N bit (0)`.
+
+Example:
+[source]
+----
+*//Example number 1): variable length hexstring*
+const hexstring c_mystring:=’5AF’H
+
+//The resulting bitfield: 1111 10100101
+//The encoding will have the following result:
+// 10100101 A5
+// ….1111 .F
+
+*//Example number 2): fixed length hexstring*
+type hexstring HEX4 with { variant "FIELDLENGTH(4)" }
+const HEX4 c_yourstring:=’5AF’H
+//The resulting bitfield: 00001111 10100101
+//The encoding will have the following result:
+// 10100101 A5
+// 00001111 0F
+
+*//Example number 3): left aligned hexstring*
+type hexstring HEX4align with {
+variant "FIELDLENGTH(4), ALIGN(left)" }
+const HEX4align c_ourstring:=’5AF’H
+
+//The resulting bitfield: 11111010 01010000
+//The encoding will have the following result:
+// 01010000 50
+// 11111010 FA
+----
+
+*INTEGER*
+
+Coding: The LSB of the binary form of an `integer` is concatenated to the LSB of the bitfield. The value of the attribute `COMP` determines how the value of an `integer` type will be coded to binary form. The integer is always of fixed length and fills the space specified by `FIELDLENGTH`. The default value of `FIELDLENGTH` for integer is 8 bit. The `ALIGN` attribute has no meaning for `integer`.
+
+Attributes allowed:
+
+* `BITORDER (0)`,
+* `BITORDERINFIELD (0)`,
+* `BYTEORDER (0)`,
+* `COMP (0)`,
+* `FIELDLENGTH (0)`,
+* `IntX (0)`,
+* `N bit / unsigned N bit (0)`.
+
+Example:
+[source]
+----
+*//Example number 1)*
+
+type integer Int12
+with{ variant "FIELDLENGTH(12)"}
+const Int12 c_myint:=1052
+
+//The resulting bitfield is 010000011100
+//The encoding will have the following result:
+// 00011100
+// ….0100
+
+//The same result represented as octetstring: ’1C.4’O
+
+*//Example number 2)*
+
+type integer Int12sg
+with{ variant "FIELDLENGTH(12), COMP(signbit)"}
+const Int12sg c_mysignedint:=-1052
+
+//The resulting bitfield: 110000011100
+//The encoding will have the following result:
+// 00011100
+// ….1100
+//The same result represented as octetstring: ’1C.C’O
+
+*//Example number 3)*
+
+type integer Int12c
+with{ variant "FIELDLENGTH(12), COMP(2scompl)"}
+const int12c c_hisint:=-1052
+//The resulted bitfield: 101111100111
+//The encoding will have the following result:
+// 11100111
+// ….1011
+//The same result represented as octetstring: ’E7.B’O
+----
+
+*OCTETSTRING*
+
+Coding: The octets are represented by their binary value. The first octet is put into first octet of bitfield. The second octet is put second octet of bitfield and so on. Thus, the first octet is put first into the buffer. If the length of the `octetstring` is shorter than the specified `FIELDLENGTH`, aligning is governed by the attribute `ALIGN`. The default `FIELDLENGTH` value for `octetstring` type is `variable`. In this case, `FIELDLENGTH` is measured in octets.
+
+Attributes allowed:
+
+* `ALIGN` (0),
+* `BITORDER` (0),
+* `BITORDERINFIELD` (0),
+* `BYTEORDER` (0),
+* `FIELDLENGTH` (0),
+* `N bit` (0).
+
+Example:
+[source]
+----
+*//Example number 1): variable length octetstring*
+const octetstring c_mystring:=’25AF’O
+
+//The resulting bitfield: 10101111 00100101
+//The encoding will have the following result:
+// 00100101 25
+// 10101111 AF
+
+*//Example number 2): fixed length octetstring*
+
+type octetstring OCT3 with { variant "FIELDLENGTH(3)" }
+const OCT3 c_yourstring:=’25AF’H
+//The resulting bitfield: 00000000 10101111 00100101
+//The encoding will have the following result:
+// 00100101 25
+// 10101111 AF
+// 00000000 00
+
+*//Example number 3): left aligned octetstring*
+type octetstring OCT3align with {
+variant "FIELDLENGTH(3), ALIGN(left)" }
+const OCT3align c_string:=’25AF’H
+
+//The resulting bitfield: 10101111 00100101 00000000
+//The encoding will have the following result:
+// 00000000 00
+// 00100101 25
+// 10101111 AF
+----
+
+*SET*
+
+Encoding: During encoding the fields present are encoded one by one. If `TAG` is specified for one field, the value of the key field is checked for a valid value. If a valid value is not found, the value of the key field will be substituted with a valid key value.
+
+Decoding: The fields can be received in any order. If `TAG` is specified, the value of the key field identifies the fields. If `TAG` is not specified for any field, the decoder tries to decode a field. If the decoding is successful, the decoder assumes that the field was received. The matching algorithm is the following: First try to identify the received fields by `TAGs`; if it fails, try to decode the fields; if it fails and `OTHERWISE` is specified in `TAG`, try that field; if it fails: unknown field is received. If all mandatory fields have already been decoded, then the set is successfully decoded, else the decoding of set has failed.
+
+*RECORD*
+
+Encoding: The fields present are encoded one by one. The value of length and pointer fields are calculated and substituted. If `TAG`, `CROSSTAG` or `PRESENCE` are specified for one field, the value of the key field is checked for a valid value. If a valid value is not found, the value of key field will be substituted with a valid key value. Finally, the extension bits are set.
+
+Decoding: Fields are decoded one by one. The presence of optional fields is determined by the attributes `TAG`, `PRESENCE`, by extension bits and by the value of the length field. The chosen field of union is determined by `CROSSTAG`, if present. The value of pointer field is used to determine the beginning of the pointed field. Have all of the mandatory fields been received and successfully decoded, the decoding of the record is successful.
+
+*RECORD OF, SET OF*
+
+Encoding: The elements of `record` of or `set of` are encoded one by one. Finally, the extension bits are set, if needed.
+
+Decoding: The items of `record` of or `set of` are decoded one by one. The number of items is determined by the attribute `FIELDLENGTH`, by extension bits or the number of available bits in buffer. The decoding of `record of` or `set of` is successful if at least one item has been decoded.
+
+*UNION*
+
+Encoding: The chosen field will be encoded according to its own encoding rules. If `TAG` is specified for this field, the value of the key field is checked for a valid value. If a valid value is not found, the value of the key field will be substituted with a valid key value.
+
+Decoding: The decoder tries to identify the received union field. If `TAG` is present, the decoder uses the value of the key fields to identify the fields. If `TAG` is not present, the decoder tries to decode the fields and if it succeeds, the decoder assumes that field is received. If the decoding of field is not successful, the decoder checks the next field. The decoding of the union will be unsuccessful if none of the fields can be decoded.
+
+Examples:
+[source]
+----
+type record Rec{
+OCT1 key,
+OCT1 values
+}
+
+type union MyUnion{
+Rec field1,
+Rec field2,
+Rec field3
+} with { variant "TAG( field1,{key = ’56’O, key=’7A’}; field2, key = ’FF’; field3,{key = ’A4’O, key = ’99’O})"
+}
+
+*//Example number 1): successful encoding*
+const MyUnion c_PDU:={
+field1:={ key:=’7A’O, values:=’B2’O}
+}
+
+//Chosen field: field1
+//Value of key field: ’7A’O; valid
+//No substitution will take place.
+//The encoding will have the following result:
+// 01111010 7A
+// 10110010 B2
+
+*//Example number 2): key field substituted*
+
+const MyUnion c_PDU2:={
+field1:={ key:=’00’O, values:=’B2’O}
+}
+
+//Chosen field: field1
+//Value of key field: ’00’O not valid
+//The value of key field will be substituted with:’56’O
+//The encoding will have the following result:
+// 01010110 56
+// 10110010 B2
+----
+
+*UNIVERSAL CHARSTRING*
+
+Coding: The characters are first converted to UTF-8 format, and the resulting octets are encoded as if they were an `octetstring`. That is, the octets are represented by their binary value. The first octet is put into the first octet of the bit field. The second octet is put into the second octet of the bit field, and so on. Thus, the first octet is put first into the buffer.
+
+The RAW encoding of a `universal` `charstring` value with no non-ASCII characters is equal to the RAW encoding of a `charstring` containing the same characters (with the same attributes).
+
+If the length of the UTF-8 encoded `universal` `charstring` is shorter than the specified `FIELDLENGTH`, aligning is governed by the attribute `ALIGN`.The default `FIELDLENGTH` for the `universal` `charstring` type is `variable`. The `FIELDLENGTH` is measured in UTF-8 octets.
+
+Attributes allowed:
+
+* `ALIGN` (0),
+* `BITORDER` (0),
+* `BITORDERINFIELD` (0),
+* `BYTEORDER` (0),
+* `FIELDLENGTH` (0),
+* `N bit` (0).
+
+Examples:
+[source]
+----
+*//Example number 1): variable length universal charstring*
+
+const universal charstring c_mystring := "sepr" & char(0, 0, 1, 113);
+
+//The encoding will have the following result:
+// 01110011 "s"
+// 01100101 "e"
+// 01110000 "p"
+// 01110010 "r"
+// 11000101 C5
+// 10110001 B1 C5B1 is the UTF-8 encoding of char(0, 0, 1, 113)
+
+*//Example number 2): fixed length universal charstring*
+type universal charstring USTR8 with { variant "FIELDLENGTH(8)" }
+const USTR8 c_yourstring := "sepr" & char(0, 0, 1, 113);
+
+//The encoding will have the following result:
+// 01110011 "s"
+// 01100101 "e"
+// 01110000 "p"
+// 01110010 "r"
+// 11000101 C5
+// 10110001 B1 C5B1 is the UTF-8 encoding of char(0, 0, 1, 113)
+// 00000000 " "
+// 00000000 " "
+
+*//Example number 3): left aligned universal charstring*
+type universal charstring USTR8align with {
+variant "FIELDLENGTH(8), ALIGN(left)" }
+const USTR8align c_string := "sepr" & char(0, 0, 1, 113);
+//The encoding will have the following result:
+// 00000000 " "
+// 00000000 " "
+// 01110011 "s"
+// 01100101 "e"
+// 01110000 "p"
+// 01110010 "r"
+// 11000101 C5
+// 10110001 B1 C5B1 is the UTF-8 encoding of char(0, 0, 1, 113)
+----
+
+== TEXT Encoder and Decoder
+
+The TEXT encoder and decoder are general purpose functionalities developed originally for handling verbose and tokenized protocols.
+
+The encoder converts abstract TTCN-3 structures (or types) into a bitstream suitable for serial transmission. The decoder, on the contrary, converts the received bitstream into values of abstract TTCN-3 structures.
+
+TITAN provides a special encoding scheme for coding elements into a textual representation. This is called TEXT and is used like `encoding "TEXT"`.
+
+This section covers the attributes controlling the <<general-rules-and-restrictions-0, coding process>> and <<bnf-of-the-attributes, BNF specification of the attributes>>.
+
+Error encountered during the encoding or decoding process are handled as defined in section "Setting error behavior" in <<13-references.adoc#_16, [16]>>.
+
+[[attributes-0]]
+=== Attributes
+
+An `attribute` determines coding and encoding rules.
+
+NOTE: the section 27.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>) states that an `attribute` is used to refine the current encoding scheme defined with the keyword `encode`. Because of backward compatibility the presence of the `encode` attribute is not required, but might result in a compile time warning (which in the future might turn into an error).
+
+*BEGIN*
+
+Role: The `BEGIN` attribute defines the leading token of the type.
+
+Format: `BEGIN(token_to_encode, <matching_exp>,<modifier>)`
+
+Description: The attribute defines the leading token of the type. This token defines the beginning of the value of the type and will be written into the encoded string before the value of the type is encoded. `BEGIN` can be used with any type.
+
+Parameters: `token_to_encode` +
+The token is used during encoding. +
+
+`Mandatory.matching_exp` +
+This TTCN–3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). This parameter is optional; when omitted, the parameter token_to_encode will be used as the matching pattern. +
+
+`modifier` +
+Modifies the behavior of the matching algorithm. Optional parameter. When omitted the default value will be used. The available modifiers: +
+* `case_sensitive` The matching is case sensitive. Default value. +
+* `case_insensitive` The matching is case insensitive.
+
+Example:
+[source]
+----
+//SIP header Subject header:
+
+type record Subject{
+charstring subject_value
+}
+
+with { variant “BEGIN(’Subject: ’,’
+(Subject[ ]#(,):[ ]#(,))|"
+“(s[ ]#(,):[ ]#(,))’,
+case_insensitive)"
+}
+
+var Subject v_subj:= "the_subject";
+//The encoded string will be: "Subject: the subject"
+//The decoder will accept the long (Subject: the subject)
+//and the short (s: the subject) format regardless
+//of the case of the character of the header.
+----
+
+*END*
+
+Role: The `END` attribute defines the closing token of the type.
+
+Format: `END(token_to_encode, <matching exp>,<modifier>)`
+
+Description: The attribute defines the closing token of the type. This token defines the end of the value of the type and will be written into the encoded string after the encoded value of the type. `END` can be used with any type.
+
+Parameters: `token_to_encode` +
+The token used during encoding. Mandatory.
+
+`matching_exp` +
+This TTCN–3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). This parameter is optional; when omitted, the `token_to_encode` will be used as matching pattern.
+
+`modifier` +
+Modifies the behavior of the matching algorithm. Optional parameter. When omitted, the default value will be used. The available modifiers: +
+* `case_sensitive`: The matching is case sensitive. Default value. +
+* `case_insensitive`: The matching is case insensitive.
+
+Example:
+[source]
+----
+//SIP header Subject header:
+
+type record Subject{
+charstring subject_value
+}
+
+with { variant “BEGIN(’Subject: ’,’
+(Subject[ ]#(,):[ ]#(,))|"
+“(s[ ]#(,):[ ]#(,))’,
+case_insensitive)“;
+variant "END(’’,’([])|([])’)"
+}
+
+var Subject v_subj:= "the_subject";
+//The encoded string will be: "Subject: the_subject"
+//The decoder will accept both "Subject: the_subject" and //"Subject: the_subject" format.
+----
+
+*SEPARATOR*
+
+Role: The attribute `SEPARATOR` defines the field separator token of the type.
+
+Format: `SEPARATOR(token to encode, <matching exp>,<modifier>)`
+
+Description: The attribute defines the field separator token of the type. This token separates the value of fields and will be written into the encoded string between the fields of the type. `SEPARATOR` can be used with any type.
+
+Parameters: `token_to_encode` +
+The token used during encoding. Mandatory.
+
+`matching_exp` +
+This TTCN–3 character pattern is used during decoding to identify the leading token of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). Optional parameter. When omitted, the token to encode will be used as matching pattern.
+
+`modifier` +
+Modifies the behavior of the matching algorithm. Optional parameter. When omitted, the default value will be used. The available modifiers: +
+* `case_sensitive` The matching is case sensitive. Default value. +
+* `case_insensitive` The matching is case insensitive.
+
+Example:
+[source]
+----
+type record Rec_1{
+charstring field_1,
+charstring field_2
+}
+
+with {
+variant "BEGIN(’Header: ’)"
+variant "SEPARATOR(’;’)"
+}
+
+var Rec_1 v_rec:={field1:="value_field1",
+field2:="value_field2"}
+//The encoded will result in the string:
+//"Header: value_field1; value_field2"
+----
+
+*TEXT_CODING*
+
+Role: The attribute TEXT_CODING defines the encoding and decoding rules of the value
+
+Format: `TEXT_CODING(encoding_rule,<decoding_rule>,<matching_exp>,<modifier>)`
+
+Description: The attribute controls the encoding and the decoding of the values.
+
+Parameters: `encoding_rule` +
+Controls the encoding of the value. For syntax see the two tables below.
+
+`decoding_rule` +
+Controls the decoding of the value. For syntax see the two tables below.
+
+`matching_exp` +
+TTCN–3 character pattern, used during decoding to identify the value of the type. The format of the parameter is described in clause B.1.5 of the TTCN–3 standard (<<13-references.adoc#_1, [1]>>). Optional parameter.
+
+`modifier` +
+Modifies the behavior of the matching algorithm. Optional parameter. When omitted, the default value will be used. The available modifiers: +
+* `case_sensitive` The matching is case sensitive. Default value. +
+* `case_insensitive` The matching is case insensitive.
+
+.Format of `encoding_rule` and `decoding_rule`
+[cols=",,",options="header",]
+|===
+|*Type* |*encoding_rule* |*decoding_rule*
+|`charstring` |The format of encoding_rule: `attr=value[;attr=value]` +
+Usable attributes: `length`, `convert`, `just`
+ |The format of decoding_rule: `attr=value[;attr=value]` +
+Usable attributes: `length`, `convert`
+
+|`integer` |The format of the encoding rule: +
+`attr=value[;attr=value]` +
+Usable attributes: `length`, `leading0`
+ |The format of the decoding rule: +
+ `attr=value[;attr=value]` +
+Usable attribute: `length`
+|`boolean` |The encoded value of `true` and `false` value: +
+`true:’token’[;false:’token’]` +
+The default encoded value of `true` is ’true’; the default encoded value of `false` is ’false’
+|The matching pattern of the value true and false: +
+`true:{’pattern’[,modifier]}[;false:{’pattern’[,modifier]}]` +
+The default decoding method is case sensitive
+|`enumerated` |The encoded value of enumeration: +
+`value:’token’[;value:’token’]` +
+The default encoded value of enumerations is the TTCN–3 identifier of the enumerations.
+ |The matching pattern of enumerations: +
+`value:{’pattern’[,modifier]}[;value:{’pattern’[,modifier]}]`
+The default decoding method is case sensitive.
+|`set` `ofrecord` `of` |Not applicable |The format of the decoding rule: +
+`attr=value[;attr=value]` +
+Usable attribute: `repeatable`
+|structured types |Not applicable |Not applicable
+|===
+
+.Attributes used with encoding_rule and decoding_rule
+[cols=",,,",options="header",]
+|===
+|*attr* |*Description* |*Parameter* |*Default value*
+|`length` |Determines the length of the coded value. |value |number of charactersof value
+|`convert` |Converts string values to lower orupper case during encoding or decoding. |`lower_case`, `upper_case` |no conversion
+|`just` |If the string is shorter than the value definedby the length attribute, just controls the justification of the value. |`left`, `right`, `center` |`left`
+|`leading0` |Controls the presence of the leading zerosof the coded integer value. |`true`, `false` |`false`
+|`repeatable` |The attribute repeatable controls whether the element of the record of or set of can be mixed with other elements of the set or they are grouped together. |`true`, `false` |`false`
+|===
+
+Example:
+[source]
+----
+*//Example number 1): integer with leading zero*
+type integer My_int with {
+variant "TEXT_CODING(length=5;leading0=true)"
+}
+
+var My_int v_a:=4;
+// The encoded value: ’00004’
+*//Example number 2): integer without leading zero*
+type integer My_int2 with {
+variant "TEXT_CODING(length=5)"
+}
+
+var My_int2 v_aa:=4;
+// The encoded value: ’ 4’
+*//Example number 3): character string*
+type charstring My_char with {
+variant "TEXT_CODING(length=5)"
+}
+
+var My_char v_aaa:=’str’;
+// The encoded value: ’ str’
+*//Example number 4): centered character string*
+
+type charstring My_char2 with {
+variant "TEXT_CODING(length=5;just=center)"
+}
+
+var My_char2 v_aaaa:=’str’;
+// The encoded value: ’ str ’
+*//Example number 5): character string converted to upper case*
+type charstring My_char3 with {
+variant "TEXT_CODING(length=5;convert=upper_case)"
+}
+
+var my_char3 v_b:=’str’;
+
+// The encoded value: ’ STR’
+*//Example number 6): case converted character string*
+
+type charstring My_char4 with {
+variant "TEXT_CODING(convert=upper_case,convert=lower_case)"
+}
+
+var My_char4 v_bb:=’str’;
+// The encoded value: ’STR’
+// The decoded value: ’str’
+*//Example number 6): boolean*
+type boolean My_bool with {
+variant "TEXT_CODING(true:’good’;false:’bad’)"
+}
+
+var my_bool v_bbb=false;
+// The encoded value: ’bad’
+----
+
+[[bnf-of-the-attributes]]
+=== BNF of the Attributes
+[source]
+----
+COMMA = ","
+
+SEMI = ";"
+
+token = any valid character literal, "’" must be escaped
+
+pattern = valid TTCN-3 character pattern, the reference is not supported
+
+number = positive integer number
+
+enumerated = the name of the enumerated value
+
+attributes = attribute *(COMMA attribute)
+
+attribute = begin-attr / end-attr / separator-attr / coding-attr
+
+begin-attr = "BEGIN(" encode-token [ COMMA [ match-expr ] [COMMA modifier] ] ")"
+
+end-attr = "END(" encode-token [ COMMA [ match-expr ] [COMMA modifier] ] ")"
+
+separator-attr = "SEPARATOR(" encode-token [ COMMA [ match-expr ] [COMMA modifier] ] ")"
+
+coding-attr = "TEXT_CODING(" [ [encoding-rules] [COMMA [decoding-rules] [ COMMA match-expr [COMMA modifier] ] ] ] ")"
+
+encode-token = "’" token "’"
+
+match-expr = "’" pattern "’"
+
+modifier = "case_sensitive" / "case_insensitive"
+
+encoding-rules = encoding-rule *(SEMI encoding-rule)
+
+encoding-rule = attr-def / enc-enum / enc-bool
+
+decoding-rules = decoding-rule *(SEMI decoding-rule)
+
+decoding-rule = attr-def / dec-enum / dec-bool
+
+attr-def = ("length=" number )/ ("convert=" ("lower_case" / "upper_case") )/ ("just=" ("left"/"right"/"center") )/ ("leading0=" ("true"/"false") )/ ("repeatable=" ("true"/"false") )
+
+enc-enu = enumerated ":" encode-token
+
+enc-bool = ("true:" encode-token) / ("true:" encode-token)
+
+dec-enum = enumerated ":" "{" [match-expr] [COMMA modifier] "}"
+
+dec-bool = (true ":" "{" [match-expr] [COMMA modifier] "}")/(false ":" "{" [match-expr] [COMMA modifier] "}")
+----
+
+== XML Encoder and Decoder
+
+The XML encoder and decoder are handling XML-based protocols. The encoder converts abstract TTCN-3 structures (or types) into an XML representation. The decoder converts the XML data into values of abstract TTCN-3 structures.
+
+[[general-rules-and-restrictions-0]]
+=== General Rules and Restrictions
+
+The TTCN-3 standard defines a mechanism using attributes to define encoding variants. The attributes concerning the XML encoding are standardized in <<13-references.adoc#_4, [4]>> (annex B of the standard lists the attributes and their effects).
+
+Faults in the XML encoding/decoding process are set to error by default, but it can be modified with the `errorbehavior` TTCN–3 attribute. (<<codec-error-handling, Codec error handling>>)
+
+[[attributes-1]]
+=== Attributes
+
+The following sections describe the TTCN-3 attributes that influence the XML coding.
+
+*Abstract*
+
+Attribute syntax: abstract
+
+Applicable to (TTCN-3) Fields of unions
+
+Description This attribute shall be generated for each field with the XSD attribute "abstract`' set to true (usually during type substitution or element substitution). It can be used to distinguish XML messages with valid type or element substitutions from XML documents containing invalid substitutions.
+
+If the decoder finds an XML element or `xsi:type` attribute corresponding to an abstract union field, a coding error is displayed. The attribute has no effect on encoding.
+
+*Any element*
+
+Attribute syntax:
+[source]
+anyElement [ except ( 'freetext' | unqualified ) | from [unqualified ,] [ { 'freetext' , } 'freetext' ] ]
+
+Applicable to (TTCN-3) Fields of structured types generated for the XSD _any_ element
+
+Description One TTCN-3 attribute shall be generated for each field corresponding to an XSD any element. The freetext part(s) shall contain the URI(s) identified by the namespace attribute of the XSD any element. The namespace attribute may also contain wildcard. They shall be mapped as given in the following table:
+
+.XSD namespace attributes
+[cols=",,",options="header",]
+|===
+|_Value of the XSDnamespace attribute_ |*Except or from clause in the TTCN-3 attribute* |*Remark*
+|*##any* |_<nor except neither from clause present>_ |
+|*##local* |from unqualified |
+|*##other* |except '_<target namespace of the ancestor schema element of the given any element>'_ |Also disallows unqualified elements, i.e. elements without a target namespace
+|*##other* |except unqualified |In the case no target namespace is ancestor schema element of the given any element
+|*##targetNamespace* |from '_<target namespace of the ancestor schema element of the given any element >'_ |
+|*"http://www.w3.org/1999/xhtml ##targetNamespace"* |from `http://www.w3.org/1999/xhtml', '_<target namespace of the ancestor schema element of the given any element >'_ |
+|===
+
+The abstract value of the field will be encoded as an XML element in place of an XML element that would be generated for the field (ignoring the name of the field). During decoding, the abstract value of the field will contain the entire XML element.
+
+Example:
+[source]
+----
+type record AEProduct {
+  charstring name,
+  integer    price,
+  universal charstring info
+}
+with {
+  variant (info) "anyElement from 'http://www.example.com/A', "
+  "'http://www.example.com/B', unqualified"
+}
+const AEProduct aep := {
+  name  := "Trousers",
+  price := 20,
+  info  := "<xyz:color xmlns:xyz=""http://www.example.com/A"" available=""true"">red</xyz:color>"
+}
+
+/* XML encoding:
+<AEProduct>
+ <name>Trousers</name>
+ <price>20</price>
+ <xyz:color xmlns:xyz="http://www.example.com/A" available="true">red</xyz:color>
+</AEProduct>
+*/
+----
+
+*Any attributes*
+
+Attribute syntax:
+
+[source]
+anyAttributes[ except 'freetext' | from [unqualified ,] { 'freetext', } 'freetext']
+
+Applicable to (TTCN-3) Fields of structured types generated for the XSD _anyAttribute_ element
+
+Description This TTCN-3 attribute can be applied to a field which is of type *`record of universal charstring`*. Each component shall contain a valid XML attribute (name/value pair), optionally preceded by a namespace identifier (URI). The encoder shall remove the URI and insert it as a namespace declaration into the enclosing XML element, followed by the content of the *`universal charstring`* as an XML attribute. The decoder should recover each attribute into a component of the *`record of`*, preceded by its namespace URI if applicable. The mapping of namespaces behaves in the same way as the anyElement TTCN-3 attribute.
+
+Example:
+[source]
+----
+type record of universal charstring AttrList;
+type record AAProduct {
+  AttrList   info,
+  charstring name,
+  integer    price
+}
+with {
+  variant (info) "anyAttributes from 'http://www.example.com/A', "
+  "'http://www.example.com/B', unqualified"
+}
+
+const AAProduct aap := {
+  info := {
+    "http://www.example.com/A size=""small""",
+    "http://www.example.com/B color=""red""",
+    "available=""yes"""},
+  name := "Trousers",
+  price:= 20
+}
+
+/* XML encoding:
+<AAProduct
+ xmlns:b0="http://www.example.com/A" b0:size="small"
+ xmlns:b1="http://www.example.com/B" b1:color="red" available="yes">
+ <name>Trousers</name>
+ <price>20</price>
+</AAProduct>
+*/
+----
+
+*Attribute*
+
+Attribute syntax: attribute
+
+Applicable to (TTCN-3) Top-level type definitions and fields of structured types generated for XSD _attribute_ elements.
+
+Description This encoding instruction causes the instances of the TTCN3 type or field to be encoded and decoded as attributes.
+
+Comment Titan currently requires during decoding that attributes are present in the same order as they are declared in the enclosing record/set.
+
+Example
+[source]
+----
+type charstring Color
+with {
+  variant "attribute"
+}
+type record Product {
+  Color      color,
+  charstring material,
+  charstring name,
+  integer    price
+}
+with {
+  variant (available) "attribute"
+}
+
+const Product shoes := {
+  color := "blue",
+  material := "suede",
+  name := "Shoes",
+  price:= 25
+}
+/* XML encoding
+<Product color="blue" material="suede">
+ <name>Shoes</name>
+ <price>25</price>
+</Product>
+*/
+----
+
+*AttributeFormQualified*
+
+Attribute syntax: `attributeFormQualified`
+
+Applicable to (TTCN-3) Modules
+
+Description This encoding instruction cause names of XML attributes that are instances of TTCN-3 definitions in the given module to be encoded as qualified names. At decoding time qualified names are expected as valid attribute names.
+
+*Control namespace identification*
+
+Attribute syntax: `controlNamespace` '__freetext__' `prefix` '__freetext__'
+
+Applicable to (TTCN-3) Module
+
+Description The control namespace is the namespace to be used for the type identification attributes and schema instances (e.g. in the special XML attribute value "xsi:nil". It shall be specified globally, with an encoding instruction attached to the TTCN-3 module.The first _freetext_ component identifies the namespace (normally `http://www.w3.org/2001/XMLSchema-instance' is used), the second _freetext_ component identifies the namespace prefix (normally `xsi' is used).
+
+Please see the example for nillable elements, for example usage of `controlNamespace`.
+
+*Block*
+
+Attribute syntax: block
+
+Applicable to (TTCN-3) Fields of unions
+
+Description This attribute shall be generated for each field referred to by XSD `block` attributes (usually during type substitution or element substitution). It can be used to distinguish XML messages with valid type or element substitutions from XML documents containing invalid substitutions.
+
+If the decoder finds an XML element or `xsi:type` attribute corresponding to a blocked union field, a coding error is displayed. The attribute has no effect on encoding.
+
+*Default for empty*
+
+Attribute syntax: defaultForEmpty as '__freetext__'
+
+Applicable to (TTCN-3) TTCN-3 components generated for XSD _attribute_ or _element_ elements with a _fixed_ or _default_ attribute.
+
+Description The '__freetext__' component shall designate a valid value of the type to which the encoding instruction is attached to. This encoding instruction has no effect on the encoding process and causes the decoder to insert the value specified by _freetext_ if the corresponding attribute or element is omitted in the received XML document.
+
+Example
+[source]
+----
+type record DFEProduct {
+charstring color,
+charstring name,
+float price,
+charstring currency
+}
+
+with {
+variant (color) "attribute";
+variant (currency) "defaultForEmpty as `US Dollars"';
+}
+
+const DFEProduct rval := {
+color := "red",
+name := "shirt",
+price := 12.33,
+currency := "US Dollars"
+}
+
+/* The following XML fragment will be decoded to the value of rval:
+
+<DFEProduct color="red">
+<name>shirt</name>
+<price>12.33</price>
+<currency/>
+</DFEProduct>
+
+*/
+----
+
+NOTE: TITAN allows the usage of constants and module parameters instead of the text value of the encoding instruction. The type of the field must be compatible with the type of the constant or module parameter. The form where constants and module parameters are allowed looks like this:
+
+[source]
+variant "defaultForEmpty as reference";
+
+where reference is a constant or a module parameter. (Notice the missing apostrophe).
+
+For example:
+[source]
+----
+const integer c_int := 3;const charstring c_str := "abc";
+
+type record MyRecord {
+  integer i,
+  charstring cs,
+  float f
+  }
+  with {
+    variant (i) "defaultForEmpty as c_int"; // allowed
+    variant (cs) "defaultForEmpty as c_str"; // allowed
+    variant (f) "defaultForEmpty as c_str"; // not allowed
+    // incompatible types
+  }
+----
+
+*Element*
+
+Attribute syntax: element
+
+Applicable to (TTCN-3): Top-level type definitions generated for XSD _element_ elements that are direct children of a _schema_ element.
+
+Description: This encoding instruction causes the instances of the TTCN3 type to be encoded and decoded as XML elements.
+
+Comment: This is the default behaviour. TTCN-3 types are encoded as elements unless altered by an encoding instruction. This encoding instruction can be used to cancel that effect.
+
+*ElementFormQualified*
+
+Attribute syntax: elementFormQualified
+
+Applicable to (TTCN-3): Modules
+
+Description: This encoding instruction causes tags of XML local elements and templates of XSD definitions in the given module to be encoded as qualified names, and inserts the namespace specification in the encoded XML. Tags of XML global elements are always encoded as qualified names, regardless of elementFormQualified. At decoding time only qualified names are accepted as valid element tag names.
+
+*Embed values*
+
+Attribute syntax: embedValues
+
+Applicable to (TTCN-3): TTCN-3 record types generated for XSD _complexType_-s and _complexContent_-s with the value of the _mixed_ attribute "true".
+
+Description: The encoder shall encode the record type to which this attribute is applied in a way that produces the same result as the following procedure: first a partial encoding of the record is produced, ignoring the `embed_values` field. The first string of the `embed_values` field (the first record of element) shall be inserted at the beginning of the partial encoding, before the start-tag of the first XML element (if any). Each subsequent string shall be inserted between the end-tag of the XML element and the start-tag of the next XML element (if any), until all strings are inserted. In the case the maximum allowed number of strings is present in the TTCN-3 value (the number of the XML elements in the partial encoding plus one) the last string will be inserted after end-tag of the last element (to the very end of the partial encoding). The following special cases apply:
+
+. At decoding, strings before, in-between and following the XML elements shall be collected as individual components of the `embed_values` field.If no XML elements are present, and there is also a defaultForEmptyencoding instruction on the sequence type, and the encoding is empty, a decoder shall interpret it as an encoding for the _freetext_ part specified in the defaultForEmptyencoding instruction and assign this abstract value to the first (and only) component of the embed_values field.
+. If the type also has the useNilencoding instruction and the optional component is absent, then the embedValues encoding instruction has no effect.
+. If the type has a useNilencoding instruction and if a decoder determines, by the absence of a nil identification attribute (or its presence with the value false) that the optionalcomponent is present, then item a) above shall apply.
+
+NOTE: Titan currently does not decode the values of the embed_values member. They will appear as empty strings.
+
+Example
+[source]
+----
+type record EmbProduct {
+record of universal charstring embed_values,
+universal charstring companyName,
+universal charstring productColor,
+universal charstring productName
+}
+
+with {
+variant "embedValues"
+}
+
+const EmbProduct rval := {
+embed_values := {"My Company", "produces", "", "which is very popular"},
+ompanyName := "ABC",
+productColor := "red",
+productName := "shirt"
+}
+
+/* XML encoding
+
+<EmbProduct>My Company<companyName>ABC</companyName>produces<productColor>red</productColor> <productName>shirt</productName>which is very popular</EmbProduct>
+
+*/
+----
+
+*Form*
+
+Attribute syntax: form as (qualified | unqualified)
+
+Applicable to (TTCN-3): Top-level type definitions generated for XSD _attribute_ elements and fields of structured type definitions generated for XSD _attribute_ or _element_ elements.
+
+Description: This encoding instruction designates that names of XML attributes or tags of XML local elements corresponding to instances of the TTCN-3 type or field of type to which the form encoding instruction is attached, shall be encoded as qualified or unqualified names respectively and at decoding qualified or unqualified names shall be expected respectively as valid attribute names or element tags.
+
+*List*
+
+Attribute syntax: list
+
+Applicable to (TTCN-3): Record-of types mapped from XSD _simpleType_-s derived as a list type.
+
+Description: This encoding instruction designates that the record of type shall be handled as an XSD list type, namely, record of elements of instances shall be combined into a single XML list value using a single SP(32) (space) character as separator between the list elements. At decoding the XML list value shall be mapped to a TTCN-3 record of value by separating the list into its itemType elements (the whitespaces between the itemType elements shall not be part of the TTCN-3 value).
+
+Example
+[source]
+----
+type record of integer Pi;
+with {
+variant "list"
+}
+
+const Pi digits := {
+3, 14, 15, 9, 26
+}
+
+/* XML encoding
+<S>3 14 15 9 26</S>
+*/
+----
+
+*Name*
+
+[[changeCase]]
+Attribute syntax:
+[source]
+name (as ("freetext" | changeCase ) | all as changeCase ), wherechangeCase := ( capitalized | uncapitalized | lowercased | uppercased )
+
+Applicable to (TTCN-3): Type or field of structured type. The form when _freetext_ is empty shall be applied to fields of union types with the "useUnion" encoding instruction only
+
+Description: The name encoding instruction is used when the name of the XML element or attribute differs from the name of the TTCN3 definition or field. The name resulted from applying the name encoding attribute shall be used as the non-qualified part of the name of the corresponding XML attribute or element tag.
+
+When the "name as `__freetext__"' form is used, _freetext_ shall be used as the attribute name or element tag, instead of the name of the related TTCN-3 definition (e.g. TTCN-3 type name or field name).
+
+The "name as "" (i.e. freetext is empty) form designates that the TTCN-3 field corresponds to an XSD unnamed type, thus its name shall not be used when encoding and decoding XML documents.
+
+The "name as capitalized" and "name as uncapitalized" forms identify that only the first character of the related TTCN3 type or field name shall be changed to lower case or upper case respectively.
+
+The "name as lowercased“ and"name as uppercased" forms identify that each character of the related TTCN3 type or field name shall be changed to lower case or upper case respectively.
+
+The "name all as capitalized", "name all as uncapitalized", "name as lowercased" and "name as uppercased" forms has effect on all direct fields of the TTCN-3 definition to which the encoding instruction is applied (e.g. in case of a structured type definition to the names of its fields in a non-recursive way but not to the name of the definition itself and not to the name of fields embedded to other fields).
+
+Example
+[source]
+----
+type record S {
+charstring r,
+charstring blue,
+charstring black
+}
+
+with {
+variant (r) "name as `Red"';
+variant (blue) "name as uppercased";
+variant (black) "name as capitalized";
+}
+
+const NM outfit := { r := "shirt", blue := "trousers", black := "shoes" }
+
+/* XML encoding
+
+<S>
+
+<Red>shirt</Red>
+<BLUE>trousers</BLUE>
+<Black>shoes</Black>
+</S>
+
+*/
+----
+
+*Namespace identification*
+
+Attribute syntax: namespace as '__freetext__' [prefix "freetext"]
+
+Applicable to (TTCN-3): Modules; fields of record types generated for _attribute_s of _complexTypes_ taken in to _complexType_ definitions by referencing _attributeGroup_(s), defined in _schema_ elements with a different (but not absent) target namespace and imported into the _schema_ element which is the ancestor of the _complexType._
+
+Description: The first _freetext_ component identifies the namespace to be used in qualified XML attribute names and element tags at encoding, and to be expected in received XML documents. The second _freetext_ component is optional and identifies the namespace prefix to be used at XML encoding. If the prefix is not specified, the encoder shall either identify the namespace as the default namespace (if all other namespaces involved in encoding the XML document have prefixes) or shall allocate a prefix to the namespace (if more than one namespace encoding instructions are missing the prefix part).
+
+Example
+[source]
+----
+type record S {
+charstring firstName,
+charstring lastName,
+charstring middleInitial
+}
+
+with { variant "namespace as `http://www.example.org/test' prefix `tst"' }
+const S jrh := { "John", "Doe", "M" }
+
+/* XML encoding
+
+<tst:S xmlns:tst="http://www.example.org/test">
+<firstName>John</firstName>
+<lastName>Doe</lastName>
+<middleInitial>M</middleInitial>
+</tst:S>
+
+*/
+----
+
+*Nillable elements*
+
+Attribute syntax: useNil
+
+Applicable to (TTCN-3): Top-level record types or record fields generated for nillable XSD _element_ elements.
+
+Description: The encoding instruction designates that the encoder, when the optional field of the record (corresponding to the nillable element) is omitted, shall produce the XML element with the xsi:nil="true" attribute and no value. When the nillable XML element is present in the received XML document and carries the xsi:nil="true" attribute, the optional field of the record in the corresponding TTCN-3 value shall be omitted. If the nillable XML element carries the xsi:nil="true" attribute and has children (either any character or element information item) at the same time, the decoder shall initiate a test case error.
+
+Example
+[source]
+----
+module UseNil {
+type record Size {
+  integer sizeval optional
+}
+with { variant "useNil" }
+
+type record NilProduct {
+  charstring name,
+  ProductColor color,
+  Size size
+}
+
+const NilProduct absent := {
+  name  := "no shirt",
+  color := red,
+  size  := { omit }
+}
+
+const NilProduct present := {
+  name  := "shirt",
+  color := red,
+  size  := { 10 }
+}
+
+}
+with {
+  encode "XML";
+  variant "controlNamespace 'http://www.w3.org/2001/XMLSchema-instance' prefix 'xsi'"
+}
+/* XML encoding of absent:
+<Product xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+<name>no shirt</name>
+ <color>red</color>
+ <size xsi:nil="true"/>
+</Product>
+
+XML encoding of present:
+<Product xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+<name>shirt</name>
+ <color>red</color>
+ <size xsi:nil="false">10</size>
+</Product>
+
+Another possible XML encoding of present:
+<Product xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+<name>shirt</name>
+ <color>red</color>
+ <size>10</size>
+</Product>
+*/
+----
+
+*Text*
+
+Attribute syntax:
+
+[source]
+text ("name" as ("freetext"|) | all as changeCase)
+
+where `changeCase` has been defined as seen <<changeCase, here>>.
+
+Applicable to (TTCN-3) Enumeration types generated for XSD enumeration facets where the enumeration base is a string type, and the name(s) of one or more TTCN-3 enumeration values are different from the related XSD enumeration item. Also applies to XSD.Boolean types, instances of XSD.Boolean types.
+
+Description When _name_ is used, it shall be generated for the differing enumerated values only. The _name_ shall be the identifier of the TTCN-3 enumerated value the given instruction relates to. If the difference is that the first character of the XSD enumeration item value is a capital letter while the identifier of the related TTCN-3 enumeration value starts with a small letter, the "text `__name__' as capitalized" form shall be used. Otherwise, _freetext_ shall contain the value of the related XSD enumeration item.If the first characters of all XSD enumeration items are capital letters, while the names of all related TTCN-3 enumeration values are identical to them except the case of their first characters, the "text all as capitalized" form shall be used.The encoding instruction designates that the encoder shall use _freetext_ or the capitalized name(s) when encoding the TTCN-3 enumeration value(s) and vice versa.When the text encoding attribute is used with XSD.Boolean types, the decoder shall accept all four possible XSD boolean values and map the received value 1 to the TTCN-3 boolean value *true* and the received value 0 to the TTCN-3 boolean value *false*. When the text encoding attribute is used on the instances of the XSD.Boolean type, the encoder shall encode the TTCN3 values according to the encoding attribute (i.e. *true* as 1 and *false* as 0).
+
+Comment For XSD.Boolean types, either of the forms "text 'true' as "1" and "text 'false' as '0' implies the other, i.e. Titan considers that both have been specified. Together, these two forms have the same effect as "text" (detailed in the last paragraph of Description).
+
+Example
+[source]
+----
+type enumerated ProductColor { red(0), light_green(1), blue(2) }
+with {
+variant "text `red' as uppercased";
+variant "text `light_green' as `Light Green"'
+variant "text `blue' as capitalized"
+};
+
+type boolean Availability
+with {
+variant "text"
+}
+
+type record T {
+ProductColor color,
+Availability available
+}
+
+const T prod := {
+color := light_green,
+available := true
+}
+
+/* XML encoding
+
+<S>
+<color>Light Green</color>
+<available>1</available>
+</S>
+
+*/
+----
+
+*Untagged*
+
+Attribute syntax: untagged
+
+Applicable to (TCN-3): Type; or field of a record, set, union; or the embedded type of a record-of or set-of. This encoding instruction is ignored if applied to a type which is encoded as the top-level type, unless the top-level type is a union or anytype. It will take effect when a field of this type is encoded as a component of the enclosing structured type.
+
+Description: The encoding instruction designates that the encoder shall omit the tag.
+
+Example: "untagged" applied to a field.
+[source]
+----
+*type* *record* Prod {
+*charstring* name,
+*float* price,
+*charstring* description
+}
+
+*with* {
+*variant* (description) "untagged"
+}
+
+*const* Prod prod := {
+name := "Danish Blue",
+price := 3.49,
+description := "Soft blue cheese"
+}
+
+/* generated XML:
+<Prod>
+<name>Danish Blue</name>
+<price>3.490000</price>
+Soft blue cheese</Prod>
+*/
+
+Example: "untagged" applied to a union type.
+*type* *union* ProdUnion {
+*Prod* prod1,
+*OtherProd* prod2
+}
+
+*with* {
+*variant* "untagged"
+}*const* ProdUnion produnion := { prod1 := {
+name := "ProdName",
+price := 66,
+description := "The best product" }
+}
+
+/* generated XML:
+<Prod>
+<name>ProdName</name>
+<price>66</price>
+The best product</Prod>
+*/
+----
+
+*Use number*
+
+Attribute syntax: useNumber
+
+Applicable to (TTCN-3) Enumeration types generated for XSD enumeration facets where the enumeration base is integer
+
+Description The encoding instruction designates that the encoder shall use the integer values associated to the TTCN-3 enumeration values to produce the value of the corresponding XML attribute or element (as opposed to the names of the TTCN-3 enumeration values) and the decoder shall map the integer values in the received XML attribute or element to the appropriate TTCN-3 enumeration values.
+
+Example
+[source]
+[source]
+----
+type enumerated ProductColor { red(0), green(1), blue(2) }
+with {
+variant "useNumber"
+}
+
+type record NrProduct {
+charstring name,
+ProductColor color,
+integer size
+}
+
+const NrProduct rval := {
+name := "shirt",
+color := red,
+size := { sizeval := 10 }
+}
+
+/* XML encoding:
+<NrProduct>
+<name>shirt</name>
+<color>0</color>
+<size>10</size>
+</NrProduct>
+*/
+----
+
+*Use order*
+
+Attribute syntax: useOrder
+
+Applicable to (TTCN-3) Record type definition, generated for XSD _complexType_-s with _all_ constructor
+
+Description The encoding instruction designates that the encoder shall encode the values of the fields corresponding to the children elements of the _all_ constructor according to the order identified by the elements of the *order* field. At decoding, the received values of the XML elements shall be placed in their corresponding record fields and a new record of element shall be inserted into the *order* field for each XML element processed (the final order of the record of elements shall reflect the order of the XML elements in the encoded XML document).
+
+Example
+[source]
+----
+type record UOProduct {
+record of enumerated { id, name, price, color } order,
+integer id,
+charstring name,
+float price,
+charstring color
+}
+
+with {
+variant "useOrder";
+}
+
+const UOProduct rval := {
+order := { id, color, price, name },
+id := 100,
+name := "shirt",
+price := 12.23,
+color := "red"
+}
+
+/* XML encoding:
+<UOProduct>
+<id>100</id>
+<color>red</color>
+<price>12.230000</price>
+<name>shirt</name>
+</UOProduct>
+*/
+----
+
+*Use union*
+
+Attribute syntax: useUnion
+
+Applicable to (TTCN-3) unions (all alternatives of the union must be character-encodable)
+
+Description The encoding instruction designates that the encoder shall not use the start-tag and the end-tag around the encoding of the selected alternative (field of the TTCN-3 union type). A type identification attribute (`xsi:type`, where `xsi` is the prefix of the control namespace) can be used to identify the selected alternative, or the encoding of the alternatives must be distinct enough that the decoder can determine the selected field based solely on its value. The decoder shall place the received XML value into the corresponding alternative of the TTCN-3 `union` type, based on the received value and the type identification attribute, if present. The encoder will always use the type identification `attribute` to identify the selected field whenever possible. If the union has the attribute or `untagged` encoding instructions, or is the component of a `record` `of` or set of with the `list` encoding instruction, then the insertion of the type identification attribute is not possible.
+
+Comment There is no check implemented to ensure the fields are sufficiently distinct. If no type identification attribute is present, the first field (in the order of declaration) that manages to successfully decode the XML value will be the selected alternative.
+
+Restrictions The use of the XSD type `QName` or other unions with the `useType` or `useUnion` coding instructions as alternatives are not supported. The `useType` or `useUnion` coding instructions cannot be applied to `anytype`.
+
+Example 1
+[source]
+----
+type union ProductId {
+integer c1,
+integer c2,
+integer c3
+}
+
+with {
+variant "useUnion"
+}
+
+const Product rval := {
+id := { c2 := 100 },
+price := 25.34,
+color := "green"
+}
+
+/*
+<Product xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+<id xsi:type="c2">100</id>
+<price>2.534E1</price>
+<color>green</color>
+</Product>
+
+*/
+Example 2
+type union IntStr {
+integer int,
+charstring str
+}
+
+with {
+variant "useUnion"
+}
+
+type record Data {
+IntStr atr,
+record of IntStr values
+}
+
+with {
+variant(atr) "attribute";
+variant(values) "list";
+}
+
+const Data d := {
+atr := { int := 26 },
+values := { { str := "abc" }, { str := "x" }, { int := -7 } }
+}
+
+/*
+
+<Data xmlns:xsi=`http://www.w3.org/2001/XMLSchema-instance' atr=`26'>
+<values>abc x -7</values>
+</Data>
+*/
+----
+
+*Use type*
+
+Attribute syntax: useType
+
+Applicable to (TTCN-3) unions
+
+Description The encoding instruction designates that the encoder shall not use the start-tag and the end-tag around the encoding of the selected alternative (field of the TTCN-3 union type), a type identification attribute (`xsi:type`, where `xsi` is the prefix of the control namespace) will be used to identify the selected alternative. This attribute may be omitted in the case of the first alternative. The decoder shall place the received XML value into the corresponding alternative of the TTCN-3 `union` type, based on the received value and the type identification attribute. The first alternative will be selected if this attribute is not present. The encoder will never insert the type identification attribute for the first alternative. Any attributes the selected alternative might have will be inserted to the union’s XML tag instead (after the type identification attribute, if it exists).
+
+The `useType` or `useUnion` coding instructions cannot be applied to anytype.
+
+Example
+[source]
+----
+type record Shirt {
+charstring color,
+charstring make,
+integer size
+}
+
+type record Trousers {
+boolean available,
+charstring color,
+charstring make
+} with {
+variant(available) "attribute"
+}
+
+type record Shoes {
+boolean available,
+string color,
+integer size
+} with {
+variant(available) "attribute"
+}
+
+type union Product {
+Shirt shirt,
+Trousers trousers,
+Shoes shoes
+} with {
+variant "useType"
+}
+
+const Product pr1 := {
+shoes := {
+available := false,
+color := "red",
+size := 9
+}
+}
+/*
+
+<Product xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’ xsi:type=’shoes’ available=’false’>
+<color>red</color>
+<size>9</size>
+</Product>
+
+*/
+const Product pr2 := {
+shirt := {
+color := "red",
+make := "ABC Company",
+size := 9
+}
+}
+
+/*
+
+<Product xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’>
+<color>red</color>
+<make>ABC Company</make>
+<size>9</size>
+</Product>
+*/
+----
+
+*Whitespace control*
+
+Attribute syntax: whitespace (preserve|replace|collapse)
+
+Applicable to (TTCN-3) String types or fields of structured types generated for XSD components with the _whitespace_ facet.
+
+Description The encoding instruction designates that the encoder shall normalize the encoded XML values corresponding to the TTCN-3 construct with the whitespace encoding instruction, and the received XML value shall be normalized before decoding as below.
+
+* preserve: no normalization shall be done, the value is not changed.
+* replace: all occurrences of HT(9) (horizontal tabulation), LF(10) (line feed) and CR(13) (carriage return) shall be replaced with an SP(32) (space) character.
+* collapse: after the processing implied by replace, contiguous sequences of SP(32) (space) characters are collapsed to a single SP(32) (space) character, and leading and trailing SP(32) (space) characters are removed.
+
+Example 1
+[source]
+----
+type charstring R
+with {
+variant "whiteSpace replace"
+}
+
+const R rval := "First Line Second Line";
+/* The following is a possible XML encoding of `rval'. During decoding it will be normalized to the value of `rval'.
+<R>First
+Line
+Second
+Line</R>
+*/
+----
+
+Example 2
+[source]
+----
+type charstring C
+with {
+variant "whiteSpace collapse"
+}
+
+const C cval := "First Line Second Line";
+/* The follwing is a possible XML encoding of `cval'. During decoding it will be normalized to the value of `cval'.
+<C>
+First Line
+Second Line
+</C>
+*/
+----
+
+[[external-functions]]
+=== External functions
+
+XML encoder / decoder functions must have the "`encode(XER)`" / "`decode(XER)`" attribute set.
+
+The following XML coding options can be specified: `XER_BASIC`, `XER_EXTENDED`, `XER_CANONICAL`. These can be used by writing for example: "`encode(XER:XER_EXTENDED)`" / "`decode(XER:XER_EXTENDED)`".
+
+Faults in the XML encoding/decoding process produce errors by default, but this can be modified with the `errorbehavior` attribute. (link:#codec-error-handling[Codec error handling])
+
+XML encoder functions can also have the "`printing(compact)`" or "`printing(pretty)`" attributes. This specifies whether the encoder should add extra white spaces to the XML code or not. This attribute cannot be set at module level.
+
+If compact printing is selected no white spaces are added to the XML code, making it as short as possible, except at the end of the XML code there will always be a new-line character.
+
+Pretty printing makes the code easier to read by adding spaces, new lines and indenting.
+
+For example:
+[source]
+----
+external function f_enc_MyRecord(in MyRecord par) return octetstring with { extension "prototype(convert) encode(XER:XER_EXTENDED) printing(pretty)" }
+
+external function f_dec_MyRecord(in MyRecord par) return octetstring with { extension "prototype(convert) decode(XER:XER_EXTENDED) printing(pretty)" }
+----
+
+== JSON Encoder and Decoder
+
+The JSON encoder and decoder handles JSON-based protocols. The encoder converts abstract TTCN-3 structures (or types) into a JSON representation (see RFC 7159). The decoder converts JSON data into values of abstract TTCN-3 structures.
+
+This section covers the coding rules in general, the attributes controlling them and the encoder / decoder external functions.
+
+[[general-rules-and-restrictions-1]]
+=== General rules and restrictions
+
+You can use the encoding rules defined in this section to encode and decode the following TTCN–3 types:
+* anytype
+* array
+* bitstring
+* boolean
+* charstring
+* enumerated
+* float
+* hexstring
+* integer
+* objid
+* octetstring
+* record, set
+* record of, set of
+* union
+* universal charstring
+* verdicttype
+
+The rules also apply to the following ASN.1 types (if imported to a TTCN-3 module):
+
+* ANY
+* BIT STRING
+* BOOLEAN
+* BMPString
+* CHOICE, open type (in instances of parameterized types)
+* ENUMERATED
+* GeneralString
+* GraphicString
+* IA5String
+* INTEGER
+* NULL
+* NumericString
+* OBJECT IDENTIFIER
+* OCTET STRING
+* PrintableString
+* RELATIVE-OID
+* SEQUENCE, SET
+* SEQUENCE OF, SET OF
+* TeletexString
+* UniversalString
+* UTF8String
+* VideotexString
+* VisibleString
+
+JSON encoding and decoding is allowed for types with the attribute "encode` "`JSON`"'. The basic types specified in the list above support JSON encoding and decoding by default.
+
+The attribute "encode` "`JSON`"' can also be set globally (at module level), allowing JSON coding for all types defined in that module.
+
+Types imported from ASN.1 modules (from the list above) automatically have JSON coding allowed and cannot have JSON variant attributes.
+
+When using <<legacy-codec-handling, legacy codec handling>> the encode attribute can be omitted if the type has at least one JSON variant attribute (see <<attributes-2, here>>).
+
+Additional requirements for JSON encoding and decoding when using legacy codec handling:
+* in case of records, sets, unions and ASN.1 open types every field must also support JSON coding;
+* in case of array, record of and set of structures the element type must also support JSON coding.
+
+[[basic-types]]
+==== Basic types
+
+The basic TTCN-3 types are encoded as JSON values.
+
+All integer values and most float values are encoded as JSON numbers. The special float values `infinity`, `-infinity` and `not_a_number` are encoded as JSON strings.
+
+Boolean values are encoded with the JSON literals `true` and `false`.
+
+Bitstring, hexstring and octetstring values (and values of the ASN.1 ANY type) appear as JSON strings containing the bits or hex digits as characters.
+
+Charstrings, universal charstrings and values of ASN.1 string types are encoded as JSON strings. Charstrings appear exactly like in TTCN-3. Universal charstrings will appear in UTF-8 encoding. JSON strings may contain the escaped character `\u` followed by 4 hex digit characters, the decoder will convert this into the character represented by the hex digits.
+
+Object identifiers are encoded as JSON strings containing the components (in number form) separated by dots.
+
+Verdicttype and enumerated types are encoded as JSON strings. The string contains the name of the verdict type or enumerated value.
+
+The ASN.1 NULL value is encoded with the JSON literal `null`.
+
+NOTE: the JSON decoder ignores all type restrictions and will successfully decode values that contradict them (e.g.: a `record of/set of` type with the `length (3..5)` restriction will successfully decode an array of 8 elements), with the exception of arrays. The restrictions of ASN.1 string types are ignored aswell (e.g.: `NumericStrings` can decode strings containing letters).
+
+==== Structured types
+
+Array, record of and set of structures are encoded as JSON arrays. Their elements will appear in the order they appear in TITAN.
+
+Records and sets are encoded as JSON objects. The JSON object will contain the field name and value pairs of each field in the order they are declared in. Omitted optional fields will be skipped.
+
+The decoder will accept the record / set field name and value pairs in any order, but every non-optional field must be present. Optional fields that do not appear in the JSON object will be omitted.
+
+Unions, anytypes and ASN.1 open types are encoded as JSON objects. The object will contain one name-value pair: the name of the selected field and its value.
+
+[[attributes-2]]
+=== Attributes
+
+The following sections describe the TTCN-3 attributes that influence JSON coding (only affects TTCN-3 types, ASN.1 types cannot have attributes that influence JSON coding).
+
+All JSON attributes begin with the word `JSON' followed by a colon (`JSON:<attribute>`). Any number of white spaces (spaces and tabs only) can be added between each word or identifier in the attribute syntax, but at least one is necessary if the syntax does not specify a separator (a comma or a colon). The attribute can also start and end with white spaces.
+
+Alternatively the syntaxes defined in <<13-references.adoc#_25, [25]>> can also be used, for the supported attributes (without the need for the `JSON`: prefix).
+
+Example:
+[source]
+----
+variant(field1) “JSON:omit as null”;			// ok
+variant(field2) “ JSON : omit as null ”;			// ok (extra spaces)
+variant(field3) “JSON	:	omit	as	null”;	// ok (with tabs)
+variant(field4) “JSON:omitasnull”;			// not ok
+----
+
+*Omit as null*
+
+Attribute syntax: omit as null
+
+Applicable to (TTCN-3): Optional fields of records and sets
+
+Description: If set, the value of the specified optional field will be encoded with the JSON literal `null` if the value is omitted. By default omitted fields (both their name and value) are skipped entirely. The decoder ignores this attribute and accepts both versions.
+
+Example:
+[source]
+----
+type record PhoneNumber {
+  integer countryPrefix optional,
+  integer networkPrefix,
+  integer localNumber
+} with {
+  variant(countryPrefix) “JSON:omit as null”
+}
+var PhoneNumber pn := { omit, 20, 1234567 }
+// JSON code with the attribute:
+// {“countryPrefix”:null,”networkPrefix”:20, “localNumber”:1234567}
+// JSON code without the attribute:
+// {”networkPrefix”:20, “localNumber”:1234567}
+----
+
+*Name as …*
+
+Attribute syntax: name as <alias>
+
+Applicable to (TTCN-3): Fields of records, sets and unions
+
+Description: Gives the specified field a different name in the JSON code. The encoder will use this alias instead of the field’s name in TTCN-3, and the decoder will look for this alias when decoding this field. The syntax of the alias is the same as the syntax of an identifier in TITAN (regex: [A-Za-z][A-Za-z0-9_]*).
+
+Example:
+[source]
+----
+type union PersionID {
+  integer numericID,
+  charstring email,
+  charstring name
+} with {
+  variant(numericID) "JSON:name as ID";
+  variant(email) "JSON:name as Email";
+  variant(name) "JSON:name as Name";
+}
+type record of PersionID PersionIDs;
+var persionIDs pids := { { numericID := 189249214 }, { email := “jdoe@mail.com” }, { name := “John Doe” } };
+// JSON code:
+// [{“ID”:189249214},{“Email”:“jdoe@mail.com”},{“Name”:“John Doe”}]
+
+----
+
+*As value*
+
+Attribute syntax: as value
+
+Applicable to (TTCN-3): Unions, the anytype, or records or sets with one field
+
+Description: The union, record, set or anytype will be encoded as a JSON value instead of as a JSON object with one name-value pair (the name of the selected field in case of unions and the anytype, or the name of the one field in case of records and sets will be omitted, as well as the surrounding braces). This allows the creation of heterogenous arrays in the JSON document (e.g. ["text",10,true,null]).Since the field name no longer appears in the JSON document, the decoder will determine the selected field (in case of unions and the anytype) based on the type of the value. The first field (in the order of declaration) that can successfully decode the value will be the selected one.
+
+This attribute can also be applied to fields of records, sets or unions, or to the element types of records of, sets of or arrays, if they meet the mentioned restrictions. In this case these fields or elements are encoded as JSON values when they are encoded as part of their larger structure (but the types of these fields or elements might be encoded as JSON objects when encoded alone, or as parts of other structures).
+
+NOTE: Pay close attention to the order of the fields when using this attribute on unions and the anytype. It’s a good idea to declare more restrictive fields before less restrictive ones (e.g.: hexstring is more restrictive than universal charstring, because hexstring can only decode hex digits, whereas universal charstring can decode any character; see also examples below).
+
+Examples:
+[source]
+----
+// Example 1: unions
+type union U1 { // good order of fields
+  integer i,
+  float f,
+  octetstring os,
+  charstring cs
+} with {
+  variant “JSON : as value”
+}
+
+type union U2 { // bad order of fields
+  float f,
+  integer i,
+  charstring cs,
+  octetstring os
+} with {
+  variant “JSON : as value”
+}
+
+type record of U1 RoU1;
+type record of U2 RoU2;
+
+var RoU1 v_rou1 := { { i := 10 }, { f := 6.4 }, { os := ‘1ED5’O }, { cs := “hello” } };
+var RoU2 v_rou2 := { { i := 10 }, { f := 6.4 }, { os := ‘1ED5’O }, { cs := “hello” } };
+
+// Both v_rou1 and v_rou2 will be encoded into:
+// [10,6.4,“1ED5”,“hello”]
+// This JSON document will be decoded into v_rou1, when decoding as type RoU1,
+// however it will not be decoded into v_rou2, when decoding as RoU2, instead // the float field will decode both numbers and the charstring field will
+// decode both strings: { { f := 10.0 }, { f := 6.4 }, { cs := “1ED5” },
+// { cs := “hello” } };
+
+// Example 2: record with one field
+type record R {
+  integer field
+}
+with {
+  variant “JSON: as value”
+}
+type record of R RoR;
+const RoR c_recs := { { field := 3 }, { field := 6 } };
+// is encoded into: [3,6]
+
+// Example 3: anytype (this can only be done as a field or element of a
+// structure, since coding instructions cannot be defined for the anytype)
+module MyModule {
+type record AnyRec {
+  anytype val
+}
+with {
+  variant (val) “JSON: as value”;
+  variant (val) “JSON: name as value”;
+}
+const AnyRec c_val := { val := { charstring := “abc” } };
+// is encoded into: {“value”:“abc”}
+...
+} // end of module
+with {
+  extension “anytype integer, charstring”
+}
+----
+
+*Default*
+
+Attribute syntax: default(<value>)
+
+Applicable to (TTCN-3): Fields of records and sets
+
+Description: The decoder will set the given value to the field if it does not appear in the JSON document. The <value> can contain the JSON encoding of a value of the field’s type (only basic types are allowed). String types don’t need the starting and ending quotes. All JSON escaped characters can be used, plus the escape sequence ")" will add a ")" (right round bracket) character.
+
+The only allowed structured value is the empty structure value `{}`, which can be set for `record of` and `set of` types, as well as empty `record` and `set` types.
+
+Optional fields with a default value will be set to `omit` if the field is set to `null` in JSON code, and will use the default value if the field does not appear in the JSON document.
+
+Example:
+[source]
+----
+type record Product {
+  charstring name,
+  float price,
+  octetstring id optional,
+  charstring from
+} with {
+  variant(id) “JSON : default (FFFF)”
+  variant(from) “JSON:default(Hungary)”
+}
+
+// { “name” : “Shoe”, “price” : 29.50 } will be decoded into:
+// { name := “Shoe”, price := 29.5, id := ‘FFFF’O, from := “Hungary” }
+
+// { “name” : “Shirt”, “price” : 12.99, “id” : null } will be decoded into:
+// { name := “Shirt”, price := 12.99, id := omit, from := “Hungary” }
+----
+
+*Extend*
+
+Attribute syntax: extend(<key>):(<value>)
+
+Applicable to (TTCN-3): Any type
+
+Description: Extends the JSON schema segment generated for this type with the specified key-value pair. The <value> is inserted as a string value.
+
+Both <key> and <value> are strings that can contain any character of a JSON string, plus the escape sequence `)' can be used to add a `)' (right round bracket) character.
+
+This attribute can be set multiple times for a type, each key-value pair is inserted as a field to the end of the type’s schema. Extending a schema with multiple fields with the same key produces a warning. Using one of the keywords used in the generated schema also produces a warning.
+
+This attribute only influences schema generation. It has no effect on encoding or decoding values.
+
+*Metainfo for unbound*
+
+Attribute syntax metainfo for unbound
+
+Applicable to (TTCN-3) Records, sets and fields of records and sets
+
+Description Allows the encoding and decoding of unbound fields with the help of a meta info field. The attribute can be set to fields individually, or to the whole `record/set` (which is equal to setting the attribute for each of its fields).
+
+The encoder sets the field’s value in JSON to `null` and inserts an extra (meta info) field into the JSON object. The meta info field’s name is `metainfo <fieldname>`, where <fieldname> is the name of the unbound field (or its alias, if the `name as …` attribute is set). Its value is `unbound` (as a JSON string).
+
+The decoder accepts the meta info field regardless of its position in the JSON object (it can even appear before the field it refers to). If the meta info field’s value is not `unbound`, or it refers to a field that does not exist or does not have this attribute set, then an encoding error is displayed. The referenced field must either be `null` or a valid JSON value decodable by the field.
+
+Example:
+[source]
+----
+// Example 1: meta info for a single field
+type record Rec {
+  integer num,
+  charstring str
+}
+with {
+  variant(str) "JSON: metainfo for unbound";
+}
+
+// { num := 6, str := <unbound> } is encoded into:
+// {“num”:6,”str”:null,”metainfo str”:”unbound”}
+
+// Example 2: meta info for the whole set (with “name as” and optional field)
+type set Set {
+  integer num,
+  charstring str,
+  octetstring octets optional
+}
+with {
+  variant " JSON : metainfo for unbound ";
+  variant (num) " JSON : name as int ";
+}
+
+// { num := <unbound>, str := "abc", octets := <unbound> } is encoded into:
+// {“int”:null,”metainfo int”:”unbound”,”str”:”abc”,”octets”:null,
+// ”metainfo octets”:”unbound”}
+
+// Example 3: other values accepted by the decoder
+// (these cannot be produced by the encoder)
+
+// { "int" : 3, "str" : "abc", "octets" : "1234", "metainfo int" : "unbound" }
+// is decoded into: { num := <unbound>, str := “abc”, octets := ‘1234’O }
+
+// {"metainfo int" : "unbound", "int" : null, "str" : "abc", "octets" : "1234"}
+// is decoded into: { num := <unbound>, str := “abc”, octets := ‘1234’O }
+----
+
+*As number*
+
+Attribute syntax: as number
+
+Applicable to (TTCN-3): Enumerated types
+
+Description: If set, the enumerated value’s numeric form will be encoded as a JSON number, instead of its name form as a JSON string.
+
+Similarly, the decoder will only accept JSON numbers equal to an enumerated value, if this attribute is set.
+
+Example:
+[source]
+----
+type enumerated Length { Short (0), Medium, Long(10) }
+with {
+  variant “JSON: as number”
+}
+type record of Length Lengths;
+const Lengths c_len := { Short, Medium, Long };
+// is encoded into: [ 0, 1, 10 ]
+----
+
+*Chosen*
+
+Attribute syntax: chosen (<parameters>)
+
+Applicable to (TTCN-3): Union fields of records and sets
+
+Description: This attribute indicates that the fields of the target `union` will be encoded without field names (as if the `union` had the attribute as `value`), and that the selected field in the `union` will be determined by the values of other fields in the parent `record`/`set`, as described by the rules in the attribute’s parameters.
+
+The attribute’s parameters are a list of rules, separated by semicolons (;). Each rule consists of a field name from the `union` (or `omit`, if the `union` is an optional field in the parent `record`/`set`), and a condition (or list of conditions). If the condition is true, then the specified field will be selected (or the field will be omitted). If there are multiple conditions, then only one of them needs to be true for the specified field to be selected.
+
+The rules have the following syntax:
+
+_<field or omit>, <condition>;_
+
+if there’s only one condition, *or*
+
+_<field or omit>, { <condition1>, <condition2>, … };_
+
+if there are multiple conditions.
+
+The syntax of a condition is
+
+_<field reference> = <value>_
+
+or the keyword `otherwise` (which is true if all other conditions are false).
+
+The <field reference> is a reference to a field within the record/set. It can contain multiple field names to indicate an embedded field, but it cannot contain array indexes.
+
+The <value> can be any value of a built-in type.
+
+The rules do not affect JSON encoding, only decoding (i.e. this attribute is equivalent to the attribute `as value`, when encoding).
+
+Example:
+[source]
+----
+type record PduWithId {
+  integer protocolId,
+  Choices field optional
+}
+with {
+  variant (field) “chosen ( type1, { protocolId = 1, protocolId = 11 };
+                            type2, protocolId = 2;
+                            type3, protocolId = 3;
+                            omit, otherwise)”;
+  // variant (protocolId) “default (2)”;
+}
+type union Choices {
+  StructType1 type1,
+  StructType2 type2,
+  StructType3 type3
+}
+// When decoding a value of type PduWithId, type1 will be selected if
+// protocolId is 1 or 11, type2 if protocolId is 2, type3 if protocolId is 3,
+// and the field will be omitted in all other cases.
+// For example { “protocolId” : 2, “field” : { ... } } is decoded into:
+// { protocolId := 2, field := { type2 := { ... } } }
+// Note: the conditions in the attribute are evaluated when the decoder reaches
+// the union field, so the protocolId field must precede the union field in the
+// JSON document. Otherwise the decoder will use whatever value the protocolId
+// field had before decoding began (likely <unbound>, which will cause a DTE).
+
+// Note: If the protocolId field had the attribute ‘default’ (see commented
+// line in the example), then the default value would be used to determine the
+// selected field in the union, if the protocolId field is not decoded before
+// the union field.
+
+----
+
+[[external-functions-0]]
+=== External functions
+
+JSON encoder / decoder functions must have the `encode(JSON)` / `decode(JSON)` attribute set.
+
+Faults in the JSON encoding/decoding process produce errors by default, but this can be modified with the `errorbehavior` attribute. (link:#codec-error-handling[Codec error handling])
+
+JSON encoder functions can also have the `printing(compact)` or `printing(pretty)` attributes. This specifies whether the encoder should add extra white spaces to the JSON code or not. This attribute cannot be set at module level.
+
+If compact printing is selected (or if the printing attribute is not set) no white spaces are added to the JSON code, making it as short as possible.
+
+Pretty printing makes the code easier to read by adding spaces, new lines and indenting.
+
+Example:
+[source]
+----
+type enumerated Day { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday };
+type record Date {
+  charstring month,
+  integer dayIdx,
+  Day dayName
+}
+type record of Date Dates;
+type record PhoneNumber {
+  integer countryPrefix optional,
+  integer networkPrefix,
+  integer localNumber
+} with {
+  variant(countryPrefix) “JSON:omit as null”
+}
+type record Profile {
+  charstring name,
+  PhoneNumber phoneNo,
+  charstring emailAddr,
+  Dates meetings
+} with {
+  variant(phoneNo) "JSON: name as phone";
+  variant(emailAddr) "JSON: name as email";
+}
+external function f_enc_profile(in Profile par) return octetstring
+  with { extension “prototype(convert) encode(JSON) printing(pretty)” }
+…
+var Profile prof := { "John Doe", { omit, 20, 1234567 }, "jdoe@mail.com", { { "December", 31, Saturday }, { "February", 7, Friday } } };
+log(f_enc_profile(prof));
+// JSON code:
+// {
+//     "name" : "John Doe",
+//     "phone" : {
+//         "countryPrefix" : null,
+//         "networkPrefix" : 20,
+//         "localNumber" : 1234567
+//     },
+//     "email" : "jdoe@mail.com",
+//     "meetings" : [
+//         {
+//             "month" : "December",
+//             "dayIdx" : 31,
+//             "dayName" : "Saturday"
+//         },
+//         {
+//             "month" : "February",
+//             "dayIdx" : 7,
+//             "dayName" : "Friday"
+//         }
+//     ]
+// }
+
+----
+
+[[converting-ttcn-3-and-asn-1-types-to-a-json-schema]]
+=== Converting TTCN-3 and ASN.1 types to a JSON schema
+
+The TITAN compiler can convert type definitions in TTCN-3 and ASN.1 modules into a JSON schema that validates the JSON encoding of these types.
+
+NOTE: the names of ASN.1 modules, types and fields will appear in TTCN-3 form (as if they were imported into a TTCN-3 module). E.g.: the ASN.1 names `Protocol-Elem` and `value` will appear as `Protocol_Elem` and `value_` respectively.
+
+==== Usage
+
+The compiler option `–-ttcn2json` shall be used for the conversion, followed by JSON schema generator specific options and the list of TTCN-3 and ASN.1 file names.
+
+The option `–j` restricts the TTCN-3 types used in the conversion: only those that have JSON coding enabled will be converted. By default all TTCN-3 types that can be converted will be used. This option does not affect ASN.1 types, these will always be converted.
+
+If option `–f` is set, then the schema will only validate types that have JSON encoding and/or decoding functions, otherwise all types it will validate all types included in the schema.
+
+The options `-A` and `–T` can be used before each input file to specify its type (`-A` for ASN.1 files and `–T` for TTCN-3 files). If a file is not preceeded by either of these option, then the compiler will attempt to determine its type based on its contents.
+
+The last parameter specifies the name of the JSON schema file if it is preceded by a dash (-). Otherwise the name of the schema will be created using the first input file name (its `.asn` or `.ttcn` extension will be replaced by `.json`, or, if it doesn’t have either of these extension, then `.json` will simply be appended to its end).
+
+Usage examples:compiler –ttcn2json –T module1.ttcn –A module2.asn – schema.jsoncompiler –-ttcn2json –j module1.ttcn module2.asn
+
+The first example will generate the `schema.json` JSON document containing the schema, the second one will generate `module1.json` (and only JSON-encodable types will be included). These documents will have the "pretty" printing format mentioned in 4.26.3.
+
+[[top-level]]
+==== Top level
+
+On the top level the schema contains a JSON object with 2 properties.
+
+The first property, "definitions", has the schema segments of the type definitions in the TTCN-3 and ASN.1 modules as its value. This value is a JSON object with one property (key-value pair) for each module. Each property has the module name as its key and an object containing the schema segments for the types definied in that module as its key. Similarly, each type definition’s key is the type name and its value is the type’s schema segment (these will be described in the next sections).
+
+The second top level property is an "anyOf" structure, which contains references to the TTCN-3 and ASN.1 types’ schema segments under "definitions". The types listed here are the ones validated by the schema. If the compiler option `–f` is set, then only the schema segments of types that have either a JSON encoding or decoding function (or both) will be referenced (ASN.1 types can have JSON encoding/decoding functions declared in TTCN-3 modules that import them). Extra information related to the encoding/decoding function(s) is stored after each reference.
+
+Example:
+[source]
+----
+module MyModule {
+  type enumerated Height { Short, Medium, Tall };
+  type set Num {
+    integer num
+  }
+  external function f_enc_h(in Height h) return octetstring
+    with { extension “prototype(convert) encode(JSON)” }
+  external function f_dec_n(in octetstring o) return Num
+    with { extension “prototype(convert) decode(JSON)” }
+} with {
+  encode ”JSON”
+}
+// Generated JSON schema:
+// {
+//     “definitions” : {
+//         “MyModule” : {
+//             “Height” : {
+//                 “enum” : [
+//                     “Short”,
+//                     “Medium”,
+//                     “Tall”
+//                 ],
+//                 “numericValues” : [
+//                     0,
+//                     1,
+//                     2
+//                 ]
+//             },
+//             “Num” : {
+//                 “type” : “object”,
+//                 “subType” : “set”,
+//                 “properties” : {
+//                     “num” : {
+//                         “type” : “integer”
+//                     }
+//                 },
+//                 “additionalProperties” : false,
+//                 “required” : [
+//                     “num”
+//                 ]
+//             }
+//         }
+//     },
+//     “anyOf” : [
+//         {
+//             “$ref” : “#/definitions/MyModule/Height”,
+//             ”encoding” : {
+//                 ”prototype” : [
+//                     ”convert”,
+//                     ”f_enc_h”,
+//                     ”h”
+//                 ]
+//             }
+//         },
+//         {
+//             “$ref” : “#/definitions/MyModule/Num”,
+//             ”decoding” : {
+//                 ”prototype” : [
+//                     ”convert”,
+//                     ”f_dec_n”,
+//                     ”o”
+//                 ]
+//             }
+//         }
+//     ]
+// }
+
+----
+
+==== Rules and extra keywords
+
+The JSON schema will be generated according to the rules of the IETF draft v4 (see http://json-schema.org/documentation.html).
+
+In addition to the "definitions" keyword specified above, the schema segments of the type definitions can use the following extra keywords:
+
+* `"subType"`: distinguishes 2 or more types from each other, that otherwise have no other differences in their schema segments (such as: charstring and universal charstring; record and set; record of and set of)
+* `"fieldOrder"`: stores the order of the fields of a record or set (value: an array containing the field names) – only needed if there are at least 2 fields
+* `"originalName"`: stores the original name of a record/set field (see <<effect-of-coding-instructions-on-the-schema, here>>)
+* `"unusedAlias"`: stores the alias of a record/set/union field name, if it doesn’t appear under a "properties" keyword (see <<effect-of-coding-instructions-on-the-schema, here>>)
+* `"omitAsNull"`: specifies if the "omit as null" JSON encoding instruction is present for an optional field of a record or set (see <<schema-segments-for-records-and-sets, here>> and <<effect-of-coding-instructions-on-the-schema, here>>)
+* `"numericValues"`: lists the numeric values of the enumerated items (in the same order as the items themselves)
+
+A schema segment is generated for each type that has its own definition in TTCN-3. References to other types in TTCN-3 type definitions are converted into references in the JSON schema. Schema segments for embedded TTCN-3 type definitions are defined inside their parent type’s schema segment (see <<schema-segments-for-records-and-sets, here>> and <<schema-segments-for-records-of-sets-of-and-arrays, here>> for examples).
+
+The examples in the following sections will only contain JSON schema segments, not complete schemas (generated for one or more TTCN-3/ASN.1 type definitions, not the whole module). These schema segments contain the type name and the schema that validates the type. In a complete JSON schema these segments would be directly under the module’s property, which is under "definitions" (for examples see section <<top-level, Top Level>>, types "Height" and "Num").
+
+==== Schema segments for basic types
+
+The JSON encoding of basic types is detailed in section <<basic-types, Basic Types>>. Here are their schema segments:
+[source]
+----
+// integer(TTCN-3) and INTEGER(ANS.1):
+// {
+//     “type” : “integer”
+// }
+// float(TTCN-3) and REAL(ASN.1):
+// {
+//     “anyOf” : [
+//         {
+//             “type” : “number”
+//         },
+//         {
+//             “enum” : [
+//                 “not_a_number”,
+//                 “infinity”,
+//                 “-infinity”
+//             ]
+//         }
+//     ]
+// }
+// boolean(TTCN-3) and BOOLEAN(ASN.1):
+// {
+//     “type” : “boolean”
+// }
+// charstring(TTCN-3), NumericString(ASN.1), PrintableString(ASN.1),
+// IA5String(ASN.1) and VisibleString(ASN.1):
+// {
+//     “type” : “string”,
+//     “subType” : “charstring”
+// }
+// universal charstring(TTCN-3), GeneralString(ASN.1), UTF8String(ASN.1),
+// UniversalString(ASN.1), BMPString(ASN.1), GraphicString(ASN.1),
+// TeletexString(ASN.1) and VideotexString(ASN.1):
+// {
+//     “type” : “string”,
+//     “subType” : “universal charstring”
+// }
+// bitstring(TTCN-3) and BIT STRING(ASN.1):
+// {
+//     “type” : “string”,
+//     “subType” : “bitstring”,
+//     “pattern” : “^[01]*$”
+// }
+// hexstring(TTCN-3):
+// {
+//     “type” : “string”,
+//     “subType” : “hexstring”,
+//     “pattern” : “^[0-9A-Fa-f]*$”
+// }
+// octetstring(TTCN-3), OCTET STRING(ASN.1) and ANY(ASN.1):
+// {
+//     “type” : “string”,
+//     “subType” : “octetstring”,
+//     “pattern” : “^([0-9A-Fa-f][0-9A-Fa-f])*$”
+// }
+// NULL(ASN.1):
+// {
+//     “type” : “null”
+// }
+// objid(TTCN-3), OBJECT IDENTIFIER(ASN.1) and RELATIVE-OID(ASN.1):
+// {
+//     “type” : “string”,
+//     “subType” : “objid”,
+//     “pattern” : “^[0-2][.][1-3]?[0-9]([.][0-9]|([1-9][0-9]+))*$”
+// }
+// verdicttype:
+// {
+//     “enum” : [
+//         “none”,
+//         “pass”,
+//         “inconc”,
+//         “fail”,
+//         “error”
+//     ]
+// }
+// Enumerated types are converted the same way as the verdicttype with the
+// addition of the numeric values. Example:
+// TTCN-3:
+type enumerated Season {
+  spring (1), summer (2), fall (3), winter (4)
+}
+// ASN.1:
+Season ::= ENUMERATED {
+  spring (1), summer (2), fall (3), winter (4)
+}
+// JSON schema segment for type “Season”:
+// “Season” : {
+//     “enum” : [
+//         “spring”,
+//         “summer”,
+//         “fall”,
+//         “winter”
+//     ],
+//     “numericValues” : [
+//         1,
+//         2,
+//         3,
+//         4
+// }
+----
+
+[[schema-segments-for-records-and-sets]]
+==== Schema segments for records and sets
+
+The JSON object type is used for records and sets. The "properties" keyword specifies the fields of the record (each property’s key is the field name, and the value is the field’s schema segment). Additional properties are not accepted ("additionalProperties" : false). The "required" keyword determines which fields are mandatory (the names of all non-optional fields are listed here).
+
+Optional fields have an "anyOf" structure directly under "properties" (instead of the field’s schema segment). The "anyOf" structure contains the JSON null value and the field’s schema segment. The "omitAsNull" keyword is used to specify how omitted optional values are encoded (after the "anyOf" structure).
+
+Examples:
+[source]
+----
+// Example 1:
+// TTCN-3:
+type record Product {
+  charstring name,
+  float price,
+  octetstring id optional,
+  charstring from
+}
+// ASN.1:
+Product ::= SEQUENCE {
+  name VisibleString,
+  price REAL,
+  id OCTET STRING OPTIONAL,
+  from VisibleString
+}
+// Schema segment for type “Product”:
+// “Product” : {
+//     “type” : “object”,
+//     “subType” : “record”,
+//     “properties” : {
+//         “name” : {
+//             “type” : “string”,
+//             “subType” : “charstring”
+//         },
+//         “price” : {
+//             “anyOf” : [
+//                 {
+//                     “type” : “number”
+//                 },
+//                 {
+//                     “enum” : [
+//                     “not_a_number”,
+//                     “infinity”,
+//                     “-infinity”
+//                 }
+//             ],
+//         }
+//         “id” : {
+//             “anyOf” : [
+//                 {
+//                     “type” : “null”
+//                 },
+//                 {
+//                     “type” : “string”,
+//                     “subType” : “octetstring”,
+//                     “pattern” : “^([0-9A-Fa-f][0-9A-Fa-f])*$”
+//                 },
+//             ],
+//             “omitAsNull” : false
+//         },
+//         “from” : {
+//             “type” : “string”,
+//             “subType” : “charstring”
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “fieldOrder” : [
+//         “name”,
+//         “price”,
+//         “id”,
+//         “from”
+//     ],
+//     “required” : [
+//         “name”,
+//         “price”,
+//         “from”
+//     ]
+// }
+// Example 2: embedded type definition
+// TTCN-3:
+type set Barrels {
+  integer numBarrels,
+  record {
+    enumerated { Small, Medium, Large } size,
+    boolean filled
+  } barrelType
+}
+// ASN.1:
+Barrels ::= SET {
+  numBarrels INTEGER,
+  barrelType SEQUENCE {
+    size ENUMERATED { Small, Medium, Large },
+    filled BOOLEAN
+  }
+}
+// JSON schema segment for type “Barrels”:
+// “Barrels” : {
+//     “type” : “object”,
+//     “subType” : “set”,
+//     “properties” : {
+//         “numBarrels” : {
+//             “type” : “integer”
+//         },
+//         “barrelType” : {
+//             “type” : “object”,
+//             “subType” : “record”,
+//             “properties” : {
+//                 “size” : {
+//                     “enum” : [
+//                         “Small”,
+//                         “Medium”,
+//                         “Large”
+//                     ],
+//                     “numericValues” : [
+//                         0,
+//                         1,
+//                         2
+//                     ]
+//                 },
+//                 “filled” : {
+//                     “type” : “boolean”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “fieldOrder” : [
+//                 “size”,
+//                 “filled”
+//             ],
+//             “required” : [
+//                 “size”,
+//                 “filled”
+//             ]
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “fieldOrder” : [
+//         “numBarrels”,
+//         “barrelType”
+//     ],
+//     “required” : [
+//         “numBarrels”,
+//         “barrelType”
+//     ]
+// }
+// Example 3: separate type definitions and references
+// (the module name is “MyModule”)
+// TTCN-3:
+type enumerated Size { Small, Medium, Large };
+type record BarrelType {
+  Size size,
+  boolean filled
+}
+type set Barrels {
+  integer numBarrels,
+  BarrelType barrelType
+}
+// ASN.1:
+Size ::= ENUMERATED { Small, Medium, Large }
+BarrelType ::= SEQUENCE {
+  size Size,
+  filled BOOLEAN
+}
+Barrels ::= SET {
+  numBarrels INTEGER,
+  barrelType BarrelType
+}
+// Schema segments for types “Size”, “BarrelType” and “Barrels”:
+// ”Size” : {
+//     ”enum” : [
+//         ”Small”,
+//         ”Medium”,
+//         ”Large”
+//     ],
+//     “numericValues” : [
+//         0,
+//         1,
+//         2
+//     ]
+// }
+// “BarrelType” : {
+//     “type” : “object”,
+//     “subType” : “record”,
+//     “properties” : {
+//         “size” : {
+//             “$ref” : “#/definitions/MyModule/Size”
+//         },
+//         “filled” : {
+//             “type” : “boolean”
+//         }
+//     },
+//     ”additionalProperties” : false,
+//     ”fieldOrder” : [
+//         ”size”,
+//         ”filled”
+//     ],
+//     ”required” : [
+//         ”size”,
+//         ”filled”
+//     ]
+// },
+// ”Barrels” : {
+//     ”type” : ”object”,
+//     ”subType” : ”set”,
+//     ”properties” : {
+//         ”numBarrels” : {
+//             ”type” : ”integer”
+//         },
+//         ”barrelType” : {
+//             ”$ref” : ”#/definitions/MyModule/BarrelType”
+//         }
+//     },
+//     ”additionalProperties” : false,
+//     ”fieldOrder” : [
+//         ”numBarrels”,
+//         ”barrelType”
+//     ],
+//     ”required” : [
+//         ”numBarrels”,
+//         ”barrelType”
+//     ]
+// }
+----
+
+[[schema-segments-for-records-of-sets-of-and-arrays]]
+==== Schema segments for records of, sets of and arrays
+
+The JSON array type is used for records of, sets of and arrays. The "items" keyword specifies the schema segment of the items. In case of arrays, the "minItems" and "maxItems" properties are set to the array length.
+
+Arrays are distinguishable from records of and sets of by the "minItems" and "maxItems" keywords, so there is no need for them to have the "subType" property.
+
+Examples:
+[source]
+----
+// Example 1:
+// TTCN-3:
+type record of bitstring Bits;
+// ASN.1:
+Bits ::= SEQUENCE OF BIT STRING
+// Schema segment for type “Bits”:
+// “Bits” : {
+//     “type” : “array”,
+//     “subType” : “record of”,
+//     “items” : {
+//         “type” : “string”,
+//         “subType” : “bitstring”,
+//         “pattern” : “^[01]*$”
+//     }
+// }
+// Example 2 (TTCN-3 only):
+type integer Ints[4];
+// Schema segment for type “Ints”:
+// “Ints” : {
+//     “type” : “array”,
+//     “minItems” : 4,
+//     “maxItems” : 4,
+//     “items” : {
+//         “type” : “integer”
+//     }
+// }
+// Example 3:
+// reference to record type Num defined in section Top Level.
+// TTCN-3:
+type set of Num Nums;
+// ASN.1:
+Nums ::= SET OF Num
+// JSON schema segment for type “Nums”:
+// “Nums” : {
+//     “type” : “array”,
+//     “subType” : “set of”,
+//     “items” : {
+//         “$ref” : “#/definitions/MyModule/Num”
+//     }
+// }
+// Example 4:
+// the same thing with Num as an embedded type
+// TTCN-3:
+type set of set { integer num } Nums;
+// ASN.1:
+Nums ::= SET OF SET { num INTEGER }
+// JSON schema segment for type “Nums”:
+// “Nums” : {
+//     “type” : “array”,
+//     “subType” : “set of”,
+//     “items” : {
+//         “type” : “object”,
+//         “subType” : “set”,
+//         “properties” : {
+//             “num” : {
+//                 “type” : “integer”
+//             }
+//         },
+//         “additionalProperties” : false,
+//         “required” : [
+//             “num”
+//         ]
+//     }
+// }
+----
+
+==== Schema segments for unions, anytype, selection type and open type
+
+The "anyOf" structure is used for unions, open types and the anytype (if they have at least 2 fields). Each item in the "anyOf" structure represents one field of the union; they are each a JSON object with one key-value pair (one property). Same as with records, the "additionalProperties" keyword is set to false, and the one property is marked as required.
+
+Examples:
+[source]
+----
+// Example 1: union
+// TTCN-3:
+type union Thing {
+  boolean b,
+  integer i,
+  charstring cs,
+  record { integer num } rec
+}
+// ASN.1:
+Thing ::= CHOICE {
+  b BOOLEAN,
+  i INTEGER,
+  cs VisibleString,
+  rec SEQUENCE { num INTEGER }
+}
+// Schema segment for type “Thing”:
+// “Thing” : {
+//     “anyOf” : [
+//         {
+//             “type” : “object”,
+//             “properties” : {
+//                 “b” : {
+//                     “type” : “boolean”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “b”
+//             ]
+//         },
+//         {
+//             “type” : “object”,
+//             “properties” : {
+//                 “i” : {
+//                     “type” : “integer”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “i”
+//             ]
+//         },
+//         {
+//             “type” : “object”,
+//             “properties” : {
+//                 “cs” : {
+//                     “type” : “string”,
+//                     “subType” : “charstring”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “cs”
+//             ]
+//         },
+//         {
+//             “type” : “object”,
+//             “properties” : {
+//                 “rec” : {
+//                     “type” : “object”,
+//                     “subType” : “record”,
+//                     “properties” : {
+//                         “num” : {
+//                             “type” : “integer”
+//                         }
+//                     },
+//                     “additionalProperties” : false,
+//                     “required” : [
+//                         “num”
+//                     ]
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “rec”
+//             ]
+//         }
+//     ]
+// }
+// Example 2: anytype (TTCN-3 only)
+module … {
+  …
+} with {
+  extension “anytype integer,charstring”
+  // the anytype must be referenced at least one,
+  // otherwise its schema segment won’t be generated
+}
+// JSON schema segment for the anytype:
+// “anytype” : {
+//     “anyOf” : [
+//         {
+//             “type” : “object”,
+//             “properties” : {
+//                 “integer” : {
+//                     “type” : “integer”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “integer”
+//             ]
+//         },
+//         {
+//             “type” : “object”,
+//             “properties” : {
+//                 “charstring” : {
+//                     “type” : “string”,
+//                     “subType” : “charstring”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “charstring”
+//             ]
+//         }
+//     ]
+// }
+----
+
+The ASN.1 selection type generates the same schema segment as the specified alternative of the CHOICE would.
+
+Example:
+[source]
+----
+// Continuing example 1 (ASN.1 only):
+NumRec ::= rec < Thing
+// JSON schema segment for type NumRec:
+// “NumRec” : {
+//     “type” : “object”,
+//     “subType” : “record”,
+//     “properties” : {
+//         “num” : {
+//             “type” : “integer”
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “required” : [
+//         “num”
+//     ]
+// }
+----
+
+[[effect-of-coding-instructions-on-the-schema]]
+==== Effect of coding instructions on the schema
+
+For the list of JSON coding instructions see <<attributes-1, here>>. As mentioned before, only TTCN-3 types can have coding instructions, ASN.1 types can’t.
+
+* _omit as null_ – its presence is indicated by the "omitAsNull" keyword (true, if it’s present)
+* _name as …_ - the alias is used under "properties" instead of the field’s name in TTCN-3; the original name is stored under the "originalName" key
+* _as value_ – the union’s "anyOf" structure contains the fields’ schema segments instead of the JSON objects with one property; the field’s name is stored under the "originalName" key
+* _default_ – specified by the "default" keyword
+* _extend_ – adds a custom key-value pair to the type’s schema segment
+* _as value_ + _name as …_ - the field name aliases are stored under the "unusedAlias" keyword, as there are no more JSON objects with one property to store them in (they are also ignored by both the schema and the encoder/decoder, and a compiler warning is displayed in this case)
+* _metainfo for unbound_ – is ignored by the schema generator
+
+Examples:
+[source]
+----
+// Example 1: omit as null
+type record Rec {
+  integer num optional,
+  universal charstring str optional
+} with {
+  variant(num) “JSON : omit as null”
+}
+// Schema segment for type “Rec”:
+// “Rec” : {
+//     “type” : “object”,
+//     “subType” : “record”,
+//     “properties” : {
+//         “num” : {
+//             “anyOf” : [
+//                 {
+//                     “type” : “null”
+//                 },
+//                 {
+//                     “type” : “integer”
+//                 }
+//             ],
+//             “omitAsNull” : true
+//         },
+//         “str” : {
+//             “anyOf” : [
+//                 {
+//                     “type” : “null”
+//                 },
+//                 {
+//                     “type” : “string”,
+//                     “subType” : “universal charstring”
+//                 }
+//             ],
+//             “omitAsNull” : false
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “fieldOrder” : [
+//         “num”,
+//         “str”
+//     ]
+// }
+// Example 2: name as ...
+type set Num {
+  integer num
+} with {
+    variant(num) ”JSON : name as number”
+}
+// Schema segment for type “Num”:
+// ”Num” : {
+//     ”type” : ”object”,
+//     ”subType” : ”set”,
+//     “properties” : {
+//         “number” : {
+//             “originalName” : “num”,
+//             “type” : “integer”
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “required” : [
+//         “number”
+//     ]
+// }
+// Example 3: as value and name as ...
+type union Thing {
+  boolean b,
+  integer i,
+  charstring cs,
+  record { integer num } rec
+} with {
+  variant “JSON : as value”;
+  variant(i) “JSON : name as int”;
+  variant(cs) “JSON : name as str”;
+}
+// Schema segment for type “Thing”:
+// “Thing” : {
+//     “anyOf” : [
+//         {
+//             “originalName” : “b”,
+//             “type” : “boolean”
+//         },
+//         {
+//             “originalName” : “i”,
+//             “unusedAlias” : “int”,
+//             “type” : “integer”
+//         },
+//         {
+//             “originalName” : “cs”,
+//             “unusedAlias” : “str”,
+//             “type” : “string”,
+//             “subType” : “charstring”
+//         },
+//         {
+//             “originalName” : “rec”,
+//             “type” : “object”,
+//             “subType” : “record”,
+//             “properties” : {
+//                 “num” : {
+//                     “type” : “integer”
+//                 }
+//             },
+//             “additionalProperties” : false,
+//             “required” : [
+//                 “num”
+//             ]
+//         }
+//     ]
+// }
+// Example 4: default
+type record Rec {
+  integer num,
+  universal charstring str
+} with {
+  variant(num) “JSON : default(0)”;
+  variant(str) “JSON : default(empty)”;
+}
+// JSON schema segment for type “Rec”:
+// “Rec” : {
+//     “type” : “object”,
+//     “subType” : “record”,
+//     “properties” : {
+//         “num” : {
+//             “type” : “integer”,
+//             “default” : 0
+//         },
+//         “str” : {
+//             “type” : “string”,
+//             “subType” : “universal charstring”,
+//             “default” : “empty”
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “fieldOrder” : [
+//         “num”,
+//         “str”
+//     ],
+//     “required” : [
+//         “num”,
+//         “str”
+//     ]
+// }
+// Example 5: extend
+type record Number {
+  integer val
+} with {
+  variant “JSON:extend(comment):(first)”;
+  variant “ JSON : extend (comment) : (second (todo: add more fields\)) ”;
+  variant “JSON: extend(description):(a record housing an integer)”;
+  variant(val) “JSON: extend(description):(an integer)”;
+  variant(val) “JSON: extend(subType):(positive integer)”;
+}
+
+// Schema segment for type “Number”:
+// "Number" : {
+//     "type" : "object",
+//     "subType" : "record",
+//     "properties" : {
+//         "val" : {
+//             "type" : "integer",
+//             "description" : "an integer",
+//             "subType" : "positive integer"
+//         }
+//     },
+//     "additionalProperties" : false,
+//     "required" : [
+//         "val"
+//     ],
+//     "comment" : "first",
+//     "comment" : "second (todo: add more fields)",
+//     "description" : "a record housing an integer"
+// }
+
+// Displayed warnings:
+// warning: JSON schema keyword 'subType' should not be used as the key of
+// attribute 'extend'
+// warning: Key 'comment' is used multiple times in 'extend' attributes of type
+// '@MyModule.Number'
+// (The multiple uses of ‘description’ don’t generate a warning, since these
+// belong to different types.)
+----
+
+==== External function properties in the schema
+
+JSON encoding/decoding functions can only be declared in TTCN-3 modules, however they can be defined for both TTCN-3 types and imported ASN.1 types.
+
+Information related to a type’s JSON encoding/decoding external function is stored after the reference to the type’s schema segment in the top level "anyOf" structure.
+
+Extra JSON schema keywords for the external function properties:
+
+* `"encoding"` and `"decoding"`: stores the specifics of the encoding or decoding function as properties (directly under the top level `"anyOf"`, after the reference to the type’s schema segment)
+* `"prototype"`: an array containing the prototype of the encoding function (as a string), the function name, and the parameter names used in its declaration (directly under `"encoding"` or `"decoding"`)
+* `"printing"`: stores the printing settings (values: `"compact"` or `"pretty"`; directly under `"encoding"`)
+* `"errorBehavior"`: an object containing the error behavior modifications as its properties, each modification has the error type as key and the error handling as value (directly under `"encoding"` or `"decoding"`)
+
+Example:
+[source]
+----
+module Mod {
+  type record Rec {
+    integer num,
+    boolean b
+  }
+  external function f_enc(in Rec x) return octetstring with {
+    extension “prototype(convert) encode(JSON) printing(pretty)”
+  }
+  external function f_dec(in octetstring o, out Rec x) with {
+    extension “prototype(fast) decode(JSON)”
+    extension “errorbehavior(ALL:WARNING,INVAL_MSG:ERROR)”
+  }
+
+} with {
+  encode “JSON”
+}
+// JSON schema:
+// {
+//     “definitions” : {
+//         “Mod” : {
+//             “Rec” : {
+//                 “type” : “object”,
+//                 “subType” : “record”,
+//                 “properties” : {
+//                     “num” : {
+//                         “type” : “integer”
+//                     },
+//                     “b” : {
+//                         “type” : “boolean”
+//                     }
+//                 },
+//                 “additionalProperties” : false,
+//                 “fieldOrder” : [
+//                     “num”,
+//                     “b”
+//                 ],
+//                 “required” : [
+//                     “num”,
+//                     “b”
+//                 ]
+//             }
+//         }
+//     },
+//     “anyOf” : [
+//         {
+//             “$ref” : “#/definitions/Mod/Rec”,
+//             “encoding” : {
+//                 “prototype” : [
+//                     “convert”,
+//                     “f_enc”,
+//                     “x”
+//                 ],
+//                 “printing” : “pretty”
+//             },
+//             “decoding” : {
+//                 “prototype” : [
+//                     “fast”,
+//                     “f_dec”,
+//                     “o”,
+//                     “x”
+//                 ],
+//                 “errorBehavior” : {
+//                     “ALL” : “WARNING”,
+//                     “INVAL_MSG” : “ERROR”
+//                 }
+//             }
+//         }
+//     ]
+// }
+----
+
+==== Schema segments for type restrictions
+
+The compiler’s `–ttcn2json` option also generates schema segments for type restrictions (subtyping constraints), even though these are ignored by the JSON encoder and decoder. Only restrictions of TTCN-3 types are converted to JSON schema format, ASN.1 type restrictions are ignored.
+
+The generated schema segments only contain basic JSON schema keywords, no extra keywords are needed.
+
+.Converting TTCN-3 type constraints to JSON schema segments
+[cols=",",options="header",]
+|===
+|TTCN-3 type restriction |JSON schema segment
+|Length restrictions of string types |Keywords `minLength` and `maxLength` are used.
+|Length restrictions of array types |Keywords `minItems` and `maxItems` are used.
+|Single values |All single values (more specifically their JSON encodings) are gathered into one JSON `enum`. Keyword valueList is used to store single values of unions with the as value coding instruction (encoded as if they did not have this coding instruction).
+|Value range restrictions of `integers` and `floats` |The keywords minimum and maximum are used to specify the range, and keywords `exclusiveMinimum` and `exclusiveMaximum` indicate whether the limits are exclusive or not. All value range and single value restrictions are placed in an `anyOf` structure, if there are at least two value ranges, or if there is one value range and at least one single value.
+|Value range restrictions of charstrings and universal charstrings |All value range restrictions are gathered into a set expression in a JSON schema `pattern`.
+|String pattern restrictions |The TTCN-3 pattern is converted into an extended regular expression and inserted into the schema as a JSON `pattern`. Since the pattern is a JSON string, it cannot contain control characters. These are replaced with the corresponding JSON escape sequences, if available, or with the escape sequence `\u`, followed by the character’s ASCII code in 4 hexadecimal digits. Furthermore all backslashes in the string are doubled.
+|===
+
+These schema elements are inserted after the type’s schema segment. If the type’s schema segment only contains a reference to another type (in case it’s a `record`/`set`/`union` field of a type with its own definition or it’s an alias to a type with its own definition), then an `allOf` structure is inserted, which contains the reference as its first element and the restrictions as its second element (since the referenced type may contain some of the schema elements used in this type’s restrictions).
+
+If the value list restriction contains references to other subtypes, then the schema segments of their restrictions are inserted, too.
+
+The JSON coding instructions `as` `value` (for unions) and `name as...` (for `records`, `sets` and `unions`) are taken into consideration when generating the schema elements for the single values.
+
+All non-ASCII characters in `universal` `charstring` single values and patterns are inserted into the schema in UTF-8 encoding.
+
+Special cases:
+
+. The restrictions of `floats` are inserted at the end of the first element in the `anyOf` structure, except those that are related to the special values (`infinity`, `-infinity` and `not_a_number`). The `enum` containing the special values is changed, if any of the special values is not allowed by the type’s restrictions. If neither of the special values are allowed, then the `anyOf` structure is omitted, and the type’s schema only contains `type` : `number`, followed by the rest of the restrictions. Similarly, if only special values are allowed by the restrictions, then the type’s schema only contains the `enum` with the valid values.
+. If a verdicttype is restricted (with single values), then only the `enum` containing the list of single values is generated (since it would conflict with the type’s schema segment, which is also an `enum`).
+. If a single value restriction contains one or more `omit` values, then all possible JSON encodings of the single value are inserted into the `enum`. There are 2^N^ different encodings, where _N_ is the number of `omits` in the single value, since each omitted field can be encoded in 2 ways (by not adding the field to the JSON object, or by adding the field with a `null` value).
+. Single value restrictions of unions with the `as value` coding instruction do not specify which alternative the value was encoded from. Thus, the single values are generated a second time, under the extra keyword `valueList`, as if they belonged to a union without `as value` (with alternative names). This second list does not contain all the combinations of omitted field encodings (mentioned in the previous point), only the one, where omitted fields are not added to their JSON objects.
+
+Examples:
+[source]
+----
+// Example 1: Type definition with value range restriction and its subtype
+// with value list restriction
+type integer PosInt (!0..infinity);
+type PosInt PosIntValues (1, 5, 7, 10);
+
+// Schema segment generated for type “PosInt”:
+// “PosInt” : {
+//     “type” : “integer”,
+//     “minimum” : 0,
+//     “exclusiveMinimum” : true
+// }
+
+// Schema segment generated for type “PosIntValues”:
+// “PosIntValues” : {
+//     “allOf” : [
+//         {
+//             “$ref” : “#/definitions/MyModule/PosInt”
+//         },
+//         {
+//             “enum” : [
+//                 1,
+//                 5,
+//                 7,
+//                 10
+//             ]
+//         }
+//     ]
+// }
+
+// Example 2: String type definitions with length, value range and pattern
+// constraints
+type charstring CapitalLetters (“A”..“Z”) length (1..6);
+type charstring CharstringPattern
+  (pattern “*ab?\*\?\(\+[0-9a-fA-F*?\n]#(2,4)\d\w\n\r\s\”x”\\d);
+
+type universal charstring UnicodeStringRanges
+  (“a”.. “z”, char(0, 0, 1, 81)..char(0, 0, 1, 113));
+type universal charstring UnicodePattern
+  (pattern “abc?\q{ 0, 0, 1, 113 }z\\q1\q{0,0,0,2}”);
+
+// Schema segment generated for type “CapitalLetters”:
+// “CapitalLetters” : {
+//     “type” : “string”,
+//     “subType” : “charstring”,
+//     “minLength” : 1,
+//     “maxLength” : 6,
+//     “pattern” : “^[A-Z]*$”
+// }
+
+// Schema segment generated for type “CharstringPattern”:
+// “CharstringPattern” : {
+//     “type” : “string”,
+//     “subType” : “charstring”,
+//     “pattern” : “^.*ab.\\*\\?\\(\\+[\n-\r*0-9?A-Fa-f]{2,4}[0-9][0-9A-Za-z]
+//[\n-\r]\r[\t-\r ]\”x\”\\\\d$”
+// }
+
+// Schema segment generated for type “UnicodeStringRanges”:
+// “UnicodeStringRanges” : {
+//     “type” : “string”,
+//     “subType” : “universal charstring”,
+//     “pattern” : “^[a-ző-ű]*$”
+// }
+
+// Schema segment generated for type “UnicodePattern”:
+// “UnicodePattern” : {
+//     “type” : “string”,
+//     “subType” : “universal charstring”,
+//     “pattern” : “^abc.űz\\\\q1\u0002$”
+// }
+
+// Example 3: Array type definitions with length restrictions and
+// restrictions for the element type
+type record length (3..infinity) of PosInt PosIntList;
+type set length (2) of integer OnesAndTwos (1, 2);
+
+// Schema segment generated for type “PosIntList”:
+// “PosIntList” : {
+//     “type” : “array”,
+//     “subType” : “record of”,
+//     “items” : {
+//         “$ref” : “#/definitions/MyModule/PosInt”
+//     },
+//     “minItems” : 3
+// }
+
+// Schema segment generated for type “OnesAndTwos”:
+// “OnesAndTwos” : {
+//     “type” : “array”,
+//     “subType” : “set of”,
+//     “items” : {
+//         “type” : “integer”,
+//         “enum” : [
+//             1,
+//             2
+//         ]
+//     },
+//     “minItems” : 2,
+//     “maxItems” : 2
+// }
+
+// Example 4: Float type definitions with all kinds of restrictions
+type float RestrictedFloat (-infinity..-1.0, 0.0, 0.5, 1.0, not_a_number);
+type float NegativeFloat (!-infinity..!0.0);
+type float InfiniteFloat (-infinity, infinity);
+
+// Schema segment generated for type “RestrictedFloat”:
+// “RestrictedFloat” : {
+//     “anyOf” : [
+//         {
+//             “type” : “number”,
+//             “anyOf” : [
+//                 {
+//                     “enum” : [
+//                         0.000000,
+//                         0.500000,
+//                         1.000000,
+//                     ]
+//                 },
+//                 {
+//                     “maximum” : -1.000000,
+//                     “exclusiveMaximum” : false
+//                 }
+//             ]
+//         },
+//         {
+//             “enum” : [
+//                 “not_a_number”,
+//                 “-infinity”
+//             ]
+//         }
+//     ]
+// }
+
+// Schema segment generated for type “NegativeFloat”:
+// “NegativeFloat” : {
+//     “type” : “number”,
+//     “maximum” : 0.000000,
+//     “exclusiveMaximum” : true
+// }
+
+// Schema segment generated for type “InfiniteFloat”:
+// “InfiniteFloat” : {
+//     “enum” : [
+//         “infinity”,
+//         “-infinity”
+//     ]
+// }
+
+// Example 5: verdicttype definition with restrictions (single values)
+type verdicttype SimpleVerdict (pass, fail, error);
+
+// Schema segment generated for type “SimpleVerdict”:
+// “SimpleVerdict” : {
+//     “enum” : [
+//         “pass”,
+//         “fail”,
+//         “error”
+//     ]
+// }
+
+// Example 6: Union type definition with the “as value” coding instruction and
+// its subtypes (one of which references the other)
+type union AsValueUnion {
+  integer i,
+  charstring str
+}
+with {
+  variant “JSON: as value”
+}
+
+type AsValueUnion AsValueUnionValues (
+  { i := 3 },
+  { str := “abc” }
+);
+
+type AsValueUnion MoreAsValueUnionValues (
+  AsValueUnionValues,
+  { i := 6 }
+);
+
+// Schema segment generated for type “AsValueUnion”:
+// “AsValueUnion” : {
+//     “anyOf” : [
+//         {
+//             “originalName” : “i”,
+//             “type” : “integer”
+//         },
+//         {
+//             “originalName” : “str”,
+//             “type” : “string”,
+//             “subType” : “charstring”
+//         }
+//     ]
+// }
+
+// Schema segment generated for type “AsValueUnionValues”:
+// “AsValueUnionValues” : {
+//     “allOf” : [
+//         {
+//             “$ref” : “#/definitions/MyModule/AsValueUnion”
+//         },
+//         {
+//             “enum” : [
+//                 3,
+//                 “abc”
+//             ],
+//             “valueList” : [
+//                 {
+//                     “i” : 3
+//                 },
+//                 {
+//                     “str” : “abc”
+//                 }
+//             ]
+//         }
+//     ]
+// }
+
+// Schema segment generated for type “MoreAsValueUnionValues”:
+// “MoreAsValueUnionValues” : {
+//     “allOf” : [
+//         {
+//             “$ref” : “#/definitions/MyModule/AsValueUnion”
+//         },
+//         {
+//             “enum” : [
+//                 3,
+//                 “abc”,
+//                 6
+//             ],
+//             “valueList” : [
+//                 {
+//                     “i” : 3
+//                 },
+//                 {
+//                     “str” : “abc”
+//                 },
+//                 {
+//                     “i” : 6
+//                 }
+//             ]
+//         }
+//     ]
+// }
+
+// Example 7: Record definition with field name aliases and extra restrictions
+// to its fields, plus its subtype, which contains omit values
+type record Rec {
+  PosIntValues val optional,
+  integer i (0..6-3),
+  octetstring os (‘1010’O, ‘1001’O, ‘1100’O) optional
+}
+with {
+  variant(val) “JSON: name as posInt”;
+  variant(i) “JSON: name as int”;
+}
+
+type Rec RecValues (
+  { 1, 0, ‘1010’O },
+  { 5, 0, ‘1001’O },
+  { 7, 2, omit },
+  { omit, 1, omit }
+);
+
+// Schema segment generated for type “Rec”:
+// “Rec” : {
+//     “type” : “object”,
+//     “subType” : “record”,
+//     “properties” : {
+//         “posInt” : {
+//             “anyOf” : [
+//                 {
+//                     “type” : “null”
+//                 },
+//                     “originalName” : “val”,
+//                     “#ref” : “#/definitions/MyModule/PosIntValues”
+//                 }
+//             ],
+//             “omitAsNull” : false
+//         },
+//         “int” : {
+//             “originalName” : “i”,
+//             “type” : “integer”,
+//             “minimum” : 0,
+//             “exclusiveMinimum” : false,
+//             “maximum” : 3,
+//             “exclusiveMaximum” : false
+//         },
+//         “os” : {
+//             “anyOf” : [
+//                 {
+//                     “type” : “null”,
+//                 },
+//                 {
+//                     “type” : “string”,
+//                     “subType” : “octetstring”,
+//                     “pattern” : “^([0-9A-Fa-f][0-9A-Fa-f])*$”,
+//                     “enum” : [
+//                         “1010”,
+//                         “1001”,
+//                         “1100”
+//                     ]
+//                 }
+//             ],
+//             “omitAsNull” : false
+//         }
+//     },
+//     “additionalProperties” : false,
+//     “fieldOrder” : [
+//         “posInt”,
+//         “int”,
+//         “os”
+//     ],
+//     “required” : [
+//         “int”
+//     ]
+// }
+
+// Schema segment for type “RecValues”:
+// “RecValues” : {
+//     “allOf” : [
+//         {
+//             “$ref” : “#/definitions/MyModule/Rec”
+//         },
+//         {
+//             “enum” : [
+//                 {
+//                     “posInt” : 1,
+//                     “int” : 0,
+//                     “os” : “1010”
+//                 },
+//                 {
+//                     “posInt” : 5,
+//                     “int” : 0,
+//                     “os” : “1001”
+//                 },
+//                 {
+//                     “posInt” : 7,
+//                     “int” : 2
+//                 },
+//                 {
+//                     “posInt” : 7,
+//                     “int” : 2,
+//                     “os” : null
+//                 },
+//                 {
+//                     “int” : 1,
+//                 },
+//                 {
+//                     “posInt” : null,
+//                     “int” : 1
+//                 },
+//                 {
+//                     “int” : 1,
+//                     “os” : null
+//                 },
+//                 {
+//                     “posInt” : null,
+//                     “int” : 1,
+//                     “os” : null
+//                 }
+//             ]
+//         }
+//     ]
+// }
+----
+=== Differences from the TTCN-3 standard
+
+The JSON encoder and decoder work according to the rules defined in the JSON part of the TTCN-3 standard <<13-references.adoc#_25, [25]>> with the following differences:
+
+* No wrapper JSON object is added around the JSON representation of the encoded value, i.e. all values are encoded as if they had the JSON variant attribute `noType` (from the standard). Similarly, the decoder expects the JSON document to only contain the value’s JSON representation (without the wrapper). If a wrapper object is desired, then the type in question should be placed in a `record`, `set` or `union`.
+* The JSON encoder and decoder only accept the variant attributes listed <<top-level, here>>. Some of these have the same effect as variant attributes (with similar names) from the standard. The rest of the variant attributes from the standard are not supported. See <<external-functions, here>> regarding the variant attributes `normalize` and `errorbehavior` (from the standard).
+* The syntax of the JSON encode attribute is `encode JSON`. The attribute `encode JSON RFC7159` is not supported.
+* The decoder converts the JSON number `-0.0 `(in any form) to the TTCN-3 float `-0.0`, i.e. float values are decoded as if they had the JSON variant attribute `useMinus` (from the standard).The same is not true for integers, since there is no integer value `-0` in TITAN.
+
+== OER Encoder and Decoder
+
+The OER (Octet Encoding Rules) encoder and decoder handles OER-based protocols. The encoder converts abstract ASN.1 structures (or types) into an octetstring representation. The decoder converts octetstring data into values of abstract ASN.1 structures. The encoding and decoding rules of the structures can be found in the [20] standard.
+
+This section covers the not supported parts of the standard and the encoder / decoder external functions.
+
+=== Not supported parts of the standard
+
+Generally, TITAN does not have full ASN.1 support, therefore some parts of the OER coding are not supported.
+
+The following parts of the standard are not supported:
+
+* In clause 12 (Encoding of real values) of the standard: the coding of real values, whether there are any constraints or not on a REAL ASN.1 type, is handled as it is declared in the clause 12.4 of the standard.
+* Clause 23 and 24 are not supported.
+* In clause 25 (Encoding of values of the embedded-pdv type): only the "general" case (sub clause 25.3) is supported. The "predefined" case (sub clause 25.2) will be handled as the "general" case.
+* In clause 28 (Encoding of the unrestricted character string type): only the "general" case (sub clause 28.3) is supported. The "predefined" case (sub clause 28.2) will be handled as the "general" case.
+* Clause 29 (Encoding of values of the time types) is not supported.
+* Clause 31 (Canonical Octet Encoding Rules) is not fully supported, as currently there is no way to choose BASIC-OER or CANONICAL-OER coding.
+
+[[external-functions-1]]
+=== External functions
+
+OER encoder / decoder functions must have the `encode(OER)` / `decode(OER)` attribute set.
+
+Faults in the OER encoding/decoding process produce errors by default, but this can be modified with the `errorbehavior` attribute. (<<codec-error-handling, Codec error handling>>)
+
+[[build-consistency-checks]]
+== Build Consistency Checks
+
+Executable test suites are typically put together from many sources, some of which (test ports, function libraries, etc.) are not written by the test writers themselves, but are developed independently. Sometimes, a test suite requires an external component with a certain feature or bug fix, or a certain minimum TITAN version. Building with a component which does not meet a requirement, or an old TITAN version, typically results in malfunction during execution or cryptic error messages during build. If version dependencies are specified explicitly, they can be checked during build and the mismatches can be reported.
+
+=== Version Information in TTCN-3 Files
+
+TITAN allows test writers to specify that a certain TTCN-3 module requires a minimum version of another TTCN-3 module or a minimum version of TITAN.
+
+==== Format of Version Information
+
+The format of the version information follows the format of Product Identity (Ericsson standard version information <<13-references.adoc#_19, [19]>>); a combination of letters and digits according to the template pruductNumber/suffix RmXnn, where
+
+* Product number identifies the product. It is 3 characters representing the ABC class, 3 digits called the type number and 2 to 4 digits called the sequence number. This part is optional for backward compatibility reasons.
+* Suffix indicates new major versions, which are not backward compatible with previous versions ("Revision suffix"). This part is optional for backward compatibility reasons.
+* R is the literal character `R'
+* m is a single digit ("Revision digit"). It changes when the product (module) functionality is extended with new features (switching to this version is possible, but switching back might not be).
+* X is an uppercase letter of the English alphabet (between A and Z inclusive) which changes when the product (module) realization changes ("Revision letter"). The following letters are not allowed: IOPQRW. Versions of a product where only this letter changes can be switched without side effect.
+* nn (optional) is a two-digit number ("Verification step") which specifies a prerelease, a version made available during development.
+
+If the final digits are not present, the version is considered a full release, which is a higher version than any prerelease.
+
+Example accepted formats: CRL 113 200/1 R9A; CRL 113 200 R9A; R9APlease note, that only these are supported from the Ericsson Naming Scheme.
+
+Here is a possible progression of release numbers, in strictly ascending order:
+
+R1A01, R1A02…, R1A (first full release), R1B01, R1B02…, R1B, R1C, R2A, R2B01, R2B02…, R2B, R2C, R3A, etc.
+
+==== Required TITAN Version
+
+A TTCN-3 module can specify the minimum required version of TITAN which can be used to compile it. The format of the extension attribute is"requiresTITAN <version>". For example, the following snippet:
+[source]
+----
+module X {
+  // …
+}
+with {
+  extension “requiresTITAN R8C”;
+}
+----
+
+specifies that module X has to be compiled with TITAN R8D (1.8.pl3) or later. Compiling the module with a TITAN which does not satisfy the requirement will cause a compilation error, stating that the version of the compiler is too low.
+
+Compiling this module with TITAN R8B or below may result in a different compiler error, because the syntax of the attribute is not understood by earlier versions.
+
+==== Specifying the Version of a TTCN-3 Module
+
+A module’s own version information can be specified in an extension attribute. The format of the extension attribute is"version <version data>"that is, the literal string "version" followed by the version information (R-state).
+
+Example:
+[source]
+----
+module supplier {
+  // …
+}
+with {
+  extension “version R1A”;
+}
+----
+
+The version of the module should be set to match the R-state of the product it belongs to.
+
+For backward compatibility, the lack of version information (no extension attribute with "version" in the module’s "with" block) is equivalent to the highest possible version and satisfies any version requirement.
+
+==== Required Version of an Imported Module
+
+The minimum version of an imported module can be specified with an extension attribute. The format of the extension attribute is "requires <module name> <required version>" that is, the literal string "requires" followed by the actual module name and required version.
+
+Example:
+[source]
+----
+module importer {
+  import from supplier all;
+}
+with {
+  extension “requires supplier R2A”
+}
+----
+
+The module name must be one that is imported into the module. Specifying a module which is not imported is flagged as an error.
+
+In general, a module should require the full version of another module or TITAN (the R1A format). Depending on a prerelease version should be avoided whenever possible.
+
+=== Consistency Check in the Generated Code
+
+A number of checks are performed during the build to ensure consistency of the TITAN compiler, TITAN runtime, C++ compiler used during the build. The compiler generates checking code that verifies:
+
+* The version of the TITAN compiler matches the version of the TITAN runtime
+* The platform on which the build is being performed matches the platform of the TITAN compiler
+* The compiler used to build the TITAN compiler matches the compiler used to build the TITAN runtime
+* Some of this information (in form of C\++ preprocessor macros definitions and instructions) is available to test port writers to express dependency on a particular TITAN version. When a C++ file includes a header generated by the TITAN compiler, that header includes the definitions for the TITAN runtime, including version information. These macro dependencies can be used in user-written C++ code.
+* TTCN3_VERSION is a C/C\++ macro defined by the TITAN runtime headers. It contains an aggregated value of the TITAN major version, minor version and patch level. So, to express that a certain C++ file must be compiled together with TITAN R8C, the following code can be used:
++
+[source]
+----
+#if TTCN3_VERSION < 10802
+#error This file requires TITAN 1.8.2
+#endif
+----
+* There is a preprocessor macro defined in the makefile which identifies the platform (operating system). It can be one of SOLARIS (for Solaris 6), SOLARIS8 (for Solaris 8 and above), LINUX, WIN32. Platform-dependent code can be isolated using conditional compilation based on these macro definitions.
+* If the TITAN runtime was compiled with the GNU Compiler Collection (GCC), the macro GCC_VERSION is defined by the TITAN runtime headers. Its value is 10000 * (GCC major version) + 100 * (GCC minor version). For example, for GCC 3.4.6, GCC_VERSION will be defined to the value 30400; for GCC 4.1.2 it will be 40100. The value of this macro is compared during C++ compilation to the version of the compiler that was used to build TITAN itself to ensure consistency of the build. The GCC patch level is ignored for this comparison; code generated by a compiler with the same major and minor version is considered compatible.User-written code can use this value if it requires a certain version of the compiler. Alternatively, the predefined macros of the GNU compiler (*GNUC* and *GNUC_MINOR*) can be used for this purpose.
+* If the TITAN runtime was built with the SunPro compiler, the compiler itself defines the __SUNPRO_CC macro. Please consult the compiler documentation for the possible values.
+
+== Negative Testing
+
+=== Overview
+
+As a TTCN-3 language extension Titan can generate invalid messages for the purpose of negative testing. The purpose is to generate wrong messages that do not conform to a given type that the SUT is expecting, and send them to the SUT and observe the SUT’s reaction. In Titan only the encoding is implemented, the decoding of wrong messages is not in the scope of this feature.
+
+In protocol testing the term of abstract syntax and transport syntax can be distinguished. In TTCN-3 abstract syntaxes are the data type definitions, while transport syntax is defined using with attributes (encode, variant) that are attached to type definitions. The negative testing feature defines modifications in the transport syntax, thus it does not affect TTCN-3 type definitions. This means that the content of the values, which shall be called *erroneous values* and *erroneous templates*, will not be modified; only their encoding will be. This encoding (transport syntax) is determined by the with attributes attached to the type definition, in case of negative testing the encoding of a value is modified by attaching special with attributes to the value which is to be encoded. TTCN-3 with attributes can be attached only to module level constants and templates; this is a limitation of the TTCN-3 standard.
+
+Values and templates of the following structured types can be made erroneous:
+
+* record
+* set
+* record of
+* set of
+* union
+
+The corresponding ASN.1 types can also be used when imported from an ASN.1 module.
+
+The following *erroneous* behaviors can be defined for the encoding of an *erroneous value* or *template*:
+
+* omit specified fields
+* change the specified field’s value or both type and value
+* omit all fields before or after the specified field
+* insert a new field before or after the specified field
+
+The inserted data can be either the value of a given constant or any "raw" binary data.
+
+All encoding types (RAW, TEXT, BER, XER, JSON, OER) supported by TITAN can be used in negative testing.
+
+=== Syntax
+
+Erroneous attributes follow the syntax laid out in section A.1.6.6 (with statement) of the TTCN-3 standard with the following modifications:
+
+[source]
+AttribKeyword ::= EncodeKeyword | VariantKeyword | DisplayKeyword | ExtensionKeyword | OptionalKeyword |
+
+[source]
+ErroneousKeywordErroneousKeyword ::= "erroneous"
+
+For an erroneous attribute the syntax of the AttribSpec, a free text within double quotes, is as follows:
+
+[source]
+AttribSpecForErroneous := IndicatorKeyword [ “(“ RawKeyword ")" ] ":=" TemplateInstance [ AllKeyword ]
+
+[source]
+IndicatorKeyword := "before" | "value" | "after"
+
+[source]
+RawKeyword := "raw"
+
+Example (the meaning of this code will be explained in the next chapter):
+[source]
+----
+type record MyRec {
+  integer i,
+  boolean b
+}
+const MyRec c_myrec := {i:=1,b:=true}
+with {
+  erroneous (i) “before := 123”
+  erroneous (b) “value := omit”
+}
+----
+
+=== Semantics
+
+The TemplateInstance is defined in the TTCN-3 standard, however the compiler will accept only constant values that have no matching symbols. The reason for using the TemplateInstance syntax is that it can contain also a type reference, allowing to define both the value and its type.
+
+For example:
+[source]
+----
+template MyRec t_myrec := {i:=2,b:=false}
+with {
+  erroneous (i) “after := MyRec.i:123”
+  erroneous (i) “before := MyInteger:123”
+}
+----
+
+It is important to be able to specify the type of the inserted value because the encoding attributes are attached to the type. In the example above two integer values were inserted, both integers have the same value, however one has type MyRec.i and the other has type MyInteger, this will result in different encodings of the same value if the encoding attributes for the two types are different. In TTCN-3 the encoding attributes are specified using the with attribute syntax, in ASN.1 BER encoding the tagging specifies the encoding attributes. If no type is given then the compiler will use the default type if it can be determined.
+
+For example:
+[source]
+----
+erroneous (i) "value := 123"
+----
+
+NOTE: The compiler will use the integer type and NOT the MyRec.i type.
+
+Both references to constant values and literal values can be used:
+[source]
+----
+const MyRec c_myrec := {i:=3,b:=true}
+template MyRec t_myrec := {i:=2,b:=false}
+with {
+  erroneous (i) “after := c_myrec” // type determined by the definition of c_myrec
+  erroneous (i) “before := MyRec: {i:=4,b:=true}” // type must be specified
+}
+----
+One or more field qualifiers must be used in the AttribQualifier part. If more than one field is specified, then the erroneous behavior will be attached to all specified fields, for example:
+[source]
+----
+erroneous (i,b) "after := MyInteger:123"
+----
+
+In this case the value of 123 which has type MyInteger will be inserted both after field i and after field b.
+
+The field qualifiers may reference any field at any depth inside a structured type that can have embedded other structured types. An example for ASN.1 types:
+[source]
+----
+MyUnion ::= CHOICE { sof MySeqOf }
+MySeqOf ::= SEQUENCE OF MySeq
+MySeq ::= SEQUENCE { i INTEGER }
+const MyUnion c_myunion := { … }
+with { erroneous (sof[5].i) “value := 3.14” }
+This also works in case of recursive types:
+type record MyRRec { MyRRec r optional }
+const MyRRec c_myrrec := { … }
+with { erroneous (r.r.r.r.r) “value := omit” }
+----
+
+If the erroneous value does not contain a field which was referred by the erroneous qualifier then the erroneous behavior specified for that field will have no effect. For example:
+
+[source]
+----
+type union MyUni { integer i, boolean b }
+const MyUni c_myuni := { i:=11}
+with {
+  erroneous (i) “value := MyUni.i:22”
+  erroneous (b) “value := MyUni.b:false” // this rule has no effect
+}
+----
+
+The reason for allowing the second rule is that the erroneous information can be transferred by using assignment. By assigning an erroneous constant to a local variable in a testcase or function it can be used with variables too. For example:
+[source]
+----
+function func() {
+  var MyUni vl_myuni := c_myuni;
+  vl_myuni.b := true;
+  // now field b is selected in vl_myuni, therefore the erroneous rule on
+  // field b will be active, the rule on field i will have no effect
+}
+----
+
+The erroneous attribute data is attached to the defined constant or template and not to its fields. The fields of this erroneous constant or template do not contain any information on how they are erroneous; this information is attached to the top level. If a field is encoded on its own or is assigned to some other variable it will not contain any erroneous information. Example:
+[source]
+----
+module Example1
+{
+type record R {
+  integer i,
+  R r optional
+} with { encode "TEXT" variant "BEGIN('[BEGIN]')"; variant "END('[END]')"; variant "SEPARATOR('[*]')" }
+external function encode_R( in R pdu) return charstring with { extension "prototype(convert) encode(TEXT)" }
+const R r1 := { i:=1, r:={ i:=2, r:=omit } }
+with { erroneous (r.i) "value:=3" }
+control {
+  log(encode_R(r1)); // output: "[BEGIN]1[*][BEGIN]3[END][END]"
+  log(encode_R(r1.r)); // output: "[BEGIN]2[END]"
+  // r1.r is not erroneous if used on its own!
+}
+}
+----
+
+Erroneous constants can be assigned to fields of other erroneous constants and templates, however if the original field or any field embedded in that field was made erroneous then the top level erroneous data will be used and the referenced constant’s erroneous data ignored. Erroneous data can be visualized as a tree that is a sub-tree of the tree of a type (in the examples the R type, which is recursive). If two erroneous sub-trees overlap then the one which was attached to the constant used as the value of that field where the overlapping happens will be ignored.
+
+Example:
+[source]
+----
+module Example2
+{
+type record R {
+  integer i,
+  R r optional
+} with { encode "TEXT" variant "BEGIN('[BEGIN]')"; variant "END('[END]')"; variant "SEPARATOR('[*]')" }
+external function encode_R( in R pdu) return charstring with { extension "prototype(convert) encode(TEXT)" }
+const R r0 := { i:=0, r:=omit } with { erroneous (i) "value:=4" }
+const R r1 := { i:=1, r:=r0 } with { erroneous (r.i) "value:=3" }
+const R r2 := { i:=1, r:=r0 }
+const R r3 := { i:=1, r:=r0 } with { erroneous (r.r) "value:=R:{i:=5,r:=omit}" }
+control {
+  log(encode_R(r0)); // output: "[BEGIN]4[END]"
+
+  log(encode_R(r1)); // output: "[BEGIN]1[*][BEGIN]3[END][END]"
+  // the value of r1.r.i is determined by the erroneous attribute of r1!
+
+  log(encode_R(r2)); // output: "[BEGIN]1[*][BEGIN]4[END][END]"
+  // the value of r2.r.i is determined by the erroneous attribute of r0
+
+  log(encode_R(r3)); // output: "[BEGIN]1[*][BEGIN]0[*][BEGIN]5[END][END][END]"
+  // the value of r3.r.i is 0, the erroneous attribute on r0.i was dropped because
+  // when r0 is used as field r3.r then this r3.r field has embedded erroneous data
+}
+}
+----
+
+Meaning of IndicatorKeyword:
+
+* `"before"`: the specified value will be inserted before the specified field(s)
+* `"value"`: the specified value will be inserted instead of the value of the specified field(s)
+* `"after"`: the specified value will be inserted after the specified field(s)
+
+In case of unions only the "value" keyword can be used.
+
+The optional "raw" keyword that can follow the IndicatorKeyword should be used when raw binary data has to be inserted instead of a value. The specified binary data will be inserted into the encoder’s output stream at the specified position. The specified data will not be checked in any way for correctness. For convenience this binary data can be specified using TTCN-3 constants as containers. For different encoding types the different containers are as follows:
+
+[cols=",,,,,,,",options="header",]
+|===
+| |RAW |TEXT |XER |BER |JSON |PER (encoding not yet supported) |OER
+|octetstring |X |X |X |X |X |X |X
+|bitstring |X | | | | |X |
+|charstring | |X |X | |X | |
+|universal charstring | | |X | |X | |
+|===
+
+Bitstrings can be used for encoding types that support the insertion of not only whole octets but also bits. For example to insert one zero bit between two fields:
+
+[source]
+----
+erroneous (i) "after(raw) := ‘0’B"
+replace a field with bits 101:
+erroneous (b) "value(raw) := ‘101’B"
+----
+
+Charstring types can be used in case of text based encodings. For example insert some XML string between two fields:
+[source]
+----
+erroneous (i) "after(raw) := ""<ERROR>erroneous element</ERROR>"””
+----
+
+Notice that the double quotes surrounding the charstring must be doubled because it’s inside another string.
+
+The optional "all" keyword after the TemplateInstance must be used when omitting all fields before or after a specified field, in all other cases it must not be used.
+
+=== Typical Use Cases
+
+Types used in the examples:
+[source]
+----
+type record MyRec {
+  integer i,
+  boolean b,
+  charstring s length (3),
+  MyRec r optional
+} with { encode “RAW” variant “ ….. “ }
+type record of integer MyRecOf;
+type MyRec.i MyInteger with { encode “RAW” variant “ ….. “ }
+----
+
+==== Discard Mandatory Fields
+
+[source]
+----
+type record of integer IntList;
+…
+var IntList vl_myList := { 1, 2, 3 };
+var IntList vl_emptyList := {};
+replace(vl_myList, 1, 2, vl_emptyList); // returns { 1 }
+replace(“abcdef”, 2, 1, “”); // returns “abdef”
+replace(‘12FFF’H, 3, 2, ‘’H); // returns ‘12F’H
+----
+
+==== Insert New Fields
+
+[source]
+----
+const MyRec c_myrec3 := { i:=1, b:=true, s:=”str”, r:=omit }
+with {
+  erroneous (i) “before := MyRec.i:3” // has same type as field i
+  erroneous (b) “after := MyInteger:4”
+}
+const MyRecOf c_myrecof2 := { 1, 2, 3 }
+with { erroneous ([1]) “after := MyRecOf[-]:99” }
+----
+
+==== Ignore Subtype Restrictions
+
+[source]
+----
+const MyRec c_myrec4 := { i:=1, b:=true, s:=”str”, r:=omit }
+with { erroneous (s) “value :=””too long string””” }
+----
+
+==== Change the Encoding of a Field
+
+Here the TTCN-3 root type and value of field i are not changed but the encoding is changed:
+[source]
+----
+const MyRec c_myrec5 := { i:=1, b:=true, s:=”str”, r:=omit }
+with { erroneous (i) “value := MyInteger:1” }
+----
+
+==== Completely Change a Field to a Different Type and Value
+
+The second field is changed from a boolean to an integer:
+[source]
+----
+const MyRec c_myrec6 := { i:=1, b:=true, s:=”str”, r:=omit }
+with { erroneous (b) “value := MyInteger:1” }
+----
+
+=== Summary
+
+Main features of negative testing in TITAN:
+
+* This feature is supported only by the Function Test runtime of TITAN; when doing negative testing this feature must be turned on using the *–R* switch to switch from the default Load Test runtime to the Function Test runtime
+
+* Performance and functionality in case of positive testing is not affected by this feature
+
+* Existing types can be used without modifications (both TTCN-3 and ASN.1 types)
+
+* The erroneous attribute of a value or template does not modify its content, the erroneous feature of that value or template can be seen only when encoding or logging
+
+* `ErroneousKeyword`, `IndicatorKeyword`, `RawKeyword` were not introduced as new keywords in TTCN-3, thus these can be used as identifiers, the compiler is backward compatible
+
+* The erroneousness of a value is lost when sending it between components or using it as parameter of the start() function. In TTCN-3 sending and receiving of values is done by specifying the type of data, but the erroneous information is attached to a value and not the type, thus the receiving side cannot handle erroneous information.
+
+=== Special Considerations for XML Encoding
+
+There are a number of particularities related to negative testing of XML encoding.
+
+* Inserted and replaced values are encoded using the normal XML encoding functions. These values are encoded as if they were top-level types: the name of the XML element is derived from the TTCN-3 or ASN.1 type name. For built-in types (e.g. integer, boolean, universal charstring) the XML name will be according to Table 4 at the end of clause 11.25 in X.680 (<<13-references.adoc#_6, [6]>>), usually the uppercased name of the type (e.g. INTEGER, BOOLEAN, UNIVERSAL_CHARSTRING). If a particular XML name is desired, an appropriate type alias can be defined.
+
+For example, encoding the following value:
+
+[source]
+----
+type record R { integer i }
+const R c_r := { 42 } with { erroneous (i) “value := \“fourty-two\” ” }
+----
+
+will result in the following XML:
+
+[source]
+----
+<R>
+  <CHARSTRING>fourty-two</CHARSTRING>
+</R>
+----
+
+To generate an XML element with a given name, e.g. "s", the following code can be used:
+
+[source]
+----
+type record R { integer i }
+type charstring s; // a type alias
+const R c_r := { 42 } with { erroneous (i) “value := s : \“fourty-two\” ” }
+----
+
+The resulting XML will be (erroneous values highlighted in yellow):
+
+[source,subs="+quotes"]
+----
+<R>
+[yellow-background]#  <s>fourty-two</s>#
+</R>
+----
+
+A `name as "…"` TTCN-3 attribute could also be used, but that also requires a separate type.
+
+* By default, fields of ASN.1 SEQUENCE /TTCN-3 record are encoded as XML elements. Only those fields which have a `with { variant "attribute" }` TTCN-3 attribute applied are encoded as XML attributes. If a field having a `with { variant "attribute" }` has an erroneous value (`before/value/after`), this erroneous value will also be encoded amongst the XML attributes. However, by default the erroneous value will be encoded as an XML element; the resulting XML will not be well-formed:
+
+[source,subs="+quotes"]
+----
+type record R2 {
+  charstring at,
+  charstring el
+}
+with { variant (at) “attribute” }
+
+const R2 c_r2 := {
+  at := “tack”, el := “le”
+} with { erroneous (at) “before := 13 ” }
+results in:
+
+<R2[yellow-background]##<INTEGER>13</INTEGER>## at='tack'>
+  <el>le</el>
+</R2>
+----
+
+To ensure the erroneous value is encoded as an XML attribute, a TTCN-3 type alias can be created which also has a `with { variant "attribute" }` TTCN-3 attribute. The name of the XML attribute can also be controlled either with the name of the type or a name as `"…"` TTCN-3 attribute.
+
+[source,subs="+quotes"]
+----
+// type record R2 as above
+type integer newatt with { variant “attribute” } // type alias for integer
+
+const R2 c_r2a := {
+  at := “tack”, el := “le”
+} with { erroneous (at) “before := newatt : 13 ” }
+
+<R2 [yellow-background]##newatt='13'## at='tack'>
+  <el>le</el>
+</R2>
+----
+
+* One particularity of the Titan XML encoder is that the space before the name of an XML attribute "belongs" to that attribute (it is written together with the attribute name). If the field (encoded as an XML attribute) is omitted or replaced, the space will also be removed. If a well-formed XML output is desired, the loss of the space must be compensated when using raw erroneous values (non-raw erroneous values encoded as attributes will supply the space, as can be seen in the previous example).
+
+[source,subs="+quotes"]
+----
+// type record R2 as above
+const R2 c_r2r := {
+  at := “tack”, el := “le”
+} with { erroneous (at) “before(raw) := ""ax='xx'"" ” } // not compensated
+
+<R2[yellow-background]##ax='xx'## at='tack'>
+  <el>le</el>
+</R2>
+----
+
+The resulting XML is not well formed.
+
+[source,subs="+quotes"]
+----
+// type record R2 as above
+const R2 c_r2r := {
+  at := “tack”, el := “le”
+} with { erroneous (at) “before(raw) := "" ax='xx'"" ” }
+// compensated, note space here-----------^
+
+<R2 [yellow-background]##ax='xx'# at='tack'>
+  <el>le</el>
+</R2>
+----
+
+Now the XML is well-formed.
+
+* When using `"before := omit all"` or `"after := omit all"` on a member of a record which has a `with { variant "useOrder" }` TTCN-3 attribute, omit-before/omit-after refers to the order of the fields in the record, not the order in which they appear in the XML. In other words, useOrder has no effect on `omit-before/omit-after`.
+
+[source]
+----
+type record UO {
+  record of enumerated { id, name, price, color } order,
+
+  integer    id,
+  charstring name,
+  float      price,
+  charstring color
+}
+with {
+  variant "element";
+  variant "useOrder";
+  variant "namespace as 'http://www.example.com' prefix 'exm'";
+}
+
+const UO c_uo_omit_after_price := {
+  order := { id, name, color, price }, // color before price
+  id    := 1,
+  name  := "shoes",
+  price :=  9.99,
+  color := "brown"
+}
+with {
+  erroneous (price) "after := omit all" // after price: that's just color
+}
+----
+
+This will result in
+[source]
+----
+<exm:UO xmlns:exm='http://www.example.com'>
+		<id>1</id>
+		<name>shoes</name>
+		<!- color omitted here -->
+		<price>9.990000</price>
+</exm:UO>
+----
+
+In the XML, `color` comes before `price`. However, in record UO, `color` comes after `price`; therefore "omit all after price" does affect `color` even though `price` is the last element in the XML.
+
+In a record type `with { variant "useOrder" }`, the first field (a record-of enumerated which controls the order of XML elements) does not appear in the generated XML. Therefore, omitting the first field has no effect.
+
+=== Special considerations for RAW encoding
+
+There are some RAW encoding attributes (e.g. `LENGTHTO, POINTERTO`) that can invalidate negative testing attributes of a given constant or template. These RAW encoding attributes instruct the RAW encoder to fill some specific fields of a given constant or template being encoded during the encoding process depending on some other specific fields of a given constant or template. In this case the RAW encoding attributes and the negative testing attributes can be in conflict. If a conflict is detected by the encoder its behavior is user defined. Depending on the `errorbehavior` attribute of the given encoder function (see 4.22.4.3) the encoder can give the user an error (`errorbehavior(NEGTEST_CONFL:ERROR)`), a warning (`errorbehavior(NEGTEST_CONFL:WARNING)`) or it can ignore it as its default behavior (`errorbehavior(NEGTEST_CONFL:IGNORE)`).
+
+The affected RAW encoding attributes and their behaviors used together with negative testing attributes are described in the following list. For detailed information about these RAW encoding attributes please check <<attributes, here>>.
+
+. `EXTENSION_BIT(<param>)`
++
+It is applied even on fields added or modified by negative testing attributes.
++
+[source]
+----
+type record extbitrec {
+                      integer f1,
+                      integer f2
+                    } with { variant "EXTENSION_BIT(yes)" encode "RAW" }
+                    const extbitrec cr := { 1, 2 } with
+                    { erroneous(f1) "before := 1" erroneous(f2) "value := 1" }
+                    // The result will be ‘010181’O.
+----
+. E`XTENSION_BIT_GROUP(<param1, param2, param3>)`
++
+If a specific extension bit group is somehow affected by negative testing attributes (e.g. some of the elements of a given extension bit group were modified, new fields were added into it) a warning <<13-references.adoc#_10, [10]>> will be given and the extension bit group will be ignored.
++
+[source]
+----
+type record extbitgrouprec {
+  integer f1,
+  integer f2,
+  integer f3,
+  integer f4,
+  integer f5,
+  integer f6
+} with {
+  variant "EXTENSION_BIT_GROUP(yes, f1, f3)"
+  variant "EXTENSION_BIT_GROUP(yes, f5, f6)"
+  encode "RAW"
+}
+const extbitgrouprec cr := { 1, 2, 3, 4, 5, 6 } with {
+  erroneous(f1) "before := 1"
+  erroneous(f4) "value := 1"
+  erroneous(f6) "after := 1" }
+// None of the extension bit groups are affected.
+// The result will be ‘0101028301058601’O.
+----
+. `LENGTHTO(<param>)` and `LENGTHINDEX(<param>)`
++
+If any of the fields the length is calculated from or the field the result is stored into are affected by negative testing attributes a warning will be given and the length calculation will be ignored. In this case the value of the field the result is stored into is undefined, but it’s possible to set its value using negative testing attributes.
++
+[source]
+----
+type record lengthtorec1 {
+                      integer f1
+                    with { variant "" encode "RAW" }
+                    type record lengthtorec2 {
+                      integer f1 optional,
+                      lengthtorec1 f2 optional,
+                      charstring f3 optional,
+                      charstring f4 optional
+                    } with {
+                      variant (f2) "LENGTHTO(f3, f4)"
+                      variant (f2) "LENGTHINDEX(f1)"
+                      encode "RAW"
+                    }
+                    const lengthtorec2 cr := { 1, { 2 }, "", "one" } with {
+                      erroneous(f1) "before := 1" erroneous(f2) "after := 1" }
+                    // No conflict, LENGTHTO is calculated normally.
+                    // The result will be ‘010103016F6E65’O.
+----
+. `POINTERTO(<param>)`
++
+If any of the fields between (and including) the pointer and the pointed fields are affected by negative testing attributes (e.g. new fields were added in-between) a warning will be given and the pointer calculation will be ignored. In this case the value of the pointer field will be undefined, but it’s possible to set its value using negative testing attributes.
++
+[source]
+----
+type record pointertorec {
+                      integer f1,
+                      charstring f2,
+                      charstring f3
+                    } with { variant (f1) "POINTERTO(f3)" encode "RAW" }
+                    const pointertorec cr := { 1, "dinner", "bell" } with {
+                      erroneous(f1) "before := 1" erroneous(f3) "after := 1" }
+                    // No conflict, POINTERTO is calculated normally.
+                    // The result will be ‘010264696E6E657262656C6C01’O.
+----
+. `PRESENCE(<param>)`
+Even if the optional field or any of the fields referenced in the presence indicator list are affected by negative testing attributes a warning will be given and the fields will not be modified according to the PRESENCE RAW encoding attribute, it will be completely ignored.
++
+[source]
+----
+type record presencerec1 {
+                      integer f1
+                    } with { variant "" encode "RAW" }
+                    type record presencerec2 {
+                      integer f1,
+                      presencerec1 f2,
+                      integer f3,
+                      integer f4 optional
+                    } with { variant (f4) "PRESENCE(f1 = 9, f2.f1 = 99, f3 = 1)"
+                      encode "RAW" }
+                    const presencerec2 cr := { 1, { 2 }, 3, 4 } with {
+                      erroneous(f1) "after := 1" erroneous(f4) "after := 1" }
+                    // No conflict.
+                    // The result will be ‘090102030401’O.
+----
+. `TAG(<param>)` and `CROSSTAG(<param>)`
++
+If the field the attribute belongs to or any of the fields referenced in the presence indicator list are affected by negative testing attributes a warning will be given and the fields will not be modified according to the TAG and CROSSTAG RAW encoding attributes, it will be completely ignored.
++
+[source]
+----
+type record tagrec1 {
+                      integer f1
+                    } with { variant "" encode "RAW" }
+                    type record tagrec2 {
+                      tagrec1 f1,
+                      ragrec1 f2,
+                      tagrec1 f3
+                    } with { variant "TAG(f1, f1 = 1; f2, f1 = 2)" encode "RAW" }
+                    const myrec17 cmr26 := { { 1 }, { 2 }, { 3 } } with {
+                      erroneous(f1) "after := 1" erroneous(f2) "after := 1"
+                      erroneous(f3) "value := 33" }
+                    // No conflict.
+                    // The result will be ‘0101020121’O.
+                    type record crosstagrec1 {
+                      integer f1,
+                      integer f2
+                    } with { variant  "" encode "RAW" }
+                    type union crosstaguni {
+                      crosstagrec1 f1,
+                      crosstagrec1 f2
+                    } with { variant "" encode "RAW" }
+                    type record crosstagrec2 {
+                      integer f1,
+                      integer f2,
+                      crosstaguni f3
+                    } with {
+                    variant (f3) "CROSSTAG(f1, { f1 = 1, f1 = 11, f2 = 6 };
+                      f2, f1 = 3)" encode "RAW" }
+                    const crosstagrec2 cr := { 1, 2, { f1 := { 3, 4 } } } with {
+                      erroneous(f1) "before := 1" erroneous(f2) "after := 1"
+                      erroneous(f3) "after := 9" }
+                    // No conflict.
+                    // The result will be ‘01010201030409’O.
+----
+
+=== Special Cosiderations for JSON Encoding
+
+There are a number of particularities related to the negative testing of the JSON encoder.
+
+* *Field names for erroneous values*
++
+Replaced values in JSON objects (fields of records, sets and unions) keep their field name, even if the replaced value is of a different type.
++
+Inserted values (in records, sets and unions) receive a field name derived from the name of the value’s type. For built-in types (e.g. integer, boolean, universal charstring) the XML name will be according to Table 4 at the end of clause 11.25 in X.680 (<<13-references.adoc#_6, [6]>>), usually the uppercased name of the type (e.g. INTEGER, BOOLEAN, UNIVERSAL_CHARSTRING). For custom types the field name will start with an '@' character, followed by the name of the module the type was defined in, and the name of the type separated by a dot ('.').
++
+Example:
++
+[source,subs="+quotes"]
+----
+module M {
+type record R {
+  integer i,
+  charstring cs
+}
+type boolean B;
+const R c_r := { 3, “a” } with {
+  erroneous(i) “before := \“before\””;
+  erroneous(i) “value := \“value\””;
+  erroneous(cs) “before := B:true”;
+  erroneous(cs) “after := R.i:10”;
+}
+...
+}
+// JSON encoding (erroneous values highlighted in yellow):
+// [yellow-background]#{“charstring”:“before”#,“i”:[yellow-background]##“value”##,[yellow-background]#“@M.B”:true#,“cs”:“a”,[yellow-background]#“@M.R.i”:10#}
+----
+
+* *Raw values*
++
+When inserting or replacing with raw values the encoder discards field names (in records, sets and unions) and separating commas (between fields in JSON objects, and between elements of JSON arrays). If a well-formed JSON output is desired, these need to be inserted manually.
++
+Example:
++
+[source,subs="+quotes"]
+----
+type record R {
+  integer i,
+  charstring cs
+}
+type record of integer L;
+const R c_r1 := { 1, “a” } with { erroneous(i) “before(raw) := \”abc\”” };
+const R c_r2 := { 1, “a” } with { erroneous(i) “value(raw) := \”abc\”” };
+const R c_r3 := { 1, “a” } with { erroneous(i) “after(raw) := \”abc\”” };
+const L c_l1 := { 1, 2, 3 } with { erroneous([1]) “before(raw) := \”x\”” };
+const L c_l2 := { 1, 2, 3 } with { erroneous([1]) “value(raw) := \”x\”” };
+const L c_l3 := { 1, 2, 3 } with { erroneous([1]) “after(raw) := \”x\”” };
+// JSON encodings (erroneous values highlighted in yellow):
+// c_r1: {[yellow-background]#abc#“i”:1,“cs”:“a”}
+// c_r2: {[yellow-background]#abc#“cs”:“a”}
+// c_r3: {“i”:1[yellow-background]##abc##,“cs”:“a”}
+// c_l1: [1##x##,2,3]
+// c_l2: [1##x##,3]
+// c_l3: [1,2##x##,3]
+----
+
+* *Unsupported types*
++
+Although the JSON encoder supports anytypes and arrays, these cannot have erroneous attributes, thus the JSON encoder’s negative testing feature is disabled for these types.
+
+=== Updating erroneous attributes
+
+The erroneous attributes of values and templates can be changed dynamically, using the TITAN-specific statement '@update'.
+
+Its syntax is:
+[source]
+----
+UpdateStatement ::= UpdateKeyword “(“ ExtendedIdentifier ")" [ WithKeyword WithAttribList ]
+
+UpdateKeyword ::= "@update"
+----
+
+The `@update` statement can be used in functions, altsteps, testcases and control parts. Per the BNF productions in the TTCN-3 standard, the `UpdateStatement' defined here would be in the FunctionStatement and ControlStatement productions.
+
+The @update statement replaces the erroneous attributes of the value or template referenced by ExtendedIdentifier with the erroneous attributes specified in WithAttribList. The statement overwrites any erroneous attributes the value or template may have had before. If the `with' attributes are omitted, then the statement removes all the value’s or template’s erroneous attributes.
+
+Example:
+[source]
+----
+type record MyRec {
+  integer i,
+  boolean b
+}
+with {
+  encode “JSON”
+}
+const MyRec c_myrec := { i:=1, b:=true }
+with {
+  erroneous (i) “before := 123”
+  erroneous (b) “value := omit”
+}
+function func() {
+  log(encvalue(c_myrec)); // output: {“INTEGER”:123,“i”:1}
+
+  @update(c_myrec) with { erroneous(i) “value := 3.5” }
+  log(encvalue(c_myrec)); // output: {“i”:3.500000,“b”:true}
+  // the erroneous attributes set for c_myrec.b at definition have been
+  // overwritten by the @update statement
+  @update(c_myrec);
+  log(encvalue(c_myrec)); // output: {“i”:1,“b”:true} // no longer erroneous
+}
+----
+
+While only literal values and references to constants can be used in the erroneous attribute specs of constant and template definitions, the erroneous specs in an @update statement may contain any value or expression.
+
+Example:
+[source]
+----
+function f_sqr(integer p) return integer {
+  return p * p;
+}
+function func2() {
+  var integer x := 7;
+  @update(c_myrec) with {
+    erroneous(i) “value := x + 6”;
+    erroneous(b) “value := int2str(1 + f_sqr(x – 3)) & \“x\” ”;
+  }
+  log(encvalue(c_myrec)); // output: {“i”:13,“b”:“17x”}
+}
+----
+
+Restrictions:
+
+* Only the erroneous attributes of global constants and templates can be updated (including parameterized templates). The reference in the `@update` statement (the ExtendedIdentifier) may not contain field names, array indexes or actual parameters. Only the template identifier shall be used when updating the erroneous attributes of parameterized templates.
+* The statement may not contain any attributes other than erroneous attributes.
+
+NOTE: The new erroneous attributes are calculated and attached to the referenced constant or template when the `@update` statement is executed, not when the encoding takes place.
+
+Example:
+[source]
+----
+type component MyComp {
+  var integer myCompVar;
+}
+function func3() runs on MyComp {
+  myCompVar := 10;
+  @update(c_myrec) with {
+    erroneous(i) “value := myCompVar”
+  } // the erroneous value of c_myrec.i is calculated here
+
+  myCompVar := 3;
+  log(encvalue(c_myrec)); // output: {“i”:10,“b”:true}
+  // even though the component variable has changed, the encoder is using the
+  // old value stored at the @update statement
+}
+----
+
+== Testcase Stop Operation
+
+The testcase stop operation defines a user defined immediate termination of a test case with the test verdict *error* and an optional associated reason for the termination. Such an immediate stop of a test case is required for cases where a user defined behavior that does not contribute to the test outcome behaves in an unexpected manner which leads to a situation where the continuation of the test case makes no more sense.
+
+Syntax:
+[source]
+testcase "." stop [ “(“ { ( FreeText | TemplateInstance ) [ ","] } ")" ]
+
+Example:
+[source]
+----
+testcase.stop(“Unexpected Termination”);
+// The testcase stops with a Dynamic Testcase Error and the parameter  string is
+// written to the log.
+----
+
+== Catching Dynamic Test Case Errors
+
+In load testing applications premature termination of test cases due to unforeseen errors is a serious issue because when a dynamic test case error (DTE) occurs there was no way to handle it on TTCN-3 level, thus the test case is stopped with an error verdict. The mechanism of catching DTEs is very similar to exception handling used in other languages: there is a try statement block which contains the guarded code and immediately after it there is a catch statement block which contains the code that is executed if a DTE occurred in the guarded statement block. When a DTE occurs in a statement the rest of the statements in that block are skipped and control is transferred to the 1st statement of the catch block. Two TITAN specific keywords were introduced for this purpose: _@try_ and _@catch_ , these start with a "@" to avoid backward compatibility issues (new keywords clashing with identifiers used in existing code) and to differentiate them from standard TTCN-3 keywords.
+
+Syntax:
+[source]
+----
+function MyFunc() {
+  @try { // this is the guarded block, all DTEs are caught here
+    <statements>
+  }
+  @catch(dte_str) { // dte_str will contain the error message of the DTE
+    <statements>
+  }
+}
+----
+
+The identifier dte_str becomes an invisible variable definition in the @catch block, the code is semantically equivalent to:
+[source]
+----
+@catch {
+  var charstring dte_str := <DTE error message>;
+  <statements>
+}
+----
+This can be used as a normal charstring type variable whose scope is the @catch statement block.
+
+Example:
+[source]
+----
+// The predefined str2int() function causes a DTE if the input is invalid,
+// this wrapper function makes it safe to use it on possibly invalid input strings
+function safe_str2int(in charstring int_str, in integer defval) return integer {
+  @try {
+    return str2int(int_str);
+  }
+  @catch(err) {
+    return defval;
+  }
+}
+
+// Here we check if the DTE was because of a division by zero, if not then
+// the DTE with the same message is created again, so that any other DTE will
+// stop the execution of the test case with the original error message.
+// If it was a division by zero then the verdict is set to fail.
+external function throw(in charstring msg);
+testcase TC(in integer i) runs on MyComp {
+  @try {
+    i := 10 / i;
+    somefunction(); // this function might cause other DTEs
+    setverdict(pass); // this line is reached only if there was no DTE
+  }
+  @catch(err) {
+    if (match(err, pattern "*division by zero*")) {
+      log(“division by zero detected”);
+      setverdict(fail); // the verdict is fail instead of error
+    } else {
+      throw(err); // external function used to re-throw the DTE
+    }
+  }
+}
+
+// external function can be used to re-throw the error in the catch block with a
+// modified or original (as in the example above) error message, the C++
+// implementation:
+void throw_(const CHARSTRING& msg) {
+  TTCN_error("%s", (const char*)msg);
+}
+
+// @try-@catch blocks can be nested. In this example minor DTEs are ignored and the // for loop continues but in case of a major error the DTE is re-thrown an caught by // the outer catch which also terminates the test case with a fail verdict:
+testcase TC() runs on MyComp {
+  @try {
+    for (var integer i:=0; i<100; i:=i+1) {
+      @try {
+        <statements that can cause DTEs>
+      }
+      @catch(dte_str) {
+        if (match(err, <some pattern for minor errors>) {
+          log(“minor error “, dte_str, “ ignored, continuing load test…”);
+        } else {
+          throw(dte_str);
+        }
+      }
+    }
+    setverdict(pass);
+  }
+  @catch(dte_msg) {
+    log(“Something went very wrong: “, dte_msg);
+    setverdict(fail);
+  }
+}
+----
+
+== Lazy Parameter Evaluation
+
+This feature was developed for load testing, to speed up function execution by not evaluating the actual parameter of the function when its value is not used inside the function. It speeds up execution when relatively large expressions are used as "in" actual parameters. In the normal case the parameter is always evaluated before the execution of the function starts, even if the parameter is never used. In case of lazy parametrization the parameter is not evaluated if it’s never used and it is evaluated exactly once when it is used. It is important to note that the values referenced by the expression may change before the evaluation actually happens. This feature can be used only in case of "in" parameters, in case of "inout" and "out" parameters expressions cannot be used and thus it would be useless. The new titan specific keyword _@lazy_ was introduced, this must be placed right before the type in the formal parameter. This can be used for both values and templates of all types.
+
+An example logging function that does not evaluate its message parameter if not used:
+[source]
+----
+function MyLog(in @lazy charstring message) runs on MyComp {
+  if (logEnabled) {
+    log(message);
+  }
+}
+----
+
+calling the function with an expression:
+
+[source]
+----
+MyLog( “MyLog: ” & log2str(some_large_data_structure) );
+----
+
+If `logEnabled` is false the above actual parameter will not be evaluated. Example for evaluation:
+[source]
+----
+type component MyComp { var integer ci := 0; }
+function MyFuncDieIfZero() runs on MyComp return integer {
+  if (ci==0) { testcase.stop; } // die if the component variable is zero
+  return ci;
+}
+function MyLazyFunc(in @lazy integer pi) runs on MyComp {
+  ci := 1;
+  log(pi); // first use of pi -> it is evaluated, ci==1, 3*1=3 is logged
+  ci := 2;
+  log(pi); // second use of pi -> not evaluated, the value 3 is used again
+}
+----
+
+Calling the function:
+[source]
+----
+MyLazyFunc(3*MyFuncDieIfZero()); // the MyFuncDieIfZero() function is not
+                                                          // evaluated here, ci==0 here, it would die
+----
+In the above example we see that MyFuncDieIfZero() can also have a side effect if ci==0. If the actual parameter expression has a side effect it must be used carefully in case of lazy formal parameter, because it is either executed at a later time or never executed at all.
+
+Currently the only limitation is that function reference types cannot have lazy formal parameters, thus functions with lazy parameters cannot be invoked.
+
+== Differences between the Load Test Runtime and the Function Test Runtime
+
+The Function Test runtime sometimes provides extra features that the default Load Test runtime doesn’t (due to it being optimized for performance). One of these features, negative testing for encoders, was already discussed <<build-consistency-checks, here>>.
+
+=== Referencing record of elements through function parameters
+
+Passing a `record of` and one (or more) of its elements as `out` and/or `inout` parameters of the same function means that changes made inside the function to either of these parameters can cause changes in the others. Lowering the size of the `record of` (inside the function) can cause some of the other parameters to become `unbound` (this functionality only works in the Function Test runtime).
+
+Example:
+[source]
+----
+type record of integer RoI;
+function f_param_ref(inout RoI p_roi, inout integer p_ref)
+{
+  p_roi := { 10 };
+  log(p_ref);      // <unbound>
+  p_ref := 20;
+  log(p_roi);      // { 10, <unbound>, <unbound>, 20 }
+}
+...
+// function call:
+var RoI v_roi := { 1, 2, 3, 4, 5 };
+f_param_ref(v_roi, v_roi[3]);
+
+----
+
+This also works if the `record of` or its element(s) are embedded into other structures, and these structures are passed as the function’s parameters. It also works if the `record of` is an `optional` field of a `record` or `set`, and the field is set to `omit` inside the function.
+
+This functionality does not work for templates.
+
+WARNING: a side effect of this feature is that, in the Function Test runtime, passing an element outside of the record of’s bounds as an `out` or `inout` parameter does not extend the record of if the function doesn’t change the parameter, instead the size of the `record of` will remain unchanged. In the Load Test runtime this would change the size of the `record of` to the value of the index, and the `record of` would contain unbound elements at its end.
+
+Example (filling an array up by passing the element after the last as a function parameter):
+[source]
+----
+type record of integer RoI;
+function f_fill_array(out integer p_elem, in integer p_val) return boolean
+{
+  if (p_val < 3) {
+    p_elem := p_val;
+    return true;
+  }
+  return false;
+}
+
+...
+// the function call:
+var integer v_val := 0;
+var RoI v_roi := { };
+while (f_fill_array(v_roi[sizeof(v_roi)], v_val)) {
+  v_val := v_val + 1;
+}
+// Results:
+// In the Function Test runtime the array would contain { 0, 1, 2 } and its
+// sizeof would return 3
+// In the Load Test runtime the array would contain { 0, 1, 2, <unbound> }
+// and its sizeof would return 4
+----
+
+=== Compatibility of record of types
+
+In the Function Test runtime `record of` and `set of` types of the same element type are compatible with each other. In the Load Test runtime this is only true for the following (TTCN-3) element types:
+
+* boolean
+* integer
+* float
+* bitstring
+* hexstring
+* octetstring
+* charstring
+* universal charstring
+
+The `record of`s / set ofs are also compatible for the ASN.1 equivalents of the previously listed element types:
+
+* BOOLEAN
+* INTEGER
+* REAL
+* BIT STRING
+* OCTET STRING
+* NumericString
+* PrintableString
+* IA5String
+* VisibleString
+* Unrestricted Character String
+* UTCTime
+* GeneralizedTime
+* UTF8String*
+* TeletexString*
+* VideotexString*
+* GraphicString*
+* GeneralString*
+* UniversalString*
+* BMPString*
+* ObjectDescriptor*
+
+There is one exception to this rule: records/sets of universal charstring (or any of its ASN.1 equivalents, marked with *) are not compatible with other records/sets of universal charstrings in the Load Test runtime, if they or their element type have the XER coding instruction `anyElement`.
+
+Example:
+[source]
+----
+ype record of integer RoI1;
+type record of integer RoI2;
+
+type record Date {
+  integer month,
+  integer day,
+  integer year
+}
+
+type record of Date Dates1;
+type record of Date Dates2;
+
+...
+
+var RoI1 roi1 := { 1, 2, 3 };
+var RoI2 roi2 := roi1; // works in both runtimes
+
+var Dates1 dates1 := { { 3, 30, 2015 }, { 3, 31, 2015 }};
+var Dates2 dates2 := dates1; // works in the Function Test runtime, displays
+                             // a compilation error in the Load Test runtime
+----
+
+=== Module parameters in the configuration file
+
+When initializing a module parameter in the configuration file, references to other module parameters can only be used in the Function Test runtime. In the Load Test runtime identifiers on the right hand side are treated as enumerated values.
+
+In the Function Test runtime, the left hand side of an assignment or concatenation (in the configuration file) can refer to a part of a module parameter, instead of the whole module parameter, through field names and array indexes. In the Load Test runtime, field names and array indexes are not supported for module parameters.
+
+=== Multiple value redirects and redirects of partial values
+
+In the Function Test runtime, TITAN supports the use of multiple value redirects in one value redirect structure. These redirects can also be used to store only a part of the received value, or to store the decoding result of a part of the value (with the help of the `@decoded` modifier).
+
+In the Load Test runtime, the received value can only be redirected to one variable or parameter (only the whole value can be redirected, not parts).
+
+Example:
+[source]
+----
+type MyType record {
+  Header header,
+  octetstring payload
+}
+
+...
+
+var MyType v_myVar;
+var Header v_myHeaderVar;
+var MyType2 v_myVar2;
+
+MyPort.receive(MyType:?) -> value v_myVar; // works in both runtimes,
+// the entire record value is stored in variable v_myVar
+
+MyPort.receive(MyType:?) -> value (v_myVar, v_myHeaderVar := header)
+// only works in the Function Test runtime, the record is stored in v_myVar
+// and its field ‘header’ is stored in v_myHeaderVar;
+// causes a compilation error in the Load Test runtime
+
+MyPort.receive(MyType:?) -> value (v_myVar2 := @decoded payload)
+// only works in the Function Test runtime, the field ‘payload’ from the
+// received value is decoded (into a value of type MyType2, with the encoding
+// type set for MyType2) and stored in v_myVar2;
+// causes a compilation error in the Load Test runtime
+----
+
+=== Deactivating altsteps that are currently running
+
+A default `altstep` can deactivate itself (by deactivating the `default` variable that initiated the `altstep` or by deactivating all defaults).
+
+In the Load Test runtime the `deactivate` operation deletes the in parameters of the default `altstep`, if it is currently running. Accessing these parameters after the `deactivate` call may cause segmentation faults or other unexpected behavior. Because of this a warning is displayed whenever `deactivate` is used within a `function` or `altstep`.
+
+In the Function Test runtime this issue is handled by automatically copying all in parameters in `altsteps`.
+
+Example:
+[source]
+----
+type component CT {
+  var default ct_def;
+  timer ct_tmr[2];
+  ...
+}
+altstep as(in integer x) runs on CT {
+  [] ct_tmr[x].timeout {
+    deactivate(ct_def); // causes a compiler warning in the Load Test runtime
+    log(x); // logs 1 in the Function Test runtime, logs memory garbage or
+    // causes a segmentation fault in the Load Test runtime
+    ct_tmr[x].stop; // stops ct_tmr[1] in the Function Test runtime, causes a
+    // dynamic test case error (invalid index) in the Load Test runtime (if it
+    // gets this far)
+  }
+}
+testcase tc() runs on CT {
+  ct_def := activate(as(1));
+  alt {
+    ...
+  }
+}
+----
+
+[[profiling-and-code-coverage]]
+== Profiling and code coverage
+
+The TTCN-3 Profiler measures the execution time of TTCN-3 code lines and functions, and determines the number of times code lines and functions were executed (including tracking lines/functions that were never executed).
+
+The profiler stores the data it has collected in a database file in JSON format.
+
+When a TTCN-3 project (with profiling enabled) finishes execution, a statistics file is generated, containing the information gathered by the profiler in various representations.
+
+=== Activating the TTCN-3 Profiler
+
+The profiler can be activated in the desired TTCN-3 modules with the compiler option `-z`, followed by a text file containing the list of TTCN-3 file names to be profiled separated by new line characters (this list can also contain `ttcnpp` files).
+
+The TTCN-3 makefile generator can set this option automatically with its own `–z` option (with the same file argument) or through the TPD file.
+
+When `–z` is set, the compiler generates extra code for profiling and code coverage in the code generated for these modules.
+
+The compiler option `-L` must also be specified.
+
+Usage example (activating the profiler in all modules in the current folder):
+[source]
+----
+ls -1 *.ttcn > prof_files.txt
+ttcn3_compiler -L -z prof_files.txt *.ttcn
+----
+
+Once activated the profiler’s behavior can be customized through the [`PROFILER`] section in the configuration file (for more details see <<7-the_run-time_configuration_file.adoc#profiler, here>>).
+
+=== Gathered information
+
+The profiler measures two things: the total execution time of a code line or function (the amount of time the TTCN-3 Executor spent running this code line/function) and the total execution count of a code line or function (the number of times a code line/function was executed).
+
+The profiler measures all times with microsecond precision.
+
+The profiler classifies the following TTCN-3 elements as functions: functions, testcases, altsteps, parameterized templates and the control part (in this case the function’s name is `control`). External functions are not considered `functions' by the profiler, they are treated as regular TTCN-3 commands.
+
+The `code lines' contain any line with at least one TTCN-3 command. The first line of a function is always a code line (even if it doesn’t contain any commands), and measures the time between the beginning of the function’s execution and the beginning of the execution of the first line in the function. The time between the end of the last line’s execution and the end of the function’s execution is not measured separately; it is simply added to the last line’s total time.
+
+In the following example there are 10 code lines and 3 functions:
+[source]
+----
+module prof1 {
+type component C {}
+const integer c1 := 7;   // line 5
+function f1(inout integer x) runs on C   // line 7, function ‘f1’
+{
+  x := x + c1;   // line 9
+}
+testcase tc1() runs on C   // line 12, function ‘tc1’
+{
+  var integer x := 6;   // line 14
+  f1(x);   // line 15
+  log(x);   // line 16
+  x := x + 1;   // line 17
+}
+control {   // line 20, function ‘prof1’
+  execute(tc1());   // line 21
+}
+}
+----
+
+==== Gross and net times
+
+The line times measured by the profiler are gross times, meaning they also contain the execution times of all function calls in that line, not just the execution of the line itself. A setting in the configuration file can change the profiler to measure net line times instead, in which case the execution times of function calls will not be added to lines’ total execution times.
+
+The same is true for functions: by default the execution times of function calls inside the function are included in the function’s total time. A configuration file setting can change the profiler to measure net function times, in which case the function’s total time will not contain the times of embedded function calls.
+
+If a function is defined in a module where profiling is not activated (does not appear in the compiler option’s file list), and is called from a module where profiling is activated, then that function call acts as if it were a regular code line (its execution time will be added the caller line’s and function’s total time in both cases).
+
+=== Contents of the statistics file
+
+The statistics file contains lists of either code lines or functions with the data gathered for each line or function.
+
+The lists start with a title specifying what data the list contains. The titles are preceded and followed by a line made of dashes (-).
+
+Each element in a list starts with the gathered data (either the total execution time, the execution count, or both) or the average time it took for the code line or function to execute (followed by the gathered data this was calculated from in brackets: total time / execution count). The second part of a list element specifies the code line or function the data belongs to in the following format:
+
+<TTCN-3 file name>:<line number> [<function name>]
+
+The function name is only displayed for functions and for code lines that mark the beginning of a function. The line number for functions is the line the function starts in.
+
+The lists either contain raw data or sorted data. Raw data is sorted ascendingly by line number and is always grouped by module (the modules are separated by lines made of dashes). Sorted data is sorted descendingly by either total time, execution count or average time, and can be global or grouped by module.
+
+Here is an example of the sorted average times in the previously mentioned module `prof1` (where `tc1` is called directly from the configuration file and `f1` is called 2 more times from other modules):
+[source]
+----
+--------------------------------------------------------------
+- Average time / execution of code lines, sorted, per module -
+--------------------------------------------------------------
+0.000362s	(0.000362s / 1)	prof1.ttcn:17
+0.000222s	(0.000222s / 1)	prof1.ttcn:12 [tc1]
+0.000050s	(0.000050s / 1)	prof1.ttcn:16
+0.000007s	(0.000021s / 3)	prof1.ttcn:5
+0.000004s	(0.000012s / 3)	prof1.ttcn:9
+0.000001s	(0.000003s / 3)	prof1.ttcn:7 [f1]
+0.000001s	(0.000001s / 1)	prof1.ttcn:14
+0.000001s	(0.000001s / 1)	prof1.ttcn:15
+--------------------------------------------------------------
+...
+----
+
+The statistics file contains the following lists:
+
+* Number of code lines and functions – this list is an exception from the previously mentioned rules; this list contains one element per module and specifies the number of code lines and function in that module, ending with a line made of dashes and the total number of code lines and functions
++
+Example:
++
+[source]
+----
+--------------------------------------
+- Number of code lines and functions -
+--------------------------------------
+prof1.ttcn:	10 lines,	3 functions
+prof2.ttcn:	13 lines,	4 functions
+prof3.ttcn:	13 lines,	3 functions
+--------------------------------------
+Total:		36 lines,	10 functions
+----
+
+* Raw data (4 lists) – one list containing both the total time and execution count for each code line and one list containing their average times, followed by one list with the total times and execution counts of functions and one list with their average times
+* Sorted total times (4 lists) – one list for code lines grouped by module and one (global) for the code lines in all modules, followed by the same for functions (these lists only contain the total execution time of each code line and function)
+* Sorted execution counts (4 lists) – same as the lists of total times
+* Sorted average times (4 lists) – same as the previous two
+* Top 10 total times, execution counts and average times (6 lists) – these contain the first 10 entries from every sorted global list (in the order mentioned in the previous three)
+* Unused code lines and functions (2 lists) – these don’t contain any data, only the code line / function specification, they are grouped by module, first the unused lines, then the functions
+
+Any of these lists can be disabled in the configuration file (either one by one or grouped).
+
+=== Starting and stopping the profiler
+
+The profiler can be stopped using the `@profiler.stop` command. When stopped the profiler does not measure new data. This command has no effect if the profiler is already stopped.
+
+A stopped profiler can be restarted with the `@profiler.start` command. Similarly, this has no effect if the profiler is already running.
+
+The execution count of a function is measured at the start of the function, thus if the profiler is stopped when the function is called, its call will not be measured, even if the profiler is restarted during the function’s execution.
+
+Starting and stopping the profiler only affects profiling and code coverage in the current component.
+
+The boolean value `@profiler.running` stores the state of the profiler in the current component (`true` if it’s running or `false` if it’s stopped).
+
+By default the profiler is automatically started for each component when the program starts, this can be changed in the configuration file.
+
+Usage example (a function that’s always profiled and returns the profiler to its original state):
+[source]
+----
+function f1(inout integer x) runs on C
+{
+  var boolean stop_prof := not @profiler.running;
+  @profiler.start;
+  x := x + c1;
+  if (stop_prof) {
+    @profiler.stop;
+  }
+}
+----
+
+=== Profiling with multiple Host Controllers
+
+In parallel mode a separate instance of the TTCN-3 Profiler runs on each process (each component, including the MTC, and each HC). These each generate a database file.
+
+The PTCs’ and the MTC’s profilers generate temporary database files (their names are created by appending a dot and either `mtc` or the PTC’s component reference to the original database file name).
+
+The Host Controller’s profiler merges the database files produced by its child processes with its own (and with the data gathered on previous runs, if data aggregation is set) and prints the final database file. The HC’s profiler is also responsible for generating the statistics file.
+
+The profilers on multiple Host Controllers do not communicate with each other, thus a profiled test system running on multiple hosts will generate multiple database files and statistics files (one of each for every HC).
+
+If more than one host uses the same working directory, then the files generated by the different profilers will overwrite each other. To avoid this clash, certain metacharacters need to be inserted into the database and statistics file names in the configuration file (e.g.: `%h` inserts the host name, or `%p` inserts the HC’s process ID, etc; see <<7-the_run-time_configuration_file.adoc#setting-output-files, here>>).
+
+The `ttcn3_profmerge` tool can be used to merge the database files of multiple Host Controllers and to generate statistics from them.
+
+[[the-ttcn3-profmerge-tool]]
+=== The ttcn3_profmerge tool
+
+The `ttcn3_profmerge` utility, which can be found in `$TTCN3_DIR/bin`, merges all profiler database files specified in the command line arguments into one output database file. These database files are generated by the TTCN-3 Profiler during runtime, when profiling is activated in a test system. The utility can also generate statistics from the merged database, the same way as the TTCN-3 Profiler.
+
+Since there are two possible outputs, neither of them are written to the standard output.
+
+This tool is useful for test systems that are run on multiple Host Controllers (in parallel mode). It can merge the databases generated on each host.
+
+The command line syntax is:
+
+[source]
+ttcn3_profmerge [-pc] [-o file] [-s file] [-f filter] db_file1 [db_file2 …]
+
+or
+
+[source]
+ttcn3_profmerge –v
+
+The command line arguments are the input database files, these must always be listed after the switches, and there must be at least one of them.
+
+The settings available in the [`PROFILER`] section of the configuration file (see <<7-the_run-time_configuration_file.adoc#profiler, here>>) are also available with this tool. `AggregateData` can be achieved by adding the database of the previous run(s) to the input file list. `StartAutomatically`, `NetLineTimes` and `NetFunctionTimes` only affect the data gathering process, and are not relevant to merging databases and to generating the statistics file.
+
+The rest of the configuration file settings are available through command line switches. These are:
+
+* `-p`
++
+Discards all profiler data from the merged database. All execution times will be set to zero in the output database file, and all statistics related to execution times will not be generated (both profiler and code coverage data cannot be discarded, since there would be no data left). Has the same effect as the configuration file setting `DisableProfiler`.
+
+* `-c`
++
+Discards all code coverage data from the merged database. All execution counts will be set to zero in the output database file, and all statistics related to execution counts will not be generated (both profiler and code coverage data cannot be discarded, since there would be no data left). Has the same effect as the configuration file setting `DisableCoverage`.
+
+* `-o file`
++
+Prints the output (merged) database to the specified file. If this option is not set, then the merged database will not be saved. At least one of the ouput files (this or the statistics file) must be set. Has a similar effect to the configuration file setting `DatabaseFile` (except metacharacters cannot be used and there is not default value).
+
+* `-s file`
++
+Prints statistics for the merged database to the specified file. If this option is not set, then statistics will not be generated. At least one of the ouput files (this or the output database file) must be set. Has a similar effect to the configuration file settings `StatisticsFile` (except metacharacters cannot be used and there is not default value) and `DisableStatistics` (if the option is not set).
+
+* `-f filter`
++
+Specifies which statistics entries are generated. The filter is a hexadecimal number, the last 25 digits each correspond to the 25 entries in the statistics file (the least significant bit represents the first entry, and so on; see Table 27 and Table 28). The filter is ignored if the statistics file is not set. Has a similar effect to the configuration file setting `StatisticsFilter` (except the filter can only be specified with a hex number and cannot be concatenated).
+
+* `-v`
++
+Prints version and license information and exits.
+
+== Defining enumeration fields with values known at compile time
+
+The standard explicitly says that the enumeration fields can have values that must be given as an integer literal. TITAN relaxes this restriction and allows `bitstring`, `octetstring`, `hexstring` literals. In addition, the fields can only be defined with values known at compile time.
+
+For example:
+
+[source]
+----
+For example:
+const integer c_myint := 5;
+type enumerated MyEnum {
+  e_first (1), // allowed, integer literal
+  e_second ('10'B), // allowed bitstring literal
+  e_third ('43'O), // allowed octetstring literal
+  e_fourth ('55'H), // allowed hexstring literal
+  e_fifth (bit2int('1101'B)), // allowed value known at compile time
+  e_sixth (oct2int('12'O)), // allowed value known at compile time
+  e_seventh (2+3), // allowed value known at compile time
+  e_eight (c_myint), // allowed value known at compile time
+  e_ninth (f()), // not allowed, functions’ return values are not known at
+                 // compile time
+}
+
+function f() return integer {
+  return 3;
+}
+----
+
+== Ports with translation capability
+
+TTCN-3 has standardized the usage of ports with translation capability. See ES 202 781 clause 5.2 (<<13-references.adoc#_21, [21]>>). In this section the differences and limitations in TITAN will be explained.
+
+Limitations of implementation in TITAN:
+
+* The `connect to` port clause is unsupported
+* Translation of `address` types is unsupported
+* `address`, `map param` and `unmap para`m clauses are unsupported
+* The elements of the list of `form` and `to` clauses of the `in` and `out` messages are separated with a colon (:) instead of a comma (,)
+
+Restrictions:
+
+* It is not possible to chain ports using the `map to` clause.
+* The ports that are referenced in the` map to` clause shall have the `provider` extension. A port with `provider` extension cannot have a `map to` clause.
+* Port variables can only be constants, variables, templates and var templates.
+* When a port is working in translation mode the `to address` clause is not supported in send operations.
+* Translation functions shall have the `prototype(fast)` extension.
+* Test port parameters from the config file cannot be given with wildcard in the place of the component for ports with translation capability. For example `\*.*.param_name:=”param_value”` will not be passed to the port but with the following line the port parameter will be passed: `system.*.param_name:=”param_value”`
+* A difference from the dual faced test ports is that the ports with translation capability can work in two modes. In normal mode and in translation mode. In normal mode, the port behaves as a standard messaging port, while in translation mode it works as it is defined in the ES 202 781 standard clause 5.2 (<<13-references.adoc#_21, [21]>>). A test port skeleton must be generated or a real test port implementation should be available for the port type with the translation capability, to ensure that the port can work in both modes. The test port skeleton is not needed when the port with translation capability is marked as `internal` port. In this case the port can only work in translation mode.
+
+Known issues:
+
+* `user_map` and `user_unmap` will be called for both endpoints of the map and `unmap` operation.
+
+Additions:
+
+* An option to discard the message is added to the `setstate` operation. This is achieved by setting the state to 4 (`DISCARDED`). Technically this does the same thing as setting the state to 2 (`FRAGMENTED`).
+
+Ports with translation capability mechanism:
+
+When a message is sent on a port with translation capability which is working in translation mode (mapped to a port which is present in the `map to` clause of the port with translation capability), the message will be translated using the translation functions.
+
+For example:
+[source]
+----
+function int_to_oct(in integer input, out octetstring
+    output) {
+if (input <= 100) {
+		output := int2oct(input, 2);
+		port.setstate(0, "Successful <=100!");
+		} else {
+			port.setstate(1, "Not successful <=100!");
+		}
+	} with {
+		extension "prototype(fast)"
+	}
+
+function int_to_oct2(in integer input, out octetstring
+    output) {
+		if (input > 100) {
+			output := int2oct(input, 4);
+			port.setstate(0, "Successful >100!");
+		} else {
+			port.setstate(1, "Not successful >100!");
+		}
+	} with {
+		extension "prototype(fast)"
+	}
+
+function char_to_char(in charstring input, out charstring
+    output) {
+  port.setstate(4); // charstring messages are discarded
+} with {
+  extension “prototype(fast)”
+}
+
+	type port DataPort message map to TransportPort {
+    out integer to octetstring with int_to_oct() :
+                   octetstring with int_to_oct2()
+    out charstring to charstring with char_to_char()
+	} with {
+		extension "internal"
+	}
+
+	type port TransportPort message {
+		out octetstring, charstring
+	} with {
+		extension "provider";
+	}
+----
+
+If we send the integer `128` on a `DataPort` port instance, the translation functions of the `DataPort` (which are mapping an integer value) will be called in lexicographic order. When one of the translation functions is successful (`port.setstate(0)` statement is executed), no more translation functions will be called. The output of the successful translation function will be forwarded to the `TransportPort` to send the translated message.
+
+In this case the `int_to_oct` function will be called first, but this function is only mapping an integer which is less than 100. The translation using the `int_to_oct` function will not be successful. Then the int_to_oct2 function will called. This translation function will be successful, and the result of the function will be forwarded to the `TransPortPort`.
+
+If we try to send a `charstring` on a `DataPort` port instance, the translation function will discard it, and nothing will be sent.
+
+The translation logic of receiving is analogous to the translation logic of sending.
+
+The testing of some protocols requires the necessity to be able to send and receive during the execution of a translation function. This can be achieved using the `port.send()` and `port.receive()` statements in a translation function. This is only possible if the translation function has a port clause. The statements will be executed on the port instance which the execution of the translation function belongs to. The send and receive statements in a translation function should be used with caution as they can easily create an infinite loop.
+
+For example when a `port.send()` statement is executed in a translation function, the same translation function could be called automatically because the same translation procedure will be executed on the parameter of the send statement. The handling of these situations can be resolved using module parameters or port parameters.
diff --git a/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc b/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..93eb5a2d31fa527069def255ff410e023d428e76
--- /dev/null
+++ b/usrguide/referenceguide/5-supported_asn1_constructs_and_limitations.adoc
@@ -0,0 +1,54 @@
+[[supported-asn-1-constructs-and-limitations]]
+= Supported ASN.1 Constructs and Limitations
+:toc:
+:table-number: 10
+
+All kind of comments defined in X.680 clause 11.6 can be used (<<13-references.adoc#_6, [6]>>).
+
+All tagging environment is supported: `IMPLICIT`, `EXPLICIT` and also `AUTOMATIC`.
+
+The type constraints are ignored. The BER (de)coding is not influenced by the constraints, except for the table constraints. For details, see section <<6-compiling_ttcn3_and_asn1_modules.adoc#using-component-relation-constraints-from-ttcn-3, Using Component Relation Constraints from TTCN–3>>.
+
+Table 11 summarizes how the different ASN.1 types are supported.
+
+There is a special type: `ANY`. It has the same interface as the `OCTET` `STRING`, but during the decoding, it accepts any valid encoded message, and its value will be the complete TLV. This type is very useful if the protocol carries an encoded message.
+
+Value sets are not supported as they are closely related to type constraints. Value set assignments in modules are parsed, but silently ignored. However, value set fields of information object classes (both fixed and variable type ones) cannot even be parsed, syntax errors are reported when processing such fields. As a consequence of this the information objects governed by such classes cannot be parsed either.
+
+Variable type value fields of information object classes are not supported. Processing of the class definition results in syntax error.
+
+A missing `IMPORTS` keyword implies an implicit import of all symbols from all modules according to the ASN.1 recommendation X.680 [4]. However, the missing `IMPORTS` keyword is interpreted by TITAN as an empty `IMPORTS`; keyword, thus, no symbols at all will be imported from any of the modules.
+
+.Supported ASN.1 types
+[cols=",,,,,,,",options="header",]
+|===
+|ASN.1 type |syntactic check| |semantic analyzing ||code generation ||(de)coding
+||type definition |value definition |typechecking |valuechecking|type definition |value assignment |
+|NULL |● |● |● |● |● |● |●
+|BOOLEAN |● |● |● |● |● |● |●
+|INTEGER |● |● |● |● |● |● |●
+|ENUMERATED |● |● |● |● |● |● |●
+|REAL |● |● |● |● |● |● |●^4^
+|BIT STRING |● |● |● |● |● |● |●
+|OCTET STRING |● |● |● |● |● |● |●
+|OBJECT IDENTIFIER |● |● |● |● |● |● |●
+|RELATIVE-OID |● |● |● |● |● |● |●
+|string^1^ |● |● |● |●^6^ |● |● |●
+|string^2^ |● |● |● |●^6^ |● |● |●^7^
+|string^3^ |● |● |● |●^6^ |● |● |●
+|CHOICE |● |● |● |● |● |● |●^5^
+|SEQUENCE |● |● |● |● |● |● |●^5^
+|SET |● |● |● |● |● |● |●
+|SEQUENCE OF |● |● |● |● |● |● |●
+|SET OF |● |● |● |● |● |● |●
+|===
+
+● supported +
+â—‹ not supported +
+1 IA5String, NumericString, PrintableString, VisibleString (ISO646String) +
+2 GeneralString, GraphicString, TeletexString (T61String), VideotexString +
+3 BMPString, UniversalString, UTF8String +
+4 only base 10 coding is supported +
+5 the ellipsis can be a problem during the decoding +
+6 the character repertoire is not checked +
+7 the conversion between ISO-10646 and ISO-2022 character stream is not fully implemented but can be overridden to meet the user’s needs
diff --git a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..68ccd3dd3908e5f40edc997ce0315bc948a6ad76
--- /dev/null
+++ b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
@@ -0,0 +1,1023 @@
+[[compiling-ttcn-3-and-asn-1-modules]]
+= Compiling TTCN–3 and ASN.1 Modules
+:toc:
+:table-number: 11
+
+You can translate your TTCN–3 and ASN.1 modules to C++ source code using the program compiler.
+
+[[command-line-syntax]]
+== Command Line Syntax
+
+This section describes the options allowed in the command line of the compiler and the Makefile generator.
+
+[[complier]]
+=== Compiler
+
+The program compiler resides in the directory `$TTCN3_DIR/bin`.
+
+The command line syntax of the compiler is the following:
+
+[source]
+compiler [ -abBcdDeEfgijlLMnNOpqrRstuwxXyY ] [ -J file ] [ -K file ] [ -z file ] [ -N old|new ][ -o dir ] [ -V n ] [ -P toplevel pdu ] [ -Qn ] [ -U none|type|"number" ] …[ -T ] module.ttcn [ -A ] module.asn … [ - module.ttcn module.asn … ]
+
+or
+
+[source]
+compiler -v
+
+or
+
+[source]
+orcompiler –-ttcn2json [ -jf ] … [ -T ] module.ttcn [ -A ] module.asn … [ - schema.json ]
+
+The compiler takes the name of files containing TTCN–3 and ASN.1 modules as arguments. The usual and recommended suffix is `.ttcn` for TTCN–3 and `.asn` for ASN.1 source files, but it is not stringentfootnote:[Other tool vendors may use .mp, .3mp or .asn1 suffixes as well.]. For TTCN–3 and ASN.1 modules, the names of the output files are the same as the name of the modules, except for the suffixes which are `.hh` and `.cc`.
+
+NOTE: In the ASN.1 module names hyphens are replaced by underscore character.
+
+WARNING: If you have a modular test suite, you have to translate all modules of the test suite in one step, i.e. you have to specify all TTCN–3 and ASN.1 files in the argument list.
+
+The switches denoted by square brackets are optional. More than one option may be merged for abbreviation. For example, `-r` `-u` has exactly the same meaning as `-ru`.
+
+The following command line options are available (listed in alphabetical order):
+
+* `-a`
++
+Enables the generation of Basic XML encoder/decoder functions for ASN.1 types. By default, these encoder/decoder functions are omitted because Basic XER has limited practical use.
+
+* `-A file`
++
+Forces the interpretation of file as an ASN.1 module.
+
+* `-b`
++
+Disables the generation of BER encoder/decoder routines for all ASN.1 types.
+
+* `-B`
++
+This is a legacy switch that allows the selected alternative in a `union` value to be unbound. This is only possible when initializing module parameters in the configuration file, and only if the selected alternative in question is a `record` or `set` (since initializing a record or set module parameter with empty braces {}, causes it to remain unbound).
++
+A warning is displayed whenever a `union` module parameter is initialized with an unbound selected alternative, and when a `union` with an unbound selected alternative is copied.
++
+This is only a temporary switch. It will be removed in future versions.
+
+* `-c`
++
+This switch is designed to help identifying compilation failures caused by mismatched versions of TTCN-3 and/or ASN.1 modules. If the compilation fails, the compiler will display the module checksums (and module version information, if available) computed during compilation.
+
+* `-d`
++
+This switch changes the way fields of ASN.1 SEQUENCE /SET types with DEFAULT values are handled. Without `-d`, the runtime handles the encoding and decoding of default values in a way that is consistent with DER and CER. With `-"d` in effect, the ETS is responsible for the handling of fields with default values. This makes it possible to send encodings which are valid BER but not valid DER/CER and to verify that the SUT has performed the encoding correctly (note that without `-d`, the cases marked * and ** below cannot be distinguished in TTCN code).
++
+[cols=",,",options="header",]
+|===
+|Sending |Without –d |With –d
+|Explicit value |Send value |Send value
+|Default value |Do not send (omit) |Send default value
+|omit |N/A |Do not send (omit)
+|===
++
+[cols=",,",options="header",]
+|===
+|Receiving |Without –d |With –d
+|Receive explicit value |TTCN sees value |TTCN sees value
+|Receive default value |TTCN sees default value* |TTCN sees default value
+|Omitted |TTCN sees default value** |TTCN sees `omit'
+|===
++
+For more details, see <<13-references.adoc#_14, [14]>>
++
+WARNING: Existing tests may behave differently when compiled with `-d`. Every behavior without `-d` can be duplicated when compiled with `-d`.
+
+* `-D`
++
+Instructs the compiler to not generate the user and time information into the header of the generated .cc and .hh files.
+
+* `-e`
++
+Instructs the compiler to use the legacy method of handling `encode` and `variant` attributes (see section <<4-ttcn3_language_extensions.adoc#legacy-codec-handling, Legacy codec handling>>).
+
+* `-E`
++
+Instructs the variant attribute parser to display warnings instead of errors for unrecognized/erroneous encoding variants.
+
+* `-f`
++
+Forces the compiler to overwrite (update) the output files even if they exist or the contents of them will be identical. Without this flag the output C++ header and source files will be overwritten only if their contents change compared to the previous version.
+
+* `-g`
++
+The compiler error/warning messages will contain the starting line number, and the starting column number if available. This option provides compatibility with the GNU compiler and many tools which are able to interpret its output (including Eclipse).
++
+If both `–g` and `–i` are specified, `-g` takes precedence.
+
+* `-i`
++
+The compiler error/warning messages will contain only the line numbers, the column numbers will remain hidden. This option provides backward compatibility with the error message format of earlier versions.
+
+* `-j`
++
+Disables the generation of JSON encoder/decoder routines for all TTCN–3 types.
+
+* `-K file`
++
+Enable code coverage for TTCN-3 modules listed in `file`. `file` is an ASCII text file which contains one `file` name per line. The set of files in file needs to be a subset of the TTCN-3 modules listed on the command line.
+
+* `-J file`
++
+The compiler will read the input files form `file` which must contain the input files separated by spaces. Every file that is in the `file` is treated as if they were passed to the compiler directly. It is possible to use the -A and -T flags to tell the compiler that a file is an ASN.1 or a TTCN-3 file.
++
+Example:
+[source]
+compiler Myttcn.ttcn Myasn.asn -J files.txt
++
+where the contents of the `files.txt` is the following:
++
+[source]
+First.ttcn Second.asn -T Third.ttcn -A Fourth.asn
++
+The command above is equivalent to this command:
++
+[source]
+compiler Myttcn.ttcn Myasn.asn First.ttcn Second.asn -T Third.ttcn -A Fourth.asn
++
+Because of the `-T` flag the `Third.ttcn` will be treated as a TTCN-3 file, and because of the `-A` flag the `Fourth.asn` will be treated as an ASN.1 file.
+
+* `-l`
++
+Instructs the compiler to generate source file and line information (that is, #line directives) into the output code so that the error messages of the C\++ compiler refer back to the lines of the original TTCN–3 input module. This makes finding the reason of C++ error messages easier. This option has effect only in the equivalent C++ code of TTCN–3 functions, test cases and control parts and this feature is not provided in other TTCN–3 definitions such as types, constants or templates.WARNING! This is an experimental feature and the C++ compiler may report misleading error messages that refer to totally wrong (e.g. non-existent) TTCN–3 line numbers. In these cases please turn off this flag, repeat the compilation and analyze the generated code manually. Without this flag, the compiler also inserts the source code information for the better understanding of C++ error messages, but only as C++ comments. This option has no impact on the run-time performance of the generated code. The compiler performs full semantic analysis on its entire input; it normally does not generate erroneous C++ code. So this option became obsolete and will be removed in future versions.
+
+* `-L`
++
+Instructs the compiler to add source file and line number information into the generated code to be included in the log during execution. This option is only a prerequisite for logging the source code information. The run-time configuration file parameters `OptionsSourceInfoFormat` and `LogEntityName` in <<7-the_run-time_configuration_file.adoc#logging, `[LOGGING]`>> have also to be set appropriately.This feature can be useful for finding the cause of dynamic test case errors in fresh TTCN3 code. Using this option enlarges the size of the generated code a bit and reduces execution speed slightly; therefore it is not recommended when the TTCN3 test suite is used for load generation.
+
+* `-M`
++
+Enforces legacy behavior when matching the value `omit`. Allows the use of the value `omit` in template lists and complemented template lists, giving the user another way to declare templates that match omitted fields. If set, an omitted field will match a template list, if the value `omit` appears in the list, and it will match a complemented template list, if `omit` is not in the list (the `ifpresent` attribute can still be used for matching omitted fields). This also affects the `ispresent` operation and the `present` template restriction accordingly.
+
+* `-n`
++
+Activates the debugger and generates extra code needed for gathering debug information and for inserting breakpoints into the TTCN-3 program.
+
+* `-N`
++
+Ignore `UNTAGGED` encoding instruction applied to top level union types when encoding or decoding with XML. Legacy behavior.
+
+* `-o dir`
++
+The output files (including Test Port skeletons) will be placed into the directory specified by `dir`. Otherwise, the current working directory is the default.
+
+* `-O`
++
+Disable the generation of OER encoding and decoding functions.
+
+* `-p`
++
+Instructs the compiler only to parse the given TTCN–3 and ASN.1 modules. This will detect only the syntax errors in them because semantic checks are not performed. The presence of all imported modules is not necessary, thus, it is allowed (and recommended) to parse the modules one-by-one.All options that influence the code generation are silently ignored when used together with `-p`.
++
+NOTE: This option includes complete syntax checks for TTCN–3 modules, but in ASN.1 there are some special constructs (e.g. the user-defined syntaxes) that cannot be parsed without semantic analysis. So there is no guarantee that an ASN.1 module is free of syntax errors if it was analyzed with compiler using the -p flag.
+
+* `-P top level pdu …`
++
+Defines a top-level pdu that must have the format `modulename.identifier`. If this switch is used, then only the defined top-level PDU(s) and the referenced assignments are checked and included in code generation, the other ASN.1 assignments are skipped. You can define not only types but any kind of ASN.1 assignments.
+
+* `-q`
++
+Quiet mode. Equivalent to the flag `-V 0`.
+
+* `-Q n`
++
+Quit after n errors (n must be a positive integer). The compiler will abort after encountering the specified number of errors.
++
+NOTE: Errors count is cumulative across all modules. Using this option may cause some modules not to be analyzed at all (if previous modules "used up" all the allowed errors).
+
+* `-r`
++
+Disables the generation of RAW encoder/decoder routines for all TTCN–3 types.
+
+* `-R`
++
+Instructs the compiler to generate code for use with the function test runtime. The size of the generated code is significantly reduced, much of the functionality was migrated to the runtime. The generated C++ code has to be compiled using the TITAN_RUNTIME_2 symbol and has to be linked with the function test version of the runtime library. For example instead of the library file libttcn3.a the alternative libttcn3-rt2.a file must be used. The included c++ header files are the same.
+
+* `-s`
++
+Instructs the compiler to parse the given TTCN–3 and ASN.1 modules and perform semantic analysis on them, but not to generate C++ output. The list of given modules shall be complete so it is not allowed to import from a module that is not in the list. All options that influence the code generation are silently ignored when used together with `-s`.
++
+NOTE: The TTCN–3 semantic analyzer of the compiler is still under development, thus, it is not capable of detecting every kind of semantic error.
+
+* `-S`
++
+Suppress context information. When the compiler reports an error or warning, it also reports context information (italic in the example below):
++
+[source]
+----
+quitter3.ttcn: In TTCN-3 module `quitter3':
+ quitter3.ttcn:11.3-23.3: In control part:
+  quitter3.ttcn:12.11-30: In variable definition `v_r':
+   quitter3.ttcn:12.20-28: error: Reference to non-existent field `z' in record value for type `@quitter3.R'
+----
++
+The `–S` option causes the compiler to output only the error (last line), without the preceding lines of context.
+
+* `-t`
++
+Generates Test Port skeleton header and source files for all port types in the input TTCN–3 modules. Existing Test Port files will not be overwritten unless the -f option is used.
++
+NOTE: In versions 1.1 and earlier this was the default behavior of the compiler, but if the existing Test Port source files were stored in a different directory, the generated new skeletons could be confusing.
+
+* `-T file`
++
+Forces the interpretation of file as a TTCN–3 module.
+
+* `-u`
++
+Forces the compiler to insert duplicated underscore characters in all output file names. This option turns on the compatibility mode with versions 1.1 or earlier.
+
+* `-U none|type|"number"`
++
+Selects the code splitting mode for the generated code. The option "none" means that the old code generation method will be used. When using the option "type", TITAN will create separate source files for the implementation code of the following types (for each module): sequence, sequence of, set, set of, union. In this case a common header file and a source file holding everything else will also be created. The option can also be a positive number. In that case each file will be split into "`number`" smaller files. The compiler tries to create files which have equal size and empty files may be created. The "number" parameter must be chosen carefully to achieve compilation time decrease. The "`number`" parameter should not be larger than the number of the CPU cores. This splitting mode only provides decreased compilation time, if the compilation is parallelized. For example, this can be achieved using the *make* command’s *-j* flag which needs a number argument that controls how many cores the compilation may use. This number should be equal to the "`number`" parameter. An example can be found <<titan-s-strategy-of-the-code-splitting-mechanism-when-using-a-number-u-number, here>> about TITAN’s strategy when splitting the files using the "`number`" parameter.
+
+* `-v`
++
+Prints version and license key information and exits.
+
+* `-V n`
++
+Sets the verbosity bit-mask directly to `n` (where n is a decimal value between 0 and 65535). Meaning of the bits:
++
+1: "NOT SUPPORTED" messages.
++
+2: WARNING messages.
++
+4: NOTIFY messages.
++
+32 | 16 | 8: DEBUG messages. The debug-bits act like a 3-bit-length number, so the debug level has a value between 0 and 7. It is useful in case of abnormal program termination.
++
+NOTE: When only parsing (option –p) DEBUG messages for ASN.1 values will appear in TTCN-3 form (e.x.: booleans will appear as `true` or `false`, instead of `TRUE` or `FALSE`).
++
+Example: If you use the option `-V 6`, then all NOTIFY and WARNING messages will be printed, but the "NOT SUPPORTED" messages will be suppressed. To have the most detailed log, use the option `-V 63`. The default is `-V 7`.
+
+* `-w`
++
+Suppresses all warning messages. Equivalent to `-V 4`.
+
+* `-x`
++
+Disables the generation of TEXT encoder/decoder routines for all TTCN–3 types.
+
+* `-X`
++
+Disables the generation of XER encoder/decoder routines for all TTCN–3 types.
+
+* `-y`
++
+Disable subtype checking. Subtype information is parsed but ignored, there is no semantic check of the parsed subtype data.
+
+* `-Y`
++
+Enforces legacy behaviour for "out" function parameters ("out" parameters will not be set to <unbound> at the start of the function, but will keep their entry value).
+
+* `-z file`
++
+Enables code coverage and profiling in the TTCN-3 files listed in the `file` argument. The TTCN-3 files in the list must be separated by new lines and must also appear among the compiler’s arguments.
+
+* `-`
++
+The single dash character as command line argument has a special meaning: it controls the selective code generation. After the list of all TTCN–3 and ASN.1 modules a subset of these files can be given separated by a dash. This option instructs the compiler to parse all modules, perform the semantic analysis on the entire module hierarchy, but generate code only for those modules that are listed after the dash again. It is not allowed to specify a file name after the dash that was not present in the list before the dash. If the single dash is not present in the command line the compiler will generate code for all modules.
+
+* `–ttcn2json`
++
+Changes the purpose of the compiler to generate a JSON schema from the types defined in the specified TTCN-3 and ASN.1 modules. The parsing and semantic check of the input modules is still executed, but a JSON schema is generated instead of the C++ files. This must always be the first compiler option, and the previously listed options don’t apply (apart from options `–A` and `–T`), instead the following options are available:
+
+* `-j`
++
+Only types that have JSON coding enabled are included in the generated schema.
+
+* `-f`
++
+Only types that have JSON encoding or decoding functions (or both) are validated by the schema.
+
+* `- file`
++
+The single dash character as command line argument can be used to specify the name of the generated JSON schema file (it must be followed by exactly one argument, which is the file name). If it is not present, the schema file name is generated from the name of the first input file (the extension "`.ttcn`" or "`.asn`" is replaced by "`.json`", or "`.json`" is appended to the end of the file name if neither extension is present).
++
+The meaning of options is also included in the manual page of the compiler. If your TTCN–3 installation is correct, the command `man compiler` will show you this manual page. If not, check the `MANPATH` environment variable.
+
+=== Makefile Generator
+
+You can generate the Makefile skeleton used for building the test suite using the program `ttcn3_makefilegen`, which resides in the directory `$TTCN3_DIR/bin`. See section 2.3.1 of the TITAN User Guide <<13-references.adoc#_13, [13]>> for details. The generated Makefile skeleton will use the parallel mode of the run-time environment by default. This can be overridden by using the option `-s` (see below).
+
+The command line syntax of the makefile generator is the following:
+
+[source]
+----
+usage: makefilegen [-abcdDEfFgGlLmMnNprRsStTVwWXZ] [-K file] [-P dir]
+[-J file] [-U none|type|’number’] [-e ets_name] [-o dir|file] [-z file]
+[-t project_descriptor.tpd [-b buildconfig]] [-I path] [-O file]
+TTCN3_module[.ttcn] ... ASN1_module[.asn] ... XSD_MODULE.xsd ... Testport_name[.cc] ...
+----
+
+or
+
+[source]
+makefilegen -v
+
+The ttcn3_makefilegen tool is able to process XSD modules along with TTCN3 or ASN1 modules. The `ttcn3_makefilegen` tool first translates the XSD modules into TTCN3 modules using the `xsd2ttcn` tool. The XSD modules will be parsed and the information which is needed for the Makefile generation will be extracted from them. It is a requirement that the XSD modules MUST be partially syntactically correct (the `schema` tag must be correct).
+
+The command line switches for generating Makefile(s) from Titan Project Descriptor (TPD) file(s) are not listed here, these are described in the next chapter.
+
+The switches denoted by square brackets are optional. More than one option may be merged for abbreviation. For example, `-g` `-p` has exactly the same meaning as `-gp`. The following command line options are available (listed in alphabetical order):
+
+* `-a`
++
+The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory.The flag generates a Makefile that is capable of using pre-compiled C++ and object files from central directories in order to save disk space and compilation time.WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCN–3 Executor and C++ compiler version, etc.).
+
+* `-c`
++
+Treat files not in the current directory as being in “central storage“. These files are assumed to be already built in their (separate) location.
+
+* `-d`
++
+Dumps the data used for Makefile generation.
+
+* `-e <ETS name>`
++
+Sets the name of the target binary program (i.e. the executable test suite) to <ETS name> in the generated Makefile. If this option is omitted, the name of the first TTCN–3 module will be used as default.
+
+* `-E`
++
+Instructs the variant attribute parser to display warnings instead of errors for unrecognized/erroneous encoding variants.
+
+* `-f`
++
+Forces the makefile generator to overwrite the output Makefile. Without this flag the existing one will not be overwritten.
+
+* `-g`
++
+Generates a Makefile that can be used with GNU `make` only. The resulting Makefile will be smaller and less redundant. It exploits the pattern substitution features of GNU `make`, which may cause syntax errors with other versions of make. By default, Makefiles generated for GNU `make` use incrementally updated dependency files instead of `makefilegen`.
+
+* `-G`
++
+Instructs the compiler to use the legacy encoding rules for semantic checking and for generating the code (see compiler option "-e" and its description in <<4-ttcn3_language_extensions.adoc#legacy-codec-handling, Legacy codec handling>>).
+
+* `-I path`
++
+Add path to the list of search paths which are used to search for referred TPD-s. `path` must be an absolute path and multiple `–I` switches can be used. The search paths are used when the `–t` switch is also present and a referred TPD project cannot be found at the location specified by `projectRelativeURI`. In this case the `makefilegen` tool tries to find the TPD file using the paths provided by `path`. If the `tpdName` attribute of a `ReferencedProject` element is present in the TPD, then the value of the `tpdName` attribute will be used as a TPD filename during the search. However if the `tpdName` attribute is missing, then the name attribute’s value with the `.tpd` suffix will be used. If there are multiple paths specified then the first `.tpd` file with the correct name found in the list of search paths is taken. See 6.1.3.4 for an example.
+
+* `-J file`
++
+The `makefilegen` tool will read the input files form `file` which must contain the input files separated by spaces. Every file that is in the `file` is treated as if they were passed to the `makefilegen` tool directly.
+
+* `-K file`
++
+Enable code coverage for TTCN-3 modules listed in `file`. `file` is an ASCII text file which contains one file name per line. The set of files in `file` needs to be a subset of the TTCN-3 modules listed on the command line. (This parameter is simply passed to the TTCN-3 compiler through `COMPILER_FLAGS` in the Makefile.)
+
+* `-l`
++
+Enable dynamic linking. All files of the project will be compiled with `–fPIC` and for each (static) object, a new shared object will be created. Then, these shared objects will be linked to the final executable instead of the (static) objects. It can be used to speed up the linking phase, in the price of somewhat lower performance and increased memory usage. It’s recommended to use this flag only in the development phase of the project. Please note, that both the project’s working directory (which holds the TITAN generated `.so` files) and the directory of TITAN libraries, most probably `${TTCN3_DIR}/lib`, should be appended to the `LD_LIBRARY_PATH` environment variable. Otherwise, the dynamic linker (or loader) won’t be able to locate the shared objects required by the executable. This option is not supported on Windows (platform string `WIN32`).
+
+* `-L`
++
+Create the makefile with library as the default target. The name of the generated library archive is <ETS name>_lib.so if the dynamic linking is enabled and <ETS name>.a otherwise.
+
+* `-m`
++
+Always use `makedepend` for dependencies. By default, for makefiles used by GNU `make`, the compiler (usually GCC) is used to generate dependency information in an incremental fashion. This switch reverts to the process for generic make tools, which uses the `makedepend` tool.
+
+* `-M`
++
+Enforces legacy behavior when matching the value `omit`. Allows the use of the value `omit` in template lists and complemented template lists, giving the user another way to declare templates that match omitted fields. If set, an omitted field will match a template list, if the value omit appears in the list, and it will match a complemented template list, if `omit` is not in the list (the `ifpresent` attribute can still be used for matching omitted fields). This also affects the `ispresent` operation and the `present` template restriction accordingly.
+
+* `-n`
++
+Activates the debugger and generates extra code needed for gathering debug information and for inserting breakpoints into the TTCN-3 program.
+
+* `-N`
++
+Ignore UNTAGGED encoding instruction applied to top level union types when encoding or decoding with XML. Legacy behavior.
+
+* `-o <dir> | < file>`
++
+Writes the Makefile to the given directory or file. If the given argument is an existing directory, the generated Makefile will be placed into that directory. Otherwise, it is assumed to be the name of the generated Makefile. By default the file name is `Makefile`, placed in the current working directory.
+
+* `-O <file>`
++
+Add file to the list of other files in the generated `Makefile` without analyzing the file contents and suffix. This option can be used to temporarily exclude some TTCN-3, ASN.1 modules ASN.1 or C++ files from the build process, but add them to the archive created by the command make archive.
+
+* `-p`
++
+Generates `Makefile` with TTCN–3 preprocessing. All the TTCN–3 source files with the suffix `.ttcnpp` will be preprocessed using the C preprocessor. For details see <<12-tips_&_troubleshooting.adoc#using-the-ttcn-3-preprocessing-functionality, Using the TTCN-3 Preprocessing Functionality>>.
+
+* `-R`
++
+Use function test runtime (TITAN_RUNTIME_2). Generates a Makefile that compiles and links the source code using the function test runtime.
+
+* `-s`
++
+Generates a `Makefile` skeleton to be used with the single mode of the run-time environment. The only difference between the Makefiles for single and parallel modes is the setting of variable `$``TTCN3_DIR` within them.
+
+* `-S`
++
+Suppresses all warning messages generated by the `makefilegen` tool.
+
+* `-U none|type|"number"`
++
+Generates a `Makefile` skeleton to be used with the chosen code splitting option. For details see the compiler options in 6.1.1.
+
+* `-v`
++
+Prints version and license key information and exits.
+
+* `-w`
++
+Suppresses all warning messages generated by TITAN compiler. This flag overrides the `suppressWarning` option in the `.tpd` file.
+
+* `-Y`
++
+Enforces legacy behaviour of the "out" function parameters (the "out" parameter will not be set to <unbound> at the start of the function, but will continue with the entry value).
+
+* `-z file`
++
+Enables code coverage and profiling in the TTCN-3 files listed in the `file` argument. The TTCN-3 files in the list must be separated by new lines and must also appear among the makefile generator’s arguments (this switch is ignored if the –t option is present).
++
+If any of the source (TTCN-3, ASN.1, user-written C++) files does not exist or cannot be accessed, `ttcn3_makefilegen` exits with an error.
++
+Other options are discussed in the next chapters.
+
+[[using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s]]
+=== Using the Makefile Generator to Generate Makefile(s) from Titan Project Descriptor file(s)
+
+It is possible to generate Makefile(s) from command line using the Titan Project Descriptor file(s) (TPD) generated by the Eclipse plugin. The Eclipse plugin generates a TPD file for each project. This file contains all the information needed to generate a Makefile for that project. See reference <<13-references.adoc#_17, [17]>> for details.
+
+The makefile generator validates the TPD file with a schema file which is located at `${TTCN3_DIR}/etc/xsd/TPD.xsd`. If there are validation errors or the xsd file cannot be found some warnings will be displayed, this validation can be disabled with the "-V" option. Validation errors will not prevent the generation of makefiles and symlinks, however if there are such warnings it is strongly recommended to check the TPD files for errors because these errors may cause either other errors during the generation of the makefiles and symlinks or the creation of invalid makefiles and symlinks.
+
+Projects can reference other projects. These dependencies between projects are contained by the generated TPD files. The TPD file is placed in the project root directory. Every project has also a working directory (usually named `bin') which is relative to the project root directory. The working directory will contain symlinks to all the source files contained by the project and the files generated when building the project. The TPD file of the project contains the names and relative paths of all the projects that the project depends on, therefore the relative location of these projects must not be changed or these won’t be found. For large projects the TPD files will describe a project hierarchy that is not necessarily a tree structure, for example:
+
+image::images/projecthierarchy_graph.png[project_hierarchy_graph]
+
+The command line makefile generator can process the TPD file hierarchy generated by Eclipse and generate one or more Makefiles for these. There are three methods to generate Makefiles:
+
+. Generate a single Makefile that will contain all files from all projects. The following command line options can be used for this: `-t` `–b` `–D` `–P` `–V` `-W`. When using this method the –c switch should not be used because in this case all the files are seen as part of one large project.
+. Generate a Makefile hierarchy recursively (-r): for each TPD file generate a Makefile that builds only one project but has a dependency on other projects using the feature called "central storage". This dependency relation in the Makefile means that prior to building a project all the other projects that it depends on must be built. The dependency relation is contained by the top-level project’s Makefile. For that to work the central storage (`-c` switch in the makefile generator) feature is used to avoid compiling the source files also in top level projects that have already been compiled in the sub-projects where they belong to. Using this one Makefile all the projects can be built in the proper order. The following command line options can be used for this: `-t` `–b` `–D` `–P` `–F` `–T` `–X` `–V` `-W` `-Z` `-H`.
+. Generate a Makefile hierarchy with improved linking method (`-Z`): for each TPD file generate a Makefile that builds only one project but has a dependency on other projects. It provides highly flexible way of linking static- and/or dynamic libraries together. The following command line options are obligatory `-`t `–Z` `–F` `–r` and these are optional: `–H` `–W`.
+
+When generating multiple Makefiles the working directories of each referenced project are determined by the TPD file of the project. The TPD file can contain more than one build configuration, but there’s always one active configuration. The active configuration is determined by the TPD file itself by the element `<ActiveConfiguration>`. Different build configurations can have different working directories and other settings. This can be overruled by the referencing project’s required configuration setting (via `<requiredConfiguration>` embedded into `<configurationRequirement>`) or in case of a top-level TPD by using the –b command line option. Both the Makefile and the symlinks to source files are generated into the working directory.
+
+If there is no "workingDirectory" specified in the TPD file, default directory will be created with name "bin". If more than one project define the same directory for working directory a collision can happen. This can be avoided by the command line switch –W (see below).
+
+If you want to generate Makefiles from tpd files with incremental dependency (via .d files), you shall apply switch –g and you must not apply –m, in addition to these the top level project descriptor (tpd) file shall contain the element ordering incremental dependency as follows:
+
+[source]
+<incrementalDependencyRefresh>
+true
+</incrementalDependencyRefresh>
+
+The following TPD related command line options are available:
+
+* `-t filename.tpd [-b buildconfig]`
++
+Use the supplied Titan Project Descriptor file to generate the Makefile. Information about directories, files and certain options is extracted from the TPD file and used to generate the Makefile(s). Additional files can be specified on the command line. Options from the command line override any option specified in the TPD file. If hierarchical makefilegen is ordered (-Frcg or –FrcgWp) then the immediately referred projects will be generated according to the element <requiredConfiguration> of the ordered top level active configuration. This is applied recursively.
+
+* `-b buildconfig`
++
+On top level use the specified build config instead of the default active configuration defined in the TPD.
+
+* `-r`
++
+Generate a Makefile hierarchy recursively from TPD hierarchy.
+
+* `-P <dir>`
++
+Print out a file list found in a given TPD and optionally in its referenced TPDs to `stdout`, relative to the given directory `<dir>`. It requires the `-t` option and a valid directory as its parameter. If used together with the `-a` option the list will contain absolute paths and the directory parameter will not be taken into account.
+
+* `-V`
++
+Disable validation of TPD file with the TPD.xsd schema file
+
+* `-F`
++
+Force the makefile generator to overwrite all output Makefiles. Without this flag the existing files in the Makefile hierarchy will not be overwritten.
+
+* `-T`
++
+Generate only the top-level Makefile of the hierarchy.
+
+* `-X`
++
+Generate an XML file that describes the project hierarchy as seen by the makefile generator.
+
+* `-D`
++
+Use current directory as working directory.
++
+NOTE: This flag overrides the working directory coming from the TPD. In case of Generate Makefile hierarchy recursively (`-r`) flag, `–D` flag is valid only for top level project.
+
+* `-W`
++
+Prefix working directories with project name. This is needed if more than one TPD file is in the same directory, because this directory will then be the root of more than one project. The working directories (usually `bin') wil conflict, by using –W the working directory name will be prefixed by the project name, for example `MyProject_bin'.
++
+NOTE: In case of incorrect TPD files, the errors are displayed multiple times if the faulty TPD is included more than once in the project structure.
+
+* `-Z`
++
+Use the improved linking method. It generates a flexible hierarchy of static and dynamic libraries. Each project can be set to build a static or dynamic library or an executable too.
+
+* `-H`
++
+Use hierarchical project generation. Use it with –Z option. It provides makefiles for generating hierarchical binaries without flattening the project hierarchy. make can be called in any working directory, the lower level projects will be handled properly. All project can be regarded as top level project. Execution time of make is higher than in case of applying –Z without –H. (The difference is 50-100% for top level modification, 0-10% for lower level modification.)
+
+Examples:
+
+. Hierarchical makefile file generation from the directory of the top level project:
++
+[source]
+makefilegen –FrcgWp –t MyTopLevelProj.tpd
+
+. Project hierarchy file generation:
++
+[source]
+makefilegen -rcX –t MyTopLevelProj.tpd
+
+. Hierarchical makefile file generation from the directory of the top level project:
++
+[source]
+makefilegen –FWrZH –t MyTopLevelProj.tpd
+
+. Generate list of files of all hierarchical projects: Go to the folder of your top level tpd file (or to the root directory of your projects) then use the following bash command:
++
+[source]
+makefilegen –V –P $(pwd) –t TopLevelProj.tpd
+
+. Create archive file of all files in all hierarchical projects:Go to the root directory of your projects then use the following bash command:
++
+[source]
+makefilegen –V –P $(pwd) –t path/to/your/TopLevelProj.tpd | xargs tar cfz YourArchive.tgz
+
+[[using-the-improved-linking-method-z-and-h-option]]
+==== Using the improved linking method (-Z and –H option)
+
+Node `<ReferencedProjects>` contains the projects whose `<defaultTarget>` is either a library (static or dynamic) or an executable. See the XML excerpt.
+
+[source]
+----
+<ReferencedProjects>
+    <ReferencedProject name="refProj1" projectLocationURI="../workspace/refProjDir1/refProj1.tpd"/>
+    <ReferencedProject name="refProj2" projectLocationURI="../workspace/refProjDir2/refProj2.tpd"/>
+</ReferencedProjects>
+<MakefileSettings>
+  <GNUMake>true</GNUMake>
+  <incrementalDependencyRefresh>true</incrementalDependencyRefresh>
+  <dynamicLinking>true</dynamicLinking>
+  <defaultTarget>library</defaultTarget>
+  <targetExecutable>bin/yourexecutable</targetExecutable>
+  <linkerLibraries>
+        <listItem>externallib1</listItem>
+  </linkerLibraries>
+  <linkerLibrarySearchPath>
+        <listItem>${externallib}/lib</listItem>
+  </linkerLibrarySearchPath>
+</MakefileSettings>
+----
+
+"refProj1" and "refProj2" are subprojects of the actual one. Other info about these subprojects can only be obtained in their own TPD file. `<incrementalDependencyRefresh>` is set to true in the project structure. `<GNUMake>` shall be set to true. In this scope other tools are not supported. The node `<dynamicLinking>` true sets the dynamic linking method for the actual project. The node `<defaultTarget>` indicates whether the output is a library. If it is omitted the output is an executable.
+
+`<linkerLibrarySearchPath>` and `<linkerLibraries>` provide information about third party (not in the project hierarchy) libraries.
+
+The solution is based on the following corner stones:
+
+Static and dynamic libraries can only be linked on `<defaultTarget>` executable build level. This means that a `<defaultTarget>` library cannot be generated by mixing other static and dynamic libraries.
+
+A `<defaultTarget>` library with dynamic linking can be generated only from its own project’s object file(s) and subprojects dynamic libraries.
+
+Static libraries are so called thin archives. This means that a static library is generated from own projects’s object file(s) and contains links to object files of other thin archive(s).
+
+Third party libraries (e.g.: Linux core libs, openssl) can only be linked dynamically.
+
+If the `<defaultTarget>` is library and `<dynamicLinking>` is true, the following aspects are to be considered:
+
+* it can be linked together with another dynamic library
+* it cannot be linked together with a static library
+* it can be linked together with a third party dynamic library (e.g. openssl)
+* it cannot have subproject(s) with `<defaultTarget>` is executable
+
+Position dependent code cannot be linked with position independent code. This is a known limitation of the GNU linker. The third party libraries shall be added to LD_LIBRARY_PATH, or be copied to a directory contained by the LD_LIBRARY_PATH
+
+If the <defaultTarget> is library and and <dynamicLinking> is false, the following aspects are to be considered:
+
+* it can be linked together with another static library
+* it cannot be linked together with a dynamic library
+* it cannot be linked together with a third party static libraryfootnote:[Not supported] (e.g. openssl)
+* it can have subproject(s) with `<defaultTarget>` is executable
+
+If the project’s `<defaultTarget`> is an executable, then the static and dynamic libraries can be linked together. If on a lower level project there is reason to link static and dynamic libraries together, then the node `<defaultTarget>` shall be set to executable, too. If –H option is NOT set then NO executable file will be generated for lower level projects. In this case the Makefile will generate only objects. The top-level project’s `<defaultTarget>` shall be set to executable. This is not checked if the -H option is set, since it causes every node to behave as if it were the top-level node.
+
+*Important*: within a Project hierarchy if the real top-level project with `<defaultTarget>` executable is set to `<dynamicLinking>` true, then every sublevel project with `<defaultTarget>` executable shall be set to `<dynamicLinking>` true as well. A top-level project with `<defaultTarget>` executable and `<dynamicLinking>` false has no such constraint. If the above requirements are not fulfilled it results in a linker error. The Project hierarchy cannot contain circular references otherwise an error will be displayed.
+
+The makefile uses the linker flag –rpath, so there is no need to set the environment variable LD_LIBRARY_PATH for the libraries in the project hierarchy.
+
+If option –H is used: There is a new make command in the makefile that is generated by using the H flag. The call of *make clean-all* cleans the whole hierarchy, whereas the behavior of *make clean* changed, it only cleans the actual project.
+
+If option –H is not used: In a cleaned Makefile structure the *make* shall be called in the working directory of the top-level project.
+
+The optimal TPD for hierarchical structure (-H option)
+
+The following picture shows a simple Project structure:
+
+image::images/struct.png[struct]
+
+The arrows show the Project references. T1 has two `<ReferencedProjects>` nodes in the TPD: M1 and M2. M1 has three: S1, S2 and S3, and so on. Since the structure is hierarchical S2 will be iterated twice. M1-S2 dependencies make S2 be compiled and linked. The makefile of M2 only knows about the project S2. If the code for M2 is generated, the iteration of S2 is inevitable, even if the make of M1 had generated the code. This cannot be avoided and increases the run time of T1’s make. But relations like T1-S3 (red arrow) should be omitted since they are unnecessary and avoidable. T1 does not need to iterate S3 since M1 did it before and T1 can reach it via M1. Summarized: Try to minimize the loops in the project hierarchy graph. In big hierarchies (50-100 Projects) a well-organized structure can have an overhead of up to 50%-100%. A poorly organized one can run even 5 times longer than the flat hierarchy (without –H option).
+
+Rewriting an existing hierarchy can lead to linker errors. For example: an error message beginning with “_undefined reference to…”_ means that one (or more) project(s) is/are missing from the calling one.
+
+*Usage hints:*
+
+. Hierarchical building can be applied by option –Z.
+
+. Any project can be regarded as top level project if the makefiles are generated with the additional option –H.
+
+. Remove unnecessary references. It can dramatically decrease the hierarchical build time. The Project hierarchy cannot contain circular references.
+
+. To optimize the building time, work only on the highest-level project(s). They should be set for executable, all lower level and all unused branches should be set for library, especially for dynamically linked library. Take into account that it is not the best solution for the the final executable because the dynamically linking libraries can decrease the speed of running.
+
+==== Placing custom rules and new targets into the generated Makefile
+
+Custom rules and new targets can be inserted into the generated Makefile. This feature consists of two parts: calling a script whose output will be inserted into the generated Makefile and specifying new targets in the TPD file which will be inserted into the generated Makefile to the appropriate places. These two parts can be used together to accomplish the desired solution. The script shall print the project’s custom Makefile rules to its standard output.
+
+These rules have targets such as:
+
+[source]
+customtarget : dependency1 dependency2
+      <command1>
+      <command2>
+
+
+The second part of the feature is to add these custom targets to other specified places of the Makefile. Currently these places are: `PHONY`, `TTCN3_MODULES`, `TTCN3_PP_MODULES`, `TTCN3_INCLUDES`, `ASN1_MODULES`, `USER_SOURCES`, `USER_HEADERS`, `USER_OBJECTS`, `OTHER_FILES`. These places usually contain a list of files which will be used in the build process at different stages. By adding a new custom target to one or more of these places it becomes part of the dependency tree which will be processed by the make program and our new custom rule will be automatically invoked when necessary.
+
+An example of how to print some message when make is done with the "all" target: +
+First make a script that prints the rule itself (here a python script): +
+
+[source]
+print """
+buildwithmessage: all
+         @echo 'Here i built the project for you!!!'
+"""
+
+Next add the new rule to the appropriate place, in this case to the `PHONY` targets because it’s not a real file to be created. The script invocation and the addition of the new target are specified in the TPD file inside the MakefileSettings element (after the `buildLevel` element):
+
+[source]
+<ProjectSpecificRulesGenerator>
+  <GeneratorCommand>python MyRulesAdder.py</GeneratorCommand>
+  <Targets>
+    <Target name=" buildwithmessage" placement="PHONY"/>
+  </Targets>
+</ProjectSpecificRulesGenerator>
+
+To see the message after the build make shall be invoked with the new target: `make buildwithmessage`
+
+Of course in most cases real files are generated and not phony targets. These can be ttcn files generated from some type descriptions written in other notations or languages. Or cc/hh files generated by lexer and parser generators (flex/bison). In these cases the generated file name shall be the custom target and it shall be added to places like `TTCN3_MODULES` or `USER_SOURCES`. This way when the make program encounters a rule that depends on the new target (for example our new custom ttcn-3 source file) it will use our added custom rule and the <command> part of that rule will create/update the ttcn-3 file before it will be used by the TITAN compiler to generate cc/hh files and then object file and finally the executable.
+
+This method of making changes on the generated Makefile is preferred over the legacy makefile modifier scripts method. The makefile modifier scripts are error prone because these contain many assumptions about the exact content of the Makefile which may not be true for future versions of the makefile generator.
+
+==== External directory usage in tpd
+
+External directory usage is described with OSS_DIR example.
+
+To enable proper OSS usage, some parameters must be set in the tpd file. Lower extractions from tpd file can be seen, details which are useful for setting up OSS usage.
+[source]
+----
+<Files>
+    <FileResource projectRelativePath="OSS_H323_MESSAGES.c" relativeURI="src/OSS_H323_MESSAGES.c"/>
+    <FileResource projectRelativePath="OSS_H323_MESSAGES.h" relativeURI="src/OSS_H323_MESSAGES.h"/>
+    <FileResource projectRelativePath="OSS_H323_MESSAGES_linux.c" relativeURI="src/OSS_H323_MESSAGES_linux.c"/>
+ </Files>
+
+<ActiveConfiguration>Default</ActiveConfiguration>
+  <Configurations>
+    <Configuration name="Default">
+      <ProjectProperties>
+        <MakefileSettings>
+          <preprocessorIncludes>
+            <listItem>[OSS_DIR]/include</listItem>
+          </preprocessorIncludes>
+          <linkerLibrarySearchPath>
+            <listItem>[OSS_DIR]/lib</listItem>
+          </linkerLibrarySearchPath>
+        </MakefileSettings>
+----
+
+NOTE: OSS_DIR system variable needs to be set properly in your path.
+
+NOTE: Using makefile updater scripts are obsolete.
+
+==== Referred project usage with –I switch
+
+If there are different TPD projects which often change location, then the –I path switch(es) can be used.
+
+Example TPD structure:
+`MainTpd.tpd` is the top level TPD and has several project dependencies. `MainTpd` depends on the following projects: `DepTpd1.tpd`, `DepTpd2.tpd` and `DepTpd3.tpd`.
+[source]
+----
+MainTpd.tpd is located at /home/titan/main_project/MainTpd.tpd
+DepTpd1.tpd is located at /home/titan/dep_project1/DepTpd1.tpd
+DepTpd2.tpd is located at /home/titan/dep_project2/DepTpd2.tpd
+DepTpd3.tpd is located at /home/titan/random_folder/ dep_project3/DepTpd3.tpd
+----
+
+The relevant part of the MainTpd.tpd is the following:
+[source]
+----
+<TITAN_Project_File_Information version="1.0">
+  <ProjectName>MainTpd</ProjectName>
+  <ReferencedProjects>
+    <ReferencedProject name="DepTpd1" projectLocationURI="../dep1/DepTpd1.tpd" />
+    <ReferencedProject name="DepTpd2X" tpdName="DepTpd2.tpd" projectLocationURI="../incorrect/path/DepTpd2.tpd" />
+    <ReferencedProject name="DepTpd3" projectLocationURI="../incorrect/path/DepTpd3.tpd" />
+  </ReferencedProjects>
+----
+
+When executing the `makefilegen` command
+[source]
+----
+makefilegen –t MainTpd.Tpd –I /home/titan/foo
+–I /home/titan/dep_project2
+–I /home/titan/random_folder/dep_project3
+----
+
+Then the tool’s logic when resolving the paths is the following:
+
+The first referred project’s name is `DepTpd1` and the tool will be able to find the `DepTpd1.tpd` in the relative path provided in the `projectLocationURI` attribute. The next referred project’s name is DepTpd2X and the tool will NOT be able to find the `DepTpd2.tpd` in the relative path provided in the `projectLocationURI` attribute. In this case the tool looks for the `tpdName` attribute which is now present. The tool takes the value of the `tpdName` attribute and in input order tries to find the `DepTpd2.tpd` at the paths in the –I switches. First try is at `/home/titan/foo` which is not correct. Second try is at `/home/titan/dep_project2 which` is correct because the DepTpd2.tpd file is at `/home/titan/dep_project2/DepTpd2.tpd` and the search stops at this point. No further trying will be done.
+
+The last referred project’s name is DepTpd3 and the tool will NOT be able to find the `DepTpd3.tpd` in the relative path provided in the projectLocationURI attribute. In this case the tool looks for the `tpdName` attribute which is NOT present now. In this case the tool takes the value of the name attribute and concatenates it with the `.tpd` suffix and this name will be used during the search. The first and second tries are not successful but the third try is correct because the `DepTpd3.tpd` file is at `/home/titan/random_folder/dep_project3/DepTpd3.tpd`.
+
+NOTE: We strongly advise you to not use this feature. Most projects don’t need this feature.
+
+==== Usage of code splitting when generating makefile from TPD
+
+The `makefilegen` tool allows the usage of code splitting mechanisms when generating makefile(s) from a TPD file using the `codeSplitting` tag in the TPD with a few restrictions:
+
+* In the project hierarchy every project shall have the same `codeSplitting` tag set. The `codeSplitting` tag can have the following values: none, type, a positive number, or an empty string which defaults to none. If the `codeSplitting` tag is missing, then the code splitting strategy will set to none.
+* Code splitting is not supported when the H or Z flags are used. (see page 228)
+
+[[titan-s-strategy-of-the-code-splitting-mechanism-when-using-a-number-u-number]]
+==== TITAN’s strategy of the code splitting mechanism when using a "number" (-U "number")
+
+Let "number" be equal to 4 for this example. We want to split the files into four pieces.
+
+Firstly, TITAN finds the TTCN3 module whose C\++ generated code will be the largest. In this example, it will be 10000 characters (let’s call it MAX). So the largest generated C++ module contains 10000 characters.
+
+Secondly TITAN calculates the splitting threshold by dividing MAX with "number", so it will be 10000 / 4 = 2500 in this case. TITAN will only split the generated c++ files which are larger than 2500 characters.
+
+*BUT* TITAN will always generate "number" pieces for each file. The reason behind this is the following: The makefilegen tool needs to know what c++ files will be generated.
+
+Let’s complete the example.
+
+We have three TTCN3 modules:
+
+* `My_Types.ttcn` (whose generated c++ code contains 10000 characters (MAX))
+* `My_Functions.ttcn` (whose generated c++ code contains 6000 characters)
+* `My_Constants.ttcn` (whose generated c++ code contains 1000 characters)
+
+If we execute the command: compiler `-U 4 My_Types.ttcn My_Functions.ttcn My_Constants.ttcn` the following c++ source files will be generated:
+
+* `My_Types_part_1.cc` (contains approximately 2500 characters)
+* `My_Types_part_2.cc` (contains approximately 2500 characters)
+* `My_Types_part_3.cc` (contains approximately 2500 characters)
+* `My_Types_part_4.cc` (contains approximately 2500 characters)
+* `My_Functions_part_1.cc` (contains approximately 2500 characters)
+* `My_Functions_part_2.cc` (contains approximately 2500 characters)
+* `My_Functions_part_3.cc` (contains approximately 1000 characters)
+* `My_Functions_part_4.cc` (contains approximately 0 effective characters)
+* `My_Constants_part_1.cc` (contains approximately 1000 characters)
+* `My_Constants_part_2.cc` (contains approximately 0 effective characters)
+* `My_Constants_part_3.cc` (contains approximately 0 effective characters)
+* `My_Constants_part_4.cc` (contains approximately 0 effective characters)
+
+[[the-compilation-process-for-ttcn-3-and-asn-1-modules]]
+== The Compilation Process for TTCN–3 and ASN.1 Modules
+
+Before analyzing the input modules the compiler applies some heuristics for each source file to determine whether it contains a TTCN–3 or ASN.1 module. These so-called pre-parsing algorithms consider only the first few words of the files so it can happen that the compiler is unable to recognize its input and stops immediately with an error message. This is the case, for example, if the beginning of the module is either erroneous or contains strange and misleading comments. In this case using the command-line options `-T` and `-A` you can bypass the pre-parsers and force to interpret the corresponding file as a TTCN–3 or ASN.1 module, respectively.
+
+During its run, the compiler reports its activities on its standard error stream like the following. The level of detail for these messages can be controlled with the flag `-V`.
+[source]
+----
+Notify: Parsing TTCN-3 module ’MyModule.ttcn’...
+Notify: Parsing ASN.1 module ’MyAsnModule.asn’...
+Notify: Checking modules...
+Notify: Generating code...
+Notify: File ‘MyModule.hh’ updated.
+Notify: File ‘MyModule.cc’ updated.
+Notify: File ‘MyAsnModule.hh’ updated.
+Notify: File ‘MyAsnModule.cc’ updated.
+Notify: 4 files updated.
+----
+
+First, the compiler reads the TTCN–3 and ASN.1 input files and performs syntax check according to the BNF of TTCN–3 <<13-references.adoc#_1, [1]>> (including the additions of <<13-references.adoc#_3, [3]>>) or ASN.1 <<13-references.adoc#_4, [4]>>, <<13-references.adoc#_7, [7]>>, <<13-references.adoc#_8, [8]>>, <<13-references.adoc#_9, [9]>>. The syntax errors are reported with the appropriate line number. Whenever it is possible, the compiler tries to recover from syntax errors and continue the analysis in order to detect further errors.
+
+NOTE: Error recovery is not always successful and it might result in additional undesired error messages when the parser gets out of synchronization. Therefore it is recommended to study the first lines on the compiler’s error listings because the error messages at the end are not always relevant.
+
+After the syntax check the compiler performs semantic analysis on TTCN–3 /ASN.1 module(s) and verifies whether the various definitions and language elements are used in the appropriate way according to the static semantics of TTCN–3 and ASN.1 languages. In addition to error messages the compiler reports a warning when the corresponding definition is correct, but it might have unwanted effects.
+
+If both syntax and semantic checks were successful, the compiler generates a C++ header and source file that contains the translated module. If the name of the input module is `MyModule` (i.e. it begins with module `MyModule`), the name of the generated header and source file will be `MyModule.hh` and `MyModule.cc`, respectively. Note that the name of the output file does NOT depend on the name of input file. In ASN.1 module names the hyphens are converted to underscore characters (e.g. the C++ code for `My-Asn-Module` will be placed into `My_Asn_Module.hh` and `My_Asn_Module.cc`).
+
+By default, the compiler generates the C++ code for all input modules. This can be unnecessarily time-consuming when doing incremental builds for large projects. The build process can be significantly speed up if the compiler option - (single dash) is used. In this case the C++ code will be generated only for those modules that have changed since last build of the ASN.1 modules. With selective code generation it can be exploited that the make utility can easily tell which source files were changed since the last compilation.
+
+This sophisticated command line syntax is necessary because in general case it is impossible to perform the semantic analysis on a subset of the modules because those may import from modules outside the list. Moreover, to avoid undesirable side-effects of the code optimization techniques implemented in the compiler (e.g. type and value folding) the C++ code is generated not only for the modified modules, but for all modules that import definitions (either directly or indirectly) from the modified ones.
+
+When the compiler translates an ASN.1 module, the different ASN.1 types are mapped to TTCN–3 types as described in the table below.
+
+.Mapping of ASN.1 types to TTCN–3 types
+[cols=",",options="header",]
+|===
+|ASN.1 |TTCN–3
+|Simple types |
+|NULL |– *
+|BOOLEAN |boolean
+|INTEGER |integer
+|ENUMERATED |enumerated
+|REAL |float
+|BIT STRING |bitstring
+|OCTET STRING |octetstring
+|OBJECT IDENTIFIER |objid
+|RELATIVE-OID |objid
+|string † |charstring
+|string ‡ |universal charstring
+|string § |universal charstring
+|*Compound types* |
+|CHOICE |union
+|SEQUENCE |record
+|SET |set
+|SEQUENCE OF |record of
+|SET OF |set of
+|===
+
+\* there is no corresponding TTCN–3 type +
+† IA5String, NumericString, PrintableString, VisibleString (ISO646String) +
+‡ GeneralString, GraphicString, TeletexString (T61String), VideotexString +
+§ BMPString, UniversalString, UTF8String +
+
+[[particularities-of-asn-1-modules]]
+== Particularities of ASN.1 Modules
+
+This section describes the checks the complier performs on ASN.1 modules.
+
+=== Type Assignments
+
+In this first phase only basic checks are made: the compiler checks for unresolved and for circular references. The simplest example for circular reference is the following:
+[source]
+----
+T1 ::= T2
+T2 ::= T1
+----
+
+But there are more complex cases, especially related to non-optional fields of compound types. For example, X.680 clause 47.8.1 contains an illegal type definition:
+[source]
+----
+A ::= SET {
+  a A,
+  b CHOICE {
+    c C,
+    d D,
+    ...
+  }
+}
+----
+It is easy to see that one can not assign a (finite) value to a variable of type A: there is an endless recursion because of the field a, which is the same type as the parent-type. If this field were optional, then the recursion could be broken at any level.
+
+=== Value Assignments
+
+The compiler checks the unresolved/circular references also in case of value assignments.
+
+The value is checked according to the type:
+
+* `NULL`: Only the `NULL` value is accepted.
+
+* `BOOLEAN: TRUE` or `FALSE` value is accepted.
+
+* `BIT STRING:` You can use `hstring`, `bstring` or (even empty) set of named bits. In the latter case, the compiler checks if there are bits with the given names.
+
+* `OCTET STRING:` Only `hstring` or `bstring` form is accepted.
+
+* `character strings`: The `cstring`, `tuple`, `quadruple` form and the combination of these forms (`CharacterStringList`) are accepted.
+
+* `INTEGER`: Number form and named values (defined in the type with which the value is associated) can be used.
+
+* `REAL`: You can use the special values (`0`, `PLUS`-`INFINITY`, `MINUS`-`INFINITY`) as well as the associated `SEQUENCE` type (defined in X.680 clause 20.5) and the real number form (defined in X.680 clause 11.9).
+
+* `OBJECT IDENTIFIER`: All possible notations (i.e.` NameForm`, `NumberForm`, `NameAndNumberForm` and `DefinedValue`) can be used for the components. The predefined names given in Annex A-C of X.660 are recognized for the first two or three components. According to X.680 clause 31 it is checked whether the Number and `DefinedValue` is (a reference to) a non-negative integer or `OBJECT IDENTIFIER/RELATIVE-OID` value, respectively. If `NameAndNumberForm` is used, only the number is considered for the code generation. A warning message is displayed if in the first two components the given name and number is not in accordance with each other.
+
+* `ENUMERATED`: Only the identifiers defined in the corresponding type can be used.
+
+* `CHOICE`: The compiler checks if there is an alternative with the given name, then checks if the value corresponds to the type of the selected alternative.
+
+* `SEQUENCE` OF and `SET OF`: You can use the "empty" value (`{}`) or list of values separated by commas, enclosed in braces. Each value in the list is checked.
+
+* `SEQUENCE`: The values of the fields shall be in the same order as in the corresponding type definition. Components marked with OPTIONAL or DEFAULT can be skipped. The components are checked recursively.
+
+* `SET`: There shall be one and exactly one value definition for each not `OPTIONAL` or * `DEFAULT` component defined in the corresponding type. They can appear in any order.
+
+Named values (in case of `INTEGER` and `ENUMERATED`) have higher priority than defined values.
+
+=== Type Definitions
+
+The compiler makes an exhaustive check of the types defined in the module. For the different types, the following checks are executed:
+
+tagged types: As you can use value references in the tags, the compiler checks if the value is a non-negative integer.
+
+* `BIT STRING`: When using named bits, the bit number must be a non-negative integer. Each bit can have only one identifier (duplications are not permitted).
+
+* `INTEGER`: Value references in named numbers (if any) must reference integer values.
+
+* `ENUMERATED`: Value references (if any) must reference integer values. The compiler assigns a numberfootnote:[According to X.680 clause 19.3] for each item which does not have an associated number. Duplicated values (neither in identifiers, nor in associated number values) are not permitted. Items defined after an ellipsis must have associated numbers that increase monotonously. For details, see X.680 clause 19.
+
+* `CHOICE`: Every alternative must have different tag. Tags in the extension must increase monotonously (X.680 28.4). (The canonical order of tags is defined in X.680 8.4.)
+
+* `SEQUENCE`: The tags in optional groupsfootnote:[Optional group: One or more consecutive occurrences of OPTIONAL or DEFAULT fields, including the first not OPTIONAL or DEFAULT field.] must have different tags (X.680 24.5).All tags in the extension must be distinct from tags used in the first optional group after the second ellipsis (X.680 24.6).
+
+* `SET`: The types used in a SET type shall all have different tags (X.680 26.3).Tags in the extension must increase monotonously.
++
+Extension is not always permissible in `CHOICE`, `SEQUENCE` and `SET` (see X.680 47.7). Here is an example:
++
+[source]
+----
+Illegal-type ::= SET {
+  a INTEGER,
+  b CHOICE {
+    c C,
+    d D,
+    ...,
+    ...
+  },
+  ...,
+  e E
+}
+----
++
+The problem is that the (BER) decoder of a version 1 system cannot attribute an unknown element (received from a version 2 system) unambiguously to a specific insertion point.
+
+[[using-component-relation-constraints-from-ttcn-3]]
+== Using Component Relation Constraints from TTCN–3
+
+To handle constructs defined in X.681, X.682 and X.683 is not easy from TTCN–3. There is an ETSI technical reportfootnote:[TR 101 295] which describes how to transform these constructs to equivalent X.680 constructs. The clause 4.4 of this document is about transforming information objects.
+
+"The transformation rules presented in this clause cannot reproduce the full semantics of the information objects they replace. The transformation rules cannot preserve component relation constraints. These constraints provide the ability to constrain a type or value with reference to a different field within an information object set."
+
+This is not such a great problem, because BER does not "see" the constraints. But there is a situation when the transformations are unusable: when references to information object type fields are constrained by component relation constraints. Let’s take the example from X.682, clause 10 (with a little bit of modifications, to enlighten the problem):
+
+[source]
+----
+ERROR-CLASS ::= CLASS
+{
+  &category PrintableString(SIZE(1)),
+  &code INTEGER,
+  &Type
+
+}
+WITH SYNTAX {&category &code &Type}
+
+ErrorType1 ::= [1] INTEGER
+
+ErrorType2 ::= [1] REAL
+
+ErrorType3 ::= [1] CHARACTER STRING
+
+ErrorType4 ::= [1] GeneralString
+
+ErrorSet ERROR-CLASS ::=
+
+{
+  {"A" 1 ErrorType1} |
+  {"A" 2 ErrorType2} |
+  {"B" 1 ErrorType3} |
+  {"B" 2 ErrorType4}
+
+}
+
+ErrorReturn ::= SEQUENCE
+
+{
+  errorCategory ERROR-CLASS.&category ({ErrorSet}) OPTIONAL,
+  errors SEQUENCE OF SEQUENCE
+  {
+    errorCode ERROR-CLASS.&code({ErrorSet}{@errorCategory}),
+    errorInfo ERROR-CLASS.&Type({ErrorSet}{@errorCategory,@.errorCode})
+  } OPTIONAL
+}
+After applying the transformation rules described in ETSI technical report, the equivalent definitions look like this:
+
+ErrorReturn ::= SEQUENCE
+  {
+    errorCategory PrintableString(SIZE(1)) OPTIONAL,
+    errors SEQUENCE OF SEQUENCE
+    {
+      errorCode INTEGER,
+      errorInfo CHOICE
+      {
+        errorType1 ErrorType1,
+        errorType2 ErrorType2,
+        errorType3 ErrorType3,
+        errorType4 ErrorType4
+      }
+    } OPTIONAL
+  }
+----
+
+It is plainly seen that this is not a legal type definition: the alternatives of a `CHOICE` must have distinct tags. The original definition is unambiguous, because the `errorCode` component "tells" the decoder how to interpret the `errorInfo` component.
diff --git a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..f4b95f53885f81b47bbca1abd34419d78f5f2efc
--- /dev/null
+++ b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
@@ -0,0 +1,1858 @@
+= The Run-time Configuration File
+:toc:
+:table-number: 12
+
+The behavior of the executable test program is described in the run-time configuration file. This is a simple text file, which contains various sections. The usual suffix of configuration files is `.cfg`.
+
+Each section begins with a section name within square brackets. Different sections use different syntax, thus the section name determines the possible syntax of the members.
+
+The configuration file can contain any white space characters. There are three ways to put comments in the file: you can use the C comment delimiters (i.e. /* and */). Additionally, characters beginning with # or // are treated as comments until the end of line.
+
+Character string values shall be given between quotation marks. The non-printable characters as well as the quotation mark character within string values must be escaped using TTCN–3 or C escape sequences or quadruple notation. All kinds of escape sequences that are available in TTCN–3 and C languages (including octal and hexadecimal notation) are recognized.
+
+All sections are optional, thus an empty file is also a valid (but meaningless) configuration file. The sections are processed in the given order. In case of duplicated sections, all sections will be processed and no warnings will be issued.
+
+In the following we present all possible sections of the configuration file. The majority of sections are applicable in both single and parallel modes with identical meaning. However, some sections or settings in a section are applicable either in single or parallel mode only.
+
+The indication (Parallel mode) following the section title signals that the concerned section is processed in parallel operation mode only. Irrelevant sections or options are ignored in each mode and a warning message is displayed during configuration file processing. For details on running TITAN TTCN–3 test suites in either single or parallel mode using see the TITAN TTCN–3 User Guide (see <<13-references.adoc#_13, [13]>>).
+
+The component name defined by the `create` operation (see <<4-ttcn3_language_extensions.adoc#parameters-of-create-operation, here>>) can contain any characters. This component name can be used without quoted marks but it shall be used with quoted marks (i.e as quoted string) if it contains extra characters e.g. space (“ “), hyphen (“-“) or dot ("."). See also the examples of this chapter in sections <<module-parameters, [MODULE_PARAMETERS]>> and <<testport-parameters, [TESTPORT_PARAMETERS]>>.
+
+[[module-parameters]]
+== [MODULE_PARAMETERS]
+
+This section may contain the values of any parameters that are defined in your TTCN–3 modules.
+
+The parameters shall be specified after each other in any order. Each parameter must be given in the following order: module name (optional) <<13-references.adoc#_24, [24]>>, parameter name, field names (in case of records, sets or unions; optional) or array indexes (in case of arrays, records of or sets of; optional), assignment or concatenation operator (that is, the characters := or &=) and parameter value. An optional terminator semicolon may be used after each parameter value. The concatenation operator can be applied to list types (record of, set of). In this case only the value list notation can be used.
+
+[[bnf-productions-for-this-section-25]]
+=== BNF Productions for this Section
+
+In the Function Test runtime:
+[source]
+----
+ModuleParametersSection ::= "[MODULE_PARAMETERS]" {ModuleParameter}
+ModuleParameter ::= ParameterName ParamOpType ParameterValue [SemiColon]
+ParameterName ::= [(ModuleName | “*”) "."] ParameterIdentifier
+ModuleName ::= Identifier
+ParameterIdentifier ::= Identifier | ParameterIdentifier “.” Identifier
+| ParameterIdentifier “[” ParameterExpression “]”
+ParamOpType ::= “:=” | “&=”
+ParameterValue ::= ParameterExpression [LengthMatch] [“ifpresent”]
+ParameterExpression ::= SimpleParameterValue | ParameterIdentifier
+	| “(” ParameterExpression “)” | (“+” | “-”) ParameterExpression
+	| ParameterExpression (“+” | “-” | “*” | “/” | “&”) ParameterExpression
+LengthMatch ::= “length” “(“ LengthBound [“..” (LengthBound|”infinity”)] “)”
+LengthBound ::= ParameterExpression
+SimpleParameterValue ::= IntegerValue | FloatValue | BitstringValue | HexstringValue
+	| OctetstringValue | StringValue | UniversalCharstringValue | BooleanValue
+	| ObjIdValue | VerdictValue | EnumeratedValue | “omit” | “NULL” | “null”
+	| “?” | “*” | IntegerRange | FloatRange | StringRange
+	| “pattern” PatternChunk
+	| BitStringMatch | HexStringMatch | OctetStringMatch
+	| “mtc” | “system”
+	| CompoundValue
+IntegerValue ::= Number
+FloatValue ::= FloatDotNotation | FloatENotation
+StringValue ::= Cstring
+BitstringValue ::= Bstring
+HexstringValue ::= Hstring
+OctetstringValue ::= Ostring
+UniversalCharstringValue ::= Quadruple
+Quadruple ::= "char" "(" ParameterExpression "," ParameterExpression ","
+    ParameterExpression "," ParameterExpression ")"
+ObjIdValue ::= "objid" "{" {ObjIdComponent}+ "}"
+ObjIdComponent ::= NumberForm | NameAndNumberForm
+NumberForm ::= Number
+NameAndNumberForm ::= Identifier "(" Number ")"
+EnumeratedValue ::= Identifier
+PatternChunk ::= Cstring | Quadruple
+IntegerRange ::= “(“ (“-“ “infinity” | IntegerValue) “..” (IntegerValue | “infinity”) “)”
+FloatRange ::= “(“ (“-“ “infinity” | FloatValue) “..” (FloatValue | “infinity”) “)”
+StringRange ::= “(“ StringRangeBound “..” StringRangeBound “)”
+StringRangeBound ::= Cstring | Quadruple
+CompoundValue ::= “{“ “}”
+ 	| “{“ FieldValue {“,” FieldValue} “}”
+ 	| “{“ ArrayItem {“,” ArrayItem} “}”
+ 	| “{“ IndexItem {“,” IndexItem} “}”
+	| “(“ ParameterValue “,” ParameterValue {“,” ParameterValue} “)”
+	| (“complement” | “superset” | “subset”) “(“ParameterValue {“,”
+   ParameterValue} “)”
+FieldValue ::= FieldName “:=” ParameterValueOrNotUsedSymbol
+FieldName ::= Identifier | ASN1LowerIdentifier
+ArrayItem ::= ParameterValueOrNotUsedSymbol | (“permutation” “(“ParameterValue {“,” ParameterValue} “)”)
+IndexItem ::= “[“ ParameterExpression “]” “:=” ParameterValue
+ParameterValueOrNotUsedSymbol ::= ParameterValue | “-“
+----
+
+The BNF productions in the Load Test runtime are mostly the same with one difference:
+
+`ParameterIdentifier ::= Identifier`
+
+The parameter value can be one of the following:
+
+* Integer value. A number in decimal notation or an expression composed of numbers using the basic arithmetic operations to allow more flexibility with macro substitution.
+* Floating point value. A floating point number in decimal dot notation or exponential notation or an arithmetic expression composed of such values.
+* Bitstring value (in the notation of TTCN–3). String fragments can be concatenated to allow more flexible macro substitution.
+* Hexstring value (in the notation of TTCN–3). String fragments can be concatenated to allow more flexible macro substitution.
+* Octetstring value (in the notation of TTCN–3). String fragments can be concatenated to allow more flexible macro substitution.
+* Charstring value (between quotation marks; escape sequences are allowed). String fragments can be concatenated to allow more flexible macro substitution.
+* Universal charstring value (sequence of concatenated fragments; each fragment can be either a printable string within quotation marks or a quadruple in TTCN–3 notation).
+* Boolean value (`true` or `false`).
+* Object identifier (`objid`) value (in the notation of TTCN–3). Only `NumberForm` or `NameAndNumberForm` notations are allowed.
+* Verdict value (`none`, `pass`, `inconc`, `fail` or `error`).
+* Enumerated value (the symbolic value, i.e. an identifier). Numeric values are not allowed.
+* Omit value (i.e.` omit`). Valid for optional record or set fields only.
+* `null` value for TTCN–3 component and default references.
+* `NULL` value for the ASN.1 `NULL` type.
+* "?" value: AnyValue for matching
+* “*” value: AnyValueOrNone for matching
+* IntegerRange/FloatRange/StringRange: matching an integer/float/charstring range
+* Pattern for pattern matching in charstring and universal charstring
+* Bit/Hex/Octet –string matching mechanism which are bit/hex/octet strings that contain "?" and “*” for matching
+* "mtc" and "system" values for component references
+* Compound value with assignment notation. One or more fields (separated by commas) with field names within brackets for types `record` and `set`.
+* Compound value with value list notation. Comma separated list of values between brackets for types `record of`, `set of` and `array`.
+* Compound value with indexed list notation. One or more fields with field index and value for types record of and set of
+* Compound value containing a template list. Can be a value list, complemented value list, superset and subset list.
+* Reference to a module parameter (or a field/element of a module parameter). Its syntax is the same as the left hand side of a module parameter assignment/concatenation (except the symbol ‘*’ cannot be used to specify all modules). The reference is substituted with the current value of the specified module parameter (its value prior to the execution of this module parameter assignment/concatenation). References can also appear in the expressions specified above (integer and float references can appear in arithmetic expressions, references to string types can be concatenated with other strings of the same type). A dynamic test case error is displayed if the referenced module parameter is unbound.
+
+Nested compound values are permitted in arbitrary depth. In compound values with assignment and value list notations the “-“ symbol can be used to skip an element. In value list notation for record of and set of permutation lists can be used.
+
+Parsing conflict: An asterisk (*) after a module parameter expression could be treated as a multiplication operator or the "all modules" symbol for the next module parameter assignment/concatenation. The configuration parser always treats it as a multiplication operator. In order to use the asterisk as an "all modules" symbol, the previous statement must be closed with a semicolon (;).
+
+Example:
+[source]
+----
+# correct:
+tsp_IntPar := tsp_IntPar + 1;
+*.tsp_FloatPar := 3.0;
+# incorrect, causes a parser error:
+tsp_IntPar := tsp_IntPar + 1
+*.tsp_FloatPar := 3.0;
+----
+
+=== Differences between the TTCN-3 and the Configuration File Module Parameters Section Syntax
+
+Neither the ttcn-3 syntax nor the module parameter section syntax is the subset of the other. Historically some module parameter values that are not legal in ttcn-3 have been accepted, for backward compatibility reasons this behavior has been kept. In most cases the module parameter syntax is a subset of the ttcn-3 syntax but there are important exceptions:
+
+* Field values of records and sets can be referenced multiple times, in this case all field value assignments will be executed in order of appearance. Example: mp_myRecord := { a :=1, b:=3, a:=2 } // a==2
+* In an assignment notation used for a union multiple field values can appear, only the last value will be used. Example: mp_myUnion := { a:=1,b:=2,a:=3 } only a:=3 will be used, the other 2 assignments are disregarded without warnings.
+* The order of fields in assignment notation for records does not have to be identical to the order of fields specified in the type definition of the record type. Example: type record MYREC { integer a, integer b } mp_myRec := { b:=2, a:=1}
+* The “\*” matching symbol can be used for mandatory fields (in TTCN-3 this cannot be used directly but indirectly any field of a variable template can be set to “*”).
+
+In the module parameters section only constant values and references to module parameters can be used. Function calls are not allowed (not even predefined functions).
+
+Example:
+[source]
+----
+[MODULE_PARAMETERS]
+par1 := -5
+MyModule1.par2 := "This is a string\n"
+MyModule1.par3 := {
+  ethernet_header := {
+    source_address := ’000100010005’O,
+    destination_address := ’0008C7993605’O,
+    ether_type := 34525
+  },
+  ipv6 := {
+    header := {
+      version := 6,
+      traffic_class := 0,
+      flow_label := 0,
+      payload_length := 0,
+      next_header := 58,
+      hop_limit := 255,
+      source_address := ’FE80000000000000020100FFFE010005’O,
+      destination_address := ’FE800000000000000208C7FFFE993605’O
+    },
+    extension_headers := {
+      {
+        hop_by_hop_options_header := {
+          next_header := 1,
+          header_length := 2,
+          options := ’13’O
+        }
+      }
+    },
+    data := {
+      f_router_advertisement := {
+        icmp_type := 134,
+        code := 0,
+        checksum := 0,
+        hop_limit := 255,
+        m_bit := ’0’B,
+        o_bit := ’0’B,
+        reserved := ’000000’B,
+        lifetime := 600,
+        reachable_time := 300000,
+        retrans_timer := 1000,
+        options := {
+          {
+            lla := {
+              option_type := 1,
+              option_length := 1,
+              lla_address := ’0008C7993605’O
+            }
+          }
+        }
+      }
+    }
+  }
+}
+MyModule2.par4 := ’10010’B
+par5 := objid { itu_t(0) identified_organization(4) etsi(0) 12345 6789 }
+par6 := "Character " & char(0, 0, 1, 113) & " is a Hungarian letter."
+par_record_of_int &= {1,2,3}
+par_record_of_int &= {4,5,6}
+par_record_of_int[6] := 7
+MyModule1.par3.ethernet_header.ether_type := 34526
+----
+
+[[logging]]
+== [LOGGING]
+
+The executable test program produces a log file during its run. The log file contains important test execution events with time stamps[26]. This section explains how to set the log file name and the event classes to be logged. Logging may be directed to file or displayed on console (standard error).
+
+Various options can be set in the section [`LOGGING`]. They affect the format and appearance of the test execution logs. Any option may be omitted; that is, each has a default value that is used if the option is omitted. If the same option is present several times in a configuration file only the latest value will take effect; the previously assigned values are ignored and a warning message is issued during configuration file processing.
+
+[[LoggerPlugins]]
+=== LoggerPlugins
+
+TITAN is equipped with an extensible logging architecture. The test execution events are directed towards the logger plugin interface. This interface can host arbitrary number of logger plugins.
+
+The logging can be statically and dynamically loaded.
+
+The default logging is the statically loaded built in logging.
+
+The dynamically loaded logging can be the built in LegacyLogger, the plugins shipped with TITAN (see <<dynamically-loaded-logger-plugins-shipped-with-titan, here>>) or user created dynamically linked plugins (for advanced users, see chapter 3 in <<13-references.adoc#_16, [16]>>.
+
+NOTE: *When using dynamically loaded logger plugins it is very important to use the dynamic runtime library of TITAN, this can be done by using the –l switch when generating the makefile.*
+
+The desired logger plugins need to be set in the `LoggerPlugins` option. The `LoggerPlugins` option takes a non-empty, comma separated list of logger plugin settings. These settings can be specified in the following ways:
+
+* A logger plugin identifier followed by an assignment and a quoted string containing the plugin location. E.g. `LoggerPlugins := { plugin1 := "/absolute/path/to/plugin1.so" } or LoggerPlugins := { plugin1 := "/absolute/path/to/plugin1" }`. The identifier of a logger plugin is determined by its author can be learned from its documentation. The plugin location includes the file name of the plugin with an optional file system path prefix. A logger plugin is a dynamically linked shared object thus the logger plugin typically resides in a `.so` file. When the path prefix is missing or a relative path is used then TITAN attempts to locate the plugin in the path specified in the `LD_LIBRARY_PATH` environment variable. The plugin file name can be provided in two different ways: either by specifying the whole file name (ending with .so) or by specifying only the base of the name (omit the .so ending). The latter method is preferred because a logger plugin usually consists of 4 different shared library files and the proper file must be selected. The 4 different versions correspond to the single/parallel mode and the load/function test TITAN runtimes. If the file name ending is not provided the executable will determine it automatically, but if the whole file name is provided then it must correspond to the runtime which is actually used by the executable.
+* A single logger plugin identifier. E.g. `LoggerPlugins := { plugin1 }`. In this case there should be a logger plugin named plugin1.so in one of the paths specified in the `LD_LIBRARY_PATH` environment variable.
+
+NOTE: If TITAN is unable to locate any of the listed logger plugins, it will quit immediately with an error message. So, if the `LoggerPlugins` option is used, take special care to set `LD_LIBRARY_PATH` correctly or use absolute paths when specifying the plugins. There is a built-in logger plugin in TITAN, which provides the usual text-based logging format. This plugin is used when the `LoggerPlugins` option is omitted or it was listed explicitly in the list with the `LegacyLogger` case insensitive identifier. Since it’s not possible to specify the path for this special, built-in logger plugin, only the second (with no path) specification mode is applicable here.
+
+The logger plugins are responsible for the "final appearance" of the test execution log. The current TITAN distribution comes with a single logger plugin but it also supports user written logging plugins. The built-in `LegacyLogger` plugin produces log files and console log entries with similar content to elder TITAN revisions.
+
+In case of overlapping plugin settings in multiple `LoggerPlugins` options, all configured plugins are attached to the list of existing plugins and take part in logging (i.e. do not overwrite them).
+
+The configured logger plugins are valid for each test component unless otherwise configured (see subsection below).
+
+It is possible to reference all the listed plugins with * to e.g. assign the same parameters and values for multiple plugins. However, plugin configuration through * will not have an effect on plugin parameters, whose value was set previously by referencing explicitly the exact plugin using its name and optionally the component identifier it is configured for.
+
+Logger plugins can be configured with arbitrary name-value pairs in the configuration file (see <<EmergencyLogging, here>>). E.g. `*.*.param1 := "value1"` will set the param1 parameter to a string value1 for all, not explicitly configured logger plugins on all test components. Logger plugins can ignore unknown parameters.
+
+Each logger plugin has 4 .so files. The following table contains the names of the 4 different cases if the base file name (this is not the name of the plugin, library file names start with "lib") of the plugin is "libplugin":
+
+NOTE: The preferred method of specifying the above logger plugin in the configuration file is: `LoggerPlugins := { MyPluginName := "libplugin"}` +
+The name MyPluginName is the name of the plugin and can be different than the library file names. If the full plugin file name is provided ( “libplugin.so, libplugin-parallel.so, etc.) then care must be taken to always use the name that corresponds to the mode in which the executable is running.
+
+==== Component-based Logger Plugin Settings
+
+It is possible to associate an individual set of logger plugins for each test component. The component designation can be:
+
+* the component name as given in the command `create`,
+* the component reference (though using component references as identifiers is not recommended as this is a tool dependent identifier),
+* the symbol * meaning all valid test components or
+* the keyword `mtc` in the case of the Main Test Component.
+
+The component name, if present, precedes the keyword `LoggerPlugins`. They are separated by a dot (.). The absent component reference is equivalent to `*.LoggerPlugins` meaning all valid test components.
+
+[[dynamically-loaded-logger-plugins-shipped-with-titan]]
+=== Dynamically Loaded Logger Plugins Shipped with TITAN
+
+Anyone can write a logger plugin to use with TITAN, but there are some widely used plugins that were made part of TITAN. These are available in the `$(TTCN3_DIR)/lib` sub-directory. Usually `LD_LIBRARY_PATH` contains this directory, if not then it should either be added to it or the path to the .so file has to be specified.
+
+[[junit-logger-plugin]]
+==== JUnitLogger Plugin
+
+It outputs XML files in JUnit format. This format is needed by Hudson/Jenkins, a continuous integration test tool. The XML files written by this logger plugin are a subset of the JUnit XML output format.
+
+At first select dynamic linking at Makefile generation according to <<LoggerPlugins, LoggerPlugins>>.
+
+To load the plugin the section `[LOGGING]` of the runtime configuration file should contain the following line: `LoggerPlugins := { JUnitLogger := "libjunitlogger" }`
+
+The plugin has 2 parameters:filename_stem: set the output file name, the name will start with the string specified in this parameter and end with "-<process_id>.log". The default value is "junit-xml". +
+testsuite_name: the name of the test suite, this will be written into the XML file.
+
+_Example 1:_ Simplest HelloWorld example.
+
+Source file
+[source]
+----
+module hello {
+  type component CT {}
+  testcase tc1() runs on CT {
+    log("Hello Titan!");
+    setverdict(pass,"Everything is ok");
+  }
+
+  testcase tc2() runs on CT {
+    log("Hello Titan!");
+    setverdict(fail,"Something was wrong");
+  }
+control {
+  execute(tc1());
+  execute(tc2());
+}
+
+}
+}
+----
+
+Configuration file (`cfg.cfg`):
+
+----
+[LOGGING]
+LogSourceInfo := Yes
+SourceInfoFormat := Single
+LoggerPlugins := { JUnitLogger := "libjunitlogger" }
+*.JUnitLogger.filename_stem := "MyJunitLogFile"
+*.JUnitLogger.testsuite_name := "myJUnitTest"
+
+[EXECUTE]
+hello.control
+----
+
+The makefile was generated by the command `makefilegen –fl hello.ttcn`.
+
+The executable was executed by the command `ttcn3_start hello cfg.cfg`.
+
+After running the log file name was `MyJunitLogFile-6426.log`, its content was:
+[source]
+----
+<?xml version="1.0"?>
+<testsuite name='myJUnitTest'><!-- logger name="JUnitLogger" version="v1.0" -->
+<!-- Testcase tc1 started -->
+<!-- Testcase tc1 finished in 0.000399, verdict: pass, reason: Everything is ok -->
+  <testcase classname='hello' name='tc1' time='0.000399'>
+  </testcase>
+<!-- Testcase tc2 started -->
+<!-- Testcase tc2 finished in 0.000225, verdict: fail, reason: Something was wrong -->
+  <testcase classname='hello' name='tc2' time='0.000225'>
+    <failure type='fail-verdict'>Something was wrong
+
+      hello.ttcn:14 hello control part
+      hello.ttcn:10 tc2 testcase
+    </failure>
+  </testcase>
+</testsuite>
+----
+
+*Format of the results*
+
+The results are included in testcases (between <testcase> tags) within a testsuite (between <testsuite> tags).The testsuite has only one attribute "name" which contains the name of the testsuite.
+
+Each testcase starts with two xml style comments which is followed by a <testcase> xml tag.
+
+*_The comments_*
+
+Each testcase starts with the following two xml comments:
+
+* `<!– Testcase "name of the testcase" started –>`
+* `<!– Testcase "name of the testcase" finished in "execution time is seconds", verdict:”verdict” –>`
+
+This is followed by a <testcase> tag.
+
+*_The <testcase> tag_*
+
+The <testcase> tag has the following attributes:
+
+* `classname=’name of the module’`
+* `name=’name of the testcase’`
+* `time=’execution duration in seconds’`
+
+Depending of the verdict the <testcase> may have element contents which can be the following:
+
+_Verdict: pass_
+
+No children
+
+_Verdict: fail_
+
+Has the following element content with the following attribute:
+
+<failure type=`fail-verdict'>
+
+The <failure> tag can have several of the following text contents – each in a separate line (see results log example above):
+
+* control part
+* testcase
+* altstep
+* function
+* external function
+* template
+
+Each line contains `"filename:linenumber identifier definition"`, where each of the items mean the following:
+
+* filename:linenumber – the file and the line where the test failed
+* identifier – the identifier depending on the definition, e.g. the classname in case of "control part" or the name of the test in case of "testcase"
+* definition – see the list in <failure> tag text content
+
+This is a simple stacktrace of the failure.
+
+Verdict: none
+
+[source]
+<skipped>no verdict</skipped>
+
+Verdict: `inconclusive`
+
+No children
+
+Verdict: `error`
+
+Has the following element content with the following attribute:
+
+[source]
+<error type='DTE'>
+
+The <error> tag has the text contents containing the reason of the error.
+
+*_XSD validation_*
+
+This is the xsd file to validate the xml generated by the plugin:
+[source]
+----
+<?xml version="1.0" encoding="UTF-8" ?>
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
+
+    <xs:element name="failure">
+        <xs:complexType mixed="true">
+            <xs:attribute name="type" type="xs:string" use="optional"/>
+        </xs:complexType>
+    </xs:element>
+
+    <xs:element name="skipped" type="xs:string"/>
+
+    <xs:element name="error">
+        <xs:complexType mixed="true">
+            <xs:attribute name="type" type="xs:string" use="optional"/>
+        </xs:complexType>
+    </xs:element>
+
+    <xs:element name="testcase">
+        <xs:complexType>
+            <xs:sequence>
+                <xs:element ref="skipped" minOccurs="0" maxOccurs="1"/>
+                <xs:element ref="error" minOccurs="0" maxOccurs="unbounded"/>
+                <xs:element ref="failure" minOccurs="0" maxOccurs="unbounded"/>
+            </xs:sequence>
+            <xs:attribute name="classname" type="xs:string" use="required"/>
+            <xs:attribute name="name" type="xs:string" use="required"/>
+            <xs:attribute name="time" type="xs:string" use="required"/>
+        </xs:complexType>
+    </xs:element>
+
+    <xs:element name="testsuite">
+        <xs:complexType>
+            <xs:sequence>
+                <xs:element ref="testcase" minOccurs="0" maxOccurs="unbounded"/>
+            </xs:sequence>
+            <xs:attribute name="name" type="xs:string" use="required"/>
+        </xs:complexType>
+    </xs:element>
+
+</xs:schema>
+----
+
+==== JUnitLogger2 Plugin
+
+It outputs XML files in JUnit format. This format is needed by Hudson/Jenkins, a continuous integration test tool. The XML files written by this logger plugin are a subset of the JUnit XML output format.
+
+The JUnitLogger2 plugin works as the <<junit-logger-plugin, JUnitLogger plugin>> with the following exceptions:
+
+* Configuration file (`cfg.cfg`):
++
+In the configuration file when specifying the logger plugin libjunitlogger2 should be written.
++
+[source]
+----
+[LOGGING]
+LogSourceInfo := Yes
+SourceInfoFormat := Single
+LoggerPlugins := { JUnitLogger := "libjunitlogger2" }
+*.JUnitLogger.filename_stem := "MyJunitLogFile"
+*.JUnitLogger.testsuite_name := "myJUnitTest"
+----
+* The results are included in testcases (between <testcase> tags) within a testsuite (between <testsuite> tags) like the JUnitLogger butthe testsuite has attributes other than "name" which contains the name of the testsuite.
++
+New attributes:
++
+tests – number of all testcases executed
++
+failures – number of testcases whose final verdict is fail
++
+errors – number of testcases that encountered an error
++
+skipped – number of testcases with a none verdict
++
+time – the time in seconds from the start of the tests until all the testcases executed.
++
+* XML comments are not added to the output.
+* XSD:
++
+[source]
+----
+<?xml version="1.0" encoding="UTF-8" ?>
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
+
+	<xs:element name="failure">
+		<xs:complexType mixed="true">
+			<xs:attribute name="type" type="xs:string" use="optional"/>
+		</xs:complexType>
+	</xs:element>
+
+	<xs:element name="skipped" type="xs:string"/>
+
+	<xs:element name="error">
+		<xs:complexType mixed="true">
+			<xs:attribute name="type" type="xs:string" use="optional"/>
+		</xs:complexType>
+	</xs:element>
+
+	<xs:element name="testcase">
+		<xs:complexType>
+			<xs:sequence>
+				<xs:element ref="skipped" minOccurs="0" maxOccurs="1"/>
+				<xs:element ref="error" minOccurs="0" maxOccurs="unbounded"/>
+				<xs:element ref="failure" minOccurs="0" maxOccurs="unbounded"/>
+			</xs:sequence>
+			<xs:attribute name="classname" type="xs:string" use="required"/>
+			<xs:attribute name="name" type="xs:string" use="required"/>
+			<xs:attribute name="time" type="xs:string" use="required"/>
+		</xs:complexType>
+	</xs:element>
+
+	<xs:element name="testsuite">
+		<xs:complexType>
+			<xs:sequence>
+				<xs:element ref="testcase" minOccurs="0" maxOccurs="unbounded"/>
+			</xs:sequence>
+			<xs:attribute name="name" type="xs:string"  use="required"/>
+			<xs:attribute name="tests" type="xs:int" use="required"/>
+			<xs:attribute name="failures" type="xs:int" use="required"/>
+			<xs:attribute name="errors" type="xs:int" use="required"/>
+			<xs:attribute name="skipped" type="xs:int" use="required"/>
+			<xs:attribute name="time" type="xs:string" use="required"/>
+		</xs:complexType>
+	</xs:element>
+
+</xs:schema>
+----
+
+==== TSTLogger plugin
+
+The `TestStatistics` TITAN Logger plugin sends HTTP messages to the `TestStatistics` web based tool. `TestStatistics` has a web interface (http://eta-teststatistics.rnd.ki.sw.ericsson.se/ts/login) where the test result data can be examined. Currently the following messages are sent to the `TestStatistics` tool:
+
+* Test suite started (tsstart)
+* Test case started (tcstart)
+* Test case finished (tcstop)
+* Test suite finished (tsstop)
+* Test case fail reason (tcfailreason)
+
+The content of these messages is filled based on the log data and data given in the configuration file. Some data needs to be set as logger plugin parameters in the configuration file because it is needed by the `TestStatistics` tool but the TITAN log messages do not contain such information. The plugin parameters:
+
+[cols="m,,",options="header",]
+|===
+|Name |Default value |Description
+|tst_host_name |"eta-teststatistics.rnd.ki.sw.ericsson.se" |`TestStatistics` web service host name
+|tst_service_name |"http" |`TestStatistics` web service name or port number
+|tst_tcstart_url |"/ts-rip/rip/tcstart" |Path for the tcstart message
+|tst_tcstop_url |"/ts-rip/rip/tcstop" |Path for the tcstop message
+|tst_tsstart_url |"/ts-rip/rip/tsstart" |Path for the tsstart message
+|tst_tsstop_url |"/ts-rip/rip/tsstop" |Path for the tsstop message
+|tst_tcfailreason_url |"/ts-rip/rip/tcfailreason" |Path for the tcfailreason message
+|dbsUrl |"esekilx0007-sql5.rnd.ki.sw.ericsson.se:3314" |database URL
+|dbUser |"demo" |database user
+|dbPass |"demo" |plain text password of the user
+|dbName |"teststatistics_demo" |name of the database
+|log_plugin_debug |"0" |The logger plugin will print some debug information to the console if this value is not "0".
+|testConfigName |"DefaultConfigName" |name of this specific configuration of the test suite
+|suiteName |"DefaultSuiteName" |name of test suite
+|executingHost |the host name of the MTC (determined with gethostname()) |host where the test was executed
+|sutId |"0.0.0.0" |IP address of SUT
+|sutName |"DefaultSUTName" |name of SUT
+|lsvMajor |"1" |major version number of SUT
+|lsvMinor |"0" |minor version number of SUT
+|runByUser |Login name of the user running the MTC (determined with getlogin()) |name of user running the tests
+|projectName |"DefaultProjectname" |name of the project
+|productName |"DefaultProductName" |name of the product
+|productVersion |"0.0" |version of the product
+|configType |"configType" |
+|configVersion |"configVersion" |
+|testType |"testType" |
+|logLink |"default_log_location" |absolute location of log files
+|logEnd |"default_web_log_dir" |log directory relative to web server root
+|reportEmail |automatically set to < runByUser > +“@ericsson.com&quot; |who is to be notified via email
+|reportTelnum |"0" |where to send the SMS notification
+|===
+
+The parameters starting with "tst_" should be modified only if the TestStatistics tool is moved to another location on the intranet.
+
+There are 4 parameters for setting the database connection, the database can also be selected on the web interface, all information sent by TITAN will be stored there. The default values will use a demo database which can be used for experimentation.
+
+All parameters have default values, thus the plugin can be used even without setting any parameters. However some parameters should be set to a meaningful value, such as the suiteName or the projectName. An example from a configuration file:
+[source]
+----
+LoggerPlugins := { TSTLogger := "libtstlogger" }
+*.TSTLogger.testConfigName = "Hiper Giga Test"
+*.TSTLogger.sutId = "11.22.33.44"
+*.TSTLogger.projectName = "MagicProject"
+*.TSTLogger.suiteName = "Super Test Suite"
+*.TSTLogger.lsvMajor = "3"
+*.TSTLogger.lsvMinor = "14"
+----
+To load the plugin the runtime configuration file should contain the following line: +
+`LoggerPlugins := { TSTLogger := "libtstlogger" }`
+
+[[lttngustlogger-plugin]]
+==== LTTngUSTLogger plugin
+
+The LTTng-UST logger plugin emits each logging statement as an http://lttng.org/[LTTng-UST] event. LTTng is a low-overhead tracer for Linux which generates http://diamon.org/ctf[CTF] traces.
+
+To use the LTTng-UST logger plugin:
+
+. Make sure LTTng (2.7 or greater) is installed (the LTTng-tools and LTTng-UST components are required).
+. Add the following line to your runtime configuration file:LoggerPlugins := { LTTngUSTLogger := "liblttng-ust-logger" }
+. Create an LTTng tracing session:lttng create
+. Enable TITAN events:lttng enable-event –userspace titan_core:'*'
+. Start tracing:lttng start
+. Run your test script.
+. When you are done, stop tracing:lttng stop
+. Inspect the recorded events with an LTTng trace viewer, for example http://tracecompass.org/[Trace Compass] or http://diamon.org/babeltrace[Babeltrace].
+
+When the plugin is loaded, it dynamically loads the LTTng-UST tracepoint provider, a shared object installed in the same directory. It is important that the `LD_LIBRARY_PATH` environment variable be set to this directory, otherwise the plugin issues a warning message and does not emit LTTng events.
+
+[[logfile]]
+=== `LogFile`
+
+Option `LogFile` stands for the name of the log file. A string value is expected, which is interpreted as a skeleton to determine the file name. To make the file name handling more flexible the string may contain special metacharacters, which are substituted dynamically during test execution.
+
+The table below contains the list of available metacharacters in alphabetical order. Any unsupported metacharacter sequence, that is, if the `%` character is followed by any character that is not listed in the table below or a single percent character stays at the end of the string, will remain unchanged.
+
+.Available metacharacters for setting log file names
+[cols="m,",options="header",]
+|===
+|Meta-character |Substituted with . . .
+|%c |the name of the TTCN–3 test case that the PTC belongs to.
+|%e |the name of the TTCN–3 executable. The .exe suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%h |the name of the computer returned by the gethostname(2) system call. This usually does not include the domain name.
+|%i |the sequence number of the log fragment.
+|%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
+|%n |
+- the name of the test component if the PTC has been given a name with the command create in the TTCN-3 create operation; an empty string otherwise. +
+- the string HC if the logfile is generated by a Host Controller +
+- the string MTC if the component is the Main Test Component (both in parallel and in single mode)
+| %p | the process ID (`pid`) of the UNIX process that implements the current test component. The `pid` is written in decimal notation.
+| %r | the component reference or component identifier. On PTCs it is the component reference (an integer number greater or equal to 3) in decimal notation. On the Main Test Component, Host Controller or in single mode the strings `mtc`, `hc` or `single` are substituted, respectively.
+| %s | the default suffix for the log files without the leading dot. Now it always results in string log, but future versions may support log file compression. In this case the suffix will depend on the chosen compression method.
+| %t | the TTCN–3 component type. Note: The MTC and HC have no dedicated component type since they can implement several component types in different test cases.
+| %% | a single % character.
+|===
+
+The outcome of substitution will result in the name of the log file. It may resolve either to a simple file name or to an absolute or relative path. The relative pathnames are always related to the current working directory of the executable tests in single mode or that of the Host Controller in parallel mode, respectively. If the pathname contains one or more nonexistent directories, those directories (and/or subdirectories) will be automatically created with permissions `0755` before the log file is opened.
+
+If the given string or the result of substitution is empty, no log file will be created and only console logging will be performed regardless the setting of `FileMask`. Empty log files will not be created when logging to files is completely disabled (i.e.` FileMask` is set to `LOG_NOTHING`) even if the value of `LogFile` would yield a valid file name.
+
+In parallel mode the user must ensure that the resulting log file names are unique for every component. Otherwise, if several components try to write into the same log file, the contents of the log will be unpredictable. The uniqueness is automatically provided if the host name (`%h`) and the component reference (`%r`) or the process ID (`%p`) is included in the file name.
+
+If testcase name (`%c`) or component name (`%t`) is included, the log file name may change during runtime. A new log file will be created/opened in this case. If a log file with the new name already exists, it is overwritten by default. Because of this, it is *highly recommended* to set `AppendFile` (see <<AppendFile, here>>) to `Yes` if LogFile contains `%c` or `%t`.
+
+If omitted, the default value for option `LogFile` is `%e-part%i.%s` in single mode and `%e.%h-%r-part%i.%s` in parallel mode, respectively. This ensures backward compatibility with earlier versions in parallel mode and follows the most commonly used file naming convention in single mode.
+
+[[filemask]]
+=== `FileMask`
+
+Option `FileMask` determines which events will be written to the log file and which ones will be filtered out.
+
+==== Category-based Filtering
+
+Table 14 enumerates the first level groups of events (that is, logging categories) along with a symbolic constant. The selected constants separated by a pipe (|) will determine what will be logged. When `FileMask` is omitted from the configuration file, its default value (`LOG_ALL`) is applied.
+
+Some of the first level logging categories may be divided in second level subcategories to get a finer logging granularity. These categories are listed in the tables 11 to 21. First level categories and second level subcategories may be mixed in the option.
+
+First level logging categories may be considered as notational convenience. They are maintained also for backward compatibility: legacy configuration files containing only first level categories will continue to work unmodified. However, the resulting log file may look different, as event categories have been modified; some messages, mostly `PARALLEL` and `FUNCTION`, have changed category, usually to `EXECUTOR`. When a first level logging category is included in the option `FileMask`, all second level subcategories pertaining to it will also be implicitly included, thus, it is redundant to list one ore more subcategories along with the concerned first level category.
+
+==== Component and Plugin Based Filtering
+
+It is possible to filter events based on the identity of the component generating them. For component designation it is recommended to use the component name given in the command `create` or the keyword `mtc`; latter one in the case of the Main Test Component. Using component numbers as identifiers is not recommended as this is a tool dependent identifier.
+
+The component name, if present, precedes the keyword `FileMask`. They are separated by a dot (.).
+
+It is also possible to apply the filtering on selected logger plugins of a component. The identifier of the desired logger plugin is appended after the component designation. The component and plugin identifiers are separated by a dot(.).
+
+[[consolemask]]
+=== `ConsoleMask`
+
+Option `ConsoleMask` determines which events will be written to the console and which ones will be filtered.
+
+[[category-based-filtering-0]]
+==== Category-based Filtering
+
+Table 14 enumerates the first level groups of events (that is, logging categories) along with a symbolic constant. The selected constants separated by a pipe (|) will determine what will be logged. When `ConsoleMask` is omitted from the configuration file, its default value (`ERROR|WARNING|ACTION |TESTCASE|STATISTICS`) is applied.
+
+Some of the first level logging categories may be divided in second level subcategories to get a finer logging granularity. These categories are listed in the tables 11 to 21. First level categories and second level subcategories may be mixed in the option.
+
+First level logging categories may be considered as notational convenience. They are maintained also for backward compatibility: legacy configuration files containing only first level categories will continue to work unmodified. However, the resulting log file may look different, as event categories have been modified; some messages, mostly `PARALLEL` and `FUNCTION`, have changed category, usually to `EXECUTOR`. When a first level logging category is included in the option `ConsoleMask`, all second level subcategories pertaining to it will also be implicitly included, thus, it is redundant to list one ore more subcategories along with the concerned first level category.
+
+In single mode the console log messages are written to the standard error of the ETS. For the interpretation of console logging in parallel mode, see section 12.3.3. of the TITAN User Guide (<<13-references.adoc#_13, [13]>>).
+
+WARNING: Please note that neither the timestamp nor the event type, nor location information is printed on the console.
+
+[[component-and-plugin-based-filtering-0]]
+==== Component and Plugin Based Filtering
+
+It is possible to filter events based on the identity of the component generating them. For component designation it is recommended to use the component name given in the command `create` or the keyword `mtc`; latter one in the case of the Main Test Component. Using component numbers as identifiers is not recommended as this is a tool dependent identifier.
+
+The component name, if present, precedes the keyword `ConsoleMask`. They are separated by a dot (.).
+
+It is also possible to apply the filtering on selected logger plugins of a component. The identifier of the desired logger plugin is appended after the component designation. The component and plugin identifiers are separated by a dot (.).
+
+.First level (coarse) log filtering
+[cols=",",options="header",]
+|===
+|Logging categories |Symbolic constantfootnote:[In order to be compatible with older configuration files, the following symbolic constants are also recognized: TTCN_ERROR, TTCN_WARNING, TTCN_PORTEVENT, TTCN_TIMEROP, TTCN_VERDICTOP, TTCN_DEFAULTOP, TTCN_TESTCASE, TTCN_ACTION, TTCN_USER, TTCN_FUNCTION, TTCN_STATISTICS, TTCN_PARALLEL, TTCN_EXECUTOR, TTCN_MATCHING and TTCN_DEBUG.These constants have the same meaning as their counterparts without the prefix TTCN_.]
+|TTCN–3 action(…) statements(No subcategory is implemented) |`ACTION`
+|Debug messages in Test Ports and external functions(For subcategories see Table 15) |`DEBUG`
+|Default operations (`activate`, `deactivate`, `return`)(For subcategories see Table 16) |`DEFAULTOP`
+|Dynamic test case errors (e.g. snapshot matching failures)(No subcategory is implemented) |`ERROR`
+|Internal TITAN events(For subcategories see Table 17) |`EXECUTOR`
+|Random number function calls(For subcategories see Note: `EXECUTOR_EXTCOMMAND` is always logged, regardless of the user’s settings. |`FUNCTION`
+|Bitwise OR of all the above except `MATCHING` and `DEBUG` |`LOG_ALL`
+|Nothing to be logged |`LOG_NOTHING`
+|Analysis of template matching failures in receiving port operations(For subcategories see Table 19) |`MATCHING`
+|Parallel test execution and test configuration related operations (`create`, `done`, `connect`, `map`, etc.)(For subcategories see Table 20) |`PARALLEL`
+|Port events (`send`, `receive`)(For subcategories see Table 22) |`PORTEVENT`
+|Statistics of verdicts at the end of execution(For subcategories see Table 23) |`STATISTICS`
+|The start, the end and the final verdict of test cases(For subcategories see Table 21) |`TESTCASE`
+|Timer operations (`start`, `stop`, `timeout`, `read`)(For subcategories see Table 24) |`TIMEROP`
+|User log(…) statements(No subcategory is implemented) |`USER`
+|Verdict operations (`setverdict`, `getverdict`)(For subcategories see Table 25) |`VERDICTOP`
+|Run-time warnings (e.g. stopping of an inactive timer)(No subcategory is implemented) |`WARNING`
+|===
+
+.Second level (fine) log filtering for *DEBUG*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|Debug information coming from generated functions of dual faced ports and built-in encoder/decoders.footnote:[Everyone writing encoder/decoder functions should implement logging in this subcategory.] |`DEBUG_ENCDEC`
+| |`DEBUG_TESTPORT`
+|Other, non categorized log messages of the category |`DEBUG_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *DEFAULTOP*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|TTCN-3 `activate` statement (activation of a default) |`DEFAULTOP_ACTIVATE`
+|Deactivation of a `default` |`DEFAULTOP_DEACTIVATE`
+|Leaving an invoked default at the end of a branch (causing leaving the `alt` statement in which it was invoked) or calling `repeat` in an invoked default (causing new snapshot and evaluation of the `alt` statement) |`DEFAULTOP_EXIT`
+|Other, non categorized log messages of the category |`DEFAULTOP_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *EXECUTOR*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|Starting and stopping MTC and HCs |`EXECUTOR_COMPONENT`
+|ETS runtime events (user control of execution, control connections between the processes of the ETS, ETS overloaded messages, etc.) |`EXECUTOR_RUNTIME`
+|Runtime test configuration data processing |`EXECUTOR_CONFIGDATA`
+|When this subcategory is present in the configuration file, logging options are printed in the second line of each log file. |`EXECUTOR_LOGOPTIONS`
+|Running of external command |`EXECUTOR_EXTCOMMAND`
+|Other, non categorized log messages of the category |`EXECUTOR_UNQUALIFIED`
+|===
+NOTE: `EXECUTOR_EXTCOMMAND` is always logged, regardless of the user’s settings.
+
+.Second level (fine) log filtering for *FUNCTION*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|Random number functions in TTCN-3 |`FUNCTION_RND`
+|Other, non categorized log messages of the category |`FUNCTION_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *MATCHING*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|Matching a TTCN-3 `done` operation |`MATCHING_DONE`
+|Timer in timeout operation is not started or not on the list of expired timers |`MATCHING_TIMEOUT`
+|Procedure-based mapped ports: successful template matching |`MATCHING_PMSUCCESS`
+|Procedure-based mapped ports: unsuccessful template matching |`MATCHING_PMUNSUCC`
+|Procedure-based connected ports: successful template matching |`MATCHING_PCSUCCESS`
+|Procedure-based connected ports: unsuccessful template matching |`MATCHING_PCUNSUCC`
+|Message-based mapped ports: successful template matching |`MATCHING_MMSUCCESS`
+|Message-based mapped ports: unsuccessful template matching |`MATCHING_MMUNSUCC`
+|Message-based connected ports: successful template matching |`MATCHING_MCSUCCESS`
+|Message-based connected ports: unsuccessful template matching |`MATCHING_MCUNSUCC`
+|Unsuccessful matching |`MATCHING_PROBLEM`
+|Other, non categorized log messages of the category |`MATCHING_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *PARALLEL*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|PTC creation and finishing, starting and finishing a function started on a PTC |`PARALLEL_PTC`
+|Port `connect` and `disconnect` operations |`PARALLEL_PORTCONN`
+|Port `map` and `unmap` operations |`PARALLEL_PORTMAP`
+|Other, non categorized log messages of the category |`PARALLEL_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *TESTCASE*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|A testcase is starting |`TESTCASE_START`
+|A testcase ends; final verdict of the testcase |`TESTCASE_FINISH`
+|Other, non categorized log messages of the category |`TESTCASE_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *PORTEVENT*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|Procedure-based ports: call, reply or exception enqueued in the queue of the port or extracted from the queue |`PORTEVENT_PQUEUE`
+|Message-based ports: message enqueued in the queue of the port or extracted from the queue |`PORTEVENT_MQUEUE`
+|Port state changesfootnote:[In mixed ports message and proc. ports cannot be distinguished] (`halt`, `start`, `stop`, port `clear` operation finished) |`PORTEVENT_STATE`
+|Procedure-based mapped ports: incoming data received (`getcall`, `getreply`, `catch`, `check`) |`PORTEVENT_PMIN`
+|Procedure-based mapped ports: outgoing data sent (`call`, `reply`, `raise`) |`PORTEVENT_PMOUT`
+|Procedure-based connected ports: incoming data received (`getcall`, `getreply`, `catch`, `check`) |`PORTEVENT_PCIN`
+|Procedure-based connected ports: outgoing data sent (`call`, `reply`, `raise`) |`PORTEVENT_PCOUT`
+|Message-based mapped ports: incoming data received (`receive`, `trigger`, `check`) |`PORTEVENT_MMRECV`
+|Message-based mapped ports: outgoing data sent (`send`) |`PORTEVENT_MMSEND`
+|Message-based connected ports: incoming data received (`receive`, `trigger`, `check`) |`PORTEVENT_MCRECV`
+|Message-based connected ports: outgoing data sent (`send`) |`PORTEVENT_MCSEND`
+|Mappings of incoming message from the external interface of dual-faced ports to the internal interface (decoding) |`PORTEVENT_DUALRECV`
+|Mappings of outgoing message from the internal interface of dual-faced ports to the external interface (encoding) |`PORTEVENT_DUALSEND`
+|Other, non categorized log messages of the category |`PORTEVENT_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *STATISTICS*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|Verdict statistics of executed test cases (% of `none`, `pass`, `inconc`, `fail`, `error`) |`STATISTICS_VERDICT`
+|Other, non categorized log messages of the category |`STATISTICS_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *TIMEROP*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|TTCN-3 `read timer` operation |`TIMEROP_READ`
+|TTCN-3 `start timer` operation |`TIMEROP_START`
+|Log events related to the guard timer used in TTCN-3 `execute` statements |`TIMEROP_GUARD`
+|TTCN-3 `stop timer` operation |`TIMEROP_STOP`
+|Successful TTCN-3 `timeout` operation (timer found on the list of expired timers) |`TIMEROP_TIMEOUT`
+|Other, non categorized log messages of the category |`TIMEROP_UNQUALIFIED`
+|===
+
+.Second level (fine) log filtering for *VERDICTOP*
+[cols=",",options="header",]
+|===
+|Logging subcategories |Symbolic constant
+|TTCN-3 `getverdict` operation |`VERDICTOP_GETVERDICT`
+|TTCN-3 `setverdict` operation |`VERDICTOP_SETVERDICT`
+|Final verdict of a test component (MTC or PTC) |`VERDICTOP_FINAL`
+|Other, non categorized log messages of the category |`VERDICTOP_UNQUALIFIED`
+|===
+
+[[AppendFile]]
+=== `AppendFile`
+
+Option `AppendFile` controls whether the run-time environment shall keep the contents of existing log files when starting execution. The possible values are `Yes` or `No`. The default is `No`, which means that all events from the previous test execution will be overwritten.
+
+This option can be used in both single and parallel modes. Its usefulness in single mode is obvious. If the executable test suite is started several times, the logs of the successive test sessions will be stored in the same single file after each other.
+
+In parallel mode the naming of log files is automatic and is based on the host name and component references. The option is applicable to all log files: all of them will be either appended or overwritten. If the test execution is repeated several times with different configuration or test case selection, the same file may contain the log of totally different test components. When appending is enabled the log files can be interpreted after using the logmerge utility (see Section 13.1. of the TITAN User Guide, <<13-references.adoc#_13, [13]>>). The option `AppendFile` guarantees only that no logged events will be lost during the entire test campaign.
+
+[[TimeStampFormat]]
+=== `TimeStampFormat`
+
+Option `TimeStampFormat` configures the formatting of timestamps in the log file. It can have three possible values: `Time` stands for the format `hh:mm:ss.microsec`. `DateTime` results in `yyyy/Mon/dd hh:mm:ss.microsec`. This is useful for long test durations (for instance, when a stability test runs for a couple of days). Using the third alternative (`Seconds`) results relative timestamps in format `s.microsec`. The time is related to the starting of the test component or test execution (i.e. this is the zero time). The default value for `TimeStampFormat` is `Time`.
+
+=== `ConsoleTimeStampFormat`
+
+Option `ConsoleTimeStampFormat` configures the formatting of timestamps in console log. It can have the same three values as `TimeStampFormat` can have: `Time`, `DateTime` and `Seconds` (see <<TimeStampFormat, here>>). If it is omitted (default) timestamp will not be inserted in the console log.
+
+=== `LogEventTypes`
+
+Option `LogEventTypes` indicates whether to include the symbolic event type (without the TTCN prefix) in each logged event immediately after the timestamp. This option can be useful for log post-filtering scripts. The possible values for `LogEventTypes` are `Yes`, `No`, `Detailed` and `Subcategories`.
+
+The default is `No`: no events will be logged.
+
+The setting `Yes` results a logfile containing event categories listed in Table 14.
+
+The setting `Subcategories` (and the equivalent `Detailed`) produces a logfile containing both event categories and subcategories. Subcategories are listed in the tables 11 to 21.
+
+In both single and parallel modes some log events are created before processing the configuration data. At this time the logging options (name of the log file, filter settings, timestamp format, etc.) are not known by the run-time environment, thus, these events are collected in a temporary memory buffer and are flushed to the log file when the processing of configuration file is finished. This implies that if the Host Controller is stopped in parallel mode before configuring it, no log file will be created at all.
+
+=== `SourceInfoFormat`
+
+Option `SourceInfoFormat` controls the appearance of the location information for the test events. The location information refers to a position in theTTCN–3 source code. It consists of the name of the TTCN–3 file and the line number separated by a colon character (:). Optionally, it may contain the name of the TTCN–3 entity (function, testcase, etc.) in parentheses that the source line belongs to. See also the option <<LogEntityName, `LogEntityName`>> below.
+
+The option can take one of the three possible values: `None`, `Single` and `Stack`. In case of `Single`, the location information of the TTCN–3 statement is logged that is currently being executed. When `Stack` is used the entire TTCN–3 call stack is logged. The logged information starts from the outermost control part or testcase and ends with the innermost TTCN–3 statement. An arrow (that is, the character sequence ->) is used as separator between the stack frames. The value `None` disables the printing of location information.The default value for `SourceInfoFormat` is `None`.
+
+The location information is placed in each line of the log file between the event type or timestamp and the textual description of the event.
+
+This option works only if the command line option `–L` is passed to the compiler (see <<6-compiling_ttcn3_and_asn1_modules.adoc#command-line-syntax, here>>). This feature is useful for debugging new TTCN–3 code or for understanding the traces of complex control constructs. If the location information is not generated into the C++ code the executable tests run faster, which can be more important when doing performance tests.
+
+NOTE: The reception of messages or procedure calls can only occur while the run-time environment is taking a new snapshot. A new snapshot is taken when the testcomponent is evaluating a stand-alone receiving operation, an `alt` construct or a standalone `altstep` invocation. Thus, the location information of the incoming messages or calls points to the first line of the above statements. The log event belonging to a TTCN–3 operation can be the extraction of a message from the port queue and not the reception of an incoming message.
+
+If the event has no associated line in the TTCN–3 source code (e.g. because it belongs to test environment startup or termination) and `SourceInfoFormat` is set to either `Single` or `Stack`, a single dash character `(-)` is printed into the log instead of the location information. This makes the automated processing of log files easier.
+
+The obsolete option `LogSourceInfo` is also accepted for backward compatibility with earlier versions. Setting `LogSourceInfo` `:= Yes` is equivalent to `SourceInfoFormat` `:= Single`, and similarly `LogSourceInfo := No` means `SourceInfoFormat := None`.
+
+[[LogEntityName]]
+=== `LogEntityName`
+
+Option `LogEntityName` controls whether the name of the corresponding TTCN–3 entity (`function`, `testcase`, `altstep, control` part, etc.) shall be included in the location information. If this option is set to `Yes`, the file name and line number is followed by the name of the TTCN–3 entity within parentheses. The default value is `No`. The option has no effect if `SourceInfoFormat` is set to `None`.
+
+=== `LogFileSize`
+
+Option `LogFileSize` sets the upper limit for the log file size. The limitation prevents load tests or long duration tests from triggering dynamic test case error when the growing log file exceeds file system size limits or available disk space.
+
+When the size limit is reached, the file is closed and a new log file will be created with an increased part number. For example, the first two log files when running `ExampleTestCase` in single mode will be `ExampleTestCase-part1.log` and `ExampleTestCase-part2.log`, respectively provided that the file name skeleton default values have not been modified.
+
+This option must be set together with <<LogFileNumber,`LogFileNumber`>>.
+
+The parameter value, a non-negative integer, is understood in kilobytes. The default value is 0, meaning that the file size is unlimited; or, to be precise, is only limited by the file system.
+
+==== Component and Plugin Dependent File Size
+
+It is possible to set different file sizes based on the identity of the component generating the log. For component designation it is recommended to use the component name given in the parameter of the command `create` (or the keyword `mtc` for the Main Test Component). Using component numbers as identifiers is not recommended as this is a tool dependent identifier.
+
+The component name, if present, precedes the keyword `LogFileSize`. The name and the keyword are separated by a dot (.).
+
+It is also possible to limit the file size on selected logger plugins of a component. The identifier of the desired logger plugin is appended after the component designation. The component and plugin identifiers are separated by a dot (.).
+
+[[LogFileNumber]]
+=== `LogFileNumber`
+
+Option `LogFileNumber`, a positive integer, sets the the maximum number of log files (fragments) kept. If the log file number limit is reached, the oldest log file of the component will be deleted and logging continues in the next log fragment file.
+
+The default value is 1, meaning that the number of log files equals one.
+
+==== Component and Plugin Dependent Fragment Number
+
+It is possible to set different fragment limits based on the identity of the component generating the log. For component designation it is recommended to use the component name given in the parameter of the command `create` (or the keyword `mtc` for the Main Test Component). Using component numbers as identifiers is not recommended as this is a tool dependent identifier.
+
+The component name, if present, precedes the keyword `LogFileNumber`. The name and the keyword are separated by a dot (.).
+
+It is also possible to limit the number of log fragments on selected logger plugins of a component. The identifier of the desired logger plugin is appended after the component designation. The component and plugin identifiers are separated by a dot (.).
+
+=== `DiskFullAction`
+
+Option `DiskFullAction` determines TITAN behavior when writing to the log file fails.
+
+If this option set to `Stop` test case execution continues without logging when an error occurs.
+
+The setting `Retry` causes test case execution to continue without logging and TITAN attempts to restart logging activity periodically (events in the unlogged periods are lost). The retry period is set by default to 30 seconds and can be changed by a parameter. Example: `Retry`(`60`) doubles the period.
+
+If the parameter is set to `Delete`, TITAN deletes the oldest log file and continues logging to a new log file fragment. If log writing fails again, the procedure is repeated until one two log files (the actual one and the previous one) are left. Further log writing failure causes a dynamic test case error.
+
+The default behavior is `Error`. With this setting, writing error causes a runtime (dynamic) test case error.
+
+==== Component and Plugin Dependent Behavior
+
+It is possible to set different error behavior based on the identity of the component generating the log. For component designation it is recommended to use the component name given in the parameter of the command `create` (or the keyword `mtc` for the Main Test Component). Using component numbers as identifiers is not recommended as this is a tool dependent identifier.
+
+The component name, if present, precedes the keyword `DiskFullAction`. The name and the keyword are separated by a dot (.).
+
+It is also possible configure different error behavior on selected logger plugins of a component. The identifier of the desired logger plugin is appended after the component designation. The component and plugin identifiers are separated by a dot (.).
+
+=== `MatchingHints`
+
+Option `MatchingHints` controls the amount and format of log messages describing template matching failures. These are written during port receive operations as logging category `MATCHING`, and as a response to TTCN-3 `log(match(…))` statements as logging category `USER`.
+
+There are two possible values: `Compact` and `Detailed`.
+
+When the `Detailed` option is in effect, a field-by-field description of the value and template is logged, followed by additional hints when matching set-of types. Example:
+
+[source]
+----
+{
+    {
+        field_rr1 := 1,
+        field_rr2 := 2
+    },
+    {
+        field_rr1 := 3,
+        field_rr2 := 4
+    }
+} with {
+    {
+        field_rr1 := 1,
+        field_rr2 := 2
+    },
+    {
+        field_rr1 := 3,
+        field_rr2 := 5
+    }
+} unmatched Some hints to find the reason of mismatch: {
+    value elements that have no pairs in the template: {
+        field_rr1 := 3,
+        field_rr2 := 4
+    } at index 1,
+    template elements that have no pairs in the value: {
+        field_rr1 := 3,
+        field_rr2 := 5
+    } at index 1,
+    matching value <-> template index pairs: {
+        0 <-> 0
+    },
+    matching unmatched value <-> template index pairs: {
+        1 <-> 1: {
+            {
+                field_rr1 := 3 with 3 matched,
+                field_rr2 := 4 with 5 unmatched
+            }
+        }
+    }
+}
+----
+
+The printout is similar to the TTCN-3 assignment notation for the entire structure.
+
+When the `Compact` option is in effect, fields and structures that match are omitted in order to pinpoint the reason why the entire match operation failed. Every mismatch is represented as a path from the outermost (containing) type to the innermost simple type that failed to match. This is similar to a mixture of dot notation referencing fields of record/set types and indexed notation referencing elements of record-of/set-of types, as it would be used to reference the innermost member of a structured type:
+
+* Mismatched fields of a record/set are represented by the field name preceded by a dot (a.k.a. full stop).
+* Mismatched elements of a record-of are represented by the index in square brackets.
+* Mismatched elements of a set-of are represented by the indexes of the mismatching elements in the vale and the template, separated by a two-headed arrow.
+
+Example: The following line is the equivalent of the nested display above when the `Compact` option is in effect instead of `Detailed`.
+
+`[1 <-> 1].field_rr2 := 4 with 5 unmatched`
+
+This means that the second element (indexing is 0-based) of the value didn’t match the second element of the template because field_rr2 in the value was 4 whereas field_rr2 in the template was 5.
+
+The default value of `MatchingHints` is `Compact`.
+
+[[EmergencyLogging]]
+=== `EmergencyLogging`
+
+Titan implements an emergency logging feature. The purpose of this feature is to help diagnose errors by logging events that would normally be suppressed, for example if only a few event types are logged (e.g. to minimize I/O overhead or log file size) and all the other log events are discarded. If something unexpected occurs (e.g. Dynamic Testcase Error), it can be difficult to diagnose the problem, but there is no way to recover the discarded events.
+
+With emergency logging, log events which are not written to the log file can be stored in a ring buffer. In case of an error, the stored events can be recovered from the buffer and written to the log. Because the buffered events are closest in time to the error, they are most likely to be helpful in diagnosing the cause.
+
+The value of the `EmergencyLogging` option is the ring buffer size (the number of log events that are kept). The default value is zero, which turns off the emergency logging feature.
+
+=== `EmergencyLoggingBehaviour`
+
+Buffering of events can be performed in two ways:
+
+* Buffering only selected messages. This option is selected with the `BufferMasked` value of the `EmergencyLoggingBehaviour` option. This is the default behaviour. Log events are sent to the plugins to be filtered and logged. Additionally log events not included by the `FileMask` and included by the `EmergencyLoggingMask` are buffered. This method cannot guarantee that timestamps of the log events passed to the plugins are always monotonically increasing. Monotonically increasing timestamps are a requirement for ttcn3_logmerge. The LegacyLogger plugin ensures that the requirements of ttcn3_logmerge are satisfied by writing the emergency log messages to a separate log file.
+* Buffer all messages. This option is selected with the `BufferAll` value of the `EmergencyLoggingBehaviour` option. The value of the `EmergencyLoggingMask` is ignored. All events are initially placed in the buffer. If the buffer is full, the oldest buffered event is extracted and sent to the logger plugins to be filtered and logged. If an error occurs, all stored events are extracted and logged without filtering. This method guarantees that all log events passed to the plugins have their timestamps in a monotonically increasing order. In this case there is no separate emergency log file.
+
+=== `EmergencyLoggingMask`
+
+Option `EmergencyLoggingMask` determines which events will be saved in the emergency logging buffer when the value of `EmergencyLoggingBehaviour` is `BufferMasked`.
+
+=== `EmergencyLoggingForFailVerdict`
+
+Option `EmergencyLoggingForFailVerdict` controls whether `setverdict(fail)` operations trigger emergency logging or not. The possible values are `Yes` or `No`. The default is `No`, which means that emergency logging would not be triggered when the component’s verdict is set to `fail`. Emergency logging is always triggered when a dynamic test case error is reached, regardless of this option.
+
+=== BNF productions for this section
+[source]
+----
+LoggingSection ::= "[LOGGING]" {LoggingAssignment}
+LoggingAssignment ::= [ComponentId "." [PluginId "."]] LoggingParam
+	| [ComponentId "."] "LoggerPlugins" AssignmentChar "{" LoggerPluginList "}"
+LoggingParam ::= (LogFile | FileMask | ConsoleMask | AppendFile
+	| TimeStampFormat | ConsoleTimeStampFormat | LogEventTypes
+	| SourceInfoFormat | LogEntityName
+	| LogFileSize | LogFileNumber | DiskFullAction | MatchingHints
+	| PluginSpecificParameter
+	| EmergencyLogging | EmergencyLoggingBehaviour | EmergencyLoggingMask
+	| EmergencyLoggingForFailVerdict) [SemiColon]
+LoggerPluginList ::= LoggerPluginSetting ["," LoggerPluginSetting ]
+LoggerPluginSetting ::= Identifier AssignmentChar PluginLocation | Identifier
+PluginId ::= Identifier | "*"
+PluginSpecificParameter ::= Identifier AssignmentChar StringValue
+PluginLocation ::= StringValue
+LogFile ::= ("LogFile" | "FileName") AssignmentChar StringValue
+FileMask ::= "FileMask" AssignmentChar LoggingBitmask
+ConsoleMask ::= "ConsoleMask" AssignmentChar LoggingBitmask
+MatchingHints := "Compact" | "Detailed"
+ComponentId ::= Identifier | Number | MTCKeyword | "*"
+LoggingBitmask ::= LoggingBit {"|" LoggingBit}
+LoggingBit ::= ... /* defined in Table 12 to Table 23 */
+AppendFile ::= "AppendFile" AssignmentChar ("Yes" | "No")
+TimeStampFormat ::= "TimeStampFormat" AssignmentChar ("Time" | "DateTime"
+	| "Seconds")
+ConsoleTimeStampFormat ::= "ConsoleTimeStampFormat" AssignmentChar ("Time" | "DateTime"
+	| "Seconds")
+LogEventTypes ::= "LogEventTypes" AssignmentChar ("Yes" | "No" | "Detailed"
+| "Subcategories")
+SourceInfoFormat ::= ("SourceInfoFormat" | "LogSourceInfo") AssignmentChar ("None"
+| "Single" | "Stack")
+LogEntityName ::= "LogEntityName" AssignmentChar ("Yes" | "No")
+LogFileSize ::= "LogFileSize" AssignmentChar Number
+LogFileNumber ::= "LogFileNumber" AssignmentChar Number
+DiskFullAction ::= "DiskFullAction" AssignmentChar DiskFullActionValue
+DiskFullActionValue ::= ( "Error" | "Stop" | "Retry" ["(" Number ")"] | "Delete" )
+EmergencyLogging ::= "EmergencyLogging" AssignmentChar Number
+EmergencyLoggingBehaviour ::= "EmergencyLoggingBehaviour" AssignmentChar
+	( "BufferAll" | "BufferMasked" )
+EmergencyLoggingMask ::= "EmergencyLoggingMask" AssignmentChar LoggingBitMask
+EmergencyLoggingForFailVerdict ::= “EmergencyLoggingForFailVerdict” AssignmentChar (“Yes” | “No”)
+----
+
+=== *_Example 1_*
+[source]
+----
+[LOGGING]
+LogFile := "/usr/local/TTCN3/logs/%l/%e.%h-%t%r-part%i.%s"
+“Alma-Ata”.FileMask := LOG_ALL
+MyComponent.FileMask := MATCHING
+mtc.FileMask := LOG_ALL | MATCHING
+ConsoleMask := ERROR | WARNING | TESTCASE | TIMEROP_START
+AppendFile := No
+TimeStampFormat := DateTime
+ConsoleTimeStampFormat := Time
+LogEventTypes := No
+SourceInfoFormat := Single
+LogEntityName := Yes
+MatchingHints := Detailed
+EmergencyLogging := 2000
+EmergencyLoggingBehaviour := BufferAll
+#EmergencyLoggingMask := LOG_ALL
+----
+=== *_Example 2_*
+[source]
+----
+[LOGGING]
+LogFile := "logs/%e-%r.%s"
+ConsoleMask := LOG_ALL
+FileMask := TESTCASE | ERROR | EXECUTOR | VERDICTOP
+TimeStampFormat := Time
+LogEventTypes := Yes
+SourceInfoFormat := Stack
+LogEventTypes := Yes
+*.EmergencyLogging:=15
+*.EmergencyLoggingBehaviour := BufferMasked
+*.EmergencyLoggingMask := LOG_ALL | DEBUG
+----
+
+[[testport-parameters]]
+== `[TESTPORT_PARAMETERS]`
+
+In this section you can specify parameters that are passed to Test Ports. Each parameter definition consists of a component name, a port name, a parameter name and a parameter value. The component name can be either an identifier that is assigned to the component in the `create` operation (see <<4-ttcn3_language_extensions.adoc#visibility-modifiers, here>>) or an integer value, which is interpreted as component reference[31]. The port and parameter names are identifiers while the parameter value must be always a `charstring` (with quotation marks). Instead of component name or port name (or both of them) the asterisk (*) sign can be used, which means ”all components” or ”all ports of the component”.
+
+If the keyword `system` is used as a component identifier, the parameter is passed to all ports of all components that are mapped to the given port of the test system interface. In this case the port identifier refers to the port of the test system and not the port of a TTCN–3 test component. These parameters are passed to the appropriate Test Port during the execution of map operations because the future mappings are not known at test component initialization. The asterisk (”*”) sign can also be used as port name with the component identifier system. This wildcard means, of course, all ports of the Test System Interface (that is, the parameter will be passed during all `map` operations).
+
+The names and meaning of Test Port parameters depend on the Test Port that you are using; for this information please consult the user documentation of your Test Port. It is the Test Port writer’s responsibility to process the parameter names and values. For the details of Test Port API see the section "Parameter setting function" in <<13-references.adoc#_16, [16]>>.
+
+[[bnf-productions-for-this-section-0]]
+=== BNF Productions for this Section
+[source]
+----
+TestPortParametersSection ::= "[TESTPORT_PARAMETERS]" {TestPortParameter}
+TestPortParameter ::= ComponentId "." PortName "." PortParameterName AssignmentChar 	PortParameterValue [SemiColon]
+ComponentId ::= Identifier | Number | MTCKeyword | SystemKeyword | "*"
+MTCKeyword ::= "mtc"
+SystemKeyword ::= "system"
+PortName ::= Identifier {ArrayRef} | "*"
+ArrayRef ::= "[" IntegerValue "]"
+PortParameterName ::= Identifier
+PortParameterValue ::= StringValue
+----
+=== *_Example_*
+[source]
+----
+[TESTPORT_PARAMETERS]
+mtc.*.LocalIPAddress := "164.48.161.146"
+“Alma-Ata”. RemoteIPAddress := "164.48.161.147"
+mtc.RADIUS[0].LocalUDPPort := "12345"
+mtc.RADIUS[1].LocalUDPPort := "12346"
+system.MySystemInterface1.RemoteIPAddress := "10.1.1.1"
+system.MySystemInterface2.RemoteIPAddress := "10.1.1.2"
+----
+== `[DEFINE]`
+
+In this section you can create macro definitions that can be used in other configuration file sections except `[INCLUDE]`. This way if the same value must be given several times in the configuration file, you can make a definition for it and only refer to the definition later on. In case of a change, you wouldn’t need to change the values all over the configuration file, but only in the definition.
+
+This section may contain zero, one or more macro definitions (assignments). Each macro definition consists of a macro identifier, which shall be a TTCN–3 identifier, an assignment operator and the macro value. The macro value is either a simple or a structured value (see the BNF below).
+
+The simple macro value is a sequence of one or more literal values and macro references. The elements of the sequence must not be separated by anything, whitespaces or comments are not allowed.
+
+The structured macro value can be used to define instances of complex TTCN-3 data structures. The defined values can be assigned to compound module parameters. There are two restrictions regarding the syntax of this value. The first and last character of the value are '{' and '}'. The value must be well-formed regarding the curly brackets. Every value which satisfies these two rules is accepted as a macro definition.
+NOTE: macro definitions do not have a type. The defined values are copied to the place of the macro references. The semantic correctness is determined by the context of the macro reference (see the examples section).
+
+Macro references can refer to previously defined macros. The reference can be provided in the following 3 formats which have the same meaning:
+
+* `$macroname`
+* `${macroname}`
+* `${macroname,charstring}`
+
+The above 3 different notations can also be used in other sections to refer to the macro with name "macroname".
+
+The literal value can be either a word (a sequence of arbitrary characters except whitespace) or a character string value delimited by quotation marks. The latter form is useful when the macro value is an empty string or contains whitespace characters. Literal values cannot follow each other, only macro references can.
+
+The values of macros as well as environmental variables set in the shell can be expanded in the configuration file using a special syntax described below. If both a macro and an environment variable are defined with the same name the macro of the configuration file has the precedence. If neither exists an error message is reported. It is possible to assign value to the same macro identifier more than once, in this case the last assignment will determine the value of the macro. When assigning a new value to the same macro, it is also possible to use the macro’s previous value.
+
+In parallel mode, in order to ensure the consistency of the test system, all macro substitutions are performed in the Main Controller. Hence the settings of environment variables are inherited from the shell that the Main Controller was started from.
+
+Macro definitions of this section do not change the environment space maintained by the operating system in any process. Thus, the macros defined in this section are not visible by the system call `getenv(3)` issued in test ports or external functions.
+
+Macro references can have one of these two formats:
+
+* Simple reference: a dollar character followed immediately by the macro identifier. Example: `$macroName`. In this case the value of the definition will be inserted as a literal charstring value.
+* Modified reference: a dollar character followed by a pair of curly brackets containing the macro identifier and a modifier separated by a comma. Example: `${macroName, modifier}`. Whitespaces are allowed within the pair of brackets, but the opening bracket must follow the dollar character immediately. In this case the type of the substituted token is specified by the modifier. Before substitution it is verified whether the value of the referred macro or environment variable fulfills the requirements for the given modifier.
+
+The following modifiers are available for macro substitution:
+
+* `integer`
++
+Transforms the value of the macro into an integer value. The macro value may contain decimal numbers only (leading and trailing whitespaces are not allowed).
+* `float`
++
+Transforms the value of the macro into a value of type float. The substitution is possible only if the value is an integer or a floating point number.
+* `boolean`
++
+Transforms the value of the macro into a boolean value. The macro value shall contain the word true or false.
+* `bitstring`
++
+Transforms the value of the macro into a literal bitstring value. Only binary digits are allowed in the macro value.
+* `hexstring`
++
+Transform the value of the macro into a hexstring value. Only hexadecimal digits are allowed in the macro value.
+* `octetstring`
++
+Transforms the value of the macro into an octetstring. The macro value shall contain even (including zero) number of hexadecimal digits.
+* `charstring`
++
+Transforms the value of the macro into a literal value of type charstring. There is no restriction about the contents of the macro value.
++
+[NOTE]
+====
+The reference with this modifier has the same result as a simple reference.
+
+* `binaryoctet` +
+Transforms the value of the macro into an octetstring value so that the octets of the resulting string will contain the ASCII character code of the corresponding character from the macro value. The macro value to be substituted may contain any kind of character.
+* `identifier` +
+Transforms the value of the macro into a TTCN–3 identifier. This modifier is useful, for instance, for specifying values of enumerated types in section [`MODULE_PARAMETERS`]. The macro value shall contain a valid TTCN–3 identifier. Leading and trailing whitespace characters are not allowed in the macro value.
+* `hostname` +
+Transforms the value of the macro into a host name, DNS name or IPv4 or IPv6 address. The modifier can be used in sections [`GROUPS`], [`COMPONENTS`] and [`MAIN_CONTROLLER`]. The value to be substituted shall contain a valid host name, DNS name or IP address formed from alphanumerical, dash (-), underscore (_), dot (.), colon(:) or percentage (%) characters. Leading and trailing whitespace is not allowed.
+====
+
+[[bnf-productions-for-this-section-1]]
+=== BNF Productions for this Section
+[source]
+----
+DefineSection ::= "[DEFINE]" {DefinitionAssignment}
+DefinitionAssignment ::= Identifier AssignmentChar DefinitionRValue
+DefinitionRValue ::= SimpleValue | StructuredValue
+SimpleValue ::= {Word | String | IPaddress | MacroReference}
+StructuredValue ::= "{" { {SimpleValue} | StructuredValue } "}"
+		| "{" "}"
+----
+`Word` may contain numbers, letters and other non-whitespace characters mixed in any way.
+
+[[example-0]]
+=== *_Example_*
+[source]
+----
+[DEFINE]
+Localhost := 127.0.0.1
+binary_240 := 11110000
+four := 4.0
+LongString := "This is a very long string."
+x1 = “Connecting to “${Localhost}
+x2 = $LongString${Localhost,charstring}” is an IP address”
+binary_str := ${binary_240}010101
+
+/* Examples for the structured macro definitions */
+// on the left side of the arrow is the definition
+// the substituted value is on the right side
+DEF_20 := 1	// 1
+DEF_21 := "1"	// 1
+DEF_22 := "\"1\""	// "1"
+DEF_23 := a	// a
+DEF_24 := "a"	// a
+DEF_25 := "\"a\""	// "a"
+
+DEF_30 := { f1 := ${DEF20}}	// => DEF_30 := { f1 := 1}
+DEF_31 := { f1 := ${DEF21}}	// => DEF_31 := { f1 := 1}
+DEF_32 := { f1 := ${DEF22}}	// => DEF_32 := { f1 := "1"}
+DEF_33 := { f1 := ${DEF23}}	// => DEF_33 := { f1 := a}
+DEF_34 := { f1 := ${DEF24}} 	// => DEF_34 := { f1 := a}
+DEF_35 := { f1 := \"${DEF24}\"} 	// => DEF_35 := { f1 := "a"}
+DEF_36 := { f1 := ${DEF25}} 	// => DEF_36 := { f1 := "a"}
+DEF_37 := { f1 := a} 		// => DEF_37 := { f1 := a}
+DEF_38 := { f1 := "a"} 		// => DEF_38 := { f1 := "a"}
+DEF_39 := { f1 := "${DEF_20}"} 	// => DEF_39 := { f1 := "${DEF_20}"}
+// DEF_30 and DEF_31 are valid module parameter definitions for tsp_1
+// the other definitions are not valid for tsp_1
+
+
+DEF_40 := { f2 := ${DEF20}} 	// => DEF_40 := { f2 := 1}
+DEF_41 := { f2 := ${DEF21}}	// => DEF_41 := { f2 := 1}
+DEF_42 := { f2 := ${DEF22}} 	// => DEF_42 := { f2 := "1"}
+DEF_43 := { f2 := ${DEF23}} 	// => DEF_43 := { f2 := a}
+DEF_44 := { f2 := ${DEF24}}	// => DEF_44 := { f2 := a}
+DEF_45 := { f2 := \"${DEF24}\"} 	// => DEF_45 := { f2 := "a"}
+DEF_46 := { f2 := ${DEF25}} 	// => DEF_46 := { f2 := "a"}
+DEF_47 := { f2 := a} 		// => DEF_47 := { f2 := a}
+DEF_48 := { f2 := "a"} 		// => DEF_48 := { f2 := "a"}
+DEF_49 := { f2 := "${DEF_20}"} 	// => DEF_49 := { f2 := "${DEF_20}"}
+// DEF_{42|45|46|48|49} are valid module parameter definitions for tsp_1
+// the other definitions are not valid for tsp_1
+
+// complex data structures can also be referenced
+DEF_50 := { f1 := ${DEF_42}, f2 := “a”}
+----
+
+=== *_Use example:_*
+[source]
+----
+[MODULE_PARAMETERS]
+par1 := $Localhost // "127.0.0.1"
+par2 := ${binary_240, bitstring} // ’11110000’B
+par3 := ${binary_240, hexstring} // ’11110000’H
+par4 := ${four, float} // 4.0
+par5 := ${four, binaryoctet} // ’342E30’O
+par6 := ${LongString, identifier} // ERROR: invalid substitution
+par7 := "$myVariable" // substitution is not done
+[MAIN_CONTROLLER]
+LocalAddress = ${Localhost, hostname} // 127.0.0.1
+----
+
+The tokens substituted are given in comments.
+
+=== *_TTCN file example_*
+[source]
+----
+// ttcn
+module a {
+  modulepar Rec tsp_1;
+  modulepar Rec2 tsp_1;
+  type record Rec {
+    integer f1 optional, charstring f2 optional
+  }
+  type record Rec2 {
+    Rec f1 optional, charstring f2 optional
+  }
+}
+----
+
+== `[INCLUDE]`
+
+It is possible to use configuration settings (module parameters, test port parameters, etc.) given in other configuration files, the configuration files just need to be listed in this section, with their full or relative pathnames. To the host controllers it will look like as if the configuration files would have been merged together into one configuration file.
+
+Each included file shall form a valid configuration file with complete section(s). The `[INCLUDE]` directives of included files are processed recursively. Each referenced configuration file is processed exactly once even if it is included from several places. Relative pathnames are resolved based on the directory of the referring configuration file.
+
+[[bnf-productions-for-this-section-2]]
+=== BNF Productions for this Section
+[source]
+----
+IncludeSection ::= "[INCLUDE]" {IncludeFile}
+IncludeFile ::= Cstring
+----
+
+The file’s name is a character string, given between quotation marks.
+
+[[example-3]]
+*_Example_*
+[source]
+----
+[INCLUDE]
+"base_definitions.cfg"
+"../additional_parameters.cfg"
+----
+
+[[ordered-include]]
+== [`ORDERED_INCLUDE]`
+
+It is possible to include configuration files to a specific location using the `[ORDERED_INCLUDE]` section. The included file can be given with the same syntax as in the `[INCLUDE]` section. The file can be specified with an absolute path, or a path relative to the configuration file in which the `[ORDERED_INCLUDE]` section takes place. Relative pathnames are resolved based on the directory of the referring configuration file.
+
+Each included file shall form a valid configuration file with complete section(s). Circular imports are not accepted.
+
+[[bnf-productions-for-this-section-3]]
+=== BNF Productions for this Section
+[source]
+----
+OrderdIncludeSection ::= "[ORDERED_INCLUDE]" {IncludeFile}
+IncludeFile ::= Cstring
+----
+The file’s name is a character string, given between quotation marks.
+
+[[example-4]]
+*_Example_*
+[source]
+----
+// main.cfg
+[ORDERED_INCLUDE]
+"oi.cfg"
+"oi2.cfg"
+[MODULE_PARAMETERS]
+tsp_1 := 3
+
+// oi.cfg
+[MODULE_PARAMTERS]
+tsp_1 := 1
+// oi2.cfg
+[MODULE_PARAMETERS]
+tsp_1 := 2
+----
+In this example we have 3 configuration files. The names of the files are included as comments. The ETS will be started with the first one ("main.cfg"). This configuration file includes "oi.cfg" and "oi2.cfg". The included files are processed sequentially. The first included file ("oi.cfg") will set the module parameter "tsp_1" to 1. As the processing continues, the second included file ("oi2.cfg") will set it to 2. Finally when the included files are processed, the main configuration file sets it to 3. In this case, the module parameter named tsp_1 will have the final value of 3.
+
+[[external-commands]]
+== `[EXTERNAL_COMMANDS]`
+
+This section defines external commands (shell scripts) to be executed by the ETS whenever a control part or test case is started or terminated. Using this feature you can control external monitor programs (like `tcpdump` in case of IP testing) automatically during test execution. In case of parallel mode, the external command is executed on the host where the MTC runs. The name of the corresponding module or test case is passed to the external command as argument. For `BeginTestCase` and `EndTestCase` the name of the module and test case separated with a dot is passed as argument; and additionally the test case verdict for `EndTestCase`. For example, this allows you to collect the output of `tcpdump` in separate files for each test case where the file name contains the name of the test case.
+
+All commands are optional and can be set independently. The command name (or full path) must be given within double quotes. Whitespaces and special characters are treated as part of the command name and will not be interpreted by the shell. This means that additional, fixed, arguments can not be passed to the external command. If the command string is empty no command will be executed (it also clears the command that was set previously).
+
+[[bnf-productions-for-this-section-4]]
+=== BNF Productions for this Section
+[source]
+----
+ExternalCommandsSection ::= "[EXTERNAL_COMMANDS]" {ExternalCommand}
+ExternalCommand ::= CommandType AssignmentChar Command [SemiColon]
+CommandType ::= "BeginControlPart" | "EndControlPart" | "BeginTestCase" |
+	"EndTestCase"
+Command ::= StringValue
+Example
+[EXTERNAL_COMMANDS]
+BeginTestCase := "/usr/local/tester/bin/StartTcpdump"
+EndTestCase := "/usr/local/tester/bin/StopTcpdump"
+BeginControlPart := "this will be overwritten"
+EndControlPart := ""
+----
+
+=== Example: Running `tcpdump` during test execution
+
+In case of testing IP based protocols it might be useful to monitor the network during TTCN–3 test execution. The following shell scripts show an example how to start the program `tcpdump` in the background at the beginning of every test case and how to terminate it when a test case is finished.
+
+When `tcpdump` is running, its `pid` is stored in the file `/etc/tcpdump.pid` to inform the stopping script which process to kill. Of course, the command line options for tcpdump may be changed to fit your needs. The output of `tcpdump` is saved in the file `<testcase name>.dump` in the working directory of the executable test program, which is useful when `repgen` is used after test execution.
+
+To make this working, you should give the names or full pathes of these scripts as `BeginTestCase` and `EndTestCase` in section `[EXTERNAL_COMMANDS]` of the configuration file.
+
+A complete example script for starting `tcpdump`:
+[source]
+----
+#!/bin/sh
+
+PIDFILE=/tmp/tcpdump.pid
+
+if [ -e $PIDFILE ]
+then
+  kill ‘cat $PIDFILE‘
+  rm $PIDFILE
+fi
+
+/usr/local/sbin/tcpdump -e -n -s 200 -x -v -i eth1 ip6 >$1.dump \
+  2>/dev/null &
+PID=$!
+
+echo $PID >$PIDFILE
+----
+
+The script for stopping `tcpdump`:
+[source]
+----
+#!/bin/sh
+
+PIDFILE=/tmp/tcpdump.pid
+
+if [ -e $PIDFILE ]
+then
+  kill ‘cat $PIDFILE‘
+  rm $PIDFILE
+fi
+----
+
+[[execute]]
+== `[EXECUTE]`
+
+In this section you have to specify what parts of your test suite you want to execute. In single mode the configuration file is useless without this section. The section [`EXECUTE`] is optional in parallel mode. If it is missing, You shall start testcases manually from command line with the command `smtc` `[module name[.control|.testcase name|.*]]` see UG <<13-references.adoc#_17, [17]>> 4.4.2.1. In this case a parameter after smtc is mandatory. Don’t omit this section in case of using `ttcn3_start`, otherwise no testcase will be executed.
+
+You can start TTCN–3 module control parts and test cases individually. There is one limitation: only those test cases having no parameters, or only parameters with default values, can be executed from this section. Other test cases can be started from the module control part with proper actual parameters.
+
+In this section, a single identifier (or an identifier followed by the optional suffix `.control`) means the control part of that TTCN–3 module. Test case names shall be preceded by the name of module that they can be found in and a dot character. You can use the character asterisk (*) instead of test case name, which means the execution of all test cases of the corresponding module in the same order as they are defined in the TTCN–3 source code.
+
+The control parts and test cases are executed in the same order as you specified them in this section. If you define the same module or test case name more than once, that control part or test case will be executed, of course, many times.
+
+=== The BNF Specification of this Section
+[source]
+----
+ExecuteSection ::= "[EXECUTE]" {ExecuteItem}
+ExecuteItem ::= (ControlPart | TestCase) [SemiColon]
+ControlPart ::= ModuleName [ "." "control" ]
+ModuleName ::= Identifier
+TestCase ::= ModuleName "." TestCaseName
+TestCaseName ::= Identifier | "*"
+----
+
+[[example-6]]
+Example
+[source]
+----
+[EXECUTE]
+IPv6Demo.send_echo
+IPv6Demo.send_echo // run it twice
+IPv6BaseSpecification
+IPv6NeighborDiscovery.*
+----
+
+[[groups-parallel-mode]]
+== `[GROUPS]` (Parallel mode)
+
+In this section you can specify groups of hosts. These groups can be used inside the [`COMPONENTS`] section to restrict the creation of certain PTCs to a given set of hosts. See also <<components-parallel-mode, here>>.
+
+This section contains any number of group specifications in the following form: group name, assignment operator (:=) and either an asterisk (*) or a comma-separated list of host names (DNS names) or IP addresses in which you should enlist each hosts belonging to that group. The asterisk appearing on the right side denotes all hosts that take part in the test execution.
+
+Groups may overlap, that is, the same hosts can belong to several groups. Group references, however, cannot appear on the right side. It is worth mentioning that group names are case sensitive.
+
+NOTE: The groups defined in this section have nothing to do with TTCN–3 group of definitions construct!
+
+[[the-bnf-specification-of-this-section-0]]
+=== The BNF Specification of this Section
+[source]
+----
+GroupsSection ::= "[GROUPS]" {GroupItem}
+GroupItem ::= GroupName AssignmentChar (GroupMemberList | "*") [SemiColon]
+GroupName ::= Identifier
+GroupMemberList ::= GroupMember {"," GroupMember}
+GroupMember ::= HostName | IPAddress
+----
+
+[[example-7]]
+Example
+[source]
+----
+[GROUPS]
+HeintelAndPauler := heintel, pauler.eth.ericsson.se
+myGroup := 153.44.87.34, test-host.123.com
+AllHosts := *
+----
+
+[[components-parallel-mode]]
+== `[COMPONENTS]` (Parallel mode)
+
+This section consists of rules restricting the location of created PTCs. These constraints are useful when distributed tests are executed in a heterogeneous environment. The participating computers may have different hardware setup, computing capacity or operating system. Thus some physical interfaces or Test Ports might be present only on a part of the hostsfootnote:[On the remaining computers the unsupported Test Ports shall be substituted with empty stubs (i.e. generated and unmodified skeletons).].
+
+The rules are described in form of assignments. The left side contains a component identifier while the right side names a host or a group of hosts on which the given components are executed. The components can be selected by their component type or name assigned in create operations. The component identifiers are case sensitive. The assigned hosts are taken from the corresponding host group set from the section <<groups-parallel-mode, [`GROUPS`]>>.
+
+Each component type or component name can appear in at most one rule. The asterisk (*) stands for all component identifiers that do not appear in any rule. The asterisk can show in a single rule only.
+
+When a TTCN–3 parallel test component is being created it is the responsibility of the MC to choose a suitable and availablefootnote:[Only those hosts participate in the component distribution algorithm that have an active HC, which has been started by the user. MC ignores all unavailable group members silently and will not start the HC on them.] host for it. First a subset of available hosts, the set of so-called candidates, is determined based on the component distribution rules. The MC implements a load balancing algorithm so that the location of the component will be the candidate with the smallest load, that is, the least number of active TTCN–3 test componentsfootnote:[This term of load has no direct relation to the load average calculated by UNIX kernels.]. Once a component is assigned to a host it, cannot be moved to another one later during its life.
+
+If a newly created PTC matches more than one rule (because both its component type and name is found in the section) all available members of both assigned groups are considered to be candidates.
+
+If section [`COMPONENTS`] is empty or omitted from the configuration file all available hosts are considered to be candidates. If the calculated set of candidates is an empty set (i.e. there is no available host that is allowed by the rules) the `create` operation will fail and dynamic test case error will occur on the ancestor component.
+
+If the location of the PTC is explicitly specified in the `create` operation (see <<3-clarifications_to_the_ttcn-3_standard.adoc#importing-import-statement-from-ttcn-3-modules, here>> for the syntax of this language extension) the rules of this section are ignored. In this case the set of candidates is determined based on the host name or group name that was specified as location.
+
+[[the-bnf-specification-of-this-section-1]]
+=== The BNF Specification of this Section
+[source]
+----
+ComponentsSection ::= "[COMPONENTS]" {ComponentItem}
+ComponentItem ::= ComponentId AssignmentChar ComponentLocation [SemiColon]
+ComponentId ::= Identifier | "*"
+ComponentLocation ::= GroupName | HostName | IPAddress
+----
+
+[[example-8]]
+Example
+[source]
+----
+[COMPONENTS]
+MyComponentType := HeintelAndPauler
+CPComponentType := 153.44.87.34
+* := AllHosts
+----
+
+[[main-controller-parallel-mode]]
+== `[MAIN_CONTROLLER]` (Parallel mode)
+
+The options herein control the behavior of MC. The section [`MAIN_CONTROLLER`] includes four options to be set.
+
+Options `LocalAddress` and `TCPPort` determine the IP address and TCP port on which the MC application will listen for incoming HC connections. Setting `LocalAddress` can be useful on computers having multiple local IP addresses (multi-homed hosts). The value of `LocalAddress` can be either an IP address or a DNS name, which must resolve to an address that belongs to a local network interface. If this option is omitted MC will accept connections on all local IP addresses.
+
+The value of option `TCPPort` is an integer number between 0 and 65535. The recommended port number is 9034. Using a TCP port number that is less than 1024 may require super-user (root) privileges. The MC will listen on an ephemeral port chosen by the kernel when `TCPPort` is omitted or set to zero.
+
+The optional variable `NumHCs` provides support for automated (batch) execution of distributed tests. When present, the MC will not give a command prompt, but wait for `NumHCs` HCs to connect. When the specified number of HCs are connected, the MC automatically creates MTC and executes all items of the section <<execute, [`EXECUTE`]>>. When finished, the MTC is terminated and the MC quits automatically. If `NumHCs` was omitted then the MC shall be controlled interactively, that is, you have to issue the commands `cmtc` and `smtc` yourself (see also sections 12.3, 12.3.1 of the TITAN User Guide <<13-references.adoc#_13, [13]>>).
+
+The `KillTimer` option tells the MC to wait some seconds for a busy test component (MTC or PTC) to terminate when it was requested to stopfootnote:[The MTC can be terminated from the MC’s user interface or from a PTC by executing the mtc.stop operation. The termination of a PTC can be requested either explicitly (using a TTCN–3 component stop or kill operation) or implicitly (at the end of test case).]. The MC in co-operation with the local HC kills the UNIX process if the component did not terminate properly before `KillTimer` expiry. The purpose of this function is to prevent the test system from deadlocks.
+
+NOTE: When the UNIX process of MTC is killed all existing PTCs are destroyed at the same time.
+
+The value of `KillTimer` is measured in seconds and can be given in either integer or floating point notation. Setting `KillTimer` to zero disables the kill functionality, that is, busy test components will not be killed even if they do not respond within a very long time period. When omitted, the default value of `KillTimer` is 10 seconds. This value is sufficient in typical test setups, but it needs to be increased on heavily loaded computers (e.g. when running performance tests). Setting a too short `KillTimer` value may have undesired effects as the final verdict of killed PTCs, which is not known by MC, is always substituted by error.
+
+`UnixSocketsEnabled` has a default value of "yes". When at default value, Titan will use Unix domain sockets for internal communication on the same machine, and TCP sockets to communicate across the network. When set to "no", TCP sockets will be used both internally and over the network.
+
+[[the-bnf-specification-of-this-section-2]]
+=== The BNF Specification of this Section
+[source]
+----
+MainControllerSection ::= "[MAIN_CONTROLLER]" {MainControllerAssignment}
+MainControllerAssignment ::= (LocalAddress | TCPPort | NumHCs | KillTimer |
+  UnixSocketsEnabled) [SemiColon]
+LocalAddress ::= "LocalAddress" AssignmentChar (HostName | IPAddress)
+TCPPort ::= "TCPPort" AssignmentChar IntegerValue
+NumHCs ::= "NumHCs" AssignmentChar IntegerValue
+KillTimer ::= "KillTimer" AssignmentChar (IntegerValue | FloatValue)
+UnixSocketsEnabled ::= "UnixSocketsEnabled" AssignmentChar ("Yes" | "No")
+----
+
+[[example-9]]
+*_Example:_*
+[source]
+----
+[MAIN_CONTROLLER]
+LocalAddress := 192.168.1.1
+TCPPort := 9034
+NumHCs := 3
+KillTimer := 4.5
+UnixSocketsEnabled := Yes
+----
+
+[[profiler]]
+== `[PROFILER]`
+
+The settings in this section control the behavior of the TTCN-3 Profiler. These settings only affect the TTCN-3 modules specified in the file list argument of the compiler option -z. If this compiler option is not set, then the [`PROFILER`] section is ignored.
+
+=== Enabling and disabling features
+
+The following features can be enabled or disabled through the configuration file:
+
+* `DisableProfiler` – if set to `true`, the measurement of execution times is disabled and data related to execution times or average times will not be present in the statistics file. Default value: false
+* `DisableCoverage` – if set to `true`, the execution count of code lines and functions is not measured and data related to execution counts, average times or unused lines/functions will not be present in the statistics file. Default value: `false`
+* If both `DisableProfiler` and `DisableCoverage` are set to `true`, then the profiler acts as if it wasn’t activated in any of the modules (as if the compiler flag –z was not set). The database and statistics files are not generated.
+* `AggregateData` – if set to `true`, the data gathered in the previous run(s) is added to the current data, otherwise all previous data is discarded, default value: `false`
+* `DisableStatistics` – if set to `true`, the statistics file will not be generated at the end of execution, default value: `false`
+* `StartAutomatically` – if set to `true`, the profiler will start when the program execution starts, otherwise it will only start at the first @profiler.start command (it needs to be started individually for each component in parallel mode), default value: `true`
+* `NetLineTimes` – if set to `true`, the execution times of function calls will not be added to the caller lines’ total times, default value: `false`
+* `NetFunctionTimes` – if set to `true`, the execution times of function calls will not be added to the caller functions’ total times, default value: `false`
+
+[[setting-output-files]]
+=== Setting output files
+
+The DatabaseFile setting can be used to specify the name and path of the database file (as a string with double quotation marks, like a `charstring`). This is the file imported by the profiler if data aggregation is set (if this setting is changed between runs, the profiler will not find the old database).
+
+Default value: `profiler.db`
+
+Similarly the `StatisticsFile` setting can be used to specify the name and path of the statistics file.
+
+Default value: `profiler.stats`
+
+The names of both files may contain special metacharacters, which are substituted dynamically during test execution. These are helpful when there are multiple Host Controllers in the profiled test system.
+
+The table below contains the list of available metacharacters in alphabetical order. Any unsupported metacharacter sequence, that is, if the % character is followed by any character that is not listed in the table below or a single percent character stays at the end of the string, will remain unchanged.
+
+.Available metacharacters for setting profiler output file names
+[cols="m,",options="header",]
+|===
+|Meta-character |Substituted with . . .
+|%e |the name of the TTCN–3 executable. The `.exe` suffix (on Windows platforms) and the directory part of the path name (if present) are truncated.
+|%h |the name of the computer returned by the `gethostname(2)` system call. This usually does not include the domain name.
+|%l |the login name of the current user. If the login name cannot be determined (e.g. the current UNIX user ID has no associated login name) an empty string is returned.
+|%p |the process ID `(pid)` of the UNIX process that implements the current test component. The `pid` is written in decimal notation.
+|%% |a single % character.
+|===
+
+=== Statistics filters
+
+The `StatisticsFilter` setting can be used to specify which lists will be calculated and displayed in the statistics file. Its value is a list of filters separated by ampersands (`&`). Vertical lines (`|`) can also be used to separate the filters (as if they were bits added together with binary or) to the same effect.
+
+The concatenation mark (`&=`) can also be used with this setting to specify the filters in multiple commands.
+
+The filters can also be specified with hexadecimal values (similarly to `hexstrings`, but without the quotation marks and the `H` at the end).
+
+.Statistics filters, single lists
+[cols=",,",options="header",]
+|===
+|Filter |Numeric value |Represented list
+|`NumberOfLines` |`0x00000001` |Number of code lines and functions
+|`LineDataRaw` |`0x00000002` |Total time and execution count of code lines (raw)
+|`FuncDataRaw` |`0x00000004` |Total time and execution count of functions (raw)
+|`LineAvgData` |`0x00000008` |Average time of code lines (raw)
+|`FuncAvgData` |`0x00000010` |Average time of functions (raw)
+|`LineTimesSortedByMod` |`0x00000020` |Total time of code lines (sorted, per module)
+|`FuncTimesSortedByMod` |`0x00000040` |Total time of functions (sorted, per module)
+|`LineTimesSortedTotal` |`0x00000080` |Total time of code lines (sorted, total)
+|`FuncTimesSortedTotal` |`0x00000100` |Total time of functions (sorted, total)
+|`LineCountSortedByMod` |`0x00000200` |Execution count of code lines (sorted, per module)
+|`FuncCountSortedByMod` |`0x00000400` |Execution count of functions (sorted, per module)
+|`LineCountSortedTotal` |`0x00000800` |Execution count of code lines (sorted, total)
+|`FuncCountSortedTotal` |`0x00001000` |Execution count of functions (sorted, total)
+|`LineAvgSortedByMod` |`0x00002000` |Average time of code lines (sorted, per module)
+|`FuncAvgSortedByMod` |`0x00004000` |Average time of functions (sorted, per module)
+|`LineAvgSortedTotal` |`0x00008000` |Average time of code lines (sorted, total)
+|`FuncAvgSortedTotal` |`0x00010000` |Average time of functions (sorted, total)
+|`Top10LineTimes` |`0x00020000` |Total times of code lines (sorted, total, top 10 only)
+|`Top10FuncTimes` |`0x00040000` |Total times of functions (sorted, total, top 10 only)
+|`Top10LineCount` |`0x00080000` |Execution count of code lines (sorted, global, top 10 only)
+|`Top10FuncCount` |`0x00100000` |Execution count of functions (sorted, total, top 10 only)
+|`Top10LineAvg` |`0x00200000` |Average time of code lines (sorted, total, top 10 only)
+|`Top10FuncAvg` |`0x00400000` |Average time of functions (sorted, total, top 10 only)
+|`UnusedLines` |`0x00800000` |Unused code lines
+|`UnusedFunc` |`0x01000000` |Unused functions
+|===
+
+.Statistics filters, grouped lists
+[cols=",,",options="header",]
+|===
+|`AllRawData` |`0x0000001E` |Total time, execution count and average time of code lines and functions (raw)
+|`LineDataSortedByMod` |`0x00002220` |Total time, execution count and average time of code lines (sorted, per module)
+|`FuncDataSortedByMod` |`0x00004440` |Total time, execution count and average time of functions (sorted, per module)
+|`LineDataSortedTotal` |`0x00008880` |Total time, execution count and average time of code lines (sorted, total)
+|`FuncDataSortedTotal` |`0x00011100` |Total time, execution count and average time of functions (sorted, total)
+|`LineDataSorted` |`0x0000AAA0` |Total time, execution count and average time of code lines (sorted, total and per module)
+|`FuncDataSorted` |`0x00015540` |Total time, execution count and average time of functions (sorted, total and per module)
+|`AllDataSorted` |`0x0001FFE0` |Total time, execution count and average time of code lines and functions (sorted, total and per module)
+|`Top10LineData` |`0x002A0000` |Total time, execution count and average time of code lines (sorted, total, top 10 only)
+|`Top10FuncData` |`0x00540000` |Total time, execution count and average time of functions (sorted, total, top 10 only)
+|`Top10AllData` |`0x007E0000` |Total time, execution count and average time of code lines and functions (sorted, total, top 10 only)
+|`UnusedData` |`0x01800000` |Unused code lines and functions
+|`All` |`0x01FFFFFF` |All lists
+|===
+
+NOTE: the `DisableProfiler` and `DisableCoverage` settings also influence which lists are displayed in the statistics file (e.g.: if `DisableCoverage` is set to `true` and `StatisticsFilter` is set to `Top10LineData`, then the statistics file will only contain the top 10 total times list).
+
+[[the-bnf-specification-of-this-section-3]]
+=== The BNF Specification of this Section
+[source]
+----
+ProfilerSection ::= "[PROFILER]" {ProfilerSetting}
+ProfilerSetting ::= (DisableProfilerSetting | DisableCoverageSetting |
+  DatabaseFileSetting | AggregateDataSetting | StatisticsFileSetting |
+  DisableStatisticsSetting | StatisticsFilterSetting) [SemiColon]
+DisableProfilerSetting ::= “DisableProfiler” AssignmentChar BooleanValue
+DisableCoverageSetting ::= “DisableCoverage” AssignmentChar BooleanValue
+DatabaseFileSetting ::= “DatabaseFile” AssignmentChar CharstringValue
+AggregateDataSetting ::= “AggregateData” AssignmentChar BooleanValue
+StatisticsFileSetting ::= “StatisticsFile” AssignmentChar CharstringValue
+DisableStatisticsSetting ::= “DisableStatistics” AssignmentChar BooleanValue
+StatisticsFilterSetting ::= “StatisticsFilter” (AssignmentChar | ConcatChar)
+  StatisticsFilter [ { (“&” | “|”) StatisticsFilter } ]
+StatisticsFilter ::= (“NumberOfLines” | “LineDataRaw” | “FuncDataRaw” |
+  “LineAvgRaw” | “FuncAvgRaw” | “LineTimesSortedByMod” | “FuncTimesSortedByMod”
+  | “LineTimesSortedTotal” | “FuncTimesSortedTotal” | “LineCountSortedByMod” |
+  “FuncCountSortedByMod” | “LineCountSortedTotal” | “FuncCountSortedTotal” |
+  “LineAvgSortedByMod” | “FuncAvgSortedByMod” | “LineAvgSortedTotal” |
+  “FuncAvgSortedTotal” | “Top10LineTimes” | “Top10FuncTimes” | “Top10LineCount”
+  | “Top10FuncCount” | “Top10LineAvg” | “Top10FuncAvg” | “UnusedLines” |
+  “UnusedFunc” | {Hex}+)
+----
+[[example-10]]
+*_Example:_*
+[source]
+----
+[PROFILER]
+DisableProfiler := false
+DisableCoverage := false
+DatabaseFile := "data.json"
+AggregateData := false
+StatisticsFile := "prof.stats"
+DisableStatistics := false
+StatisticsFilter := Top10AllData & UnusedData
+StatisticsFilter &= AllRawData
+StatisticsFilter &= 88A0
+----
+
+== Dynamic Configuration of Logging Options
+
+Some logging options may be altered during the run of the test suite. This allows e.g. to vary the logging verbosity between testcases.
+
+The interface is contained in `$(TTCN3_DIR)/include/TitanLoggerControl.ttcn`; this file needs to be added to the project. `TitanLoggerControl.ttcn` contains definitions of various external functions which can be called from TTCN-3 code. The implementation of these external functions is built into the Titan runtime library; it will be linked automatically.
+
+The individual logging severities are contained in the "Severity" enumerated type. A logging mask is represented by a record-of:
+
+`type record of Severity Severities;`
+
+For each logging bit set, the record-of will contain an element.
+
+The TitanLoggerControl module defines several constants:
+[source]
+----
+const Severities log_nothing    := {};
+const Severities log_console_default := { … }
+const Severities log_all := { … } // LOG_ALL, without MATCHING,DEBUG
+const Severities log_everything := { … } // really everything
+----
+These constants can be used when setting logger options.
+
+Each function has a parameter named `plugin`, to specify which `plugin` is being manipulated. Currently, the value of the plugin parameter must be `"LegacyLogger"`.
+
+=== Retrieving Logging Masks
+
+The following functions can be used to retrieve the current value of the logger file mask/console mask:
+[source]
+----
+get_file_mask(in charstring plugin) return Severities;
+get_console_mask(in charstring plugin) return Severities;
+----
+
+=== Setting Logging Masks
+
+The following functions set the file mask or console mask, overwriting the previous value:
+[source]
+----
+set_file_mask(in charstring plugin, in Severities s);
+set_console_mask(in charstring plugin, in Severities s);
+----
+Logging severities present in the parameter will be switched on; severities absent from the parameter will be switched off.
+
+The following functions allow adding individual Severity values to the list of events that are logged, without affecting other severities:
+[source]
+----
+add_to_file_mask(in charstring plugin, in Severities s);
+add_to_console_mask(in charstring plugin, in Severities s);
+----
+Logging severities present in the parameter will be switched on; severities absent from the parameter will not be modified. Example: to turn on DEBUG_ENCDEC without affecting other severities:
+[source]
+----
+var Severities encdec := { DEBUG_ENCDEC }
+TitanLoggerControl.add_to_file_mask(“LegacyLogger”, encdec);
+----
+
+NOTE: Each bit is treated individually. To turn on a first level category, one needs to enumerate all subcategories. For example, to turn on all `DEBUG` messages, the value of the Severities variable should be:
+
+[source]
+----
+var Severities debug_all := { DEBUG_ENCDEC, DEBUG_TESTPORT, DEBUG_UNQUALIFIED };
+TitanLoggerControl.add_to_file_mask(“LegacyLogger”, debug_all);
+----
+
+The following functions allow removing of individual Severities:
+[source]
+----
+remove_from_file_mask(in charstring plugin, in Severities s);
+remove_from_console_mask(in charstring plugin, in Severities s);
+----
+
+Logging severities present in the parameter will be switched off; severities absent from the parameter will not be modified.
+When setting file/console masks, redundant severity values are ignored. For example, the two following values have the same effect when passed to set_file_mask.
+[source]
+----
+var Severities ptc := { PARALLEL_PTC };
+var Severities ptc3:= { PARALLEL_PTC, PARALLEL_PTC, PARALLEL_PTC };
+----
+
+=== Manipulating the Log File Name
+
+The following function allows setting the log file name skeleton. See <<lttngustlogger-plugin, here>> for possible values.
+
+[source]
+set_log_file(in charstring plugin, in charstring filename);
+
+[[enabling-disabling-the-logging-of-ttcn-3-entity-name]]
+=== Enabling/disabling the Logging of TTCN-3 Entity Name
+
+The following functions allow the reading and writing of the <<LogEntityName, `LogEntityName`>> parameter.
+
+[source]
+----
+set_log_entity_name(in charstring plugin, in boolean b);
+get_log_entity_name(in charstring plugin) return boolean;
+----
diff --git a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..3bd9a2ab73e189336887929f944b8a63ea5c6cae
--- /dev/null
+++ b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
@@ -0,0 +1,630 @@
+= The TITAN Project Descriptor File
+:toc:
+:table-number: 28
+
+Concept of the project is defined in chapter 4 of User Guide for the TITAN Designer <<13-references.adoc#_17, [17]>> because it is introduced in TITAN Designer which is the name of one of the Eclipse plugin of TITAN.
+
+The content of a project and all project specific settings are described in the TITAN project descriptor (TPD) file. The name of the TPD file is in the form `<project_name>.tpd` e.g. `HelloTitan.tpd`.
+
+The tpd file contains information about the project name, the contained files, referenced (used) projects, make, configuration and running information etc. (se later) but doesn’t contain source files at all.
+
+Tpd files are designed to produce portability for projects. Primarily it is automatically created by the Titan Designer (in Eclipse) when project settings of an existing project are exported (see Chapter 4.9.4 of <<13-references.adoc#_17, [17]>>). The created TPD file can be used to import the project into another workspace (belonging to the same or to a different user) if the files and projects referred by the TPD are available at the new place (see Chapter 4.9.5 of <<13-references.adoc#_17, [17]>>). If the project to be exported contains referenced (used) project, then the TITAN project setting of the referenced projects shall be exported previously.
+
+Tpd files can be used without TITAN Designer for example for generating hierarchical Makefiles from command line by the makefile generator (see <<6-compiling_ttcn3_and_asn1_modules.adoc#using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s, here>>). The files and TPD files referred by the TPD should be available.
+
+TPD files are designed to be created by the Eclipse Designer but it can be created or modified by experts.
+
+The data is stored in XML format. The schema definition of the project descriptor is delivered with the Titan package and can be found in the `${TTCN3_DIR}/etc/xsd/TPD.xsd` file. If the type of an element is a subtype of string, for example a file name or a path, the xsd file doesn’t restrict it but uses only string or NormalizedString as type. Although the compliance of a TPD file for TPD.xsd is a necessary but not sufficient statement, it is very useful to verify the tpd file against TPD.xsd for example with this command: `xmllint –noout –schema XSD_FILE XML_FILE`
+
+Each element is designed to be extendable, so for almost all elements there is a default value defined, if the element is missing this value is used.To simplify the reviews the elements are always saved in an ordered fashion thus limiting the effects of minor changes. The lists can contain from 0 to infinite elements. The O/M column in the tables describes if the element is optional or mandatory.
+
+The TPD file contains a top level element <TITAN_Project_File_Information>.
+
+This has an attribute called "version". This attribute describes the version of the TPD.xsd file which the tpd file validates to. e.g.:
+
+`<TITAN_Project_File_Information version="1.0">`. Currently this version is fixed.
+
+The elements contained in the top level element are listed below in Table.
+
+The content of these elements is discussed later in this chapter.
+
+.The sequence of elements of TITAN_Project_File_Information
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Meaning* |*O/M*
+|`ProjectName` |The name of the project. This name is used as the name of the TPD file used for export. This is also the name of the project created by TITAN Designer at import. See also <<project-name, here>> |M
+|`ReferencedProjects` |The list of projects referenced by the actual one.Not present if the actual project does not reference any other. See also <<referenced-projects, here>> |O
+|`Folders` |The list of folders present in the project.Not present if the actual project does not contain any folders to be saved. See also <<files-and-folders, here>> |O
+|`Files` |The list of files present in the project.Not present if the actual project does not contain any files to be saved. See also <<files-and-folders, here>> |O
+|`PathVariables` |The list of eclipse path variables active in the workbench.Not present if the actual workbench did not contain any path variables. See also <<path-variables, here>> |O
+|`ActiveConfiguration` |The name of the build configuration active whose parameters will be used by TITAN for building the project. See also <<ActiveConfiguration, here>> |M
+|`Configurations` |The list of configurations set on the actual project. Please note, that there is always at least one configuration, the "Default", set for every project. See also <<configuration, here>> |O
+|`PackedReferencedProjects` |PackedReferencedProjects contains not references for other TPDS but the content of the TPDs belonging to the referenced projects (without element PackedReferencedProjects). Not present if the actual project is not referencing any other, or if the saving of this data is not explicitly requested by the user. See also <<packed-referenced-projects, here>> |O
+|===
+
+[[project-name]]
+== Project Name
+
+The ProjectName element contains the name of the project.
+
+Example:
+[source]
+<ProjectName>HelloTitan2</ProjectName>
+
+[[referenced-projects]]
+== Referenced Projects
+
+The `ReferencedProjects` element contains a list of `ReferencedProject` elements, each of which describes a single project referencing relation. A referenced project is a project whose content is used by our project, e.g. its files are imported by the file of the current project.
+
+The following tags are supported:
+
+.Attributes of ReferencedProject
+[cols=",,",options="header",]
+|===
+|*Name of the attributes* |*Meaning* |*O/M*
+|`name` |The name of the project referenced. This will create the relation between the actual and the referenced project. The value of this attribute must be equal to the `ProjectName` of the referenced project. |M
+|`projectLocationURI` |The path of the project descriptor of the referenced project, relative to the actual descriptor.If the project is not already loaded in eclipse, it will be loaded from this path. |M
+|`tpdName` |The file name of the TPD file. This attribute is used with the `makefilegen’s` –I switch to provide search paths to find the referenced project if it is not found at `projectLocationURI`. |O
+|===
+
+Example:
+[source]
+----
+<ReferencedProjects>
+       <ReferencedProject name="Hello_world"
+projectLocationURI="../Hello_world/Hello_world.tpd"/>
+</ReferencedProjects>
+----
+
+[[files-and-folders]]
+== Files and Folders
+
+These elements contain some basic information on files and folders present in the project that is needed to recreate the structure of the project anytime later.
+
+The `Files` element is a list of `FileResource` elements, the `Folders` element is a list of `FolderResource` elements.
+
+Right now the contents of the `FileResource` and `FolderResource` elements are the same. All information is stored in attributes.
+
+.The attributes of `FileResource` and `FolderResource`.
+[cols=",,",options="header",]
+|===
+|*Name of the attribute* |*Meaning* |*O/M*
+|`projectRelativePath` |The path of the resource inside the resource system of eclipse. |M
+|`relativeURI` |This is the path relative to the location where the project descriptor files is being saved, in case the path of the resource does not contain any feature, that needs to be resolved, and it is possible to calculate the relative path. |O
+|`rawURI` |This is the raw path of the resource as stored by the platform. In this form the path variables, or any other feature, are not yet resolved. |O
+|===
+
+If both tags are present the `relativeURI` should be used. It is an error if neither the `relativeURI` nor the `rawURI` attribute is present.
+
+Example:
+[source]
+----
+<Folders>
+    <FolderResource projectRelativePath="src" relativeURI="file:src"/>
+    <FolderResource projectRelativePath="virtual" rawURI="virtual:/virtual"/>
+  </Folders>
+  <Files>
+    <FileResource projectRelativePath=".TITAN_properties" relativeURI="file:.TITAN_properties"/>
+    <FileResource projectRelativePath=".project" relativeURI="file:.project"/>
+  </Files>
+----
+
+[[path-variables]]
+== Path Variables
+
+The `PathVariables` element stores the list of `PathVariable` elements, each of which describes a single eclipse path variable. They are not used at Makefile generation from command line.
+
+.Attributes of PathVariable
+[cols=",,",options="header",]
+|===
+|*Name of the attribute* |*Meaning* |*O/M*
+|Name |The name of the path variable. |M
+|Value |The value of the path variable. |M
+|===
+
+Example:
+[source]
+----
+<PathVariables>
+    <PathVariable name="path_variable1" value="C:/ekrisza"/>
+    <PathVariable name="path_variable2" value="C:/Users/ekrisza/doksi-workbench-workspace/masik/masik.TITAN_Project_Format"/>
+  </PathVariables>
+----
+
+[[ActiveConfiguration]]
+== ActiveConfiguration
+
+The ActiveConfiguration element stores the name of the active build configuration whose parameters will be used by TITAN for building the project.
+
+NOTE: This can be overwritten from TITAN Designer (from Eclipse) or from command line generating Makefile(s) by ttcn3_makefilegen using the –b flag, see <<6-compiling_ttcn3_and_asn1_modules.adoc#using-the-makefile-generator-to-generate-makefile-s-from-titan-project-descriptor-file-s, here>>.
+
+See also chapter <<configurations, Configurations>>.
+
+Example:
+
+[source]
+<ActiveConfiguration>Default</ActiveConfiguration>
+
+[[configurations]]
+== Configurations
+
+The `Configurations` element stores a list of `Configuration` elements, each of which describes a single build configuration. Different build configurations can use a different file set, different makefile settings (e.g single or parallel mode, operational system specific settings etc).
+
+The `Configuration` element has a single tag called `name`, and stores the name of the configuration.
+
+.Elements of Configuration
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Meaning* |*O/M*
+|`ProjectProperties` |Stores the settings of the project required to create a Makefile, to build the project, and the project level naming conventions. See <<project-properties, here>>. |O
+|`FolderProperties` |Stores the properties of each folder contained in the project. Not present if there are no folders in the project, or all folders have all attributes on their default values. See chapter <<folder-properties, here>>. |O
+|`FileProperties` |Stores the properties of each file contained in the project. Not present if there are no files in the project, or all files have all attributes on their default values. See chapter <<file-properties, here>>. |O
+|===
+
+[[project-properties]]
+=== Project Properties
+
+This element contains all information needed to create a proper Makefile for the project to drive the build process (all information other than the list of files) and for naming convention checking. Compare this chapter with chapter "Setting Project Properties" in TITAN Designer Documentation <<13-references.adoc#_17, [17]>>.
+
+It can contain 5 elements: `MakefileSettings`, `LocalBuildSettings`,
+
+`RemoteBuildProperties`, `NamingConventions`, `ConfigurationRequirements`.
+
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Meaning* |*O/M*
+|`MakefileSettings` |Stores the settings of the project required to create a Makefile.For more information see <<makefile-settings, here>> |O
+|`LocalBuildSettings` |Stores the settings of the project required to perform the build. See <<local-build-settings, here>> |O
+|`RemoteBuildProperties` |Stores information necessary for remote build. See <<remote-build-properties, here>> |
+|`NamingConventions` |Stores the project specific naming conventions. See <<naming-conventions, here>> |O
+|`ConfigurationRequirements` |Stores the required build configurations of the referenced projects. See <<configuration-requirements, here>> |O
+|===
+
+[[makefile-settings]]
+==== Makefile Settings
+
+The flags for the TTCN3 compiler can be specified in this section. For more information please refer to section <<6-compiling_ttcn3_and_asn1_modules.adoc#complier, Compiler>>. A supplementary information is placed in brackets.
+
+Useful information can be found in TITAN Designer documentation <<13-references.adoc#_17, [17]>> as well.
+
+.The elements of MakefileSettings
+[cols=",,,,",options="header",]
+|===
+|*Name* |*Makefilegen option* |*Compiler option* |*Default value (used when not being present)* |*O/M*
+|`generateMakefile (meaningful only in Eclipse)` |- |- |true |O
+|`generateInternalMakefile (meaningful only in Eclipse)` |- |- |false |O
+|`symboliclinklessBuild` |- |- |false |O
+|`useAbsolutePath` |-a |- |false |O
+|`GNUMake` |-g |- |false |O
+|`incrementalDependencyRefresh (meaningful not only in Eclipse, necessary to apply incremental dependency via gnu Make and .d files)` |- |- |false |O
+|`dynamicLinking` |-l |- |false |O
+|`functiontestRuntime (use function test runtime (TITAN_RUNTIME_2)` |-R |-R |false |O
+|`singleMode` |-s |- |false |O
+|`codeSplitting (select code splitting mode for the generated C++ code)` |-U |-U |none |O
+|`defaultTarget ("executable" or "library", if –L applied, see 6.1.2)` |-L |- |executable |O
+|`targetExecutable` |-e |- |N/A |O
+|`TTCN3preprocessor (the name of the preprocessor meaningful only in Eclipse)` |- |- |cpp |O
+|`TTCN3preprocessorIncludes` |- |- |empty |O
+|`preprocessorIncludes` |-p |- |emtpy |O
+|`disableBER (disable BER encoder/decoder functions)` |- |-b |false |O
+|`disableRAW (disable RAW encoder/decoder functions)` |- |-r |false |O
+|`disableTEXT (disable TEXT encoder/decoder functions)` |- |-x |false |O
+|`disableXER` |- |-X |false |O
+|`disableOER` |- |-O |false |O
+|`forceXERinASN.1 (force XER in ASN.1 files)` |- |-a |false |O
+|`defaultasOmit (-d compiler option)` |- |-d |false |O
+|`gccMessageFormat (emulate GCC error/warning message format)` |- |-g |false |O
+|`lineNumbersOnlyInMessages (use only line numbers in error/warning messages)` |- |-i |false |O
+|`includeSourceInfo (include source line info in C++ code)` |- |-l |false |O
+|`addSourceLineInfo (add source line info for logging)` |- |-L |false |O
+|`suppressWarnings (suppress warnings)` |-w |-w |false |O
+|`Quietly (suppress all messages, quiet mode)` |- |-q |false |O
+|`namingRules (only in Eclipse)` |- |- |unspecified |O
+|`disableSubtypeChecking (disable subtype checking)` |- |-y |false |O
+|`forceOldFuncOutParHandling (force old function out parameter handling) Note: overwrites obsolete tag outParamBoundness` |-Y |-Y |false |O
+|`CxxCompiler (The name of the compiler, only in Eclipse)` |- |- |g++ |O
+|`optimizationLevel (only in Eclipse)`|- |- |"Common optimizations" |O
+|`otherOptimizationFlags (only in Eclipse)` |- |- |empty |O
+|`disablePredefinedExternalFolder (OPENSSL_DIR and XMLDIR)` |- |- |false |O
+|`enableLegacyEncoding` |-G |-e |false |O
+|`disableUserInformation` |- |-D |false |O
+|`buildLevel (only in Eclipse, see below and in 6.1.6 The actual building in [17])`|- |- |"Level 5 - Creating Executable Test Suite with dependency update" |O
+|`ProjectSpecificRulesGenerator` |- |- |Used to place custom rules and new targets into the generated Makefile |O
+|`profiledFileList (enables profiling and code coverage in the specified modules)` |-z |-z |empty |O
+|`omitInValueList` |-M |-M |false |O
+|`warningsForBadVariants` |-E |-E |false |O
+|`activateDebugger` |-n |-n |false |O
+|`ignoreUntaggedOnTopLevelUnion` |-N |-N |false |O
+|===
+
+The supported values of `optimizationLevel` are:
+
+* "None"
+* "Minor optimizations"
+* "Common optimizations"
+* "Optimize for speed"
+* "Optimize for size"
+* The optimization flags given as the value of otherOptimizationFlags are passed to the Cxx compiler.
+
+The support values for buildLevel are:
+
+* "Level 0 - Semantic Check"
+* "Level 1 - TTCN3 -> C++ compilation"
+* "Level 2 - Creating object files"
+* "Level 2.5 - Creating object files with heuristical dependency update"
+* "Level 3 - Creating object files with dependency update"
+* "Level 4 - Creating Executable Test Suite"
+* "Level 4.5 - Creating Executable Test Suite with heuristical dependency update"
+* "Level 5 - Creating Executable Test Suite with dependency update"
+
+NOTE: The targetExecutable path is stored either relative to the root of the project, or with full path.
+
+It is possible to reference environment variables in the following fields with the syntax `"[" VariableName "]"`:
+
+* `TTCN3preprocessorIncludes`
+* `preprocessorIncludes`
+* `SolarisSpecificLibraries`
+* `Solaris8SpecificLibraries`
+* `LinuxSpecificLibraries`
+* `FreeBSDSpecificLibraries`
+* `Win32SpecificLibraries`
+* `linkerLibraries`
+* `linkerLibrarySearchPath`
+
+The variables referenced with this syntax will be recognized by the Eclipse Designer plugin. If the tpd is used for makefile generation, the `ttcn3_makefilegen` will replace the reference with its command line equivalent in the generated makefile. (e.g. `[VariableName] => $(VariableName)` ).
+
+Contents of the `ProjectSpecificRulesGenerator` element:
+
+Exactly one `GeneratorCommand` element that specifies the external command to be run
+
+An optional Targets element that contains any number of Target elements, each element having two attributes: name – name of the target, placement – the place of where the target shall be inserted. Possible places are defined in the TPD.xsd file.
+
+The content of the `profiledFileList` element is the path to a text file, using the same path attributes as `FileResource` elements. The text file contains the list of files (TTCN-3 modules), that will be profiled, separated by new lines. This file is stored in the variable `PROFILED_FILE_LIST` in the generated makefile.
+
+TPDs of referenced projects may also contain profiled file lists, these are merged with each other and with the top-level project’s file list (a new rule is created that merges the lists). In this case the variable `PROFILED_FILE_LIST` contains the merged file list, and `PROFILED_FILE_LIST_SEGMENTS` contains the individual file lists.
+
+NOTE: A new rule is added to make target `compile` (both rules are switched to double colon rules), if the profiled file list exists, since changing the list of profiled files requires all modules to be recompiled. If the profiled file list is also a make target (in case it is merged from other lists), then a new dependency is added to make targets `check` and `compile-all` (also with the use of double colon rules).
+
+[[local-build-settings]]
+==== Local Build Settings
+
+.Elements of LocalBuildSettings
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Default value* |*O/M*
+|`MakefileFlags` |empty |O
+|`MakefileScript` |empty |O
+|`workingDirectory` |N/A |O
+|===
+
+`MakefileScript` is a script which modifies the Makefile generated by the makefilegen program or by the TITAN Designer internal makefile generator. This kind of script is widely used to automatically insert or remove flags which are not handled by the ttcn3_makefilegen. If the Makefile is generated by the TITAN Designer, this script is generally not necessary because the TITAN Designer can handle (insert or remove) them but even in this case there can be necessary modifications. Duplicated insertion of flags can cause errors.
+
+The `MakefileScript` shall be a shell script and it must have two parameters. The first parameter is the name of the generated Makefile and the second parameter is the name of the generated Makefile with the `.tmp` suffix. The `MakefileScript` should write the contents of the modified Makefile into the `.tmp` file from the second argument. The TITAN Designer and the makefilegen tool will automatically move the contents of the `.tmp` file into the Makefile and then remove the `.tmp` file.
+
+NOTE: The `MakefileScript` and `workingDirectory` paths are stored either relative to the root of the project, or with full path.
+
+[[remote-build-properties]]
+==== Remote Build Properties
+
+RemoteBuildProperties contains a sequence of elements type of "RemoteHost" and one optional ParallelExecution element which is a boolean. A RemoteHost contains 3 elements according to Table 36 Elements of `RemoteHost`.
+
+.Elements of `RemoteHost`
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Type* |*O/M*
+|`Active` |boolean |M
+|`Name` |string |M
+|`Command` |string |M
+|===
+
+[[naming-conventions]]
+==== Naming Conventions
+
+The naming conventions are given using Java regular expressions. All of the elements below are optional.
+
+.Elements of NamingConventions
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Default value* |*O/M*
+|`TTCN3ModuleName` |.* |O
+|`ASN1ModuleName` |.* |O
+|`altstep` |as_.* |O
+|`globalConstant` |cg_.* |O
+|`externalConstant` |ec_.* |O
+|`function` |f_.* |O
+|`externalFunction` |ef_.* |O
+|`moduleParameter` |m.* |O
+|`globalPort` |.*_PT |O
+|`globalTemplate` |t.* |O
+|`testcase` |tc_.* |O
+|`globalTimer` |T.* |O
+|`type` |.* |O
+|`group` |[A-Z].* |O
+|`localConstant` |cl.* |O
+|`localVariable` |vl.* |O
+|`localTemplate` |t.* |O
+|`localVariableTemplate` |vt.* |O
+|`localTimer` |TL_.* |O
+|`formalParameter` |pl_.* |O
+|`componentConstant` |c_.* |O
+|`componentVariable` |v_.* |O
+|`componentTimer` |T_.* |O
+|===
+
+Other than the above mentioned on the project level there is one more called: `enableProjectSpecificSettings` with being empty as the default value. This element makes it possible to override the global settings.
+
+On folder level the extra node is called `enableFolderSpecificSettings` with being empty as the default value. This element makes it possible to override the global settings.
+
+[[configuration-requirements]]
+==== Configuration Requirements
+
+The `ConfigurationRequirements` element stores a list of `ConfigurationRequirement` elements, each of which describes a single configuration requirement for a referenced project. For each referenced project there can be maximally one `ConfigurationRequirement` element. If there is no requirement against the actual configuration of a referenced project this element is missing.
+
+.Elements of ConfigurationRequirement
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Meaning* |*O/M*
+|`projectName` |Stores the name of the project for which the requirement applies. |M
+|`rerquiredConfiguration` |Stores the name of the required project configuration as known by the referenced project. |M
+|===
+
+[[folder-properties]]
+=== Folder Properties
+
+The `FolderProperties` element contains a list of `FolderResource` elements each of which contains all information related to the actual settings of the folders in a given build configuration. The `FolderResource` element contains a `FolderPath` and a `FolderProperties` subelement.
+
+.Elements of FolderResource
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Meaning* |*O/M*
+|`FolderPath` |The path of the folder in the eclipse resource system. |O
+|`FolderProperties` |The actual properties of the folder. |O
+|===
+
+.The optional elements of the FolderProperties sub element
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Default value* |*O/M*
+|`ExcludeFromBuild` |false |O
+|`centralStorage` |false |O
+|`NamingCoventions` |Missing if all elements are on default value |O
+|===
+
+For more information about the `NamingConventions` element please refer <<naming-conventions, here>>.
+
+[[file-properties]]
+=== File Properties
+
+The `FileProperties` element contains a list of `FileResource` elements each of which contains all information related to the actual settings of the files in a given build configuration. The `FilePath` and the `FileProperties` subelements are mandatory.
+
+.Elements of FileResource
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Meaning* |*O/M*
+|`FilePath` |The path of the file in the eclipse resource system. |M
+|`FileProperties` |The actual properties of the file. see Table 42 |M
+|===
+
+.Elements of the FileProperties sub element
+[cols=",,",options="header",]
+|===
+|*Name of the element* |*Default value* |*O/M*
+|`ExcludeFromBuild` |false |O
+|===
+
+[[packed-referenced-projects]]
+== Packed Referenced Projects
+
+The `PackedReferencedProjects` element stores a list of `PackedReferencedProject` elements, each of them describes a single project reachable from the actual one or from referenced projects via project referencing.
+
+The elements of this list are the same as TITAN_Project_File_Information but they cannot contain `PackedReferencesProjects`. All referred projects in the project chain are listed in this list.
+
+A single `PackedProjectReference` element stores the same data in the same manner as it is stored in the referenced project but it cannot store the element `PackedReferencedProjects`.
+
+Example:
+[source]
+----
+<PackedReferencedProjects>
+    <PackedReferencedProject>
+      <ProjectName>HelloTitan</ProjectName>
+      <Folders>
+        <FolderResource projectRelativePath="bin" relativeURI="../HelloTitan/bin"/>
+        <FolderResource projectRelativePath="src" relativeURI="../HelloTitan/src"/>
+      </Folders>
+      <Files>
+        <FileResource projectRelativePath=".TITAN_properties" relativeURI="../HelloTitan/.TITAN_properties"/>
+        <FileResource projectRelativePath=".project" relativeURI="../HelloTitan/.project"/>
+        <FileResource projectRelativePath="HelloTitan.tpd" relativeURI="../HelloTitan/HelloTitan.tpd"/>
+      </Files>
+      <ActiveConfiguration>Default</ActiveConfiguration>
+      <Configurations>
+        <Configuration name="Default">
+          <ProjectProperties>
+            <MakefileSettings>
+              <generateMakefile>true</generateMakefile>
+              <generateInternalMakefile>true</generateInternalMakefile>
+              <symboliclinklessBuild>false</symboliclinklessBuild>
+              <useAbsolutePath>false</useAbsolutePath>
+              <GNUMake>false</GNUMake>
+              <incrementalDependencyRefresh>false</incrementalDependencyRefresh>
+              <dynamicLinking>false</dynamicLinking>
+              <functiontestRuntime>false</functiontestRuntime>
+              <singleMode>false</singleMode>
+              <codeSplitting>none</codeSplitting>
+              <defaultTarget>executable</defaultTarget>
+              <targetExecutable>bin\HelloTitan.exe</targetExecutable>
+              <TTCN3preprocessor>cpp</TTCN3preprocessor>
+              <TTCN3preprocessorIncludes/>
+              <preprocessorIncludes/>
+              <disableBER>false</disableBER>
+              <disableRAW>false</disableRAW>
+              <disableTEXT>false</disableTEXT>
+              <disableXER>false</disableXER>
+              <disableOER>false</disableOER>
+              <forceXERinASN.1>false</forceXERinASN.1>
+              <defaultasOmit>false</defaultasOmit>
+              <enumHackProperty>false</enumHackProperty>
+              <forceOldFuncOutParHandling>false<forceOldFuncOutParHandling>
+              <gccMessageFormat>false</gccMessageFormat>
+              <lineNumbersOnlyInMessages>false</lineNumbersOnlyInMessages>
+              <includeSourceInfo>false</includeSourceInfo>
+              <addSourceLineInfo>false</addSourceLineInfo>
+              <suppressWarnings>false</suppressWarnings>
+              <quietly>false</quietly>
+              <namingRules>unspecified</namingRules>
+              <disableSubtypeChecking>false</disableSubtypeChecking>
+              <CxxCompiler>g++</CxxCompiler>
+              <optimizationLevel>Commonoptimizations</optimizationLevel>
+              <otherOptimizationFlags></otherOptimizationFlags>
+<ignoreUntaggedOnTopLevelUnion>false</ignoreUntaggedOnTopLevelUnion>
+              <enableLegacyEncoding>false</enableLegacyEncoding>
+              <disableUserInformation>false</disableUserInformation>
+<disablePredefinedExternalFolder>false</disablePredefinedExternalFolder>
+              <buildLevel>Level5-CreatingExecutableTestSuitewithdependencyupdate</buildLevel>
+            </MakefileSettings>
+            <LocalBuildSettings>
+              <MakefileFlags></MakefileFlags>
+              <MakefileScript></MakefileScript>
+              <workingDirectory>bin</workingDirectory>
+            </LocalBuildSettings>
+            <NamingCoventions>
+              <enableProjectSpecificSettings></enableProjectSpecificSettings>
+              <TTCN3ModuleName>.*</TTCN3ModuleName>
+              <ASN1ModuleName>.*</ASN1ModuleName>
+              <altstep>as_.*</altstep>
+              <globalConstant>cg_.*</globalConstant>
+              <externalConstant>ec_.*</externalConstant>
+              <function>f_.*</function>
+              <externalFunction>ef_.*</externalFunction>
+              <moduleParameter>m.*</moduleParameter>
+              <globalPort>.*_PT</globalPort>
+              <globalTemplate>t.*</globalTemplate>
+              <testcase>tc_.*</testcase>
+              <globalTimer>T.*</globalTimer>
+              <type>.*</type>
+              <group>[A-Z].*</group>
+              <localConstant>cl.*</localConstant>
+              <localVariable>vl.*</localVariable>
+              <localTemplate>t.*</localTemplate>
+              <localVariableTemplate>vt.*</localVariableTemplate>
+              <localTimer>TL_.*</localTimer>
+              <formalParameter>pl_.*</formalParameter>
+              <componentConstant>c_.*</componentConstant>
+              <componentVariable>v_.*</componentVariable>
+              <componentTimer>T_.*</componentTimer>
+            </NamingCoventions>
+          </ProjectProperties>
+          <FolderProperties>
+            <FolderResource>
+              <FolderPath>src</FolderPath>
+              <FolderProperties>
+                <ExcludeFromBuild>false</ExcludeFromBuild>
+                <centralStorage>false</centralStorage>
+                <NamingCoventions>
+                  <enableFolderSpecificSettings></enableFolderSpecificSettings>
+                  <TTCN3ModuleName>.*</TTCN3ModuleName>
+                  <ASN1ModuleName>.*</ASN1ModuleName>
+                  <altstep>as_.*</altstep>
+                  <globalConstant>cg_.*</globalConstant>
+                  <externalConstant>ec_.*</externalConstant>
+                  <function>f_.*</function>
+                  <externalFunction>ef_.*</externalFunction>
+                  <moduleParameter>m.*</moduleParameter>
+                  <globalPort>.*_PT</globalPort>
+                  <globalTemplate>t.*</globalTemplate>
+                  <testcase>tc_.*</testcase>
+                  <globalTimer>T.*</globalTimer>
+                  <type>.*</type>
+                  <group>[A-Z].*</group>
+                  <localConstant>cl.*</localConstant>
+                  <localVariable>vl.*</localVariable>
+                  <localTemplate>t.*</localTemplate>
+                  <localVariableTemplate>vt.*</localVariableTemplate>
+                  <localTimer>TL_.*</localTimer>
+                  <formalParameter>pl_.*</formalParameter>
+                  <componentConstant>c_.*</componentConstant>
+                  <componentVariable>v_.*</componentVariable>
+                  <componentTimer>T_.*</componentTimer>
+                </NamingCoventions>
+              </FolderProperties>
+            </FolderResource>
+            <FolderResource>
+              <FolderPath>bin</FolderPath>
+              <FolderProperties>
+                <ExcludeFromBuild>false</ExcludeFromBuild>
+                <centralStorage>false</centralStorage>
+                <NamingCoventions>
+                  <enableFolderSpecificSettings></enableFolderSpecificSettings>
+                  <TTCN3ModuleName>.*</TTCN3ModuleName>
+                  <ASN1ModuleName>.*</ASN1ModuleName>
+                  <altstep>as_.*</altstep>
+                  <globalConstant>cg_.*</globalConstant>
+                  <externalConstant>ec_.*</externalConstant>
+                  <function>f_.*</function>
+                  <externalFunction>ef_.*</externalFunction>
+                  <moduleParameter>m.*</moduleParameter>
+                  <globalPort>.*_PT</globalPort>
+                  <globalTemplate>t.*</globalTemplate>
+                  <testcase>tc_.*</testcase>
+                  <globalTimer>T.*</globalTimer>
+                  <type>.*</type>
+                  <group>[A-Z].*</group>
+                  <localConstant>cl.*</localConstant>
+                  <localVariable>vl.*</localVariable>
+                  <localTemplate>t.*</localTemplate>
+                  <localVariableTemplate>vt.*</localVariableTemplate>
+                  <localTimer>TL_.*</localTimer>
+                  <formalParameter>pl_.*</formalParameter>
+                  <componentConstant>c_.*</componentConstant>
+                  <componentVariable>v_.*</componentVariable>
+                  <componentTimer>T_.*</componentTimer>
+                </NamingCoventions>
+              </FolderProperties>
+            </FolderResource>
+          </FolderProperties>
+          <FileProperties>
+            <FileResource>
+              <FilePath>HelloTitan.tpd</FilePath>
+              <FileProperties>
+                <ExcludeFromBuild>false</ExcludeFromBuild>
+              </FileProperties>
+            </FileResource>
+            <FileResource>
+              <FilePath>.project</FilePath>
+              <FileProperties>
+                <ExcludeFromBuild>false</ExcludeFromBuild>
+              </FileProperties>
+            </FileResource>
+            <FileResource>
+              <FilePath>.TITAN_properties</FilePath>
+              <FileProperties>
+                <ExcludeFromBuild>false</ExcludeFromBuild>
+              </FileProperties>
+            </FileResource>
+          </FileProperties>
+        </Configuration>
+      </Configurations>
+    </PackedReferencedProject>
+----
+
+== Important Information, Limitations
+
+We can only save settings related to the TITAN Designer plug-in. The settings of other plug-ins, related to the actual project, needs to be handled by the user separately.*From our point of view data loss and corruption of any kind and magnitude is acceptable, as long as it does not involve TITAN Designer specific settings directly.*
+
+The import is recreating the structure and the content of the project, not the project as a whole. For example: if on the source side there is a resource called X.ttcn located in the file system as Y.ttcn, after saving and loading this information at another location the created project will also have a resource called X.ttcn located in the file system as Y.ttcn. However as the 2 projects are located at different locations in the file system, the reference used to point to this file will be different. In case the file was originally located in the source project, and is now linked in the loaded project, the resource will be decorated accordingly by the platform.
+
+We support eclipse path variables, by saving the location info of the resource using them in a form where this information is available. However as this is an eclipse internal feature outside of our control, command line processing might be limited, or limiting the user. If a required path variable is not defined at the loading side, the resource will be created, but later on, when the platform tries to resolve it, the user might get some kind of error message.
+
+It is also important to know, that we save the location information of all files and folders as Eclipse knows it. By default this means only local file system locations, however Eclipse can be extended with additional plug-ins to support remote operations (like FTP, HTTP, SSH connections) or virtual file systems. If such features are used it is the user’s responsibility to make sure, that the needed plug-ins are available on every machine where the project is to be used. Also when doing command line builds, their build scripts must be prepared to support such features.
+
+In order to be able to recreate the whole project structure all referenced projects have to be saved as well. Otherwise we would not be able to load a missing referenced project.
+
+However once loaded these projects can be used intermixed with other kinds of project inside Eclipse. For example it is possible to refer to them from not yet saved projects.
+
+In case of a referenced project we only store the location where it was loaded from, or where it was saved to first. If it is saved to a new location it must be loaded first, otherwise the changes will be lost. However inside eclipse the project will still contain all the changes.
+
+In the command line referenced projects are identified by the location of their descriptor, in eclipse they are identified by the name of the project. This means, that if a project to be referenced is loaded on a different name, the referencing project will not see it, and at load time will load it again. Also if a different project is loaded at an expected name, it will be used instead of the one being referenced.
+
+In eclipse all information is persisted by the platform, as such the closing and re-opening of the workspace will not change any project information, or come with data loss.
+
+This is our own project information; it can not be expected from external tool vendors to support it. As such exporting/importing a project via the ClearCase Remote Client will not be possible using this format, or might not produce the expected results.
diff --git a/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc b/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..e98f08cdf0ae5fbb6e87ebfb12ac7e7328d4243d
--- /dev/null
+++ b/usrguide/referenceguide/9-xsd_to_ttcn-3_converter.adoc
@@ -0,0 +1,326 @@
+= XSD to TTCN-3 Converter
+:toc:
+
+The XSD to TTCN-3 converter is converting XSD components to TTCN-3 modules according to the ETSI standard ES 201 873-9 (part 9 of the TTCN-3 standard).
+
+The *XSD to TTCN-3 converter* takes as input one or more schemas written in XML Schema and produces one or more TTCN-3 modules containing a set of type definitions and encoding instructions to keep the same XML encoding, in such a way that there is one-to-one correspondence between TTCN-3 values and valid XML instances.
+
+== Terminology
+
+For the purposes of the present section the following definitions apply:
+
+== Schema Component
+
+Schema component is the generic XSD term for the building blocks that comprise the abstract data model of the schema.
+
+=== Schema Document
+
+A schema document contains a collection of schema components, assembled in a _schema_ element information item. The target namespace of the schema document may be defined (specified by the _targetNamespace_ attribute of the _schema_ element) or may be absent (identified by a missing _targetNamespace_ attribute of the _schema_ element). The latter case is handled in this document as a particular case of the target namespace being defined.
+
+=== Target TTCN-3 Module
+
+This is the TTCN-3 module, generated during the conversion, to which the TTCN-3 definition produced by the translation of a given XSD declaration or definition is added.
+
+=== XML Schema
+
+An XML Schema is represented by a set of schema documents forming a complete specification (i.e. all definitions and references are completely defined). The set may be composed of one or more schema documents, and in the latter case identifying one or more target namespaces. More than one schema documents of the set may have the same target namespace.
+
+== Command-line Syntax
+
+The command line syntax of the converter is the following:
+
+[source]
+xsd2ttcn [-ceghmpstVwx] [-f file] [-J file] schema.xsd [-schema.xsd…]
+
+or
+
+[source]
+xsd2ttcn -v
+
+The XSD to TTCN-3 converter takes the name of files containing XML schemas as arguments (usually with the extension .xsd). The converter expects input files to be plain text files.
+
+The following command line options are available (listed in alphabetical order):
+
+* `-c`
++
+Disables the generation of comments derived from top level XML comments and also from XSD annotations and notations. TTCN-3 comments derived from XSD annotations and notations contain the actual character data of the nested XSD 'documentation' or 'appinfo' elements.
+
+* `-e`
++
+Disables the generation of encoding instructions for TTCN-3 types and modules.
+
+* `-f file`
++
+The list of the XSD files will be taken from the given file instead of the command line. The file format is a white-space separated list of XSD files. (Other XSD files in the command line will not be taken into account if this option is used.)
+
+* `-J file`
++
+It has the same effect as the `-f file` flag.
+
+* `-g`
++
+Instructs the converter to generate TTCN-3 code disallowing element substitution.
+
+* `-h`
++
+Instructs the converter to generate TTCN-3 code allowing type substitution.
+
+* `-m`
++
+Instructs the converter to only generate the `UsefulTtcn3Types` and `XSD` predefined modules.
+
+* `-p`
++
+Disables the generation of `UsefulTtcn3Types` and `XSD` predefined modules.
+
+* `-s`
++
+Instructs the converter to parse the given XML schemas and perform only syntactic analysis on them (well-formedness check), but not to generate TTCN-3 output. This option is useful if you do not wish to generate TTCN-3 files when debugging an XML Schema.
+
+* `-t`
++
+Disables the generation of timing information in TTCN-3 modules. These parts are the changing parts of the generated modules. By using this switch it is possible to generate TTCN-3 modules that will be the same even if time and version change.
+
+* `-v`
++
+Prints version and license key information and exits.
+
+* `-V`
++
+Disables status messages, for example, indicates which input file is currently being read, while converting.
+
+* `-w`
++
+Suppresses warnings.
+
+* `-x`
++
+Disables schema validation but generates TTCN-3 modules.
+
+== The Compilation Process for XML Schema
+
+The XSD to TTCN-3 converter requires that each schema file used by the specification must be present in the input. From the input schema files, the converter will build one or possibly more independent TTCN-3 modules. The names of the output files (and the names of the TTCN-3 modules within) are set according to the value of the `targetNamespace` attribute defined in the schema element. Suffixes of TTCN-3 modules are .ttcn.
+
+Whenever a schema file contains an `import` element with the `namespace` attribute, all components (elements, types, groups, etc.) from that namespace are imported into the final XML schema.
+
+NOTE: There can be several schema files having one namespace. All components from that namespace are imported.
+
+The following examples demonstrate how the XSD to TTCN-3 converter assembles input schema files to create the XML Schema.
+
+=== Include
+
+*Example 1-1.* ‘include’ with resolvable schemaLocation attribute
+
+A.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+<xsd:include schemaLocation="B.xsd"/>
+</xsd:schema>
+----
+
+B.xsd:
+
+[source]
+----
+<xsd:schema	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+     ...
+</xsd:schema>
+----
+
+Converter command:
+
+[source]
+xsd2ttcn A.xsd B.xsd
+
+In Example 1-1, the `schemaLocation` attribute indicates a schema file name that is present in the command line. The referenced schema file must be provided and listed in the command line.
+
+=== Import
+
+*Example 1-2.* ‘import’ with resolvable schemaLocation attribute
+
+A.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+		<xsd:import namespace=”http://www.example.org/xsd/B”
+	schemaLocation="B.xsd"/>
+     ...
+</xsd:schema>
+----
+
+B.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd/B"
+	targetNamespace="http://www.example.org/xsd/B">
+     ...
+</xsd:schema>
+----
+
+Converter command:
+
+[source]
+xsd2ttcn A.xsd B.xsd
+
+Example 1-3 shows the use of `import`. Schema `A.xsd` is importing schema `B.xsd`. The `schemaLocation` attribute in schema `A.xsd` is pointing to a schema file which is present on the command line input.
+
+*Example 1-3.* ‘import’ without schemaLocation attribute
+
+A.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+<xsd:import namespace="http://www.example.org/xsd/B"/>
+     ...
+</xsd:schema>
+----
+
+B.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd/B"
+	targetNamespace="http://www.example.org/xsd/B">
+     ...
+</xsd:schema>
+----
+
+B2.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd/B"
+	targetNamespace="http://www.example.org/xsd/B">
+		<xsd:include schemaLocation="http://www.example.org/xsd/B.xsd"/>
+     ...
+</xsd:schema>
+----
+
+Converter command:
+
+[source]
+xsd2ttcn A.xsd B.xsd B2.xsd
+
+An `import` with only `namespace` attribute, imports all the schemas present on the command line having the same targetNamespace as the value specified by the namespace attribute in the import element. In Example 1-3, `A.xsd` contains an `import` element having specified the `namespace` attribute only; the XSD to TTCN-3 converter will import both `B.xsd` and `B2.xsd`, as they have the same targetNamespace as the one defined in the `namespace` attribute of the import element from the schema `A.xsd`.
+
+*Example 1-4.* ‘import’ without namespace attribute
+
+A.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+     <xsd:import schemaLocation="B.xsd"/>
+     ...
+</xsd:schema>
+----
+
+B.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
+     ...
+</xsd:schema>
+----
+
+Converter command:
+
+[source]
+xsd2ttcn A.xsd B.xsd
+
+If the import element specifies the `schemaLocation` attribute only, the imported schema (`B.xsd`) should not be associated with any namespace; otherwise the converter reports an error message.
+
+*Example 1-5.* ‘import’ with no attributes
+
+A.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+     <xsd:import/>
+     ...
+</xsd:schema>
+----
+
+Converter command:
+
+[source]
+xsd2ttcn A.xsd B.xsd C.xsd D.xsd E.xsd F.xsd G.xsd H.xsd
+
+The `import` statement with no attributes specified imports all the schema files in the command line input that have no `targetNamespace` specified. In Example 1-5, if `B.``xsd`, `C.xsd`, and `H.xsd` are not associated with any namespace they are imported in the `A.xsd`.
+
+== Restrictions
+
+Some features of XSD have no equivalent in TTCN-3 or make no sense when translated to the TTCN-3 language. Whenever possible, these features are translated into encoding instructions completing the TTCN-3 code. For any further information about unsupported features see <<13-references.adoc#_4, [4]>>.
+
+Translation of the following XML schema elements is not supported:
+
+`field`, `key`, `keyref`, `selector`, `unique` (identity-constraint definition schema components)
+
+Translation of the following XML schema attributes is not supported:
+
+`final`, `processContents`
+
+The following XML schema attributes are ignored, when they are used as attributes of schema element:
+
+`finalDefault`, `id`, `version`, `xml:lang`
+
+Numeric types are not allowed to be restricted by patterns.
+
+List types are not allowed to be restricted by enumerations or patterns.
+
+All time types restrict year to 4 digits.
+
+Information in the `appinfo` tags are not translated.
+
+== Extensions
+
+The XSD to TTCN-3 Converted has the following non-standard additions to the Using XML Schema with TTCN–3 <<13-references.adoc#_4, [4]>> .
+
+TITAN allows the usage of constants and module parameters in the value of a `defaultForEmpty` encoding instruction. The `xsd2ttcn` tool generates the `defaultForEmpty` encoding instructions with a constant definition as a value to provide reusability of the `defaultForEmpty` values. Only the conversion of `default` and `fixed` attributes of elements is changed.
+
+For example:
+
+A.xsd:
+[source]
+----
+<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+	xmlns="http://www.example.org/xsd"
+	targetNamespace="http://www.example.org/xsd">
+     <xsd:element name="DefStr" type="xsd:string" default="abc"/>
+
+     <xsd:element name="FixStr" type="xsd:string" fixed="def"/>
+</xsd:schema>
+----
+
+The `DefStr` and `FixStr` elements are generated into the following type definitions:
+[source]
+----
+const XSD.String c_defaultForEmpty_1 := "abc";
+
+const XSD.String c_defaultForEmpty_2 := "def";
+
+type XSD.String DefStr
+with {
+  variant "defaultForEmpty as c_defaultForEmpty_1";
+  variant "element";
+};
+
+type XSD.String FixStr (c_defaultForEmpty_2)
+with {
+  variant "defaultForEmpty as c_defaultForEmpty_2";
+  variant "element";
+};
+----
diff --git a/usrguide/referenceguide/ReferenceGuide.adoc b/usrguide/referenceguide/ReferenceGuide.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..80bf5e04435c39a2066d13f1d52c5892f3180540
--- /dev/null
+++ b/usrguide/referenceguide/ReferenceGuide.adoc
@@ -0,0 +1,65 @@
+---
+Author: Jenő Balaskó
+Version: 2/198 17-CRL 113 200/6, Rev. PE1
+Date: 2018-06-18
+
+---
+= Programmers' Technical Reference Guide for the TITAN TTCN-3 Toolset
+:author: Jenő Balaskó
+:revnumber: 2/198 17-CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-18
+:title-logo-image: images/titan_logo.png
+:toc:
+
+ifdef::env-github,backend-html5[]
+image::images/titan_logo.png[alt]
+endif::[]
+
+*Abstract*
+
+This document describes detailed information on writing components of executable test suites for the TITAN TTCN-3 Toolset.
+
+*Copyright*
+
+Copyright (c) 2000-2018 Ericsson Telecom AB. +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution, and is available at +
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html.
+
+*Disclaimer*
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson should have no liability for any error or damage of any kind resulting from the use of this document.
+
+ifdef::env-github,backend-html5[]
+* link:1-about_the_document.adoc[About the document]
+* link:2-ttcn-3_limitations_in_this_version.adoc[TTCN-3 Limitations in this Version]
+* link:3-clarifications_to_the_ttcn-3_standard.adoc[Clarifications to the TTCN-3 Standard]
+* link:4-ttcn3_language_extensions.adoc[TTCN–3 Language Extensions]
+* link:5-supported_asn1_constructs_and_limitations.adoc[Supported ASN.1 Constructs and Limitations]
+* link:6-compiling_ttcn3_and_asn1_modules.adoc[Compiling TTCN–3 and ASN.1 Modules]
+* link:7-the_run-time_configuration_file.adoc[The Run-time Configuration File]
+* link:8-the_titan_project_descriptor_file.adoc[The TITAN Project Descriptor File]
+* link:9-xsd_to_ttcn-3_converter.adoc[XSD to TTCN-3 Converter]
+* link:10-code_coverage_of_ttcn-3_modules.adoc[Code Coverage of TTCN-3 Modules]
+* link:11-the_ttcn-3_debugger.adoc[The TTCN-3 Debugger]
+* link:12-tips_&_troubleshooting.adoc[Tips & Troubleshootings]
+* link:13-references.adoc[References]
+* link:14-abbreviations.adoc[Abbreviations]
+endif::[]
+
+
+ifndef::env-github,backend-html5[]
+include::1-about_the_document.adoc[]
+include::2-ttcn-3_limitations_in_this_version.adoc[]
+include::3-clarifications_to_the_ttcn-3_standard.adoc[]
+include::4-ttcn3_language_extensions.adoc[]
+include::5-supported_asn1_constructs_and_limitations.adoc[]
+include::6-compiling_ttcn3_and_asn1_modules.adoc[]
+include::7-the_run-time_configuration_file.adoc[]
+include::8-the_titan_project_descriptor_file.adoc[]
+include::9-xsd_to_ttcn-3_converter.adoc[]
+include::10-code_coverage_of_ttcn-3_modules.adoc[]
+include::11-the_ttcn-3_debugger.adoc[]
+include::12-tips_&_troubleshooting.adoc[]
+include::13-references.adoc[]
+include::14-abbreviations.adoc[]
+endif::[]
diff --git a/usrguide/referenceguide/images/dualfaced.png b/usrguide/referenceguide/images/dualfaced.png
new file mode 100644
index 0000000000000000000000000000000000000000..739104871c6c56d1991f1fecd23ecc5106a2fa22
Binary files /dev/null and b/usrguide/referenceguide/images/dualfaced.png differ
diff --git a/usrguide/referenceguide/images/projecthierarchy_graph.png b/usrguide/referenceguide/images/projecthierarchy_graph.png
new file mode 100644
index 0000000000000000000000000000000000000000..6edd52c34753187eef29cfa8a1c258abe0352656
Binary files /dev/null and b/usrguide/referenceguide/images/projecthierarchy_graph.png differ
diff --git a/usrguide/referenceguide/images/struct.png b/usrguide/referenceguide/images/struct.png
new file mode 100644
index 0000000000000000000000000000000000000000..73199b67d39b10c1c5843b22053e7aadfd292ba6
Binary files /dev/null and b/usrguide/referenceguide/images/struct.png differ
diff --git a/usrguide/referenceguide/images/titan_logo.png b/usrguide/referenceguide/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..f1e7539e4fbfe31344787adaff8698170bccbf71
Binary files /dev/null and b/usrguide/referenceguide/images/titan_logo.png differ
diff --git a/usrguide/releasenotes.doc b/usrguide/releasenotes.doc
deleted file mode 100644
index d0e47af5fb7d6d93b1aee39b7e95c50e414215f5..0000000000000000000000000000000000000000
Binary files a/usrguide/releasenotes.doc and /dev/null differ
diff --git a/usrguide/releasenotes/images/titan_logo.png b/usrguide/releasenotes/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..8174bacaf66b6a00a4a30eec1ce7ce73719872be
Binary files /dev/null and b/usrguide/releasenotes/images/titan_logo.png differ
diff --git a/usrguide/releasenotes/releasenotes.adoc b/usrguide/releasenotes/releasenotes.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..1da3eaad513c41ff968376f4fa9619370c247c94
--- /dev/null
+++ b/usrguide/releasenotes/releasenotes.adoc
@@ -0,0 +1,3791 @@
+---
+Author: Elemér Lelik
+Version: 109 47-CRL 113 200/6 Uen, Rev. D
+Date: 2018-05-24
+
+---
+= Release Notes for TITAN TTCN-3 Test Executor
+:author: Elemér Lelik
+:revnumber: 109 47-CRL 113 200/6 Uen, Rev. D
+:revdate: 2018-05-24
+:title-logo-image: images/titan_logo.png
+:toc:
+
+ifdef::env-github,backend-html5[]
+image::images/titan_logo.png[alt]
+endif::[]
+
+= Introduction
+
+This document describes changes implemented in TITAN TTCN–3 toolset and the associated Test Port API from the initial TITAN TTCN–3 release through to the current release.
+
+The document is organized as follows: <<what-s-new-in-this-version,What's new in this version?>> gives a short overview about the new features of major releases. <<version-history,Version history>> contains the detailed list of changes, including new functionalities and solved problems, throughout the history of TITAN TTCN–3 toolset. <<Changes-of-Test-Port-API,Changes of Test Port API>> summarizes the changes of the Test Port API in each version.
+
+[[what-s-new-in-this-version]]
+= What’s new in this version?
+
+[[version-6-4-crl-113-200-6-r4a]]
+== Version 6.4 (CRL 113 200/6 R4A)
+
+This release is mainly a corrective release, it introduces no major new features. No backward incompatibilities are to be expected, with maybe one exception we see as a minor risk: the fix for Bug 533767 - RAW encoder ALIGN(right) is working according of specification of ALIGN(left) (and vice versa) for octetstring may induce under some unlikely circumstances an incompatible behavior.
+
+This version has the following new features:
+
+* Implement verdict redirect for 'done' statement
+* `str2float` should handle special float values
+* RT2 record equality
+* `string2ttcn` to filter patterns of visible characters in octetstrings
+* Syntax to bind a variant attribute to multiple encodings
+* TITAN build on Alpine Linux
+* new tpd tag `disableUserInformation`
+* runs on scope reduction (Titanium)
+* Add discarding option to `setstate` operation
+* Notify user if port is not mapped in translation mode
+* Implement reference to port in translation function
+* Implement extendable sequence coding in OER
+* TAG and CROSSTAG for JSON encoder
+
+[[version-6-3-crl-113-200-6-r3a]]
+== Version 6.3 (CRL 113 200/6 R3A)
+
+This version has the following new features:
+
+* new compiler options:
+** e: enforce legacy handling of `encode` and `variant` attributes
+** O: disable OER encoder/decoder functions
+** D: disable user and time information generation in the generated files
+* Support for multiple encodings
+* Implement OER coder in TITAN (with the option to restrict generation of OER codecs)
+* Implement OER negative testing
+* Allowing to start functions with `out` and `inout` formal parameters
+* Enable 'out' parameters for behavior functions in the 'start' operation support for dynamic erroneous attributes
+* Allow translation ports to work as internal ports
+* Allow sending and receiving during translation functions
+* Flag to disable time and user information in the generated files
+* Implement mtc and system clauses in `testcase` and `altstep` and functions
+* Add runtime configuration setting for plain XML and JSON encodings
+* Implement `json2cbor` and `cbor2json`
+* Implement `json2bson` and `bson2json`
+* JSON enc/dec: encoding enumerated values in number form
+* Support `enableLegacyEncoding` in tpd
+* Add the encoding legacy switch to tpd TEXT codec
+* Add the encoding legacy switch to makefilegen
+* Add support for NULL terminated string in RAW
+* RAW: add offset option to `LENGTHTO` attribute
+* RAW: Support also `… bits` syntax in variant attributes
+
+[[version-6-2-crl-113-200-6-r2a]]
+== Version 6.2 (CRL 113 200/6 R2A)
+
+This version has the following new features:
+
+* new compiler options:
+** J: Compiler (and xsd2ttcn, makefilegen) option to read input files list from a text file
+** N: ignore UNTAGGED encoding instruction on top level unions (legacy behavior)
+* support of encvalue/decvalue for ASN.1 types
+* support for implicit call of PER codec external functions
+* implemented: ports with translation capability
+* support for concatenation of templates
+* implemented any from clause and index redirects with the use of the @index modifier (see standard, chapters 21-23)
+* support for dynamic erroneous attributes
+* implemented @fuzzy support
+* support for external functions for decmatch and @decoded
+* no support of Solaris binaries from this release of Titan (older versions of course will continue to support Solaris)
+* makefilegen more restrictive on name attribute of the referenced project
+* makefilegen: remove generated headers dependency from all `.c` `.cc` files
+* (This will revert the following bugs: Bug 499963 - The generated `Makefile` does not make full build when `-j` switch is present ; Bug 512688 - makefilegen: Incorrect `.c` and `.cc` compiling rule )
+* XER: allow `anytype` to be xer enc/decodable
+* JSON `as value` attribute extended for records/sets with one field and for the `anytype`
+* *make archive* button in Eclipse
+* support for `make port` command in Eclipse
+* plug-ins upgraded to Jung 2.1 +
+
+This list is not comprehensive; for details, see document embedded in PRI.
+
+[[version-6-1-crl-113-200-6-r1a]]
+== Version 6.1 (CRL 113 200/6 R1A)
+
+This version has the following new features:
+
+* support for `mctr reconf` command
+* command line debugger
+* advanced code splitting
+* makefilegen capability to handle .xsd files
+* makefilegen and compiler to handle file lists in files(`compiler –J` file or `makefilegen –J` file)
+* new compiler switch for decreasing variant errorlevel from error to warning
+* LTTng logger plug-in
+* encvalue/decvalue for ASN.1 types
+* Titan build for ARM/Raspberry Pi
+* decmatch and @decoded
+* istemplatekind
+* select union
+* @nocase
+* Partial @deterministic support
+* Storing parts of received messages
+
+Incompatibilities:
+
+* warning changed to error when '*' is used for mandatory elements
+* infinity/NaN not allowed at timer start
+* receive handling changed (receive(*) and receive(?) not allowed or restricted) +
+
+The above is not a comprehensive list; for all details , pls. check the document embedded in PRI.
+
+[[version-5-5-crl-113-200-5-r5a]]
+== Version 5.5 (CRL 113 200/5 R5A)
+
+This version has the following new features:
+
+* type substitutionGroup support
+* allow using specific encode attribute strings to identify encode functions
+* `ttcn2json`: extra keyword for restricted "as value" unions
+* makefilegen shall generate `-Y` if tpd orders it
+* user Debug classes
+* negative testing with JSON encoder
+* new compiler switch for decreasing variant errorlevel from error to warning
+* makefilegen supports commenting out `OPENSSL_DIR` based on tpd setting
+* activate emergency logging when a test fails
+* `makefilegen -I` option
+* RAW encoder for universal character string
+* ISO 10646-conformant unicode syntaxes
+* new internal functions: `encvalue2unichar`/`decvalue2unichar`,`any2unistr`
+* `make port` command
+* `checkstate port` operation
+* clang support in Titan
+* Eclipse Designer: implement fast algorithm
+* config parser/editor based on ANTLR 4
+* A number of TRs related to XML, Eclipse, JSON
+* negative and positive conformance tests covering core language part of the standard added
+* new document: statement of compliance covering Core language part of the standard
+* legacy switches:
+** M: allow 'omit' in template value lists (legacy behavior) (artf692717)
+** B: allow selected union field to be unbound (legacy behavior) (artf717563)
+
+[[version-5-4-crl-113-200-5-r4a]]
+== Version 5.4 (CRL 113 200/5 R4A)
+
+This version has the following new features:
+
+* Refactored xsd2ttcn converter
+* Eclipse plug-ins migrated from ANTLR 2 to ANTLR 4.
+* 60 Eclipse plug-in related TRs and CRs implemented.
+* Function calls with subreferences (artf550360)
+* Template(present) accepts complement matching (artf564824)
+* Integer to enumerated (artf590888)
+* Support for IntX in RAW(artf607782)
+* Module parameters can be initialized with module parameters (artf618367)
+* Improved logformat to pretty-print XML and JSON
+
+[[version-5-3-crl-113-200-5-r3a]]
+== Version 5.3 (CRL 113 200/5 R3A)
+
+This version has the following new features:
+
+* TEXT codec to support universal character string (UTF-8).
+* New Junit Logger plugin with extended logging.
+* First version of the coverage/profiler tool.
+* Stack trace displayed in case of segmentation fault or abort().
+* Allow component and default types in module parameters.
+
+[[version-5-2-crl-113-200-5-r2a]]
+== Version 5.2 (CRL 113 200/5 R2A)
+
+This version has the following new features:
+
+* `Makefilegen –Z` option: Faster than the previous recursive linking method , support for dynamic linking, improved make archive
+* `Makefilegen –H` option: support for partial build of hierarchical *.tpd structures.
+* `Ttcn2json` improved ASN.1 handling, including parameterized types
+* TR HS 34398 revoked.
+* As the solution to TR HT 24380 caused performance problems, this was removed from RT1 (the default load test runtime)
+
+[[version-5-1-crl-113-200-5-r1a]]
+== Version 5.1 (CRL 113 200/5 R1A)
+
+This version has the following new features:
+
+* Changes in the assignment of charstring and universal charstring values to permit direct assignment of Unicode characters in editors with UTF-8 support.
+* *Out parameter behavior changed: all out parameters are set to <unbound> at the start of the function. As this could cause incompatible behavior, a compiler option enforcing legacy behavior (`-Y`) was introduced.*
+* A number of deprecated compiler options (`-E`, `-n`, `-N`, `-B`) were removed.
+* New JSON codec variants "as value", "default".
+* TTCN-3 type to JSON schema converter compiler option introduced.
+* Eclipse plug-in improvements.
+* Macro redefinition functionality for TITAN TTCN-3 Test Executor in the `[DEFINE]` section of the .cfg file.
+* Nested concatenation operator `&`= in the `[MODULE_PARAMETERS]` section of the .cfg file
+* Eclipse plug-in package and bundle id’s (including extension point id’s) have been changed due to open sourcing Titan. Their names start with *"org.eclipse.titan"* instead of *"com.ericsson.titan"*
+* Legacy `mctr_gui` and `logbrowser` (based on Qt3 which lacks support in modern Linux versions) removed. The last version can still be obtained from older Titan packages.
+* `Ctags` support removed due to licensing problems (`ctags` files can be obtained from older Titan releases).
+* From this release, usage of 64-bit Cygwin is encouraged. A 32 bit version will not be released.
+* Correction for newer openssl packages that break Titan license validation.
+
+IMPORTANT: Titan releases previous to CRL 113 200/5 R1A will not work if openssl is upgraded beyond the critical level of release; the exact level depends on the Linux platform and version.
+
+* *A correction for TR HT24380 (Error in manipulating dependent inout parameters - a record of and its element) may cause incompatible behavior (see TR for further details). When Titans’ behavior might change compared to previous releases, a warning message- intended to help users to detect sequences of TTCN-3 code that need to be changed- will be displayed.*
+
+[[version-4-2-crl-113-200-4-r2a]]
+== Version 4.2 (CRL 113 200/4 R2A)
+
+This version has the following new features:
+
+* JSON encoding support.
+* Support for various universal character string encodings (UTF-8, UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE).
+* Built-in support for base64 encodings.
+* Java executor API for Titan.
+* Eclipse plug-in improvements.
+* Configurable timestamp in console.
+* Improved behavior in port congestion situations.
+* Superfluous circular warnings for ASN.1 disabled.
+* TEXT encoder debug logging.
+* Several improvements regarding the XML encoding/decoding.
+* T3Doc disabled in the Designer.
+* The asciiart directory emptied to prevent interference with automated usage.
+
+Important notes:
+
+* As the referenced TTCN-3 standards for universal character string encodings and for JSON are not finalized yet, details of these (as in exact function names) may change.
+* The following new keywords have been introduced in this release: `oct2unichar`, `unichar2oct`, `get_stringencoding`, `remove_bom`, `encode_base64`, `decode_base64`
+
+[[version-4-1-crl-113-200-4-r1a]]
+== Version 4.1 (CRL 113 200/4 R1A)
+
+This version has the following new features:
+
+* Catching Dynamic Test case errors – Adds the ability to survive DTEs in TTCN-3 code, for instance in case of long running load tests. Very similar to exception handling used in other languages.
+* Lazy Parameter Evaluation – In formal parameters can be defined to be subject of lazy evaluation: the expression used as actual parameter shall be evaluated only when the formal parameter is used (not at the function call); the evaluation is only done once.
+* Titanium – new Eclipse plugin, a code quality analysis prototype for advanced users, available upon request.
+* Usage statistics - Titan compiler, runtime and Titan Eclipse plug-in usages are collected for statistical purposes.
+* Change of default error behavior for XML encoding from 'Warning' to 'Error' to align with the other Titan encoders.
+* Template Module Parameters - TTCN-3 language extension, module parameters can be both values (standard) and templates (non-standard).
+* `Ttcn2string()` predefined function - returns the parameter’s value in TTCN-3 string representation. `String2ttcn()` predefined function - `Ttcn2string()` predefined function contrariwise.
+
+NOTE: Please make sure that your makefile contains the following part marked with red:
+
+[source, subs="+quotes"]
+----
+SOLARIS8_LIBS =[red]#*-lresolv -lnsl -lsocket*#
+
+LINUX_LIBS = [red]#*-lpthread -lrt*#
+----
+[[version-3-2]]
+== Version 3.2
+
+This version has the following new features:
+
+* Support for distributed build using hierarchical `Makefiles` with new `ttcn3_makefilegen` command line options (`-r`, `-F`).
+* New makefile target "library" is implemented. The pre-compiled objects can be collected to a library archive file(.a or .so), useful when the project hierarchy has rarely changing parts.
+* Extended _.tpd file handling in makefilegen was introduced. `ttcn3_makefilegen` processes the `MakefileSettings` part of the _.tpd files. Benefits: *.tpd files extracted/created with Eclipse can be used in command line and usage of makefilepatch scripts can be hugely reduced or even eliminated.
+* `ORDERED_INCLUDE` in configuration files is implemented; the includes will be strictly ordered.
+* Clean-up after unsuccessful makefilegen execution, `symlinks` are now generated only if no errors were found during *.tpd file processing
+* _.tpd file validation with `ttcn3_makefilegen`: the _.tpd file is validated with a schema that now is part of TITAN (`file $(TTCN3_DIR)/etc/xsd/TPD.xsd` ); validation errors will prevent makefile generation.
+* `Makefilegen`: override the working directory in _.tpd file: the working directory of top level project comes from top level _.tpd file by default; when using the –D switch the working directory will be the current directory.
+* `Makefilegen` support for OSS Nokalva ASN.1 compiler is implemented. `Makefile` generation from *.tpd file enables OSS Nokalva support without custom makefilepatch scripts
+* Integration of DPMG(Diameter Protocol Module Generator) into the TITAN build system.
+* Improved *.tpd file related documentation.
+* Reduced nr of supported gcc versions. Supported versions are: 3.4.6 – 4.7.2
+* Changes in supported platforms: Solaris versions from 5.10 are supported; Cygwin versions from 1.7 are supported. Earlier Solaris and Cygwin versions are not supported
+* Titan Eclipse plugins support Eclipse versions from Eclipse 3.7.2 to Eclipse 4.2
+* Java 1.6 is the minimum requirement
+* A fourth Eclipse plug-in, Titanium, is released as a prototype. Update and maintenance of Titanium will be the responsibility of the Titanium project until further notice. For details pls. see https://ericoll2.internal.ericsson.com/sites/DUCI_SW_Technology/Titanium/default.aspx
+
+[[version-3-1]]
+== Version 3.1
+
+Version 3.1 has the following new features:
+
+* Interface implemented for the TestStatistics tool
+* All from in value list, subset, superset and permutation supported
+* Embedded macro references in the `[DEFINE]` section - runtime (support in command line)
+* Structured macro definitions in the `[DEFINE]` section - runtime (support in command line)
+* Embedding TTCN-3 functions (limited functionality)
+
+[[version-2-2]]
+== Version 2.2
+
+Version 2.2 has the following new features:
+
+* XML encoding is now supported for the hexstring and verdicttype TTCN-3 types
+
+* Transparent functions were introduced to allow easier identification of failing tests in case of SourceInfo := Single.
+
+[[version-2-1]]
+== Version 2.1
+
+Version 2.1 has the following new features:
+
+* The Titan Eclipse Designer’s support for preprocessed TTCN-3 files has been improved.
+* The performance of TEXT decoding has been improved.
+* A logger plugin (JUnitLogger) is now delivered with Titan. It outputs XML files in the same format as JUnit. Using this logger plugin allows integrating of Titan with the Jenkins (Hudson) continuous integration tool.
+* To allow JUnitLogger to receive the necessary information, the Titan Logger API has been slightly changed. Existing logger plugins will need to be rebuilt.
+* In response to a TR (HP88760), the C++ interface of the OBJID class has been changed. The type of the elements in the internal storage of the OBJID class is now specified with a `typedef`, `objid_component`. Code which uses the indexing operators or directly accesses the element storage will need to be rewritten. It is a backward incompatible change and it affects users of the SNMP test port. A new version of the SNMP test port was released (CNL 113 344 R4B) compatible with the new Titan.
+* `ttcn3_makefilegen` has a new flag `–P`, which prints out the list of files found in a given TPD recursively relative to a given directory.
+* TTCN-3 level code coverage was implemented.
+* Text hover for T3Doc in Eclipse was implemented.
+* `mctr_gui`, `ttcn3_logbrowser`, `ctags`, Nedit, XEmacs support is part of the Titan package again.
+
+[[version-1-10]]
+== Version 1.10
+
+Version 1.10 has the following new features:
+
+* Renaming refactoring was implemented in Titan Eclipse Designer. This feature provides TTCN-3 scope-aware renaming of declarations.
+* Selection highlighting was implemented in Titan Eclipse Designer. When a variable name or function name or keyword is selected in the code, all the occurrences of the selected variable name or function name or keyword will be highlighted in the same file.
+* Performance of `log2str()` was improved.
+* Implicit omit support for module parameters was implemented.
+* Append operation (`&=`) for list types in configuration files was implemented.
+* Support of executing testcases with default parameters from command line and configuration file was added.
+* Improved error recovery for the compiler. E.g. it can now stop on the first syntactic error and skip the semantic analysis.
+
+[[version-1-9]]
+== Version 1.9
+
+Version 1.9 has the following new features:
+
+* With the release we have decided to change from the proprietary Titan versioning scheme, to the one used by Ericsson. From now on it will be much easier to decide if a new version is forward, backward compatible with a previous version. The versioning is also supported in the attributes of the modules, with some limitations. We only accept version numbers in 3 formats: R9A, CRL 113 200 R9A and CRL 113 200/1 R9A.
+
+* With this release we removed all QT based GUI parts (`mctr_gui`) and `ctags` from the official Titan releases, as they have been in maintenance phase for the last year. NEdit and XEmacs parts are still available as downloadable components from our download pages.
+
+* The import of imports feature declared in the newest TTCN-3 standard was implemented. This way it is now possible to recursively import import statements from other modules.
+
+* IPv6 support for Titan’s internal communication was implemented. This way Titan is now able to function properly when the MC and PTCs are located on an IPv6 network.
+
+* The makefilegen tool in the command line package is now able to generate `Makefiles` from the information stored in .Tpd project descriptor files.
+
+* It is now possible to find all reference pointing to a given declaration inside eclipse. Finding all references to a definition was implemented as a new kind of search in the Eclipse platform.
+
+* The Executor plug-in will now be able to automatically merge the generated log files after execution.
+
+[[version-1-8]]
+== Version 1.8
+
+Version 1.8 has the following new features:
+
+* The `testcase.stop` operation is now supported, allowing for the users to stop the execution of the actual `testcase` raising a dynamic `testcase` error with a custom explanation text.
+
+* The `ispresent` predefined function was extended to operate on all structured types and fields as described in the 4.3.2 version of the TTCN-3 standard.
+
+* The main features of the LogViewer eclipse feature can no be accessed from the Project Explorer too, so it is no longer required to switch to its custom navigator.
+
+* It is now possible to configure the Executor feature and eclipse executed "launch configurations" to automatically merge the log files that were generated during execution. For the case of several consecutive executions it is now possible to configure the system, to remove the previous log files before a new execution.
+
+* Added the negative testing feature allowing to generate invalid messages, and to send them to the SUT, to observe its reaction.
+* With the help of emergency logging it is now possible to define different behaviors for logging in normal and in emergency situations.
+* The performance of the LogViewer plug-in has been enhanced considerably, to support the processing of arbitrary large log files.
+* Titan is no longer depending on the external Readline package. It has been replaced with Editline, which is now compiled into the delivered packages.
+* A new project description format has been created to support exporting and importing the data of Titan projects in eclipse into a single file.
+* The LogViewer eclipse plug-in was enhanced to work on larger files, with less resource consumption. Also it is now much better integrated with the rest of the toolset.
+
+* Huge increase in the speed of the on-the-fly analysis in the Designer plug-in, with much more efficient memory usage when the incremental parsing option is turned on.
+
+* The Designer now supports build configurations allowing switching between sets of build settings in a consistent way.
+
+* The build action of Eclipse can now be invoked from the command line on two ways. One guaranteeing to build exactly as Eclipse is doing it, and one allowing the user to fine tune all of his settings.
+
+* Support for the launch shortcut feature of eclipse was introduced allowing to create and initialize new launch configurations in an easier way.
+
+* The base of the TTCN-3 standard used to describe the features and limitations of TITAN was changed from version v3.1.1 to v4.1.1
+
+* The build process was enhanced with options for dynamic linking, advanced dependency refreshing, and with splitting the generated code into several files.
+
+* The checking of subtypes in TTCN-3 and ASN.1 modules was enhanced considerably, and the on-the-fly semantic analyzer in the Designer plug-in was brought on the same level as the command line compiler is on.
+
+* Introduced support for the module interface feature, allowing for the user to hide internal parts of a module from the other modules.
+
+* Introduced the `testcasename()` and removed the `sizeoftype()` predefined function in accordance with the standard.
+
+* Support for XML encoding and decoding is introduced, together with a new command line tool that converts XSD files into TTCN-3 modules.
+
+* The `enum2int`, `encode` and `decode` predefined functions were introduced.
+
+* It is now possible to use the `concatenation`, `replace`, `substr`, `lengthof` predefined functions on values of the set of, record of an array types.
+
+* The implicit omit attribute is now supported.
+
+* The TTCN-3 type anytype became supported with some restrictions.
+
+* The runtime was split into two versions: one for function testing where much less code is generated, at the cost of somewhat degraded runtime performance; and one for load testing. Both are compatible with the interfaces of the original runtime.
+
+* Both eclipse plug-ins were enhanced to be able to format and merge log files produced by an execution.
+
+* The on-the-fly semantic analyzer of the Designer plug-in was considerably enhanced.
+
+* The code quality checks done by the on-the-fly in the designer plug-in were extended to detect unused local and module level definitions too.
+
+* The checking of the validity of the license file was introduced in the Designer plug-in, so as to protect it from unauthorized usage.
+
+* The Designer plug-in was enhanced to be able to parse TTCN-3 files in an incremental manner, which should reduce the time required for analyzing a project from a few second, to a few times 10-2 seconds.
+
+* The designer plug-in was extended with its own internal Makefile generator.
+
+[[version-1-7]]
+== Version 1.7
+
+Version 1.7 has the following new features:
+
+* The naming convention of the generated C\++ code has been revised to avoid potential name clashes between definitions. The definitions of each TTCN–3 and ASN.1 module is put into a separate C++ namespace that corresponds to the module name. This eliminates all problems caused by definitions with identical names in different modules. The scope of C++ enum values that represent the values of TTCN–3 and ASN.1 enumerated types became narrower to avoid conflicts if the same element name appears in two different enumerated types.
+
+* Extension (inheritance) of TTCN–3 component types and compatibility between different component types is now supported by the compiler.
+
+* Dual-faced TTCN–3 ports, which can transform the incoming and outgoing messages, were introduced. Using this feature the compiler is capable of automatic generation of TTCN–3 external functions that perform encoding or decoding based on the built-in codecs (RAW, BER, TEXT).
+
+* The Runtime GUI has become a stand-alone product. It is no longer part of the TTCN–3 Executor package.
+
+* The logging functionality has been significantly enhanced. From now the types of events logged can be set using much finer granularity. Using the name of the component in the name of the log files also became possible.
+
+* From now it is possible to assign actual parameters in a parameter list to a specific formal parameter from the formal parameters of the type.
+
+* It is now possible to use assignment notation with array indices.
+
+* The efficiency of connection handling of the Main Controller, the Parallel Test Components and the testports was greatly enhanced.
+
+* The Eclipse Designer plug-in is now building an AST that is structurally equivalent to the on found in the compiler, and stores about the same amount of data. Thus increasing the amount of semantic errors that can be detected on-the-fly without invoking the build system.
+
+* The logging of the `match` operation was made configurable through the `MatchingHints` logging option. If it is set in "Compact" mode (which is the default) the log record will be only a few lines long, instead of a few hundred lines long. In fact if there is only one field mismatching than the log will contain 1 line regardless of the size and structure of the value and template compared.
+
+[[version-1-6]]
+== Version 1.6
+
+Version 1.6 has the following new features:
+
+* The semantic check for the TTCN–3 dynamic behavior descriptions (such as functions, altsteps, testcases) have been implemented, which means that all parts of TTCN–3 modules are now analyzed.
+
+* The compiler generates the entire C++ code from the Abstract Syntax Tree, that is, the output of semantic analysis. This makes it possible to add support for some language constructs and perform code optimization in future versions. These were impossible with the old, parser-based code generator.
+
+* The TTCN–3 parser of the compiler supports recovery from syntax errors. This means the compiler does not stop when a syntax error is detected, but it continues to analyze the input to find more errors. +
+
+NOTE: In some cases it is not possible or worthwhile to recover from a syntax errorfootnote:[For example, the parser may get confused after a missing opening or closing bracket and ignore the rest of input module.].
+
+* Code generation for in-line compound values and templates (including in-line modified templates) is now supported.
+
+* The initializer sequences of constants and non-parameterized templates are ordered automatically so that forward references do not cause dynamic test case errors anymore.
+
+* Support of TTCN–3 language constructs has been enhanced. There is full support of arrays, groups and attributes. Select-case and interleave statements as well as alive PTCs were implemented.
+
+* Text encoding has been introduced.
+
+* Function, altstep and testcase references are supported in TTCN–3 .
+
+* Non-mandatory parameters (i.e. default values for formal parameters) are supported in TTCN–3 .
+
+* Usage of C preprocessor on TTCN–3 modules is allowed.
+
+* The Makefile generator has been significantly enhanced and moved from the compiler to a stand-alone program.
+
+* The syntax of run-time configuration files has been enhanced to allow the use of macros and environment variables. Modularity (i.e. spreading configuration data over several files) is also supported.
+
+[[version-1-5]]
+== Version 1.5
+
+Version 1.5 has the following new features:
+
+* The compiler supports the semantic analysis for all TTCN–3 definitions except the dynamic parts (i.e. functions, altsteps, testcases and control parts). This means that new checking routines were implemented for TTCN–3 subtype constraints, signatures, constants, templates and all definitions within component types.
+
+* The compiler produces user-friendly error messages with file name and line number information and supports error recovery. It displays all error messages found in the input modules.
+
+* The time needed for the compilation of generated C++ code was significantly reduced compared to 1.4.pl0. The saving can be more than 50 % in case of large projects.
+
+* Procedure based TTCN–3 ports and the related communication operations are now supported with enhanced Test Port API.
+
+* The run-time environment provides one unified API for both RAW and BER encoder/decoder functions.
+
+* The internal structure of RAW encoder/decoder functions was significantly revised. This results in faster and more robust operation.
+
+[[version-1-4]]
+== Version 1.4
+
+Version 1.4 has the following new features:
+
+* One integrated compiler for TTCN–3 and ASN.1. This allows the semantic analysis of test suites that import from ASN.1 modules without intermediate files. The command line switches of the previous two compilers were unified.
+
+* The ASN.1 front-end of the compiler was significantly enhanced to handle X.681- X.683 extensions.
+
+* The compiler supports the full semantic analysis of ASN.1 modules and semantic analysis of TTCN–3 type definitions. The output for other TTCN–3 definitions is still generated on the fly without checks.
+
+* The compiler performs automatic reordering in the generated code for TTCN–3 types as well. This means, the generated C\++ code will be always valid even if the type definitions use forward referencing. +
+
+NOTE: The forward referencing problem between TTCN–3 constants and templates is still unsolved. They must be declared in bottom-up order to get a working C++ code.
+
+* The code generation routines of the previous compilers were fully re-used and no significant changes were made in the Base Library in order to preserve the stability of the executable tests.
+
+[[version-1-3]]
+== Version 1.3
+
+Version 1.3 has the following new features:
+
+The Main Controller was completely re-designed in this version, which means the following advantages:
+
+* There are no longer static limits on the number of simultaneously active PTCs.
+
+* Improved and more comfortable command-line interface (with history, command completion, etc.).
+
+* More robust and more efficient handling of large number of test components and/or port connections. Graceful recovery from run-time errors.
+
+* Central configuration file handling and automatic distribution of configuration parameters.
+
+* Version checking in MC to avoid inconsistent ETSes in distributed test environments.
+
+* Faster execution of TTCN–3 configuration operations.
+
+* Explicit control of PTC locations with user-defined constraints in addition to load balancing.
+
+* A lot of Main Controller related bugs were fixed, which caused deadlocks in some situations before.
+
+* TTCN–3 address type is supported by the compiler and the Test Port API.
+
+* Lot of bug fixes in the compilers and the run-time environment.
+
+* Re-organized chapters and clarifications in the user documentation.
+
+[[version-1-2]]
+== Version 1.2
+
+Version 1.2 has the following new features:
+
+* The compiler supports the new, Edition 2 syntax of the TTCN–3 Core Language. The obsolete language elements that were supported in version 1.1 (e.g. named alternatives) are still accepted for backward compatibility, but a warning message is printed.
+
+* The toolset contains a new ASN.1 compiler, which allows the importing of ASN.1 modules into TTCN–3 test suites. Like the TTCN–3 compiler, the ASN.1 compiler translates ASN.1 definitions to C\++ code, which shall be used together with C++ output of TTCN–3 modules.
+
+* The ASN.1 compiler performs a semantic analysis on its input and reports errors instead of generating invalid C++ code.
+
+* The ASN.1 compiler may generate additional functions for the equivalent C++ classes of ASN.1 data types that allow the encoding and decoding of data values according to the Basic Encoding Rules (BER) of ASN.1.
+
+* The TTCN–3 compiler has a new feature that may generate additional functions for TTCN–3 data types for direct (RAW) encoding/decoding of messages. This encoding scheme can be efficiently used for protocols that define the encoding of its PDUs in table-based format. The encoding rules shall be specified in special with attributes of the data types.
+
+* The TTCN–3 compiler and runtime environment provides full support for the use of altsteps and dynamic defaults as specified in the (link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Edition 2 of TTCN–3 standard]). Moreover, for backward compatibility, the obsolete named alts can also be used, even in combination with altsteps and defaults.
+
+* The internal handling of TTCN–3 string types (bitstring, octetstring, charstring) has been improved. The runtime environment can copy string values without memory allocation, which may result in 50% performance improvement in some cases. The Test Port API for these types did not change.
+
+* We have a comprehensive regression test suite for the tool itself. It covers almost all basic and user-defined types, built-in operators, template and behavior constructs of the TTCN–3 language. The tests are run before each release to minimize the remaining bugs.
+
+* Lots of minor improvements and bug fixes.
+
+* The tool is no longer called prototype. Quick help to achieve full backward compatibility with version 1.1. For the meaning of these switches please refer to the respective sections of this document.
+
+* Use the `-u` and `-r` flags for the TTCN–3 compiler.
+
+* Use the `-s` flag for the logformat utility.
+
+* Ignore all warnings of the compiler that refer to obsolete TTCN–3 language elements.
+
+[[version-1-1]]
+== Version 1.1
+
+Version 1.1 has the following new features:
+
+* Support of parallel test execution. Full support of TTCN–3 create, start, stop, running and done operations.
+
+* Support of distributed test execution, which means scalability. Automatic load balancing between the participating computers.
+
+* Platform interoperability, that is, test components running on any of supported platforms can communicate with each other.
+
+* The total number of parallel test components can be safely increased up to 1000, which enables performance (load) testing with the Test Executor.
+
+* Internal communication between TTCN–3 test components is supported in a transparent way. TTCN–3 `connect`, `disconnect`, `map`, `unmap`, `send (…) to` and `receive (…) from` operations are also fully supported.
+
+* Extended Test Port interface.
+
+* Enhanced command line syntax and functionality of the compiler.
+
+* Many bug fixes.
+
+* Improved User Documentation. For more details, please see the next chapters.
+
+[[version-history]]
+= Version history
+
+[[version-crl-113-200-6-r4a]]
+== Version CRL 113 200/6 R4A
+
+Release date: 31st of May 2018
+
+*New features:*
+
+* Implement verdict redirect for `done' statement
+* str2float should handle special float values
+* RT2 record equality
+* string2ttcn to filter patterns of visible characters in octetstrings
+* Syntax to bind a variant attribute to multiple encodings
+* TITAN build on Alpine Linux
+* new tpd tag `disableUserInformation`
+* runs on scope reduction (Titanium)
+* Add discarding option to `setstate` operation
+* Notify user if port is not mapped in translation mode
+* Implement reference to port in translation function
+* Implement extendable sequence coding in OER
+* TAG and CROSSTAG for JSON encoder
+
+[[version-crl-113-200-6-r3a]]
+== Version CRL 113 200/6 R3A
+
+Release date: 17th of November, 2017
+
+*New features:*
+
+* new compiler options:
+** -e: enforce legacy handling of `encode` and `variant` attributes
+** -O: disable OER encoder/decoder functions
+** -D: disable user and time information generation in the generated files
+* Support for multiple encodings
+* Implement OER coder in TITAN (with the option to restrict generation of OER codecs)
+* Implement OER negative testing
+* Allowing to start functions with `out` and `inout` formal parameters
+* Enable `out` parameters for behavior functions in the `start` operation support for dynamic erroneous attributes
+* Allow translation ports to work as internal ports
+* Allow sending and receiving during translation functions
+* Flag to disable time and user information in the generated files
+* Implement mtc and system clauses in testcase and altstep and functions
+* Add runtime configuration setting for plain XML and JSON encodings
+* Implement `json2cbor` and `cbor2json`
+* Implement `json2bson` and `bson2json`
+* JSON enc/dec: encoding enumerated values in number form
+* Support `enableLegacyEncoding` in tpd
+* Add the encoding legacy switch to tpd TEXT codec
+* Add the encoding legacy switch to makefilegen
+* Add support for NULL terminated string in RAW
+* RAW: add offset option to `LENGTHTO` attribute
+* RAW: Support also `… bits` syntax in variant attributes
+
+[[version-crl-113-200-6-r2a]]
+== Version CRL 113 200/6 R2A
+
+Release date: 26th of May, 2017
+
+*New features:*
+
+* new compiler options:
+
+`-J`: Compiler (and `xsd2ttcn`, makefilegen) option to read input files list from a text file
+
+`-N`: ignore UNTAGGED encoding instruction on top level unions (legacy behavior)
+
+* support of encvalue/decvalue for ASN.1 types
+* support for implicit call of PER codec external functions
+* implemented: ports with translation capability
+* support for concatenation of templates
+* implemented 'any from' clause and index redirects with the use of the @index modifier (see standard, chapters 21-23)
+* support for dynamic erroneous attributes
+* implemented @fuzzy support
+* support for external functions for decmatch and @decoded
+* no support of Solaris binaries from this release of Titan (older versions of course will continue to support Solaris)
+* makefilegen more restrictive on name attribute of the referenced project
+* makefilegen: remove generated headers dependency from all `.c` `.cc` files
+
+(This will revert the following bugs:Bug 499963 - The generated Makefile does not make full build when `-j` switch is present ; Bug 512688 - makefilegen: Incorrect `.c` and `.cc` compiling rule )
+
+* XER: allow anytype to be xer enc/decodable
+* JSON `as value` attribute extended for records/sets with one field and for the anytype
+* *make archive* button in Eclipse
+* support for `make port` command in Eclipse
+* plug-ins upgraded to Jung 2.1
+
+[[version-crl-113-200-6-r1a]]
+== Version CRL 113 200/6 R1A
+
+Release date: 18th of November, 2016
+
+*New features:*
+
+* support for `mctr reconf` command
+* command line debugger
+* advanced code splitting
+* makefilegen capability to handle `.xsd` files
+* makefilegen and compiler to handle file lists in files(`compiler –J` file or `makefilegen –J` file)
+* new compiler switch for decreasing variant errorlevel from error to warning
+* LTTng logger plug-in
+* encvalue/decvalue for ASN.1 types
+* Titan build for ARM/Raspberry Pi
+* decmatch and @decoded
+* istemplatekind
+* select union
+* @nocase
+* Partial @deterministic support
+* Storing parts of received messages
+
+Incompatibilities:
+
+* warning changed to error when '*'is used for mandatory elements
+* infinity/NaN not allowed at timer start
+
+receive handling changed (receive(*) and receive(?) not allowed or restricted)
+
+[[version-crl-113-200-5-r5a]]
+== Version CRL 113 200/5 R5A
+
+Release date: 26th of May, 2016
+
+*New features:*
+
+* type substitutionGroup support
+* allow using specific encode attribute strings to identify encode functions
+* `ttcn2json`: extra keyword for restricted "as value" unions
+* makefilegen shall generate `-Y` if tpd orders it
+* user Debug classes
+* negative testing with JSON encoder
+* new compiler switch for decreasing variant errorlevel from error to warning
+* makefilegen supports commenting out OPENSSL_DIR based on tpd setting
+* activate emergency logging when a test fails
+* makefilegen `-I` option
+* RAW encoder for universal character string
+* ISO 10646-conformant unicode syntaxes
+* new internal functions: `encvalue2unichar/decvalue2unichar`,`any2unistr`,
+* `make port` command
+* `checkstate` port operation
+* clang support in Titan
+* Eclipse Designer: implement fast algorithm
+* config parser/editor based on ANTLR 4
+* negative and positive conformance tests covering core language part of the standard added
+* new document: statement of compliance covering Core language part of the standard
+* legacy switches:
+
+-M: allow 'omit' in template value lists (legacy behavior) (artf692717)
+
+-B: allow selected union field to be unbound (legacy behavior) (artf717563)
+
+[[version-crl-113-200-5-r4a]]
+== Version CRL 113 200/5 R4A
+
+Release date: 13th of November, 2015
+
+*New features:*
+
+* Refactored xsd2ttcn converter
+* Eclipse plug-ins migrated from ANTLR 2 to ANTLR 4.
+* 60 Eclipse plug-in related TRs and CRs implemented.
+* Function calls with subreferences (artf550360)
+* Template(present) accepts complement matching (artf564824)
+* Integer to enumerated (artf590888)
+* Support for IntX in RAW (artf607782)
+* Module parameters can be initialized with module parameters (artf618367)
+* Improved logformat to pretty-print XML and JSON
+
+[[version-crl-113-200-5-r3a]]
+== Version CRL 113 200/5 R3A
+
+Release date: 22nd of May, 2015
+
+*New features:*
+
+* TEXT codec to support universal character string (UTF-8).
+* New Junit Logger plugin with extended logging.
+* First version of the coverage/profiler tool.
+* Stack trace displayed in case of segmentation fault or `abort()`.
+* Allow component and default types in module parameters.
+
+[[version-crl-113-200-5-r2a]]
+== Version CRL 113 200/5 R2A
+
+Tentative release date: 19th of March, 2015
+
+*New features:*
+
+* `Makefilegen –Z` option: Faster than the previous recursive linking method , support for dynamic linking, improved make archive
+* `Makefilegen –H` option: support for partial build of hierarchical *.tpd structures.
+* `Ttcn2json` improved ASN.1 handling, including parameterized types
+
+[[version-crl-113-200-5-r1a]]
+== Version CRL 113 200/5 R1A
+
+Tentative release date: 9th of January, 2015
+
+*New features:*
+
+* New JSON codec variants.
+
+* TTCN-3 type to JSON schema converter compiler option introduced.
+
+* Macro redefinition functionality for TITAN TTCN-3 Test Executor in the `[DEFINE]` section of the `.cfg` file.
+
+* Nested concatenation operator `&=` in the `[MODULE_PARAMETERS]` section of the `.cfg` file.
+
+* A number of deprecated compiler options (`-E`, `-n`, `-N`, `-B`) removed.
+
+* Correction for newer openssl packages that break Titan license validation.
+
+IMPORTANT: Titan releases previous to CRL 113 200/5 R1A will not work if openssl is upgraded beyond the critical level of release; the exact level depends on the Linux platform and version.
+
+[[version-crl-113-200-4-r2a]]
+== Version CRL 113 200/4 R2A
+
+Released on the 4th of July, 2014
+
+*New features:*
+
+* JSON encoding support.
+
+* Support for various universal character string encodings (UTF-8, UTF-16, UTF-32).
+
+* Built-in support for base64 encodings.
+
+* Java executor API for Titan.
+
+* Eclipse plug-in improvements.
+
+* Configurable timestamp in console.
+
+* Improved behavior in port congestion situations.
+
+* Superfluous circular warnings for ASN.1 disabled.
+
+* TEXT encoder debug logging.
+
+[[version-crl-113-200-4-r1a]]
+== Version CRL 113 200/4 R1A
+
+Released on Jan. 10, 2014
+
+*New features:*
+
+* Catching Dynamic Test case errors – Adds the ability to survive DTEs in TTCN-3 code, for instance in case of long running load tests. Very similar to exception handling used in other languages.
+* Lazy Parameter Evaluation – In formal parameters can be defined to be subject of lazy evaluation: the expression used as actual parameter shall be evaluated only when the formal parameter is used (not at the function call); the evaluation is only done once.
+* Titanium – new Eclipse plugin, a code quality analysis prototype for advanced users, available upon request.
+* Usage statistics - Titan compiler, runtime and Titan Eclipse plug-in usages are collected for statistical purposes.
+* Change of default error behavior for XML encoding from 'Warning' to 'Error' to align with the other Titan encoders.
+* Template Module Parameters - TTCN-3 language extension, module parameters can be both values (standard) and templates (non-standard).
+* `Ttcn2string()` predefined function - returns the parameter’s value in TTCN-3 string representation. `String2ttcn()` predefined function - `Ttcn2string()` predefined function contrariwise.
+
+[[version-crl-113-200-3-r2a]]
+== Version CRL 113 200/3 R2A
+
+Released on Jul. 5, 2013
+
+*New features:*
+
+* Support for distributed build using hierarchical Makefiles with new `ttcn3_makefilegen` command line options (`-r`, `-F`).
+* New makefile target "library" is implemented. The pre-compiled objects can be collected to a library archive file (.a or .so), useful when the project hierarchy has rarely changing parts.
+* Extended _.tpd file handling in makefilegen was introduced. `ttcn3_makefilegen` processes the MakefileSettings part of the _.tpd files. Benefits: *.tpd files extracted/created with Eclipse can be used in command line and usage of makefilepatch scripts can be hugely reduced or even eliminated.
+* `ORDERED_INCLUDE` in configuration files is implemented; the includes will be strictly ordered.
+* Clean-up after unsuccessful makefilegen execution, symlinks are now generated only if no errors were found during *.tpd file processing
+* _.tpd file validation with `ttcn3_makefilegen`: the _.tpd file is validated with a schema that now is part of TITAN (file `$(TTCN3_DIR)/etc/xsd/TPD.xsd`); validation errors will prevent makefile generation.
+* `Makefilegen`: override the working directory in _.tpd file: the working directory of top level project comes from top level _.tpd file by default; when using the –D switch the working directory will be the current directory.
+* `Makefilegen` support for OSS Nokalva ASN.1 compiler is implemented. Makefile generation from *.tpd file enables OSS Nokalva support without custom makefilepatch scripts
+* Integration of DPMG (Diameter Protocol Module Generator) into the TITAN build system.
+* Improved *.tpd file related documentation.
+* Reduced nr of supported gcc versions. Supported versions are: 3.4.6 – 4.7.2
+* Changes in supported platforms: Solaris versions from 5.10 are supported; Cygwin versions from 1.7 are supported. Earlier Solaris and Cygwin versions are not supported
+* Titan Eclipse plugins support Eclipse versions from Eclipse 3.7.2 to Eclipse 4.2
+* Java 1.6 is the minimum requirement
+* A fourth Eclipse plug-in, Titanium, is released as a prototype. Update and maintenance of Titanium will be the responsibility of the Titanium project until further notice. For details pls. see https://ericoll2.internal.ericsson.com/sites/DUCI_SW_Technology/Titanium/default.aspx
+
+[[version-crl-113-200-3-r1a]]
+== Version CRL 113 200/3 R1A
+
+Released on Jan. 18, 2013
+
+*New features:*
+
+* Interface implemented for the TestStatistics tool
+* All from in value list, subset, superset and permutation supported
+* Embedded macro references in the `[DEFINE]` section - runtime (support in command line)
+* Structured macro definitions in the `[DEFINE]` section - runtime (support in command line)
+* Embedding TTCN-3 functions
+
+[[version-crl-113-200-2-r2a]]
+== Version CRL 113 200/2 R2A
+
+Released on Aug. 31, 2012
+
+*New features:*
+
+XML encoding is now supported for the hexstring and verdicttype TTCN-3 types
+
+Transparent functions were introduced to allow easier identification of failing tests in case of SourceInfo := Single.
+
+[[version-crl-113-200-2-r1a]]
+== Version CRL 113 200/2 R1A
+
+Released on Jun. 27, 2012
+
+*New features:*
+
+* The Titan Eclipse Designer’s support for preprocessed TTCN-3 files has been improved.
+* The performance of TEXT decoding has been improved.
+* A logger plugin (`JUnitLogger`) is now delivered with Titan. It outputs XML files in the same format as JUnit. Using this logger plugin allows integrating of Titan with the Jenkins (Hudson) continuous integration tool.
+* To allow `JUnitLogger` to receive the necessary information, the Titan Logger API has been slightly changed. Existing logger plugins will need to be rebuilt.
+* In response to a TR (HP88760), the C++ interface of the OBJID class has been changed. The type of the elements in the internal storage of the OBJID class is now specified with a `typedef`, `objid_component`. Code which uses the indexing operators or directly accesses the element storage will need to be rewritten. It is a backward incompatible change and it affects users of the SNMP test port. A new version of the SNMP test port was released (CNL 113 344 R4B) compatible with the new Titan.
+* `ttcn3_makefilegen` has a new flag `–P`, which prints out the list of files found in a given TPD recursively relative to a given directory.
+* TTCN-3 level code coverage was implemented.
+* Text hover for T3Doc in Eclipse was implemented.
+* `mctr_gui`, `ttcn3_logbrowser`, `ctags`, Nedit, XEmacs support is part of the Titan package again.
+
+[[version-crl-113-200-1-r10a]]
+== Version CRL 113 200/1 R10A
+
+Released on Apr. 13, 2012
+
+*New features*
+
+* Renaming refactoring was implemented in Titan Eclipse Designer. This feature provides TTCN-3 scope-aware renaming of declarations.
+* Selection highlighting was implemented in Titan Eclipse Designer. When a variable name or function name or keyword is selected in the code, all the occurrences of the selected variable name or function name or keyword will be highlighted in the same file.
+* Performance of `log2str()` was improved.
+* Implicit omit support for module parameters was implemented.
+* Append operation (`&=`) for list types in configuration files was implemented.
+* Support of executing testcases with default parameters from command line and configuration file was added.
+* Improved error recovery for the compiler. E.g. it can now stop on the first syntactic error and skip the semantic analysis.
+
+*Fixed bugs*
+
+* *HP53582* Calling `Remove_Fd_All_Handlers` after `Remove_Fd_Read_Handler` causes error
+* *HP57968* Designer: Running the compiled test without parameters can have unexpected effect
+* *HP49044* Error window popup on any `Exclude/Include` operation in the workspace
+* *HP70610* Reference search: does not find references in for loop header part
+* *HP70600* Reference search: does not find local variables inside alt guard blocks
+* *HP63161* Designer: `IllegalArgumentException` when creating TTCN3 files
+* *HP40284* On-the-fly checker does not accept timer as log argument
+* *HP55541* Single mode launcher runs in an arbitrary directory
+* *HP55521* Eclipse Single Mode Launcher ignores config file
+* *HP43578* Titan: faulty warning printout during compilation, "statement not reachable"
+* *HP43572* Titan: fail to evaluate alt-statement (snapshot) correctly
+* *HP22848* Titan compiler 1.8pl7 fails on Solaris10u10 with a "Too many files open "message.
+* *HP38572* modulepar description in the Titan help is outdated, and not complete
+* *HP39882* On-the fly checker: second imported definition of the same type is not recognized/stored
+* *HP39843* on-the-fly checker: faulty transitive behavior of import
+* *HP19155* UserGuide does not contain information for `-lutil` flag dependency in Makefile
+* *HP38965* On-the-fly semantic checker doesn't accept `sizeof(X)` where X type is record of sth
+
+[[version-crl-113-200-1-r9b]]
+== Version CRL 113 200/1 R9B
+
+Released on Jan. 24, 2012
+
+*Fixed bugs*
+
+* HP36538 was fixed. Incorrect handling of the := assignment in the `[DEFINE]` section of configuration files.
+
+[[version-crl-113-200-1-r9a]]
+== Version CRL 113 200/1 R9A
+
+Released on Dec. 19, 2011
+
+*New features*
+
+* With the release we have decided to change from the proprietary Titan versioning scheme, to the one used by Ericsson. From now on it will be much easier to decide if a new version is forward, backward compatible with a previous version. The versioning is also supported in the attributes of the modules, with some limitations. We only accept version numbers in 3 formats: R9A, CRL 113 200 R9A and CRL 113 200/1 R9A.
+
+* With this release we removed all QT based GUI parts (`mctr_gui`) and `ctags` from the official Titan releases, as they have been in maintenance phase for the last year. NEdit and XEmacs parts are still available as downloadable components from our download pages.
+
+* The import of imports feature declared in the newest TTCN-3 standard was implemented. This way it is now possible to recursively import import statements from other modules.
+
+* IPv6 support for Titan’s internal communication was implemented. This way Titan is now able to function properly when the MC and PTCs are located on an IPv6 network.
+
+* The makefilegen tool in the command line package is now able to generate Makefiles from the information stored in .Tpd project descriptor files.
+
+* It is now possible to find all reference pointing to a given declaration inside eclipse. Finding all references to a definition was implemented as a new kind of search in the Eclipse platform.
+
+* The Executor plug-in will now be able to automatically merge the generated log files after execution.
+
+[[version-1-8-pl7]]
+== Version 1.8.pl7
+
+Released on Oct. 10, 2011
+
+*New features*
+
+* The handling of XSD minOccurs and maxOccurs was updated to follow the upcoming version of the standard (4.3.2) with regards to the handling of optional alternatives of <choice> elements.
+
+* The `testcase.stop` operation is now supported, allowing for the users to stop the execution of the actual testcase raising a dynamic testcase error with a custom explanation text.
+
+* The `ispresent` predefined function was extended to operate on all structured types and fields as described in the 4.3.2 version of the TTCN-3 standard.
+
+* We have re-implemented the `isbound` predefined function in way that is much more performance efficient than the previous one released.
+
+* The `encode_utf8` function of our universal charstring class became part of our public API, so it can now be safely used from C/C++ codes as well.
+
+* The indexing of string templates became supported.
+
+* The main features of the LogViewer eclipse feature can no be accessed from the Project Explorer too, so it is no longer required to switch to its custom navigator.
+
+* It is now possible to configure the Executor feature and eclipse executed "launch configurations" to automatically merge the log files that were generated during execution. For the case of several consecutive executions it is now possible to configure the system, to remove the previous log files before a new execution.
+
+[[version-1-8-pl6]]
+== Version 1.8.pl6
+
+Released on Maj. 30, 2011
+
+*New Features*
+
+* With the new negative testing feature it is possible to generate invalid messages, and to send them to the SUT, to observe its reaction. For example mandatory fields can be left out, new data fields appended, value constraints can be violated.
+
+* Emergency logging allows for the users to define logging behavior for normal and emergency situations. For example one could completely turn off logging for the normal case, while still receiving all needed logs in case of an error.
+
+* The performance of the LogViewer eclipse plug-in was enhanced, so that now it no longer needs to store in memory all data of the log files to be able to display its content, neither in the table based representation nor in the Message Sequence Chart based representation.
+
+* The LogViewer was also extended with support for searching and filtering in Titan generated lo files. Naturally this was also done in a way that blends naturally to the platform, so that users will not have to learn new ways of working.
+
+[[version-1-8-pl5]]
+== Version 1.8.pl5
+
+Released on Dec. 17, 2010
+
+*New Features*
+
+* The TITAN logging architecture has been re-designed to support dynamic configuration and logger plug-ins. Currently only the legacy logger plug-in is supported, which creates backward compatible log files.
+
+* Titan is no longer depending on the external Readline package. It has been replaced with Editline, which is now compiled into the delivered packages.
+
+* A new feature for importing and converting MCTR_GUI project to Eclipse format was added.
+
+* A new project description format has been created to support exporting and importing the data of Titan projects in eclipse into a single file.
+
+* The LogViewer eclipse plug-in was enhanced to work on larger files, with less resource consumption. Also it is now much better integrated with the rest of the toolset.
+
+*Backward incompatibilities*
+
+TR number HM60511 raised our attention to the fact that according to the newest standard it is disallowed to index inside a matching different from "?" (See section 15.6.3 of the standard). This might make existing codes cause dynamic testcase errors at runtime.
+
+[[version-1-8-pl4]]
+== Version 1.8.pl4
+
+Released on Aug. 13, 2010
+
+*New Features*
+
+* Unbound checking has been completely finished according to the standard.
+
+* Huge speed increase and reduced memory usage was achieved in the Designer when the incremental parsing is turned on. Thanks to research efforts done in this field.
+
+[[version-1-8-pl3]]
+== Version 1.8.pl3
+
+Release on July. 02, 2010
+
+*New Features*
+
+* Subtype checking for ASN.1 subtype constructions was implemented for the command line.
+
+* A feature introduced into the 4.1.2 version of the TTCN-3 standard became supported, which allows the declaration and usage of not completely initialized record and record of values as long as the un-initialized element is not referenced directly.
+
+* The `-v` flag of the generated ETS was enhanced to print the version information attached to the modules it was compiled from.
+
+* Single mode execution was enhanced with automatic control part execution in case there is only one control part in the whole testsuite compiled into the ETS. In this case it is not necessary to provide parameters to the ETS when executed.
+
+* Added support for the exclusive range bounds feature of the TTCN-3 standard.
+
+* The name of the testcase will be displayed in the name of the log files of the MTC and HC if configured to be shown. Previously it was only displayed in the PTC’s logs.
+
+* The execution of external script actions will always be logged in the MC, both before the execution and after the execution of the script, to indicate the range where execution has spent its time outside the TITAN generated code.
+
+* The `*ttcn3_start*` script was extended to accept as an optional parameter the ip address it should start its communication on. This is useful when the computer running the tests is connected to several networks at the same time.
+
+* We have started to re-work the logging of the runtime. At this time this should not have any effect noticeable for the users (Other than taking the name "Titan_Logger_Api").
+
+* The subtype checking done on TTCN-3 modules in the previous release of the command line tools, was introduced into the Designer plug-in.
+
+* When a new TITAN project is created as the last step of the wizard it will present the properties page of the new project.
+
+* Launch shortcuts became supported by the Executor plug-in. This enables the user to create and initialize a new or reuse an old Launch Configuration simply by selecting a TITAN project or a configuration file for execution. The new launch configuration will be created and initialized to default values based on the data found on the project (if the Designer is also installed at the same time) and automatically launch the execution.
+
+* It is now possible the exclude certain resources from the build by providing a global list of regular expression, that will be matched on the file names. If any of the expression matches on the name of a file, that file will be excluded from the build.
+
+* It is also possible to configure the Project Explorer view to exclude the excluded resources and the working directory from its shown elements.
+
+* In order to make it more apparent, why a given resource is not part of the build of the project, the exclusion decoration has been enhanced to describe the reason of exclusion.
+
+* It is now possible to configure the Designer plug-in to do naming convention checks on the source code. The conventions can be configured globally, on project level and even on folder level if needed.
+
+* The way of handling the path of the working directory, the generated executable and the makefile updater script was reworked so, that now it is possible to use environmental variables and Eclipse path variables in them too.
+
+* As part of the previous item if the working directory is not present when the build is started, it will be created automatically.
+
+* The Designer was enhanced to collect information about the compiler being configured as the actual build environment. If this setting is changed it will offer to rebuild all of the projects.
+
+* The internal `Makefile` generator of the Designer was enhanced to support building a project without using symbolic links.
+
+* It now supported to have several build configurations defined for each project. This way if one has a "debug" and a "release" configuration, one will be able to switch between the sets of build settings configured for each simply with a few clicks.
+
+* The on-the-fly analysis of the Designer was extended to support delayed semantic checking. When this option is turned on, the on-the-fly semantic analysis will be only invoked when the users saves the file he was working on. While he is editing it only the syntactic checks will run. This mode enhances the performance of the tool, when one is editing framework libraries. However as the semantic database is not updated until the semantic analyzer is run, so will the code completion and other higher level functions also work with somewhat outdated data until the next `save` operation.
+
+* The methods for building a TITAN project were introduced. In the first form the user is able to invoke the build process of Eclipse on a project from the command line, without activating any user interface elements. This mode will build the project on the exact same way it is done when the user is calling it from Eclipse. In the second form an xml file generated with all the data that might be needed to call the TITAN provided makefile generator. Using this form the user is able to create his own scripts, allowing to configure his build process in much finer detail.
+
+[[version-1-8-pl2]]
+== Version 1.8.pl2
+
+Released on Jan. 29, 2010
+
+*New Features*
+
+* The base of the TTCN-3 standard used to describe the features and limitations of TITAN was changed from version v3.1.1 to v4.1.1
+
+* The checking of subtypes in TTCN-3 was improved considerably.
+
+* The semantic checking done by the on-the-fly analyzer in the Designer plug-in was enhanced to be on the same or higher level than present in the command line. A few checks are still missing as a limitation, but if the configurable checks are set several high level bugs/maintenance problems can be detected.
+
+* A version checking mechanism was implemented, where TTCN-3 modules can have version numbers and place version requirements on imported modules, or the TITAN that is used to compile the actual module. Please also note, that as this feature introduces new syntax, earlier TITAN version will report an error for it.
+
+* Support for dynamic linking was introduced into the build system. As in case of incremental modifications, sometimes most of the build time is spent with linking the object files to the final executable, eliminating this step can enhance build times in these cases. However this also means that the dynamic libraries must be transported together with the executable, as it will no longer work in a standalone manner.
+
+* Dependency checking was enhanced in the build system. If using the new way, dependencies will be refreshed only for those modules that have changed, plus the dependencies on gcc are not tracked.
+
+* At build time the compiler can to split the generated code based on the types present in modules. When using the option "type", TITAN will create separate source files for the implementation code of the following types (for each module): sequence, sequence of, set, set of, union. In this case a common header file and a source file holding everything else will also be created. The amount of the generated files increases on this way, but as each of them is smaller the C++ compiler can compile them easier. As there are more files, the build process can run much more efficiently in parallel mode.
+
+* In the Designer plug-in the behavior of the content assistant can be configured by the user. Sorting of the proposals can be configured to be either alphabetical or relevance based. It is also possible to set the common prefixes of proposals, or in the case there was only 1 proposal found the whole proposal should be inserted automatically.
+
+* The automatic insertion of closing apostrophes can also be configured.
+
+* A new action was added to the TITAN actions toolbar, where the xsd2ttcn converter can be invoked on the selected files.
+
+* The syntactic analysis of files was enhanced to become parallel, allowing several times faster operation on machines having several computational cores. For example a dual core processor (commonly present nowadays) will be able to parse two files in parallel.
+
+* The show view menu of the plug-in's default perspectives was extended with links to views commonly present in the perspectives, to help faster navigation.
+
+* In the internal makefile generator the `OPENSSL_DIR` and the `XMLDIR linker` search paths can be disabled, in case the users wish to set their own libraries.
+
+* The reporting of syntax errors in extension attributes became configurable. According to the standard if TITAN is not able to perfectly understand an extension attribute, it should assume that it was meant for a different tool instead of reporting errors, but in this case typos could not be reported to the user.
+
+* In the build process if the working directory does not exist when the build is started, but is set to be contained directly in the root of the project, it will be created automatically. And after the build has finished its contents will always be refreshed automatically, to represent the contents of the actual file system.
+
+* Also in the build process, just before executing the external command the `derived` flag of the working directory will be set automatically (users could set this by hand till now). Setting this flag should mean for other plug-ins, that the contents of this folder should be treated specially, for example they will be left out of search results, and version handling plug-in should also ignore them. This together with the previous feature allows better interoperability with version handling systems, as in this case the working directory no longer needs to be handled by the version handling system in most of the cases.
+
+*Fixed bugs*
+
+Several bugs found both in the xsd2ttcn converter and in the XML encoder/decoder were corrected.
+
+[[version-1-8-pl1]]
+== Version 1.8.pl1
+
+Released on Sept 11, 2009
+
+*New Features*
+
+* Added support for the module interface feature of the TTCN-3 standard (version 4.1). Allowing for the users to assign visibility attributes to definitions.
+
+* Added the `testcasename()` predefined function, which returns the name of the actual testcase or an empty character string.
+
+* The `sizeoftype()` predefined function was removed in accordance with the new TTCN-3 standard.
+
+* Introduced the *FILE* and *BFILE* pre-processor macros, which are replaced with the canonical path of the file, and the name of the file respectively.
+
+* The meaning of the *SCOPE* macro is changed to comply with how it has appeared in the standard. In the new operation it will be replaced with the name of the lowest named basic scope unit in which the macro is used.
+
+*Fixed bugs*
+
+In the Designer plug-in the `extends` extension attribute was parsed incorrectly.
+
+[[version-1-8-pl0]]
+== Version 1.8.pl0
+
+Released on Jun 12, 2009
+
+*New Features*
+
+* Support for XML encoding and decoding is introduced, together with a new command line tool that converts XSD files into TTCN-3 modules.
+
+* The TTCN-3 type Anytype is now supported with some restrictions (see section 4.2 of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer Reference Guide]).
+
+* A new runtime was introduced, that requires much less code to be generated and compiled at the cost of minor decrease in runtime performance. The original runtime is advised to be used in load test scenarios (for this it is called load test runtime), while the new runtime is advised to be used in function test scenarios (for this it is called function test runtime).
+
+* The internal handling of extension attributes was redesigned. The original analysis of these attributes was dependent on the location where they were found (so the same extension was accepted for a function but rejected for a type). This behavior was changed to accept all extension attributes, and only report an error if the attribute is located at the correct place, but contains some semantic errors in itself.
+
+* Several predefined functions were extended to be able to accept templates as parameters (`encode`, `replace`, `substr`).
+
+* Index assignment notation became supported in base templates
+
+* With the addition of the *SCOPE* macro TITAN will now support all TTCN-3 macros defined by the upcoming TTCN-3 standard (version 3.4)
+
+* The speed with which PTC were created was enhanced. Compared to 1.7.pl3 there was a noticeable slowdown in 1.7.pl4. With this improvement PTC should be created faster than in 1.7.pl3.
+
+* All operations are now supported for big integers too.
+
+* The `enum2int` predefined function was implemented
+
+* The `setverdict` predefined function was extended with an optional `charstring` parameter where the users can specify the reason of setting the verdict.
+
+* The implicit omit attribute feature of TTCN-3 was implemented
+
+* A new option was introduced to the compiler to emulate more precisely the warning/error message format of gcc, so to make it integrate with eclipse much better.
+
+* Concatenation of patterns became supported, and from now on patterns can reference templates too.
+
+* The encode, decode predefined functions were implemented.
+
+* `Inout` parameters became supported when functions are started.
+
+* The automatic postfixing of identifiers was introduced, to be able to refer to assignment in ASN.1 modules which have a name that is a keyword in the TTCN-3 language.
+
+* We added support for several features that operate on list types (set of, record of and arrays) including: `concatenation`, `rotation`, `substr`, `replace` and `lengthof`.
+
+* Both Eclipse plug-ins were enhanced with the ability to format and merge log files, in the form of two new actions available in the TITAN menu.
+
+* The executor plug-in was extended to report an error if an executable was set for a launch configuration that is not able to use it (for example an executable compiled for single mode execution can not be executed in parallel mode).
+
+* It is now possible to set, that when the external TITAN action actions are executed on a set of file, they should not process those that are excluded, or are inside excluded folders.
+
+* It became possible to configure what should happen to the markers reported by the compiler, once an on-the-fly analization was executed.
+
+* It is also possible to handle the on-the-fly reported error markers as fatal for build, meaning that as long as the on-the-fly analyzer is reporting an error on a project it will automatically fail the build process. Running the build in such cases would most probably also end up reporting the very same error, but would take a long time to do this.
+
+* It is possible to configure the severity with which the unused function return value problem should be reported.
+
+* The "go to matching bracket" feature was implemented.
+
+* The Designer plug-in was enhanced to detect the number of processing resources possible to use in a build, and as such is able to drive the build process to use several parallel threads. This should result in the decrease of build times, for user who have not yet manually configured their system to do so.
+
+* Introduced the "Treat `.ttcnpp` files as `.ttcn`" feature. If this is enabled the on-the-fly analyzer will try to analyze `.ttcnpp` files as if they were ordinary TTCN-3 files. If the `.ttcnpp` files do not contain any pre-processing macros, but can not be renamed for external reasons, this feature will greatly enhance the user experience. If the files do contain pre-processing macros than enabling this feature will only mean a change of reported errors.
+
+* The Designer plug-in is able to check the validity of the license file, to display the data contained within, and to warn the user a few days before the expiration of the license.
+
+* Enhanced the code quality checks to detect unused definitions and assignments, both on module level and in local scopes. These two scopes has to be separated as unused local definitions always indicate an error, while unused module level definitions might be completely valid in library modules.
+
+* The on-the-fly semantic checker of the Designer plug-in was enhanced considerably.
+
+* The Designer plug-in was enhanced with the ability to incrementally parse TTCN-3 files. This means that after the first time there should be no need to syntactically re-analyze the whole file, but the tool will be able to decrease the amount of data to be re-analyzed to about a few lines. This will not only decrease the time required to re-analyze a project from a few seconds to a few times 10-2 seconds, but will also stop the outline from collapsing after each change in the file.
+
+* The Designer plug-in was extended with an internal makefile generator which uses the data collected by the on-the-fly analyzer. Using this makefiles can not only be generated faster, but the way the makefile is generated can be configured very precisely for each project. When used properly makefiles generated this way should not need to be changes later with makefile updater scripts.
+
+* The on-the-fly analyzer was enhanced to adapt to changes in the file system. So if a new file is added to the project it will be analyzed automatically (earlier a file had to be opened in a supported editor).
+
+*Fixed bugs*
+
+* There was a slowdown in component creation.
+
+* When the `Log match` operation was used, with the matching hints option set to compact, and the mismatch between the value and the template was contained somewhere within a union type, there was actually no information logged by the operation.
+
+* Some special big integers could be encoded or decoded incorrectly in internal communication.
+
+* The `install_handler` function did not handle correctly the case when a user closed a file already having a handler, then opened a file with the very same file descriptor, and tried to install a new handler on it.
+
+[[version-1-7-pl4]]
+== Version 1.7.pl4
+
+Released on October 03, 2008.
+
+*New features*
+
+* Template restrictions from the coming TTCN-3 standard (version 3.3.1) was implemented, allowing a finer specification of templates.
+
+* A new predefined function called `log2str` was introduced. This function works like the original log function, accepting any number of parameters of any type. But the character string created with the concatenation of the parameters is not logged in a file, but returned as a charstring.
+
+* The `replace` predefined function was implemented for all string types.
+
+* Two new keywords from the coming TTCN-3 standard (version 3.3.1) were implemented : break and continue. Using these constructs it will be easier to create simple to understand loop sequences, as the loop condition can be simplified (INCOMPATIBLE).
+
+* The connection handling on both the Main Controller and the Parallel Test Component side was enhanced with using an epoll based mechanism. On the Linux based platforms where this feature is available the users will be able to create as many connections as they want without the need to use a special build of TITAN. The overhead of using thousands of connections compared to using only a few will be almost non-measurable.
+
+* The testport API was also redesigned to support this new feature gained by using the epoll functionality. This way the above mentioned benefits will also be present for the testport writers. For backward compatibility reasons the old interface is kept, meaning that existing testports does not need to be changed. However, using the old interface the testports will not be able to use the new possibility to its fullest.
+
+* The logging of the `match` operation was made configurable through the `MatchingHints` logging option. If it is set in "Compact" mode (which is the default) the log record will be only a few lines long, instead of a few hundred lines long. In fact if there is only one field mismatching than the log will contain 1 line regardless of the size and structure of the value and template compared.
+
+*New features added to the Eclipse plug-ins*
+
+* The semantic data stored by the on-the-fly toolset about TTCN-3 files was increased to be about at the same level as the compiler is. Minor items like storing the 'with attributes' is missing, but other than that every structure is in place. This change was used as base for other features, and will serve as the base of the whole infrastructure we are going to build.
+
+* The on-the-fly semantic checker was enhanced considerably thanks to the increased amount of data available. This allows the fast detections of lost of much more semantic errors, reducing the number of builds the users have to have dramatically. Because full semantic checking was not an aim of this project, and storing data coming from ASN.1 modules is not yet fully supported, the on-the-fly semantic checker can not be complete. The missing parts include areas like the checking of actual parameters, or checking the existence of return statements.
+
+* We have implemented a few code quality checks in the on-the-fly semantic checker, which can detect a few inefficient structures: loops whose entry condition never evaluates to true, value shifting or rotation that actually does not change the value, etc…
+
+* Seeing that now there are projects containing hundreds of modules, we implemented a heuristical check for superfluous import statements. In several cases import relations were declared between modules that did not actually import any definition from each other. This only complicated the understanding of the relations between modules, and put an unnecessary constraint on the incremental build system. This function is not a full functionality, as the on-the-fly semantic check is not complete, it can also not be complete. For this reason the reported severity of such problems was made to be user configurable (it can be set to be an error, or warning, but can also be turned off).
+
+* Even though we have increased the amount of data stored in the memory, we have managed to decrease the overall memory consumption. This is mainly the result of completing the on-the-fly structure for the TTCN-3 modules, as with the whole structure and the better semantic checker in hand we could already implement several optimalizations.
+
+* The jump to definition was also implemented for configuration files. This way it is now possible to jump to definitions inside the configuration files, or to module parameters receiving value in the module parameters section.
+
+* The standard outline view found in Eclipse is now supported for TTCN-3 and ASN.1 modules. This way the user can see an outline of the structure of his module to better understand it, or to find the declaration of definitions much faster. This outline view can not only be used to sort and filter the definitions in a way best suited for the user, but by clicking on an element displayed can be used to instantly navigate to the searched feature.
+
+* An other long existing and wished for feature that we now started to support was what Eclipse calls "project references". In this feature the user can set the dependencies of projects inside Eclipse and from then on both the build processing and the on-the-fly checking of these projects will handle them automatically as dependent projects. This not only allows the partitioning of larger projects into smaller, more concise parts, but also allows to do this in a file system independent manner. For example a new project just existing on the users computer might depend on other projects stored in several different version control system around the world, as long as each project is set up to be working correctly in a standalone manner, they can be connected into much bigger project hierarchies.
+
+* We have introduced two more build levels in the Designer plug-in (level 2.5 and 4.5) which use a heuristic algorithm to decide when the dependency relations of modules needs to be refreshed. Using this feature the users don’t need to choose between the safety of refreshing the dependency hierarchy, and the speed when not doing so. When all of the source code used in the module is handled by the on-the-fly analyzer, the dependency data will be tracked, and the slow external dependency update will only be called if needed. However if not all sources are handled by the on-the-fly analyzer, or the situation is not perfectly clear it will always decide to do the dependency update as otherwise the generated code might not compile correctly.
+
+* We have also implemented a text hover functionality. When the user holds the mouse cursor over a definition for long enough, the information displayed about the definition in code completion, will be displayed in a hover box. This way to find out the type of a definition, the user only needs to hold the mouse above it for a short time, there is no need to actually jump to declaration of the definition.
+
+* Since the on-the-fly toolset started to report syntactic and semantic errors, there was always the problem of different errors being reported. The compiler doing the full semantic checking was doing a much better check, but the on-the-fly toolset was working with the actual state of the file. This resulted in situations where the error marker of the compiler was already outdated, or when the tools had their error markers on single error (detected by both). This was now changed, by making the problems reported by the compiler "outdate" after the user has edited the file. This way the markers will still be there, so the user will be able to find other errors to correct, but the gray color of the outdated markings will indicate that the problem might already have been corrected.
+
+* The `mctr_cli` based execution mode was extended to support automatic execution via tracking the state of the underlying `mctr_cli`, through the command line.
+
+* All executor modes were extended to support the execution of control parts as members of test sets.
+
+* Both the Designer and the Executor Eclipse plug-ins received a graphical refresh. All launch modes, definitions and other outline elements, invocable external actions received their very own distinct icons.
+
+*Fixed bugs*
+
+* The matching of a value containing the omit value, was not handled correctly when the template had a list or a complemented list in the position. The required functionality was not implemented in the generated code, but only the base library.
+
+* When an interleave was embedded in another interleave the generated code was incorrect. If one branch of the embedded interleave was executed it was handled as if all branches of the embedded interleave would have been executed.
+
+* Although TITAN allowed the referencing of global definitions without specifying the module name inside patterns, but not charstring fields of structured constants or using with the module name prefix.
+
+* In certain situations, when a returning function had a too complex branching hierarchy implemented, sometimes the compiler was not reporting paths without a return statement as an error, but as a simple warning. This caused that even though there was no return statement, the code was compiled without problem, and when the execution of the function finished it returned with some memory garbage. This case, when the compiler noticed that something was wrong, but could not decide if it really was wrong or not, was promoted to an error level, to provide safe operation. This is not a backward compatible change, but well written source code, should not need any changes (INCOMPATIBLE).
+
+* The values assigned to templates of signature types were not checked semantically, and so corrupted code was generated.
+
+* In very complex, self-reflexive type structures the semantic checking of the compiler could mark the start function of startable functions as generated, without actually generating it. For this reason the generated code was sometimes erroneous, as the function call could be generated, but the function itself was not.
+
+* The `isvalue` predefined function was working incorrectly for array templates, as the specific functionality was not implemented, and so the general implementation included in the base libraries was executed.
+
+* The code generated for timer array was very inefficient as the name of each timer was generated separately in the code. In case of a timer array containing 20 million timers this resulted in a so big generated source file, that gcc was not able to compile it.
+
+* In the Executor Eclipse plug-in there was no error report if the command used to create the Host Controllers was erroneous. This was simply caused by the fact, that the output appearing in the console was only reported on the user interface one the Host Controller was started, as in this case it was not able to start the contents of the output reading stream were cleared too early.
+
+* The `ttcn3_start` script had no error handling procedure if the error appeared right after trying to execute the `cmtc` command. Which in some cases caused it to keep waiting for the good results indefinitely long, instead of exiting.
+
+* The self component reference was only usable in function which had a runs on clause. This was too restrictive as the standard allows such usage.
+
+* When the system component was used in the connect operation the semantic checker reported a rather un-intuitive error message, which had to be rephrased.
+
+* The `is_bound` function was not generated for some types when the usage of older naming conventions was specified by the user.
+
+* In the Designer Eclipse plug-in the configuration of TITAN to use default values as option always only implemented in the main build system, but other external operations like the testport generation was not configurable with this option.
+
+* In some case the On-the-fly parser of the Designer plug-in was reporting syntactic error for syntactically correct named parameter constructs as a result of an incorrect grammar rule.
+
+* The compiler was not checking the compatibility of runs on components if the function with incompatible runs on component was called inside a log statement inside a function. This check was simply not implemented for function calls placed in log statements.
+
+* Because of a minor bug the pattern #(,1) was not accepted directly in template patterns.
+
+* Because of an error in the Executor Eclipse plug-in, in single mode execution when the input configuration file was syntactically erroneous it was not reported, and the execution was not stopped, but temporary configuration file was generated erroneously.
+
+* TITAN, as a nice feature, was implicitly concatenating character strings which turned out to cause problem, as in case of list of strings, the missing of comma sign was not reported as a syntax error, but the list was created with less elements (as the string where the comma was missing were concatenated).
+
+* We have found an interoperability problem related to the ClearCase Remote Client in the Designer Eclipse plug-in. As the problem was found to be on the side of the Remote Client an error report was sent to IBM, and a workaround was implemented in our plug-in.
+
+[[version-1-7-pl3]]
+== Version 1.7.pl3
+
+Released on March 10, 2008.
+
+*New features*
+
+* When calling a function, altstep or testcase it is now possible to provide the actual parameters in a different order than the formal parameters were defined. If the each actual parameter exactly qualify to which formal parameter they should be assigned to.
+* Now it is possible to use array indices within assignment notations.
+* A new flag `-d` was introduced for the compiler to enhance interoperability with other implementations of the ASN.1 standard. When this option is provided the compiler will handle fields of set and sequence types having a default value as if they were optional. This means that these fields will be omitted when encoded, and will not be expected at decode time.
+* A new predefined function called `isvalue` was introduced. Using this feature it is now possible to check if a template can be converted to a value with the `valueof` operation or not. As calling `valueof` on a template which did not contain an exact value resulted in a dynamic testcase error.
+* Concatenation of binary strings is now possible in the runtime configuration file.
+* To further enhance the logging utilities it is now able to split huge logfiles at the time of generation based on options set by the user in the runtime configuration file.
+
+*New features added to the Eclipse plugins:*
+
+* An on-the-fly parser for runtime configuration files.
+* A basic on-the-fly parser for ASN.1 .
+* Low level semantic code analysis for TTCN-3 and ASN.1 modules.
+* The "Jump to definition" and "Open declaration" features were enhanced to work in ASN.1 modules too. Now it is also possible to cross the borders between the 2 module kinds, allowing for the user to jump to a declaration in an ASN.1 module, from a TTCN-3 module where it is used.
+* The runtime configuration file editor was enhanced to offer not only textual editing possibilities for the user, but also some graphical editing functionalites. The graphical pages of the configuration file editor were organized according the sections in the file format, trying to provide a clean separation for informations that are not directly related. Each graphical page was designed to simplify the most common operations, for example on the logging page the user can change the logging settings with simply selecting the categories they wish to be logged out, or deselecting the ones that should be left out.
+* The icons of the different supported file formats, and callable command line operations were re-designed, to provide a much better user interface, where the users can find the oprations they wish to invoke simplier and faster.
+
+*Fixed bugs*
+
+When a constant universal charstring value was assigned to a charstring the compiler did the assignment with reporting any problems, however if there was a complex expression resulting in a universal charatring on the right side the compiler reported a semantic error. This inconsistent state was resolved by reporting a warning for the first case too. This is only done to give some time to the user to make the necessary changes before an error will be reported for that code, making it un-compilable.
+
+[[version-1-7-pl2]]
+== Version 1.7.pl2
+
+NOTE: This is was an intermediate release, required by the TitanSim project.
+
+Released on November 30, 2007.
+
+*New features*
+
+* A new function and altstep reference type was introduced called "runs on references". This allows the reference touse resources defined by the runs on clause of the actual function or altstep, when it is called using the apply statement.
+
+[[version-1-7-pl1]]
+== Version 1.7.pl1
+
+NOTE: This is not a released version, only a delivery, delivered on August 27, 2007.
+
+*New features*
+
+T* he log event subtypes were introduced, allowing finer log settings.
+
+* Type mapping rule discard has been introduced in dual-faced ports, which allows conditional or unconditional dropping of messages while translating them between the external and internal interfaces.
+
+* Automatically generated TTCN–3 external functions used for encoding and decoding have been enhanced: The functions generate debug printouts with event type DEBUG ENCDEC before and after invoking the codecs. The decoder functions report a warning if superfluous data remained in the buffer after successful decoding.
+
+* The translation of TTCN–3 regular expressions has been significantly enhanced in the compiler and the run-time environment: The character sets are verified and duplicate members are reported. Support of quadruple notation has been added for character codes between \q_{_0,0,0,1_} and \q_{_0,0,0,255_}. The generated POSIX equivalent is optimized to be shorter and simpler. +
+
+NOTE: TTCN–3 regular expressions are used by the matching mechanism pattern in templates of type charstring, the arguments of predefined function `regexp()` and the attributes of TEXT encoding.
+
+* Non-standard additional predefined function `unichar2char()` has been introduced.
+
+* The run-time realization of TTCN–3 additional predefined functions has been enhanced. New polymorphic versions have been introduced to eliminate the conversion of arguments in C++. The error messages generated by these functions have been rephrased to make the reason of the failure easier to understand.
+
+* Utility `*ttcn3 logformat*` supports the indentation depth of zero. Option `-i` 0 eliminates the previous indentation made in the file so that each log entry is printed in one line.
+
+* The semantic analyzer of the compiler checks the TTCN–3 and ASN.1 modules in bottom-up order, which means the analysis of a module is started only after the checking of all imported modules is completed (except in case of circular imports). This new checking strategy results in shorter and more straightforward error messages because the irrelevant context information is not printed anymore. The original algorithm processed the modules in the same order as they were given in the command line. So when the first module was referring to a faulty definition in a module given later the context information of the error message pointed to both modules although there was no error in the first module.
+
+* The meaning of metacharacter `%n` within the log file name skeletons has been extended. It is substituted with the string `_MTC_` in single mode and on the MTC, with string `_HC_` on the HCs or with the name of the PTC if it was given one when it was created. Formerly, this metacharacter had useful value only on PTCs.
+
+* The status of module parameter values given without module name in section `[MODULE PARAMETERS]` of the configuration file has been clarified. The ambiguity was introduced in the previous release, 1.7.pl0, in which the new C++ naming rules allow the definition of module parameters with identical names in different modules. If the module name is omitted or substituted with an asterisk character (*) in the configuration file the value will be set in all modules that have parameter with the given name. Error occurs if none of the modules contain module parameter with the that name. Unless the module name is given in the configuration file the run-time environment assumes that all identically named parameters have the same type.
+
+* The following enhancements have been made on the GUI:
+
+* The speed of automatic refresh operations on the execution window has been significantly increased. In former versions the window was refreshed after every change in the TTCN–3 test configuration, which could lead to significant delays in the GUI if the test configuration has changed too frequently (like in case of complex load test setups).
+
+New features added to the Eclipse plugins:
+
+* Code completion:
+
+* Became type structure sensitive in TTCN–3 modules, allowing it to complete the fields of structured types in references.
+
+* Became scope sensitve in TTCN–3 modules offering only proposals which could be used in the actual scope.
+
+* Was enhanced with pre-defined skeletons in `asn1`, `ttcn`, `ttcnpp`, `ttcnin` files.
+
+* Was enhanced with type specific, dynamically generated skeletons in ttcn files (for example function calls can be completed with the short version of the formal parameter list of the function).
+
+* Wizards were introduced to help the creation of TTCN–3 , ASN.1 modules and configuration files.
+
+* Changes done to a document in one editor are reflected in every other editor too, where the same document is being edited.
+
+* Syntax coloring changes no longer need to be applied one by one.
+
+* The help system of the Designer and the Executor plugins was separated.
+
+*Fixed bugs*
+
+* The generated C\++ equivalent of enumerated types could not be compiled with GCC 2.95.x if the new naming rules were in effect. The problem was caused by the C++ enum type that was declared within the scope of the C++ class representing the values of the enumerated type. The old version of GCC accepts the casting operator only if the name of the embedded enum type is prefixed with the name of the C++ class.
+
+* When logging the matching procedure of optional fields in record and set types the field of the value and the template was printed in the wrong order if the field of the value was set to omit. Always the value must be printed first during matching, which corresponds to the order of arguments in built-in operation `match()`.
+
+* The compiler generated wrong C\++ code for repeat statements found within the response and exception handling parts of call statements. If the call statement was embedded into an altstep the generated code assumed that the repeat statement refers to the whole altstep. Otherwise the generated C++ code was erroneous, it could not be compiled.
+
+* The copy constructor of class TTCN Buffer did not work properly in the Base Library. This class is used by the common API for encoding and decoding. The defective copy constructor did not copy the length indicator field of the buffer to the newly created object thus some manually written codec functions and Test Ports reported mysterious internal error messages.
+
+* The semantic analyzer of the compiler reported false error messages while checking procedure-based operations `catch(timeout)`. Although this operation is applicable after calling any blocking signature the compiler accepted `catch(timeout)` only if the regular catch operation was allowed (i.e. the corresponding signature had at least one exception type). Of course, the operation `catch(timeout)` is allowed within the response and exception handling parts of call operations and only if the respective operation has a call timer.
+
+* The compiler generated erroneous C\++ code for the construct _value returning done_ if the new naming rules were in effect. The invoked C++ function was not prefixed with the appropriate namespace if the done statement and the return type of the PTC behavior function (having attribute with _{extension "done" }_) were defined in different modules.
+
+* Erroneous circular TTCN–3 type references pointing back to themselves with field or array sub-references (like type T[0].f1 T;) caused infinite recursion in the semantic analyzer and consequently the compiler crashed with segmentation fault.
+
+* The utility `*ttcn3 logbrowser*` mis-interpreted some log entries. If the text of the log entry contained only a small integer number (like 1 or 2) the log browser presented the number as an erroneous component reference and left the field for the event text empty.
+
+* The generated C\++ code related to TTCN–3 expressions comparing optional fields of record and set types was erroneous in some cases. If two optional fields were tested for inequality the generated code could not be compiled with GCC 4.0.x or later. GCC complained about ambiguous overloading of operators. Furthermore, if an optional field containing a value of type charstring was compared with an optional field containing universal charstring the C++ code caused infinite recursion at runtime. All these errors were related to the instantiation of template member functions of C++ template classes.
+
+* The semantic analyzer of the compiler did not check properly the value list and value range (i.e. character range) type restrictions of type universal charstring. Even some basic checks, such as the verification of range boundaries and overlapping, were skipped in previous versions.
+
+* The compiler generated incomplete C++ type descriptor structures for some TTCN–3 types, which could lead to segmentation fault in the run-time environment during encoding or decoding using the built-in RAW or TEXT codecs. For example, if a type alias was created for type charstring with a fixed length restriction, but without coding attributes then the type descriptor of the aliased type contained information only for RAW encoding. The information about TEXT coding was not inherited from the built-in type charstring. If this aliased type was embedded into a structured type with appropriate TEXT coding attributes the TEXT encoder and decoder operations on the structured type would crash with segmentation fault.
+
+* The compiler generated erroneous C++ initializers for literal values of type charstring containing NUL characters (i.e. characters with character code zero). The length of the strings was set correctly in the run-time environment, but the characters of the string contained memory garbage after the first NUL character.
+
+* The algorithm that translates TTCN–3 regular expressions to their POSIX equivalents handled the TTCN–3 character set expressions incorrectly. Neither individual characters nor character ranges of the set were mapped properly (using the appropriate escape sequences) to POSIX. The resulting POSIX character set was sometimes faulty or had different meaning than the original TTCN–3 set. This problem affected the matching mechanism pattern in templates of type charstring, the arguments of predefined function `regexp()` and the attributes of TEXT encoding in both the compiler and the run-time environment.
+
+* The TTCN–3 test components could terminate with a dynamic test case error if their communication partner terminated while a `disconnect` operation was in progress on an existing port connection. If sending an internal protocol message requesting the connection termination fails on a socket connection only a warning message is displayed rather than an error. This change makes the shutdown process of complex test configurations more robust.
+
+* Utility `*ttcn3 logmerge*` could crash with a segmentation fault when it was run on several input files and one of them contained only one log entry.
+
+* The semantic analyzer of the compiler could report false error messages complaining about missing return statements within functions having return type. This was the case, for instance, if the function contained an infinite loop without return statement realized using a goto statement. Such code fragments should not be considered faulty.
+
+* The RAWcodec of the run-time environment crashed with a segmentation fault while decoding an integer value encoded on more than 16 octets (i.e. the value of attribute `FIELDLENGTH` was greater than 128).
+
+* The semantic checker algorithm that verified attribute user of dual-faced port types was incomplete. The compiler did not report any error if a source type of an in or out mapping was not present on the message list of the respective port type.
+
+* The decode type mapping rules of dual-faced port types did not consider the associated `errorbehavior` attribute. The reason was that the C++ equivalents of the errorbehavior settings were left out from the generated code by mistake.
+
+* The default argument of the constructor (NULL pointer) was missing from the generated C\++ classes implementing TTCN–3 ports if the respective TTCN–3 port type had attribute provider or user. Because of this the compilation of the generated C++ code failed when a TTCN–3 port array was created from the above port types. The C++ template class that realizes port arrays tried to instantiate its elements using the default constructor (i.e. without parameters).
+
+* The command line version of the Main Controller (i.e. `mctr cli`) crashed with a segmentation fault after encountering the expansion of an invalid macro to a host name (e.g. $_{NonExistentMacro, hostname}_) in the configuration file. The crash occurred after reporting the appropriate error message. The reason was an uninitialized variable.
+
+* The semantic analyzer routines of the compiler that check the correctness of the RAW and TEXT codec attributes did not work properly in some very rare cases. The problem occurred when a field of a structured type was a referenced type pointing to another referenced type, which was an alias of a built-in type and neither types had encoding attributes. After checking this construct the internal memory structures of the compiler remained in an invalid state, which caused an internal fatal error during code generation.
+
+* The error message of the compiler pointed to the wrong location in the source file if a (named) TTCN–3 constant was assigned to a variable and the actual value of the constant violated the subtype restrictions in the type of the variable. In this case the error message pointed to the literal value of the constant (which was apparently correct) rather than the faulty variable assignment.
+
+* The Base Library lacked the C\++ functions and operators that can implicitly convert a template (or template variable) of type charstring to a template of type universal charstring by translating the embedded matching mechanisms character-by-character. TTCN–3 modules using such constructs were accepted by the compiler, but the generated C++ code could not be compiled due to ambiguous overloads of operators. To resolve the problem a new constructor and assignment operator have been added to class UNIVERSAL CHARSTRING template, both taking CHARSTRING template as argument.
+
+* Although the ASN.1 front-end of the compiler ignores all type constraints except the table and component relation constraints of open types, some valid type constraints were rejected by the parser. False syntax errors were generated, for instance, if a single value constraint contained values within brackets (such as `SEQUENCE` or `SET` values) or a permitted alphabet constraint (denoted by keyword FROM) contained single characters using the quadruple notation.
+
+* The following bugs have been fixed in the GUI:
+
+* Configuration file macros were not substituted in sections that are processed locally (such as `[MAIN CONTROLLER]`, `[GROUPS]` and `[COMPONENTS]`). Macro substitution was inefficient in the rest of the sections.
+
+* Fixed bugs in the Eclipse plugins:
+
+* Coloring of multi line comments in ttcn3 files could get corrupted. This was corrected by using the on-the-fly parser created intervals to identify its exact location.
+
+* Faster operations in general.
+
+* Calling errors of the native win32 commands corrected.
+
+[[version-1-7-pl0]]
+== Version 1.7.pl0
+
+Released on March 9, 2007.
+
+*New features*
+
+* The naming convention of the generated C\++ code has been revised to avoid name clashes between different definitions. The use of a C++ namespace for each module eliminates all compilation problems caused by definitions with the same identifier in different modules. The proper scoping of enumerated values excludes the name conflict between two enumerated types and makes the enum-hack option unnecessary and obsolete.
+
+* Extensibility (inheritance) of TTCN–3 component types and type compatibility between different component types is now supported by the compiler.
+
+* The compiler can generate TTCN–3 external functions automatically in C\++ to perform encoding and decoding of message types using the built-in codecs of the runtime environments. C++ programming is no longer necessary to create a complete and working protocol module. All options of the encoding shall be given in TTCN–3 as attributes of the external functions.
+
+* Dual-faced TTCN–3 ports are now supported. Such ports have two different interfaces: internal (used when sending and receiving messages) and external (used when connecting the port to another test component or mapping to a system port). The handling of incoming and outgoing messages shall be specified using type mapping rules in the attributes of port types.
+
+* Code generation for mixed port types is now supported.
+
+* The expect script `*ttcn3 start*` has been improved:
+
+* The script uses a built-in function to obtain the name of the computer rather than launching the command hostname, which results in faster and more reliable operation.
+
+* Zombie processes are no longer left during the script run.
+
+* Error handling has been enhanced, which avoids deadlocks in various error situations.
+
+* It is no longer required to have identical names of formal parameters to the corresponding function, altstep or testcase type for the function, altstep or testcase referenced in a `refers` operation. Only the direction and the type of parameters must be identical. Different parameter names will generate warnings rather than errors.
+
+* Formerly, the semantic analyzer of the compiler reported two consecutive error messages when it found duplicate definitions with the same identifier. Now it reports a single error message because this is a single fault. The location of the clashing definition is given as a note following the error message. Hence the counter printed at the end of compiler run shows a more realistic information about the number of errors.
+
+* The visualization of template matching in the log files had contained the corresponding value and template fields in a misleading order. In built-in operation match of TTCN–3 the first argument is a value and the second is a template, but in the log printout the fields of the template was given first followed by the value. The order of the log printout has been reversed to be consistent with the TTCN–3 syntax.
+
+* The status of TTCN–3 special type address was clarified.
+
+* The BER decoding of ASN.1 type UTF8String was significantly enhanced. The newly written decoder is able to detect all possible violations of the UTF-8 character encoding and to report appropriate error messages. Error recovery is also supported, that is, an incorrectly encoded character will not prevent the decoder from processing the rest of the string. The former algorithm caused buffer over-indexing, which led to non-deterministic results, if one or more octets were missing from the end of the received octet stream.
+
+* The compiler supports the latest official TTCN–3 language syntax according to the BNF published in version 3.2.1 of link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language]. The only significant change is that the new BNF allows multiple external constant definitions with the same type separated by commas.
+
+* The Runtime GUI is no longer part of the TTCN–3 Executor package. It has become a stand-alone product with number CNL 113 437 and its own version numbering.
+
+* The following enhancements have been made on the GUI:
+
+* A red 'X' is drawn on the symlink icons of files in the project if the related symlink does not exist, but it should.
+
+* Excluded files are not passed to the `Makefile` generator, and will not be present in the `Makefile`.
+
+*Fixed bugs*
+
+* The compiler reported an error if the argument of TTCN–3 built-in operation `ischosen` was a value or template of an ASN.1 open type. ASN.1 open types should be visible from TTCN–3 as union types.
+
+* The compiler generated wrong C++ code for port operation `getreply` if the corresponding signature had return type, but the operation did not specify a value match. The lack of value match means that all possible incoming return values should be accepted by the operation. However, when the referred signature template was nonparameterized the generated code matched the return value against the value match specified in the previous `getreply` operation referring to the same signature template.
+
+* The compiler aborted with an internal fatal error during semantic analysis when a function or altstep type had a timer formal parameter.
+
+* The error message of the run-time environment was misleading when trying to convert a record or set value containing an unbound optional field to a template of the corresponding type because the message referred to built-in function `ispresent`. The reason was that the internal realization of the value to template conversion was based on `ispresent`. The conversion algorithm has been rewritten to give a more straightforward error message.
+
+* The semantic analyzer of the compiler did not verify the compatibility of component types when checking the component references returned by built-in operations `create`, `self`, `mtc` and `system`. For example the compiler was unable to detect if a component reference returned by create was assigned to a variable of a different component type. The C++ code generated from invalid input could be compiled to executable, but the component operations following the erroneous statement could result in run-time errors.
+
+* The implementation of TTCN–3 operation any `component.done` was incorrect in the Main Controller. The MC gave false positive answer to the MTC if there was a PTC that was just created, but not yet started.
+
+* The `Makefile` generator program `*ttcn3 makefilegen*` could not cope with binary files (object files, executable programs, etc.) given as command line arguments. The program entered an infinite loop while trying to determine whether the file contains a valid TTCN–3 or ASN.1 module.
+
+* The configuration file parser of the run-time environment handled string values concatenated from two or more fragments incorrectly in sections `[LOGGING]`, `[TESTPORT PARAMETERS]` and `[EXTERNAL COMMANDS]`. In most cases the entire string was simply substituted with the first fragment and the rest was ignored. Such fragmented strings are used mostly in combination with macro substitution when only parts of the string come from macros.
+
+* The Main Controller printed a strange error message complaining about unexpected message STOPPED KILLED when a PTC terminated because of an error while it was executing a blocking TTCN–3 operation. A typical example for this situation is when a PTC is trying to map its own port to a system port, but the operation fails in the test port for some reasons.
+
+* The compiler crashed with a segmentation fault during semantic analysis while checking the definitions of an erroneous group. This could happen if a group contained valid definitions, but the end of the group (i.e. the closing bracket) was missing from the input file. The syntax error related to the faulty group was reported properly during parsing.
+
+* Unsuccessful BER decoding of ASN.1 string types could lead to memory corruption causing segmentation faults in the run-time environment. The problem occurred if the string variable that was passed to the decoder to store the result had a previously assigned value. First the memory buffer carrying the previous value was deallocated, but if the decoding failed the variable was not updated properly. Thus further operations on the variable or the destructor tried to deallocate the same memory area again.
+
+* The run-time environment created wrong BER encoding for negative INTEGER and ENUMERATED values that were smaller than -8388608. In case of such numbers the size of the value part was set to 4 octets correctly, but the encoded value represented a number that was greater than necessary by one (-8388608 instead of -8388609, -8388609 instead of -8388610, and so on). In case of input -8388609 the encoded value was invalid (overlong) according to the rules of CER and DER.
+
+* Matching of TTCN–3 regular expressions did not work on Cello Packet Platform in parallel mode. The routines converting TTCN–3 regular expressions to their POSIX equivalents referred to macros stdin and stdout, which caused restart of the operating system. The problem occurred when matching templates of type charstring containing matching mechanism pattern or using the built-in predefined function `regexp()`. Executable test suites built in single mode were not affected by this fault.
+
+* The following bug fixes have been made on the GUI:
+
+* The GUI no longer tries to create symlinks for non-existing files in the project. This behavior resulted in creating symlinks in the working directory pointing to itself.
+
+* Crash fixed when loading a FileGroup from file when no other FileGroup was present in the project.
+
+[[version-1-6-pl5]]
+== Version 1.6.pl5
+
+Released on November 27, 2006.
+
+*New features*
+
+* The meaning of TTCN–3 subtype constraints in nested record of and set of types has been clarified. Formerly the type restrictions were attached canonically to the outermost type, but now they belong to the innermost type embedded in record of or set of construct.
+
+* The TTCN–3 language mode of utility `ctags` has been enhanced. Source line markers in preprocessed TTCN–3 modules are now recognized and interpreted. Recognition of the following TTCN–3 language elements has been corrected or improved: constants, variables, templates, template variables, enumerated types, nested type definitions.
+
+* The subroutine of utility `*ttcn3 logmerge*` that extracts the test component identifier from the name of the log file has been improved. The new algorithm works better when a custom file naming convention is used and the component reference is separated with a dot (.) character rather than a dash (-).
+
+* The `Makefile` generator functionality has been significantly improved and moved from the compiler to a separate utility called `*ttcn3 makefilegen*`. The following changes have been made:
+
+* The program automatically recognizes TTCN–3 include files with suffix `.ttcnin.`
+
+* The detection of file name clashes and filtering of generated files related to TTCN–3 preprocessing and/or central storage has been improved.
+
+* Warnings are displayed if the central storage or preprocessing options are used unnecessarily or the options are not used, but they should be.
+
+* The program detects if the names of input files contain spaces or other special characters that cannot be handled by the make utility.
+
+* The path transformation rules are also applied on the name of the target executable.
+
+* On Windows the `.exe` suffix is appended to the name of the target executable only if the file name does not contain that.
+
+* The compiler and the run-time environment supports the evaluation of some nonstandard TTCN–3 macros. The detailed description of the macros can be found in the Reference Guide.
+
+* Macro substitution modifier hostname was introduced in the run-time configuration files. This modifier allows the substitution of macro values containing a DNS name or IP address into sections `[GROUPS]`, `[COMPONENTS]` and `[MAIN CONTROLLER]`.
+
+* The following enhancements have been made on the GUI:
+
+* Exclude and Include from build functionality has been added to source files included in File Groups.
+
+*Fixed bugs*
+
+* In some cases the GUI did not load the user-defined test sets that were stored in the project.
+
+* The compiler generated wrong (uncompilable) C\++ code for the location information when the name of the input file contained special characters (like the backslash) that require escaping in C++ string literals.
+
+* The compiler aborted with an internal fatal error during semantic analysis if a RAW attribute POINTERTO referred to a non-existent field. The abort occurred after printing the relevant error message.
+
+* The performance of utility `*ttcn3 logformat*` was very poor on log files containing very long lines. It took several minutes even for a powerful processor to format a file containing only a few megabytes of data. The reason was regular expressions that were supposed to match the beginning and end of TTCN–3 test cases were given in an inefficient way so that the parser generated by utility `flex` could not process the input with a linear algorithm. The complete internal structure of `*ttcn3 logformat*` has been redesigned to eliminate the performance critical regular expressions. The block indentation algorithm has been replaced with a more robust one that, for instance, can re-indent previously indented log files.
+
+* The compiled did not issue warnings for some TTCN–3 reserved words that can appear in ASN.1 modules thus making the corresponding ASN.1 value or type field unreachable from TTCN–3 . The values of type verdicttype (like `none` or `error`) and the binary operators of TTCN–3 (like `not4b` or `xor4b`) were not detected and reported by the compiler.
+
+* The compiler crashed with a segmentation fault when generating code for an ASN.1 open type that did not have table constraint. This problem was introduced by a bugfix of the previous release that was about missing C++ classes related to open types. Nevertheless, an ASN.1 open type without table constraint is useless in TTCN–3 because there is no way to create templates for it. The compiler now reports warnings when encountering such open types.
+
+* The semantic analyzer of the compiler verified the arguments of built-in TTCN–3 conversion functions int2hex and int2oct incorrectly. In some cases when the arguments were constants and the given value did not fit in the given length the semantic analyzer did not report any error, but the compiler aborted with an internal fatal error during constant folding while doing the conversion.
+
+* The compiler generated incorrect C\++ code for TTCN–3 for loops if the boolean guard expression was constant false. In this case the entire loop was substituted with an empty C++ statement although the initial variable assignment had to be executed exactly once in all cases. The wrong code could cause problems if the initial assignment had side effects (e.g. it called a function or modified a variable defined outside the for loop).
+
+* The compiler and the run-time environment supports the short-circuit evaluation of logical `and` and `or` operations as it is required by the TTCN–3 standard. If the result of the operation can be determined based on the first (left) operand (i.e. the first operand is false in case of and or true in case of or) the second (right) operand will not be evaluated at all. The writer of the TTCN–3 code can exploit this behavior if the right operand may have side-effects or cause a dynamic test case error.
+
+* The compiler reported wrong location information for some TTCN–3 parse errors. For example, when a literal integer value was too large the error message indicating the overflow referred to the previous token of the input rather than the number itself.
+
+* The compiler detects if the same TTCN–3 or ASN.1 input file is passed to it more than once and reports a single, but appropriate error message about this. Formerly the file was parsed and analyzed several times, the same error messages were repeated and only an error message complaining about duplicate module identifiers referred to the real problem.
+
+* The generated C++ code suffered aliasing problem in case of some TTCN–3 function and altstep calls. If a component variable was passed as in parameter to a function having runs on clause and the called function modified the same variable the value of the in parameter has also changed. This behavior breaks TTCN–3 semantics since in parameters shall always be passed by value. The code generator has been fixed by adding explicit copy constructor invocations at the calling side when necessary.
+
+* The configuration file handler of the GUI reported syntax error and created syntactically invalid configuration file if a compound module parameter within brackets contained a typed macro reference. The problem was caused by a subroutine of the GUI that performed block auto-indentation on all configuration file entries. The algorithm did not recognize the brackets of the macro reference and inserted whitespace between the "$" and "{" characters.
+
+* The compiler did not export the type descriptors of the embedded TTCN–3 and ASN.1 types to the generated header file. Thus the generated code was uncompilable if the embedded type was referenced from another module using field or array subreferences.
+
+* The compiler performed incomplete semantic analysis on the arguments of built-in operations `ispresent` and `ischosen`. For instance, when the operations were used in the value of a constant the compiler did not report an error if the argument referenced to a template or template variable.
+
+* Built-in operation `ischosen` was not implemented properly in the run-time environment. When the argument was an unbound union value the operation returned false rather than causing a dynamic test case error.
+
+* The macro processor of the run-time configuration files did not allow the substitution of macros with empty values as `bitstring`, `hexstring` or `octetstring` value.
+
+* When a project file was passed to the GUI as command line argument the program did not convert the simple file names or relative pathnames to absolute paths. Thus the same file could appear several times on the list of recently opened projects.
+
+* In some cases the GUI crashed with a segmentation fault when selecting and opening a file from the list of recently used projects. The reason was that the program tried to use a string reference pointing to a value that was already destroyed.
+
+* The compiler checked the actual parameter of a parameterized ASN.1 assignment only when the parameter was referenced through the dummy reference. This allowed syntax and semantic errors in the actual parameters to remain hidden if the dummy reference was not used within the body of the parameterized assignment. The corrected algorithm checks all actual parameters as well as the entire instantiated assignment at the point of instantiation when processing the parameterized reference.
+
+* The generated C++ code could contain name clashes between types and values generated at the instantiation of parameterized ASN.1 assignments. The clash could occur, for example, when a parameterized information object assignment had a field setting and a parameter (dummy reference) with identical names (apart from the leading &).
+
+[[version-1-6-pl4]]
+== Version 1.6.pl4
+
+Released on July 31, 2006.
+
+*New features*
+
+* The `Makefile` generator of the compiler supports the use of C preprocessor on TTCN–3 code. The TTCN–3 parser of the compiler understands the preprocessor’s line directives thus the error messages refer to the right position in the source code.
+
+* The non-standard TTCN–3 language extension about function, altstep and testcase references and the related operations, such as apply, refers and derefers are now supported.
+
+* The non-standard TTCN–3 language extension about non-mandatory parameters are now supported. It is now possible to assign default settings to formal parameters and omit actual parameters when invoking the respective definition.
+
+* The run-time environment supports the use of UNIX domain sockets for the realization of TTCN–3 port connections. This results in more efficient data transfer on native UNIX platforms compared to the former TCP-based method when both endpoints of the port connection are located on the same computer.
+
+* Test execution is now supported on Cello Packet Platform with OSE Delta operating system.
+
+* The memory requirement of the run-time environment has been improved by a few percents. For instance, in older versions every string value allocated 3 bytes more than it is necessary.
+
+* The execution time as well as the memory usage of the compiler has been improved by a few percents. The generic containers of the abstract syntax tree have been optimized.
+
+* In parallel mode it is allowed to connect a new Host Controller to the Main Controller while a test case is running. The newly connected HC gets the configuration information immediately and takes part in load balancing as soon as possible.
+
+* The Main Controller supports the relocation of a newly created PTC to another host if it is impossible to create a new process on the host that was chosen initially. If the Host Controller cannot create a new process the MC will exclude the host from load balancing until it reports that overload has ceased.
+
+* The logging routines of the run-time environment support the handling of several log events in a stack-based concept. It is allowed to call TTCN Logger:: `begin event()`, `log event()` and `end event()` in the middle of another event. This allows the use of `TTCN–3 log()` statements in recursive contexts (e.g. when the return value of a function is being logged and the function itself also contains `log()` statements).
+
+* During load tests it often happens that two test components continuously send data to each other through connected ports. Earlier versions of the run-time environment used blocking send operations on the underlying TCP connections, which could lead to deadlocks if all network buffers were full in both directions. Starting from this version non-blocking send operations are used on port connections and when sending would block the test component tries to increase the size of outgoing network buffer if this is supported and allowed by the operating system. If the buffer cannot be enlarged any further the send operation will block and also try to handle incoming messages. In this case a warning message indicates the unusual operation of the run-time environment (i.e. new incoming messages might appear in the port queues while only sending is performed). +
+
+NOTE: This improvement prevents the test system from deadlocks in many cases, but there is no warranty that the run-time environment can cope with all possible situations (for example, infinite port queues exist only in theory). The ultimate solution is to restrict the amount of outstanding data on port the connections by well designed flow-control algorithms in the TTCN–3 code (e.g. by introducing an application level sliding-window protocol).
+
+* The compiler’s output generation algorithm has been improved. In order to perform selective updates the compiler first writes the generated code into a temporary file and updates the final target only if the contents of the existing file differs from the newly generated one. In earlier versions the temporary files were always created even if the real target files did not exist. Now the output is written directly to the target file if a previous version does not exist, which can result in significant speedup in the compiler’s operation when building large projects from scratch.
+
+* The compiler supports error recovery in the RAW and TEXT encoding attributes of TTCN–3 types. Formerly a single syntax error in the attribute text caused the compiler to stop immediately.
+
+* Macro substitution is now supported in section `[MAIN CONTROLLER]` of the configuration file in both command-line and GUI modes.
+
+* Basic arithmetic operations and concatenation of character string values are now supported in the run-time configuration file. This allows the more flexible use of macros since a module parameter or a configuration option can be derived from several macros and/or constant values.
+
+* The TTCN–3 parser of the compiler allows in-line compound values in the operands of expressions. +
+
+NOTE: Compound values can only be used with comparison operators (i.e `==` or `!=`) and the other operand has to be a referenced value.
+
+* Metacharacter `%c`, which denotes the name of the current testcase, is now supported when specifying the names of the log files in section `[LOGGING]` of the configuration file.
+
+* The run-time environment knows about the names of TTCN–3 timers. Log entries and error messages related to timers now contain the name of the corresponding timer, which makes the analysis of logs easier.
+
+* The following enhancements have been made on the GUI:
+
+* Execution Window: When configuring the host controllers with ’Detailed actions’ switched on, the configuration file to use can be chosen from a list.
+
+* Project Window / File tree: File Groups section added.
+
+*Fixed bugs*
+
+* The behavior of the run-time environment could be undefined if the left operand of TTCN–3 concatenation operator (`&`) was a bitstring element (containing a single bit) and the right operand was a bitstring value. If the right operand was long enough the operation could lead to segmentation fault because a programming mistake allowed over-indexing in memory.
+
+* The pre-defined functions `bit2int`, `hex2int` and `oct2int` refused the conversion with a dynamic test-case error if their argument contained more bits than the integer representation of the given platform. Now the conversion is possible if the argument is longer than this limit, but after cutting the leading zero bits, hex digits or octets the result can be represented as a non-negative number in the integer type. On the other hand, the conversion was incorrectly possible if the input had the same size as the integer type, but the result was a negative number. Both the compiler and run-time versions of these functions were affected by this fault.
+
+* The compiler reported an inappropriate warning message when checking a value or template of an empty record or set type. The message stated that all elements were not used symbols (i.e. -) although the value or template did not contain any elements. +
+
+NOTE: The only possible value of these types is _{}_.
+
+* The error messages of the compiler contained incomplete or missing location and context information hierarchy if there was an error deeply within a complex TTCN–3 expression.
+
+* The Main Controller stopped in a deadlock in batch mode if the MTC and all alive HCs terminated at the same time and closed their control connections unexpectedly.
+
+* Empty character strings in TTCN–3 pattern templates were not handled properly. The compiler accepted empty strings after the pattern keyword, but generated faulty (uncompilable) C++ code. Moreover, the run-time environment reported dynamic test case error if the pattern was empty (e.g. after variable substitution). Of course, empty charstring patterns are allowed and they match the empty string values only.
+
+* The TTCN–3 parser of the compiler rejected array index sub-references in type references. That is why a nested unnamed type of a record of type could not be addressed. +
+
+NOTE: The array indices in type references are handled in a special way in the compiler: it is verified that the value in square brackets should be of type integer, but the number itself is not used for anything.
+
+* The compiler generated wrong (uncompilable) C\++ code for ASN.1 open types in some cases. The C++ equivalents of some types and values were missing if an unnamed information object set was used in the open type’s table constraint. This was the case, for instance, if the open type was embedded into a parameterized type assignment and the object set was defined in-line in the actual parameter list of the type reference.
+
+* Incremental compilation of ASN.1 modules did not work properly if the instantiation of some parameterized type assignments changed since the last full re-compilation of all modules. Changing the order of files in the compiler’s command line could cause similar problems. Module-based incremental compilation uses the concept that the C\++ equivalent of a module shall only depend on the module itself and the imported modules. Importing modules that use some definitions from the module must not influence the generated code. The C++ equivalents of parameterized assignments are generated when the assignment is instantiated by a parameterized reference (because only these instances can be visible from TTCN–3 ). The instances are created in the module where the parameterized reference is because the actual parameters might be visible only from that module. Different instantiations of the same parameterized assignment are identified by instance counters. Earlier versions of the compiler used one instance counter for each parameterized assignment. This can cause problems when there is a parameterized assignment in module A and it is instantiated from B and C. If the number of instantiations in B changes this would change the instance counters of C. Thus the generated files of C became outdated although C does not import from B. Starting from this version the instance counters are associated with target modules. In the above example the parameterized assignment in A has two counters: one for B and another for C. This change required a new naming convention for the C\++ classes of instantiated types: the identifier of the target module became part of the name, which resulted in longer C++ identifiers.
+
+* The compiler assigned wrong identifiers to some ASN.1 open type members. Open types are mapped to implicit CHOICE types and the alternatives are the distinct types from the table constraint’s object set. The alternative identifiers of the CHOICE are derived from each type’s name by changing the first letter (which must always be a capital letter) to lower case. This mapping of names did not work properly if the elements of the object set were the instances of a parameterized information object assignment. For instance, different types got the same identifier (and therefore the generated C++ code was invalid) if the respective object field was a dummy reference pointing to the object’s formal parameter. When constructing open types the compiler generates a warning message if a member type has a complicated constructed name and thus the alternative will get a strange identifier. These warnings were missing too from the instances of parameterized types.
+
+* The semantic analyzer of the compiler did not accept value (character) range matching mechanisms in templates of type universal charstring.
+
+* Values of type charstring that were created by indexing a single-character element of another charstring value had incorrect internal representation in the run-time environment. The run-time representation of charstring values contains a length indicator and a terminating zero byte is also appended at the end of the string. However, the indexing operator set only the length indicator in the result so the builtin functions that relied on the terminating byte (e.g. str2int) worked incorrectly.
+
+* The compiler did not handle the unterminated TTCN–3 comments properly at the end of file. Unterminated line comments (beginning with "//" and when the file did not end with a newline character) were accepted without any error message. Moreover, an unterminated block comment (beginning with "/*") could confuse the compiler so that it was unable to parse further files.
+
+* The compiler aborted with an internal fatal error when detecting an erroneous reference in the argument of built-in operations `ispresent` or `ischosen`. The proper error message was displayed before the abort.
+
+* The compiler generated wrong C++ code (which worked incorrectly) for TTCN–3 function calls in very rare cases. The aliasing problem occurred if the same variable was passed to a function as both in and `inout` parameters. When the function has updated its `inout` parameter (i.e. the variable of the caller) the value of the in parameter has been changed although it should have been constant throughout the entire function call.
+
+* The compiler aborted with an internal fatal error during the comparison of constant values of TTCN–3 type objid and its ASN.1 equivalents (i.e. OBJECT IDENTIFIER and RELATIVE-OID). This could occur, for instance, while the compiler was checking the component relation constraints of some ASN.1 protocol modules.
+
+* The compiler’s semantic analyzer rejected the return statements within the body of altstep definitions although the latest version of the TTCN–3 standard allows them.
+
+* Checking of built-in operation `valueof` was implemented incorrectly in the compiler’s semantic analyzer. For instance, the compiler did not report error if the argument of `valueof` was of an incompatible structured type. Another bug in the algorithm caused segmentation fault during code generation if the argument was an in-line modified template.
+
+* The compiler’s semantic analyzer verified the uniqueness of field names in TTCN–3 record, set and union types and the correctness of embedded types in a single step. This strategy resulted in false error messages as well as memory leaks if a type was part of multiple recursion loops and had RAW encoding attributes that referred to its recursive fields, such as `LENGTHTO` or `CROSSTAG`. The algorithm has been restructured into two distinct steps so that the embedded types are not analyzed until the field names are completely verified.
+
+* The RAWencoder of the run-time environment could crash with a segmentation fault while encoding a union value with TAG attribute. This was the case if the field that was referred by TAG (which is used to select the right alternative during decoding) had an invalid value. The situation was similar if more than one values were listed for the current alternative and the value to be encoded did not contain the first one from the list.
+
+* The compiler could report false errors or abort with internal fatal error if the length restriction of a TTCN–3 template contained an arithmetical expression of type integer rather than a literal value.
+
+* The ASN.1 parser of the compiler classified the information object assignments incorrectly as value assignments if the governor information object class was parameterized. Due to the false recognition the semantic analyzer reported inappropriate error messages and crashed with a segmentation fault.
+
+* The compiler could crash with a segmentation fault during semantic analysis when a parameterized ASN.1 assignment was instantiated and its right-hand side contained an in-line information object set definition (e.g. in a table or component relation constraint).
+
+* The following bug fixes have been made on the GUI:
+
+* Project Window / File tree: The GUI crashed if included projects contained test sets. Now they are displayed correctly, and are offered for execution in the Execution window.
+
+* Execution Window: Log lines containing only a number are aligned to the left of the table cell instead of aligning to right.
+
+* Project Window / File tree: Fixes in included project handling. There is no more warning about read-only project file for included projects.
+
+* Project Window / `Makefile` generation: Sources under "Misc Files" are not included in the `Makefile`. They get automatically" Excluded from build" when adding them to the project.
+
+* Process Monitor: Normal text color is not changed after clicking on highlighted text.
+
+* Execute Dialog: Controls, Test Cases and Test Sets are placed in right order in the list.
+
+[[version-1-6-pl3]]
+== Version 1.6.pl3
+
+Released on December 16, 2005.
+
+*New features*
+
+* Arrays of TTCN–3 language are now fully supported. This includes multidimensional arrays, arrays within type definitions and index ranges with lower and upper bounds. Index values in array references are verified against the array bounds both in the compiler (as long as the index value is constant) and in the run-time environment. In case of index overflows or underflows a proper run-time error message is generated instead of the unpredictable behavior of former versions.
+
+* The template matching mechanisms subset and permutation are now fully supported.
+
+* Semantic analysis of TTCN–3 group names has been implemented.
+
+* TTCN–3 with attributes that belong to modules or group definitions are now processed and propagated to the embedded definitions. Consistency checking of attributes and attribute qualifiers has been improved.
+
+* The compiler supports generation of `Makefiles` to be used with central storage of precompiled files. Administrators of larger projects can collect and compile the common TTCN–3 and ASN.1 modules that change rarely (type definitions, test ports, etc.) in a central directory. Test developers can build their projects without re-compiling the common modules by taking the pre-compiled object files and C++ header files from the central storage. Usage of this feature can save compilation time as well as disk space for the individual developers.
+
+* The configuration file of the run-time environment has been enhanced. Two new sections (`[INCLUDE]` and `[DEFINE]`) have been introduced. This allows modular configuration information spanning over multiple files and usage of macros and environment variables within the configuration files.
+
+* Built-in TTCN–3 operations `ispresent`, `ischosen`, `lengthof` and `sizeof` are now applicable to templates and template variables in addition to values (constants, variables, etc.).
+
+* The RAW encoder/decoder supports forward references in `CROSSTAG` attributes. It is allowed that the decoding of an union field depends on another field that is defined later in the same record if the union field is mandatory and all embedded alternative types have the same, fixed size. During decoding such union fields are processed out of order. In the first round the field is simply skipped, it is processed only when the field that determines which alternative to choose is successfully decoded.
+
+* The run-time environment and the MC supports the killing of the MTC process if it is not responding because it is stuck in an infinite loop. Formerly an unresponsive MTC could cause deadlock in the whole test system. The termination of MTC can be initiated from a PTC using operation `mtc.stop` or from the user interface by issuing a `stop` command or pressing the *Stop* button. The MTC process is killed only if it does not respond to the stop request before the guard timer expires.
+
+* The IP addresses used for the control connections between the Main Controller and Host Controllers and test components are now configurable. These options are useful when testing is performed on multi-homed hosts (i.e. computers with multiple network interfaces and/or IP addresses). In case of MC the address of the TCP server can be restricted using a new option in the configuration file. On the HC side the client IP address can be set using a command line switch.
+
+* The expect script `*ttcn3 start*` accepts absolute or relative path names as the name of the ETS. If the configuration file is not specified explicitly in the command line it is searched in the same directory as the ETS is in.
+
+* The following enhancements have been made on the GUI:
+
+* Configuration Editor: Updated to handle the new sections (`[INCLUDE]` and `[DEFINE]`).
+
+* Project window: Subprojects can be added to the main project. `Makefile` generation is updated to generate `Makefile` supporting the central storage.
+
+* Project window: Project tree now remembers the opened and closed state of the main types.
+
+* Project window: When adding a file to the project with a name which already existed within the project’s files, replacing the old file with the added one is offered.
+
+* GUI Preferences: The line number switch for the external editor can be configured.
+
+* Process monitor: Highlighting of the source code file paths with line numbers, errors, warnings and identifiers added. The source code with the line number can be clicked, and if configured well in the preferences, the external editor will be opened at that line.
+
+* Project Properties: Added setting of whether to create symlinks with absolute or relative target path.
+
+* Project Properties: Added setting of whether to use absolute paths in the generated `Makefile`.
+
+* Execution window: *Follow last log line* checkbox added to the toolbar to set the log area to scroll to the last added line or not.
+
+* Execution window: The items in the Execute Dialog are not sorted alphabetically by default. The order of the controls and test cases will be the order they were returned by the test case collection (the order they were written in the source modules).
+
+* GUI Preferences: %active config path added to the selectable GUI variables for use in the User Menus.
+
+* The Log Browser supports searching of strings within the event texts.
+
+*Fixed bugs*
+
+* Templates with length restrictions produced strange printout in the run-time logs due to a missing break in a C++ switch-case statement.
+
+* The run-time location information of else if statements pointed to the wrong line of the TTCN–3 code. For example, if an error occurred in the boolean expression of an else if statement the dynamic test case error message of the log file contained the line number of the first if statement. This made difficult to find the reason of the error since the first boolean expression, which the error message referred to, was correct.
+
+* The compiler generated faulty C\++ code if the last statement of a TTCN–3 statement block was a select-case statement. The C++ compiler complained about that the last label of the block was not followed by a statement. The syntaxerror was corrected by adding an empty C++ statement (i.e. a semi-colon) after the corresponding label.
+
+* The compiler crashed with a segmentation fault during code generation if the boolean expression of a TTCN–3 if, for or while statement contained an in-line compound expression that could not be mapped directly to a C++ expression.
+
+* If the actual value for a module parameter of a record of or set of type contained fewer elements in the configuration file than the default value in the TTCN–3 module then the surplus elements of the default value remained present after processing the configuration file.
+
+* The compiler could produce a segmentation fault when generating the C++ structures for describing TEXT encoding of enumerated types. The reason was that the code generation subroutine addressed internal data structures in a wrong manner.
+
+* The expect script `*ttcn3 start*` detects if the configuration file instructs the MC to run in batch mode. Instead of causing a deadlock the script terminates with a proper error message.
+
+* The compiler aborted with an internal fatal error if a TTCN–3 template reference tried to address a sub-field or element of a template (or template field) containing a generic wildcard like ? or *. Now a proper error message is printed in these circumstances.
+
+* The value comparison algorithm for set of types was not implemented in the compiler. These functions are applied during constant folding (i.e. when all operands of a TTCN–3 expression are available at compilation time) to substitute the expression with its result in the generated C++ code. In case of set of values the comparison algorithm of record of types was applied, which could give incorrect result because it considered the order of elements.
+
+* The TTCN–3 language mode of program `ctags` did not handle the string literals properly. If a TTCN–3 string constant contained a special character like _{_ or _}_ `ctags` got confused and ignored the definitions in the rest of the file. Moreover, the program failed to parse character string patterns within templates.
+
+* The run-time environment did not specify the client IP address for the control connections towards the `MC`, thus it was chosen by the kernel independently for every connection. On some multi-homed Sun Grid environments it could happen that a test component got a different local IP address from the kernel than the `HC` (i.e. its parent process). In this case the `MC` refused the component’s control connection and the respective create operation failed with a dynamic test case error. In the new version only the `HC`s can get automatically assigned IP addresses (unless the local address is explicitly given in the command line). The test components (child processes) always assign the HC’s local IP address explicitly before establishing their control connections.
+
+* The RAW decoder of the run-time environment contained a memory leak. When the decoding of an enumerated value was unsuccessful a memory block containing a temporary string was not deallocated. This could lead to significant memory growth in case of load testing, especially when the types used the TAG attribute, the decoding of which is implemented using backtracking.
+
+* The run-time environment caused a dynamic test case error when an optional record or set field containing omit value was compared with a mandatory field or a simple value. The false error message complained about unbound operand of comparison. Now those operations return the appropriate boolean result: false in case of operator `==` and true in case of `! =`.
+
+* The dynamically linked version of the TTCN–3 Base Library (i.e. libttcn3-dynamic.so and libttcn3-parallel-dynamic.so) did not contain all functions that are necessary for building the executable. If those libraries were used the linker complained about a lot of unresolved function references. Thus only the statically linked versions of the Base Library (i.e. `libttcn3.a` and `libttcn3-parallel.a`) were usable. The reason was a mistake in the built script (the script did not add some object files to the dynamic libraries).
+
+* The compiler aborted with an internal fatal error if it encountered non-ASCII characters (i.e. character codes above 127) in the argument of predefined function `char2oct()`.
+
+* The expect script `*ttcn3 start*` could hang in a deadlock after issuing the `emtc` command. The reason was that the expected output lines of the Main Controller (MC) came in the wrong order due to a race condition within the MC. To avoid such problems in the future both the script has been enhanced and the race condition has been eliminated.
+
+* The utility `*ttcn3 logformat*` did not separate the log entries belonging to different test cases (using the `-s` option) when the timestamps contained the date (i.e. option `TimeStampFormat` was set to `DateTime` in section `[LOGGING]` of the configuration file). In this case all entries were dumped to standard output. This was because a incorrect regular expression was specified in the parser for those timestamps.
+
+* The utility `*ttcn3 logmerge*` did not detect or handle write errors (e.g. when the disk became full the user was not notified that the output file is incomplete). Now the utility reports the appropriate error message and terminates immediately when it encounters any error related to file operations. Moreover, it was not handled properly when the limit of simultaneously open files was reached on Solaris 2.6. In such situations the program got into an infinite loop of printing error messages.
+
+* The program routine that is responsible for processing TTCN–3 character patterns contained a memory leak. Although this fault affected the compiler as well, it could cause serious problems in the run-time environment during long-duration performance tests. The memory usage of TTCN–3 test components increased continuously if they used charstring templates containing pattern matching mechanisms or the predefined function `regexp()`.
+
+* Utility `*ttcn3 logmerge*` could cause segmentation fault if one of its arguments was a path name containing . or .., but its file name part did not contain dash (i.e. -) character.
+
+* The compiler generated invalid C\++ code if the first operand of predefined function `substr` was a charstring element. The C++ compiler complained about an ambiguous function overload.
+
+* The following bug fixes have been made on the GUI:
+
+* GUI Preferences: Successful saving of the settings is checked, and an error dialog is shown when it fails.
+
+[[version-1-6-pl2]]
+== Version 1.6.pl2
+
+Released on August 1, 2005.
+
+*New features*
+
+* C++ code generation for TTCN–3 interleave statements is now supported.
+
+* The compiler reports a warning if an ASN.1 identifier is a TTCN–3 keyword so it is unreachable from TTCN–3 . The warning is generated only if the ASN.1 identifier should be visible from TTCN–3 (e.g. there is no warning if a named bit or an information object is identified with a TTCN–3 keyword). The names of TTCN–3 predefined functions are also considered to be keywords.
+
+* The following enhancements have been made on the GUI:
+
+* Project window: When creating new configuration file, the default assignments are commented.
+
+* Project window: When creating new TTCN-3 or ASN.1 files, the file and module names are checked against basic mistakes.
+
+*Fixed bugs*
+
+* The Main Controller updated its internal state table incorrectly when an idle nonalive type PTC was stopped explicitly by another test component. The PTC was instructed properly to terminate, but MC reported unexpected events when the PTC finished. As a consequence of this MC assigned error verdict to the corresponding PTC at the end of the testcase regardless its real final verdict.
+
+* The command line version of the Main Controller (i.e. `mctr cli`) stuck in a deadlock if the MTC terminated unexpectedly in batch mode. This could happen, for example, if a faulty Test Port caused the MTC to crash with a segmentation fault. Now this situation is handled explicitly by the MC, which reports an error and terminates with unsuccessful exit status in this case. The same problem was also present in the expect script `*ttcn3 start*`, which invokes `mctr cli` in interactive mode. The script was fixed, too.
+
+* The Log Browser displayed those log entries incorrectly that consisted of a timestamp and an integer number. Such entry can be produced, for example, by passing an integer value to the TTCN–3 `log()` statement. When seeing this line the Log Browser got confused and recognized the integer number as a component reference and considered the entire next log entry (line) as the text of this event.
+*
+The compiler reported strange error messages on valid TTCN–3 input if an encoding token of a TEXT attribute contained one of the following characters: #, ], _}_ and a decoding token was not specified for the same attribute. When the decoding token is omitted the compiler derives it from the encoding token automatically. Since the encoding token is a simple charstring value, but the decoding token is a TTCN–3 pattern the characters that have special meaning in patterns have to be escaped. The above three characters, however, were not escaped during the transformation.
+
+* The BER decoder for one-octet character strings (i.e. ASN.1 character string types that are mapped to charstring in TTCN–3 ) created incorrect string values. In the internal string representation the length and the content characters were set properly, but the terminating NUL character (zero byte) was missing at the end of the decoded string. In most cases the fault remained invisible because the majority of built-in string operations use the length field. However, the predefined function `str2int` uses the NUL terminated string without the length, which caused undefined behavior if its input came from BER decoding.
+
+* It was impossible to specify literal charstring values in RAW encoding attributes of TTCN–3 types. Since the coding with attribute is delimited with quotation mark characters the beginning and end of the embedded string has to be escaped (i.e. the quotation mark character shall be preceded with a backslash or a double quotation mark character shall be used). However, the attribute parser of the compiler used a wrong regular expression, it expected a single quotation mark character as delimiters in charstring literals.
+
+* The code generator of the RAW enc/dec did not prefix the enumerated values if the `-E` (enum-hack) compiler switch was turned on. Thus the generated C++ code did not compile in this case.
+
+* The documentation of RAW attribute `PRESENCE` contained a mistake in syntax description. The attribute parser of the compiler required a pair of brackets for multiple values, but the documentation does not. Now the parser accepts both syntax variants to preserve backward compatibility.
+
+* The RAW encoder encoded the empty charstring values incorrectly. The result of encoding was nothing (empty string) even if the FIELDLENGTH attribute was set to a positive number.
+
+* The following bug fixes have been made on the GUI:
+
+* Execution window: GUI hung in a deadlock when displaying errors or warnings during test execution.
+
+* Project window / process output on Cygwin: endless loop avoided on Cygwin when executing a process. +
+
+NOTE: Cygwin is not officially supported by TCC.
+
+[[version-1-6-pl1]]
+== Version 1.6.pl1
+
+Released on June 30, 2005.
+
+*New features*
+
+* The TTCN–3 parser of the compiler works based on the final BNF of version 3.1.1 of the Core Language standard. This implies the following minor additions:
+
+* Nested (unnamed) TTCN–3 type definitions can now be used.
+
+* The log statement accepts template instances (including inline and inline modified templates) in addition to values and template references.
+
+* The halt port operation is now supported.
+
+* The TTCN–3 select-case statement is now supported.
+
+* Test case static test configurations, that is, alive TTCN–3 test components and the related operations are now supported. The following new component operations have been added: create alive, kill, killed, alive. The meaning of the following existing component operations has been extended: stop, done, running.
+
+* Error recovery in the TTCN–3 parser has been significantly improved.
+
+* The following enhancements have been made on the GUI:
+
+* Project window: added toolbar icon (hotkey: F9) for executing the `[EXECUTE]` section of the config file.
+
+* Project window: toolbar icons (and separators) can be sorted by adding @place number to the end of their name, i.e. `MAINTOOLBAR_>_Make -j2@5`.
+
+* Project window: file tree accepts the *<Del>* key.
+
+* Project window: hotkeys: CTRL+C stops current process execution, CTRL+L clears current process window, CTRL+W closes current process monitor if it is enabled.
+
+* Project window: executable is offered to be removed when changing the Build/Execution mode.
+
+* Project window: symlinks are created as relative symlinks instead of absolute.
+
+* Project window: log files are refreshed right after loading the project.
+
+* Project window / Process monitor: performance improved.
+
+* Config file editor: save compound values formatted.
+
+* Execution window: improved stability and memory consumption on high load.
+
+* Execution window: button sizes are the same when switching to Detailed.
+
+* Execution window: test execution does not need any config file.
+
+* Execution window: waits until the specified number of HCs (NumHCs in the config file) connect before starting the test execution.
+
+* Execution window: state strings are the same as used in the CLI version.
+
+* Execution window: removes the temporary config file from /tmp when finished.
+
+* Execution window: added timed execution; the start date/time can be set before starting the test in the test case selection dialog.
+
+* Execution window: double click is accepted in the test case selection dialog.
+
+* Execution window: empty selection is not accepted.
+
+*Fixed bugs*
+
+* The compiler aborted with an internal fatal error when checking a TTCN–3 expression (or sub-expression) if all operands of an arithmetic or logical operation were available at compilation timefootnote:[The operands were literal values or references pointing to constants.] and one of the operands was a referenced value pointing to a TTCN–3 constant of type float or ASN.1 value of type REAL.
+
+* The generated C\++ code was uncompilable if the name of an ASN.1 built-in string type (e.g. UTF8String) was used as identifier in a TTCN–3 module or the name of a TTCN–3 built-in conversion function (e.g. bit2int) was used as ASN.1 identifier. Now the compiler appends a single underscore character to the C++ equivalents of these identifiers to avoid name clashes with the definitions of the Base Library.
+
+* The compiler caused segmentation fault during semantic analysis if the type of a constant or module parameter was erroneous (e.g. the referenced type was not imported) and the value of the constant or the default value of the module parameter contained an embedded record or set value (i.e. a value with TTCN–3 assignment notation). The problem occurred after reporting the relevant error message and only if when C++ code generation was requested (i.e. the command line switch `-s` was not used).
+
+* The GUI crashed at startup with segmentation fault if the environment variable TTCN3 DIR was not set or the configuration files and images were not found under `$TTCN3 DIR/etc/gui`.
+
+* The compiler analyzed only the top-level expressions in the optional arguments of TTCN–3 `create` operation, that is, recursive checks were not performed on the embedded sub-expressions. Because of this some kinds of errors were not detected and the compiler could abort with internal fatal error during code generation even on valid input (e.g. when a sub-expression contained a simple reference pointing to a variable).
+
+* The semantic analysis did not detect when a variable defined in the header of a TTCN–3 for statement shadowed a definition in an outer scope unit with the same identifier.
+
+* The compiler generated invalid code if the argument of a TTCN–3 `send` operation referred to an optional field of a record or set value (constant, variable, module parameter, etc.). The C++ compiler complained about ambiguous overload of a member function in the port class.
+
+* The Main Controller caused segmentation fault in both command-line and GUI modes if the `stop` command was issued while a control part was running and no testcase was executed before.
+
+* In parallel mode the MTC crashed with internal error if a test case was executed after stopping test execution from MC. When the `stop` command of MC interrupted the test execution the actual test case was not terminated properly and MTC remained in an inconsistent state.
+
+* The compiler rejected valid TTCN–3 input if one operand of the comparison operator was a reference pointing to an imported (constant or module parameter) definition and the other operand was an enumerated value. The error message complained about that the compiler was unable to determine the type of operands in the expression.
+
+* The MC reported internal error (unexpected STOPPED message) when a TTCN–3 map operation failed because the Test Port called TTCN error. This error situation is now handled properly.
+
+* The compiler did not allow to assign omit value from an optional field of a TTCN–3 constant to a template variable. The reason was a mistake in the a semantic analyzer routine because it did not propagate an option recursively.
+
+* The semantic analyzer of the compiler reported wrong circular recursion error message if a template reference in a function or testcase contained an array sub-reference the index of which was not constant. For example, this was the case when a for loop iterated through the elements of a record of template or template variable.
+
+* The compiler accepted any kinds of expressions (not only the boolean ones) in if, for, while and do-while statements because of a programming mistake in the semantic analyzer. Moreover, in most cases the generated C++ code was compilable (thus the problem remained hidden) if the type of the expression was a built-in TTCN–3 type (e.g. charstring).
+
+* The compiler generated wrong (uncompilable) C++ code if the boolean expression of a if, for, while or do-while statement referred to an optional boolean field of a record or set value.
+
+* The semantic analyzer routine of the compiler that checks the length restriction of templates contained several bugs. In certain cases this could cause segmentation faults or aborts in the compiler or the acceptance of invalid inputs. For example, the bugs could be triggered with the following constructs: length ranges with infinity as upper limit, length restrictions for the universal charstring type, length restrictions combined with specific string values.
+
+* The run-time environment did not pass the test port parameters to the respectivetest port objects if the parameter was assigned to named test components. One part of parameter processing routines that handled named test components was inactive due to a programming mistake.
+
+* The run-time environment produced a misleading warning message if an expired TTCN–3 timer was re-started. The message complained about re-starting a running timer although the built-in running operation returns false on expired timers.
+
+* The semantic analyzer of the compiler was unable to determine the type of string patterns in receiving port operations if the corresponding port type had more than one incoming message types. The statement was accepted only if the explicit type specification was present before the pattern (e.g. `p.receive(bitstring:'1?0'B)`;) although the type of the pattern is unambiguous.
+
+* The GUI did not pass the configuration option `KillTimer` to the Main Controller. The default value was always used even if it was overridden in the configuration file.
+
+* In the run-time environment, after invoking the `TTCN EncDec::set error behavior()` function with ET ALL option, the `TTCN EncDec::get last error type()` returned a wrong result unless you cleared it with TTCN `EncDec::clear error()`.
+
+[[version-1-6-pl0]]
+== Version 1.6.pl0
+
+Released on April 1, 2005.
+
+*New features*
+
+* The compiler supports semantic checking for the dynamic parts of TTCN–3 modules. This means that TTCN–3 modules are entirely covered with semantic analysis.
+
+* The compiler generates the entire C++ code from the output of semantic analysis, the so-called Abstract Syntax Tree (AST).
+
+* The TTCN–3 parser of the compiler supports error recovery, that is, it does not stop when a syntax error is detected, but it tries to read the further parts of the input and perform semantic analysis as well. However, in some cases it is not possible or worth-while to recover from a syntax error.
+
+* The text encoding has been introduced.
+
+* New RAW encoding attribute `REPEATABLE` has been added and the meaning of the `PRESENCE` attribute has been extended.
+
+* The `AssignmentList` notation also can be used in the parameter redirect of `getcall` and `getreply` operations.
+
+* Non-printable control characters of charstring values are printed using C escape sequences or quadruple notation into the log files. The raw format of earlier versions could disturb the log processing utilities.
+
+* In addition to the quadruple notation all escape sequences that are available in the C language are accepted for specifying non-printable characters of charstring and universal charstring values in the run-time configuration file.
+
+* The order of steps that are performed when deactivating a TTCN–3 port at component termination have been changed. Now the existing connections and mappings are shut down first and after that the port is stopped and its queue is cleared. In some Test Ports it can happen that the user `unmap` function tries to add a new incoming message into the port queue when destroying the mapping. In former versions this could cause dynamic test case error because the port was already in stopped state while user `unmap` was running. Now the incoming message is accepted and the port is stopped only after user `unmap` is completed.
+
+* As a non-standard extension the compiler and the run-time environment supports the assignment of names to the test components in create operations. The location of the new component can also be specified at creation, which is useful in distributed test environments.
+
+* Script `*ttcn3 start*` has been enhanced. It supports configuration files that are named differently than the ETS and the execution of multiple test cases given in command line.
+
+* The number of how many times the selected test(s) should run can be set on the GUI when selecting which test to run.
+
+* Input field added to the GUI main window. It is enabled when a process runs. Any input entered here is sent to the process as user input.
+
+* The GUI does not allow the creation or saving of empty test sets.
+
+* The GUI asks whether to recreate symlinks and recreate the `Makefile` if appropriate changes are made on the project’s properties.
+
+* If creating new file through the GUI, and not specifying file extension in the file name selection dialog, the first extension listed in extensions for that type will be appended to the given file name.
+
+*Fixed bugs*
+
+* The compiler aborted with an internal fatal error during code generation if an ASN.1 value assignment contained a `ValueFromObject` reference.
+
+* In some cases the compiler aborted with an internal fatal error when checking modified templates for record of or set of types. This was the case, for instance, if the base template contained a generic wildcard like ? or *.
+
+* The compiler generated invalid (uncompilable) C\++ code for `getcall` operations if the corresponding signature was imported from another module. This was because the default arguments of the C++ function that handles `param` redirects for the respective signature were generated into the source file instead of the header file and thus remained invisible for other modules.
+
+* The code generator of the compiler ignored the `NotUsedSymbol` characters in `param` redirect of `getcall` and `getreply` operations if the `VariableList` notation was used. Thus the run-time environment assigned the wrong parameters to the given variables.
+
+* The compiler ignored and did not check the value list subtype constraints for TTCN–3 union types.
+
+* The compiler aborted with an internal fatal error when the `-P` (top-level PDU) command-line switch was used. This was because the switch `-P` disabled the semantic checking of ASN.1 modules including their import lists. But when the given top-level PDU tried to refer to an imported symbol the symbol table for imported symbols was uninitialized.
+
+* The compiler rejected the `call` operations that did not have response and exception handling part with an error message even if the corresponding signature was a nonblocking one (i.e. it was defined with the `noblock` keyword).
+
+* The compiler generated invalid (uncompilable) C++ code for those in-line signature templates the signature of which had no parameters.
+
+* The compiler did not generate the C++ equivalents of some data types thus the generated code was uncompilable because of missing classes if an ASN.1 PDU type was defined using an object set, which was imported from another ASN.1 module.
+
+* All generated header files included `version.h` from the Base Library, which made it impossible to use the precompiled headers created by GCC 3.4 or above. The above file contains some preprocessor statements, which disable the processing of existing precompiled headers in further `#include` directives.
+
+* The compiler did not accept the `NotUsedSymbol` in the default duration of timer arrays. The symbol means that the corresponding array element shall have no default duration.
+
+* The compiler might generate invalid (uncompilable) code for the TTCN–3 functions that had signature template parameters. The C++ compiler complained about missing encode text and decode text functions, which are used when the corresponding function is being started as a PTC behavior.
+
+* The compiler did not recognize properly the default syntax for ASN.1 objects. If an object class did not have user defined syntax the compiler rejected the valid object definitions with strange parse error messages.
+
+* The semantic analyzer did not detect errors in procedure based port types. For example, a reference to a non-existent signature in the incoming or outgoing list resulted in an erroneous (uncompilable) output C++ code.
+
+* Our run-time environment implements the TTCN–3 entity that runs the control part and the MTC in the same process. The lists of active timers and defaults were not separated between the two entities thus the testcase could access and modify the control part timers and defaults. For instance, the statement all `timer.stop` in the testcase stopped the active timers of the control part as well.
+
+* It was impossible to specify value list type restrictions for TTCN–3 enumerated types because the compiler did not recognize the enumerated values within the subtype definition.
+
+* The compiler accepted value range type restrictions for almost all built-in types although value ranges are allowed only for integer and float types.
+
+* The predefined conversion functions str2int and str2float in the run-time environment accepted some invalid input strings. For instance if the numbers were followed by letters in the input string the numbers were converted and the remaining letters were silently ignored. Now these functions accept only valid inputs containing a valid integer or float value. An invalid input causes dynamic testcase error.
+
+* The compiler generated invalid (uncompilable) C++ code if the component reference in the `connect`, `disconnect`, `map` or `unmap` operation referred to an optional field of a record or set value because there was no conversion function to perform the implicit cast.
+
+* The compiler aborted with a segmentation fault or similar error when trying to generate C++ code for the initial value of a component variable, which contained a `valueof` operation. Such constructs usually appear in the output of the TTCN–2 to TTCN–3 converter.
+
+* The utility `*ttcn3 logmerge*` reported memory leaks when the operating system’s limit for the maximum number of simultaneously open files was smaller than the number of input files. In this case the log merge utility has to create temporary files in order to perform the merge in several steps. When the temporary file was closed the internal memory structure associated to it was not deallocated. Apart from the warning this bug had no other side effects.
+
+* The ASN.1 parser of the compiler did not recognize the EXPORTS ALL directive in the module and reported syntax error on it. This construct was introduced in the 2002 edition of the ASN.1 standard, its meaning is identical to the missing EXPORTS clause.
+
+* The compiler rejected the expressions, in which a constant value was referenced with a non-constant index. The error message complained that an integer value was expected as index even if the referenced value was of type integer. Such constructs can be created, for instance, in the body of parameterized templates where the index value refers to a formal parameter of the template.
+
+* The Main Controller entered an infinite loop and flooded the console with an endless sequence of error messages if the operating system’s limit of simultaneously open files was reached. This could happen when accepting the control TCP connections of newly created test components during load testing. The problem occurred on Solaris platform only. The reason was that the error codes of operating system calls were retrieved in an improper way and MC did not recognize the above situation.
+
+* If a literal value of TTCN–3 float type caused an overflow in the internal memory representationfootnote:[TTCN–3 float and ASN.1 REAL values are represented in the double type of the C/C++ language,which is mapped to 64-bit floating point numbers on most platforms.] the compiler stopped immediately with an internal fatal error during the parsing phase. Such situations are now handled properly and the compiler can continue its run after producing the appropriate error message.
+
+* The compiler aborted with an internal fatal error during code generation when it encountered a reference pointing to an element of a string value within template bodies or in the initial value of component variables. The code generator tried to follow the type of the embedded value and it handled the string element index in the same way as the indices of array and record of types.
+
+* The run-time environment did not handle the variable assignments for record of and set of types properly. If the newly assigned value had fewer elements than the previous value of the variable the extra elements at the end were not erased from the variable. For example, if a variable contained three elements and the newly assigned value had only two, the new value of the variable had incorrectly three elements: the first two from the new value and the third one from the old value. This problem was present regardless whether the embedded type was a built-in or a user defined type or the extra values were bound or not. The effects of this bug were the most strange if a component variable of the MTC was initialized in the component type definition and several test cases were executed after each other.
+
+* The run-time environment caused dynamic test case error if an optional component of an ASN.1 `SEQUENCE` or `SET` type, the type of which was the ANY type, was assigned to an optional octetstring field of a TTCN–3 `record` or `set` type and the source field contained omit value. The appropriate C\++ member function was missing and the C++ compiler performed an implicit conversion, which assumed that the value of the source field is present.
+
+* In case of some valid, but sophisticated TTCN–3 or ASN.1 type recursion loops the compiler did not produce the equivalent C++ classes in the right bottom-up order. Thus the generated code was uncompilable because of forward referencing of incomplete types.
+
+* The Main Controller could report memory leaks if the configuration file passed to it contained syntax errors.
+
+* The TTCN–3 parser of the compiler could not handle references pointing to an element of a multi-dimensional array in timer and port operations. It reported syntax error if the reference had more than one array indices, although the input was valid. The situation was the same if a component reference was embedded into a structured type and the `start`, `running` or `done` operation referred to a field of a variable.
+
+* The compiler aborted with an internal fatal error during semantic analysis if the base template of a modified union template did not contain a specific value (e.g. it was a generic wildcard like "?").
+
+* The generated C\++ code was uncompilable if an indexed element of a string value was assigned to a template. The C++ compiler complained about ambiguous function overloads in case of all string types (i.e. bitstring, hexstring, octetstring, charstring and universal charstring).
+
+* The generated C\++ code was uncompilable if an operand of a built-in TTCN–3 arithmetic, logical or string operation was a reference pointing to an optional field of a record or set value. The problem was present in case of all TTCN–3 operations that are mapped to infix C++ operators.
+
+* The HC logs contained incorrect information about the exit status of the test component if the corresponding UNIX process was terminated by a signal. In this case the log file showed a successful (zero) exit status although the process was aborted by a fatal error. Now the HC distinguishes between normal and abnormal process termination and reports the signal number instead of exit status in the latter case.
+
+* Fixed segmentation fault in RAW encoder. The fault occurs if the length field is an union field and it stores the length of optional fields.
+
+[[version-1-5-pl8]]
+== Version 1.5.pl8
+
+Released on November 5, 2004.
+
+*New features*
+
+* The `Makefile` generated by the compiler cuts the `.exe` suffix from the name of the executable on Windows platforms when running the command `make archive`.
+
+* The compiler uses more efficient internal data structures, which reduces its memory usage by about 10%.
+
+* The verification algorithm of `USER` limited licenses became more robust. Formerly only a reverse lookup was performed based on the numerical user ID (UID) of the process and the license was rejected if the UID was mapped to a login name different from that of the license file. Now, if this step fails a forward lookup is also performed on the login name of the license file. If the resulting UID matches the process UID the license is accepted. This makes the user name limited licensing working on UNIX systems where several login names are mapped to the same UID (e.g. portable Linux laptops with both local users and NIS membership). On such systems the reverse lookup returns one of the login names randomly.
+
+* The compiler generates the equivalent C++ code of TTCN–3 templates based on the output of semantic analysis. This means the following enhancements:
+
+* The compiler automatically re-arranges the initialization sequences for nonparameterized templates in case of forward referencing. It is not mandatory anymore to place such templates in bottom-up order in the module.
+
+* If enum-hack is turned on the short form can be used for enumerated values within template bodies. The use of long form in functions, testcases and altsteps is still mandatory.
+
+* The short-hand value list notation can be used in templates of record types.
+
+* In-line compound expressions (including in-line modified templates) are supported as function or template actual parameters within template bodies.
+
+* The run-time environment handles some test port errors in a more robust way. Formerly, if the `user map()` call failed (i.e. `TTCN error()` was called during its run) the test component registered the mapping before the error recovery. After the error recovery a regular unmap procedure was performed causing extra error messages.
+
+* The run-time environment now supports the partial overwriting of generic wildcards ? and * in modified templates and template variables of structured TTCN–3 and ASN.1 types. When transforming a template from ? or * to a specific value the following rules are applied recursively:
+
+* In case of record or set types all mandatory fields are set to ? and optional fields are set to *.
+
+* In case of union types the selected field is set to ?.
+
+* In case of record of or set of types all newly created elements up to and including the referred index are set to ?.
+
+* The run-time environment executes the `EndTestCase` command, which is specified in section `[EXTERNAL COMMANDS]` of configuration file, after writing the verdict of test case into the log. Thus the external command can extract this verdict from the logand act accordingly.
+
+* The C++ mapping of TTCN–3 and ASN.1 import statements has been improved. These updates make the generated code compatible with the limitations of GCC 3.4 or above that are in place when precompiled header files are used. The following changes were implemented:
+
+* The #include directives are generated in the same order as the import statements are placed in the source module. This allows the explicit control which header file to be included first.
+
+* Unnecessary #include directives are optimized out. For instance, if module C imports from both A and B and module B imports from A then `C.hh` will include only `B.hh` since `A.hh` is already included in `B.hh`.
+
+* Base Library header files is not included directly if the module has imports.
+
+* Circular import chains are handled in a special way.
+
+* Logging of timers is now supported. That is, a reference to a timer can be an argument of a `TTCN–3 log()` statement. When executing the statement the attributes of the timer (state, default and actual duration, elapsed time) are printed into the log.
+
+* If the executable tests are built with GCC the C++ compiler will perform extra checks on the arguments of Base Library functions that have printf-like syntax. The variable arguments of `TTCN error()`, `TTCN warning()`, `TTCN Logger::log()`, `TTCN Logger::log event()`, etc. are verified against the format string. New warning messages may be displayed during the compilation of Test Ports and external functions if type mismatches are found.
+
+* Log Browser now is able to determine the component name from the log file name.
+
+* Log Browser saves the configured view (columns shown) in the resource file.
+
+* The Configuration Editor of the GUI has been rewritten. Now it also handles the comments in the configuration file. The comments should be above the assignments. See Part II of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/userguide[TITAN TTCN–3 User Guide] for further details.
+
+* The GUI does not open Process output tabs for the external text editor, Log browser and the font / look and feel configuration programs.
+
+* The icon of the TTCN–3 and ASN.1 modules has changed to be brighter.
+
+* The working directory defined in the GUI project now automatically belongs to the log file directories.
+
+* The compiled executable’s path is now configurable for GUI projects.
+
+* The Make archive item has been added to the GUI’s project menu.
+
+* If running a command in a dialog window in the GUI (ie View execution statistics in on the Execution window) the dialog can be closed by clicking on the *Close* button in the lower-right corner.
+
+* The %selectedfile names has been added to the GUI variables. This enables to call the text editor for the symlinks in the working directory, and not to open the file referenced by the symlink. Using this variable in the text editor command makes `ctags` program work as intended.
+
+*Fixed bugs*
+
+* The compiler issued misleading warning messages when it found circular imports between the TTCN–3 and ASN.1 modules. Irrelevant module names were listed and the closing module of the loop was missing.
+
+* Several faults were corrected in the TTCN–3 and ASN.1 object identifier value checking algorithm of the compiler. Referenced values within `NameAndNumberForm` were not verified properly thus faulty input could result in unpredictable behavior during code generation. Referenced values containing module name and module objid caused memory leaks. If a TTCN–3 subtype constraint referred to an `objid` value having a faulty component the compiler stopped with an internal fatal error.
+
+* If a TTCN–3 or ASN.1 integer constant was so large that it did not fit in the internal memory representation of the compiler (actually 64-bit signed integers are used) the compiler stopped immediately with an internal fatal error during parsing. Such overflow situations now produce regular error messages and the compiler can continue analyzing the input.
+
+* The compiler generated erroneous (uncompilable) C++ code for type alias definitions of port types and signatures.
+
+* The configuration file parser of the run-time environment accepted some invalid DNS names in section `[GROUPS]`. However, some valid names (e.g. names containing the dash character or having parts containing numbers only) were rejected.
+
+* Circular recursions within parameterized template references could lead to infinite recursions in the compiler. A typical example for this situation: the body of a nonparameterized template refers to a parameterized template and one of the actual parameters is a reference to the non-parameterized template itself.
+
+* In some very rare cases the compiler generated invalid C++ code for message based port types. Data was read from an uninitialized memory location and in case of a specific bit pattern the compiler called both the message based and the procedure based code generator for the same port type.
+
+* The compiler generated wrong (uncompilable) C++ code if a TTCN–3 charstring value contained non-printable characters. Such characters were created during constant folding (e.g. the output of function `int2char`, which was evaluated by the compiler).
+
+* Some compiler error messages reporting invalid RAW attributes printed memory garbage instead of TTCN–3 identifiers.
+
+* The parser for the formal parameter lists of ASN.1 assignments was not implemented properly. It accepted all possible valid inputs, but some erroneous parameter lists as well.
+
+* The compiler did not support the value list and value range subtype constraints for type universal charstring. Such constructs caused compilation errors.
+
+* If a running operation was performed on an active, but already expired timer it disappeared from the list of active timers. After that the timer became invisible for operations `any timer.timeout` and all `timer.stop`.
+
+* The RAW decoder did not handle the empty record of and set of values properly. If the octet stream contained no elements the corresponding value remained unbound after the decoding instead of containing an empty value (i.e. _{ }_).
+
+* The GUI now shows a warning message if the symlink creation fails because a file named the same as the symlink exists in the working directory.
+
+[[version-1-5-pl7]]
+== Version 1.5.pl7
+
+Released on September 20, 2004.
+
+*New features*
+
+* The logformat utility no longer wraps the quadruples of universal charstring values into several lines. In previous versions it inserted a newline character after the commas like in case of compound (e.g. record or set) values. Now the valid quadruples are recognized and kept in the same line as the other parts of the string.
+
+* The semantic analysis was improved for procedure signatures. The error messages related to parameters became more intuitive.
+
+* The semantic checking of modified templates has been improved. For instance, if the derivation path contained a circular recursion loop with 4 steps, the compiler printed the same error message 4 times after each other. The differences in the base and modified template’s formal parameters are reported now in a more intuitive way.
+
+* The generated `Makefiles` distinguish between different Solaris versions to make it easier to create portable test ports. This is necessary because some socket handling function calls use different types of arguments on Solaris 2.6 and Solaris 8 systems. Now the `Makefile` generator of the compiler automatically recognizes the operating system version and sets the variable `PLATFORM` accordingly to `SOLARIS` on SunOS 5.6 (Solaris 2.6) and to `SOLARIS8` on `SunOS` 5.7 (Solaris 2.7) or above.
+
+* The logging of procedure based port operations has been improved. For instance, in previous versions the name of the signature was logged twice when transmitting calls or replies. In case of exceptions only the signature name was logged, the type of the exception itself was missing.
+
+* The snapshot manager of the run-time environment has been improved. It does not call the registered event handlers anymore when taking the first snapshot before evaluating an alternative. This results in higher execution speed and fair scheduling when running performance tests. In a typical case one call of the event handler can insert hundreds of messages into the port queue while an alt statement extracts only the first one. With the improved snapshot manager the event handlers are not called again while the port queue is not empty. The new algorithm has a drawback that it cannot cope with the `[else]` branches. Thus when the first `[else]` branch is executed the algorithm switches back to the original compatibility mode.
+
+* Log browser tool has been added as stand-alone tool to browse log files, or can be used in the GUI.
+
+* GUI Type browser tool has been added.
+
+* User menus and editor for the User menus have been added to the GUI. The editor can be accessed on the Preferences *window/User* menus tab.
+
+* Preferences window’s *General preferences* tab has been re-designed.
+
+* New Help menu is added. It contains help index, contents, keyword search, license information and re-designed *About* dialog.
+
+* The Process *output window* has been re-designed. Now it handles multiple running processes, each has its own output tab, and each can be stopped by the *Stop running* button.
+
+* The Make, Clearcase and CVS menus have been rewritten for the GUI. Now they are configurable user menus.
+
+* Test controls, test cases and test sets can be chosen and run by pressing the *Execute…* button in the Execution window.
+
+* Statistics about the test execution can be viewed by using the View *execution statistics* toolbar button on the Execution window.
+
+* The Execution window has been redesigned. Now it can be used both for single and parallel test execution. In parallel mode the default view now contains only the *Execute…* button. The detailed view can be switched on.
+
+* Project properties window has been re-designed. General, log file, build and HC execution properties can be set on different tabs.
+
+* The GUI supports starting multiple Host Controllers on different machines on the network.
+
+*Fixed bugs*
+
+* The compiler reported memory leak at termination if it encountered a `self.stop` or `mtc.stop` statement in its input module(s). A small memory block was not deallocated during the parsing of these constructs. This mistake had no other harmful side-effects.
+
+* The compiler generated invalid C\++ code if a TTCN–3 `activate` operation was used as a function statement. This construct was introduced in the most recent BNF and the newly written code generator forgot to put a semi-colon at the end of the equivalent C++ statement.
+
+* If a TTCN–3 or ASN.1 module contained an enumerated type and it was imported into another TTCN–3 module using the undocumented `"light" extension` attribute the C\++ equivalent of the importing module was uncompilable. This option disables the processing of some sections of the imported C++ header file from the importing module by using the C preprocessor to reduce the compilation time for large projects. The masked section contains mainly the C\++ equivalent classes of data types and in this case some in-line enumerated conversion functions in another (active) section referred to class members, which were invisible from the C++ translation unit of the importing module.
+
+* The compiler did not accept the hexadecimal string notation in ASN.1 modules for the values of the ANY type.
+
+* The BER encoder did not detect if the octets of the value for an ASN.1 ANY type contained some extra bytes of garbage after a complete TLV. The accepted erroneous octet stream could cause failure during decoding.
+
+* The behavior of the compiler was unpredictable when it processed asymmetric and non-internal procedure based port types. If the in and out lists contained different signatures the compiler usually crashed with a segmentation fault because the code generation routine tried to access the elements of the wrong list.
+
+* In parallel mode the test components aborted with signal SIGPIPE (Broken pipe) if the `ConsoleMask` logging option was set to LOG ALL and the Main Controller has terminated unexpectedly (e.g. because Control-C was pressed on the command line). The components recognized the end of their control connection and therefore they tried to send a log message through the terminated TCP channel.
+
+* The actual parameters of TTCN–3 entities were mapped to an improper data structure in the compiler’s abstract syntax tree. The corresponding BNF production is called `TemplateInstance`, which consists of an optional type, an optional derived reference and a mandatory template body. For instance, in the former implementation the type part (if it was present) was excluded from the semantic analysis. At the same time the error messages that are used to report incorrect actual parameters were also improved.
+
+* If the compiled Executable Test Suite was started with the command line switch `-l` (in order to obtain the list of test cases and control parts) and any internal error occurred during the initialization of the run-time environment, the ETS did not print anything and returned a successful (zero) exit status. Seeing this behavior it can be assumed that the modules contain no executable test cases or control parts. Now the ETS prints the error message to its `stderr` and returns a non-zero exit status.
+
+* The handling of the list of active event handlers was implemented incorrectly in the snapshot manager of the test components, which is a part of the Base Library. This could result in the unpredictable behavior of the test component in some race conditions. For example, if the termination of a port mapping was requested from a remote test component (by using an `unmap` operation) and at the same time data has arrived on the registered file descriptor of the corresponding Test Port, it could happen that the snapshot manager called the `Event Handler()` function of the Test Port after completing the `unmap` operation (i.e. calling user `unmap()`), which already performed the deactivation of the event handler.
+
+* The compiler did not accept the valid null value as initial value for component variables with type default or a component type. It reported semantic errors for those definitions.
+
+* The compiler aborted with an internal fatal error during error recovery (i.e. after reporting the error) if an invalid `SEQUENCE` notation was used for an ASN.1 REAL value.
+
+* The generated C\++ code could be uncompilable due to ambiguous function overloads in the class that implements TTCN–3 port types if the support of address type was turned on (i.e. the extension attribute `address` was used in the port type). The problem appeared only if the port type had outgoing messages or signatures and the address type was aliased to a built-in type the C++ equivalent class of which had a constructor with `int` parameter (e.g.` integer`, objid and all string types). The reason was a missing explicit cast in a generated function and the C++ compiler could not distinguish between component references and address values.
+
+* The compiler produced invalid C++ code if the to clause was present in a TTCN–3 `raise` port operation. The generated code contained an unnecessary extra closing parenthesis.
+
+* The semantic analyzer of the compiler did not report error if it encountered a length restriction or `ifpresent` matching mechanism in an actual value parameter of a template or function. It simply ignored the extra matching attributes and analyzed the specific value only. The generated C++ code was uncompilable in these cases.
+
+* The special component references such as `null`, `mtc`, `system` and `self` were not handled in component `start` operations. Thus the run-time error messages were cryptic when the argument of start was one of the above.
+
+* The entries of the alphabetical index in this document contained wrong page numbers. This was because the index was built before the table of contents and the pages occupied by the latter were neglected.
+
+* The RAW type descriptor of charstring type was missing causing segmentation fault during RAW encoding/decoding.
+
+* Utility `*ttcn3 logmerge*` printed garbage characters to the output if the component identifier part of input file name was longer than 30 characters. By default the component identifier is the numeric component reference, which cannot be so long, but in case of custom filename skeletons that part can contain any string.
+
+* The semantic analyzer of the compiler could reject some valid TTCN–3 constant definitions by printing mysterious error messages. The problem occurred if a referenced value with field or array sub-references pointed to a sub-field of another referenced compound value.
+
+* There were some minor mistakes in the semantic checking algorithms of value ranges within template bodies: The compiler did not check the upper bound if the lower bound was set to minus infinity. The `ifpresent` matching attribute of value ranges was reported twice if it was inappropriate.
+
+* The ASN.1 parser of the compiler did not accept the construct `ObjectClassFieldType` in `FixedTypeValueFieldSpec`.
+
+* The semantic analyzer of the compiler was unable to detect circular recursion loops in template references.
+
+* Infinite type recursions (e.g. when a TTCN–3 record type contains itself as a mandatory field) caused stack overflow and segmentation fault in the compiler. Moreover, the compiler was unable to detect the similar embedded recursions within constants and templates of valid recursive types (e.g. when a field of a structured value refers back to the whole value).
+
+[[version-1-5-pl6]]
+== Version 1.5.pl6
+
+*Released on June 11, 2004.*
+
+*New features*
+
+* The compiler and the run-time environment supports the following non-standard TTCN–3 language extensions, which allow the dynamic creation of templates during test execution. In the future these constructs will be added to the TTCN–3 standard in the same or very similar form.
+
+* Functions and external functions may return templates (i.e. all permitted matching mechanisms in addition to specific values) if the return type is defined as template.
+
+* It is allowed to define template variables at any place where the definition of regular (value) variables is permitted. The value of such variables may be dynamically assigned and they can carry any permitted matching mechanism.
+
+* It is allowed to pass template parameters to functions, `altsteps` and `testcases` by reference. Those parameters are denoted by the keywords `out` or `inout` similarly to value parameters. The actual parameters shall be template variables.
+
+* The conversion functions related to enumerated types are no longer global C functions. They were moved to static members of the value class. This makes easier to write generic C++ template functions in Test Ports that can handle any enumerated type.
+
+* The script `*ttcn3 start*` handles the configuration files automatically. If it finds a file named `<ETS name>.cfg` in its current working directory it passes the file to MC as a command line argument.
+
+* New compiler flag `-B` added to generate browserdata.dat needed by the visual type browser (part of GUI).
+
+* The RAW attribute `HEXORDER` is now applicable to the octetstring type besides hexstring type. The `HEXORDER(high)` settings will twist the nibbles within an octet during encoding and decoding.
+
+* The new command `make check` was introduced in the `Makefile` generated by the compiler, which performs syntax and semantic checks on the TTCN–3 and ASN.1 modules.
+
+*Fixed bugs*
+
+* The Main Controller behaved incorrectly during the shutdown procedure after the `exit` command. There was an unhandled race condition between the internal threads, which had noticeable effects only on Linux. The MC sometimes reported memory leaks or segmentation fault occurred or the final _Shutdown complete._ message was missing. On other platforms the problem remained hidden due to the different thread scheduling algorithms of the operating systems.
+
+* The type descriptor needed for the RAW encoding of the boolean type was missing from the run-time environment. This resulted in segmentation fault if a message containing a boolean field was encoded or decoded.
+
+* The compiler accepted an invalid syntax for catching timeout on procedure based ports. The string `catch timeout` was interpreted as a `catch` operation in addition to the standard `PortReference.catch(timeout)` notation. Moreover, the standard syntax produced invalid C\++ output, only the irregular variant resulted in working code. Only the standard syntax is accepted from now, and it is translated to a valid C++ code.
+
+* The compiler returned a misleading successful (zero) exit status if it encountered a general problem with an input file (e.g. the file could not be opened or classified as a TTCN–3 or ASN.1 module).
+
+* The Main Controller did not set the close-on-exec flag on its socket file descriptors that were used for communication with the other processes of the test system (HCs and test components). As a result of this all commands launched from the user interface (e.g. the text editor started from the GUI) inherited the open files. If the process did not finish before the end of the test session the MC could not close the TCP connections properly.
+
+[[version-1-5-pl5]]
+== Version 1.5.pl5
+
+Released on April 30, 2004.
+
+*New features*
+
+* The compiler is able to generate `Makefiles` to be used in single mode with the newly introduced command line switch `-s`.
+
+* The `Makefile` generator of the compiler recognizes if a given C++ source file is generated from one of the TTCN–3 or ASN.1 modules. In this case a warning is issued and the given file is not added to the list of USER SOURCES.
+
+* The compiler became less strict regarding the usage of semi-colons within `TTCN–3modulepar` blocks. The compiler treats the semi-colons optional, but it issues a warning if the input does not conform to the standard TTCN–3 BNF.
+
+* If the Test Port writer tries to register the event handler on a bad (e.g. nonexistent) file descriptor, the run-time environment reports this error immediately when Install Handler member function is called. In earlier versions the error was detected later by the select system call when taking a new snapshot. It was more difficult to determine the origin of the error if more than one Test Ports were used in the same test component.
+
+* The logging of location information has been improved. The line numbers are more accurate (e.g. when a TTCN–3 function is called from a send or receive template). It is possible to log the entire call stack and the name of the current TTCN–3 function, testcase or altstep.
+
+* The compiler prints correct location information for errors and warnings found in ASN.1 `OBJECT IDENTIFIER`, Relative-OID and TTCN–3 `objid` values. The error recovery is also supported in these values. In earlier versions the compiler stopped after finding the first error in these values.
+
+*Fixed bugs*
+
+* The compiler terminated with a segmentation fault during error recovery if it encountered more than one opening brackets (_{_) without closing pairs in ASN.1 modules.
+
+* The compiler aborted with an internal fatal error if a referenced value or template of wrong type was used as a template for an enumerated type. The error occurred when the compiler tried to print the ’type mismatch’ error message.
+
+* The compiler aborted with an internal fatal error instead of printing the appropriate error message if the empty record/set value (i.e. _{ }_) was given as a TTCN–3 template for a union type. If the union template contains (incorrectly) more than one selected fields, the compiler checks now every field template against the corresponding field type after printing the error message.
+
+* If the compiler generated a `Makefile` to be used with GNU make and all user source files had the `.cc` suffix, but one or more of them did not have its own header file, the suffix substitution rule was not used to obtain the list of object files. In this case only the user header files have to be explicitly enumerated, the names of object files do not need to be enumerated.
+
+* The `sizeof` built-in function could not be used on optional record or set fields (or their ASN.1 equivalents) if the type of the field was a `record of` or `set of` type. The generated C++ code did not compile in these cases, the compiler complained about no matching function.
+
+* If the body of a parameterized template used a formal parameter with field or array sub-references, the compiler evaluated the type of the reference expression incorrectly and thus reported type mismatches on valid templates. For instance, if the type of a formal parameter was a record with an integer field then the compiler assumed that the type of the formal parameter reference with the field sub-reference is the record type and not integer.
+
+* The compiler reported fake circular value recursion if an expression within an array index contained a nested array reference. The reason was that the names of some nodes in the compiler’s internal syntax tree were not set and the recursion detection algorithm saw empty strings instead of the real names.
+
+* The ASN.1 parser of the compiler did not consider the default tagging method correctly. If an embedded block (e.g. a `CHOICE` type) contained tagged types, the compiler decided whether to use implicit or explicit tags based on the default tagging method of the lastly parsed ASN.1 module instead of the current module. The problem was visible only if the input ASN.1 modules did not use the same default tagging method, which happens rarely.
+
+* The type descriptor structures in the Base Library were not declared for TTCN–3 type universal charstring. This caused compilation errors in the generated C++ code if the universal charstring type was embedded into a record, set or union type. The problem did not affect the ASN.1 character string types.
+* The precedence requirements for RAW attributes `PRESENCE` and `CROSSTAG` were not checked at compilation. Such kinds of errors caused dynamic test case errors (i.e. when the field that determines the presence or selection of another field is encoded at a later position in the message than the field it points to). These problems are now detected by the compiler and no C++ code is generated for faulty types.
+
+* The utility `*ttcn3 logformat*` did not interpret the command line switch `-s` properly (i.e. it did not split up the log of each test case into separate files) if the input log file contained location information. The logformat utility supports now also the newly introduced location information formats (stack traces, etc.).
+
+* Some weird and recursive use of `COMPONENTS OF` construct in ASN.1 modules could cause the unpredictable behavior of the compiler (segmentation fault, bus error, etc.).
+
+* The compiler aborted with an internal fatal error during semantic analysis in the following case: The operand of an expression in a template body or component type definition referred to a module parameter or a formal parameter of the template, that is, the value of it could not be evaluated at compilation. Moreover, the type of the corresponding module parameter or formal parameter was a referenced type pointing to another referenced type (i.e. the chain of type references contained at least two elements).
+
+* The compiler aborted with an internal fatal error during semantic analysis if an expression of type universal charstring contained references that cannot be evaluated at compilation time (e.g. references pointing to module parameters or formal parameters of the template).
+
+* The Main Controller reported memory leak at exiting if its connection towards MTC had terminated unexpectedly (e.g. due to the crash of MTC).
+
+* The compiler reported memory leak if a string element was referred in an operand of an expression.
+
+* The compiler generated wrong type descriptors for BER decoding of an ASN.1 `SEQUENCE OF` or `SET OF` types. The user-defined tags of the enclosed type were ignored during decoding.
+
+[[version-1-5-pl4]]
+== Version 1.5.pl4
+
+*Released on March 19, 2004.*
+
+*New features*
+
+* The variables and templates of some types in the run-time environment occupy less memory than before.
+
+* The expect script `*ttcn3 start*` launches the Main Controller from `$TTCN3 DIR/bin` if the environment variable is set.
+
+*Fixed bugs*
+
+* The internal encoder of the run-time environment stuck in an infinite loop when it tried to encode integer value -2147483648. This could occur when the above value was sent over connected ports or passed to functions to be started on PTCs.
+*
+The run-time environment crashed with a dynamic test case error when if a template was initialized with an omitted optional field containing an optional ASN.1 `NULL` type.
+
+* The compiler generated implicit tags instead of explicit ones when "Tag Type" was used for a "DummyReference"  and the referenced type was not `CHOICE` or open type. (For details, see link:https://www.itu.int/rec/T-REC-X.680-200207-S[Information Technology, Abstract Syntax Notation One (ASN.1): Specification of basic notation] clause 30.6c.)
+
+* The ASN.1 parser did not accept the {} value for `SEQUENCE` and `SET` types.
+
+* The mapping of some ASN.1 character string types were wrong: TeletexString, VideotexString, GraphicString and GeneralString must be mapped to universal charstring (and not charstring) according to link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/03.01.01_60/es_20187307v030101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCN–3].
+
+* The semantic checker accepted (and checked) named numbers for ASN.1 integers in TTCN–3 templates (but the generated code was invalid).
+
+* The RAW coding of empty record/set types went wrong in version 1.5.pl3 (the object files could not be linked because of missing member functions).
+
+* The RAW decoding of octetstring values that are not beginning at octet boundary was erroneous (no error message but incorrect value).
+
+* The Main Controller caused memory corruption (which could result in segmentation fault, bus error or other unpredictable behavior) if its control connection towards MTC terminated unexpectedly during the testcase. The MC tried to read and modify some internal memory areas during the error handling procedure that were previously deallocated.
+
+[[version-1-5-pl3]]
+== Version 1.5.pl3
+
+Released on February 27, 2004.
+
+*New features*
+
+* The built-in TTCN–3 type universal charstring and ASN.1 character string types with multiple-byte character sets are now supported.
+
+* The unrestricted character string type and selection types are now supported by the ASN.1 front-end of the compiler.
+
+* The RAW encoder/decoder allows to use referenced values in attributes `PRESENCE`, `TAG` and `CROSSTAG`. The references shall point to constant definitions of the right type. In earlier versions only literal values were accepted in RAW attributes.
+
+* If a value of a set of type does not match the respective template the run-time environment produces more verbose results in the log. Formerly only the nonmatching template and value were logged as a whole. In addition to this the newly implemented heuristic algorithm prints the following:
+
+* Each element of the value (including its index) that has no matching pair in the template.
+
+* Each element of the template (including its index) that has no matching pair in the value.
+
+* Every matching value _$_ template index pairs. +
+
+NOTE: Although it is trivial to show a possible successful matching, it is very complicated to develop an exact algorithm to present the reason of mismatch. It can be theoretically proven that the matching fails if and only if there exists a subset of values (or templates, symmetrically) with _k_ elements, the elements of which has less than _k_ pairs in the template (or value) altogether. The exact algorithm should show the minimal ones of these sets with the respective pairs. Our heuristics present only those trivial subsets that have _k_ = 1 elements, which give useful hints in the majority of practical cases.
+
+* The static run-time memory usage of TTCN–3 port instances was significantly reduced (from about 1000 bytes per port to 60 bytes). The majority of this memory block contained file descriptor bit masks that were moved to the dynamically allocated heap area. This is an important improvement since all UNIX processes that implement TTCN–3 test components contain all port instances of all component types defined in the test suite. In complex test setups (with many component types) the majority of port instances are inactive since they belong to other component types. On operating systems that do not support the copy-on-write mechanism each inactive port instance on every test component used about one kilobyte of memory unnecessarily.
+
+* The first line of all log files contain the version number of the TTCN–3 Test Executor in both single and parallel modes.
+
+* The predefined conversion functions int2char, char2int and str2int behave according to the new (still unpublished) TTCN–3 semantics. That is, they cause a dynamic test case error if their output is invalid instead of returning a dummy result. These changes were necessary to be consistent with the newly implemented int2unichar and unichar2int functions.
+
+* Value range templates are now supported for both charstring and universal charstring types. The upper and lower bound of such ranges shall be one character long string values since they denote the smallest and largest character positions of the permitted character set.
+
+* Some anachronistic TTCN–3 syntax variants were removed from the compiler: The to keyword cannot be used in range definitions either in subtype constraints or in template bodies instead of two dots anymore.
+
+* The compiler did not allow negative integer values to be assigned to TTCN–3 enumerated values due to a BNF bug in the standard. The negative numbers are now accepted just like in ASN.1 (or the embedded ASN.1 tables of converted TTCN–2 test suites).
+
+* The operation `mtc.stop` is now supported. If it is executed on a PTC the execution of the current test case (including all active PTCs) will be interrupted immediately. The execution continues with the next test case or the next statement of the control part.
+
+*Fixed bugs*
+
+* If the `-E` (enum-hack) switch was used the compiler generated invalid C\++ code for those ASN.1 enumerated values that are keywords in both TTCN–3 and C++ languages (e.g. true).
+
+* If an ASN.1 `SEQUENCE`, `SET` or `CHOICE` type definition contained a syntax error the error recovery routines of the compiler did not work properly. Thus the compiler could fail with internal error messages or produce memory leaks later during the semantic analysis.
+
+* The infinite type recursion detection algorithm of the compiler could cause internal errors on some kinds of recursive type definitions. The algorithm was re-designed so that it is started only from top-level types. In addition to solving the above problem this makes the compiler a bit faster.
+
+* If a field of an ASN.1 object class had a default setting the parser did not allow the field to be omitted in object definitions.
+
+* Some mis-encoded data streams could cause segmentation faults in the BER decoder. If the length of some strings was encoded in a faulty way the decoder interpreted it as a very large number and tried to allocate a too large buffer for the value.
+
+* In some cases the run-time environment called the `Event Handler` of a Test Port unnecessarily twice within the same snapshot. This might happen if the first call of `Event Handler` used the `Uninstall Handler` and `Install Handler` primitives after each other. At re-installation the event handler was inserted at the end of active event handlers’ list thus the list iterator reached it again. Now the run-time environment keeps track of each event handler whether it was called in the current snapshot.
+
+* If a TTCN–3 string element was assigned to the owner string the assigned value might be incorrect. The problem occurred with all string types: bitstring, hexstring, octetstring and charstring. The reason was the faulty implementation of the respective operators in the run-time environment. The operators deallocated the original string’s memory area first and took the value of string element after that.
+
+* If a RAW encoding attribute of a TTCN–3 type contained a syntax error the file name in the compiler error message pointed to the lastly parsed TTCN–3 file instead of the faulty one. Only the line number information was correct. Moreover, the error message did not contain the reason of the error.
+
+* The compiler generated invalid C++ code if the `PRESENCE` RAW attributes contained nested field references.
+
+* If a TTCN–3 default reference was logged, which has already deactivated, the `log()` statement could have unpredictable results (e.g. segmentation fault, irrelevant printout, etc.)
+
+* If a parameterized ASN.1 object assignment was referenced without an actual parameter list the compiler crashed with a segmentation fault after printing the relevant error message.
+
+* If an ASN.1 object assignment has referenced itself recursively the recursion detection routine of the compiler turned into an infinite recursion and printed endless error messages.
+
+* If the component type initialization failed on a PTC (because, for instance, the initial value of a component variable was unbound) its control connection towards MC was closed unexpectedly. This was reported on the MC console, but no error message refer to the component type. Now the PTCs do graceful termination even in such cases.
+
+[[version-1-5-pl2]]
+== Version 1.5.pl2
+
+Released on January 23, 2004.
+
+*New features*
+
+* The TTCN–3 parser of the compiler no longer recognizes the identifier parameters as a keyword. This is an obsolete variant of keyword `modulepar`, which was used in earlier versions of the TTCN–3 standard.
+
+* The elements of bitstring, hexstring, octetstring and charstring values, which can be accessed using an array-like syntax, can now be logged by TTCN–3 `log()` statements. In previous versions the `log()` statement printed nothing for string element arguments.
+
+* The compiler now gives warning messages if there are circular import chains at module level, e.g. module A imports things from module B, module B imports another things from module C and module C imports something from module A. This is legal in both ASN.1 and TTCN–3 , but the generated C++ code might be uncompilable.
+
+* `GeneralizedTime` and `UTCTime` have been prefixed with ASN in the library because also OSS library uses these identifiers. This prefix is consistent with some other type names (e.g. `ASN NULL`).
+
+* The behavior has changed to greedy while parsing identifiers in objects if there is a _{_ after the identifier. This is because that identifier can be a parameterized reference. The old behavior was to leave the block for the next element in the object class syntax because that can be object set or value set.
+
+*Fixed bugs*
+
+* The compiler issued irrelevant error messages for modified templates if the base template had formal parameter list. The error message complained about missing actual parameter lists, but the actual parameters of the base template shall not be specified according to TTCN–3 syntax.
+
+* The compiler aborted with an internal fatal error if the base template reference of a modified template pointed to a definition other than a template. _•_ The compiler generated invalid C\++ code for some ASN.1 constructs if the enumhack (`-E`) option was used. If an ASN.1 type contained an embedded (unnamed) ENUMERATED type the C++ `enum` values were incorrectly prefixed in value assignments for such types.
+
+* The compiler crashed with a segmentation fault if an actual parameter of an altstep invocation contained an in-line compound expression. The C\++ mapping of such constructs is still unsolved due to the lack of full semantic analysis. The compiler now continues the parsing and substitutes the unsupported parameter with the comment /* NOT SUPPORTED */ in the output code, which will cause a C++ compilation error.
+
+* The compiler generated erroneous C\++ code for certain legal TTCN–3 constructs. Let us assume that the name P was used to identify a component variable in component type A. If a function, altstep or testcase had a runs on clause other than A and a formal parameter named `P` the resulting C++ code did not compile if parameter `P` was used in the function body. The reason is that the TTCN–3 component type scoping is solved using tricky C preprocessor macros in the generated code. Due to the wrong placement of preprocessor statements different name substitution rules were applied on formal parameter list and function body.
+
+* If the user `unmap` function of a Test Port called Install Handler the event handler could remain active after the deactivation of the port. This could result in unexpected Event Handler calls and warnings when the test component terminated.
+
+* The functions of TTCN `logger` caused segmentation fault if one tried to create log entries when the logging was already shut down at test component termination. These late log events are now silently ignored by the logger.
+
+* The RAW decoding of record with optional elements may fail if TAG attribute used to identify the optional elements.
+
+* Fixed the incorrect RAW encoding of HEXSTRING if HEXORDER(high) was specified and the field is started at the 4th bit of the octet.
+
+* The internal hostid calculation algorithm worked unstable on Windows XP. The hostid of a given computer could change between successive reboots, which made host licensing impossible on computers running XP. The algorithm included a registry key in the hostid calculation that could be modified at system startup. This problem did not appear on other Windows versions such as 2000, NT or 9X.
+
+* There was a fatal error if a module imported a symbol with the same name more than twice.
+
+[[version-1-5-pl1]]
+== Version 1.5.pl1
+
+Released on December 19, 2003.
+
+*New features*
+
+* TTCN–3 external constants and external functions are now included in semantic analysis, which means that they can be referred from template bodies.
+
+* The Main Controller supports the constraints about the location of newly created PTCs. This means the sections `[GROUPS]` and `[COMPONENTS]` of the configuration file are properly interpreted. The load balancing is done only within a subset of hosts (the so-called candidates) that fulfill the constraints set in the above two sections.
+
+* Type recursion loops that are terminated with optional record or set fields are now handled properly. For instance, it is now possible to define a record type, which contains itself as an optional field. Such types are useful to implement the TTCN–3 equivalents of linked list containers, where omit denotes the end of list. In former versions this construct caused the compiler to enter an infinite recursion loop, which finally resulted in a segmentation fault.
+
+* The run-time environment provides a more efficient implementation for local TTCN–3 port connections. If the two endpoints are located on the same test component a software loop is used between the two port objects instead of a TCP connection. This results in faster connection establishment or termination and more efficient data transfer through the connection.
+
+* As a special case of local port connections it is now supported that both endpoints of the connection is the same port. Although this is allowed by the TTCN–3 standard, the establishment of such looped connections failed with mysterious run-time errors in previous versions.
+
+* The `connect` and `disconnect` TTCN–3 operations are now supported in single mode as well. Of course, both endpoints of the port connections must reside on the MTC in single mode.
+
+* The run-time environment is now able to terminate those PTCs that entered an infinite loop without any receiving operation (e.g. by doing an infinite calculation). If a PTC does not respond to a stop request within a configurable amount of time the Main Controller instructs the Host Controller of the corresponding host to kill the uncontrollable UNIX process.
+
+* The ? and * wildcards in bitstring, hexstring and octetstring templates are accepted and the correct matching of those patterns is implemented.
+
+* The pattern construct in charstring templates and the additional predefined function `regexp` are now implemented. This means that the matching of TTCN–3 regular expressions and substring extraction based on them are now supported.
+
+* The ASN.1 types `EXTERNAL` and `EMBEDDED-PDV` are now supported including their BER encoding.
+
+* Associated SEQUENCE notation for REAL values in ASN.1 is now supported.
+
+* Metacharacter substitution was introduced in log file names, which means that the names of the log files are determined during execution. At the same time the log file naming convention became configurable in parallel mode as well.
+
+* Enhanced error recovery during ASN.1-parsing.
+
+* The RAW encoder/decoder contains significant improvements.
+
+*Fixed bugs*
+
+* The member function `cut()` of class TTCN Buffer in the run-time environment caused damages to the remaining contents of the buffer because of an incorrect memory handling technique. For instance, if the buffer contained two correct BER-encoded messages after each other then after decoding and cutting the first message the decoding of second one failed.
+
+* If the execution of the `[EXECUTE]` section was launched in parallel mode, that is, the `smtc` command was invoked without arguments the Main Controller did not give the prompt back until the execution is completely finished. This made it impossible, for instance, to monitor the actual test configuration (using the info command) or interrupt the execution (using the `stop` command) at any time.
+
+* The load balancing algorithm in the Main Controller did not count the MTC when choosing a location for a newly created PTC. For instance, if a test configuration, which required 3 PTCs, was distributed on two hosts it happened that the first host ran 2 PTCs in addition to the MTC while the second host had only one PTC.
+
+* The compiler generated invalid C++ code for TTCN–3 constants that referred to a sub-field of another constant (or ASN.1 value), which was imported from another module.
+
+* Use of TTCN–3 subtype constraints (e.g. value lists or length restrictions) caused memory leakage in the compiler if it was invoked with the `-p` (parse only) option. The memory responsibilities were incorrectly assigned in the syntax tree if the semantic analysis was bypassed.
+
+* The parse errors in ASN.1 modules (or embedded blocks within ASN.1 definitions) caused memory leaks within the compiler.
+
+* Compound templates (both with value list and assignment notation) were accepted by the compiler for objid and ASN.1 NULL types. The C++ code generated from such invalid input was also erroneous, of course.
+
+* When a modified template was written for a union type, which contained an embedded record the compiler did not allow missing fields for the inner record even if the same alternative of the union was selected as in the base template.
+
+* References to parameterized TTCN–3 entities (i.e. templates or functions) were accepted by the compiler without actual parameter lists in template bodies.
+
+* If a statement block within a TTCN–3 altstep contained local variable definitions the generated C++ code did not compile because of a missing pair of brackets.
+
+* Circular references within TTCN–3 constant expressions (that is, if the right-handside value of a constant definition referred back to the same constant) caused the compiler to abort after reporting the relevant error message.
+
+[[version-1-5-pl0]]
+== Version 1.5.pl0
+
+Released on October 31, 2003.
+
+*New features*
+
+* The compiler supports the semantic analysis of TTCN–3 templates including the parameterized and modified ones. Signatures and signature templates are also checked.
+
+* The constant, variable, port and timer declarations within TTCN–3 component types are now checked.
+
+* The run-time environment has a new option in the configuration file to append log files instead of overwriting.
+
+* The evaluation order of activated defaults has been reversed to be compliant with an accepted CR to TTCN–3 operational semantics. That is, the lastly activated default is tried first when matching snapshot in alt statements or stand-alone receiving operations.
+
+* In ASN.1 Component Relation Constraint, you can use multi-level parent reference (See link:https://www.itu.int/rec/T-REC-X.682-200207-S[Information Technology, Abstract Syntax Notation One (ASN.1): Constraint specification] X.682 clause 10.10b). If the Component Relation Constraint is broken, the decoder logs the value(s) of the constraining component(s).
+
+* The BER coder has many enhancements. The sorting of SET and SET OF components (needed by CER and DER) are done. `SET` values can be decoded regardless of the order of components. `REAL` decoding is supported (only base 10).
+
+*Fixed bugs*
+
+* When a TTCN–3 enumerated type was forward referenced within a module the compiler aborted with an internal fatal error if the enum hack (`-E`) option was used.
+
+* The compiler generated incorrect C++ code for some procedure-based port types. This caused memory corruption when an incoming call, reply or exception was extracted from the port queue, which could result in unpredictable behavior (segmentation faults, infinite loops, etc.) on some platforms.
+
+* When an individual testcase was executed in parallel mode (i.e. without the control part) the name of the module and testcase were swapped in the log (like this: `Executing test case MyModule in module MyTestCase.`).
+
+* The additional predefined function `int2hex` produced incorrect results. Every second hexadecimal digit of the output was zero regardless the input.
+
+* The concatenation operator (`&`) did not work properly for bitstring values if the length of the left operand was not a multiple of eight. The last few bits of the result contained memory garbage instead of the correct value.
+
+* If the Main Controller encountered a socket error in one of the control connections (e.g. a broken TCP link because of a network failure) it entered an infinite loop and flooded the console with error messages.
+
+* The log filter utility performed seek operations on its input file. Thus it could handle only regular files properly as input and produced incorrect (truncated) results if its input was a UNIX pipe.
+
+* The select system call could fail on Solaris with an Invalid argument error code in the snapshot handler of the run-time environment when extremely large timer durations were usedfootnote:[This case is different from infinite blocking, that is, when no timers are running at all.]. The reason of the failure is a limitation in the select implementation of the operating system because it does not accept timeout values that are larger than an undocumented limit. Now the timeout values are truncated to a safe limit (which is about 26 days), that is, the test components never block for longer time than this value. In case of truncation a warning message is issued. If nothing happened within this time interval the process will wake up and block again.
+
+* The test execution could stop with strange internal error messages in parallel mode if guard timers were used in execute statements. This happened if the MTC was performing a configuration operation (e.g.`create` or `connect`) at the moment when the guard timer expired. This situation is now explicitly handled in the internal control protocols, which start an error recovery procedure to interrupt the current test case and continue with the control part.
+
+[[version-1-4-pl5]]
+== Version 1.4.pl5
+
+Released on October 2, 2003.
+
+*Fixed bugs*
+
+The ASN.1 front-end of the compiler crashed with an Internal Error in some cases when checking the tags of open types. For instance, this made impossible the parsing of MAP protocol specification.
+
+[[version-1-4-pl4]]
+== Version 1.4.pl4
+
+Released on September 19, 2003.
+
+*New features*
+
+* The generated C++ code no longer uses template classes for the realization of enumerated, record of and set of types and their ASN.1 equivalents. This results in significantly faster compilation of the generated code especially in case of large projects. The generated flat code provides the same (or backward compatible) API for the Test Ports.
+
+* The compiler supports semantic analysis and automatic ordering for TTCN–3 module (global) constants. The semantic checks include the folding of expressions, which results in more compact and faster C++ code. The component constants and local constants are still unchecked.
+
+* The compiler error messages include location information (file name and line number) for the faulty language elements. This helps a lot in finding the faults in TTCN–3 and ASN.1 modules.
+
+* The compiler supports error recovery, that is, it does not stop after the first error message, but it goes further to find more errors. At the same time it implements advanced error masking techniques to avoid snowball effect.
+
+* Signatures, procedure based ports and related port operations (i.e.`call`, `getcall`, `reply`, `getreply`, `raise`, `catch`) are now supported. The in-line signature templates are still not supported like the in-line message templates.
+
+* It is now possible to combine value lists and value ranges in templates for integer and float types.
+
+* It is now possible to give a `match` operation as an argument to the TTCN–3 log statements. This logs the matching process field-by-field (like in case of failed receive statements) instead of the boolean result.
+
+* The following new Main Controller commands were introduced: `info`, `stop`, `pause`, `continue`, `log`. See Section 12.3.1 of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/userguide[TITAN TTCN–3 User Guide] for details.
+
+*Fixed bugs*
+
+* The compiler no longer gets confused during `Makefile` generation if it finds a file with a name identical to a TTCN–3 or ASN.1 module. An executable program, which was built with a previous `Makefile`, can have such name.
+
+* The run-time environment now detects if the file descriptor returned by the operating system is larger than the system limit `FD_SETSIZE` footnote:[FD SETSIZE is usually set to 1024. This implies that the test components cannot have more than1024 simultaneous port connections by default. This limitation is not applicable to the Main Controller (it uses poll instead of select) so you can work around this situation by using hierarchical test configuration with proxy components. Moreover, if you want to exceed this limit FD SETSIZE can be increased on some operating systems (e. g. Linux or Solaris 8). In this case you will need a special binary package, which is available on request.]. The internal event handler mechanism of the test components uses the _select_ system call to handle messages on port connections. Only the file descriptors that are smaller than FD SETSIZE can be used with _select_, so if a newly created socket file descriptor reaches this limit a proper error message is printed instead of the unpredictable behavior of former releases.
+
+* The run-time environment put misleading location information into the log if a TTCN–3 function was called from a non-parameterized template. The location info pointed to the last line of the called function.
+
+* The logging of template matching (which is done at failed receive events if the logging of event `TTCN MATCHING` is enabled) did not work properly for record of and set of types and their ASN.1 equivalents. The algorithm did not compare the sub-fields of the elements even if the template had the same number of elements. Now the field-by-field comparison is done, but only if the template and the received value has the same number of elements.
+
+* The compiler did not translate the TTCN–3 identifiers properly if they ended up by more than one underscore character. For example, 2 underscores at the end became 3 underscores in C++ instead of 4.
+
+* The error messages given by the compiler when detecting syntax errors in the RAW encoding attributes referred to the wrong file. The error messages always contained the file name of the lastly parsed TTCN–3 module, but the line numbers were correct.
+
+* The template matching algorithm for the set of type construct did not work properly in some rare cases. Sometimes it did not find the right pairs when sophisticated graphs were needed for this, thus it returned false instead of true.
+
+* The _>>_ (shift right) operator produced invalid results for some bitstring and hexstring values. If the string operand was longer than 1 byte (8 bits or 2 nibbles, respectively) the last few bits or nibbles of the result could contain memory garbage instead of the correct value.
+
+* TTCN–3 identifiers `stdin`, `stdout` and `stderr` are handled by the compiler as if they were C++ keywords to avoid interferences with the libc macros.
+
+[[version-1-4-pl3]]
+== Version 1.4.pl3
+
+Released on July 23, 2003.
+
+*New features*
+
+* The compiler has a new option, which allows to parse its input modules without performing semantic analysis or code generation. Consequently, the command line switch `-s` has been introduced and the meaning of `-p` changed. Now `-p` means parsing only and `-s` includes semantic checks as well.
+
+* The size of the C++ classes that the compiler generates for record/set/union types or their ASN.1 equivalents was reduced by about 10 %. This results in smaller executables and faster compilation (especially in case of incremental builds).
+
+* The compiler is now capable of selective code generation when doing incremental builds. It means that after performing a relatively fast parsing and semantic analysis on all modules the C++ code is generated only for those modules that have changed since the last build or import from changed modules. This feature can substantially reduce the time needed for an incremental compilation in case of large projects. Of course, the capability of selective updating has been preserved.
+
+* The interrupt signal (which can be raised, for example, by pressing Control-C while the executable tests are running) is now handled explicitly in single mode. If the signal is received the run-time environment tries to clean up all resources (destroys all existing port mappings, calls the destructors of global objects, etc.) before terminating instead of exiting immediately. This was necessary for implementing test ports on the top of some poorly designed APIs, which require the application level connections to be terminated explicitly (although the communication is carried by TCP).
+
+* The Main Controller now supports batch mode execution if the variable `NumHCs` is set in the section `[MAIN CONTROLLER]` of the configuration file.
+
+*Fixed bugs*
+
+* The values of empty record/set types (e.g. type record `MyRecord` _{ }_ were always logged as _{ }_, even if the value was unbound. This could result in misleading behavior during test port development.
+
+* The RAW decoder decoded the fixed length bitstring fields with incorrect length if the `FIELDLENGTH` value was greater than 8 and the field did not start on octet boundary.
+
+* The accuracy of internal encoding mechanisms that are used for the transmission of TTCN–3 float and ASN.1 REAL values has been enhanced. Formerly the encoding considered 6 decimal digits only, which was too few in some cases. Now the encoded value can carry up to 16 decimal digits which provides lossless transmission for the 48-bit mantissa of 64-bit floating point values.
+
+* The run-time environment could produce misleading error messages in parallel mode at initialization. If the initialization of non-parameterized templates failed (e.g. due to an unspecified field or forward referencing) the error message that was displayed on MC console complained about an error in the configuration file.
+
+* The `start` and `stop` port operations are now implemented exactly according to the TTCN–3 semantics. That is, not the `stop` but the `start` operation clears the remaining messages from the queue.
+
+* The Main Controller did not give the prompt back if the `smtc` command was issued without arguments until all items of the `[EXECUTE]` section have been executed.
+
+[[version-1-4-pl2]]
+== Version 1.4.pl2
+
+Released on June 30, 2003.
+
+*New features*
+
+* Value returning by started PTC functions and storing the returned values in `done` operations are now supported.
+
+* Improved argument processing (file and module auto-detection) when generating `Makefile` skeletons.
+
+* Support of obsolete TTCN–3 language constructs (such as named alts, old-style notation for imports and module parameters) were removed from the compiler. Consequently the old keywords are no longer reserved.
+
+*Fixed bugs*
+
+* There was a memory corruption bug in the ASN.1 front-end of the compiler, which could result in invalid C++ identifiers in the generated code. The phenomenon was libc dependent and appeared only on some Linux platforms.
+
+* The Main Controller did not stop if the given configuration file did not exist or contained syntax errors. It assumed that the configuration file is empty in this cases.
+
+* The handling of configuration file errors in parallel mode was improved. That is, no deadlock occurs in this case.
+
+* The make archive rule of the generated `Makefile` passed incorrect arguments to tar.
+
+* Handling of ObjectFieldSetting and ObjectSetFieldSetting.
+
+* Chains in InformationFromObject(s), ObjectSetFromObjects.
+
+* Circular references through InformationFromObjects construct caused segfault in some rare cases.
+
+* If `-P` was used, some assignments were missing from the generated code that should not.
+
+* The Main Controller on Linux stopped with an error message indicating a failure in `poll()` system call when its X terminal window was resized.
+
+* The ASN.1 front-end of the compiler did not check the existence of imported definitions if they were not used. For example, if module A imports X from module B, and module B exports all (or simply doesn’t have an exports statement), then it wasn’t checked that the module B really has an assignment or imported symbol with name X. So, when X was missing, but wasn’t used in module A, there was no error message.
+
+[[version-1-4-pl1]]
+== Version 1.4.pl1
+
+Released on June 13, 2003.
+
+*New features*
+
+* Hexstring related additional predefined (conversion) functions were implemented. Namely: `hex2int`, `int2hex`, `hex2str`, `str2hex`, `bit2hex`, `hex2bit`, `hex2oct`, `oct2hex` and `substr` with hexstring as first argument.
+
+* The obsolete TTCN–3 type char was removed from the run-time environment (including the Test Port API). For backward compatibility all occurrences of char is substituted with type charstring.
+
+* The compiler command line switch `-P` was introduced to specify top-level PDUs in order to disable the code generation for unreachable data types.
+
+* Anachronistic timer duration units are no longer supported. Therefore the words `min`, `s`, `ms`, etc. can now be used as regular identifiers.
+
+*Fixed bugs*
+
+* Sub-fields of optional record/set fields can now be directly referenced in TTCN–3 expressions and assignments.
+
+* The template matching mechanism for the set of type construct (which uses sophisticated graph-pairing algorithms) could stuck at infinite loops in some cases due to an improper variable initialization. The infinite loop included memory allocation thus the memory consumption of the executable grew rapidly after reaching this deadlock situation.
+
+* The `Makefile` generated by the compiler behaved incorrectly in case of incremental compilation because of a missing empty rule. The build process stopped immediately after the translation of TTCN–3 and ASN.1 modules and the C++ compiler was not invoked. The `make` command had to be issued again for the complete build. Moreover, in case of the non-GNU version the build procedure did not stop if the TTCN–3 /ASN.1 compiler returned unsuccessful exit status.
+
+* The `-E` (enum-hack) option generated invalid C\++ identifiers if the enumeration was a C/C++ keyword (e.g.`class`).
+
+* The default syntax (i.e. when `WITH SYNTAX` is not defined) of object classes was implemented incorrectly.
+
+[[version-1-4-pl0]]
+== Version 1.4.pl0
+
+Released on June 4, 2003.
+
+*New features*
+
+* One new, integrated compiler for TTCN–3 and ASN.1.
+
+* X.681-X.683 extensions of ASN.1 are now supported by the compiler.
+
+* Semantic analysis and automatic ordering for TTCN–3 data types.
+
+* TTCN–3 altsteps containing only an [else] branch are now accepted by the compiler as a language extension.
+
+* The PDF version of this User Documentation contains hyperlinks to the referenced sections.
+
+* The new structure for the generated `Makefile` eliminates the unnecessarily repeated compiler invocations when doing incremental builds.
+
+*Fixed bugs*
+
+* TTCN–3 predefined functions are distinguished from other user defined functions during parsing. As a consequence of this the number of arguments is checked at compilation and the statement `mytimer.start(int2float(5)`); is no longer interpreted as a component start operation.
+
+* The license verification procedure caused segmentation fault in all programs if the real UID of the program had no associated login name. This could happen on Cygwin or if the system administrator did some evil things. A proper error message is printed now in this case.
+
+* The RAW encoder/decoder functions were not generated for some structured TTCN–3 types due to a human mistake in the compiler source code.
+
+* TTCN–3 `execute` statements could not be used as expressions, meaning the final verdict of the corresponding testcase. This construct is now supported even if the testcase has a maximal duration.
+
+* Test cases can no longer be called as simple functions, only the execute statement is allowed.
+
+* An improper memory initialization in the templates of TTCN–3 type hexstring could cause segmentation faults in the run-time environment.
+
+* The member function user start of Test Ports is called implicitly by the run-timeenvironment when a testcase is started. If a fatal error occurred in this function (which was signaled with TTCN error) the error recovery routines have interrupted the execution immediately. Moreover, the error verdict was not counted in the final statistics line. Now in this situation only the corresponding testcase is aborted with error verdict and the execution will continue with the next one.
+
+* When execution was started in parallel mode and the MC detected a version or module checksum mismatch for one of the HCs, the error message appeared only in the log file of the corresponding HC. Now the error message given by the MC (indicating the reason of the failure) is printed to the standard error of the HC as well.
+
+* The expect script called `*ttcn3 start*` (see Section 12.3.4 of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/userguide[TITAN TTCN–3 User Guide] for details) was missing from the binary packages and the scripts delivered with versions 1.2.plx are not compatible with the command line interface of the new MC. A new version of the script was added to the packages. This seems to be more robust when handling console messages coming from the HC or TCs because the former one could cause deadlocks if the messages arrived too frequently.
+
+* When the `-l` command line switch was used with the ETS (in order to obtain the list of test cases and control parts) and the initialization of constants has failed the program exited with abort signal abnormally in both single and parallel modes. The exception caused by this fatal error is now caught and the program terminates with non-zero exit status after printing the error message.
+
+* If the initialization of constants or templates has failed at test startup the error message could include an inappropriate operating system error message. This was because some library calls have set the global variable `errno` to an inappropriate error code even if the library call was successful. As a work-around the `errno` variable is explicitly set to zero after such calls.
+
+* If an empty message (empty string) was logged from the test suite the logger signaled a fatal error message and exited immediately.
+
+[[version-1-3-pl0]]
+== Version 1.3.pl0
+
+Released on April 18, 2003.
+
+*New features*
+
+* The new MC supports the execution of individual test cases (without control part) in parallel mode as well.
+
+* The new MC supports the automatic distribution of the configuration file to multiple HCs over the network.
+
+* There are no longer static limits on the number of simultaneously active PTCs. The new MC is able to handle any number of PTCs if the limit on simultaneously open files is set to large enough in the operating system.
+
+* The new MC explicitly terminates the remained active PTCs at the end of each test case.
+
+* The checksums in the ETS are checked by the MC to avoid launching of inconsistent HCs in case of distributed execution.
+
+* The configuration operations in parallel mode are executed significantly faster because the Nagle algorithm is switched off on the control TCP connections.
+
+* The internal messages of the TTCN–3 run-time environment (control messages or messages sent on connected TTCN–3 ports) use a more compact encoding for integer attributes. The size of typical messages sent over TCP channels was reduced by 50%.
+
+* TTCN–3 `action` statements are now implemented. The argument is placed to the log with a dedicated severity. Similarly to the log statements it is allowed to pass not only fixed strings, but variables or templates to the action statements. Multiple arguments (separated by commas) are also supported.
+
+* Compound expressions are now allowed in TTCN–3 return statements.
+
+* Statement blocks following altstep instances are now accepted by the TTCN–3 compiler.
+
+* The special TTCN–3 `address` type is now supported (i.e. the user can define it). Address values can be used in port operations (in to or from clauses or in sender redirects) only if the corresponding port type has a special extension attribute.
+
+* Parameterized modified templates may have more parameters than the base template, even if the base template has no parameters. Additional parameters can be appended to the parameter list anywhere in the modification chain.
+
+* The TTCN–3 configuration operations `create`, `stop`, `connect`, `disconnect`, `map` and `unmap` produce more verbose information in the log files of all components that are involved in the operation.
+
+* The option `-e` (enum-hack) was introduced in the ASN.1 compiler to resolve name clashes between different enumerated types. Using this the ENUMERATED values seem like this: TYPENAME enum ENUMID.
+
+* The ASN.1 compiler translates large ASN.1 modules significantly faster than in the previous version due to the improved type checking algorithms.
+
+* The statistics line at the end of execution contains more information than before (e.g. the percentage of passed, failed, etc. test cases). The statistics information is also available in parallel mode. It is logged when the MTC terminates.
+
+* More robust error checking is performed in the run-time environment during logging. If writing to the log file fails at any time the execution will terminate immediately with a proper error message.
+
+*Fixed bugs*
+
+* The incorrect behavior of the old MC caused deadlocks if a `connect` or `map` operation was performed on an already established connection or mapping, or similarly if the `disconnect` or `unmap` operation referred to a non-existent connection or mapping. The situation was the same if a `stop` operation was performed on the component reference of an already terminated PTC. The new MC is robust enough to handle such situations.
+
+* The TTCN–3 `done` and `running` operations with `any component` or all component were incorrectly implemented in the old MC.
+
+* The calculation of test case verdicts was implemented in a non-standard way in the former versions (i.e. a successful `done` operation meant an implicit `setverdict`). Now the MTC receives and processes the final verdicts of all PTCs at the end of each test case in compliance with the standard.
+
+* The non-standard predefined function `float2str` used exponential notation if the argument was zero thus it resulted 0.000000e+00 instead of 0.000000.
+
+* The snapshot manager of the run-time environment now signals a dynamic testcase error if it has to block for infinite time. In former versions the execution stopped forever without any warning or error message. This situation can happen only in single mode when there are neither active timers nor active event handlers.
+
+* If an inactive timer was stopped an inappropriate duration (i.e. a memory garbage) was printed to the log after the warning message. Now only the warning is displayed in such cases.
+
+* Negative timer durations were not handled in the previous versions of the run-time environment. A negative default value for a timer produces now a warning. If a timer is started with a negative duration (which can be either explicit or the default one) a dynamic testcase error will now happen.
+
+* The incoming messages had incorrect line information in the log file if they were received during the evaluation of an alt statement. Those messages always pointed to the last branch, which could be in a default as well. Now the line information is set to the first line of the alt statement.
+
+* The TTCN–3 behavior statement `self.stop` was refused by the compiler, although it is allowed in the standard text. The reason for this was a bug in the official TTCN–3 BNF that disallows `self.stop`. The compiler now accepts `self.stop`, which has identical meaning as stop.
+
+* The TTCN–3 compiler generated invalid C++ code if an altstep was instantiated from the top-level alternative of another altstep in combination with a boolean guard expression. A closing bracket was missing in this case.
+
+* The ASN.1 compiler produced an inappropriate error message if in a module with AUTOMATIC TAGS a CHOICE type was included in a SEQUENCE with tagging.
+
+* The ASN.1 tag descriptor structures in the run-time environment were initialized in wrong order. Therefore dynamic testcase errors could happen during encoding/decoding with the error message ”The innermost tag is not explicit”.
+
+* Some parts of the C++ header file generated by the ASN.1 compiler was reordered to resolve some import related problems.
+
+* In parallel mode the log files are always placed in the current working directory of the HC even if the executable is started with a full pathname. In former versions if the HC was started with a pathname the logs where placed to the directory where the HC resided. Moreover, on Windows platforms the `.exe` suffix of the HC executables is also cut from the names of the log files.
+
+* The `make archive` command of the generated `Makefile` follows symbolic links when creating backups. If the TTCN–3 and/or ASN.1 modules are linked from another directory, the real files are stored in the backup instead of the meaningless symbolic link.
+
+* The identifiers that are reserved for internal purposes in the Base Library and do not contain underscore characters (such as `INTEGER`, `OCTETSTRING` or `PORT`) could not be used as TTCN–3 identifiers because of name clashes. The conflict is now resolved by appending a single underscore at the end of such identifiers thus they are freely usable in TTCN–3 modules.
+
+[[version-1-2-pl4]]
+== Version 1.2.pl4
+
+Released on February 10, 2003.
+
+*New features*
+
+* Host limited licensing are now supported on Windows platforms as well.
+
+* New non-standard conversion functions float2str and str2float were introduced.
+
+* The internal control protocols of the parallel test architecture were updated. The updates, which are the first steps in the migration toward version 1.3, are not backward compatible. Therefore the ETSes built with 1.2.pl4 must use the Main Controller of version 1.2.pl4 only. Similarly, the Main Controller of 1.2.pl4 does not work with ETSes built with earlier versions. Using incompatible versions may result in run-time errors or deadlocks.
+
+* The TTCN–3 compiler emits the repeated string (bitstring, hexstring, octetstring, charstring) and object identifier literals into the generated C++ source file only once for each module. This can reduce the size of binary object code by about 20-30% for modules containing mainly TTCN–3 templates.
+
+* All ASN.1 identifiers are printed in TTCN–3 form into the log file (underscores are used instead of hyphenation characters).
+
+*Fixed bugs*
+
+* The RAW encoder and decoder did not handle the `integer` fields properly if FIELDLENGTH was not a multiply of 8. For instance, 7-bit fields were mis-interpreted during both encoding and decoding.
+
+* The RAW decoder has left record of and set of fields unbound if no elements were received.
+
+* If a PTC has terminated with an error verdict a successful `done` operation on it caused Dynamic Testcase Error on the parent component.
+
+* Inappropriate source code information was reported at the end of PTC logs if the `LogSourceInfo` logging option was turned on.
+
+* The ETS could die with a segmentation fault during error recovery if the assignment of union, record of or set of value or template fields failed because of unbound sub-fields.
+
+* Float values that are either smaller than 10_−_4 or larger than 1010 in absolute value are logged in exponential notation. In previous versions all float values were logged in decimal dot notation so the small float values seemed as 0.000000.
+
+* The internal handling of TTCN–3 port mappings could cause the unpredictable behavior of the ETS on some platform/compiler combinations (e.g. on Debian Linux with GCC 2.95.4) because of memory corruption due to incorrect memory allocation methods.
+
+* If more than one empty record or set type was defined as incoming or outgoing type on a TTCN–3 port type the send or receive operations with in-line templates (like `EmptyRecordType`: _{}_) resulted in erroneous C++ code. The remained limitation is that the type name must be always present for in-line empty record templates even if the type is unambiguous.
+
+* The caching of status values in stand alone receiving statements (such as `receive`, `timeout` or `done` operations) was incorrectly implemented. If an activated default has returned with a repeat statement the ETS could hang in a live-lock or report a dynamic testcase error incorrectly.
+
+* The run-time configuration file parser did not accept ASN.1 identifiers (enumerated values, field names, etc.) that contained hyphenation character. Such identifiers can now be used in the configuration file either in the original ASN.1 form or in TTCN–3 form (i.e. the hyphenation characters are replaced by underscores). Both formats are equivalent.
+
+* The TTCN–3 compiler generated invalid or incorrectly working C++ code if a variable of a set type was initialized at the definition and the fields were not in the same order as in the type definition.
+
+[[version-1-2-pl3]]
+== Version 1.2.pl3
+
+Released on December 16, 2002.
+
+*New features*
+
+* TTCN–3 templates, even parameterized ones, can be printed to the log using `log(…)` statements like constants, variables. All wildcard combinations are handled properly.
+
+* TTCN–3 functions that have template parameters can be started on PTCs using component `start` operations.
+
+* The `hexstring` data type is now supported. Unfortunately the RAW encoder/decoder still does not work for `hexstring` fields.
+
+* If a `receive` port operation fails because the incoming message does not match the given template, the matching process can be logged field-by-field to make it easier to find the difference. This option is switched on if the event type `TTCN MATCHING` is enabled in logging filters.
+
+* Location information (that is, the name of the source file and line number) can be included in the log file for each TTCN–3 test event.
+
+* The TTCN–3 compiler accepts the latest published BNF (Rev. 12.7, v2.2.1). Of course, it is backward compatible and still accepts the obsolete keywords and constructs, such as named alts.
+
+* The cross-referencing between different kinds of TTCN–3 language elements was clarified. At the same time a two-phase module initialization scheme was implemented. The first phase is performed before, the second one is after processing the configuration file. At the same time the syntax of initializer functions for importable modules has changed.
+
+*Fixed bugs*
+
+* The precedence between TTCN–3 operators was revised. In former 1.2.plx versions the parser worked exactly as specified in ETSI’s TTCN–3 BNF. However, that BNF is wrong (it contradicts the standard text), because – for example – it assigns the same precedence level to operators `and`, `xor` and `or`. Now our parser works as it is specified in the standard text (i.e. as an average user expects).
+
+* The ETS crashed with segmentation fault if a TTCN–3 function with runs on clause was called directly from control part. A proper error message is printed now.
+
+* The compiler and the run-time environment accepted invalid range templates (i.e. if the upper bound was smaller than the lower) for integer or float types. The run-time environment prints now a proper error message during initialization.
+
+* Templates of built-in type charstring could not be initialized with string literals containing exactly one character. The compilation of the generated code failed because of a missing conversion operator.
+
+* The tag in the output of BER encoder could contain invalid primitive/constructed indicator bit in some rare cases. If an ASN.1 CHOICE type contained a built-in type (e.g. OCTET STRING) as field with implicit tagging, the encoder set the indicator bit to 1 (constructed) in the tag, but the value was a single octet string.
+
+* The RAW encoder did not handle properly the pointers to omitted optional fields. In this case the pointer must be set to 0, but it pointed to the next field.
+
+* The error and warning messages displayed during the processing of the with attributes of TTCN–3 data types for RAW encoding contained an invisible carriage return (CR) character at the beginning (like other error messages, which were fixed in the previous version).
+
+* The log formatter utility did not place a newline character into the formatted output when an opening bracket character (_{_) was followed immediately by a string literal (for example, when logging a `record of charstring` value).
+
+[[version-1-2-pl2]]
+== Version 1.2.pl2
+
+Released on October 11, 2002.
+
+*New features*
+
+* The internal string handling routines were rewritten in both TTCN–3 and ASN.1 compilers. The old functions were inefficient, especially when generating large C++ output files. The improved TTCN–3 compiler runs significantly (about 4 times, the ASN.1 compiler 2 times) faster on a typical input module.
+
+* The C\++ header and source files generated from TTCN–3 and ASN.1 type definitions were restructured so that the header files became smaller. This means faster compilation (with lower memory usage) from C++ to object module in case of the importing modules of those type definitions.
+
+* The error messages related to templates became more talkative for record/set/SEQUENCE and union/CHOICE types. This helps locating the error when debugging faulty template definitions. The type and field names are incorporated into the error strings.
+
+* The compiler is able to generate a smaller and less redundant `Makefile` to be used with GNU make.
+
+* The compiler incorporates source file and line number information into the dynamic testcase error messages of alt statements and stand-alone receiving operations.
+
+* The missing documentation of RAW and BER PDU encoders/decoders was added.
+
+* Two new log processing tools: `logmerge` and `logfilter`. See sections 13.1 and 13.2 of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/userguide[TITAN TTCN–3 User Guide].
+
+* The ETSes can print the list of the test cases and modules.
+
+*Fixed bugs*
+
+* One header file (Message `types.hh`) was missing from the binary distribution. This caused C++ compilation errors for startable TTCN–3 functions.
+
+* The `stop component` operation caused idle PTCs (i.e. PTCs that were just created and no `start` operation was performed on them) to abort with a core dump because of an uncaught C++ exception.
+
+* The `create`, `done`, component `start`, `stop` and `running` operations report proper error messages in single mode.
+
+* Operation any `component.done` caused a segmentation fault if no done operations were performed on that component before.
+
+* The executable test programs (both in single and parallel mode) caused segmentationfaults during the logging of the first message if the opening of log file was not successful. Now, a proper error message is printed and the test executor process exits immediately after a log file opening failure.
+
+* The ASN.1 `NULL` values were not interpreted properly by the TTCN–3 compiler.
+
+* Component `stop` operation hangs if it is performed on a PTC that is already terminated. This is due to bug in the Main Controller, which will be fixed later. A work-around for this was added to the Base Library: the `stop` operation returns immediately if the TC knows locally the termination of the target PTC (for example, if the `stop` operation is used subsequently after a done for the same component).
+
+* The error messages of the TTCN–3 compiler contained an invisible carriage return (CR) character at the beginning. This disturbed, for instance, Emacs when finding the location of the error.
+
+* The year and date were in the reverse order in the timestamps of log files when `TimeStampFormat` was set to `DateTime`. For example, 28/Sep/2002 was printed instead of 2002/Sep/28, as specified in this document.
+
+* Character strings that resemble to a format string of C function `printf` (containing %d %s, etc.) no longer cause problems in TTCN–3 log statements.
+
+* A `charstring` value that contained only one character (which can also be considered as a char value) could not be used as a template for receive operations on ports those incoming type was charstring.
+
+[[version-1-2-pl1]]
+== Version 1.2.pl1
+
+Released on August 16, 2002.
+
+*New features*
+
+* The `set of` type construct is now supported, including template matching.
+
+* The component type scoping units are supported. Different component types may have identically named ports, timers, constants and variables.
+
+* The runs on clause is properly interpreted for test cases, functions and altsteps. Component instances (ports, variables, etc.) are accessible only if the proper runs on clause is present. If a function or altstep is called on a test component, the component type is checked against the runs on clause. Component type mismatches cause dynamic testcase error.
+
+* The chapter about the usage of the ASN.1 compiler was added to this document.
+
+* System related Test Port parameters were introduced.
+
+* Event severity TTCN DEBUG was introduced in logger.
+
+* String literals (constants) are translated to static C\++ objects, that is, they are listed in the source file only. In previous version when a string constant was added to or removed from the source TTCN–3 module, the compiler re-generated the C++ header file as well and therefore it was necessary to re-compile several C++ files.
+
+*Fixed bugs*
+
+* The HTML report generator `repgen` started `logformat` with invalid command line arguments.
+
+* If some modules of the ETS were compiled on Solaris 8 while others on Solaris 2.6 (but using the same GCC 3.0.3), it might have happened that the functions of RAW enc/dec were unable to catch an internal exception and therefore the TC was killed by an abort signal. The reason of this problem might be the incompatibilities in the system header files of the two operating system. However, making the copy constructor of the exception class trivial has solved the problem.
+
+* The compiler generated invalid C++ code for nested altsteps (i.e. when an altstep was instantiated from another one).
+
+* The TTCN–3 standard specifies that if the action list of a default terminates without reaching a stop or repeat statement, the test executor has to skip the alt statement or receiving operation that the default was called from and jump to the next statement. In the previous version, however, this situation was handled incorrectly and resulted in a dynamic test case error.
+
+[[version-1-2-pl0]]
+== Version 1.2.pl0
+
+Released on July 29, 2002.
+
+*New features*
+
+* Importing from ASN.1 modules and BER encoding/decoding of ASN.1 types are now supported.
+
+* Direct (RAW) encoding and decoding of TTCN–3 data types are now supported.
+
+* The compiler accepts the latest available BNF of TTCN–3 (V2.2.0, Rev 12.5). The obsolete language elements that were removed from Edition 2 of TTCN–3 (e.g. named alts, old style import statements and module parameters, `verdict.set` and `verdict.get` operations, `goto` alt statements, etc.) are still accepted with warnings to provide backward compatibility.
+
+* Altsteps and (dynamic) defaults are now supported.
+
+* The internal handling of basic TTCN–3 string types (bitstring, octetstring, charstring) has been changed to a reference counter based method. This means that memory allocation and copying is no longer necessary for value assignments or parameter passing. This change in combination with the load-time initialization of string literals can result in 50-100% improvement of overall execution performance, especially in case of test suites dealing with long string values.
+
+* The extra matching attributes (i.e.`ifpresent` or `length` matches) can be used for compound templates as well. Because of a mistake, the TTCN–3 BNF allows them only with single values.
+
+* New command line options of the compiler: `-n`, `-o`, `-p`, `-u` and `-w`. See the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN TTCN–3 Programmer´s Technical Reference] for details.
+
+* The format of timestamps in log file can be configured. The event type names can also be logged for each event. These options are useful for log post-processing.
+
+* The numeric values are assigned properly (i.e. as it is described in the Edition 2 standard) to enumerated values that have no assigned value.
+
+* The object identifier type of TTCN–3 (i.e. objid) is properly supported, it is no longer an alias to charstring.
+
+* The TTCN–3 compiler has a nice manual page.
+
+* The `Makefile` generation was extended to support ASN.1 modules.
+
+* Some additional predefined functions were renamed according to the latest TTCN–3 specification. Non-standard predefined functions `string2bit` and `string2oct` were renamed to `str2bit` and `str2oct`, respectively. For backward compatibility built-in functions can still be referred using old names as well.
+
+* The generation and use of empty test port skeletons can be omitted for port types that are used only for internal communication between test components. If the with attribute extension `internal` is appended to the port type definition, all necessary code will be included in the C++ output files of the module. This feature reduces the compilation time and the total size of ETS.
+
+* A positive integer identifier number is assigned to all incoming messages when the message is appended to the port queue. The extraction of messages (e.g. in case of a successful `receive` operation) is also logged with a reference to these identifiers. This addition may help the test writers to trace continuously the actual state of port queues when debugging TTCN–3 code.
+
+* The `setverdict` operation displays the old and the new value of the local verdict in the log.
+
+* A new `expect` script makes the testing in parallel mode easier. See Section `expectscript`.
+
+*Fixed bugs*
+
+* The line numbering (i.e. `-l`) compiler option generated invalid C++ code for the named alternatives.
+
+* The line continuation backslashes in the generated `Makefile` caused syntax errors with some non-GNU versions of make.
+
+* The TTCN–3 `connect` operation sometimes failed and caused a run-time error on Windows platforms. The reason was a small difference between the native UNIX and Cygwin socket APIs. Namely, under Cygwin a _bind()_ operation must be always performed before calling _listen()_, even if listening to an automatically assigned ephemeral TCP port.
+
+* The execution of MTC failed in a select system call if some port connections of MTC remained active at the end of the previous test case.
+
+* The NotUsedSymbol (-) is now properly interpreted in array or record of values both in TTCN–3 modules and in the configuration file of module parameters.
+
+* The `map` and `unmap` port operations did not work in single mode. Moreover, `connect` and `disconnect` operations produce proper error messages in single mode.
+
+* Escape sequences in single character string literals (e.g. in a charstring containing only a quotation mark character) resulted in invalid C++ code.
+
+* All ports of test components are started implicitly according to the TTCN–3 specification immediately when the component is created. The explicit start statements are no longer necessary.
+
+[[version-1-1-pl10]]
+== Version 1.1.pl10
+
+Released on February 11 2002.
+
+*New features*
+
+* The char built-in type is now supported, including the conversion functions `int2char` and `char2int`.
+
+* Bitwise operators `not4b`, `and4b`, `or4b` and `xor4b` are implemented for types bitstring and octetstring.
+
+* Bitwise shifting and rotating operators are implemented for all string types and integers.
+
+* Length restrictions are supported in string templates.
+
+* The template attribute `ifpresent` is supported for optional record/set fields.
+
+* An HTML report generator was added to the official package. See Section 13.4 of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/userguide[TITAN TTCN–3 User Guide] for details.
+
+*Fixed bugs*
+
+* A UNIX signal can no longer cause dynamic testcase error when the ETS is waiting for a new snapshot. This could happen in some conditions during the profiling of ETS.
+
+* The assignment operator did not work properly for bitstring elements.
+
+* The size of equivalent C++ code was reduced by about 10 % in case of compound TTCN–3 data types because of revised template realizations.
+
+* The Main Controller no longer creates the log file Parallel MC log, which contained debug messages only.
+
+* The built-in TTCN–3 type verdicttype was not recognized by the compiler. The compiler supported the older syntax that called this type as verdict.
+
+* The compiler generated invalid C\++ code if you used an enumerated type in a record of type construct (within the same module). The resulting C++ definitions were in the wrong order.
+
+* The octetstring values that contained ASCII control characters (e.g. newlines or tabulators) were incorrectly logged in ASCII format.
+
+[[version-1-1-pl9]]
+== Version 1.1.pl9
+
+Released on December 21 2001.
+
+*New features*
+
+* Indexing (i.e. accessing of individual bits) is now supported for type bitstring as well.
+
+* The `Makefile` generated by the compiler was significantly improved. For example, you can easily archive your source files with time stamping.
+
+* It is possible to execute external programs (shell scripts) by the ETS at the beginning or end of each test case or control part.
+
+* TTCN–3 constants and module parameters cannot be modified from TTCN–3 code. Such attempts result in erroneous C++ code.
+
+* The compiler inserts source code information (i.e. the name and line number of TTCN–3 source code) as comments into the equivalent C++ code of TTCN–3 functions, test cases and control parts. This feature hopefully can help when locating syntax errors in TTCN–3 code. It still does not work for other definitions (such as constants or templates), but it will be extended in future versions.
+
+* The `-l` command line switch instructs the compiler to include this line information as #line directives instead of C\++ comments. Using this the error messages of the C++ compiler will point to the lines of the original TTCN–3 source code. However, be extremely careful with this option because sometimes the error messages can refer to invalid line numbers. In such cases turn this switch off and analyze the C++ code manually.
+
+* The TTCN–3 `rem` operator is now supported. In the Test Port API it is mapped to global function `rem`, which takes two arguments, either `INTEGER` or `int` in any combinations.
+
+* Non-standard conversion operations `string2bit` and `string2oct` were introduced.
+
+* Default values for module parameters are supported.
+
+* The module name can also be specified when setting module parameters in the configuration file.
+
+*Fixed bugs*
+
+* There were linking problems with the OpenSSL shared library on some Solaris systems. In the meantime the downloadable packages were updated, so these problems should disappear using the current 1.1.pl8 version.
+
+* The compiler generated invalid C++ code for the initializers of constant and variable arrays.
+
+* The string concatenation operation in Test Port API was changed from '&' to '+' for all string types. The `&` operator will be used for the TTCN–3 and4b operator in future versions.
+
+* In the Test Port API the TTCN–3 `mod` operator is no longer mapped to the C++ operator `%` because they have different semantics in case of negative operands. Instead the global function `mod` was introduced, which takes two arguments, either `INTEGER` or `int` in any combinations.
+
+* It was impossible to set negative integer numbers as module parameters in the configuration file.
+
+* Some symbolic constants worked incorrectly when setting the log filtering bitmasks in the configuration file.
+
+* Logging can be completely disabled by using the filtering mask value `LOG NOTHING`.
+
+[[version-1-1-pl8]]
+== Version 1.1.pl8
+
+Released on November 7 2001.
+
+*New features*
+
+* All parts of the test executor system can only be used with a valid license key.
+
+* The input language of the parser complies with the latest official BNF of TTCN–3 (Version 1.1.2, published on June 2001).
+
+* With attributes do not cause parse errors, but they are not interpreted by the compiler.
+
+* Modified templates are now supported. The only limitation is that a modified parameterized template must have the same formal parameter list as its base template.
+
+* Explicit type casting for generic wildcard templates in receiving operations is now supported. For example, `MyPCO.receive(ICONreq:?)` is accepted.
+
+*Fixed bugs*
+
+* The else branch was executed incorrectly in alternatives. Formerly, it was executed only if the guard operations failed for all other branches. Now, the else branch is executed immediately if none of the other branches are successful for the first try (according to the TTCN–3 operational semantics).
+
+* Predefined functions `oct2int` and `bit2int` returned wrong integer values, because they interpreted the octets or bits in the wrong order.
+
+* Invalid C++ code was generated for TTCN–3 functions that had formal port parameters but were otherwise startable on PTCs.
+
+[[version-1-1-pl7]]
+== Version 1.1.pl7
+
+Released on October 8 2001.
+
+*New features*
+
+* The _any value or none_ (*) wildcard is now matched correctly in templates of record of types. Formerly the * was interpreted as _any value_ (?), that is, it matched exactly one element.
+
+* The memory handling of record of type construct was improved.
+
+* External TTCN–3 constants and functions are now supported. They are translated to external C++ constant definitions or function prototypes in the target header file.
+
+* The compiler does not stop when it encounters an unsupported type definitions, instead it outputs a warning message. Value list and length restrictions are simply ignored while the set of type construct is currently substituted with record of.
+
+* The unsupported `sut.action` statements are skipped by the compiler.
+
+*Fixed bugs*
+
+* Overlapped component creation (initiated from different TCs) sometimes caused segmentation fault in Host Controllers.
+
+* Performing a running operation on an already terminated component sometimes resulted in dynamic test case error instead of returning false.
+
+* Passing of simple value parameters (i.e. without `tt in`, `out` or `inout` keywords) in TTCN–3 functions resulted in invalid C++ code in some cases. Now these parameters are passed by value in case of data types and by reference in case of port types.
+
+* Concatenation (`&`) operators were not implemented for string elements returned by indexing.
+
+* Expressions were not allowed in timer start operations. +
+
+NOTE: Simple function instances (i.e. their return values) are still not allowed in timer start operations, because the compiler cannot distinguish `MyTimer.start(MyFunction()`) from `MyComponent.start(MyFunction()`), but they should be handled in different ways. In such cases please use `MyTimer.start(MyFunction() + 0.0)` as a workaround, which yields always valid C++ code.
+
+* Value list and complemented list templates for record of types resulted in invalid C++ code.
+
+[[version-1-1-pl6]]
+== Version 1.1.pl6
+
+Released on September 26 2001.
+
+*Fixed bugs*
+
+* The `running` timer operation returned always true for a started timer even if it has already expired.
+
+* The `enumerated` module parameters remained unbound even if they were set correctly in the configuration file.
+
+* Test execution terminated abnormally in parallel mode if the `disconnect` port operation was performed on a component other than the connection was requested from by a `connect` operation.
+
+* The compiler generated invalid C++ code for some templates that contain specific values for enumerated types.
+
+[[version-1-1-pl5]]
+== Version 1.1.pl5
+
+Released on September 17 2001.
+
+*New features*
+
+* The compiler does not overwrite the target C\++ header or source file if its content does not change. This can speed up incremental compilation because the header files usually do not change if the user only modifies a TTCN–3 definition and therefore only one C++ module shall be re-compiled. This feature can be disabled by passing the `-f` switch to the compiler.
+
+* Non-standard conversion functions `oct2char` and `char2oct` were introduced.
+
+*Fixed bugs*
+
+* The return statements in TTCN–3 functions accept expressions without parentheses as well.
+
+* A reference to a non-existent test case in the `[EXECUTE]` section of the configuration file did not cause any error message.
+
+* Translation of named alts having parameters caused memory leakage in the compiler.
+
+* Translation of TTCN–3 functions having port parameters resulted in invalid C++ code.
+
+[[version-1-1-pl4]]
+== Version 1.1.pl4
+
+* Released on August 27 2001.
+
+*New features*
+
+* The stand-alone instances (i.e. like a function call, not within an alt statement) of a named alt within one function are no longer limited. (It is a good exercise to understand how it works with the C preprocessor.)
+
+*Fixed bugs*
+
+* Log file naming discrepancies were fixed in configuration file.
+
+* Function `main()` was missing from `libttcn3-dynamic.so`.
+
+* The compiler reported memory leakage or sometimes crashed with segmentation fault after translating an array of constants.
+
+* Logging did not work properly when Base Library was linked dynamically.
+
+* There were compilation problems with Base Library on FreeBSD/NetBSD because of missing included header files.
+
+* Comparison of charstrings with NULL pointer no longer causes segmentation fault. The NULL pointer is interpreted as an empty string.
+
+* The `trigger` port operation did not work correctly, because it dropped all nonmatching messages for the first try. TTCN–3 operational semantics says to drop only one message in one round (i.e. it introduces an implicit receive).
+
+* Port operations any `port.receive`, any `port.trigger` and any `port.check` are now translated correctly.
+
+* The compiler no longer generates code with quadratic size for incoming queue handling of ports.
+
+[[version-1-1-pl3]]
+== Version 1.1.pl3
+
+Released on August 1 2001.
+
+*New features*
+
+* Run-time support of TTCN–3 module parameters. They are read by the test executor from a configuration file.
+
+* Individual execution of test cases that have no parameters (independently from module control part).
+
+* Test port parameters.
+
+* Additional predefined functions (except hexstring related ones) specified in TTCN–3 standard are now supported.
+
+* Pre-defined TTCN–3 functions (except char, universal char and hexstring related ones) defined in Annex C of link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language] are now supported.
+
+* The enumerated types are provided with a _value ) string_ and _string ) value_ conversion functions.
+
+*Fixed bugs*
+
+* Some C\++ templates of Base Library generated erroneous C++ code.
+
+* The bug in Main Controller that caused some map operations to fail was fixed.
+
+* C/C\++ keywords that are not keywords in TTCN–3 are now translated to valid C++ identifiers, i.e. the compiler appends a trailing underscore character to them.
+
+* C style comments longer than 16 kbytes in TTCN–3 modules caused the compiler to fail during translation.
+
+* The translation of TTCN–3 `union` type constructs was improved. The former quadratic algorithm was replaced with a linear one, which results in both faster translation and smaller generated C++ code, especially for unions containing a large number of fields.
+
+* Some error messages of the compiler printed the identifiers with double underscore characters.
+
+* Logging of enumerated constants also used duplicated underscores.
+
+[[version-1-1-pl2]]
+== Version 1.1.pl2
+
+Released on July 23 2001.
+
+*New features*
+
+* Preparations for supporting TTCN–3 module parameters. They will be read runtime by the test executor from a configuration file.
+
+*Fixed bugs*
+
+* Port operations `connect`, `disconnect`, `map` and `unmap` now works for members of port arrays as well.
+
+* The compiler generated erroneous C++ code for setting the initial value of variable and constant arrays.
+
+* Functions were startable only if their parameters were explicitly denoted by in keyword.
+
+* Variable `LD FLAGS` was defined twice in the generated `Makefile`.
+
+[[version-1-1-pl1]]
+== Version 1.1.pl1
+
+Released on July 10 2001.
+
+*Fixed bugs*
+
+* TTCN–3 operations all `port.start` and all `port.stop` were not supported by the compiler due to a bug.
+
+* Value redirects in port receiving operations without value template did not cause syntax error during compilation.
+
+* Compilation of the Base Library failed under FreeBSD due to a wrong `#ifdef` statement.
+
+* White spaces were removed from the beginning of comment lines in `Makefile` template generated by the compiler. This confused the make utility on FreeBSD.
+
+* C++ compiler flag `-O2` was removed from `Makefile` template generated by the compiler in order to decrease compilation time.
+
+* In test port function `incoming message` logging is now performed before adding message into the port queue. This facilitates Test Port debugging (e.g. finding unbound fields).
+
+* The user `log` statement in TTCN–3 now accepts more than one arguments separated by commas.
+
+[[version-1-1-pl0]]
+== Version 1.1.pl0
+
+Released in July 2001.
+
+*New features*
+
+* Parallel and distributed test execution is now supported.
+
+* Internal communication of test components is supported in a transparent way.
+
+* Explicit addressing in `send` and `receive` operations is supported. The sender’s address in `receive` operations can be matched and stored.
+
+* `Makefile` template generation by the compiler.
+
+* The compiler can translate more than one modules given in command line.
+
+* Test Port skeleton generation can be controlled by a `-t` command line switch of the compiler.
+
+* The executor does not walk through the data structure to be sent or received, if the logging of port events is disabled. This increases the execution speed with one magnitude compared to logging.
+
+* If a value (e.g. variable) is given as parameter to a send operation instead of a template, the _value ) template ) value_ conversion chain is eliminated, which also results in higher performance.
+
+* execute statements (either with or without timeout value) are supported. The old style (function-like) test case calls are still also supported.
+
+* TTCN `error(…)` now accepts printf-style format string and variable number of arguments.
+
+* New function `TTCN warning(…)` was introduced.
+
+* The semicolon is an optional separator between function statements according to the newest TTCN–3 BNF. +
+
+NOTE: The parser may screw up if the omission of semicolon causes ambiguity.
+
+* The compiler still accepts the obsolete duration units and the dash character (-) instead of the omit keyword, but gives a warning message during translation.
+
+*Fixed bugs*
+
+* In-line array initializers were not permitted by the compiler in the right values of local constant or variable definitions.
+
+* The generated C++ code was erroneous when using single initial values for union constants or variables.
+
+* Execution failed with a dynamic test case error in a send or receive statement when converting a record or set value with an omitted optional field to template.
+
+* The bits of a bitstring constant were in the reverse order within the bytes.
+
+* The constructor of class CHARSTRING with explicit length initialized the string only until the first NUL character in initial value.
+
+* The message type contained duplicated underscore characters in the log entry of send and receive events.
+
+* In case of port arrays, the name of each instance was not set properly.
+
+* The value omit was permitted only in template bodies.
+
+[[version-1-0]]
+== Version 1.0
+
+First published release. Issued in January 19, 2001.
+
+NOTE: The programs in this release do not support any version printout claiming 1.0. By this time the tool was simply called TTCN–3 Test Executor Prototype.
+
+[[Changes-of-Test-Port-API]]
+= Changes of Test Port API
+
+This section gives you a summary of changes on the Test Port API between the different versions of the test executor. You should check this list carefully if you want to use a Test Port developed for an older version with a newer version. Sometimes you have to change some pieces of code to perform a successful upgrade. The changes that result in incompatibility are denoted by word INCOMPATIBLE.
+
+WARNING: The classes of data types or the Test Port base class may have some member functions that are not described in this document. These functions are written or generated only for internal purposes of the test executor. You should not use the undocumented functions because improper calls may cause the instability of your ETS. In addition, the interface of these functions may change in future releases without notice.
+
+[[version-1-8-pl6]]
+== Version 1.8.pl6
+
+No changes
+
+[[version-1-8-pl5]]
+== Version 1.8.pl5
+
+No changes
+
+[[version-1-8-pl4]]
+== Version 1.8.pl4
+
+No changes
+
+[[version-1-8-pl3]]
+== Version 1.8.pl3
+
+No changes
+
+[[version-1-8-pl2]]
+== Version 1.8.pl2
+
+Although there were no direct changes done to the testport API, the version handling feature introduced some ways for testport writers to constrain the use of their testports by:
+
+* The version of TITAN using the TTCN3_VERSION macro
+
+* The version of gcc using the GCC_VERSION macro
+
+For more information please consult section 4.23.2 of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN programmers reference guide].
+
+[[version-1-8-pl1]]
+== Version 1.8.pl1
+
+No changes
+
+[[version-1-8-pl0]]
+== Version 1.8.pl0
+
+No changes
+
+[[version-1-7-pl4]]
+== Version 1.7.pl4
+
+The Test Port was enhanced with the handling of the epoll system call present on recent linux systems, making it possible to handle connections in a much more efficient way. The already existing Test Port interface was kept, but it is no longer a direct interface, but a mapping to the new interface, which provides several new functions, that can be used to handle connections in a simplier manner (for example there are specific callback functions to handle new data appearing on a registered port connection).
+
+[[version-1-7-pl3]]
+== Version 1.7.pl3
+
+No changes.
+
+[[version-1-7-pl2]]
+== Version 1.7.pl2
+
+No changes.
+
+[[version-1-7-pl1]]
+== Version 1.7.pl1
+
+Log event subtypes were introduced and the generated codes were updated to use the new log events by default. The logger was enhanced to log the actual logging options. Some log messages were moved to other log event categories. (INCOMPATIBLE)
+
+[[version-1-7-pl0]]
+== Version 1.7.pl0
+
+* Test Port classes as well as C\++ classes of user defined data types are put into a C++ namespace that corresponds to the TTCN–3 module. (INCOMPATIBLE)
+
+* The C\++ equivalents of TTCN–3 and ASN.1 enumerated values were moved into the scope of the C++ class that implements the enumerated type. The enum-hack option became obsolete. (INCOMPATIBLE)
+
+* The C++ enumerated type that describes the selected field of a TTCN–3 union or ASN.1 CHOICE type was moved into the scope of the value class. The naming rules of the possible enumerated values have changed too. (INCOMPATIBLE)
+
+* The C++ realization of TTCN–3 predefined function `ischosen` has changed. There is one common function, which takes the enumerated field identifier as argument instead of the former dedicated functions for all possible fields. (INCOMPATIBLE)
+
+* Useless C++ classes and port operations are no longer generated for procedure based communication. Signatures with `noblock` keyword do not allow reply or `getreply`, signatures without exception types do not allow raise or catch. (INCOMPATIBLE)
+
+* The C++ class that represents signature exceptions provides accessor functions for exception types using a new naming convention. The naming convention of the enumerated type that describes the selected type has also changed. (INCOMPATIBLE)
+
+* The address extension no longer works with imported address type. (INCOMPATIBLE)
+
+* New API was introduced for provider port types. (ADDITION)
+
+[[version-1-6-pl5]]
+== Version 1.6.pl5
+
+No changes.
+
+[[version-1-6-pl4]]
+== Version 1.6.pl4
+
+* C++ representation of external function parameters without the in keyword has been changed. (INCOMPATIBLE)
+
+[[version-1-6-pl3]]
+== Version 1.6.pl3
+
+* Array types were introduced. (ADDITION)
+
+[[version-1-6-pl2]]
+== Version 1.6.pl2
+
+No changes.
+
+[[version-1-6-pl1]]
+== Version 1.6.pl1
+
+No changes.
+
+[[version-1-6-pl0]]
+== Version 1.6.pl0
+
+* The constructor of test port classes now has a default argument, which is a NULL pointer. In the newly created skeletons the default argument is already present, but it has to be added to the existing test port header files manually. Otherwise, if the port type is used in a port array the generated C++ code will not compile. The updated and newly created test ports also work with older versions. (INCOMPATIBLE)
+
+* The member function `set size()` was added to the C++ equivalents of record of and set of types. (ADDITION)
+
+[[version-1-5-pl8]]
+== Version 1.5.pl8
+
+No changes.
+
+[[version-1-5-pl7]]
+== Version 1.5.pl7
+
+No changes.
+
+[[version-1-5-pl6]]
+== Version 1.5.pl6
+
+The global C-like functions for the conversion of enumerated values were moved into the class scope. They became static members of the value class. The old function names are still preserved for backward compatibility. (ADDITION)
+
+[[version-1-5-pl5]]
+== Version 1.5.pl5
+
+No changes.
+
+[[version-1-5-pl4]]
+== Version 1.5.pl4
+
+No changes.
+
+[[version-1-5-pl3]]
+== Version 1.5.pl3
+
+* Type universal charstring is now supported. Its equivalent C++ class named UNIVERSAL CHARSTRING was introduced. (ADDITION)
+
+[[version-1-5-pl2]]
+== Version 1.5.pl2
+
+No changes.
+
+[[version-1-5-pl1]]
+== Version 1.5.pl1
+
+No changes.
+
+[[version-1-5-pl0]]
+== Version 1.5.pl0
+
+* The C++ API for invoking the RAW and BER encoding/decoding functions has significantly changed. The purpose of changes was to provide a common, unified and more flexible interface for both encoding methods. See the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN TTCN–3 Programmer´s Technical Reference] for more details. (INCOMPATIBLE)
+
+[[version-1-4-pl5]]
+== Version 1.4.pl5
+
+No changes.
+
+[[version-1-4-pl4]]
+== Version 1.4.pl4
+
+* The procedure based ports are now supported with an enhanced Test Port API. (ADDITION)
+
+* The C\++ code generated by the compiler has changed for record of, set of and enumerated types. These are not realized as C++ template classes any more, but as regular C++ classes. These changes should not cause any incompatibilities in properly written test ports.
+
+* The parameter type and/or return type of some helper functions used for enumerated types has been changed from `int` to `enum`. This may require explicit casting in some Test Ports. (INCOMPATIBLE)
+
+[[version-1-4-pl3]]
+== Version 1.4.pl3
+
+* The interrupt signal is handled in single mode. (ADDITION)
+
+[[version-1-4-pl2]]
+== Version 1.4.pl2
+
+No changes.
+
+[[version-1-4-pl1]]
+== Version 1.4.pl1
+
+* Class CHAR, which was the C++ equivalent of the obsolete TTCN–3 type char was removed. The compiler substitutes all occurrences of type char with charstring and CHAR is now a typedef alias to class CHARSTRING, which provides partial backward compatibility. (INCOMPATIBLE)
+
+* Hexstring related conversion functions were added. (ADDITION)
+
+[[version-1-4-pl0]]
+== Version 1.4.pl0
+
+No changes.
+
+[[version-1-3-pl0]]
+== Version 1.3.pl0
+
+* The symbolic constants NULL ADDRESS, MTC ADDRESS and SYSTEM ADDRESS were renamed to NULL COMPREF, MTC COMPREF and SYSTEM COMPREF, respectively. (INCOMPATIBLE)
+
+* Usage of TTCN–3 `address` type is now supported. See the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN TTCN–3 Programmer´s Technical Reference]. (ADDITION)
+
+[[version-1-2-pl4]]
+== Version 1.2.pl4
+
+No changes.
+
+[[version-1-2-pl3]]
+== Version 1.2.pl3
+
+* TTCN–3 type hexstring is now supported. Its C++ equivalent is class HEXSTRING. (ADDITION)
+
+[[version-1-2-pl2]]
+== Version 1.2.pl2
+
+No changes.
+
+[[version-1-2-pl1]]
+== Version 1.2.pl1
+
+* System related Test Port parameters were introduced. Their value is passed to the Test Port during test run when executing a map statement. (ADDITION)
+
+* The set of type construct is now supported. The API is exactly the same as in case of record of. (ADDITION)
+
+[[version-1-2-pl0]]
+== Version 1.2.pl0
+
+* The new OBJID built-in type was added. (ADDITION) It is not compatible with CHARSTRING, which was OBJID aliased to before. (INCOMPATIBLE)
+
+* The default mapping of underscore characters within file names (including Test Port header and source files) has been changed. (INCOMPATIBLE) Use the command line option `-u` of the compiler to switch the compatibility mode on.
+
+* Member functions VERDICTTYPE::set and VERDICTTYPE::get were removed. Use the functions `TTCN Runtime::setverdict` and `TTCN Runtime::getverdict` to modify or get the local verdict. (INCOMPATIBLE)
+
+[[version-1-1-pl10]]
+== Version 1.1.pl10
+
+* The CHAR built-in type was added. (ADDITION)
+
+* The bitwise and rotating overloaded operators were added. (ADDITION)
+
+NOTE: You should not upgrade a Test Port developed for version 1.1.pl8 or earlier directly to 1.1.pl10 because operator `&` meant concatenation in older versions but it means now bitwise and operation. You should upgrade these old Test Ports to 1.1.pl9 first and after the successful compilation you can proceed to 1.1.pl10.
+
+[[version-1-1-pl9]]
+== Version 1.1.pl9
+
+* The concatenation operator has been changed from `&` to `+` for all string types. (INCOMPATIBLE)
+
+* The modulo division overloaded operator has been removed from the class INTEGER. The `mod` and `rem` TTCN–3 operations can be performed by polymorphic global functions called `mod` and `rem`, respectively. (INCOMPATIBLE)
+
+[[version-1-1-pl8]]
+== Version 1.1.pl8
+
+No changes.
+
+[[version-1-1-pl7]]
+== Version 1.1.pl7
+
+No changes.
+
+[[version-1-1-pl6]]
+== Version 1.1.pl6
+
+No changes.
+
+[[version-1-1-pl5]]
+== Version 1.1.pl5
+
+No changes.
+
+[[version-1-1-pl4]]
+== Version 1.1.pl4
+
+No changes.
+
+[[version-1-1-pl3]]
+== Version 1.1.pl3
+
+* Member function set parameter was introduced. (ADDITION)
+
+* The enumerated types are provided with a _value ) string_ and _string ) value_ conversion functions, i.e. `<enum type>` to `str` and `str` to `<enum type>`. (ADDITION)
+
+[[version-1-1-pl2]]
+== Version 1.1.pl2
+
+No changes.
+
+[[version-1-1-pl1]]
+== Version 1.1.pl1
+
+No changes.
+
+[[version-1-1-pl0]]
+== Version 1.1.pl0
+
+* The constructors of Test Port base classes take the port name as a parameter. In version 1.0 the port name was directly assigned in the constructor of the user code, but now it has to be passed to the constructor of base class. (INCOMPATIBLE)
+
+* The function `Event Handler` has now four parameters containing the triggering file descriptors and the time elapsed since the last call. (INCOMPATIBLE)
+
+* Functions user map and user `unmap` were introduced. (ADDITION)
+
+* Function TTCN error accepts printf-style arguments and TTCN warning was introduced. (ADDITION)
+
+= References
+
+1. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.01.01_60/es_20187301v040101p.pdf[Methods for Testing and Specification (MTS);The Testing and Test Control Notation version 3.Part 1: Core LanguageEuropean Telecommunications Standards Institute. ES 201 873-1 Version 4.1.1, July 2009]
+
+2. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187304/04.01.01_60/es_20187304v040101p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 4: TTCN–3 Operational Semantics European Telecommunications Standards Institute. ES 201 873-4 Version 4.1.1, June 2009]
+
+3. link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187307/03.01.01_60/es_20187307v030101p.pdf[Methods for Testing and Specification (MTS);The Testing and Test Control Notation version 3.Part 7: Using ASN.1 with TTCN–3European Telecommunications Standards Institute.ES 201 873-7  Version 3.1.1, June 2005]
+
+4. link:https://www.itu.int/rec/T-REC-X.680-200207-S[ITU-T, X.680, Information TechnologyAbstract Syntax Notation One (ASN.1): Specification of basic notationInternational Telecommunication Union, July 2002]
+
+
+5. link:https://www.itu.int/rec/T-REC-X.682-200207-S[ITU-T, X.682, Information TechnologyAbstract Syntax Notation One (ASN.1): Constraint specificationInternational Telecommunication Union, July 2002]
+
+6. link:https://github.com/eclipse/titan.core/blob/master/usrguide/installationguide.adoc[Installation guide for TITAN TTCN-3 Test Executor]
+
+7. link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer’s Technical Reference for TITAN TTCN-3 Executor]
+
+
+8. link:https://github.com/eclipse/titan.core/blob/master/usrguide/userguide/README.adoc[User Guide for TITAN TTCN-3 Test Executor]
diff --git a/usrguide/userguide.doc b/usrguide/userguide.doc
deleted file mode 100644
index 9ade28332d684389608124e59b333e3caed60a2e..0000000000000000000000000000000000000000
Binary files a/usrguide/userguide.doc and /dev/null differ
diff --git a/usrguide/userguide/1-about_the_document.adoc b/usrguide/userguide/1-about_the_document.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..82f5cc30de67f9e9601568f3b26d3dcd13163861
--- /dev/null
+++ b/usrguide/userguide/1-about_the_document.adoc
@@ -0,0 +1,23 @@
+= About the Document
+
+== Purpose
+
+The purpose of this document is to provide detailed information on using the TITAN toolset, that is, creating test suites from TTCN-3, ASN.1 modules, and test port files, by modifying a `Makefile` and using `make` to build executables.
+
+== Target Groups
+
+This document is intended for users of the TITAN TTCN–3 Test Toolset. In addition to this document, readers requiring additional information on creating and building test suites or writing test ports are referred to the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor].
+
+NOTE: Test port writing requires a sound knowledge of C++ programming.
+
+== Typographical Conventions
+
+This document uses the following typographical conventions:
+
+* *Bold* is used to represent graphical user interface (GUI) components such as buttons, menus, menu items, dialog box options, fields and keywords, as well as menu commands. Bold is also used with '+' to represent key combinations. For example, *Ctrl+Click*
+
+* The character '*/*' is used to denote a menu and sub-menu sequence. For example, *File / Open*.
+
+* `Monospaced` font is used represent system elements such as command and parameter names, program names, path names, URLs, directory names and code examples.
+
+* `*Bold monospaced*` font is used for commands that must be entered at the Command Line Interface (CLI).
diff --git a/usrguide/userguide/2-overview_of_titan.adoc b/usrguide/userguide/2-overview_of_titan.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..2eac6cb81e9a5007b997c7e8ece39297ebd2aa81
--- /dev/null
+++ b/usrguide/userguide/2-overview_of_titan.adoc
@@ -0,0 +1,48 @@
+= Overview of TITAN
+
+This Test Executor is an implementation of the TTCN–3 Core Language standard with support of ASN.1. There are limitations to supported TTCN–3 language constructs in the Test Executor. In addition, there are some non-standard extensions to the TTCN–3 language implemented by TITAN. Information on these limitations and extensions and also some clarifications of how the standard has been implemented in TITAN, refer to the
+link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor].
+
+== Components
+
+The main components are the following:
+
+* The *Compiler*, which translates TTCN–3 and ASN.1 modulesfootnote:[Compilation of ASN.1 modules is necessary only if the test suite imports type definitions from ASN.1 modules.] into C++ program code.
+
+* The *Base Library*, written in C++ language, which contains important supplementary functions for the generated code.
+
+* The *Test Port(s)*, which facilitate the communication between the TTCN–3 Test System and the System Under Test (SUT).
+
+The generated C\++ modules as well as the Test Ports should be compiled to binary object code and linked together with the Base Library using a traditional C++ compiler.
+
+All parts, except the protocol specific Test Ports, are included in the binary package of the Test Executor. The Test Executor is a protocol and platform independent tool that can be easily adapted to any kind of protocols by writing the appropriate Test Port. The generated C\++ code is exactly the same on all platforms, provided that the pre-compiled Base Library that matches the operating system and C++ compiler is used. The Test Port may use operating system calls or external library functions for sending or receiving messages towards System Under Test so it may become platform dependent.
+
+Writing a Test Port is not an easy task for the first time, but the Compiler alleviates it by generating an empty skeleton for each function to be written. This skeleton is also useful for checking the correctness of an existing test suite because the Executable Test Program can be linked with this empty Test Port. In this case the resulting program actually does nothing, but the successful linking means that no modules or functions are missing from the test suite.
+
+This document describes building and running test suites using the command line.
+
+image::images/titanexecutor_structure_x.png[title="Titan structure"]
+
+== General Workflow
+
+* Generating and editing a `Makefile`
+
+* Building the executable
+
+* Executing test suites
+
+* Analyzing the execution log files.
+
+== Building Test Suites
+
+Creating a TTCN–3 test suite involves building an executable from the initial modules (TTCN–3, ASN.1 or both) and test port files. The process basically comprises creating and modifying a `Makefile` and using the `make` command to build the executable.
+
+For detailed information, refer to <<3-creating_executable_test_suites_from_the_command-l.adoc, Creating Executable Test Suites from the Command-line>>.
+
+== Executing Test Suites
+
+After the test suite has been created a suitable configuration file has been built, the executable is ready to run.
+
+The test executor can operate in single or parallel mode. The single mode—also called non-parallel mode—is thought for TTCN–3 test suites built around a single test component. It is forbidden to create parallel test components in single mode: the test suite is not supposed to contain any `create` operation otherwise the test execution will fail. The parallel mode, on the other hand, offers full-featured test execution including distributed and parallel execution. The goal of introducing the single operating mode was to eliminate redundancies and thereby increase the speed of execution. It is possible to execute non-parallel test suites in parallel mode, but doing so results in unnecessary overhead. The C++ code generated by the compiler is suitable for both execution modes, there are no command line switches to select mode. The only difference is that different Base Libraries must be linked in single and parallel modes.
+
+For detailed information on executing test suites in single or parallel mode, refer to <<4-executing_test_suites.adoc, Executing Test Suites>>.
diff --git a/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc b/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..6adef6dcb932dd536abee4e700250aa4d859b345
--- /dev/null
+++ b/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc
@@ -0,0 +1,516 @@
+= Creating Executable Test Suites from the Command-line
+
+This section describes the elementary commands that comprise the build process. The primary audience of this section is the group of users who want to integrate TTCN–3 to a new or an existing build system.
+
+== Using `make`
+
+This section gives an example about how to create a new `Makefile` or modify an existing one manually to make it capable of handling TTCN–3 test suites. For example, if using many external libraries and program modules with TTCN–3, it can be beneficial to write an own `Makefile`.
+
+The generated skeleton is always a good starting point for a custom `Makefile`.
+
+The following lines are mandatory in the `Makefile`:
+[source]
+----
+TTCN3_MODULES = MyModule.ttcn
+
+ASN1_MODULES =
+
+GENERATED_SOURCES = MyModule.cc
+
+GENERATED_HEADERS = MyModule.hh
+
+$(GENERATED_SOURCES) $(GENERATED_HEADERS): $(TTCN3_MODULES) $(ASN1_MODULES)
+
+$(TTCN3_DIR)/bin/compiler $(TTCN3_MODULES) $(ASN1_MODULES)
+----
+
+`TTCN3_MODULES` and `ASN1_MODULES` contain the names of the TTCN–3 and ASN.1 files, respectively.
+
+The variables `GENERATED_SOURCES` and `GENERATED_HEADERS` store the name of the source and header files that the compiler will generate. This rule calls the compiler with an argument list that contains the name of all TTCN–3 and ASN.1 files. Beginning from version 1.2.pl0 the compiler does _not_ duplicate the underscore ("_") characters in output file names, so you may safely use such module and file names that contain this character.
+
+To compile the generated C++ code using `make`, the following rule in the `Makefile` is also needed:
+[source]
+----
+.cc.o:
+
+          g++ -c -I$(TTCN3_DIR)/include -Wall $<
+----
+In this case simply issue the command `*make MyModule.o*` and the two translation steps will be performed automatically in a row.
+
+=== Rules for Modular Test Suites
+
+The compiler supports modular TTCN–3 test suites as well. Each module is translated to a separate C\++ header and source file. These source files can be compiled by the C++ compiler one-by-one separately.
+
+The importing mechanisms work in the following way. For example, two TTCN-3 modules are present in files `A.ttcn` and `B.ttcn`, respectively. Definitions of module A may be used from module B, so the `import from A all`; statement must be added to module B. The modules A and B *must* be translated by the compiler in one step to `A.cc`, `A.hh`, `B.cc` and `B.hh`. During the compilation from TTCN–3 to C++ of module B, the import statement will be translated to `#include "A.hh"`. This statement will be put to the beginning of `B.hh`, so you can refer to any definitions of A in module B. But note that when compiling `B.cc`, `A.hh` must exist and it must be up to date.
+
+Thus, additional rules are needed in the `Makefile`. It is recommended adding them automatically using the utility `makedepend` footnote:[The makedepend utility is available on all supported platforms. It usually can be found in the X11 development package.]. Run the following command:
+
+[source,subs="+quotes"]
+*makedepend -I$TTCN3_DIR/include A.cc B.cc*
+
+This will add the rules to the end of the `Makefile` and they will be updated upon re-running `makedepend`. For further details please consult the manual page of `makedepend`.
+
+Multiple imports of the same module are handled correctly. For example, if importing all definitions of module C from both modules A and B in the previous example, all three C++ source files will compile correctly.
+
+== Automatically Generated `Makefile`
+
+This section describes the automatically generated `Makefile`, its structure, the supported commands and the possibilities for customization.
+
+=== `Makefile` Generation
+
+The `Makefile` for a project can be generated using the generator tool `ttcn3_Makefile gen` footnote:[Up to version 1.6pl4 Makefile generation was part of the compiler (using the -M option).]. A project usually consists of some TTCN–3 and ASN.1 modules and at least one test port and results in an executable test suite.
+
+`Makefile` generation is performed with the following command syntax:
+
+[source,subs="+quotes"]
+** $TTCN3_DIR/bin/ttcn3_Makefilegen [options] <Main module> {Module}* {Test_Port}* {Other_File}* **
+
+* `[options]` can be one or more of the options that are listed in the TITAN Programmer's Technical Reference for link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor].
+
+* `<Main module>` is the main TTCN–3 Core Language module. The argument can be either a file name (with or without path) or a module name. The name of the desired executable will be derived from the name of this module unless the `-e` option is used.
+
+* `{Module}*` are additional TTCN–3 or ASN.1 modules, which are directly or indirectly referenced (imported) from the main module and thus required for building the executable test suite. Each argument should be a file name (with or without path) or a module name.
+
+* `{Test Port}*` specifies names of all test ports or other required C++ program modules. The names can be given with or without suffix.
+
+* `{Other File}*` specifies the names of other files (configuration files, shell scripts, and so on) that are used in this project.
+
+For detailed content of the generated `Makefile`, refer to <<Makefile-Structure, Makefile Structure>>.
+
+==== `Makefile` Generation Algorithm
+
+Before generating the `Makefile` the `Makefile` generator tries to figure out the file name, module type and module name for each argument automatically. It uses some heuristics which yield correct results in most cases, but not always. Typically, the algorithm works perfectly with shell wildcards. For example, if all source files reside in the same directory the following command will generate the right `Makefile`:
+
+`*$TTCN3_DIR/bin/ttcn3_Makefilegen *.ttcn *.asn *.c**`
+
+The `Makefile` generator looks for an existing file for each argument. It tries the given argument without any suffix, then the following list of suffixes are tried in this order: `.ttcn`, `.ttcn3`, `.3mp`, `.ttcnpp`, `.ttcnin`, `.asn`, `.asn1`, `.cc`, `.c`, `.hh`, `.h`, `.cfg`, `.prj`. Once a file is found, the `Makefile` generator tries to guess its type as described below. If no suitable file is found for a given argument the `Makefile` generator prints an error message and exits.
+
+In the case of TTCN–3 preprocessing (using the `-p` command line argument) the TTCN–3 files with special suffix `.ttcnpp` will be added to the list of TTCN–3 modules which need to be preprocessed before compilation. Files with the `.ttcnin` suffix will be added to the list of TTCN–3 include files (without the `-p` switch these will be added to the other files section of the `Makefile`).
+
+Then the `Makefile` generator tries to classify the file in the following categories based on the contents and/or the suffix:
+
+* TTCN–3 modules (based on contents)
+
+* ASN.1 modules (based on contents)
+
+* TTCN–3 include files (based on suffix, only with `-p`)
+
+* C/C++ source files (based on suffix)
+
+* C/C++ header files (based on suffix)
+
+* other files (the rest)
+
+The `Makefile` generator has two built-in "light" parsers that can decide whether a file is a TTCN–3 or ASN.1 module, respectively. Those parsers read only the first few lines of the input and do not check the syntactical correctness of the modules. They are capable of retrieving the module name as well.
+
+If the `Makefile` generator ensured that the file is neither a TTCN–3 nor an ASN.1 module then it checks whether the file has `.cc`, `.c`, `.hh` or `.h` suffix. The content of the file is not examined anymore.
+
+The remaining files (configuration files and so on) will be added to the other files’ section of the `Makefile`. These files do not take part in the build process, but they are added to the archive files created using the `Makefile`.
+
+After the classification, the `Makefile` generator filters out the redundant generated C\++ files. If a given C/C++ file was found to be generated from one of the given TTCN–3 or ASN.1 modules, a warning is printed and the file will be dropped from the list of C/C++ files. That is, the file will not be added to the list of user source files since it is already a member of the generated sources. This feature is useful if one wants to regenerate the `Makefile` using the shell wildcard `*.cc` while the generated files from the previous compilation are still present.
+
+In the next step the algorithm tries to complete the list of C/C\++ files by checking the pairs of header and source files. If a C/C++ source file was identified and a header file with the same name exists (only the suffix differs) too, the `Makefile` generator will add the header file automatically. This step is performed in the reverse direction too: the `Makefile` generator can find an existing source file based on the header file given to it. Of course a C++ source file can exist without a header file or vice versa.
+
+The `Makefile` generator continuously checks the uniqueness of files and module names. If the same file was given more than once in the command line the repeated argument is simply ignored and a warning message is displayed. It is not allowed to use two or more different TTCN–3 or ASN.1 files containing modules with the same name because the generated C\++ files would clash. For similar reasons the user C/C++ files cannot have identical names even if they are located in different directories.
+
+Finally the `Makefile` is generated based on the resulting data. If the `Makefile` generator finds an existing `Makefile` in its working directory, it will not be overwritten unless the option `-f` is used.
+
+It is always assumed that the working directory of the generated `Makefile` will be the same as the current working directory of the `Makefile` generator even if the `Makefile` is placed into another directory using the `-o` switch.
+
+When a path name passed to the `Makefile` generator contains a directory part the `Makefile` generator analyzes and canonizes the directory name by resolving relative directory references (such as . or ..) and symbolic links pointing to directories footnote:[Symbolic links pointing to files will not be resolved.]. If the path name does not contain any directory part or it turns out that the file is located in the current working directory the generated `Makefile` will refer to the file using a simple file name without any directory. Files located in other directories will be referenced in a uniform way using either absolute or relative path names depending on whether the command line switch -a was specified or not. Thus it is not relevant whether the file was given as relative or absolute path name in the command line.
+
+The `Makefile` is generated based on the following assumptions:
+
+* Each object and if applicable, shared object file is located in the same directory as the C/C++ source file it is derived from. This allows the use of efficient wildcard rules.
+
+* The TTCN–3 /ASN.1 compiler will place all generated C++ files in the current working directory.
+
+==== Use of `GNU make`
+
+If option `-g` is used, the resulting `Makefile` will be less redundant as it will use some suffix substitution rules. These rules are supported only by `GNU make`, other versions of the make utility will find such `Makefiles` erroneous.
+
+The more of the file naming conventions below are fulfilled, the more suffix substitution rules can be applied in the generated `Makefile`. If the rules are only partially fulfilled, the `Makefile` will be also correct, but it will be more difficult to maintain. It is recommended to follow these rules especially when starting a new project.
+
+* Unless option `-c` is used, all TTCN–3, ASN.1 and C++ modules should reside in the current working directory. If these files are stored in a different scheme (for example in a hierarchical directory tree) symbolic links can be used to collect all input files into one build directory.
+
+* The suffix should be `.ttcn` for TTCN–3 modules, `.asn` for ASN.1 modules and `.cc` for C/C++ files.
+
+* The file name (without suffix) should be identical to the module name. If the name of the ASN.1 module contains a hyphen, the corresponding file name should contain an underscore character instead. For example, the TTCN–3 module `My_Module` should be stored in `My_Module.ttcn` and the file containing ASN.1 module My-ASN1-Module should be named as `My_ASN1_Module.asn`.
+
+* Each C/C++ module should have a header file with identical name, but with the suffix `.hh`.
+
+==== Use of Central Storage
+
+Option `-c` can be used to create a `Makefile` that can use pre-compiled files from one or more central directories to save disk space and compilation time. Such `Makefiles` have different layout and more complex build rules.
+
+The central directories should contain those common modules that do not change frequently (type definitions, test ports, external functions, test configurations, and so on). The central directories should be updated and maintained by the project administrators while the individual testers are developing their test cases in their working directory based on the common files. Moreover, it is allowed to create a hierarchy of central directories, that is, to use a directory that takes files from other central directories as a central directory of another project. In such cases the files of all central directories should be passed to the compiler for `Makefile` generation.
+
+In addition to the above mentioned ones the following assumptions are used in these `Makefiles`:
+
+* The compiler will generate C\++ files only for those TTCN–3 and ASN.1 modules that are located in the current working directory. The generated C++ files of the remaining TTCN–3 and ASN.1 modules should be located in the same directory as the respective module. If a module is located in a directory other than the current working directory and it does not have pre-compiled files a symbolic link must be created in the current working directory, which should point to the file containing the module.
+
+* Object and if applicable, shared object files will be created only from those C/C++ source files that are located in the current working directory. Object and if applicable, shared object files of the remaining source files should be located in the same directory as the respective source file.
+
+* The TTCN–3 and ASN.1 modules of central directories should not import definitions from the modules of the current working directory. Importing in the reverse direction is allowed, of course.
+
+* C/C++ files of central directories should not include header files of the current working directory. Local C/C++ files can include headers from other directories.
+
+* The generated C++ files and object and if applicable, shared object files of all central directories must be up-to-date before invoking `make`. Otherwise the build process will fail immediately with an error message footnote:[If an object and if applicable, a shared object file of a central directory is not up-to-date, but make is invoked it tries to build that file instead of printing an error message. The build will usually fail due to missing access rights. This is a known limitation of this `Makefile` system that cannot be easily solved in a generic way.]. In case of multi-level hierarchy of central directories the re-compilation should be performed in bottom-up order in the central directories.
+
+* All directories must use the same environment, that is, same hardware platform, operating system, version of TTCN–3 Executor and C++ compiler, command line switches, and so on, for building. Otherwise compilation or run-time errors may occur.
+
+Note that when a pre-compiled TTCN–3 or ASN.1 module is taken from a central directory the following three files will be used from the central directory during the build process. Thus it is essential to keep all these files always consistent and up-to-date.
+
+* The module itself when performing the semantic analysis on the local modules importing it.
+
+* The generated C\++ header file when compiling the generated C++ files of the importing modules.
+
+* The object and if applicable, the shared object file when linking the executable.
+
+[[ttcn-3-preprocessing]]
+==== TTCN–3 Preprocessing
+
+Preprocessing of TTCN–3 source code is supported with the use of the option `-p`. The TTCN–3 source files to be preprocessed must have the suffix `.ttcnpp`; these files will be preprocessed with the C preprocessor before being compiled. The compiler will detect all TTCN–3 files, including the ones containing directives for the preprocessor, but only the ones with the suffix `.ttcnpp` will be preprocessed. If any other suffix is used the user has to edit the `Makefile` manually to add the file to the list of files which will be preprocessed. The output of the preprocessing will be an intermediate file with the extension `.ttcn`. Do not use the extension `.ttcn` for any TTCN–3 file that will be preprocessed; also avoid using the same name for different `.ttcn` and `.ttcnpp` files. Files included in `.ttcnpp` files with C preprocessor directive `#include` should have suffix `.ttcnin`.
+
+[[Makefile-Structure]]
+=== `Makefile` Structure
+
+This section presents the internal structure of the generated `Makefile`.
+
+For example, the following command will generate a `Makefile` for TTCN–3 test suite "Hello, world!", which can be found in binary distribution:
+
+`*$TTCN3_DIR/bin/ttcn3_`Makefile`gen -gs MyExample.ttcn PCOType.cc MyExample.cfg*`
+
+The `Makefile` generator creates the `Makefile` with the following content:
+[source]
+----
+# This Makefile was generated by the Makefile Generator
+# of the TTCN-3 Test Executor version 1.6.pl5
+# for Adam Delic (edmdeli@ehubuux110)
+# on Tue Oct 10 13:53:04 2006
+
+# Copyright Ericsson Telecom AB 2000-2014
+
+# The following make commands are available:
+# - make, make all Builds the executable test suite.
+# - make archive Archives all source files.
+# - make check Checks the semantics of TTCN-3 and ASN.1
+# modules.
+# - make port Generates port skeletons.
+# - make clean Removes all generated files.
+# - make compile Translates TTCN-3 and ASN.1 modules to
+# C++.
+# - make dep Creates/updates dependency list.
+# - make objects Builds the object files without linking
+# the executable.
+# - make tags Creates/updates tags file using ctags.
+# WARNING! This Makefile can be used with GNU make only.
+# Other versions of make may report syntax errors in it.
+#
+# Do NOT touch this line...
+#
+.PHONY: all archive check clean dep objects
+#
+# Set these variables...
+#
+# The path of your TTCN-3 Test Executor installation:
+# Uncomment this line to override the environment variable.
+# TTCN3_DIR =
+# Your platform: (SOLARIS, SOLARIS8, LINUX, FREEBSD or WIN32)
+PLATFORM = SOLARIS8
+# Your C++ compiler:
+CXX = g++
+# Flags for the C++ preprocessor (and makedepend as well):
+CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include
+# Flags for the C++ compiler:
+CXXFLAGS = -Wall
+# Flags for the linker:
+LDFLAGS =
+# Flags for the TTCN-3 and ASN.1 compiler:
+COMPILER_FLAGS = -L
+# Execution mode: (either ttcn3 or ttcn3-parallel)
+TTCN3_LIB = ttcn3
+# The path of your OpenSSL installation:
+# If you do not have your own one, leave it unchanged.
+OPENSSL_DIR = $(TTCN3_DIR)
+# Directory to store the archived source files:
+ARCHIVE_DIR = backup
+#
+# You may change these variables. Add your files if necessary...
+#
+# TTCN-3 modules of this project:
+TTCN3_MODULES = MyExample.ttcn
+# ASN.1 modules of this project:
+ASN1_MODULES =
+# C++ source & header files generated from the TTCN-3 & ASN.1
+# modules of this project:
+GENERATED_SOURCES = $(TTCN3_MODULES:.ttcn=.cc) $(ASN1_MODULES:.asn=.cc)
+GENERATED_HEADERS = $(GENERATED_SOURCES:.cc=.hh)
+# C/C++ Source & header files of Test Ports, external functions
+# and other modules:
+USER_SOURCES = PCOType.cc
+USER_HEADERS = $(USER_SOURCES:.cc=.hh)
+# Object files of this project that are needed for the executable
+# test suite:
+OBJECTS = $(GENERATED_SOURCES:.cc=.o) $(USER_SOURCES:.cc=.o)
+# Other files of the project (Makefile, configuration files, and so on)
+# that will be added to the archived source files:
+OTHER_FILES = Makefile MyExample.cfg
+# The name of the executable test suite:
+TARGET = MyExample
+#
+# Do not modify these unless you know what you are doing...
+# Platform specific additional libraries:
+#
+SOLARIS_LIBS = -lsocket -lnsl
+SOLARIS8_LIBS = -lsocket -lnsl
+LINUX_LIBS =
+FREEBSD_LIBS =
+WIN32_LIBS =
+#
+# Rules for building the executable...
+#
+all: $(TARGET) ;
+objects: $(OBJECTS) ;
+$(TARGET): $(OBJECTS)
+$(CXX) $(LDFLAGS) -o $@ $ˆ \
+-L$(TTCN3_DIR)/lib -l$(TTCN3_LIB) \
+-L$(OPENSSL_DIR)/lib -lcrypto $($(PLATFORM)_LIBS)
+.cc.o .c.o:
+$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) -o $@ $<
+$(GENERATED_SOURCES) $(GENERATED_HEADERS): compile
+@if [ ! -f $@ ]; then $(RM) compile; $(MAKE) compile; fi
+check: $(TTCN3_MODULES) $(ASN1_MODULES)
+$(TTCN3_DIR)/bin/compiler -s $(COMPILER_FLAGS) $ˆ
+port: $(TTCN3_MODULES) $(ASN1_MODULES)
+$(TTCN3_DIR)/bin/compiler -t $(COMPILER_FLAGS) $ˆ
+compile: $(TTCN3_MODULES) $(ASN1_MODULES)
+$(TTCN3_DIR)/bin/compiler $(COMPILER_FLAGS) $ˆ - $?
+touch $@
+tags: $(TTCN3_MODULES) $(ASN1_MODULES) \
+$(USER_HEADERS) $(USER_SOURCES)
+$(TTCN3_DIR)/bin/ctags_ttcn3 --line-directives=yes $ˆ
+clean:
+-$(RM) $(TARGET) $(OBJECTS) $(GENERATED_HEADERS) \
+$(GENERATED_SOURCES) compile \
+tags *.log
+dep: $(GENERATED_SOURCES) $(USER_SOURCES)
+makedepend $(CPPFLAGS) $ˆ
+archive:
+mkdir -p $(ARCHIVE_DIR)
+tar -cvhf - $(TTCN3_MODULES) $(ASN1_MODULES) \
+$(USER_HEADERS) $(USER_SOURCES) $(OTHER_FILES) \
+| gzip >$(ARCHIVE_DIR)/‘basename $(TARGET) .exe‘-\
+‘date ’+%y%m%d-%H%M’‘.tgz
+#
+# Add your rules here if necessary...
+#
+----
+[[Editing-the-Generated-Makefile]]
+=== Editing the Generated `Makefile`
+
+Assume that the TTCN–3 and ASN.1 modules together with the test ports have been written and a `Makefile` skeleton has been generated. The `Makefile` generator recognizes the operating environment and sets up some compiler/linker flags accordingly. The path to the TTCN–3 test executor installation must be set in `TTCN3_DIR` before starting to use `make`. If OpenSSL is installed and proprietary shared libraries will be used, the variable `OPENSSL_DIR` may be changed to point to the directory of the proprietary OpenSSL installation. In the above "Hello, world!" example the user also needs to change the execution mode (variable `TTCN3_LIB`) to non-parallel.
+
+Always perform the following checklist before the first build of the executable test suite from the generated `Makefile`:
+
+* Verify that the variable `TTCN3_DIR` is set to point to the root directory of the TTCN–3 test executor installation. If this variable is automatically set in the login script, this line can be removed from the `Makefile`.
+
+* Ensure that the variable PLATFORM is set to match the test execution platformfootnote:[The test suite must be translated on the same platform on which it will be executed.].
+
+* Verify that the variable `TTCN3_LIB` contains the name of the appropriate Base Library for the chosen operating mode, that is,` ttcn3` for single and `ttcn3-parallel` for parallel execution mode!
+
+* The variable `CXX` should point to the name or full path of the C++ compiler.
+
+* The variables `CPPFLAGS`, `CXXFLAGS` and `LDFLAGS` should contain the extra command line switches to be passed to the C\\++ preprocessor, compiler and linker, respectivelyfootnote:[For the detailed list and explanation of possible command line switches, refer to the manual page of the used C++ compiler]. For example, profiling or optimization is set here.
+
+* Using the variable `COMPILER_FLAGS` you can pass additional command line options to the TTCN–3 /ASN.1 compiler.
+
+* Ensure that the version of the TTCN–3 /ASN.1 compiler used is identical to the version of Base Library it is linked with. In case of version mismatch the generated C++ source files will not compile and an `#error` notification will be received. This means that changing to another version of TTCN–3 Test Executor, a full re-build of all modules using `make clean` must be performed.
+
+* Make sure to always build test ports from their source distribution. A version mismatch between the object and if applicable, shared object files may cause improper linkage or unpredictable behavior. It is thus contra-indicated to link precompiled test port objects and if applicable, shared objects into your executable (for example taken from a central repository). If the `Makefile` was generated with the option `-p` check also:
+
+* The variable `CPP` should point to the name or full path of the used C preprocessor.
+
+* Command line options for the C preprocessor can be given using the `CPPFLAGS TTCN3` variable. +
+
+WARNING: do not confuse it with the `CPPFLAGS` variable, which is used on the generated C++ code.
+
+* Specify additional files which are included (`#include` directive) into `ttcnpp` files with the variable `TTCN3_INCLUDES`. These files will be checked (modification time) at every build to determine if any dependent files need to be recompiled. Any file with extension `.ttcnin` will be added to TTCN3_INCLUDES by the `Makefile` generator.
+
+=== Available Commands
+
+The generated `Makefile` supports the following:
+
+* `*make all*`, `*make*`
++
+Creates or updates the executable test suite. Performs only those steps of compilation that are really necessary, that is, the output of which is outdated.
+
+* `*make archive*`
++
+Creates a backup copy of all source files and other files in a tar-gzip archive stored in directory set by the variable `ARCHIVE_DIR` footnote:[The value archive should not be assigned to the variable ARCHIVE_DIR otherwise the make archive command will work incorrectly. Choose other directory name, like backup.]. The command can be applied periodically: to avoid overwriting older versions, a time stamp containing the current date and time is included in the name of the archive file. The output of this command can be attached to trouble reports submitted for the TTCN–3 compiler or other parts of the TTCN–3 toolset.
+
+* `*make check*`
++
+Checks the syntax and semantics of the TTCN–3 and ASN.1 modules. This command does not create or update any generated files.
+
+* `*make clean*`
++
+Removes all generated files (generated C++ files, object and TITAN generated shared object files and the executable) and log files. This command is useful when changing to another version of the test executor or simply for saving disk space.
+
+* `*make compile*`
++
+Translates the TTCN–3 and ASN.1 modules to C\++. It is useful when the user wants to carry out the compilation of the generated C++ code later. As a result, an empty file named `compile` is created in the working directory. The attributes of this file contain the date and time of the last compilation, which helps the compiler in selective code generation. It is not recommended to change this file manually. The compiler will be invoked only if one or more of the TTCN–3 or ASN.1 modules were modified after that timestamp, otherwise the generated C++ files are up to date.
+
+* `*make diag*`
++
+Lists general information about the environment and the build. This information can be useful to fix build problem by the developers or the support team. The output contains: +
+- the compiler related information (titan version, build date, C\\++ version, license information, see command `*"compiler –v"*`), +
+- main controller related information (titan version, C++ compiler version, build date, license information, see command `*"mctr_cli –v"*`), +
+- C\++ compiler information (see command `*"g++ -v"*`), +
+- library creator info ( see command `*"ar –v"*`), +
+- values of environment variables `$TTCN3_DIR`, ``$ OPENSSL_DIR`, `$XML_DIR`, `$PLATFORM`.
+
+* `*make dep*`
++
+Obsolete. Creates or updates the dependency list between the C++ header and source files by invoking the utility `makedepend`. This command must be invoked before the first compilation or when the list of modules or test ports has changed. It is also necessary to run `make dep` if an import statement has been added or removed in a module. The command implies `make compile` and after that it modifies the `Makefile` itself. Used only with older `gcc` versions.
+
+* `*make objects*`
++
+Creates or updates the object files created from the C++ source files. This command has the same effect as `make all` except that the executable test suite is not linked in the final step.
+
+* `*make port*`
++
+Creates Test Port skeleton header and source files for all port types in the input TTCN-3 modules. Existing Test Port files will not be overwritten.
+
+* `*make shared_objects*`
+Creates the shared object files from object files, compiled with `-fPIC`. This target is present only when dynamic linking is enabled. For detailed information, refer to the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer’s Reference].
+
+* `*make run*`
++
+Creates or updates the executable test suite and then runs it. This is only recommended for simple test suites in single mode. Running requires a configuration file; its name by default is `config.cfg`. This file has to be written by the user.
+
+=== Building the Executable
+Issue the command `make dep` when finished creating and editing the `Makefile`. This command will translate all TTCN–3 and ASN.1 modules to C++ and will find the dependencies between them automatically. The `Makefile` will be modified; many lines will be appended to it.
+
+Finally, issue the `make` command, which will build the executable test suite. If any of the source files (TTCN–3 or ASN.1 modules or test port source files) has been changed, issue the `make` command to get an up-to-date binary.
+
+If TTCN–3 or ASN.1 modules or test ports are need to be added or removed to or from the project, regenerate the `Makefile` skeleton or change the variables `TTCN3_MODULES`, `ASN1_MODULES`, `GENERATED_HEADERS`, `GENERATED_SOURCES`, `OBJECTS` or `SHARED_OBJECTS` accordingly. If a new test port or other C/C++ module should be added, add it to the lines `USER_HEADERS`, `USER_SOURCES` and `OBJECTS` or `SHARED_OBJECTS`.
+
+WARNING: It is recommended to use the `makedepend` utility together with make. This ensures that all dependencies are handled correctly. Therefore, `make dep` command must be issued before the first use of `make` and whenever the module hierarchy (imports) changes! If no `make dep` command is issued then in some cases two `make` commands shall be issued for the successful compilation.
+
+Use the command `make clean` to remove all generated files.
+
+=== Modifying the Generated `Makefile`
+
+NOTE: this is a deprecated feature; whenever possible, a .tpd (Titan project descriptor) file should be used instead.
+
+When there is a `Makefile` in a project, it should be updated each time a further file is added or removed from the project.
+
+However, some manual modifications were made to the originally created `Makefile` skeleton, regeneration of the `Makefile` will cause the manually performed changes to be lost. To avoid this situation, write a shell script containing the `Makefile` updates, and configure this shell script to be automatically run after each instance of `Makefile` regeneration.
+
+This way, there is no need to perform the same manual updates upon every `Makefile` generation and file addition process.
+
+The shell script example below can be used to automate the modification of the `Makefile` with the updates every time it is regenerated.
+
+.Example Shell Script for `Makefile` Modification
+[source]
+----
+#!/bin/sh
+editcmd=’s/CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)\
+/include/CPPFLAGS = -D$(PLATFORM)
+-I$(TTCN3_DIR)\/include -I$(ERLANG_DIR)\
+/include -I$(OPENSSL_DIR)\/include/g
+s/TTCN3_LIB = ttcn3-parallel/TTCN3_LIB = ttcn3/g
+s/OPENSSL_DIR = $(TTCN3_DIR)/OPENSSL_DIR = \/mnt\/TTCN\/Tools\
+/openssl-0.9.7d/g
+s/ˆ makedepend/ \/mnt\/TTCN\/Tools\/makedepend-R6.6\
+/bin\/makedepend/g
+/ARCHIVE_DIR = ./ {
+a\
+a\
+# Directory for ERLANG:
+a\
+ERLANG_DIR = /OTP/LXA_11930_R9C_6/lib/erl_interface-3.4.2
+}
+s/-lcrypto $($(PLATFORM)_LIBS)/-lcrypto \\/g
+/-lcrypto \\/ {
+a\
+-L$(ERLANG_DIR)/lib -lerl_interface -lei $($(PLATFORM)_LIBS)
+}
+’
+if [ ‘uname‘ = SunOS ]
+then
+case ‘uname -r‘ in
+5.6) editcmd="$editcmd
+s/CXX = g++/CXX = \/usr\/local\/gnu\/bin\/g++/g"
+;;
+5.7) editcmd="$editcmd
+s/CXX = g++/CXX = \/mnt\/TTCN\/Tools\/gcc-3.0.4-sol7\/bin\/g++/g"
+;;
+5.8) editcmd="$editcmd
+s/CXX = g++/CXX = \/usr\/local\/gnu\/gnu28\/gcc3.0.4_shared_sol8\
+/bin\/g++/g"
+;;
+*) echo ’Unsupported Solaris version.’; exit 1
+esac
+else echo ’This script runs on Solaris only.’; exit 1
+fi
+sed -e "$editcmd" <$1 >$2
+----
+
+== Manual Building
+This section contains information useful for the experienced users who are using a build framework other than `make` for TTCN–3 -based testing.
+
+=== Compiling the Generated C++ Code
+
+If the TTCN–3 test suite was successfully translated to C\++, it’s a good idea to check if the generated code contains any errors. The simplest way is to compile it using a C++ compiler. Since the generated code refers to the base library, run the following command:
+[source, subs="+quotes"]
+*g++ -c -I$TTCN3_DIR/include -Wall MyModule.cc*
+
+In the following, using of an GNU C\++ compiler is assumed. If the TTCN–3 /ASN.1 compiler did not report any errors in the input test suite, the generated C++ code must be correct (that is, compile without errors). After certain TTCN–3 warnings (such as unreachable statements) the generated code may trigger similar warnings in the C++ compiler.
+
+The generated code has been tested on various versions of GNU C\++ and Sun Workshop C++ compilers. However, the code should work with any standard-compliant C\++ compiler since it does not depend on hardware or compiler specific features. If the generated code fails to compile on a supported platform and C++ compiler the situation is considered as a compiler bug and a Trouble Report can be issued footnote:[The Trouble Report must include the compiler error message(s), all input files and command line switches of the TTCN–3 /ASN.1 compiler, the platform and the exact version of TITAN TTCN–3 Test Executor and the C++ compiler. It is highly appreciated if the user could minimize the input by dropping out irrelevant modules and definitions.].
+
+The switch `-c` tells the GNU C++ compiler to compile only and not to build an executable because, for example, the `main` function is missing from the generated code. The switch `-I` adds the `$TTCN3_DIR/include` directory to the compiler’s standard include path. The optional argument, `-Wall`, forces the compiler to report all warnings found in its input. This argument can be used in GCC only.
+
+The result after a successful compilation is an object file named `MyModule.o` and if applicable, a shared object file named `MyModule.so`. If compilation fails, a lot of error messages may be generated. For example, a misspelled type name in an included test port can totally confuse the C++ compiler. That’s why it is recommended to analyze the reason of the first error message only.
+
+=== Linking the Executable
+
+In order to get the executable test suite, the following files must be linked:
+
+* The object and if applicable, shared object files generated from all used TTCN–3 modules.
+
+* The object and if applicable, shared object files generated from all used ASN.1 modules.
+
+* The object and if applicable, shared object files generated from all used test ports and any libraries that are used in the test ports.
+
+* The parallel `ttcn3-parallel` or the non-parallel `ttcn3` version of the TTCN3 Base Library depending on the chosen operating mode. They reside in `$TTCN3_DIR/lib`.
+
+* The shared library of OpenSSL, that is `$TTCN3_DIR/lib/libcrypto.so`.
+
+Assuming only one TTCN–3 module (called `MyModule`) and one test port (called `MyTestPort`), the linking command will be the following for parallel operation mode:
+
+[source, subs="+quotes"]
+*g++ -o MyModule MyModule.o MyTestPort.o -L$TTCN3_DIR/lib-lttcn3-parallel -lcrypto*
+
+The linking command for single operation mode:
+
+[source, subs="+quotes"]
+*g++ -o MyModule MyModule.o MyTestPort.o -L$TTCN3_DIR/lib -lttcn3 -lcrypto*
+
+The name of the executable file will be `MyModule` in both cases.
+
+=== Dynamic Linking
+
+In order to save disk and memory space, the TTCN–3 Base Library may be dynamically linked to the executable. In this case use the following command in single mode:
+
+[source, subs="+quotes"]
+*g++ -o MyModule MyModule.o MyTestPort.o -L$TTCN3_DIR/lib -lttcn3-dynamic -lcrypto*
+
+In parallel mode use `*-lttcn3-parallel-dynamic*` instead of
+`*-lttcn3-dynamic*`.
+
+When running the executable, add the directory `$TTCN3_DIR/lib` to the system library path (which is specified in `/etc/ld.so.conf` on most of UNIX systems) or simply add it to the environment variable `LD_LIBRARY_PATH`.
+
+From version 1.8pl2, `ttcn3_Makefilegen` supports the generation of (per module) shared objects. If this option is enabled with the `-l` command line switch, the project’s working directory (together with the central storage directories, if applicable) should be added to `LD_LIBRARY_PATH` in addition to `$TTCN3_DIR/lib`. Otherwise, the resulting executable may not run. If moving the executable from one machine to another, all the generated shared object (.so) files should be copied as well. For more information about the `–l` command line switch, please consult the  link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor].
diff --git a/usrguide/userguide/4-executing_test_suites.adoc b/usrguide/userguide/4-executing_test_suites.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..edc1e7ec538ac040be347e896bb2dc7a819bdb3e
--- /dev/null
+++ b/usrguide/userguide/4-executing_test_suites.adoc
@@ -0,0 +1,301 @@
+= Executing Test Suites
+
+This chapter describes the modalities of test suite execution.
+[[The-Run-time-Configuration-File]]
+== The Run-time Configuration File
+
+The behavior of the executable test program is described in the run-time configuration file.
+
+Each section of the configuration file begins with a section name within square brackets. Different sections use different syntax, thus the section name determines the possible syntax of the members.
+
+Refer to the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor] for details of the runtime configuration file including descriptions of each of its sections and examples.
+[[Running-Non-parallel-Test-Suites]]
+== Running Non-parallel Test Suites
+
+If an application is built for single operation mode the resulting executable contains the ETS itself.
+
+It takes a single optional parameter (the name and path of its configuration file) and two optional command line switches related to debugging:
+
+* `*-h*`
++
+Automatically halts execution at the beginning, when the first test case’s or control part’s execution begins, and displays the debugger’s user interface (debugging must be activated).
+
+* `*-b file*`
+Automatically executes the specified batch file (containing debugger commands) at the beginning of the program’s execution.
++
+The ETS also accepts the command line options `-l` and `-v` with the following semantics:
+
+* `*-l*`
++
+Lists the names of all control parts and individually executable test cases of the ETS to standard output. The list is suitable as the `[EXECUTE]` section of a configuration file. Refer to link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor] for more details.
+
+* `*-v*`
++
+Prints the tool version, license information and the name, compilation time, checksum and (if available) the version info of the participating modules.
+
+If the ETS contains exactly one module with a control part, then a configuration file need not be specified. In this case, running the ETS with no parameters will execute the control part. If more than one control part is present (or none at all) then the configuration file is mandatory.
+
+The ETS blocks until all test cases are executed as specified in the section `[EXECUTE]` of its configuration file. Console log messages are displayed on the terminal, while the execution log is written into `LogFile`.
+
+ETSes built for single operation mode are unable to act as HCs thus these cannot be executed in the parallel environment. The test suite should be re-linked with the parallel version of Base Library instead if this was the intention (see <<3-creating_executable_test_suites_from_the_command-l.adoc#Editing-the-Generated-Makefile, Editing the Generated Makefile>> for information on editing the `Makefile`).
+
+== Configuration
+
+The TITAN runtime environment uses configuration files to control execution of the test suites. An ordinary text editor can be used to create and modify configuration files. The configuration file (with the default extension `.cfg`) is a simple text file consisting of the following sections:
+
+* Module parameters
++
+This section contains the value of each parameter that is defined in the TTCN-3 or ASN.1 modules of the project.
+
+* Logging
++
+This section indicates logging conditions: the name of the log file, category and component based logging filters or the like.
+
+* Testport parameters
++
+This section specifies the parameters that are passed to the test ports during the execution of the test suite.
+
+* Define
++
+This section contains definitions of macros that can be used in other configuration file sections (except Include) for entry of recurring values.
+
+* Include
++
+Paths to additional configuration files may be listed in this section. The host controller takes into account the values listed in those configuration files, too.
+
+* External commands
++
+This section contains shell scripts that are called whenever a control part or a test case is started or terminated.
+
+* Execute
++
+This section indicates which parts of the test suite will be executed. This section is mandatory in single execution mode. Only test cases without parameters, or test cases where every parameter has a default value, can be started from this section. +
+Testcases with parameters can be started from the control part.
+
+The following sections are used only in parallel mode:
+
+* Groups
++
+This section specifies a groups of hosts used in the Components section.
+
+* Components
++
+This section contains the rules that restrict the location of PTCs.
+
+* Main controller
++
+This section controls the behavior of the main controller when executing a test suite.
+
+TITAN processes the configuration file sequentially. If a section occurs several times in the configuration file, all sections will be processed without an error message.
+
+Refer to the corresponding chapter of the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor] for details of the runtime configuration file including descriptions of each of its sections and examples.
+
+== Running Parallel Test Suites
+
+The test execution in parallel mode comprises the following steps:
+
+1. Start Main Controller. (See <<the-ttcn-3-main-controller, The TTCN-3 Main Controller>>)
+
+2. Start Host Controllers, that is, the executable test suite, on all participating computers. (See <<the-ttcn-3-host-controller,The TTCN–3 Host Controller>>)
+
+3. Create MTC.
+
+4. Start the control part or a selection of test cases of a TTCN–3 module on MTC.
+
+5. View the verdicts of executed test cases on MC.
+
+6. Terminate MTC after the end of execution.
+
+7. Terminate HCs and MC.
+
+8. Analyze the logs of each test component.
+
+[[parallel-ttcn-3-execution-architecture]]
+=== Parallel TTCN–3 Execution Architecture
+
+The components of test environment form two main groups: the Test System and the SUT. As TTCN–3 is used for black box testing, that is, the test suite does not assume anything about the internal structure of the SUT, this section describes the internal structure of Test System only. The Test System consists of one or more test components, whose behaviors are entirely described in a TTCN–3 test suite. The test system has other components for special purposes, listed below.
+
+Each component of the test system runs independently, they are different processes of the operating system. Every component executes one single thread of control. The components can be located on different machines and, of course, there can be more than one component running on the same computer. In the latter case scheduling among them is provided by the scheduler of the operating system. Regardless of their roles, all test components execute binary code generated from the same C++ source code. Their code consists of three parts: the code generated from the test suite by the TTCN–3 compiler, the Test Ports and the TTCN–3 Base Library.
+
+The components communicate with each other using TCP connections with proprietary protocols and platform independently encoded abstract messages. The components form three groups according to their functionality.
+
+image::images/titanparallel_execution_x.png[title="Components of parallel test execution"]
+
+* *Main Controller (MC)*
++
+The Main Controller is a stand-alone application delivered with the distribution (`$TTCN3_DIR/bin/mctr`). It is started manually by the user and runs in one instance during the entire test execution. MC provides the user with CLI to the test executor system. It arranges the creation and termination of Main Test Component on user request and the execution of module control part. It shows the user the verdicts of executed test cases. MC has many hidden tasks that can only be performed in a centralized way, for example component reference assignment, verdict collection, and so on. MC maintains a control connection with all other components.
+
+* *Host Controller (HC)*
++
+Host Controllers are instances (processes) of the executable test program, that is, the translated test suite linked with Test Ports and Base Library. Exactly one HC should be run on each computer that participates in (distributed) TTCN–3 test execution. HCs are started by the user manually on all participating computers. They maintain a connection to MC and if MC wants a new test component to be created on that host, HC duplicates itself and its child process will act as the new test component.
+
+* *Test Component (TC)*
++
+Can be either the Main Test Component or a Parallel Test Component.
+
+* *Main Test Component (MTC)*
++
+The Main Test Component is an instance of the executable test program that is firstly created on a user request. There is exactly one MTC in the Test System. It can execute the control part of a TTCN–3 module if requested by the user. If a test case is executed MTC changes its component type to the type specified in the `runs on` clause of the testcase. Note that MTC is the only one test component that can change its component type. MTC maintains a control connection to MC.
+
+* *Parallel Test Component (PTC)*
++
+Parallel Test Components are also instances of the same executable test program. TCs execute TTCN–3 functions written by the user in the same way as in non-parallel mode. They are automatically created by HC when requested from the MTC or other PTCs. PTCs also maintain a connection to MC.
+
+[[the-ttcn-3-main-controller]]
+=== The TTCN–3 Main Controller
+
+The binary executable of Main Controller is `$TTCN3_DIR/bin/mctr_cli`. It takes the optional configuration file (<<The-Run-time-Configuration-File, The Run-time Configuration File>>) as its single argument. The variables in the section `[MAIN CONTROLLER]` of the configuration file determine important MC properties, for detailed information refer to the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor].
+
+The Main Controller has two operation modes: interactive and batch mode. In interactive mode the user can control and monitor the test execution from a CLI. Batch mode is useful for automated and unattended execution of parallel and distributed tests. The actual operation mode depends on the configuration file and is determined at program startup. If the option `NumHCs` is set in the `[MAIN CONTROLLER]` section, the MC starts in batch mode, otherwise interactive mode is selected.
+
+==== Interactive Mode
+
+After starting MC in interactive mode a welcome screen and command prompt appear.
+[source]
+----
+********************************************
+* TTCN-3 Test Executor - Main Controller 2 *
+* Version: 1.3.pl0 *
+********************************************
+MC2>
+----
+The MC command line interface uses the `editline` library which is compatible with the GNU `readline` editing functionality. In addition to its powerful line editing functions it provides command completion, line history and help function.
+
+Command completion is activated using the tabulator key. It presents the list of applicable commands according to the typed prefix. The typing of the command is concluded when a single alternative remains (for example pressing key `c` followed by the tabulator puts the `cmtc` command onto the command line).
+
+The last couple of entered command lines are stored in the history buffer. The implementation is based on GNU `history` library. The buffer elements can be browsed with the cursor keys or an incremental search backward can be performed following a `<CTRL>-r` keystroke and a lot more. History buffer contents are automatically saved and loaded when the `mctr cli` is started or stopped into a file named `.ttcn3 history` located in the home directory. Note that console log messages as well as notifications of HC connection establishments are printed on the MC’s screen and may disrupt its contents.
+
+The following commands are accepted by the MC:
+
+* `help [command]` displays the list of available commands or a short use information about the command submitted as parameter.
+* `cmtc [hostname]` creates the MTC on the given host. If the optional hostname is omitted, the MTC will be created on the host whose HC has connected first. Once an MTC is created, this command cannot be used before terminating the MTC via emtc.
+* `smtc [module name[.control|.testcase name|.\*]]` is used to start test execution. smtc has a single optional parameter defining the name of the module or test case to start. The MTC must exist and it must be in idle state when using this command. smtc is a non-blocking command, there is a prompt and it is possible to issue other commands while the test case execution is proceeding. When the module name argument is used (with or without the .control suffix) then smtc starts executing the control part of that module. footnote:[TTCN–3 assumes to have a single control part within an ETS. Our Test Executor, however, removed this limitation and permits multiple module control parts within the ETS. The smtc command can be used to select between the available control parts, which one needs to be executed. Moreover, it can be specified to execute a number of different control parts, too.] When it is intended to select a single test case for execution, smtc is told using the format `module name.testcase name`. Only those test cases can be executed individually that have no formal parameters, or every formal parameter has a default value. It is also possible to execute all individually startable test cases defined inside a module by specifying the module `name.*` as smtc parameter. In case the optional parameter is omitted, the contents of the `[EXECUTE]` section of the configuration file are run after each other if that section was specified.
+* `emtc` terminates MTC. When using this command MTC must be in idle state, that is, it cannot be killed.
+* `info` prints statistics and status information of the currently connected HCs and test components.
+* `reconf` instructs MC to re-read and re-distribute its configuration file to the connected HCs. This feature is useful when restarting a test campaign involving multiple HCs, because the tester configuration can be altered eliminating the drawback of restarting and reconnecting all elements of the test set-up manually.
+* `stop` terminates test execution. The verdict of the actual test case will not be considered in the statistics of the test suite.
+* `pause [on|off]` sets whether to interrupt test execution after each test case. For setting the state of the pause function on or off values can be used. If the state of the pause function is on and the actual test case is finished, the execution is stopped until the continue command is issued. If pause is in off state and the actual test case is finished, the execution is continued with the next test case. Using pause without these options it simply prints the state of the pause function.
+* `continue` resumes interrupted test execution.
+* `log [on|off]` enables/disables console logging. It can be set using on or off. If log is in off state no log messages will be printed to MC’s console. Using log without these options it simply prints the state of logging.
+* `!` prefix is used to execute command line contents in a subshell.
+* `exit` terminates all HCs and MC itself. This command can be used when test execution is not in progress. If MTC still exists it will be terminated gracefully, like with emtc.
+* `quit` is an alias to exit to provide backward compatibility.
+
+==== Batch Mode
+
+If MC is started in batch mode no command prompt is given. In order to monitor the actual state of execution the console messages are printed to the standard output.
+
+In batch mode, the MC performs the following actions sequentially:
+
+* MC waits until the specified number of HCs, that is given in configuration option `NumHCs`, are connected.
+* MTC is created on the host of firstly connected HC. Equivalent command: `cmtc`
+* The items of the `[EXECUTE]` section are launched sequentially. Equivalent command: `smtc`
+* After all items are finished the MTC is terminated. Equivalent command: `emtc`
+* The session and all HCs are shut down and MC exits. Equivalent command: `exit`
+
+If the `[EXECUTE]` section of the configuration file is empty or it is missing the MC stops in batch mode immediately with an error message.
+
+If a fatal error is encountered during initialization, for example due to an error in the configuration file, no MTC is created and the session stops immediately. If an error happens within a test case the normal error recovery routines are activated and the execution continues with the next test case.
+
+==== Performance Hints
+NOTE: if performance tests are executed with a large number of test components, MC can be a performance bottleneck in the test executor system. If performance problems occur around the test executor, the first thing that should be checked is the operating environment of MC. Running MC on a dedicated computer with a powerful CPU can help in the most cases.
+
+MC maintains a control TCP connection with all other components (HCs, MTC and PTCs). Each of these connections use an open file descriptor, which is a limited resource in the operating system. If many test components should be run simultaneously, this limitation can be a bottleneck. However, the number of open files per process can be increased up to a so called hard limit (for example 1024 on Solaris and unlimitedfootnote:[The total number of open files can also be a bottleneck on Linux kernel, which can be changed through the /proc file system.] on Linux). The limit can be increased by a built-in shell commandfootnote:[Called limit on tcsh and ulimit on bash. For more details please consult the manual page of the used shell.], of course, before starting MC. On the other hand, the license key also limits the number of simultaneously active PTCs, which is considered in MC when processing TTCN–3 create operations.
+
+==== Displaying ASCII Art on Startup
+
+The command line main controller displays an ASCII art file that is located in the `$TTCN3_DIR/etc/asciiart` directory. There can be any number of ASCII art text files in that directory, a random file will be chosen from those. The file name can contain special filtering instructions, if such instructions are detected in the file name then the file is grouped into the special files group, all other files are in the normal group. If there is at least one file in the special group that was not filtered out by the condition(s) given in the file name then the file to be displayed will be chosen randomly from the list of special files. If there are no such special files or all of these were filtered out by their filtering instructions then a normal file will be displayed. The filtering instructions in the file name are separated by dots, one instruction consists of a name and a value which are separated by a dash. If the value is of numerical type then it can be a single number or an interval, an interval consists of 2 numbers separated by an underscore. Currently the following filtering condition name and value pairs can be used:
+
+[cols=",,",options="header",]
+|====================================================
+|Filter condition name |Value, type of value |Example
+|user |User name, string |user-edmdeli
+|weekday |Number/interval, 1-7 |weekday-6_7
+|day |Number/interval, 1-31 |day-1
+|month |Number/interval, 1-12 |month-12
+|year |Number/interval |year-2013
+|hour |Number/interval, 0-23 |hour-18_23
+|minute |Number/interval, 0-59 |minute-30
+|second |Number/interval, 0-61 |second-0_30
+|====================================================
+
+Example file names: +
+`xmasparty.month-12.day-24_26.txt` +
+`weekendwork.weekday-6_7.txt`
+
+Displaying ASCII art can be prevented by deleting all files from the directory. Adding some filtering conditions can be done by renaming the file according to the above described naming rules.
+
+[[the-ttcn-3-host-controller]]
+=== The TTCN–3 Host Controller
+
+The ETS built for parallel operation mode will act as Host Controller. After starting up it establishes a TCP connection to MC (which must be started prior to HC) and waits for requests. The executable takes two mandatory arguments, the host name or IP address and the TCP port number that MC listens on footnote:[If MC and HC runs on the same computer and you run Host Controllers on other computers as well, never use localhost or 127.0.0.1 as host name argument to HC. The IP address that the HC’s connection comes from may be transferred by MC to TCs running on other hosts. Giving out the local IP address may result in incorrect behavior.].
+
+The optional command line switch `-s` can be used to specify the source address of control connections towards MC. Either an IP address or a DNS name can be given after the switch. Only such IP address is accepted that is assigned to one of the local network interfaces. This option can be useful on multi-homed hosts, that is, computers with more than one network interfaces, in order to route all traffic of control connections to a separate network path to avoid disturbances in the communication with SUT. If the option is omitted the local IP address is chosen automatically based on MC’s IP address and the kernel routing table. The test components, child processes of HC, will use the same local IP address for their connections as the HC independent if it was set manually or automatically.
+
+The command line synopsis for HC is the following:
+[source,subs="specialchars,quotes"]
+*<executable_program_name> [-s <local_address>] <MC_host> <MC_port>*
+
+NOTE: In earlier versions, the HCs accepted an optional third command line argument specifying the configuration file name. From version 1.3 (MC version 2), the MC distributes configuration data to all participating HCs. Consequently, the configuration file became a command line argument of the MC.
+
+The ETS linked in parallel mode accepts the command line switches `-l` and `-v` like in single mode (see <<Running-Non-parallel-Test-Suites, Running Non-parallel Test Suites>>). If the test execution is performed in a distributed environment and file synchronization between computers is not automatic (for example you use FTP instead of a shared NFS directory), it is useful to check the module checksums and versions with flag `-v` on each computer before starting the HCs.
+
+From version 1.3.pl0 the MC checks the version of each connected HC automatically in order to ensure the consistency of the distributed test system. If the ETSes used in the same test campaign contain different TTCN–3 modules or different versions of the same TTCN–3 modules the HC connections, except the firstly connected one, will be refused by the MC.
+
+=== Logging in Parallel Mode
+
+During test execution all test components create separate log files. Each log file has the same format as presented in non-parallel mode. Logging into the same, NFS shared directory makes the log analysis easier.
+
+The name of log files can be explicitly set in the configuration file using a metacharacter substitution mechanism. If the file names are not set, the backward compatible default naming convention is used. It is important to ensure that every component has its own unique log file name. Refer to the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor] for more details.
+
+In parallel mode the log messages sent to the console are transmitted through the network and printed on the user interface of MC in normal cases. Thus it is an unwise thing to log all messages to the console without filtering when the test suite is used for load generation. If the control connection from a TC or HC to MC is broken due to any error, the console log messages are written to the standard error of the ETS locally.
+
+=== Automation of Testing in Parallel Mode
+
+The starting procedure of TTCN–3 tests in parallel mode can be a tiring task if it has to be repeated the tests several times. We have developed a small script that can do this work for you. It is based on the `expect` command, which is an extension of the TCL scripting language. The script is called `ttcn3_start` and is located in `$TTCN3_DIR/bin`. In order to use it a working `expect` interpreter must be in the `$PATH`.
+
+The script itself is very simple, it takes one mandatory and one or more optional arguments. The first mandatory argument is the name of the ETS that is launched. The second argument can be the name of the configuration file that will be passed to MC during execution. If this argument is omitted or the second argument does not resemble to a file name, the script will look for file `<ETS name>.cfg` in its current working directory. If such file exists, it will be used as configuration file. Otherwise MC will be launched without configuration file.
+
+Additionally, the IP address of the interface used for communication between the MC and the ETS can be specified. The syntax is `–ip` followed by the IP address in dotted decimal format, for example 192.168.0.1. If not specified explicitly, the address defaults to the IP address of the local machine.
+
+The rest of arguments are the list of test cases to be executed in format `<modulename>.<testcase name>`. They are passed to MC command `smtc` sequentially, see <<the-ttcn-3-main-controller, The TTCN–3 Main Controller>> for details. If these arguments are missing and a configuration file is present the items of section `[EXECUTE]` will be executed, that is, `smtc` will be called without arguments. If neither configuration file nor test cases are specified the control part of the main TTCN–3 module, that is, the module that has the same name as the ETS, is executed.
+
+The script works the following way: first it launches the MC. If the environment variable `TTCN3_DIR` is set the MC is started from directory `$TTCN3_DIR/bin` (to find the right one multiple versions are present), otherwise the command `mctr cli` is invoked using your search path. If the configuration file is present it is passed to MC as a command line argument. After that `ttcn3_start` launches the ETS, that is, the HC, locally with the appropriate arguments. That is, the script guesses the host name and extracts the TCP port number from the output of MC automatically. Then the script issues the `cmtc` and the appropriate `smtc` commands in the MC command prompt and waits until test execution is finished. Finally it terminates the programs by issuing `emtc` and `quit`. It also takes care of MC’s answers and issues the commands in the right state.
+
+The messages coming from the standard output or standard error of MC, HC and the test components are continuously displayed in the output of `ttcn3_start`.
+
+Note that this script does not support distributed test execution when more than one HC has to be started.
+
+Examples for the invocation of `ttcn3_start`:
+[source]
+----
+$ ttcn3_start Main_Control
+$ ttcn3_start Main_Control multi.cfg
+$ ttcn3_start Main_Control –ip 10.10.10.10 multi.cfg
+$ ttcn3_start Main_Control SNMP_Testcases.tc_110 SNMP_Testcases.tc_113  SNMP_Testcases.tc_114
+$ ttcn3_start Main_Control multi.cfg SNMP_Testcases.tc_110 _Testcases.tc_113 SNMP_Testcases.tc_114
+----
+The script returns different exit codes which can be used by user written software which invokes it. In case of success the return code is 0, in error cases the return codes are the following:
+
+[cols=",",options="header",]
+|====================================================================
+|*Return code* |*Error description*
+|1 |The expect tool was not found.
+|2 |Parameters are missing.
+|3 |Cannot find the given executable.
+|4 |The script cannot be used when MC is run in batch mode.
+|5 |The MC has terminated unexpectedly.
+|6 |The given executable is not a TTCN-3 executable in parallel mode.
+|7 |The executable could not connect to the MC.
+|8 |The MTC cannot be created.
+|9 |The MTC cannot be created on an unknown host.
+|10 |The MTC terminated unexpectedly.
+|====================================================================
+
+== Strange Behavior of the Executable
+
+If modular test suites are executed, sometimes the executable test program can do strange things, for example, the execution terminates without any reason or the send functions of the Test Port is not called, and so on. This is because out-of-date C\++ header files are used for translating the C++ modules, that is, there is a wrong `Makefile`.
+
+This may happen when the Test Port files are renamed, so the compiler regenerates them. Thus the C++ source files generated by the compiler see an empty Test Port header file, but the fully functional Test Port object file is linked to the executable. In this case, the linking will be successful, but during the execution strange things can happen. The reason behind this phenomenon is that the modules consider the raw binary structure of the same C++ class different, for example they fetch the virtual function pointer from a wrong place.
+
+Avoid these situations and re-compile all C++ files before reporting such bugs, and the use of `makedepend` utility is strongly recommended.
diff --git a/usrguide/userguide/5-log_processing.adoc b/usrguide/userguide/5-log_processing.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..51c90e0c2e79bea2eaab55bbafcab922e8745a9b
--- /dev/null
+++ b/usrguide/userguide/5-log_processing.adoc
@@ -0,0 +1,202 @@
+= Log Processing
+
+The logs generated by the test executor, although they are ASCII text files, are perfect for machine processing, but not for analyzing by humans. To make these log files more readable log formatting tools are provided. All of these programs require the same license feature, `LOGFORMAT`. The programs are designed so that they can be used either individually or bundled together with UNIX pipelines.
+
+* `Logmerge` is useful for test suites that are run in parallel mode. It can merge the logs of different PTC into one single file based on the timestamps.
+
+* `Logfilter` can be used for post filtering large log files based on the kind of logged events. It can be specified to keep or remove the event type(s).
+
+* `Logformat` breaks the sent and received data structures into lines and indents the fields according to their hierarchy. Moreover, if the test suite was executed in single mode, the log formatter splits the logs of each test case into separate files.
+
+* `Repgen` can present not only the formatted log files but the description and TTCN–3 source code of test cases as well as the output of other network monitor programs, like `tcpdump`, in HTML format. The test results can be easily viewed by any JavaScript capable Web browser.
+
+== The `logmerge` Utility
+
+The `logmerge` utility, which can be found in `$TTCN3_DIR/bin`, merges all files given in the command argument into a single output file. The output of logmerge is sorted based on the timestamps found in the log files.
+
+The command line syntax is:
+
+[source,subs="+quotes"]
+*ttcn3_logmerge [ -o _outfile_ ] [ file.log ] …*
+
+or
+[source,subs="+quotes"]
+*ttcn3_logmerge -v*
+
+Available command line switches are:
+
+* `*-o _outfile_*`
++
+Merges all input log files into `outfile`. If the `outfile` exists its contents will be overwritten. This switch is optional, if it is omitted, merged logs will be printed to standard output.
+
+* `*-v*`
++
+Prints `version` and license key information and exits. Each line of the input files should contain an event in the following format: +
+`<timestamp> <rest of the event>`
+
+Merging log files with different types of timestamps, for example with timestamp format `Time` and `DateTime`, results in warning message(s), and only files with same format are merged. Merging log files with timestamp format `Seconds` is not. If a file contains one or more timestamp(s) that is in wrong order, the resulting order will be incorrect too. In this case a warning message will be printed to the standard error.
+
+The output of the utility is the following:
+
+[source,subs="specialchars,quotes"]
+<timestamp> <component id> <rest of the event>
+
+where `<component id>` is taken from the name of the respective input file. If the name of the input file is not in the format `<ets name>.<host>-<component id>.log`, the whole input file name will be used as `<component id>`. Events spreading over multiple lines are also handled properly.
+
+== The `logfilter` Utility
+
+The `logfilter` utility, which can be found in `$TTCN3_DIR/bin`, filters the input log file given in the command line argument based on the event types in the file, and filter parameters given in the program argument. The output is then written to an output file if specified, or to the standard output. The program is useful only if the variable `LogEventTypes` is set to `yes` in section `[LOGGING]` of the configuration file.
+
+The command line syntax is:
+
+[source,subs="+quotes"]
+*ttcn3_logfilter [ -o _outfile_ ] {eventtype(+__|__-)}[input.log]*
+
+or
+
+[source,subs="+quotes"]
+*ttcn3_logfilter -v _|_ -h _|_ -l*
+
+Available command line switches are:
+
+* `*-h*`
++
+Prints `help` on using the utility.
+
+* `*-l*`
++
+Prints the `list` of supported event types.
+
+* `*-o _outfile_*`
++
+Puts its output into `outfile`. If the `outfile` exists, its contents will be overwritten. This switch is optional, if it is omitted, the output will be printed to standard output.
+
+* `*-v*`
++
+Prints `version` and license key information and exits.
+
+The utility can handle one file at a time, giving more input files results an error. If no input file is given, it reads the log from standard input. `Logfilter` can be efficiently used as the middle stage of a pipeline, combined with `logmerge` and `logformat`.
+
+Event types to be included or excluded should be given without the `TTCN` prefix, that is, as they appear in the log file. Undefined event type(s), that are not listed in the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor], specified as filter parameters will cause warning message(s), but will not cause the utility to quit. If there are parameters specified both to include and to exclude one or more event types, the program will quit with an error message, because in this case it is not well defined how to handle other event types. All possible error and warning messages will be printed to standard error.
+
+== The `logformat` Utility
+
+The `logformat` utility, which can be found in `$TTCN3_DIR/bin`, reads the unformatted log file generated by test executor from its standard input. It can split up the log into several files based on the lines that are automatically logged at the beginning or end of each test case. Furthermore, `logformat` formats the sent and received messages in the log file. The structured values are indented and each field is put into a new line according to the braces and commas.
+
+The command line syntax is:
+
+[source,subs="+quotes"]
+*ttcn3 logformat [ -i _n_ ] [ -o _outfile_ ] [ -s ] [ -n ][ file.log ] …*
+
+or
+
+[source,subs="+quotes"]
+*ttcn3 logformat -v*
+
+The switches denoted by square brackets are optional. The following command line options are available (listed in alphabetical order):
+
+* `*-i _n_*`
++
+Sets the depth of each indentation level to `_n_` characters. The default value is `_4_`. If the sent or received PDU is too complex and has too deeply nested fields, this number can be decreased to get more readable output.
+
+* `*-o _outfile_*`
++
+Places the output into file `outfile`. If the `-s` flag is also set, only those parts of the log files will be written into this file that were logged outside the test cases, that is, in control part or on PTCs. If this option is omitted, the formatted log will be printed to standard output.
+
+* `*-s*`
++
+If this option is set, the entries that were recorded during the execution of a particular test case will be saved in a separate file in `logformat`’s working directory. The name of this file will be identical to the name of the test case. If the same test case is executed several times after each other, the results of repeated test runs will be collected after each other. If the output file contained some data before `logformat` was started, for example the results of previous test run, the output file will be emptied and the old logs will be destroyed. +
+`logformat` recognizes any types of timestamps that can be set in the `[LOGGING]` section of the configuration file. +
+
+WARNING: This option is useless when formatting the log files of PTCs, because these logs do not contain the name of the testcase the PTC belongs to.
+
+* `*-n*`
++
+If this option is set, newline and tab control characters are not modified, they are printed as \n and \t.
+
+* `*-v*`
++
+Prints `version` and license key information and exits.
+
+`logformat` formats all files that are given as arguments and concatenates them after each other. If no files are given, it reads the log from standard input.
+
+== The HTML Report Generator
+
+The HTML report generator called `repgen` can be found in `$TTCN3_DIR/bin`. The program requires one command line argument that contains the name of its configuration file. The behavior of `repgen` can be configured only through this file. If the switch `-h` is given instead of the name of the configuration file, `repgen` prints a sample configuration file to its standard output.
+
+The configuration file of `repgen` is a simple text file which contains a sequence of directives. Its usual suffix is `.ts`. Each directive starts with a special keyword beginning with a hash mark (#) character. The first part of configuration file should contain global settings, the description of test cases can be added after that.
+
+The following table summarizes all global settings:
+
+[width="100%",cols="30%,70%",options="header",]
+|===
+|Keyword |Meaning
+|`#Title` |The name of the ETS. This string will be used as title in the resulting HTML pages.
+|`#Tab length` |The report generator replaces all tabulator characters with spaces in the TTCN–3 test cases and log files. This parameter sets how many spaces a single tab character should be replaced with. The default value is `_8_`.
+|`#Column width`| The report generator breaks the long lines of the ATS and the external monitor logs. The resulting lines in HTML output will not be longer than this limit. The default value is `_80_` characters.
+|`#TTCN-3 code` |The name of the directory that contains the TTCN–3 source files of the test suite. All files will be searched in this directory whose name ends with `.ttcn`. `repgen` collects the source code of test cases that are listed in the remainder of this configuration file. The referenced functions, templates and other definitions are not collected. An absolute or a relative path may be entered, the starting point is always the `repgen`’s working directory, for this and the following three parameters. The same directory may be used for many purposes because the file names do not clash.
+|`#TTCN-3 log` |The name of the directory that contains the log file(s) of the test executor. The report generator splits and formats the log files using the log formatter `logformat`. All files will be formatted in this directory whose name ends with .log. If the log of one test case can be found more than once in the log file(s), for example, because of repeated test execution, the resulting HTML page will contain the log of one execution. The others will be lost.
+|`#Other log` |The name of the directory that contains the log files of the external monitor programs, for example `tcpdump`. Each file should contain the messages (network packets) recorded during the execution of one test case. The log files in this directory must be named as `<testcase name>.dump` where `<testcase name>` stands for the name of the corresponding test case. All files must be in ASCII format. `logformat` will simply copy them into the destination directory and will not change their content.
+|`#Destination` |The name of the destination directory where the files of the resulting HTML report should be stored by `repgen`. The starting page will be `<title>-report.html` in this directory and the other files will be stored under sub-directory `<title>-report`, where `<title>` stands for the string set as the value of parameter `#Title`. Note that each space and dash in this name will be replaced by an underscore character.
+|===
+
+After the global settings, the name and description of all test cases after each other (in arbitrary order) can be listed. +
+
+NOTE: `repgen` processes the source code and logs only for those test cases that are listed in the configuration file. The TTCN–3 code and logs of other test cases will be silently ignored. A test case can be specified using the following keywords:
+
+[width="100%",cols="30%,70%",options="header",]
+|===
+|Keyword |Meaning
+|`#Testcase` |The name of the test case. It must be the same as in the TTCN–3 code.
+|`#Purpose` |A short summary of the test case describing in one sentence what it does. It must not be longer than one line. These short descriptions will be listed on the HTML page that lists the results of all test cases in one table.
+|`#Description` |This section should contain the detailed description of the test case. It may continue through several lines, until the next `#Testcase` directive. Figures or message sequence charts can be drawn using ASCII characters, but images cannot be embedded.
+|===
+
+For browsing the HTML reports the only thing needed is to open the starting page, the file `<title>-report.html` in the destination directory, with a JavaScript capable web browser. The reports should work with any versions of Netscape and Microsoft Internet Explorer on any platforms. The reports can be viewed locally or remotely using any web server.
+
+The starting page consists of two list boxes and four buttons (in addition to the title and the Ericsson logo). The test case can be selected in the left list box. After selecting a test case the available descriptions and logs will be shown on the right list box. The following items can be selected: +
+
+    * *Detailed description*
+    * *TTCN–3 code*
+    * *TTCN–3 executor’s log*
+    * *Other type of log* +
+
+If one or more items for the test case are missing from input files, the missing option will not be shown. Select or unselect the available descriptions and logs one-by-one independently by clicking on them.
+
+After selecting a test case and its items the ”Show” button at bottom should be pressed to view the selected logs and descriptions. A new browser window will be opened for each test case and the selected items will be shown in vertically split frames. The text in each frame can be scrolled independently. Of course, the `logformat` tool is unable to figure out the relation between the TTCN–3 source code and the produced log events.
+
+In the root window, it is possible to walk through the available test cases step-by-step using the buttons *Previous* and *Next*. The button *Summary* will bring up another window that lists all test cases, their short descriptions and verdicts in a single table to get a quick overview about the test results.
+
+.*Example:* In the following is an example configuration file of `logformat`. We included the descriptions of the first three test cases only.
+[source]
+----
+#Title ROHC
+#Tab length 8
+#Column width 80
+#TTCN-3 code /home/ethpkr/ROHC
+#TTCN-3 log /home/ethpkr/ROHC/log
+#Other log ./
+#Destination ./
+#Testcase CTC01
+#Purpose Mode transition from Unidirectional to Optimistic mode.
+#Description
+Comp->IRs, Comp->IR_DYNs, Comp->UO-0s, Decomp->Feedback(mode
+transition u->o), Comp->UO-0s
+#Testcase CTC02
+#Purpose Feedback processing in Unidirectional mode.
+#Description
+Testing the compressor’s feedback processing capabilities in U
+mode.
+#Testcase CTC03
+#Purpose Operation in Optimistic mode (NACK).
+#Description
+Testing the compressor’s operation in Bidirectional Optimistic
+mode. Preamble: taking the compressor to SO state and O mode.
+After that a NACK is sent as an answer to a received compressed
+packet. The answer for that should be an IR with dynamic chain
+or UOR-2 or an IR-DYN packet.
+[...]
+----
+NOTE: `repgen` was designed to present the results of non-parallel test cases. In case of parallel test execution, the logs of PTCs cannot be browsed, only the MTC log.
+
+WARNING: During its run `repgen` will start the other log formatter program `logformat`. That is why `repgen` works correctly only if the directory `$TTCN3_DIR/bin` is included to the path.
diff --git a/usrguide/userguide/6-references.adoc b/usrguide/userguide/6-references.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..1157f1bcf9cf29334ae8ce2e699ac89e833fe84e
--- /dev/null
+++ b/usrguide/userguide/6-references.adoc
@@ -0,0 +1,7 @@
+= References
+
+1.  link:https://github.com/eclipse/titan.core/blob/master/usrguide/installationguide.adoc[Installation guide for TITAN TTCN-3 Test Executor]
+2.  link:https://github.com/eclipse/titan.core/blob/master/usrguide/referenceguide/README.adoc[Programmers Technical Reference for TITAN TTCN-3 Test Executor]
+3.  link:https://github.com/eclipse/titan.core/blob/master/usrguide/releasenotes.adoc[Release Notes for TITAN TTCN-3 Test Executor]
+4.  TTCN–3 Style Guide 1/0113-FCPCA 101 35
+5.  TTCN–3 Naming Convention ETH/R-04:000010
diff --git a/usrguide/userguide/UserGuide.adoc b/usrguide/userguide/UserGuide.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..0f495e1aa497f7e5608c0128bed69f9e47ef6aea
--- /dev/null
+++ b/usrguide/userguide/UserGuide.adoc
@@ -0,0 +1,51 @@
+---
+Author: Jenő Balaskó
+Version: 1/198 17-CRL 113 200/6, Rev. PE1
+Date: 2018-06-18
+
+---
+= User Guide for TITAN TTCN-3 Test Executor
+:author: Jenő Balaskó
+:revnumber: 1/198 17-CRL 113 200/6, Rev. PE1
+:revdate: 2018-06-18
+:title-logo-image: images/titan_logo.png
+:toc:
+
+ifdef::env-github,backend-html5[]
+image::images/titan_logo.png[alt]
+endif::[]
+
+== Abstract
+
+This document describes detailed information on using the TITAN TTCN-3 Toolset, creating, compiling and executing test suites.
+
+== Copyright
+
+Copyright (c) 2000-2018 Ericsson Telecom AB +
+All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 that accompanies this distribution, and
+
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html
+
+== Disclaimer
+
+The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson should have no liability for any error or damage of any kind resulting from the use of this document.
+
+== Contents
+
+ifdef::env-github,backend-html5[]
+* link:1-about_the_document.adoc[About the Document]
+* link:2-overview_of_titan.adoc[Overview of TITAN]
+* link:3-creating_executable_test_suites_from_the_command-l.adoc[Creating Executable Test Suites from the Command-line]
+* link:4-executing_test_suites.adoc[Executing Test Suites]
+* link:5-log_processing.adoc[Log Processing]
+* link:6-references.adoc[References]
+endif::[]
+
+ifndef::env-github,backend-html5[]
+include::1-about_the_document.adoc[]
+include::2-overview_of_titan.adoc[]
+include::3-creating_executable_test_suites_from_the_command-l.adoc[]
+include::4-executing_test_suites.adoc[]
+include::5-log_processing.adoc[]
+include::6-references.adoc[]
+endif::[]
\ No newline at end of file
diff --git a/usrguide/userguide/images/titan_logo.png b/usrguide/userguide/images/titan_logo.png
new file mode 100644
index 0000000000000000000000000000000000000000..52512562f4df5e35fa7a40a1a59fc1c00ef445dd
Binary files /dev/null and b/usrguide/userguide/images/titan_logo.png differ
diff --git a/usrguide/userguide/images/titanexecutor_structure_x-wmf b/usrguide/userguide/images/titanexecutor_structure_x-wmf
new file mode 100644
index 0000000000000000000000000000000000000000..d78c9fa858954a176888d740201abc8bbf03e027
Binary files /dev/null and b/usrguide/userguide/images/titanexecutor_structure_x-wmf differ
diff --git a/usrguide/userguide/images/titanexecutor_structure_x.png b/usrguide/userguide/images/titanexecutor_structure_x.png
new file mode 100644
index 0000000000000000000000000000000000000000..772fb97becd53bc7d703253bcfab9d19937d4899
Binary files /dev/null and b/usrguide/userguide/images/titanexecutor_structure_x.png differ
diff --git a/usrguide/userguide/images/titanparallel_execution.x-wmf b/usrguide/userguide/images/titanparallel_execution.x-wmf
new file mode 100644
index 0000000000000000000000000000000000000000..8f6c404f23c28f329179c3566b11db0d77d40f15
Binary files /dev/null and b/usrguide/userguide/images/titanparallel_execution.x-wmf differ
diff --git a/usrguide/userguide/images/titanparallel_execution_x.png b/usrguide/userguide/images/titanparallel_execution_x.png
new file mode 100644
index 0000000000000000000000000000000000000000..c6cf4da8606f5212a74fadc668b80a0033b2a5c6
Binary files /dev/null and b/usrguide/userguide/images/titanparallel_execution_x.png differ