ISO/TS 16401-1:2012
(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/TS 16401-1:2011 specifies the test suite structure (TSS) and test purposes (TP) to evaluate the conformity of Front End Communications API and Front End application to ISO/TS 17575-2.
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/TS
SPECIFICATION 16401-1
First edition
2012-03-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/TS 16401-1:2012(E)
©
ISO 2012
---------------------- Page: 1 ----------------------
ISO/TS 16401-1:2012(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 16401-1:2012(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviations.2
5 Test Suite Structure (TSS).3
5.1 Structure.3
5.2 Reference to conformance test specifications .3
5.3 Test Purposes (TP).4
5.3.1 TP definition conventions.4
5.3.2 TP naming conventions.4
5.4 Protocol Conformance Test Report (PCTR) .5
Annex A (normative) TP for Front End Communications API.6
Annex B (normative) Annex ATP for Front End Application.139
Annex C (informative) PCTR Proforma for Front End Communications API.143
Annex D (informative) PCTR Proforma for Front End Application .150
Bibliography.154
© ISO 2012 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 16401-1:2012(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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee
casting a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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.
ISO/TS 16401-1 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with Technical Committee CEN/TC 278, Road transport and traffic telematics.
ISO/TS 16401 consists of the following parts, under the general title Electronic fee collection — Evaluation of
equipment for conformity to ISO/TS 17575-2:
— Part 1: Test suite structure and test purposes
— Part 2: Abstract test suite
iv © ISO 2012 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 16401-1:2012(E)
Introduction
This part of ISO/TS 16401 is part of a set of standards that supports interoperability of autonomous EFC-
systems, which includes ISO/TS 17575 parts 1 to 4 that define the EFC context data, their charge reports and
their use of communication infrastructure.
Within the suite of EFC standards this conformance evaluation procedure defines the process and tests for
conformity evaluation of Front End Communications API and Front End application that comply with the
requirements in ISO/TS 17575-2.
This part of ISO/TS 16401 is intended to
⎯ assess Front End Communications API and Front End application capabilities,
⎯ assess Front End Communications API and Front End application behaviour,
⎯ serve as a guide for Front End Communications API and Front End application conformance evaluation
and type approval,
⎯ achieve comparability between the results of the corresponding tests applied in different places at
different times, and
⎯ facilitate communications between parties.
This part of ISO/TS 16401 is based on
⎯ ISO/TS 17575-2, and
⎯ the ISO/IEC 9646 family of standards on conformance test methodology.
© ISO 2012 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/TS 16401-1:2012(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 part of ISO/TS 16401 specifies the test suite structure (TSS) and test purposes (TP) to evaluate the
conformity of Front End Communications API and Front End application to ISO/TS 17575-2.
The objective of this part of ISO/TS 16401 is to provide a basis for conformance tests for Front Ent
Communications API and Front End application in Electronic Fee Collection based on autonomous on-board
equipment (OBE) to enable interoperability between different equipment supplied by different manufacturers.
This part of ISO/TS 16401 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 fully covers EFC communication services claimed
in ISO/TS 17575-2 clause 7 and PICS proforma Clause B.2 ISO/TS 17575-2. Claims related to Front End
Storage capacity are outside of the scope of this part of ISO/TS 16401.
This part of ISO/TS 16401 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 claimed in ISO/TS 17575-2.
The underlying communication technology requirements for layer 1-4 specified in Clause 8 ISO/TS 17575-2 is
outside of the scope of this part of ISO/TS 16401.
Similarly Back End communications API is outside of the scope of this part of ISO/TS 16401. According to
ISO/TS 17575-2 it is expected that these Front End Communications API will be reflected in the BE, however
BE Communications API is outside of the scope of ISO/TS 17575-2.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/TS 17575-1, Electronic fee collection — Application interface definition for autonomous systems —
Part 2: Charging
ISO/TS 17575-2, Electronic fee collection — Application interface definition for autonomous systems —
Part 2: Communication and connection to the lower layers
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 17575-1 and the following apply.
© ISO 2012 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/TS 16401-1:2012(E)
3.1
contract
expression of an agreement between two or more parties concerning the use of the road infrastructure
[ISO 14906:2011, definition 3.7]
NOTE A contract specifies obligations, permissions and prohibitions for the objects involved.
3.2
Front End application
part of the Front End above the API
3.3
service provider
operator that accepts the user's payment means and in return provides a road-use service to the user
NOTE Taken from ISO 14906:2004.
3.4
toll charger
legal entity charging toll for vehicles in a toll domain
[ISO/TS 17574:2009, definition 3.27]
4 Abbreviations
For the purposes of this document, the following abbreviations apply throughout the document unless
otherwise specified.
ADU Application Data Unit
API Application Programming Interface
ASN.1 Abstract Syntax Notation One
ATS Abstract Test Suite
BE Back End
BI Invalid Behaviour
BV Valid Behaviour
CCC Compliance Check Communication
CN Cellular Network
DUT Device Under Tests
EFC Electronic Fee Collection
FE Front End
GNSS Global Navigation Satellite Systems
HMI Human Machine Interface
ID Identifier
2 © ISO 2012 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TS 16401-1:2012(E)
OBE On-Board Equipment
PCTR Protocol Conformance Test Report
PICS Protocol Implementation Conformance Statements
TP Test Purposes
TSS Test Suite Structure
VAT Value Added Tax
5 Test Suite Structure (TSS)
5.1 Structure
Table 1 — Test Suite Structures shows the Test Suite Structure (TSS).
Table 1 — Test Suite Structures
Group Type of DUT Behaviour
Instance Handling Front End Communications Valid Behaviour
API
Invalid Behaviour
Session Handling Front End Communications Valid Behaviour
API
Invalid Behaviour
Front End application Valid Behaviour
Communication Service Front End Communications Valid Behaviour
Primitives API
Invalid Behaviour
State Transitions Front End Communications Valid Behaviour
API
5.2 Reference to conformance test specifications
This part of ISO/TS 16401 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 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/TS 17575-2, a complete description is given.
d) An indication on whether a test purpose is identical, derived, or specific is given in each test purpose.
© ISO 2012 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/TS 16401-1:2012(E)
5.3 Test Purposes (TP)
5.3.1 TP definition conventions
The TPs are defined following the rules shown in Table 2 — TP Definition Rules below. All Test Purposes are
defined in Annex A and Annex B, including the special notation and symbol conventions that shall be used.
Table 2 — TP Definition Rules
TP ID according to the TP naming Title
conventions Reference
TP origin
Initial condition
Stimulus and expected behaviour
TP ID The TP ID is a unique identifier. It shall be specified according to
the TP naming conventions defined in the sub-clause below.
Title Short description of Test Purpose objective.
Reference The reference should contain the references of the subject to be
validated 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
standard, 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 DUT 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
DUT 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 : to indicate that it is a Test Purpose;
: which group TP belongs to;
: type of DUT (i.e. API or APPL);
X : type of testing (i.e. Valid Behaviour tests – BV, or Invalid Behaviour tests – BI);
: sequential TP number (01-99).
The naming conventions are as described in Table 3.
4 © ISO 2012 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TS 16401-1:2012(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 DUT API Front End Communications API
APPL Front End application
x = Type of testing BV Valid Behaviour Tests
BI Invalid Behaviour Tests
= sequential number (01-99) Test Purpose Number
5.4 Protocol Conformance Test Report (PCTR)
The supplier of the Front End and Back End, respectively, is responsible for providing a Protocol
Conformance Test Report (PCTR).
The supplier of the Front End and the Back End shall complete a PCTR; see Annex C and Annex D for the
proformas.
© ISO 2012 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/TS 16401-1:2012(E)
Annex A
(normative)
TP for Front End Communications API
A.1 Introduction
This annex contains the Test Purposes (TP) for the conformity evaluation of Front End Communications API
to ISO/TS 17575-2.
A.1.1 TP symbols conventions
A special notation and symbol convention is used, as defined in what follows.
Symbols are used in the description of the TPs, with meanings according to Table A.1 below.
Table A.1 — Description of TP Symbols
SYMBOL DESCRIPTION
XXX(Type1=value1) The Tester executes an XXX method of Front End
Communications API with argument of Type1 having value
value1.
Value1 shall be stored in tester's memory for further TP
processing.
R:ReturnedType
The DUT returns a value of type ReturnedType
C:CallbackName (Type1) The DUT provides a callback CallbackName receiving
variable of type Type1.
Type ISO/TS 17575-2 Anytime Type defined in ISO/TS 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 B
i = i+1 Increment variable i by 1
Testing Front End Communications API it is needed to trigger operations and observe the DUT 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 using directly with DUT and emulates the Front End application layer. It is
identified in the following test purposes by AppEm discriminator.
6 © ISO 2012 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TS 16401-1:2012(E)
Remote End emulation test point is linked with DUT over communications channel. Depending on the test
purposes it emulates application, presentation and session layer. It is identified in the following test purposes
by RemEnd discriminator.
Testpoint:
Application
Emulation
Testpoint:
FE
Remote End
Communications
Front End Emulation Back (Remote) End
API (DUT)
Application Application
6. Presentation 6. Presentation
Communications Communications
5. Session 5. Session
subsystem subsystem
Underlying Underlying
4. Transport 4. Transport
3. Network 3. Network
communications communications
2. Data Link 2. Data Link
technology technology
1. Physical 1. Physical
Figure A.1 — Handling of ADUs applicable for particular TP
A.2 Instance Handling
These Test Purposes apply to instance handling as claimed in ISO/TS 17575-2 clause 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.2.1 BV test purposes (Valid Behaviour tests)
Test subgroup objective:
⎯ to test DUT behaviour with respect to instance initialization including multiple instance handling in parallel;
⎯ to test DUT behaviour with respect to parameter setting and updating;
⎯ to test DUT behaviour with respect to parameter getting;
⎯ to test DUT behaviour with respect to parameter deleting;
⎯ to test DUT behaviour with respect to availability of communications stack;
© ISO 2012 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/TS 16401-1:2012(E)
⎯ to test DUT behaviour with respect to dropping the session with following severities:
⎯ SENormal;
⎯ SEUrgent;
⎯ SEUnconditional.
TP/IH/API/BV/01 Verify the communications interface initialization
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition Front End Communications API must handle at least one underlying
communications stack which StackID equals to stack1.
Set of Callback instances is instantiated.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 InitialiseInstance (StackID = stack1, AppEm
Callbacks = cb1)
2 AppEm R: Instace
3 Verify whether Instance is valid
4 IF verify OK THEN TP passed
ELSE TP failed
ENDI
8 © ISO 2012 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/02 Verify the multiple instance communications interface initialization
based on the same communications stack
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition Front End Communications API must handle at least one underlying
communications stack which StackID equals to stack1.
Sets of Callback instances are instantiated.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 InitialiseInstance (StackID = stack1, AppEm
Callbacks = cb1)
2
AppEm R: Instance
3
Verify whether Instance is valid
4
IF verify OK
THEN GOTO step5
ELSE TP failed
ENDIF
5 InitialiseInstance (StackID = stack1, AppEm
Callbacks = cb2)
6 AppEm R: Instance
7 Verify whether Instance is vali
8 IF verify OK
THEN GOTO step 9
ELSE TP failed
ENDIF
9 InitialiseInstance (StackID = stack1, AppEm
Callbacks = cb3)
10 AppEm Instance
11 Verify whether Instance s valid
12 IF verify OK
THEN TP passed ELSE TP failed
ENDIF
© ISO 2012 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/03 Verify the multiple instance communications interface initialization
based on different communications stack
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition Front End Communications API must handle at least 2 underlying
communications stacks which StackID equals to stack1 and stack2.
Sets of Callback instances are instantiated.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 InitialiseInstance (StackID = stack1, AppEm
Callbacks = cb1)
2
AppEm R: Instance
3
Verify whether Instance is valid
4
IF verify OK
THEN GOTO step5
ELSE TP failed
ENDIF
5 InitialiseInstance (StackID = stack2, AppEm
Callbacks = cb2)
6 AppEm R: Instance
7 Verify whether Instance is vali
8 IF verify OK
THEN TP passed
ELSE TP failed
ENDIF
10 © ISO 2012 – All rights reserved
---------------------- Page: 15 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/04 Verify that parameter is set by Front End Application (single
parameter)
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1 is created.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 SetParameter (Instance = instance1, AppEm
Parameter = "Parameter1",
Value = "Value1")
2 AppEm R:CEN175 52Error
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 Valu1)
THEN T passed
ELSE TP failed
ENDIF
© ISO 2012 – All rights reserved 11
---------------------- Page: 16 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/05 Verify that parameter is set by Front End Application for multiple
instances (different parameter names)
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1 and instance2 are created.
Stimulus and Expected Behaviour
Tester Test DUT
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 step8
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 K
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
12 © ISO 2012 – All rights reserved
---------------------- Page: 17 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/06 Verify that parameter is set by Front End Application for multiple
instances (the same parameter names)
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1 and instance2 are created.
Stimulus and Expected Behaviour
Tester Test DUT
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 step8
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 O
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 2012 – All rights reserved 13
---------------------- Page: 18 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/07 Verify that parameter is updated by Front End Application
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1 is created.
Stimulus and Expected Behaviour
Tester Test DUT
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 step8
ELSE TP failed
ENDIF
8 SetParameter (Instance = instance1, 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 = instance1, AppEm
Parameter = "Parameter1")
13
AppEm R: String
14
IF (String equals to Value2)
THEN GOTO step8
ELSE TP failed
ENDIF
14 © ISO 2012 – All rights reserved
---------------------- Page: 19 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/08 Verify that parameter's value is fetched by the Front End
Application
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1 is created.
Parameter1 has already been set with value1.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 GetParameter (Instance = instance1, AppEm
Parameter = "Parameter1")
2 AppEm R: String
3 IF (String equals to Value1)
THEN TP passed
ELSE TP failed
ENDIF
© ISO 2012 – All rights reserved 15
---------------------- Page: 20 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/09 Verify that parameter's value is fetched by the Front End
Application (multiple instances)
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1, instance2 and instance3 are created.
Parameter1 in instance1 has already been set with value1.
Parameter2 in instance1 has already been set with value2.
Parameter1 in instance3 has already been set with value3.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 GetParameter (Instance = instance1, AppEm
Parameter = "Parameter1")
2
AppEm R: String
3
IF (String equals to Value1)
THEN GOTO step4
ELSE TP failed
ENDIF
4 GetParameter (Instance = instance2, AppEm
Parameter = "Parameter2")
5 AppEm R: String
6 IF (String equals to Value2)
THEN GOTO step7
ELSE P failed
ENDIF
7 GetParameter (Instance = instance3, AppEm
Parameter = "Parameter1")
8 AppEm R: String
9 IF (String equals to Value3)
THEN TP passed
ELSE TP failed
ENDIF
16 © ISO 2012 – All rights reserved
---------------------- Page: 21 ----------------------
ISO/TS 16401-1:2012(E)
TP/IH/API/BV/10 Verify that parameter is deleted by Front End Application (single
parameter)
TP Origin Specific
Reference ISO/TS 17575-2, Clause 7.2.1
Initial Condition A valid Instance instance1 is created.
Parameter1 has already been set by Front End application.
Stimulus and Expected Behaviour
Tester Test DUT
Point
1 DeleteParameter (Instance = instance1, AppEm
Parameter = "Parameter1")
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 has invalid value)
THEN TP passed
ELSE TP f
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.