BA RTLS-Integrationsassistent-V2.13.0.0 76

RTLS DeviceAssistant
Preface
Security recommendations 1
2
SIMATIC RTLS Introduction
Configuration 3
Localization systems
RTLS DeviceAssistant 4
Code examples
Error messages 5
Operating Instructions
01/2022
C7900-G8976-C564-03
Legal information
Warning notice system
This manual contains notices you have to observe in order to ensure your personal safety, as well as to prevent
damage to property. The notices referring to your personal safety are highlighted in the manual by a safety alert
symbol, notices referring only to property damage have no safety alert symbol. These notices shown below are
graded according to the degree of danger.
DANGER
indicates that death or severe personal injury will result if proper precautions are not taken.
WARNING
indicates that death or severe personal injury may result if proper precautions are not taken.
CAUTION
indicates that minor personal injury can result if proper precautions are not taken.
NOTICE
indicates that property damage can result if proper precautions are not taken.
If more than one degree of danger is present, the warning notice representing the highest degree of danger will
be used. A notice warning of injury to persons with a safety alert symbol may also include a warning relating to
property damage.
Qualified Personnel
The product/system described in this documentation may be operated only by personnel qualified for the specific
task in accordance with the relevant documentation, in particular its warning notices and safety instructions.
Qualified personnel are those who, based on their training and experience, are capable of identifying risks and
avoiding potential hazards when working with these products/systems.
Proper use of Siemens products
Note the following:
WARNING
Siemens products may only be used for the applications described in the catalog and in the relevant technical
documentation. If products and components from other manufacturers are used, these must be recommended
or approved by Siemens. Proper transport, storage, installation, assembly, commissioning, operation and
maintenance are required to ensure that the products operate safely and without any problems. The permissible
ambient conditions must be complied with. The information in the relevant documentation must be observed.
Trademarks
All names identified by ® are registered trademarks of Siemens AG. The remaining trademarks in this publication
may be trademarks whose use by third parties for their own purposes could violate the rights of the owner.
Disclaimer of Liability
We have reviewed the contents of this publication to ensure consistency with the hardware and software
described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the
information in this publication is reviewed regularly and any necessary corrections are included in subsequent
editions.
Siemens AG C7900-G8976-C564-03 Copyright © Siemens AG 2022.

Digital Industries Ⓟ 01/2022 Subject to change All rights reserved
Postfach 48 48
90026 NÜRNBERG
GERMANY
Preface
Purpose of this documentation

These operating instructions support you during installation and configuration of the RTLS
DeviceAssistant.
The installation and connection of SIMATIC RTLS infrastructure devices and transponders in
an RTLS localization network are not covered by these operating instructions.
Validity of this documentation

This documentation is valid for version 2.13.0.0 of the "SIMATIC RTLS Locating Manager".
Additional information
You can find more information on SIMATIC RTLS anchors, gateways and transponders listed in
this documentation in the corresponding manuals.
Link: (https://support.industry.siemens.com/cs/us/en/ps/25277)
Trademarks
SIMATIC RTLS ® is a registered trademark of the Siemens AG.
Industry Online Support

In addition to the product documentation, the comprehensive online information platform of
Siemens Industry Online Support offers support at the following Internet address:
(https://support.industry.siemens.com/cs/us/en/)
Apart from news, there you will also find:
• Project information: Manuals, FAQs, downloads, application examples etc.
• Contacts, Technical Forum
• The option submitting a support query: (https://support.industry.siemens.com/My/us/en/)
• Our service offer:
Right across our products and systems, we provide numerous services that support you in
every phase of the life of your machine or system - from planning and implementation to
commissioning, through to maintenance and modernization.
You will find contact information on the Internet at the following address:
(https://www.automation.siemens.com/aspa_app/?ci=yes&lang=en)
Operating Instructions, 01/2022, C7900-G8976-C564-03 3
Preface
SITRAIN - Training for Industry

The training offer includes more than 300 courses on basic topics, extended knowledge and
special knowledge as well as advanced training for individual sectors - available at more than
130 locations. Courses can also be organized individually and held locally at your location.
You will find detailed information on the training curriculum and how to contact our
customer consultants at the following Internet address:
(https://new.siemens.com/global/en/products/services/industry/sitrain/personal.html)
RTLS Technology and Practice (ID-RTLS-TP)

Training and certification
After completing the RTLS certification training, you will be able to plan and implement small
and medium-sized RTLS projects and provide efficient and multifaceted support in large
projects. Your RTLS basics will be strengthened and, building upon them, you will receive
new tools of the trade in order to offer customers the optimal solution for them. The
complete project sequence is taken as a reference and important steps, resources and work
results for each phase are presented. Comprehensive practical exercises in connection with
troubleshooting techniques and a great deal of input from industrial projects allow you to
internalize a confident approach to working with different types of localization projects. With
the training documents, you also receive extensive reference material for your daily work.
Link: (https://www.sitrain-learning.siemens.com/EN/en/rw35251/Industrielle-Identifikation-
RTLS-Technologie-und-Praxis)
Security information
Siemens provides products and solutions with industrial security functions that support the
secure operation of plants, systems, machines, and networks.
In order to protect plants, systems, machines and networks against cyber threats, it is
necessary to implement – and continuously maintain – a holistic, state-of-the-art industrial
security concept. Siemens’ products and solutions form one element of such a concept.
Customers are responsible for preventing unauthorized access to their plants, systems,
machines and networks. These systems, machines and components should only be
connected to the enterprise network or the Internet if and only to the extent necessary and
with appropriate security measures (firewalls and/or network segmentation) in place.
You can find more information on protective measures in the area of industrial security by
visiting: (http://www.siemens.com/industrialsecurity).
Siemens’ products and solutions undergo continuous development to make them more
secure. Siemens strongly recommends performing product updates as soon as they are
available and using only the latest product versions. Use of product versions that are no
longer supported, and failure to apply latest updates may increase customer’s exposure to
cyber threats.
To stay informed about product updates, subscribe to the Siemens Industrial Security RSS
Feed under (http://www.siemens.com/industrialsecurity).
4 Operating Instructions, 01/2022, C7900-G8976-C564-03
Preface
Note on firmware/software support

Siemens only provides bug and security fixes for the last released firmware/software version.
This means that Siemens only monitors the current firmware/software version for security
vulnerabilities.
Recycling and disposal

The products are low in harmful substances, can be recycled and meet the requirements of
the Directive 2012/19/EU for disposal of waste electrical and electronic equipment (WEEE).
Do not dispose of the products at public disposal sites.
For environmentally compliant recycling and disposal of your electronic waste, please contact
a company certified for the disposal of electronic waste or your Siemens representative.
Note the different national regulations.
Preface
Table of contents
Preface ................................................................................................................................................... 3
1 Security recommendations .................................................................................................................... 9
2 Introduction ......................................................................................................................................... 13
2.1 Note on the term "Anchor" ................................................................................................. 13
2.2 Overview ........................................................................................................................... 13
2.3 Functions in the menu bar of the client .............................................................................. 14
2.3.1 Connecting and disconnecting ........................................................................................... 14
2.3.2 Connection configuration .................................................................................................. 14
2.3.3 Changing the password / language..................................................................................... 15
2.3.4 Search ............................................................................................................................... 15
2.3.5 Search options ................................................................................................................... 15
2.3.6 Check for update ............................................................................................................... 15
2.3.7 Clear log ............................................................................................................................ 15
3 Configuration....................................................................................................................................... 17
3.1 How it works ..................................................................................................................... 17
3.2 Required configurations before first program start.............................................................. 18
3.3 Configuration file ............................................................................................................... 19
3.3.1 Parameter [misc] ............................................................................................................... 20
3.3.2 Parameter [server] ............................................................................................................. 20
3.3.3 Parameter [position] .......................................................................................................... 20
3.3.4 Parameter [CentralConfiguration] ...................................................................................... 21
3.3.5 Parameter [Integration] ..................................................................................................... 22
3.3.6 Parameter [IntegPictures] .................................................................................................. 24
3.3.7 Parameter [IntegAutoSetting] ............................................................................................ 25
3.3.8 Parameter [GroupConfigVehiclesWorking] .......................................................................... 25
3.3.9 Parameter [AntennaPosition] ............................................................................................. 26
3.3.10 Parameter [CableLength] ................................................................................................... 26
3.3.11 [CableFactor] parameter .................................................................................................... 26
3.3.12 [CableAntennaOffset] parameter ....................................................................................... 26
3.3.13 Parameter [Retrofit] ........................................................................................................... 27
3.4 Script files.......................................................................................................................... 28
3.4.1 Structure of the test scripts ................................................................................................ 28
3.4.2 Basic structure ................................................................................................................... 29
3.4.3 Test scripts of XML files ...................................................................................................... 30
3.4.4 Test scripts of XML files - conditions ................................................................................... 32
3.4.5 Test scripts of XML files - responses .................................................................................... 36
3.4.6 Test step types ................................................................................................................... 41
3.4.7 Possible test steps .............................................................................................................. 46
3.5 Selection of the action to be performed ............................................................................. 47
3.5.1 Selection of the action to be performed ............................................................................. 47
3.5.2 Installation and removal of vehicle tags .............................................................................. 47
Table of contents
3.5.3 Infrastructure exchange ..................................................................................................... 48

3.5.4 Retrofit .............................................................................................................................. 49
4 Code examples .................................................................................................................................... 51
4.1 General application examples ............................................................................................ 51
4.1.1 Basic framework and parameter test .................................................................................. 51
4.1.2 Restriction to transponders with certain system software ................................................... 52
4.1.3 Restriction to transponders with a certain software version ................................................ 52
4.1.4 Antenna connector test ..................................................................................................... 52
4.1.5 LED check .......................................................................................................................... 53
4.1.6 Query the installation alignment via inertial sensors ........................................................... 53
4.1.7 CableLength ...................................................................................................................... 53
4.1.8 Vehicle alignment .............................................................................................................. 54
4.1.9 Fixation of transponders .................................................................................................... 54
4.1.10 Test of the acceleration sensor ........................................................................................... 55
4.1.11 Installation alignment of the transponder........................................................................... 55
4.1.12 AntennaPosition ................................................................................................................ 56
4.1.13 Antenna position editable .................................................................................................. 56
4.1.14 Antenna position specified ................................................................................................. 56
4.1.15 Antenna configuration ....................................................................................................... 57
4.1.16 Antenna configuration with preset cable length ................................................................. 57
4.1.17 Write temporary parameters .............................................................................................. 58
4.1.18 Distance measurement ...................................................................................................... 58
4.1.19 Test V signal ...................................................................................................................... 58
4.1.20 Set parameters .................................................................................................................. 59
4.1.21 Ready for run test .............................................................................................................. 59
4.1.22 Run test ............................................................................................................................. 59
4.2 Special application examples.............................................................................................. 60
4.2.1 Road vehicles..................................................................................................................... 60
4.2.2 Rail vehicle ........................................................................................................................ 61
5 Error messages .................................................................................................................................... 67
Security recommendations 1
General
Note the following security recommendations to prevent unauthorized access:
• You should make regular checks to ensure that the devices meet these recommendations
and/or other security guidelines.
• Evaluate your plant as a whole in terms of security. Use a cell protection concept with
suitable products (https://new.siemens.com/global/en/company/topic-areas/future-of-
manufacturing/industrial-security.html).
• Keep the software up to date. Check regularly for security updates for the device. You can
find information on this at the Industrial Security
(https://new.siemens.com/global/en/company/topic-areas/future-of-
manufacturing/industrial-security.html) website.
• Only activate protocols that you require to operate your system.
• Whenever possible, always use the variants of protocols that provide enhanced security
(e.g. SNMPv3).
• Connections over unsecured network areas must be secured by security mechanisms such
as SSL VPN.
• Always click on the "Disconnect" button when you have finished working with the clients.
Especially when you work remotely on the host on which the clients are located.
• Restrict access to the software and its add-on programs (e.g. database) to qualified
personnel.
• Use the user and role administration to configure the rights of the users according to their
authorizations.
Users, roles and passwords

• Define rules for the use of the software and assignment of passwords. Configure these
roles using UMC and Active Directory.
• Regularly update the passwords to increase security.
• Change user names and default passwords of the databases before you use the software.
For the SIMATIC RTLS Locating Manager, a changeable user and an editable password is
used for each installation. You can change the password via the respective DBMS version.
• Create users and roles that are tailored to the scope of authorization required by each
user. Do not exclusively use the "System administrator" role that is present by default, and
disable the "System administrator" user that is present by default after new users with
corresponding rights have been created. You disable the "System Administrator" rights for
the UMC administrator by assigning this role to a specific user or a user group.
• Only use passwords with a high password strength. Avoid weak passwords, for example
password1, 123456789, abcdefgh.
Security recommendations
• Make sure that all passwords are protected and inaccessible to unauthorized personnel.
• Do not use the same password for different users and systems or after it has expired.
Physical access
Restrict physical access to the device to qualified personnel.
Automation License Manager

If you do not require the network functions of the Automation License Manager, deny access
to its functions in your firewall.
Software (security functions)

• Keep the software up to date. Check regularly for security updates for the product. You
can find information on this at the website
(https://new.siemens.com/global/en/company/topic-areas/future-of-
manufacturing/industrial-security.html).
• Only activate the protocols, functions and interfaces that you require to operate your
system.
• Restrict access to the device with a firewall or rules in an access control list (ACL - Access
Control List).
• The option of VLAN structuring provides good protection against DoS attacks and
unauthorized access. Check whether this is practical or useful in your environment.
• Enable the logging functions to record changes and access attempts. Check the logging
information regularly.
Secure and non-secure protocols

• Check whether the use of SNMPv2c is necessary. SNMPv2c is classified as non-secure. The
product provides you with suitable setting options.
• When SNMP is enabled, change the community names. When no unrestricted access is
necessary, restrict access with SNMP.
• Use secure protocols when access to the device is not secured by physical protection
measures. The following protocols provide a secure alternative:
– SNMPv2c → SNMPv3
– SMTP (simple) → SMTP via SSL
– NTLM → Kerberos (UMC connection to Active Directory)
• Avoid or disable non-secure protocols. For historical reasons, these protocols are available,
however not intended for secure applications. Use non-secure protocols on the device
with caution.
• To prevent unauthorized access to the device or network, take appropriate protective
measures against non-secure protocols.
List of available protocols (local access via a local network)

The following is a list of all available protocols and their ports through which the RTLS
devices/products can be accessed. Note the list when you configure a firewall.
Explanation for table:
• Services/protocols
Services or protocols that support the RTLS devices/products.
• Port number
Port number assigned to the protocol/service.
• Default port status
– Open
The port is open by default.
– Closed
As default the port is closed.
• Authentication
Specifies whether the communication partner is authenticated.
• Loopback only
Specifies whether the protocol only needs local connections.
– Yes: No port must be open within the firewall. Access restrictions are recommended.
– No: The functionality requires this port to be accessed. Restrict access to necessary
hosts.
– Optional: The functionality depends on your system. Restrict access to necessary hosts
if your system requires remote access.
Service/Protocol Port number Default port status Authentication Loopback only

Data export modules TCP/variable Closed No Optional
Internal server TCP/8001 Closed No Yes
communication
Client connection TCP/9500 Open Yes Optional
Client connection TCP/9501 Open No Optional
E-mail TCP/variable Closed Optional No
Wireless network TCP/8000 Open No No
WAMP router TCP/12344 Closed Yes Optional
Microsoft SQL Server TCP/1433 Open Yes Optional
Microsoft SQL Server UDP/1434 Open No Optional
Introduction 2
2.1 Note on the term "Anchor"
Note
The term "Anchor" is still used in the user interface of the Locating Manager and in this
manual. However, this product is being phased out and can no longer be ordered. To replace
the hardware, use a gateway that can be operated without an Ethernet connection; it offers
the same functionality.
2.2 Overview
General
This section describes the operation of the "DeviceAssistant" client of the Locating Manager.
Note
The client may only be used by experienced and trained users.
Application
You can manage transponders with the "DeviceAssistant" client. It makes it possible to
integrate transponders into an existing RTLS localization system, retrofit them and replace
infrastructure devices.
Integration means that transponders newly installed in vehicles are added to the
Locating Manager, configured and checked for functionality according to a defined test
protocol. Existing transponders can also be removed.
When infrastructure devices are replaced, existing anchors and gateways are replaced by
newly attached infrastructure devices in the RTLS localization system. The parameters of the
old node are written directly to the new node.
The purpose of retrofitting is to make certain changes to transponders that are already
integrated. This could be, for example, later entry of an initial mileage configuration of a
vehicle or the calibration of the wheel circumference.
Start client
You start the "DeviceAssistant" client with the "DeviceAssistant.exe" file. By default, the file is
located under "C:\Program Files (x86)\SIMATIC_RTLS_LM\Clients\DeviceAssistant.exe".
Introduction
2.3 Functions in the menu bar of the client
2.3.1 Connecting and disconnecting

After the client starts, click the "Connect" button to connect to the Locating Manager and log
in. As an alternative, you can make a connection using the menu "File > Connect".
You can use the "User Configuration" client to assign roles to additional users. Fill in the
"Domain" input box when the user is an Active Directory user. If the user is not an Active
Directory user, this input box must remain empty.
The status of the connection is displayed on the left in the status bar.
When a connection has been established, the connection symbol changes to "Disconnect",
indicating an existing connection. The red connection symbol "Connect" indicates that there
is no connection.
If a connection to the RTLS localization system could not be established, an error message is
issued after about 20 seconds. The connection symbol changes to "Connect" and
"Disconnected" appears in the status bar.
2.3.2 Connection configuration

Proceed as follows to configure the connections:
1. Adapt the server name and port accordingly if a valid connection to the Locating Manager
has not yet been established. The default port is 9500. The server name is the name of the
server in the RTLS localization network on which the Locating Manager server was installed.
By default, "localhost" is set. You can change these configurations at any time in the menu
"Options > Connections".
2. Enter "localhost" in the "Host name or IP" input box if the Locating Manager server is on the
same PC as the current client. This is the default setting.
3. Otherwise, enter the appropriate name or the IP address of the Locating Manager server in
the RTLS localization network.
Note
Ensure that communication between the Locating Manager server, the infrastructure and the
current client is not blocked by a firewall or incorrect configuration on the local network.
Introduction
2.3.3 Changing the password / language
Change password
You can change the password of the current user under "Options > Change password...".
Note
The password is valid for access of this user to all clients within the Locating Manager.
Changing the language

You can switch between "German" and "English" under "Options > Language" .
2.3.4 Search
Under "Options > Search", you can search for any terms, descriptions or even addresses. Any
hits found are displayed in the user interface. If there are several search results, the main
window switches to the selected hit.
2.3.5 Search options

Under "Options > Search options", you can restrict the search range to specific node types,
transponders, transponder names, antenna positions or types, or specific text boxes. The text
boxes for selection for the transponders can be individually assigned. You can also open the
"Search options" dialog by clicking on the "Options" button in the search window.
2.3.6 Check for update

If the "Check for update" option is selected, the system checks to see if a more recent version
of the client is available on the server.
2.3.7 Clear log

Under "Options > Clear log", you can delete the messages displayed in the output window for
logging data. Newly added messages are displayed again.
Introduction
Configuration 3
3.1 How it works
The following diagram shows how the "DeviceAssistant" client works in principle.
Configuration
3.2 Required configurations before first program start
3.2 Required configurations before first program start

The transponders processed with the "DeviceAssistant" client are assigned to four different
transponder groups. These groups must be created with the "Network Configuration" client.
Create transponder group

Open the "Network Configuration" client under "Start > Programs > SIMATIC RTLS Locating
Manager > Network Configuration". You need four transponder groups for the assignment of
transponders with the following states. You can freely select the name of the transponder
group.
Transponder groups Description

NewTransponder All devices that have not yet been integrated, but have been localized by
the Locating Manager.
WorkingTransponder Transponders that are currently working in the integration process, i.e.
active.
ProblemTransponder Transponders whose integration caused errors and which therefore could
not be integrated.
ActiveTransponder Transponders that have been fully integrated without error.
For new transponders, select the configured default group "DEFAULT". If there are multiple
transponder groups, navigate the mouse over the group in the tree topology of the "Network
Configuration" client. You can recognize the group by the fact that "Transponder Group [1]" is
specified in the tooltip that appears.
Select "Transponder" in the tree topology if you want to create additional transponder
groups. Select "New transponder group..." to create a new transponder group. Alternatively,
it is possible to link the transponder groups with the various transponder states at the
program start of the "DeviceAssistant" client and via the name of the group there.
Assignment of transponder groups via configuration file

You can assign the created transponder groups to the respective transponder states by
starting the "DeviceAssistant" client program or via corresponding entries in the
"DeviceAssistant.ini" configuration file (located by default under
"%USERPROFILE%\AppData\Roaming\SIMATIC_RTLS_LM"). If you make an assignment via the
program start, you make the corresponding configuration entry automatically.
It is recommended to open the "DeviceAssistant.ini" configuration file with an editing
program, such as "Notepad++", to provide clear views.
Enter the transponder group number to the right of the corresponding entry in the
"[GroupConfig]" sub-item of the "DeviceAssistant.ini" configuration file to assign the
transponder groups created to the respective states.
Example:
[GroupConfig]
NewTags=1
WorkingTags=2
ActiveTags=4
ProblemTags=3
Configuration
3.3 Configuration file
After completing the group assignment, the service writes a corresponding entry to the
"DeviceAssistant.ini" configuration file. If you want to make changes to these groups, you
must create other groups and delete the numerical assignment in the "DeviceAssistant.ini"
configuration file or change it directly to meet your needs.
Example:
[GroupConfig]
NewTags=1
WorkingTags=2
ActiveTags=4
ProblemTags=3
Assignment of transponder groups at the start of the service

After starting the "DeviceAssistant" client and the user login, a dialog box appears in which
you can automatically assign the created transponder groups and the possible transponder
states one after the other.
The "New transponders" transponder group is automatically proposed as the group for the
new transponders. For all other transponder states, you can determine the corresponding
transponder group via the drop-down list. You should take care when making the selection in
order to avoid confusion in the use of the service later.

You can make the following configurations in the "DeviceAssistant.ini" configuration file (by
default under "%USERPROFILE%\AppData\Roaming\SIMATIC_RTLS_LM"):
• Simplify the use of the client in general
• Determine which integration processes can be performed
• Determining how the integration process works
• Determine the conditions under which an integration process is aborted.
It is recommended to edit the "DeviceAssistant.ini" configuration file with an advanced text
editor program such as "Notepad++", as this allows for clearer views. The order of these
parameters is not relevant for the functionality of the client.
Note
When you edit them, note that they are case-sensitive.
Configuration
3.3.1 Parameter [misc]

You can use the "[misc]" parameter to specify whether a help document is to be connected to
the client. If a document is specified under "HelpDocument", you can open this via the menu
under "About > Help..." or by clicking the "F1" key when the client is started. Enter either the
full path to the help document or the relative path:
[misc]
;Complete path:
HelpDocument=C:\Program
Files (x86)\SIMATIC_RTLS_LM\Documents\Manuals\English\Manual
DeviceAssistant.pdf
;or path relative to the installation folder of the client:
HelpDocument=..\Doc\Manual DeviceAssistant.pdf
lang=de
The ""lang"" item can be used to display the last language selected in the client.
3.3.2 Parameter [server]

You can use the "[server]" parameter to specify the valid connection of the client to the
Locating Manager Server. This information is required for the operation of the client. They are
adopted automatically by the Locating Manager configurations or adapted via the options in
the drop-down list (section "AUTOHOTSPOT").
[server]
host=localhost
port=9500
3.3.3 Parameter [position]

You can use the "[position]" parameter to configure the window size and position of the user
interface. If you change the Client window directly, the corresponding parameters in the
"DeviceAssistant.ini" configuration file are adapted.
[position]
Maximized=0
Width=534
Height=387
Top=267
Left=2317
TreeWidth=64
LoggingHeight=30
Configuration
3.3.4 Parameter [CentralConfiguration]

You can use the "[CentralConfiguration]" parameter to ensure that certain configurations are
always used during integration. It does not matter of whether you are integrating the
Locating Manager server or another device (e.g. notebook).
You store configurations to be used permanently in the "IntegConfig.ini" file. This file must be
located in the installation directory of the Locating Manager (by default under
C:\Program Files (x86)\SIMATIC_RTLS_LM\Server\files\program).
Apply the parameters "[misc]", "[server]" and "[position]" from the "DeviceAssistant.ini"
configuration file which is located in the installation directory of the "DeviceAssistant" client.
[CentralConfiguration]
DontOverwriteValuesFromCentralFile=1
DownloadIni=0
DownloadTemplates=2
When the program starts, the "DeviceAssistant" client always first reads out the local
"DeviceAssistant.ini" configuration file and behaves according to the configuration defined
there.
Element Description
DontOverwriteValuesFromCentralFile You use this item to specify which configuration value is used if it is present in
both files.
The following values are possible:
0 (Default value) Value from the local "DeviceAssistant.ini" is used
1 Value from the central "IntegConfig.ini" is used
DownloadIni You use this item to control the behavior of the client in relation to the central
"IntegConfig.ini" configuration file.
0 The configuration file "IntegConfig.ini" is not read.
1 The client tries to read the "IntegConfig.ini" configuration file
and stops its service if it cannot be read (e.g. because it does
not exist or no server connection can be established).
2 (default value) The client attempts to read the configuration file
"IntegConfig.ini". The client continues to be executed when
reading is not successful. Provided that the configurations in
the "DeviceAssistant.ini" configuration file are
comprehensive enough.
DownloadTemplates You use this item to specify whether templates and test scripts ("*.awt" and
"*.ats" files) are loaded from the central server or whether the locally stored
data is used.
0 Automatic download from the server is prevented
1 Client attempts to download files from server and stops
operation if server fails
2 (default value) Client attempts to download files from server and continues
to be executed even if the download fails. Provided that
there are no local templates.
Configuration
3.3.5 Parameter [Integration]

With the "[Integration]" parameter, all basic configurations for integration of the
transponders are made via the "DeviceAssistant" client.
[Integration]
;Printer settings:
PrinterName=FreePDF - Siemens
PrintStepNums=1
PrimarySignature=1
;Client representation:
DispPreset=1;2;3
MainBtnCaption=Installing and\nremoving\nvehicle TAGs
SelListCaption=Integratable TAGs
Naming convention for transponder:
NameNumChar=0
NameLeadingZeros=0
ForbiddenNames=TAG x;TAG y;TAG z
;Transponder activation:
LocActive=1
;Integration process options:
PreParamSetName=Pre_Parameter_set_000000000
EnableTagDeletition=1
;Integration information according to vehicle model and type:
DeviceGroups=Bus;Tatra;Vario
VehiclesBus=Citaro:Urbino:Lion's City:Ikarus 415

ParamsBus=Integration_Parameter_Bus_000000000
IntegTestBus=Test_Step_Bus
SecondSignerBus=Mr. Müller
VehiclesTatra=KT8D5
ParamsTatra=Integration_Parameter_KT8D5_000000000
IntegTestTatra=Test_Step_KT8D5
SecondSignerTatra=Ms. Schmidt
VehiclesVario=Variobahn
ParamsVario=Integration_Parameter_Variobahn_000000000
IntegTestVario=Test_Step_Variobahn
SecondSignerVario=Müller and Schmidt
Element Description
PrinterName You use this item to specify the name of the printer to be used for printing the integration log.
When the client finds the specified printer after completing the integration process, it selects it
automatically. If the printer is not found or the line in the "DeviceAssistant.ini" configuration file
is missing, the operating system print dialog appears.
PrintStepNums You use this item to specify whether the test step numbers of the integration are to be
transferred to the log.
Configuration
Element Description
0 No
1 (default value) Yes
PrimarySignature You use this item to specify whether a primary signature field is to be inserted at the end of the
integration log. The name of the user logged in to the "DeviceAssistant" client is automatically
used as the name below the signature field.
0 No
DispPreset You use this item to specify the functions the user can perform. If only one function is selected,
it is executed immediately.
1 Transponder (activates the "Mobile integration" button)
2 Infrastructure (activates the "Infrastructure exchange" button)
3 Retrofit (enables the "Retrofit" button)
MainBtnCaption You use this item to replace the default text on the "Mobile integration" button with a
customized text. You can make a line break by inserting "\n". The change is only displayed if you
make several entries in the "DispPreset" element.
SelListCaption You use this item to create labels for the selection list in the transponder integration area. By
default, these are overwritten with "Transponder for integration".
NameNumChar You can use this item to can define the maximum character length the transponder names must
have.
If a value greater than 0 is set, only numbers are allowed as names. Alternatively, deleting the
"NameNumChar" element enables the assignment of any text of your choice as the transponder
name. If an invalid vehicle number is specified in the client, an error message appears next to
the text box (in the example: NameNumChar=4).
0 No restrictions to name length and character selection
2 ... 5 The name must be at least 2 characters long, but no more than 5 characters
long.
NameLeadingZeroes You use this item to specify whether leading zeros are permitted for the name assignment of
the transponders, provided the name length "NameNumChar" is observed.
Invalid entries trigger a corresponding message.
0 Off: No leading zeros may be assigned.
1 (default value) Leading zeros may be in a transponder name
ForbiddenNames You can use this item to create a list of names that may not be used as transponder names
during integration. The prohibited names must be separated by semicolons and without spaces.
If the entries later contradict the specifications made with this item during operation, a
corresponding message is output.
LocActive You use this item to define whether a fully integrated transponder is to be automatically
activated for localization.
0 Transponder is not automatically enabled for localization after successful
integration
1 (default value) Transponder is automatically enabled for localization after successful
integration
PreParamSetName You use this item to use an optional encrypted parameter file. The included parameters ensure
that the transponder is and remains accessible during the integration process.
Do not change the default element; otherwise, a successful integration of a transponder is not
guaranteed.
Configuration
Element Description
EnableTagDeletition You use this item to define whether a transponder is to be deleted from the RTLS localization
system.
0 No
DeviceGroups You can use this item to specify vehicle groups for which separate test scripts and/or parameter
files are used. A vehicle group can contain several vehicle types (see the example of the "Bus"
vehicle group). Separate the different groups with semicolons and do not use the same name
twice.
VehicleBus You can use this item to specify vehicle types for the respective vehicle group that were
previously defined in the "DeviceGroups" item. These must be separated from each other by a
colon.
Input format: VehicleGroupName=Vehicle type:Vehicle type:Vehicle type
ParamsBus You can use this item to refer to the parameter file (without file extension) from which the
values are written to the transponder. If no special integration parameters are to be set on the
transponder, you can remove this item from the "DeviceAssistant.ini" configuration file.
IntegTestBus The script file that defines the test steps for the integration is mandatory. The test step file is
specified without a file extension.
SecondSignerBus You can use this item to create a secondary signature field for the integration log for the
respective vehicle group. Remove this item from the "DeviceAssistant.ini" configuration file
when the second signature field is not needed.
3.3.6 Parameter [IntegPictures]

You can use the parameter "[IntegPictures]" to assign a picture to each vehicle type, which is
displayed in the client. The "*.bmp" file format is supported. The item must be specified as
follows:
"Vehicle type=path relative to DeviceAssistant.exe\Picturename.bmp"
[IntegPictures]
Fahrzeugtyp1=Pictures\fahrzeugtyp1.bmp
Fahrzeugtyp2=Pictures\fahrzeugtyp2.bmp
Configuration
3.3.7 Parameter [IntegAutoSetting]

You can use the "[IntegAutoSetting]" parameter to control the automatic firmware update.
[IntegAutoSetting]
FirmwareUpdate=1
UpdateOnlySelectedNode=1
FirmwareUpdateTagGroupFilter=1
Element Description
FirmwareUpdate With this item, you determine whether the firmware of the devices should be updated
automatically.
Alternatively, you can also update the firmware manually via the "Network
Configuration" client. In this case, it is not necessary to control the update via the
"DeviceAssistant.ini" configuration file.
0 Automatic update is not performed
1 Automatic update is performed
UpdateOnlySelectedNode You use this item to control for which devices the automatic update is performed, when
you have enabled the "FirmwareUpdate" item.
0 Firmware updates are performed on all transponders that are suitable for
integration and at the same time accessible via wireless technology.
1 (default Firmware update is performed exclusively on the transponder selected
value) for the integration in question
FirmwareUpdateTagGroupFilter You use this item to determine for which transponder group a firmware update is to be
performed. Specify the group number. Separate several group numbers with commas
and without spaces. If you do not specify anything else, all devices that are suitable for
integration and at the same time are accessible wirelessly are updated.
Delete the line if you do not want to restrict the automatic firmware update.
3.3.8 Parameter [GroupConfigVehiclesWorking]

You can use the "[GroupConfigVehiclesWorking]" parameter to allocate the integrated
transponders of certain vehicle types to different groups. Create the corresponding
transponder groups. The format of this item is "Vehicle type=Group number", e.g. "Ikarus
415=4" to move all fully integrated buses of type Ikarus 415 to group 4. If you do not make
any specific configurations, the "DeviceAssistant" client uses the previously made
configurations and moves fully integrated transponders to the general "ActiveTags" folder.
[GroupConfigVehiclesWorking]
Ikarus 415=4
Configuration
3.3.9 Parameter [AntennaPosition]

You can use the "[AntennaPosition]" parameter to specify antenna positions for vehicle types.
These entries overwrite the default values of the "*.ats" template file. The format of the item
is "VehicleType.Position=value in cm" with the possible positions "Front", "Center" and
"Bottom". Use this parameter only if the test script includes an antenna position test step.
[AntennaPosition]
Ikarus 415.Front=70
Ikarus 415.Center=25
Ikarus 415.Bottom=45
3.3.10 Parameter [CableLength]

You can use the "[CableLength]" parameter to specify the cable length of the respective
vehicle types in centimeters. Use this parameter only if the test script includes a cable length
test step.
[CableLength]
Ikarus 415=78
Citaro=112
Urbino=45
3.3.11 [CableFactor] parameter

You can use the "[CableFactor]" parameter to specify the cable factors of the respective
vehicles. Use this parameter only if the test script includes a cable length test step. When the
value is not specified for a vehicle, a value of 1.4 is assumed.
[CableFactor]
Urbino=1.8
Ikarus 415=1.6
3.3.12 [CableAntennaOffset] parameter

You can use the "[CableAntennaOffset]" parameter to specify the antenna offsets for the
calibration values of the respective vehicles in centimeters. Use this parameter only if the test
script includes a cable length test step. When the value is not specified for a vehicle, a value
of 40 is assumed.
[CableAntennaOffset]
Citaro=40
Urbino=80
Configuration
3.3.13 Parameter [Retrofit]

The "[Retrofit]" parameter relates to retrofitting, that is, specific adaptation tests for
transponders already integrated, for example, the entry of the vehicle odometer reading or
the wheel size at a later time.
[Retrofit]
PrintProtocol=1
MainBtnCaption=Retrofit\nMileage configuration
SelListCaption=TAGs to retrofit
testnames=Mileage configuration;K factor
GroupFilter.Mileage configuration=4
RetrofitTest.Mileage configuration=Retrofit mileage configuration
GroupFilter.K factor=4
RetrofitTest.K factor=KFactorTest
Element Description
PrintProtocol You use this item to specify whether a test log is to be printed at the end of the adaptation
test. When enabled, the printer setting of the "[Integration]" parameter is used.
0 No
MainBtnCaption You use this item to set the label for the button for retrofitting. Insert a line break in the
caption text with "\n". If you do not make an entry, the button with the inscription "Retrofit"
appears.
SelListCaption You can use this item to specify a heading for the node selection menu in the retrofit
display. If you leave the entry in the "DeviceAssistant.ini" configuration file empty or delete
the entire line, the menu heading "Nodes for retrofit" appears.
testnames You can use this item to specify a series of retrofit tests that use the same parameter files
and test scripts. Separate the individual entries with semicolons. Duplicate names are not
permitted. If the corresponding test script is stored, you can select from the specified tests.
GroupFilter You can use this item to define the transponder group numbers for which the respective
test is to be performed. If the entry in the "DeviceAssistant.ini" configuration file remains
empty, it is applied to all transponders. The item "GroupFilter.Test name=Group number(s)"
is separated with commas.
RetrofitTest You use this item to refer to the template with the test steps to be performed. The format is
"RetrofitTest.Testname=Name of the template file without extension".
The templates must be stored in the "Templates" subfolder. This folder must be in the same
directory as the "DeviceAssistant.exe" installation file. If no file is specified, no upgrade can
be performed. Example scripts for retrofitting the mileage configuration and the K factor
can be found in the sections "Basic framework and parameter test (Page 51)" and
"Restriction to transponders with certain system software (Page 52)".
Configuration
3.4 Script files
3.4 Script files

The script files are files written in "*.xml" format for exchanging information between devices
and the Locating Manager. To use the "DeviceAssistant" client, it is necessary to use "*.xml"
files with the desired test steps for the integration, replacement or retrofitting of devices. The
"*.xml" files are encrypted before being included in the client and thus become "*.ats" files.
Note
Script files for the "DeviceAssistant" client may only be written by trained personnel!
Scripts and template files (encrypted parameter files) are stored locally in the installation
folder of the "DeviceAssistant" client and in the "templates" subfolder there. These files are to
be stored centrally on the Locating Manager server in the folder
"C:\Program Files (x86)\Siemens\Server\files\templates".
Possible integration steps are described below.
3.4.1 Structure of the test scripts

Test scripts consist of a description, a list of conditions, and a list of test steps. The general
structure of a test script is as follows:
<TestConfiguration revision="4">
<description>
<testname>Bus integration</testname>
<testrevision>5</testrevision>
</description>
<TestPrecondition ../>
<TestAdaptionList ../>
<StepList>
</TestConfiguration>
Element Description
<TestConfiguration This element is used to version the structure of the script file. The
revision="4"> current version is 4, for example. This number is selected by the
"DeviceAssistant" client and may not be changed.
<description> The test is described and versioned with this item. For example, it may
be available in different versions for installation in a bus. Do not
confuse this section with that of the tests.
<testname> The name is mandatory and is there for purposes
of logging.
<testrevision> This element is optional. If the entry exists, it
must have a value of "≥ 0". Impermissible values
are ignored without an error message and logged
during integration.
Configuration
3.4 Script files
Element Description
<TestPrecondition> You can use this optional item to define global preconditions that must
apply for the test to run. For more detailed information, refer to the
section "Test scripts of XML files - conditions (Page 32)".
<TestAdaptionList> You can use this optional item to make global adaptations to the test.
This section can be used to perform tests for specific devices only.
All adaptations are summarized under "<TestAdaption>". If the
condition applies, the reactions are executed. The condition is
evaluated at the start of the integration. Only use conditions with
values that are available at the time.
Do not use this condition list if reactions are to be executed
independently of preconditions.
3.4.2 Basic structure

Each individual test step required is listed in the test step list "<StepList>".
Each test step "<TestStep id="Number" type="Type designation">" must be provided with an
identification number and the desired type (section "Test scripts of XML files (Page 30)"). You
can freely assign the "<TestStep id="...">", each ID must be unique.
Within the test step, you need to specify the name "<name>" and a description
"<description>" of the step.
If the following test step is to be skipped if a test step was not affirmed, you must add the
"<skipnextstepifnotyes/>" command.
Example:
<StepList>
<TestStep id="1" type="question">
<name>Antenna connector</name>
<description>Is the antenna is permanently mounted on the
device?</description>
<buttonvisibility yes="true" no="true" skip="false"/>
<skipnextstepifnotyes/>
</TestStep>
<name>LED check</name>
<description>Do the POWER LEDs light up after switching on the
supply voltage?</description>
</TestStep>
</StepList>
You can also group the test steps in a list with the item "<StepGroup>". For example, you can
group all test steps or test groups related to the antenna according to device types.
Configuration
3.4 Script files
3.4.3 Test scripts of XML files
Buttons
You can customize the buttons that appear for all test steps:
Visibility
If you do not want all three response options to appear, you must insert a corresponding line
for button visibility. The desired buttons are set with the tags "true"; those that are not
required with "false".
<buttonvisibility yes="true" no="true" skip="false"/>
Alternatively, you can hide the unwanted buttons with the tag "false", which has the same
result:
<buttonvisibility skip="false"/>
Results
By default, if the integration process is considered successful you click the "Yes" button. If you
click the "Skip" button, the integration process with the default configurations generates an
error. You can assign certain tags to the buttons in relation to the overall result of the
integration.
The following tags are permitted:
Tag Description
TROk Response leads to the overall result "OK" (successful integration)
TRNo Response leads to the overall result "OK with restriction"
TRNoUnrestricted Response leads to the overall result "OK" (successful integration)
TRSkipped Response leads to the overall result "OK with restriction"
TRSkipUnrestricted Response leads to the overall result "OK" (successful integration)
TRFailed Response leads to failed integration
TRSkipFailed Response leads to failed integration
Each button that was defined as failed disables the "Save" button at the end of the integration
process, thus aborting the check.
Standard tags:
<buttonresults yes="TROk" no="TRFailed" skip="TRSkipFailed"/>
Modified tags (example):

<name>Attention check</name>
<description>Did the transponder catch fire?</description>
<buttonresults yes="TRFailed" no="TROk" skip="TRSkipFailed"/>
</TestStep>
Configuration
3.4 Script files
Labeling
By default, the buttons are labeled "Yes", "No" and "Skip". If you want to change the labels for
a test step, add the following line to the test step:
<buttoncaption yes="Your text" no="Your text" skip="Your text"/>
If you want to change only one or two buttons, you only have to specify them. The buttons
that are not specified remain filled with the default text:
<buttoncaption skip="Exclude"/>
Skip test step

If you want to skip a test step when the previous step was not answered with "Yes", insert this
line in the test step:
The test step that follows is displayed in the client, but is skipped automatically.
End test step automatically

You can end test steps automatically after a specified time in seconds. The test step is
considered to have failed:
<autotimeout duration_s="123"><message>Measurement
failed</message></autotimeout>
You can specify time periods from "1" to "7200" seconds (= two hours).
Restriction of user activity

You can restrict the actions that can be performed in the user interface using a maximum of
one of the following test scripts:
<useractions>SkipOnly</useractions>
<useractions>All</useractions>
<useractions>None</useractions>
Configuration
3.4 Script files
3.4.4 Test scripts of XML files - conditions

For some types of test steps, you can add conditions for passing a test step (section "Test step
types (Page 41)"). This is done with a list of conditions "<conditionlist>" integrated in the test
step. You can use the parameter "<conditionlist>" by itself or in combination with other
items.
The tags "and" (standard tag) and "or" are permitted for the "type" item. The item "negate"
("true" or "false" = standard tag) is an optional item with which you can invert the condition:
<conditionlist type="and" negate="false">
<conditionlist type="or" negate="true">
<conditionlist type="or">
Examples:
The tag "syssubsys" must either have the value "XONS_TAM1" or the tag "sys" must have the
value "MONS":
<conditionlist type="or" negate="false">

<condition type="syssubsys">
<value>XONS_TAM1</value>
</condition>
<condition type="sys">
<value>MONS</value>
</condition>
</conditionlist>
The tag "syssubsys" must not have the value "XONS_TAM1" nor must the tag "sys" have the
value "MONS":

</condition>
<value>MONS</value>
</condition>
</conditionlist>
The parameter "<condition>" can contain the items "relation" or "type":
<conditionlist>
<condition relation="match">
<value>1</value>
</condition>
</conditionlist>
Configuration
3.4 Script files
"relation" item
The condition is related to a pre-defined value "<value>". The relation of the present value
can be a "match", a minimum value of "min", a maximum value of "max" or a threshold value
of "above".
Examples:
The value must be "1":
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
This value must be at least "0":
<conditionlist>
<condition relation="min">
<value>0</value>
</condition>
</conditionlist>
The value must be in the value range from "0" to "5000000":
<conditionlist>
<condition relation="above">
<value>0</value>
</condition>
<condition relation="max">
<value>5000000</value>
</condition>
</conditionlist>
"type" item
Condition whether the write and read operations of the node parameters have been
completed:
<conditionlist>
<condition type="paramwritingdone"/>
</conditionlist>
Condition that a heartbeat has been sent after the reset following the configuration of the
device:
<conditionlist>
<condition type="lifesignafterreset"/>
</conditionlist>
Specific values must be defined for the "<type>" item. The default relation is "match".
Configuration
3.4 Script files
The following tags are permitted for the "<relation>" item:

• below
• max
• above
• min
• not
In the following example, therefore, the system must be "MONS", the subsystem "TA1" and
the system subsystem "CORFU_DRV1":
<condition type="sys"><value>MONS</value></condition>
<condition type="subsys"><value>TA1</value></condition>
<condition type="syssubsys"><value>CORFU DRV1</value></condition>
In the example of the type "softwareversion", this must correspond at least to version
"2.1.18". The value must be specified in the format "a.b.c.". The version numbers are padded
with zeros so that there are three characters per digit. For the version number in this
example, this would be "002001018".
<condition type="softwareversion" relation="min">

<value>2.1.18</value>
</condition>
Device parameters are compared with the tag "paramvalue". You need to specify the
parameter name for the tag "<paramname>" and the value for the parameter "<value>". Only
make comparisons for equality (the default configuration is relation="match"), because the
parameter values are interpreted as strings (text).
<condition type="paramvalue">
<paramname>APPL_DevType_001</paramname>
<value>APPL_eneDevType_Bus</value>
</condition>
If the only condition to be checked is whether or not a particular parameter exists, neither a
relation is queried nor is it checked whether the parameter has been read:
<condition type="hasparam">
<paramname>InitialMileage</paramname>
</condition>
In practical application, the unconditional presence of a parameter is required, e.g. for
mileage configuration retrofitting (section "Rail vehicle (Page 61)"). In the case of the
Property Value Key Values "pvkvalue", setpoints and actual values are compared. Enter the
key "<key>" and the value "<value>". You can also specify the relation and whether the value
should be converted to a number (isInt="true") . If the value to be queried is a string,
"isInt="true"" must not be set, by default, "isInt="false"" is specified in the code:
<condition type="pvkvalue" relation="min" isInt="true">

<key>ExternalVoltage</key>
<value>200</value>
</condition>
Configuration
3.4 Script files
Note
When comparing for equality of values "relation="match"", take the parameter value
interpretation as string (text).
Alternatively, you can compare property values only within test steps (TestStep), but not
within test adaptation lists (TestAdaptionList) or test step groups (StepGroup).
When querying for "float" decimal numbers, the relation type match is not advisable.
However, it is mandatory to specify a relation.
<condition type="float" relation="min">

<value>1.3</value>
</condition>
Condition lists can also be used recursively. A condition can also be a condition list.
In the example shown, the "syssubsys" of the transponder must accept "XONS_TAM1" or the
"sys" must accept "MONS". The "APPL_DevType_001" parameter must be set to
"APPL_eneDevType_Bus".
<conditionlist type="and">
<conditionlist type="or" negate="false">
</condition>
<value>MONS</value>
</condition>
</conditionlist>
</condition>
</conditionlist>
Message about fulfilled condition

You can use the following text line to display a message in the user interface to indicate if the
condition set has been fulfilled:
<conditionokmessage>Params writing done</conditionokmessage>
Configuration
3.4 Script files
3.4.5 Test scripts of XML files - responses

You can use reaction lists <reactionlist> to configure a number of automatically executable
reactions. These reactions include, for example:
• Setting parameters
• Restarting the device
• Cancel, skip, or add conditions
Some of the possible automatic reactions are possible in conjunction with certain other steps,
such as test adaptation <TestAdaption>. Basically, all reactions must be embedded in a
reaction list, which in turn is embedded in a test step, the test adaptation or parameter
configurations.
<TestAdaptionList>
<TestAdaption>
<reactionlist>
<reactparamwrite when="preparams">
<paramvalue>APPL_eneDevType_Bus</paramvalue>
</reactparamwrite>
</reactionlist>
</TestAdaption>
</TestAdaptionList>
Note
There may only be one reaction list within a test adaptation. However, this reaction list can
contain several reactions. Also within a test adaptation list <TestAdaptionList> there can be
several test adaptations with one reaction list each. Each test adaptation consists (optionally)
of a condition and a reaction list.
Time for execution

Each reaction must be provided with a "when" execution time. The following times are
possible:
now
The reaction is executed immediately when the command line in the sequence script is
reached.
<reactsetcomment when="now">
<comment>Condition ok</comment>
</reactsetcomment>
Configuration
3.4 Script files
end
The reaction is executed at the end of the integration process.
<reactparamread when="end">
<paramname>ATU_wRotation_001</paramname>
</reactparamread>
For the parameter write operations, there are also the "when" conditions "preparams" and
"params".
These reactions cause the parameter to be included in the list of parameters to be written in
this step. The reaction must be executed before the start of this step so that the parameters
are ready. Use "now" instead of "preparams" if the integration has already started.
preparams
This reaction adds the parameter to the list of temporary parameters. Because setting the
temporary parameters starts when the integration starts, you must embed reactions with
when="preparams" in the test adaptation.
<TestAdaptionList>
<TestAdaption>
<reactionlist>
</reactparamwrite>
</reactionlist>
</TestAdaption>
</TestAdaptionList>
params
This reaction adds the parameter to the list of regular parameters. This reaction must be
executed before the start of the step with type="nodeparams".
<reactparamwrite when="params">
<paramname>Sensor position</paramname>
<paramvalue>Installation_system_2</paramvalue>
</reactparamwrite>
nextstep
The reaction refers to the following test step. In the following example, the condition "at least
750" is inserted in the test step:
<reactconditionadd when="nextstep">
<value>750</value>
</condition>
</reactconditionadd>
Configuration
3.4 Script files
stepbyid
The reaction is executed for the specified test step. For this, the test step number "stepid"
must be specified in addition to the time "stepbyid". The following example skips test step 32:
<reactskipstep when="stepbyid" stepid="32">
</reactskipstep>
Possible reactions
Test cancellation (reactcanceltest)

This reaction is can only be used when it is embedded in a test adaptation or test
precondition <TestPrecondition>. If the conditions for the test termination are met, the
integration process is terminated immediately. If the condition list contains only one
condition, the type can be "or" or "and".
Example 1: A test abort is triggered if the condition that the device must have the CORFU
system is not fulfilled. "Software version not supported." is output as an optional response.
<TestAdaptionList>
<TestAdaption>
<value>CORFU</value>
</condition>
</conditionlist>
<reactionlist>
<reactcanceltest>
<description>Software version not
supported.</description>
</reactcanceltest>
</reactionlist>
</TestAdaption>
</TestAdaptionList>
Example 2: The test abort is triggered when the software on the device is older than version
2.1.19. The output texts <description>, in this example output in two lines, are optional.
<TestAdaptionList>
<TestAdaption>
<conditionlist>
<condition type="softwareversion" relation="below">
</condition>
</conditionlist>
<reactionlist>
<reactcanceltest>
<description>Device's software is
outdated!</description>
<description>Proceed with Transponder-integration after
completing software update.</description>
Configuration
3.4 Script files
</reactcanceltest>
</reactionlist>
</TestAdaption>
</TestAdaptionList>
Configurations
You can insert some reactions into the corresponding command line of the configuration.
These reactions are listed during the corresponding processes:
Write parameter <reactparamwrite>:
The reaction causes a parameter <paramvalue> to be appended to the list of parameters
being written to the device. You can choose to write the pre-parameters "preparams",
parameters "params" or immediately "now" as the time for this action. Enter the parameter
name <paramname> and parameter value <paramvalue> to be written.
<TestAdaptionList>
<TestAdaption>
<reactionlist>
</reactparamwrite>
</reactionlist>
</TestAdaption>
</TestAdaptionList>
Read out parameter (reactparamread):
This reaction forces you to read the particular parameter. Possible points in time are
immediately and at the end of the test step.
<TestStep id="47" type="apk" apktype="papk" apknum="0x0a" param1="1"

param2="0" param3="0">
<name>Measurement of the installation alignment</name>
<description>The installation alignment of the device is read
out.</description>
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
<reactionlist>
</reactparamread>
</reactionlist>
</TestStep>
Configuration
3.4 Script files
Restart node (reactnodereset)

You can use this reaction to specify that the node restarts. This is possible at the end of
parameter writing as well as under a conceivable abort of the test in progress.
<reactnodereset when="end"/>
Add condition (reactconditionadd)

The following command block adds another condition to a condition list.
<reactconditionadd when="nextstep">
<value>750</value>
</condition>
Skip test step (reactskipstep)

<reactskipstep when="stepbyid" stepid="32">
</reactskipstep>
Special I/O reaction (reactiocheckmode)
<reactiocheckmode when="stepbyid" stepid="34">

<highlowmode>
<highmask>0x10</highmask>
<lowmask>0x00</lowmask>
</highlowmode>
</reactiocheckmode>
This sets the label of the corresponding step:
<reactsetdescription when="stepbyid" stepid="32">

<description>Checking connector B</description>
</reactsetdescription>
This sets the comment of the corresponding step, which is output in the test log:
<reactsetcomment when="now">
<comment>Condition ok</comment>
</reactsetcomment>
Configuration
3.4 Script files
3.4.6 Test step types
question
The "question" type is the basic type of all tests that can be performed.

<name>Antenna connection test</name>
<description>Is the antenna is permanently mounted on the
device?</description>
</TestStep>
When a test step is created as a "question", the buttons "Yes", "No" and "Skip" automatically
appear. The test sequence is only continued after one of the buttons has been clicked.
Ranging
This test step is performed without other test steps being performed at the same time. When
the test step is finished, the next one is started. You can only use this test step once per test
script. This test step is only for transponders that use TWR localization.
<TestStep id="8" type="ranging">

<name>Distance measurement</name>
<description>Wait until the transponder has performed a distance
measurement.</description>
</TestStep>
IO
The IO test checks whether the assignment of the input and output signals of the
transponder are functioning correctly. To check a virtual input or output signal, specify
iomode="virtual". If an iomode specification is missing, a physical IO signal is automatically
checked.
You can configure three test versions that cannot be combined with each other:
risingflank
The signal must change from 0 to 1.
<TestStep id="8" type="IO">

<name>Ignition signal on (terminal 15)</name>
<description>Switch on the ignition of the vehicle, but not the
motor.</description>
<risingflank>0x01</risingflank>
</TestStep>
Configuration
3.4 Script files
fallingflank
The signal must change from 1 to 0.

<name>Ignition signal off (terminal 15)</name>
<description>Switch off the ignition of the
vehicle.</description>
<fallingflank>0x01</fallingflank>
</TestStep>
highlowmode
The signal of one IO must be 1 or become 1, while the signal of another IO must be 0 or
become 0.
<TestStep id="12" type="IO" iomode="virtual">

<name>Run test</name>
<description>Run the vehicle two to five meters.</description>
<highlowmode>
</highlowmode>
<autotimeout duration_s="30"><message>Messung
fehlgeschlagen</message></autotimeout>
</TestStep>
nochangemask
If the test is only to be passed if no signal change has been specified, you must optionally
specify a "nochangemask". You can only use this test step for the type "IO".
In this example, "risingflank" (0x0A) is connected to "nochangemask" (0x01). It is checked
whether inputs 2 and 4 are switched. Input 1 must not change.

<description>Run the vehicle two to five meters.</description>
<risingflank nochangemask="0x01">0x0A</risingflank>
</TestStep>
Configuration
3.4 Script files
Inputs
The specification of the physical or virtual input is hexadecimal:
Hexadecimal Description Hexadecimal Description

0x00 For no input 0x10 For input 5
0x01 For input 1 0x11 For inputs 1 and 5
0x03 For inputs 1 and 2 0x13 For inputs 1, 2 and 5
0x07 For inputs 1, 2 and 3 0x17 For inputs 1, 2, 3 and 5
0x0A For inputs 2 and 4 0x1A For inputs 2, 4 and 5
0x0B For inputs 1, 2 and 4 0x1B For inputs 1, 2, 4 and 5
0x0C For inputs 3 and 4 0x1C For inputs 3, 4 and 5
0x0D For inputs 1, 3 and 4 0x1D For inputs 1, 3, 4 and 5
0x0E For inputs 2, 3 and 4 0x1E For inputs 2, 3, 4 and 5
0x0F For inputs 1, 2, 3 and 4 0x1f For inputs 1 to 5
Please refer to the operating instructions of the transponder to determine the inputs of the
transponder to be integrated. Currently, transponders up to input 8 are supported.
If the test fails, the message specified under <conditionviolatedmessage> is output. This
message can only be output in the IO test if the command line is supplemented by an
automatic time window:
Example:
Input 2 must be 1 or change from 0 to 1, input 1 must be 0 or change from 1 to 0. The
condition must be fulfilled within 300 seconds, otherwise the test failed.

<description>Run the vehicle two to five meters. Switch off the
ignition.</description>
<highlowmode>
</highlowmode>
<buttonresults yes="TROk" no="TRFailed" skip="TRSkipped"/>
<conditionviolatemessage>The vehicle was not moved. Start the
integration process again.</conditionviolatemessage>
<autotimeout duration_s="300"><message>Measurement
failed</message></autotimeout>
</TestStep>
Configuration
3.4 Script files
MultiSelect
You can use this item to add a drop-down list "type="ComboBox"" for the integration step.
You can name this menu with the "<name>" parameter. You can define the individual
selection points using values within the "<selection>". You can create a corresponding
reaction list for each selection. Do not select "Yes" or "No", but instead a certain pre-
configured text, e.g. installation alignment of the transponder.
Note
The "No" button is hidden by default during this test step. The label of the "Yes" button is set
to "OK" and can be overwritten.
<TestStep id="62" type="MultiSelect">

<name> Device alignment</name>
<description> Select device alignment</description>
<SelectItem type="ComboBox">
<name>Device alignment</name>
<selection>
<value>Installation_system_1</value>
<reactionlist>
<reactapkparamvalue when="nextstep"
paramnum="2">0</reactapkparamvalue>
<reactconditionadd> when="nextstep">
<value>-1500</value>
</condition>

</reactionlist>
</selection>
<selection>
<value>Installation_system_2</value>
<reactionlist>
<reactapkparamvalue when="nextstep"
paramnum="2">0</reactapkparamvalue>

</reactionlist>
</selection>
</SelectItem>
</TestStep>
Configuration
3.4 Script files
KilometerKFactor
For the conversion of the wheel ticks in centimeters, you must set the K factor. The
parameter name <paramname> can be changed if the value is stored on the transponder
under a different name. Specifying the parameter name is optional. The parameter factor is
used to multiply the edit before it is stored on the node. The visible buttons for this particular
test step must not be modified by command lines.
The test uses the <conditionlist> to check the value. There is a default condition that the
value must be just above "0". If this is to be further restricted, the <condition-type> must be
changed to <and> and the actual condition must be configured as a sub-condition.
<TestStep id="61" type="KilometerKFaktor">

<paramname>MileageKFaktor</paramname>
<paramfactor>1024</paramfactor>
</TestStep>
voltage
This test step type can be used to check the voltage of the device in conjunction with a
<conditionlist>. If the first voltage value read out is inadmissible, the test step waits for the
next heartbeat, since in some devices the voltage value is not yet available immediately after
a reset.
<TestStep id="20" type="voltage">
nodeparams
The "nodeparams" test step type causes the specified values of a parameter list to be written
to the device. The test step is only reported as successful and the entire test continues as
soon as the write operation is reported as completed.
<TestStep id="7" type="nodeparams">
condition
Do not confuse this test step type with the conditions (section "Test scripts of XML files -
conditions (Page 32)"), that are not test step types. The "condition" test step type refers to a
template that contains the parameters present on the device. This is required so that the
"DeviceAssistant" client can change parameters on the device. For example, this test step type
allows the client to recognize the signal change of a digital input signal that needs to be
monitored in order to recognize the reported level change at the wheel sensor and thus
whether the vehicle has been moved.
<TestStep id="6" type="condition">
This test step type can be used practically, e.g. when writing temporary parameters (section
"Write temporary parameters (Page 58)").
Configuration
3.4 Script files
3.4.7 Possible test steps

The following table lists all test steps that can be executed using script files and that can be
used in the "DeviceAssistant" client. The desired test steps must be activated accordingly via
the script file. Note that you may only assign each ID once. Some test steps may require
different actions by the agent for integration, whereas some test steps may require the
system to automatically check the selected step.
ID Type Name for test step Description

0 Start, Name, Type
1 Question Antenna
2 Question LED check
6 Parameters during integration
7 Parameter set
8 Ranging
10 IO Terminal 15 on
11 IO Terminal 15 off
12 IO V signal (outdated)
13 IO TW2500 rear coupled Affects Upgrade B or Coupler B test
20 Voltage
31 Upgrade A
32 Upgrade B
33 Coupler A
34 Coupler B
35 Operating voltage (signal)
36 Supply voltage (PVK)
41 V signal query
42 Run test (V signal)
43 Run test (negated standstill signal)
44 Installation alignment test
46 Check acceleration sensor flags
47 Measure installation position at bottom
48 Question Query vehicle horizontally
49 Question Wireless device permanently installed
51 Read original calibration value
52 Bus at test position
55 Calibration measurement
57 Save calibration value
60 Configure antenna position
61 Query cable length and antenna type
62 Query installation alignment
63 KilometerKFactor
71 Output 1 On switch
72 Output 1 On query
73 Output 1 Off switch
74 Output 1 Off query
81 Output 2 On switch
82 Output 2 On query
Configuration
3.5 Selection of the action to be performed
ID Type Name for test step Description

83 Output 2 Off switch
84 Output 2 Off query
90 Display PropertyValues
95 Write parameter
96 Write PropertyValues
101 Cable connection question
102 Sealing ring query
103 Cover cap closed question
104 Secured via safety rope
3.5.1 Selection of the action to be performed

The "DeviceAssistant" client can be used for the following administrative tasks:
• "Installation and removal of vehicle tags (Page 47)"
• "Replacement of infrastructure devices (Page 48)"
• Management of the "Retrofit (Page 49)"
3.5.2 Installation and removal of vehicle tags

You can use the "Installation and removal of vehicle tags" button to open the user interface
for transponder integration. Status information, such as the supply voltage or software
version, of the selected transponder is shown there in the "Device information" dialog.
Mobile integration
The "Transponder for integration" dialog displays all transponders that can be reached for
integration. Make sure that you can only edit active transponders. These are indicated by
the symbol.
Proceed as follows to integrate transponders:
1. Select the desired transponder and click the "Start" button to start the integration process.
Result: The "Configure transponder" section appears.
2. Enter your internal vehicle number.
3. Select the relevant vehicle type from the drop-down list.
4. Click "Save" to initiate the next step of the integration, the connection test. Depending on
the vehicle type selected, individual integration steps may differ from those shown.
Configuration
5. Ensure that the antenna is correctly mounted. The integration test cannot be completed
successfully if this step is skipped.
6. Click "Yes" or "No" to proceed to the next integration step.
7. For the "LED check", indicate whether the LEDs on the device have lit up when connected to
the mains plug. Click either the "Yes" or "No" button.
Result: The temporary parameters are set automatically and the specified antenna position is
output.
8. Click "OK" button to proceed to the next integration steps:
By upgrading Operator Platform A, the corresponding section of the integration is
automatically confirmed with "Yes" and continued. The same applies to the required
"Upgrade B" and the simulated couplings. The "Distance measurement", "Installation
alignment" and "Set parameters" steps also run automatically.
9. Click "Save" once the assistant has performed the actions to complete the integration.
Result: A print dialog box appears for outputting the integration log.
Remove transponders
1. In the "Delete mobile devices" drop-down list, select the corresponding transponder to
remove it.
2. Click "Delete" to remove the transponder and the associated configurations after confirming
the dialog that appears.
3.5.3 Infrastructure exchange

Proceed as follows to exchange infrastructure devices:
1. In the view for replacing infrastructure equipment, use the drop-down lists to select the
device to be replaced after the replacement device has been installed in place of the old
device. New gateways are automatically detected by the Locating Manager. Anchors are
only created automatically if they have been found via exploration.
Note
You can only replace devices with devices of the same type. It is not possible to replace a
gateway with an anchor or vice versa.
2. Enter the device address if the new device does not exist. If the device has already been
created, you can search for parts of the address or the name in the "New node" text box.
The selected devices are displayed in the section "Information about nodes to be
replaced".
3. Click "Start" and confirm your selection.
4. Confirm the two subsequent dialog boxes.
The node names are automatically adapted. The localization areas are checked and adapted
automatically, and the routing is analyzed and replaced. If the nodes have the same device
software and the new node is active, all configuration parameters of the old node are
automatically transferred to the new node.
Configuration
Finally, you can decide whether to delete the replaced node from the Locating Manager.
Result: The replacement of the old node and the integration of the new node are now
complete.
3.5.4 Retrofit
Mileage configuration
Proceed as follows to open the "Mileage configuration" dialog:
1. Click "Mileage configuration" to open the user interface for entering the current mileage
configuration or for calibrating the mileage configurationer.
2. Select the desired function in the drop-down list for the transponder selected in the "Nodes
for retrofit" window.
You can use the "Naming restriction" text box to restrict the list of displayed nodes
accordingly.
3. Click "Start" to perform the selected action.
Enter the mileage configuration

Enter the current mileage configuration of the vehicle in the corresponding text box and
confirm the entry with "OK". The value is set in the Locating Manager database or the existing
value is overwritten. The retrofit is now complete and a print dialog appears for the output of
the integration log.
Note
Depending on the system, the correction or entry of mileage configuration can only be
performed using the procedure described. The use of the "DeviceAssistant" client is
indispensable for processing the mileage configurations.
Mileage configuration
Proceed as follows to set the mileage configuration:
1. In the "Mileage configuration" section, you can optionally define the ticks and wheel
circumferences or the conversion factor. When entering ticks and wheel circumference (only
integer values allowed), the "cm/tick" factor is automatically determined in the same section.
After having entered the values, you can set them by clicking the corresponding button.
2. Click "Start measurement run" to perform a measurement run of a few meter on a calibrated
route.
This checks the signal connection on the transponder and the conversion factor.
3. Stop the test drive after completion via the "Stop test drive" button.
Configuration
4. Click "Acknowledge" to agree to the measured values determined.

5. Perform another measurement run if the displayed value does not match the traveled
distance by entering the parameters listed above once again.
Result: Retrofitting the transponder is fully completed. A print dialog box appears for
outputting the integration log.
The transponder stores the conversion factor, counts the ticks and reports the current relative
kilometers to the Locating Manager. The total kilometers set in the database plus the relative
kilometer last reported by the transponder serve as the basis for calculating the mileage
configuration for the vehicle in the RTLS localization system.
Code examples 4
4.1 General application examples
The following are application examples in script form.
4.1.1 Basic framework and parameter test
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<description>
<testname>Bus integration</testname>
</description>
<TestAdaptionList>
<TestAdaption>
<reactionlist>
</reactparamwrite>
</reactionlist>
</TestAdaption>
</TestAdaptionList>
Code examples
4.1.2 Restriction to transponders with certain system software
<TestAdaption>
<value>CORFU</value>
</condition>
</conditionlist>
<reactionlist>
<reactcanceltest>
<description>Software version not supported.</description>
</reactcanceltest>
</reactionlist>
</TestAdaption>
4.1.3 Restriction to transponders with a certain software version
<TestAdaption>
<conditionlist>
<condition type="softwareversion" relation="below">
</condition>
</conditionlist>
<reactionlist>
<reactcanceltest>
<description>Please update software version.</description>
</reactcanceltest>
</reactionlist>
</TestAdaption>
4.1.4 Antenna connector test
<StepList>
<name>Connection test</name>
<description>Is the antenna cable permanently
mounted?</description>
</TestStep>
</StepList>
Code examples
4.1.5 LED check

<name>LED check</name>
<description>Do the LEDs light up when there is a plug-in
connection?</description>
</TestStep>
4.1.6 Query the installation alignment via inertial sensors
<StepGroup>
<name>Measurement of the alignment</name>
<activeconditions insertonskip="false">
<value>CORFU_DRV1</value>
</condition>
</activeconditions>
<StepGroup>
<name>Measurement of the alignment</name>
<activeconditions insertonskip="true">
<conditionlist>
<value>CORFU_DRV1</value>
</condition>
<condition type="softwareversion" relation="min">
</condition>
</conditionlist>
</activeconditions>
4.1.7 CableLength
Using different antennas or cables has an effect on the runtime of the radio signals and thus
an effect on the distance measurement for the localization. To compensate for this effect, the
calibration values of the transponders can be adjusted. Compensation is based on the
following formula:
Calibration offset = -1 * (cable length*cable factor + antenna offset)
This test step is only for permitted for CHIRP devices.
Code examples
You can find more information on cable factor and antenna offset in the sections
"[CableFactor] parameter (Page 26)" and "[CableAntennaOffset] parameter (Page 26)".
You can specify the cable length, like the antenna position, via the "DeviceAssistant.ini"
configuration file (section "Parameter [CableLength] (Page 26)"). The data entered there
overwrites the cable lengths entered in the script.
The specification of the <defaults> section including the length is optional. By default, only
the "OK" and "Skip" buttons are displayed in the user interface for this test step. The test run
after this test step must include a test step of the type "SetParameter" because the calibration
offset is written in this step.
Note
The length "100" is the default value, but can be changed.
<TestStep id="61" type="CableLength" editable="true">

<defaults>
<length>100</length>
</defaults>
</TestStep>
4.1.8 Vehicle alignment

<name>Vehicle horizontal</name>
<description>Ensure that the vehicle is level during the
installation.</description>
<buttonvisibility yes="true" no="false" skip="true"/>
</TestStep>
4.1.9 Fixation of transponders

<name>Device fixed</name>
<description>Is the device mounted in the intended
position?</description>
<buttonvisibility yes="true" no="false" skip="true"/>
</TestStep>
Code examples
4.1.10 Test of the acceleration sensor
<TestStep id="46" type="apk" apktype="mwb" apknum="0x14" param1="0"

param2="0">
<name>Acceleration sensor</name>
<description>Read out sensor information</description>
<conditionviolatedmessage>Fail: Please return device for repair
to Siemens.</conditionviolatedmessage>
<conditionlist>
<condition relation="BinaryMask">
<value>0x36</value>
</condition>
</conditionlist>
</TestStep>
4.1.11 Installation alignment of the transponder
<TestStep id="47" type="apk" apktype="papk" apknum="0x0a" param1="1"

<name>Measuring alignment</name>
<description>Measuring device alignment</description>
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
<reactionlist>
</reactparamread>
</reactionlist>
</TestStep>
Code examples
4.1.12 AntennaPosition
The antenna position can be set in the "DeviceAssistant.ini" configuration file (section "
Parameter [AntennaPosition] (Page 26)"). In addition, this configuration can be done via the
script file. You can create an editable text box (section " Antenna position editable (Page 56)")
or specify fixed antenna positions (section " Antenna position specified (Page 56)").
If this test step is used while specifying an antenna position value in the "DeviceAssistant.ini"
configuration file, the value specified in the "DeviceAssistant.ini" configuration file overwrites
specified values.
The values specified in the script are used if no corresponding value is read from the
"DeviceAssistant.ini" configuration file.
<defaults>
<AntennaPositionFront>123</AntennaPositionFront>
<AntennaPositionCenter>0</AntennaPositionCenter>
<AntennaPositionBottom>200</AntennaPositionBottom>
</defaults>
4.1.13 Antenna position editable
<TestStep id="60" type="AntennaPosition" editable="true">

<name>Antenna position</name>
<description>Antenna position relative to vehicle</description>
</TestStep>
4.1.14 Antenna position specified
<TestStep id="60" type="AntennaPosition" editable="false">

<name>Antenna position</name>
<description>Antenna position relative to vehicle</description>
<defaults>
<AntennaPositionFront>325</AntennaPositionFront>
<AntennaPositionCenter>0</AntennaPositionCenter>
<AntennaPositionBottom>0</AntennaPositionBottom>
</defaults>
</TestStep>
Code examples
4.1.15 Antenna configuration
<TestStep id="61" type="CableLength">

<name>Antenna configuration</name>
<description>Enter the antenna configuration.</description>
<conditionlist>
<value>0</value>
<condition>
</conditionlist>
</TestStep>
4.1.16 Antenna configuration with preset cable length
<TestStep id="61" type="CableLength" editable="false">

<name>Antenna configuration</name>
<description>Enter the antenna configuration.</description>
<defaults>
<length>100</length>
</defaults>
</TestStep>
Note
If a specific cable length is specified in the "DeviceAssistant.ini" configuration file, this cable
length is used and cannot be overwritten by another specification.
Code examples
4.1.17 Write temporary parameters
Note
Use this test step so that the transponders are pre-configured for integration. In the data
record for temporary parameters, the configuration is usually such that localization is active
in all operating states and good accessibility is guaranteed over a short heartbeat cycle. At
the end of this test step, a reset is performed automatically so that all parameters are applied
by the device.
<TestStep id="6" type="condition">

<name>Set temporary parameter</name>
<description>Write temporary parameter</description>
<conditionokmessage>The parameter writing is
finished.</conditionokmessage>
<buttonresults yes="TROk" no="TRNo" skip="TRSkipped">
<useractions>SkipOnly</useractions>
<conditionlist>
<condition type="paramwritingdone"/>
</conditionlist>
</TestStep>
4.1.18 Distance measurement
<TestStep id="8" type="ranging">

<name>Distance measurement</name>
<description>Waiting for the distance
measurement....</description>
</TestStep>
4.1.19 Test V signal

<name>V signal</name>
<description>Was the V signal correctly connected?</description>
</TestStep>
Code examples
4.1.20 Set parameters
<TestStep id="7" type="nodeparams">

<name>Set parameters</name>
<description>Wait until parameters are fully
written...</description>
</TestStep>
4.1.21 Ready for run test

<name>Ready for the run test?</name>
<description>Is the vehicle ready for the run test?</description>
</TestStep>
4.1.22 Run test
<TestStep id="42" type="IO" iomode="virtual">

<description>Move the vehicle two to five m.</description>
<highlowmode>
</highlowmode>
</TestStep>
or

<description>Move the vehicle two to five m.</description>
<highlowmode>
</highlowmode>
</TestStep>
Code examples
4.2 Special application examples
4.2.1 Road vehicles
Terminal 15 on

<name>"Terminal 15 on" test</name>
<description>Switch on the ignition, but not the motor. If
necessary, switch the ignition off beforehand and then
on.</description>
<risingflank>0x01/risingflank>
</TestStep>
Terminal 15 off

<name>"Terminal 15 off" test</name>
<description>Switch the ignition off again..</description>
<fallingflank>0x01/fallingflank>
</TestStep>
Code examples
4.2.2 Rail vehicle
Operating voltage

<name>Operation switch on supply voltage</name>
<description>Turn on the power supply.</description>
</TestStep>
Upgrade operator platforms / direction of travel

<name>Upgrade A</name>
<description>Upgrade Operator Platform A (V) and downgrade it
again after at least 5 seconds.</description>
</TestStep>

<name>Upgrade B</name>
<description>Upgrade operator platform B with (V) and leave it
upgraded.</description>
</TestStep>
Couplers

<name>Coupler A</name>
<description>Simulate Coupler A.</description>
</TestStep>

<name>Coupler B</name>
<description>Simulate Coupler B.</description>
</TestStep>
Code examples
Pantograph
<TestStep id="71" type="apk" apktype="papk" apknum="0" param1="1"

<name>Pantograph on</name>
<description>Enable the pantograph.</description>
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
</TestStep>

<name>Pantograph on test</name>
<description>Is the passage available?</description>
</TestStep>

<name>Pantograph off</name>
<description>Disable the pantograph.</description>
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
</TestStep>

<name>Pantograph off test</name>
<description>Is the passage no longer available?</description>
</TestStep>
Code examples
Heating

<name>Heating on</name>
<description>Activate the heating.</description>
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
</TestStep>

<name>Heating on test</name>
<description>Is the passage ensured?</description>
</TestStep>

<name>Heating off</name>
<description>Disable the heating.</description>
<conditionlist>
<value>1</value>
</condition>
</conditionlist>
</TestStep>

<name>Heating off test</name>
<description>Is the passage no longer ensured?</description>
</TestStep>
Code examples
Retrofit mileage configuration
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<description>
<testname>Set mileage configuration</testname>
</description>
<TestAdaptionList>
</TestAdaptionList>
<TestPrecondition type="and">
<paramname>MileageKFactor</paramname>
</condition>
</condition>
</TestPrecondition>
<StepList>
<TestStep id="95" type="SetPropvals" editable="false">
<name>Current mileage configuration</name>
<description>Enter the mileage configuration and save it on
the vehicle transponder.</description>
<param>
<desc>Mileage configuration [km]</desc>
<paramname>Mileage</paramname>
<conditionlist>
<condition relation="above">
<value>0</value>
</condition>
<condition relation="max">
<value>5000000</value>
</condition>
</conditionlist>
</param>
<buttonvisibility no="false" skip="false">

</TestStep>
</StepList>
Code examples
K factor
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<description>
<testname>Adapt K factor</testname>
</description>
<TestAdaptionList>
</TestAdaptionList>
<TestPrecondition type="and">
<paramname>MileageKFactor</paramname>
</condition>
<value>APPL_eneDevType_KT8D5</value>
</condition>
</TestPrecondition>
<StepList>
<TestStep id="63" type="KilometerKFactor">
<name>Mileage configuration</name>
<description>Set conversion factor</description>
</TestStep>
</StepList>
Code examples
Error messages 5
Error number text Possible cause
10050 Network is down Ethernet connection disconnected
Network interface defective
Error in the Windows protocol stack
10051 Network unreachable RTLS localization network cannot be reached, no
connection to the target
10052 Network dropped connection on Connection closed due to lacking heartbeat
reset
10053 Software caused connection abort Connection disconnected by Locating Manager
server
10054 Connection reset by peer Locating Manager server has disconnected
connection
Locating Manager server is shut down
10055 No buffer space available The local PC is working at full capacity
No output buffer available
10056 Socket is already connected A socket is already connected.
10060 Connection timed out Connection attempt canceled because the
Locating Manager server does not respond
10061 Connection refused Connection attempt canceled because the
Locating Manager server has rejected the
connection
10064 Host is down The Locating Manager server is not responding.
10065 No route to host Destination not accessible, no route

BA RTLS-Integrationsassistent-V2.13.0.0 76

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BA RTLS-Integrationsassistent-V2.13.0.0 76

Uploaded by

Copyright:

Available Formats

RTLS DeviceAssistant

Siemens AG C7900-G8976-C564-03 Copyright © Siemens AG 2022.

Purpose of this documentation

Validity of this documentation

Industry Online Support

SITRAIN - Training for Industry

RTLS Technology and Practice (ID-RTLS-TP)

Note on firmware/software support

Recycling and disposal

3.5.3 Infrastructure exchange ..................................................................................................... 48

Users, roles and passwords

Automation License Manager

Software (security functions)

Secure and non-secure protocols

List of available protocols (local access via a local network)

Service/Protocol Port number Default port status Authentication Loopback only

2.3 Functions in the menu bar of the client

2.3.1 Connecting and disconnecting

2.3.2 Connection configuration

2.3.3 Changing the password / language

Changing the language

2.3.5 Search options

2.3.6 Check for update

2.3.7 Clear log

3.2 Required configurations before first program start

Create transponder group

Transponder groups Description

Assignment of transponder groups via configuration file

Assignment of transponder groups at the start of the service

3.3 Configuration file

3.3.1 Parameter [misc]

3.3.2 Parameter [server]

3.3.3 Parameter [position]

3.3.4 Parameter [CentralConfiguration]

3.3.5 Parameter [Integration]

VehiclesBus=Citaro:Urbino:Lion's City:Ikarus 415

3.3.6 Parameter [IntegPictures]

3.3.7 Parameter [IntegAutoSetting]

3.3.8 Parameter [GroupConfigVehiclesWorking]

3.3.9 Parameter [AntennaPosition]

3.3.10 Parameter [CableLength]

3.3.11 [CableFactor] parameter

3.3.12 [CableAntennaOffset] parameter

3.3.13 Parameter [Retrofit]

testnames=Mileage configuration;K factor

3.4 Script files

3.4.1 Structure of the test scripts

3.4.2 Basic structure

3.4.3 Test scripts of XML files

<TestStep id="99" type="question">

Skip test step

End test step automatically

Restriction of user activity

3.4.4 Test scripts of XML files - conditions

<conditionlist type="or" negate="false">

<conditionlist type="or" negate="true">

The following tags are permitted for the "<relation>" item:

<condition type="softwareversion" relation="min">

<condition type="pvkvalue" relation="min" isInt="true">

<condition type="float" relation="min">

Message about fulfilled condition

3.4.5 Test scripts of XML files - responses

Time for execution