ISO/TR 16401-1:2018
(Main)Electronic fee collection — Evaluation of equipment for conformity to ISO/TS 17575-2 — Part 1: Test suite structure and test purposes
Electronic fee collection — Evaluation of equipment for conformity to ISO/TS 17575-2 — Part 1: Test suite structure and test purposes
ISO/TR 16401-1:2018 covers the test purposes for Front End Communications API covering functionalities related to instance handling, session handling, communication service primitives (i.e. sending/receiving of ADUs) and visible state transitions. It covers EFC communication services described in ISO 17575‑2:2016, Clause 5 and PICS proforma in ISO 17575‑2:2016, B.2. Claims related to Front End storage capacity are out of scope of this document. ISO/TR 16401-1:2018 covers the test purposes for Front End Application related to session establishment on Back End request and related to session re-establishment when session requested by Back End failed. There are no other claims with respect to Front End Application described in ISO 17575‑2. The underlying communication technology requirements for layer 1 to 4 specified in ISO 17575‑2:2016, Clause 6 are out of scope of this document. Similarly, Back End Communications API is out of scope of this document. According to ISO 17575‑2 it is expected that these Front End Communications API will be "reflected" in the BE; however, BE Communications API is out of scope of ISO 17575‑2. Test purposes have been organized into the test suite groups, designated for the Front End Communications API and Front End Application, respectively. Aside from the test purposes, this document also provides proforma conformance test reports templates for both the Front End and Back End test purposes. ISO 17575‑2 contains more information regarding the requirements against which the conformance is evaluated in this document.
Perception du télépéage — Évaluation de conformité de l'équipement à l'ISO/TS 17575-2 — Partie 1: Structure de la suite d'essais et objectifs d'essai
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TR
REPORT 16401-1
First edition
2018-01
Electronic fee collection — Evaluation
of equipment for conformity to ISO/TS
17575-2 —
Part 1:
Test suite structure and test purposes
Perception du télépéage — Évaluation de conformité de l'équipement
à l'ISO/TS 17575-2 —
Partie 1: Structure de la suite d'essais et objectifs d'essai
Reference number
ISO/TR 16401-1:2018(E)
©
ISO 2018
---------------------- Page: 1 ----------------------
ISO/TR 16401-1:2018(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2018, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2018 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TR 16401-1:2018(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Test Suite Structure . 5
5.1 Structure . 5
5.2 Reference to conformance test specifications . 5
5.3 Test purposes (TP) . 5
5.3.1 TP definition conventions . 5
5.3.2 TP naming conventions . 6
5.4 Protocol Conformance Test Report (PCTR). 7
Annex A (informative) Test purposes (TP) for Front End Communications API.8
Annex B (informative) Test purposes (TP) for Front End Application .137
Annex C (informative) PCTR proforma for Front End Communications API .141
Annex D (informative) PCTR proforma for Front End Application .148
Bibliography .152
© ISO 2018 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TR 16401-1:2018(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This edition of ISO/TR 16401-1 cancels and replaces ISO/TS 16401-1:2012, which has been technically
revised.
The main changes compared to the previous edition are as follows:
— the document has been converted from a Technical Specification to a Technical Report;
— the terms and definitions have been revised;
— the test purpose naming convention has been changed, i.e. “/” has been replaced by “_”;
— editorial corrections, as well as changes to improve readability have been made.
A list of all parts in the ISO/TR 16401 series can be found on the ISO website.
iv © ISO 2018 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TR 16401-1:2018(E)
Introduction
This document is part of a set of standards that supports interoperability of autonomous electronic fee
collection (EFC) systems. Autonomous systems use satellite positioning, often combined with additional
sensor technologies such as gyroscopes, odometers and accelerometers, to localize the vehicle and to
find its position on a map containing the charged geographic objects, such as charged roads or charged
areas. From the charged objects, the vehicle characteristics, the time of day and other data that are
relevant for describing road use, the tariff and ultimately, the road usage fee is determined.
The ISO/TR 16401 series provides tests to assess the Front End Communications API and Front End
Application behaviours compliancy towards the requirements listed in ISO 17575-2. This document
contains the definition of such tests in the form of test purposes, listing the initial conditions, references
and individual steps in a structured textual manner. ISO/TR 16401-2 contains the identical tests
written in Testing and Test Control Notation version 3 (TTCN v3).
Autonomous on-board equipment (OBE) operates without relying on dedicated roadside infrastructure
by employing wide-area technologies such as Global Navigation Satellite Systems (GNSS) and Cellular
Communications Networks (CN). Therefore, autonomous systems can also be referred to as GNSS/CN
systems.
ISO/TR 16401-1 is based on
— ISO 17575-2, and
— the ISO 9646 family of standards on conformance test methodology.
© ISO 2018 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/TR 16401-1:2018(E)
Electronic fee collection — Evaluation of equipment for
conformity to ISO/TS 17575-2 —
Part 1:
Test suite structure and test purposes
1 Scope
This document covers the test purposes for Front End Communications API covering functionalities
related to instance handling, session handling, communication service primitives (i.e.
sending/receiving of ADUs) and visible state transitions. It covers EFC communication services
described in ISO 17575-2:2016, Clause 5 and PICS proforma in ISO 17575-2:2016, B.2. Claims related to
Front End storage capacity are out of scope of this document.
This document covers the test purposes for Front End Application related to session establishment on
Back End request and related to session re-establishment when session requested by Back End failed.
There are no other claims with respect to Front End Application described in ISO 17575-2.
The underlying communication technology requirements for layer 1 to 4 specified in ISO 17575-2:2016,
Clause 6 are out of scope of this document.
Similarly, Back End Communications API is out of scope of this document. According to ISO 17575-2
it is expected that these Front End Communications API will be “reflected” in the BE; however, BE
Communications API is out of scope of ISO 17575-2.
Test purposes have been organized into the test suite groups, designated for the Front End
Communications API and Front End Application, respectively.
Aside from the test purposes, this document also provides proforma conformance test reports
templates for both the Front End and Back End test purposes.
ISO 17575-2 contains more information regarding the requirements against which the conformance is
evaluated in this document.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
area charging
charging based on road usage within a given area
[SOURCE: ISO 17575-1:2016, 3.1]
© ISO 2018 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/TR 16401-1:2018(E)
3.2
attribute
addressable package of data consisting of a single data element (3.9)or structured sequences of data
elements
[SOURCE: ISO 17575-1:2016, 3.2]
3.3
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
3.4
Back End
part of a back office system interfacing to one or more Front Ends (3.11)
[SOURCE: ISO 17575-1:2016, 3.4]
3.5
charge object
geographic or road related object for the use of which a charge is applied
[SOURCE: ISO 17575-1:2016, 3.5]
3.6
charge report
information containing road usage and related information originated at the Front End (3.11)
[SOURCE: ISO 17575-1:2016, 3.6]
3.7
cordon
border line of an area
[SOURCE: ISO 17575-1:2016, 3.7]
3.8
cordon charging
charging for the crossing of a cordon (3.7)
[SOURCE: ISO 17575-1:2016, 3.8]
3.9
data element
coded information, which might itself consist of lower level information structures
[SOURCE: ISO 17575-1:2016, 3.9]
3.10
data set
logical set of data elements (3.9) with a semantic relation
[SOURCE: ISO 17575-3:2016, 3.10]
3.11
Front End
part of a tolling system consisting of an OBE (3.14) and possibly a proxy (3.15) where road tolling
information and usage data are collected and processed for delivery to the Back End (3.4)
[SOURCE: ISO/TS 19299:2015, 3.17]
2 © ISO 2018 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TR 16401-1:2018(E)
3.12
Front End Application
part of the Front End (3.11) above the API
[SOURCE: ISO 17575-2:2016, 3.12]
3.13
layout
technical description of the location of tolled objects including their borders
[SOURCE: ISO 17575-3:2016, 3.12]
3.14
on-board equipment
OBE
all required equipment on-board a vehicle for performing required EFC functions and communication
services
3.15
proxy
optional part of a Front End (3.11) that communicates with external equipment and processes the data
received into an agreed format to be delivered to the Back End (3.4)
[SOURCE: ISO 17575-1:2016, 3.13]
3.16
road section charging
tolling principle where the fee is due if predefined sections of roads are used
[SOURCE: ISO 17575-1:2016, 3.14]
3.17
toll
charge, tax or duty levied in connection to using a vehicle in a toll domain (3.21)
[SOURCE: ISO/TS 19299:2015, 3.42 modified]
3.18
tolled area
geographic area where a toll (3.17) is charged for road usage
[SOURCE: ISO 17575-3:2016, 3.17]
3.19
toll context
logical view as defined by attributes (3.2) and functions of the basic elements of a toll scheme consisting
of a single basic tolling principle, a spatial distribution of the charge objects (3.5) and a single behaviour
of the related Front End (3.11)
[SOURCE: ISO 17575-1:2016, 3.17]
3.20
toll context data
information defined by the responsible Toll Charger necessary to establish the toll (3.17) due for using a
vehicle on a particular toll context (3.19) and to conclude the toll transaction
[SOURCE: ISO 12855:2015, 3.15]
© ISO 2018 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/TR 16401-1:2018(E)
3.21
toll domain
area or part of a road network where a certain toll regime (3.22) is applied
[SOURCE: ISO 17573:2010, 3.18]
3.22
toll regime
set of rules, including enforcement rules, governing the collection of toll (3.17) in a toll domain (3.21)
[SOURCE: ISO 17573:2010, 3.20]
3.23
toll scheme
organizational view of a toll regime (3.22), including the actors and their relationships
[SOURCE: ISO 17575-3:2016, 3.22]
3.24
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: ISO 17575-1:2016, 3.21]
3.25
transaction model
functional model describing the structure of electronic payment transactions
[SOURCE: ISO 14906:2011, 3.25 modified]
4 Abbreviated terms
ADU Application data unit
API Application Programming Interface
ASN.1 Abstract Syntax Notation One
ATS Abstract Test Suite
BE Back End
BI Behaviour invalid
BV Behaviour valid
CN Cellular network
IUT Implementation under test
EFC Electronic fee collection
FE Front End
GNSS Global Navigation Satellite Systems
ID Identifier
OBE On-board equipment
PCTR Protocol Conformance Test Report
PICS Protocol Implementation Conformance Statements
4 © ISO 2018 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TR 16401-1:2018(E)
TP Test purposes
TSS Test Suite Structure
TTCN Testing and Test Control Notation
5 Test Suite Structure
5.1 Structure
Table 1 shows the Test Suite Structure (TSS).
Table 1 — Test Suite Structures
Group Type of IUT Behaviour
Behaviour valid
Instance handling Front End Communications API
Behaviour invalid
Behaviour valid
Front End Communications API
Session handling Behaviour invalid
Front End Application Behaviour valid
Behaviour valid
Communication service
Front End Communications API
primitives
Behaviour invalid
State transitions Front End Communications API Behaviour valid
5.2 Reference to conformance test specifications
This document takes into account already defined test purposes for conformance to the base standards
by referencing them, so that
a) for test purposes that are identical to those defined in this document or the base standards
conformance test cases, direct reference is reported; for reader’s convenience, the title or a verbal
description of the referenced test purpose is given, together with the reference,
b) for test purposes that are derived from those defined in the base standards conformance test
cases, a direct reference is reported, plus an indication on how the referred test purpose has to be
modified for the profile conformance testing,
c) for test purposes that are specific to ISO 17575-2, complete description is given, and
d) an indication on whether a test purpose is identical, derived or specific is given in each test
purpose.
5.3 Test purposes (TP)
5.3.1 TP definition conventions
The TPs are defined following the rules shown in Table 2. Test purposes are defined in Annex A and
Annex B, including the following special notation and symbol conventions.
© ISO 2018 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/TR 16401-1:2018(E)
Table 2 — TP definition rules
Title:
Reference:
TP ID according
to the TP naming TP origin:
conventions
Initial condition:
Stimulus and expected behaviour:
TP ID The TP ID is a unique identifier. It is specified according to the TP
naming conventions defined in the subclause below.
Title Short description of TP objective.
Reference The reference should contain the references of the subject to be vali-
dated by the actual TP (specification reference, clause, paragraph), or
the reference to the standard document defining the TP.
TP origin Indicates if the TP is identical to a TP defined in another test stand-
ard, derived from a TP defined in another test standard, or specific
for this standard profile.
Initial condition The condition defines in which initial state the IUT has to be to apply
the actual TP.
Stimulus and expected Definition of the events the tester performs and the events that are
behaviour expected from the IUT to conform to the base specification.
5.3.2 TP naming conventions
Each TP is given a unique identification. This unique identification is built up to contain the following
string of information:
TP____
TP : indicates that it is a test purpose;
: indicates to which group the TP belongs;
: indicates the type of IUT, i.e. API or APPL;
: indicates the type of testing, i.e. behaviour valid tests (BV) or behaviour invalid
tests (BI);
: indicates the sequential TP number (01 to 99).
The naming conventions are as described in Table 3.
6 © ISO 2018 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TR 16401-1:2018(E)
Table 3 — TP naming convention
Identifier: TP___-
applicable for FE Communications API IH Instance Handling
applicable for FE Communications API SH Session Handling
applicable for FE Application SH Session Handling
applicable for FE Communications API CSP Communications Service Primitives
applicable for FE Communications API ST State Transitions
= type of IUT API Front End Communications API
APPL Front End Application
= type of testing BV Behaviour Valid Tests
BI Behaviour Invalid Tests
= sequential number (01 to 99) Test Purpose Number
5.4 Protocol Conformance Test Report (PCTR)
The supplier of the Front End is responsible for providing a conformance test report.
The supplier of the Front End Communications API should complete the Protocol Conformance Test
Report (PCTR) proforma as defined in Annex C.
The supplier of the Front End Application should complete the Protocol Conformance Test Report
(PCTR) proforma as defined in Annex D.
© ISO 2018 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/TR 16401-1:2018(E)
Annex A
(informative)
Test purposes (TP) for Front End Communications API
A.1 Overview
This annex contains the test purposes (TP) for the conformity evaluation of Front End Communications
to ISO 17575-2.
A.2 TP symbols conventions
A special notation and symbol convention is used, as defined in this subclause.
Definitions of the symbols used in the description of the TPs are provided in Table A.1.
Table A.1 — Description of TP Symbols
Symbol Description
XXX(Type1 = value1) ⇒ The tester executes an XXX method of FE Communications API
with argument Type1 having a value of value1.
Value1 is stored in the tester's memory for further TP processing.
⇐ R:ReturnedType The IUT returns a value of type ReturnedType.
⇐ C:CallbackName (Type1) The IUT provides a callback CallbackName receiving
variable of type Type1.
Type ISO 17575-2 Anytime Type defined in ISO 17575-2 is used.
It means a variable of Type.
A → B A “is transformed” into B.
Ø Means “empty” or “not set”.
A | B A or B
A ! = B A is not equal to B.
i = i + 1 Increment variable i by 1.
In testing the Front End Communications API, it is needed to trigger operations and observe the IUT
feedback both from the Front End Application and remote end (i.e. Back End) perspective. Thus, there
are two test points located as shown in Figure A.1.
Application emulation test point is used directly with the IUT and emulates the Front End Application
layer. It is identified in the following test purposes by the AppEm discriminator.
Remote End emulation test point is linked with the IUT over communications channel. Depending on
the test purposes, it emulates application, presentation and session layer. It is identified in the following
test purposes by the RemEnd discriminator.
8 © ISO 2018 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/TR 16401-1:2018(E)
Figure A.1 — Handling of ADUs applicable for a particular TP
A.3 Instance handling
These test purposes apply to instance handling as described in ISO 17575-2:2016, B.2, with respect to
following PICS proforma entries:
— API supports InitialiseInstance;
— API supports SetParameter;
— API supports GetParameter;
— API supports DeleteParameter;
— API supports DropInstance;
— API supports StackAvail.
A.3.1 BV test purposes (Behaviour Valid tests)
Test subgroup objective:
— to test IUT behaviour with respect to instance initialization, including multiple instance handling in
parallel;
— to test IUT behaviour with respect to parameter setting and updating;
— to test IUT behaviour with respect to parameter getting;
— to test IUT behaviour with respect to parameter deleting;
— to test IUT behaviour with respect to availability of communications stack;
— to test IUT behaviour with respect to dropping the session with the following severities:
— SENormal;
— SEUrgent;
— SEUnconditional.
© ISO 2018 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_01 Verify the communications interface initialization.
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition FE Communications API shall handle at least one underlying
communication stack: which StackID equals to stack1.
Set of Callback instances is instantiated.
Stimulus and expected behaviour
Test
Tester IUT
point
1 InitialiseInstance (StackID = stack1, AppEm ⇒
Callbacks = cb1)
2 AppEm ⇐ R: Instance
3 Verify whether Instance is valid.
4 IF verify OK
THEN TP passed
ELSE TP failed
ENDIF
10 © ISO 2018 – All rights reserved
---------------------- Page: 15 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_02 Verify the multiple instance communications interface initialization
based on the same communications stack.
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition FE Communications API shall handle at least one underlying
communication stack: which StackID equals to stack1.
Sets of Callback instances are instantiated.
Stimulus and expected behaviour
Test
Tester IUT
point
1 InitialiseInstance (StackID = stack1, AppEm ⇒
Callbacks = cb1)
2 AppEm ⇐ R: Instance
3 Verify whether Instance is valid.
4 IF verify OK
THEN GOTO step 5
ELSE TP failed
ENDIF
5 InitialiseInstance (StackID = stack1, AppEm ⇒
Callbacks = cb2)
6 AppEm ⇐ R: Instance
7 Verify whether Instance is valid.
8 IF verify OK
THEN GOTO step 9
ELSE TP failed
ENDIF
9 InitialiseInstance (StackID = stack1, AppEm ⇒
Callbacks = cb3)
10 AppEm ⇐ R: Instance
11 Verify whether Instance is valid.
12 IF verify OK
THEN TP passed
ELSE TP failed
ENDIF
© ISO 2018 – All rights reserved 11
---------------------- Page: 16 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_03 Verify the multiple instance communications interface
initialization based on different communications stack.
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition FE Communications API shall handle at least two underlying
communication stacks: which StackID equals to stack1 and stack2.
Sets of Callback instances are instantiated.
Stimulus and expected behaviour
Test
Tester IUT
point
1 InitialiseInstance (StackID = stack1, AppEm ⇒
Callbacks = cb1)
2 AppEm ⇐ R: Instance
3 Verify whether Instance is valid.
4 IF verify OK
THEN GOTO step 5
ELSE TP failed
ENDIF
5 InitialiseInstance (StackID = stack2, AppEm ⇒
Callbacks = cb2)
6 AppEm ⇐ R: Instance
7 Verify whether Instance is valid.
8 IF verify OK
THEN TP passed
ELSE TP failed
ENDIF
12 © ISO 2018 – All rights reserved
---------------------- Page: 17 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_04 Verify that parameter is set by the Front End Application
(single parameter).
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition A valid Instance, instance1, is created.
Stimulus and expected behaviour
Test
Tester IUT
point
1 SetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”,
Value = “Value1”)
2 AppEm ⇐ R: CEN175752Error
3 Verify whether CEN175752Error
equals to ERNoError.
4 IF verify NOT OK
THEN TP failed
ENDIF
5 GetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”)
6 AppEm ⇐ R: String
7 IF (String equals to Value1)
THEN TP passed
ELSE TP failed
ENDIF
© ISO 2018 – All rights reserved 13
---------------------- Page: 18 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_05 Verify that parameter is set by the Front End Application for multiple
instances (different parameter names).
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition Valid Instances, instance1 and instance2, are created.
Stimulus and expected behaviour
Test
Tester IUT
point
1 SetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”,
Value = “Value1”)
2 AppEm ⇐ R: CEN175752Error
3 Verify whether CEN175752Error
equals to ERNoError.
4 IF verify NOT OK
THEN TP failed
ENDIF
5 GetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”)
6 AppEm ⇐ R: String
7 IF (String equals to Value1)
THEN GOTO step 8
ELSE TP failed
ENDIF
8 SetParameter (Instance = instance2, AppEm ⇒
Parameter = “Parameter2”,
Value = “Value2”)
9 AppEm ⇐ R: CEN175752Error
10 Verify whether CEN175752Error
equals to ERNoError.
11 IF verify NOT OK
THEN TP failed
ENDIF
12 GetParameter (Instance = instance2, AppEm ⇒
Parameter = “Parameter2”)
13 AppEm ⇐ R: String
14 IF (String equals to Value2)
THEN TP passed
ELSE TP failed
ENDIF
14 © ISO 2018 – All rights reserved
---------------------- Page: 19 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_06 Verify that parameter is set by the Front End Application for multiple
instances (the same parameter names).
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition Valid Instances, instance1 and instance2, are created.
Stimulus and expected behaviour
Test
Tester IUT
point
1 SetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”,
Value = “Value1”)
2 AppEm ⇐ R: CEN175752Error
3 Verify whether CEN175752Error
equals to ERNoError.
4 IF verify NOT OK
THEN TP failed
ENDIF
5 GetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”)
6 AppEm ⇐ R: String
7 IF (String equals to Value1)
THEN GOTO step 8
ELSE TP failed
ENDIF
8 SetParameter (Instance = instance2, AppEm ⇒
Parameter = “Parameter1”,
Value = “Value2”)
9 AppEm ⇐ R: CEN175752Error
10 Verify whether CEN175752Error
equals to ERNoError.
11 IF verify NOT OK
THEN TP failed
ENDIF
12 GetParameter (Instance = instance2, AppEm ⇒
Parameter = “Parameter1”)
13 AppEm ⇐ R: String
14 IF (String equals to Value2)
THEN TP passed
ELSE TP failed
ENDIF
© ISO 2018 – All rights reserved 15
---------------------- Page: 20 ----------------------
ISO/TR 16401-1:2018(E)
TP_IH_API_BV_07 Verify that parameter is updated by the Front End Application.
TP origin Specific
Reference ISO 17575-2:2016, 5.2.1
Initial condition A valid Instance, instance1, is created.
Stimulus and expected behaviour
Test
Tester IUT
point
1 SetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”,
Value = “Value1”)
2 AppEm ⇐ R: CEN175752Error
3 Verify whether CEN175752Error
equals to ERNoError.
4 IF verify NOT OK
THEN TP failed
ENDIF
5 GetParameter (Instance = instance1, AppEm ⇒
Parameter = “Parameter1”)
6 AppEm ⇐ R: String
7 IF (String equals to Value1)
THEN G
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.