AVEVA™ InTouch HMI

Application Deployment Guide

aveva.com
 © 2015-2024 by AVEVA Group Limited or its subsidiaries. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any
means, mechanical, photocopying, recording, or otherwise, without the prior written permission of AVEVA
Group Limited. No liability is assumed with respect to the use of the information contained herein.
Although precaution has been taken in the preparation of this documentation, AVEVA assumes no responsibility
for errors or omissions. The information in this documentation is subject to change without notice and does not
represent a commitment on the part of AVEVA. The software described in this documentation is furnished under
a license agreement. This software may be used or copied only in accordance with the terms of such license
agreement. AVEVA, the AVEVA logo and logotype, OSIsoft, the OSIsoft logo and logotype, ArchestrA, Avantis,
Citect, DYNSIM, eDNA, EYESIM, InBatch, InduSoft, InStep, IntelaTrac, InTouch, Managed PI, OASyS, OSIsoft
Advanced Services, OSIsoft Cloud Services, OSIsoft Connected Services, OSIsoft EDS, PIPEPHASE, PI ACE, PI
Advanced Computing Engine, PI AF SDK, PI API, PI Asset Framework, PI Audit Viewer, PI Builder, PI Cloud
Connect, PI Connectors, PI Data Archive, PI DataLink, PI DataLink Server, PI Developers Club, PI Integrator for
Business Analytics, PI Interfaces, PI JDBC Driver, PI Manual Logger, PI Notifications, PI ODBC Driver, PI OLEDB
Enterprise, PI OLEDB Provider, PI OPC DA Server, PI OPC HDA Server, PI ProcessBook, PI SDK, PI Server, PI Square,
PI System, PI System Access, PI Vision, PI Visualization Suite, PI Web API, PI WebParts, PI Web Services, PRiSM,
PRO/II, PROVISION, ROMeo, RLINK, RtReports, SIM4ME, SimCentral, SimSci, Skelta, SmartGlance, Spiral Software,
WindowMaker, WindowViewer, and Wonderware are trademarks of AVEVA and/or its subsidiaries. All other
brands may be trademarks of their respective owners.
U.S. GOVERNMENT RIGHTS
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the license agreement
with AVEVA Group Limited or its subsidiaries and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR
12-212, FAR 52.227-19, or their successors, as applicable.
Publication date: Monday, July 29, 2024
Publication ID: 1401922
Contact information
AVEVA Group Limited
High Cross
Madingley Road
Cambridge
CB3 0HB. UK
https://sw.aveva.com/
For information on how to contact sales and customer training, see https://sw.aveva.com/contact.
For information on how to contact technical support, see https://sw.aveva.com/support.
To access the AVEVA Knowledge and Support center, visit https://softwaresupport.aveva.com.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 2
Contents

Chapter 1 Deploy and work with Terminal Services and Remote Desktop Services. . . 5
Plan for Terminal Server applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Deploy InTouch applications in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Alarms in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Security in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I/O in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Script execution in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Log on to a terminal session properly to run InTouch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Alarm query syntax in a Terminal Service environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Miscellaneous limitations in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Retrieve information about the InTouch client session using scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
TseGetClientId() function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
TseGetClientNodeName() function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
TseQueryRunningOnConsole() function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
TseQueryRunningOnClient() function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Remote Desktop Services overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Remote Desktop Services role services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Secure your Remote Desktop Services (RDS) connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Windows Server 2016 Remote Desktop Services best practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 2 Distribute applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Supported InTouch architectures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Single computer architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Client-based architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Server-based architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Network Application Development (NAD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Plan networked applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
I/O data access for networked applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Use global I/O addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Use local I/O addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SuiteLink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Access to shared files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Use global addresses to file data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Use local addresses to file data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Access to shared files through UNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Log data in a distributed environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Configure remote history providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 3
 AVEVA™ InTouch HMI
Contents

Dynamically configure remote history providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Configure distributed historical logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Considerations for special networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Configure an InTouch application for NAD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Perform an automatic NAD update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Perform a manual NAD update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
$ApplicationChanged system tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
$ApplicationVersion system tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
RestartWindowViewer() function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ReloadWindowViewer() function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Application editing locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Changes to an application during a NAD update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Scale the application resolution at run time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Lock the application resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Publish applications to remote nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contents of a published file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Publish a standalone InTouch application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Publish managed InTouch applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Publish a managed InTouch application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Publish applications to Insight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 3 Use managed InTouch applications at run time. . . . . . . . . . . . . . . . . . . . . . 40

Deploy a managed InTouch application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Deploy a InTouchViewApp object for the first time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Deploy changes to a managed InTouch application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Start a managed InTouch application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Control the WindowViewer restart wait period when deploying managed applications. . . . . . . . . . . . . . . . 43
Accept new application versions at the operator node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Run ArchestrA scripts in embedded industrial graphics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Deploy the InTouchViewApp object in a Terminal Services environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 4 Use InTouch HMI applications in AVEVA Edge. . . . . . . . . . . . . . . . . . . . . . . 48

Download the AVEVA Edge zip file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Upload the AVEVA Edge zip file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Configure users for Edge device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 4
Chapter 1

Deploy and work with Terminal Services

and Remote Desktop Services

Terminal Services is a configurable service included in the Microsoft Windows Server operating systems that runs
Windows-based applications centrally from a server. In Terminal Services, client computers access the server
node, where multiple instances of InTouch software applications run simultaneously.
WindowViewer WindowViewer WindowViewer
Thin Client Thin Client Thin Client

Corporate Network

InTouch
Terminal Server

Supervisory Network

The Terminal Services environment has three main parts:

• Terminal Services Server. The server manages the computing resources for each client session and provides
client users with their own unique environment. The server receives and processes all keystrokes and mouse
actions performed at the remote client and directs all display output for both the operating system and
applications to the appropriate client. All Terminal Services application processing occurs on the server.
• Remote Desktop Protocol (RDP). A Remote Desktop Protocol (RDP) client application passes the input data,
such as keystrokes and mouse movements, to the server.
• Client. The Terminal Services client performs no local application processing; it just shows the application
output. You access Terminal Services from a client by running the Terminal Services Client command on the
Windows Program menu. When you connect to the Terminal server, the client environment looks the same
as the Windows server. The fact that the application is not running locally is completely transparent.
For more information about Terminal Services, including features and benefits, see your Microsoft
documentation.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 5
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

Plan for Terminal Server applications

Important: We recommend that you install applications on a test server before you deploy them in your
production environment.
Before you install Terminal Services
• Identify the client applications (for example, InTouch) that you need to install on the server.
• Identify the hardware requirements for your clients.
• Determine the server configuration required to support clients.
• Identify the licenses required for Terminal Services as well as other applications that you will be running.
• Understand how some aspects of InTouch applications run under Terminal Services, such as alarms, security,
I/O, and scripts.

Deploy InTouch applications in a Terminal Services environment

When deploying InTouch applications in a Terminal Services environment, a separate InTouch application should
be deployed for each node.

Alarms in a Terminal Services environment

By using the Distributed Alarm System with Terminal Services for InTouch, alarm clients running on different
terminal sessions can select what alarm to show and how to present it.
Alarm Providers identify themselves by a name that uniquely identifies their application, and the instance of
their application. This information is made available to the Distributed Alarm System when the Alarm Provider or
the Alarm Consumer registers with the Distributed Alarm System.
The node on which an Alarm Provider is running is identified by a name that uniquely identifies the computer
node in the system. This information is made available to the Distributed Alarm System when an instance of it
starts up on the computer node.
When an alarm event is logged, the node and complete Alarm Provider name identify the source of the alarm.
When an alarm is acknowledged in a Terminal Services environment, the Operator Node that gets recorded is
the name of the client computer running the Terminal Services session used by the operator. If the node name of
the computer cannot be retrieved, its IP address is used instead.
Note: Alarm Providers are not supported on Terminal sessions. They are only supported on the Terminal Console.

Security in a Terminal Services environment

Use application security to secure your InTouch application, IndustrialSQL Server, and other sensitive information
systems.
• Use the $Operator system tag to secure your application. You can then control operator access to specific
functions by linking those functions to internal tags.
For more information about using the $Operator system tag, see About Securing InTouch.
• Replace the GetNodeName() function with the newer TseGetClientId() function to identify the client
computer. When using Terminal Services, the GetNodeName() function returns the name of the terminal
server, not the name of the client computer.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 6
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

Use security auditing to monitor intrusion attempts. If you suspect that your system is under any sort of attack,
then you can enable logging for an array of auditable events. By default, security logging/auditing is disabled
because it usually requires excessive processing resources.
Caution: Security auditing requires significant resources. Enable auditing when you evaluate your pilot server to
accurately estimate your InTouch application hardware requirements.

I/O in a Terminal Services environment

The InTouch HMI cannot start I/O Servers in a Terminal Services environment. Depending on the sequence that
view sessions start, you may need to use the IOReinitialize() function. All servers (I/O devices or view
applications) must be running before starting an application that reads values from these servers.
Avoid receiving an "initializing I/O" error message when WindowViewer starts
1. Open WindowMaker.
1. On the File menu, select Configure, and then select WindowViewer.
The WindowViewer configuration screen appears.
1. On the Preferences tab, in the I/O section, clear the Start Local Servers check box.

Script execution in a Terminal Services environment

Because all applications running in Terminal Services use a single timing reference (server clock), scripts may not
run during periods of excessive CPU loading. Abnormal CPU loading can be caused by excessive video processing
or when several applications have the same script triggers defined (such as an End-of-Shift event). It is possible,
therefore, that if the server is busy processing scripts from many clients, it may not start a script on another
client during the interval when the timer would normally start the script. This can prevent the script from
running on the client.
To ensure scripts run correctly, combine scripts with common triggers and move them to a single application,
such as a tag server. This is one of the primary reasons for pilot deployment. Pilot deployment gives you an
opportunity to conduct stress testing to determine if your hardware selection is adequate.

Log on to a terminal session properly to run InTouch

Each session must be logged on with a unique account. This can be done manually or Terminal Services can be
configured to enforce unique logons.
Note: Running with the same logon account on multiple sessions can cause corruption and other unexpected
results.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 7
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

Alarm query syntax in a Terminal Service environment

The alarm query syntax for a session's alarms is:
\\ServerNodename\InTouch!$System
The alarm query syntax for console alarms includes a colon (:) after the node name; for example:
\\ServerNodename:\InTouch!$system

Miscellaneous limitations in a Terminal Services environment

The following table describes the limitations and suggested solutions to run applications on a terminal server.
Feature Supported? Comment

WindowViewer Yes WindowViewer is not supported running as a

service under Terminal Services.
DDE to an I/O Device or MS Office No Use a tag server (console or separate
(for example, Excel) computer). This includes DDE QuickScripts:
WWExecute(), WWpoke() and WWRequest()

DDE from MS Office (for example, Yes Excel and the InTouch HMI must be running
Hot-link configured in Excel) in the same session.

Historical Trending Yes Use a tag server or NAD to log values.

Multiple sessions may read the same
historical files, but only a console can write to
historical files.
InTouch Alarm Logger Yes --
MEM OLE Automation Yes --
Printing Alarms No --
Retentive tags Yes Must use NAD.
SQL Access (ODBC) Yes Database should be on a separate computer.

SuiteLink to an I/O Device or Yes When communicating to another view

another InTouch application. session, include the Terminal Server node
name and append the IP address of the
desired session to the application name. For
example, view10.103.25.6. I/O Servers are
not supported in client sessions.

Retrieve information about the InTouch client session using scripts

You can use the following InTouch QuickScript functions for Terminal Services.
• TseGetClientId() function

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 8
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

• TseGetClientNodeName() function
• TseQueryRunningOnConsole() function
• TseQueryRunningOnClient() function

TseGetClientId() function
Returns a string version of the client ID (the TCP/IP address of the client) if the View application is running on a
Terminal Server client. This client ID is used internally to generate SuiteLink server names and logger file names.
Otherwise, the TseGetClientId() function returns an empty string.
Syntax
MessageResult=TseGetClientId();
Example
The client IP address 10.103.202.1 is saved to the MsgTag tag.
MsgTag=TseGetClientID();

TseGetClientNodeName() function
Returns the client node name if the View application is running on a Terminal Server client assigned a name that
can be identified by Windows. Otherwise, the TseGetClientNodeName() function returns an empty string.
Syntax
MessageResult=TseGetClientNodeName();
Example
The client node name is returned as the value assigned to the MsgTag tag.
MsgTag=TseGetClientNodeName();

TseQueryRunningOnConsole() function
The TseQueryRunningOnConsole() function can be run from a script to indicate whether the View application is
running on a Terminal Services console.
Syntax
Result=TseQueryRunningOnConsole();
Return value
Returns a non-zero integer value if the View application is running on a Terminal Services console. Otherwise, the
TseQueryRunningOnConsole() function returns a zero.
Example
IntTag is set to 1 if WindowViewer is running on a Terminal Services console.
IntTag=TseQueryRunningOnConsole();

TseQueryRunningOnClient() function
Returns a non-zero integer value if the View application is running on a Terminal Services client. Otherwise, it
returns a zero.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 9
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

Syntax
Result=TseQueryRunningOnClient();
Return value
Returns 0 if View is not running on a Terminal Services client.
Example
IntTag is set to 1 if WindowViewer is running on a Terminal Services client.
IntTag=TseQueryRunningOnClient;

Remote Desktop Services overview

Remote Desktop Services, formerly Terminal Services, is a server role in Windows Server® 2008 R2 and later
versions that provides technologies that enable users to access Windows-based programs that are installed on a
Remote Desktop Session Host (RD Session Host) server, or to access the full Windows desktop. With Remote
Desktop Services, users can access an RD Session Host server from within a corporate network or from the
Internet.
When a user accesses a program on an RD Session Host server, the program runs on the server. Each user sees
only their individual session. The session is managed transparently by the server operating system and is
independent of any other client session. Additionally, you can configure Remote Desktop Services to use Hyper-
V™ to either assign virtual machines to users or have Remote Desktop Services dynamically assign an available
virtual machine to a user upon connection.
For more information about Remote Desktop Services, see the Remote Desktop Services page on the Windows
Server 2008 R2 TechCenter (http://go.microsoft.com/fwlink/?LinkId=138055).

Remote Desktop Services role services

Remote Desktop Services is a server role that consists of several role services. In Windows Server 2008 R2 and
later versions, Remote Desktop Services consists of the following role services:
• RD Session Host: Remote Desktop Session Host (RD Session Host), formerly Terminal Server, enables a server
to host Windows-based programs or the full Windows desktop. Users can connect to an RD Session Host
server to run programs, to save files, and to use network resources on that server.
• RD Web Access: Remote Desktop Web Access (RD Web Access), formerly TS Web Access, enables users to
access RemoteApp and Desktop Connection through the Start menu on a computer that is running
Windows 7 or through a Web browser. RemoteApp and Desktop Connection provides a customized view of
RemoteApp programs and virtual desktops to users.
• RD Licensing: Remote Desktop Licensing (RD Licensing), formerly TS Licensing, manages the Remote Desktop
Services client access licenses (RDS CALs) that are required for each device or user to connect to an
RD Session Host server. You use RD Licensing to install, issue, and track the availability of RDS CALs on a
Remote Desktop license server.
• RD Gateway: Remote Desktop Gateway (RD Gateway), formerly TS Gateway, enables authorized remote
users to connect to resources on an internal corporate network, from any Internet-connected device.
• RD Connection Broker: Remote Desktop Connection Broker (RD Connection Broker), formerly TS Session
Broker, supports session load balancing and session reconnection in a load-balanced RD Session Host server

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 10
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

farm. RD Connection Broker is also used to provide users access to RemoteApp programs and virtual
desktops through RemoteApp and Desktop Connection.
• RD Virtualization Host: Remote Desktop Virtualization Host (RD Virtualization Host) integrates with Hyper-V
to host virtual machines and provide them to users as virtual desktops. You can assign a unique virtual
desktop to each user in your organization, or provide them shared access to a pool of virtual desktops.

Secure your Remote Desktop Services (RDS) connections

Safeguard against attacks with the following security practices
1. Use strong passwords
Use a strong password on all accounts with access to Remote Desktop.
2. Update your software
Make sure you are running the latest versions of both the client and server software by enabling and
auditing automatic Microsoft Updates.
3. Set an account lockout policy
By setting your computer to lock an account for a period of time after a number of incorrect guesses, you will
help prevent "brute-force" attack.
4. Use Two-factor authentication
RD Gateways support smartcard two-factor authentication.
5. Change the listening port for Remote Desktop
Prevents network attacks and worms that attempt to access the default Remote Desktop port (TCP 3389).
6. Use RD Gateways

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 11
 AVEVA™ InTouch HMI
Chapter 1 – Deploy and work with Terminal Services and Remote Desktop Services

RD Gateway restricts access to Remote Desktop ports while supporting remote connections through a single
"Gateway" server. When using an RD Gateway server, all Remote Desktop services on your desktop and
workstations are routed through the RD Gateway. The RD Gateway server listens for Remote Desktop
requests over HTTPS (port 443), and connects the client to the Remote Desktop service on the target
machine. Refer to the steps here: http://technet.microsoft.com/en-us/library/cc770601.aspx
7. Configure Network Level Authentication for Remote Desktop Services Connections
Network Level Authentication requires that the user be authenticated to the RD Session Host server before a
session is created. Network Level Authentication increasing availability of the RD Session Host server
(reduces the risk of denial-of-service attacks of the RD Session Host server). https://
technet.microsoft.com/en-us/library/hh831778.aspx
8. Configure Server Authentication and Encryption Levels
By default, Terminal Services sessions use native Remote Desktop Protocol (RDP) encryption. However, RDP
does not provide authentication to verify the identity of a terminal server. You can enhance the security of
Terminal Services sessions by using Transport Layer Security (TLS) 1.0 for server authentication and to
encrypt terminal server communications. The RDS and the client computer must be correctly configured for
TLS to provide enhanced security. By default, RDS connections between the client and server are encrypted
at the highest level of security available (128-bit), ensuring integrity and confidentiality of the data
transmitted.

Windows Server 2016 Remote Desktop Services best practices

For the Windows Server 2016 environment you can implement the below best practices for Remote Desktop
Services
• Use Multi-Factor Authentication
Leverage the power of Active Directory with Multi-Factor Authentication to enforce high security protection.
Refer to the Microsoft documentation here: https://docs.microsoft.com/en-us/windows-server/remote/
remote-desktop-services/rds-plan-mfa
• Secure data storage with User Profile Disks (UPDs)
User Profile Disks (UPDs) allow user data, customizations, and application settings to follow a user within a
single collection. A UPD is a per-user, per-collection VHD file saved in a central share that is mounted to a
user’s session when they sign in - the UPD is treated as a local drive for the duration of that session. Refer to
the Microsoft documentation here: https://docs.microsoft.com/en-us/windows-server/remote/remote-
desktop-services/rds-plan-secure-data-storage

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 12
Chapter 2

Distribute applications

Distributed applications typically have a central development station, central data storage, and client stations.
You use InTouch Network Application Development (NAD) to build and maintain distributed applications. NAD
allows many client stations to maintain a copy of a single application without restricting the development of that
application. Using an individual copy of the application provides Viewer redundancy. Client stations are
automatically notified when the application changes. You can create single computer, client-based, and server-
based InTouch applications.
You can also manage and deploy InTouch applications using the System Platform IDE.

Supported InTouch architectures

Supported InTouch network architectures are:
• Single computer
• Client-based
• Server-based
• NAD

Single computer architecture

A single computer application typically consists of one non-networked computer that functions as the primary
operator interface. This computer is connected to the industrial process with a direct connection, such as a serial
cable.
In this architecture, you develop the InTouch application on the single computer. You can copy the application to
another computer to modify it and then copy it back to the original computer.
Development and View Node

InTouch Process
App. serial connection

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 13
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Client-based architecture
In a client-based architecture, there is a unique copy of one InTouch application for each computer running
WindowViewer (View node) or in a unique location on a network server. In the following example, an application
is developed and tested on the development node and then copied to each View node.
Development Node View Node 1 View Node 2

InTouch InTouch InTouch

App. App. App. Process

Network

There is inherent redundancy because each node can be self-sufficient, and there is no limit to the number of
View nodes you can use.
Each View node must have an identical copy of the application and identical access to any network data sources,
such as I/O Servers or the IndustrialSQL Server. However, each View node maintains a separate conversation with
the shared server, which can result in increased network loading.
You can modify and test the application on the development node without affecting the running process.
However, you must distribute the modified application to the View nodes. You must shut down each View node
locally, copy the new application to it, and then restart.

Server-based architecture
A server-based architecture distributes a common InTouch application to several View nodes. In the following
figure, two View nodes access the same application from the development node.
Development Node
View Node 1 View Node 2

InTouch
App. Process

Network

For each View node:

• A logical drive must be mapped to the shared network drive of the development node.
• The shared application must be registered with the InTouch program.
• The computer must have identical access to any data sources referred to by the application. There are also
ways to define the data source locations by using a combination of scripts to identify the node name and
change each data location based on that name.
In this architecture, there is a single application to maintain. View nodes are automatically updated when the
application changes and WindowViewer restarts.
Disadvantages of this architecture are:
• Development of application is restricted
• No redundancy if the development node goes down
• All nodes must have the same screen resolution

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 14
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Network Application Development (NAD)

In the Network Application Development (NAD) architecture, you maintain a master copy of an application on a
central network location, which is usually the development node. Each View node copies the application to a
user-defined location and runs it.
When you notify clients of application changes (using the Notify Clients command on the WindowMaker Special
menu), a flag is set in the application directory, which is then read by the View nodes.
You can configure how you want application changes handled for the View nodes. These range from ignoring the
changes to automatically shutting down and restarting the View node, which reloads the master application.
In the following figure, the two View nodes have the master application registered from the development node,
but actually run it locally on their computers.
Development Node View Node 1 View Node 2

InTouch InTouch InTouch

App. App. App. Process

Network

Note: If you configure your application to write historical data to the master application node's application
directory, all NAD nodes attempt to write their historical data to the master application. To avoid this, on each
NAD node, configure historical data to write to a local directory, not the master application node.
If you are distributing a large, complex application to numerous nodes, slow system response time may be
apparent on the initial download. Updates, however, are optimized. Application transfer may be a problem for
slow networks or over serial connections.
Also, be aware of other network constraints, such as the user of routers that filter out certain types of network
traffic and addresses.

Plan networked applications

Regardless of the architecture you choose when building your InTouch application, it is important to consider:
• Access to I/O data sources.
• Access to shared files.
• Where data is logged.
• Any special network requirements.

I/O data access for networked applications

The InTouch HMI uses Access Names to reference real-time I/O data. Each Access Name equates to an I/O
address, which consists of a node name, an application, and a topic. In a distributed application, I/O references
can be set as global addresses to a network I/O Server or local addresses to a local I/O Server.
Note: InTouchView is restricted to the single Galaxy Access Name. You cannot create other Access Names for
InTouchView. For more information about the restrictions of InTouchView, see Viewing Applications at Run Time.
The View node must have the same access to data sources as the development node.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 15
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Use global I/O addresses

Global addresses to I/O data allow all View nodes to share a common network-based I/O Server. This eliminates
the need for multiple I/O Servers, but is less fault-tolerant and can result in lower overall performance.
In the following figure, two View nodes are running a copy of the same application. Both View nodes refer to the
same I/O data source. Because each application uses a fully qualified I/O address for the data source, all
references point to the same I/O Server.
View Node 1 View Node 2 DAServer “DAS1”

Process

Network

Network

You can set up an InTouch application to identify an element of data stored on another node by using a three-
part addressing convention in an Access Name. The Access Name addressing convention includes the node
name, application name, and topic name where the remote data is located. An InTouch application obtains
remote data using the Access Name in combination with an item name. For more information about defining an
Access Name for a remote I/O Server, see Data Access with I/O in AVEVA™ InTouch HMI Application Development
Guide.
Note: When you create Access Names in WindowMaker, if the Access Name uses the SuiteLink protocol, the
software prevents Access Names from accessing the same node, application and topic. Do not use the
IOSetAccessName() function to redirect Access Names to duplicate ones during run time or else the redirected
Access Name will not work.

Use local I/O addresses

Local addresses to I/O data are used when each View node has its own I/O Server. This architecture provides
fault-tolerant operation, as each View node can continue to run independently if the network goes down.
In the following figure, two View nodes run copies of the same application that refer to their own I/O data
source. Because each application uses a local I/O address for the data source, each reference points to the local
I/O Server.
View Node 1 View Node 2 View Node 3

Process
Network

Network

Using a local I/O Server significantly increases the load on the process connection network. For example, three
nodes triples the traffic created by one node, as each node's requests must be separately processed.
For more information about defining an Access Name for a local I/O Server, see Data Access with I/O in AVEVA™
InTouch HMI Application Development Guide.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 16
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

SuiteLink
The SuiteLink communications protocol is based on the TCP/IP protocol. Use SuiteLink for your high-speed
industrial applications, as it provides these features:
• Value Time Quality (VTQ), in which a timestamp and quality indicator are associated with all data values
delivered to VTQ-aware clients. The InTouch HMI is a VTQ-aware client whose tag data is delivered with a
VTQ indicator.
• Extensive diagnostics of the data throughput, the server loading, computer resource consumption, and
network transport are made accessible through the Microsoft Windows operating system performance
monitor.
• Consistent high data volumes can be maintained between applications regardless if the applications are on a
single node or distributed over a large number of nodes.
SuiteLink is not a replacement for DDE, FastDDE, or NetDDE. Each connection between a client and a server
depends on your network requirements.

Access to shared files

In a distributed application, file references can be set up as
• Global addresses to a network file server.
• Local addresses to local files.
The View node must have the same access to data sources as the development node.

Use global addresses to file data

You can set up global addresses to file data so that all View nodes share a common network-based set of files.
This provides single-source maintenance of the files, but it is less fault-tolerant than local copies.
In the following figure, two View nodes are each running a copy of the same application, but reference the same
recipe file. Because each application uses a drive letter mapped to a fully-qualified network path for the file, all
references point to the same file.
View Node 1 View Node 2 FileServer “Moo”

Network

Set up a shared file

1. Map a network drive to the shared path containing the referenced files. For example,
G:\Directory\Recipe.csv, where "G:\" is the mapped drive letter that refers to \\Moo\Share. You must map
this same drive on every View node.
2. In scripts, reference the shared path. For example:
RecipeSelectRecipe("G:\Directory\Recipe.csv", "review", "RecipeName");

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 17
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Use local addresses to file data

You can use local addresses to file data when each View node has its own copy of the file. In the following figure,
three View nodes are each running a copy of the same application and reference the local copy of a recipe file.
View Node 1 View Node 2 View Node 3

Network

In this example, the local address is:

C:\Directory\Recipe.csv
where "C:\" is the local drive.
In scripts, reference the local path. For example:
RecipeSelectRecipe("C:\Directory\Recipe.csv", "review", "RecipeName");
This architecture is fault-tolerant. However, you must copy any file changes to all the View nodes.
Any file access should be "Read Only" and modification to the local file should not be permitted.

Access to shared files through UNC

You can use a Universal Naming Convention (UNC) address anywhere that you would normally enter a file path,
such as for application directory entries, configuration items, and distributed alarms. If you use UNC names, you
do not need to create mapped drives.
A UNC address is in the form of \\Node\Share\Path, where:
• Node is the name of the computer that contains the file share.
• Share is the logical name assigned to the shared folder on that computer.
• Path is the normal path to that file with respect to the share.
Note: If you are using SuiteLink, the node name is limited to 15 characters.
Before you can access a file through UNC, you must create a file share on the computer you want to access. For
more information, see your Windows documentation.
For example, assume that you have a computer with the network name of "EngineRm" that you have shared the
root drive "C:\" with the share name of "Root". To set up a UNC path to the "C:\IT\Apps\Boiler" application you
must use the following UNC:
\\EngineRm\Root\IT\Apps\Boiler
If the "Boiler" directory itself was shared as "Boiler," the UNC could be shortened to:
\\EnginerRm\Boiler
No path is required if the share is a path specified in the PATH environment variable.
Note: If you need to write to a file referred to by a UNC address, the share must be a read/write share, even on a
local node. If you create a share that is password-protected, you will not be able to access the share with a UNC
unless you first set up a network drive mapping. You can set up a drive mapping from the remote node by using
Windows Explorer.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 18
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Log data in a distributed environment

You can use the InTouch distributed history system to retrieve historical data from any InTouch application on the
network. This system also allows for remote retrieval of data from multiple history databases simultaneously.
These databases are called history providers.
Only one InTouch node can log to a distributed history file. However, an unlimited number of InTouch nodes can
view the contents of the file.
View Node View Node View Node View Node

Retrieve Retrieve Retrieve Retrieve

Log/Retrieve

History File History File

Log/Retrieve

View Node (Logger)

A remote node retrieving data from a history file may not see data for the last hour of data (based on the logger
node's time). Remote trends can only view data that has been written to the logging node's disk.
Data for each tag checked for 'Log Data' is automatically written to disk after 22 samples for that tag have been
collected. If the HTUpdateToCurrentTime() function is called, data is written to disk regardless of the number of
samples collected. By default, data is written to disk once an hour. You can change this interval by adding the
following line to the INTOUCH.ini file:
ForceLogging=X;
Where X is minutes and can be set to any interval between 5 and 120.
Note: The NetDDE Helper service must be running when you use the distributed history system.
The following figure shows the configuration of a typical distributed history system using Network Application
Development (NAD) to distribute the application.
Node 1 Node 2

Node3

Log/Retrieve Retrieve
Retrieve Retrieve
Log/Retrieve

Remote
Local
History File
History File
(HistPrv1)

Nodes 1 and 2 contain copies of the same InTouch application; however, the application is configured to allow
only Node 1 to log to a local history file, whereas either node can retrieve from the local history file or the
remote history file. Node 3 is also logging to and retrieving from the remote history file location. Node 3, the
history provider, is assigned the name HistPrv1. Node 1 is both a development and run-time station, while Node
2 is just a run-time station.
Create this type of application
1. Create a history provider list. See Configure remote history providers.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 19
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

2. Create and configure a historical trend object. For more information, see Trending Tag Data in AVEVA™
InTouch HMI Application Development Guide.
3. Configure the application for distributed logging. See Configure distributed historical logging.
4. Distribute the application. See Configure an InTouch application for NAD.
You can distribute your application manually or by using NAD. When you distribute your application, the
historical provider list file is distributed as part of the application.
After you have distributed your application, you can run the View nodes and retrieve both local tags and tags
from a remote history provider. While the application runs on all the View nodes, only the logging node logs to
the historical log file; other nodes can only read from it.

Configure remote history providers

You must specify a name and network location for each remote history provider that you want to use with the
InTouch HMI. You can use either a remote InTouch history provider or a remote IndustrialSQL Server history
provider.
Note: A remote history provider cannot be configured for an InTouchView application. For more information
about the limitations of InTouchView applications, see About InTouchView Applications.
While the local InTouch application is considered a history provider, you do not need to define it for your
application.
If you reference an undefined history provider in an application, WindowViewer ignores the reference and an
error message is written to the Logger.
The HistData utility cannot retrieve historical information from a Historian provider.
Configure a history provider
1. Open WindowMaker.
2. On the File menu, select Configure, and then select Distributed Name Manager.
The Distributed Name Manager configuration screen appears, with separate tabs for the Distributed Alarms
and the Distributed History.
3. On the Distributed History tab, select the + icon to add a history provider, or press Alt+A.
The Add history provider dialog appears.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 20
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

4. In the Provider name box, type the name you want to use for the new historical provider.
A provider name can be 16 alphanumeric characters or fewer.
5. Configure an InTouch history provider
a. Select InTouch provider.
b. In the UNC name box, type the UNC path to the InTouch application directory and then select Add.
The UNC path format is:
\\node_name\volume_name\directory\
If the UNC location is password-protected, you must first establish a node connection using Windows
Explorer.
6. Configure an AVEVA history provider
a. Select Historian.
b. In the Data source box, type the node name of the server where the Historian Server is installed.
c. From the Credentials drop-down list, select the credentials for authentication.
Note: For standalone InTouch applications, the credentials are retrieved from the Application Manager. For
managed InTouch applications, the credentials are retrieved from the Credential Manager of the Application
Server. For more information, see Work with Credential Manager in the AVEVA™ InTouch HMI Application
Development Guide.
7. Select Test connection to verify the connection to the Historian Server database. A message appears
indicating whether the connection to the database is successful or not.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 21
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

8. Select Add to close the dialog box.

The Historian Server node appears in the History Providers list.

Dynamically configure remote history providers

At run time, you can also dynamically configure a historical trend's remote history provider by creating a script
that specifies the remote history provider tag references in the HTSetPenName() function. For example:
HTSetPenName("HistTrendTag", 1, "HistPrv1.Boiler1");
Where a 1 specifies the trend pen that plots the specified remote history provider tag.
The run-time Historical Trend Setup dialog box and .Pen dotfield are not supported for remote history providers.

Configure distributed historical logging

Only one InTouch node can log to the history file. However, multiple InTouch nodes can view the file.
Note: Historical logging cannot be configured for an InTouchView application. For more information about the
limitations of InTouchView applications, see About InTouchView Applications.
Configure distributed historical logging
1. On the File menu, select Configure, and then select Historical Logging.
The Historical Logging configuration screen appears.

2. Select the Enable historical logging check box to turn on global tag logging.
3. Select Store Log Files in Specific Directory, and then in the input box, type the path of the location where
the log files are stored.
You must type a valid Universal Naming Convention (UNC) path. For example, \\Node\Share\Path
If you are using NAD, make sure the path points to a folder other than the application folder.
4. In the Name of Logging Node box, type the name of the node that will be logging to the history log file.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 22
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

This setting only allows the node named here to log to the file.
5. Select OK.
Note: When an application with the Enable Historical Logging option selected is distributed to a WindowViewer
node, that node checks this option to determine if it should log or not. If Enable Historical Logging is selected,
the possible settings are: Field equals name of Node - Logging enabled Field does not equal name of Node -
Logging disabled.

Considerations for special networks

If you are working on a slow network and the InTouch HMI takes a long time to start or save information, modify
the win.ini settings on the NAD client:
ViewNadClearNADCopyDirectory=0
ViewNADCopyApplicationOnStartup=1
ViewNADOnApplicationChanged=3 ( or 4)
ViewNADThreadPriority=2
For the ViewNADOnApplicationChanged parameter, a setting of 3 corresponds to the Load changes into
WindowViewer option on the Node Properties dialog box in the InTouch Application Manager. A setting of 4
corresponds to the Prompt user to load changes into WindowViewer option. These settings allow the
application to continue to run while NAD downloads take place in parallel, on a separate execution thread.
When NAD performs an update to an application, it copies only the changed files from the master. NAD does not
copy the SmartSymbol design-time dictionary files for run-time language switching.

Configure an InTouch application for NAD

Network Application Development or NAD is an architecture that combines the best of the client-based and
server-based architectures. NAD provides automatic notification of application changes and can automatically
distribute updated applications to View nodes
When configuring an application for NAD, you must specify the folder that you want WindowViewer to copy the
master application to.
• If this is the development node, you can type a local folder path, such as c:\InTouch\NAD. You can also type a
networked remote UNC path, such as \\node\share\path. This is convenient for file server-based networks
where most file storage is kept in a central location.
• If this is a client node (run-time only), you typically use a local folder path.
We recommend that you use a local folder whenever possible to prevent network delays and failures from
affecting the operation of WindowViewer.
Caution: Do not use a root folder or a UNC pathname that points to a root folder. The View node recursively
deletes all files and subfolders in the specified destination application folder before copying the master
application directory. Therefore, never use the path of the master application folder or a UNC to the master
application folder.
If you do not specify a folder, WindowViewer automatically creates a local subfolder named NAD in the folder
from which WindowViewer is launched. The NAD folder should be considered a temporary folder and no other
files should be saved to it except those copied by NAD itself.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 23
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Configure an application for NAD

1. Start Application Manager.
2. On the Tools tab, select Node Properties.
The Node Properties screen appears.

3. Select the Enable Network Application Development radio button.

4. In the Local working directory box, type the path to the folder that you want WindowViewer to copy the
master application.
5. In the Polling period (sec) box, type the interval, in seconds, at which the View node checks the
development node for updates.
• Be careful that you do not set this value too small. If WindowViewer checks for master application
changes too often, it can interfere with servicing the running application.
6. In the Change Mode area, select the option that determines the action WindowViewer takes when the
master application changes.
• Select Ignore changes to have the WindowViewer node ignore any changes made on the development
node.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 24
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

• Select Restart WindowViewer to have the WindowViewer node copy over the updated master
application (if configured to do so) and then restart itself.
• Select Prompt user to Restart WindowViewer to show the operator a message that the application has
changed. The operator can either restart WindowViewer with the application updates or continue using
the current application.
• Select Load Changes into WindowViewer to dynamically load in WindowViewer the changes made in
the development node. This may affect performance for large updates.
Note: It is recommended that you use the Load Changes into WindowViewer option only if the application
changes are minor and few in number. Examples of minor changes include changes made within an existing
window, resizing of graphic toolbar elements, adding new graphic toolbar elements, and reference
substitutions. When making changes that require that WindowViewer be restarted, such as adding new tags,
adding new windows, or changing the configuration—or if in doubt—use one of the Restart options instead.
• Select Prompt user to load changes into WindowViewer to show the operator a message that the
application has changed. The message prompts the operator to load the changes.
7. Select OK.

Perform an automatic NAD update

You can start an automatic NAD update during application development.
When you run the Notify Clients command, a flag is set to notify all remote View nodes that the master
application has changed. Clients can automatically start an update process based on the Change Mode option
defined for each node.
The first time a standalone application (with embedded Industrial graphics) is opened on a View node, graphics
may not appear and errors are logged in the Logger. To avoid this, run the Notify Clients command from the
master node and the Industrial graphics will be loaded on the View node based on the Change Mode option.
Perform an automatic update
1. Open the application in WindowMaker.
2. On the Properties menu, in the Clients group:
a. Select Notify now to notify clients immediately.
b. Select Notify on-close, to be reminded to notify NAD clients, when WindowMaker is closed.
Note: If the Notify on close option is selected, every time WindowMaker is closed it will verify if there are any
changes from the last notification. If there are any changes, a dialog box with the prompt ‘Do you want to notify
the NAD clients?’ will appear. Select Yes to notify the clients, select No to ignore the changes.

Perform a manual NAD update

You can write scripts that allow operators to manually start a NAD update on the View nodes in which they work.
To manually update an application with NAD, you must set the Change Mode option to Ignore Changes in the
Node Properties dialog box. For more information, see Configure an InTouch application for NAD.
Use the following system tags and functions in your script to perform a manual NAD update:
• $ApplicationChanged System Tag

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 25
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

• $ApplicationVersion System Tag

• RestartWindowViewer() Function
• ReloadWindowViewer() Function

$ApplicationChanged system tag

Signals that the master application has changed in a Network Application Development (NAD) architecture.
Category
application
Usage
$ApplicationChanged
Remarks
This system tag changes to 1 every time the update signal is generated by selecting Notify Clients on the
WindowMaker Special menu. $ApplicationChanged is reset to 0 when the application is updated. This tag can be
used to generate a message that informs the operator that the master application has changed.
You can also use the $ApplicationChanged system tag in a data change script to build a node update notification
script. This script can launch your own dialog boxes or stop running processes. Then, you could use the
ReloadWindowViewer() function to start the update process.
Data Type
Discrete (read only)
Example
Using the following statement in the tagname box of a data change script causes the body of the script to run.
The script body could show a window informing the user to restart WindowViewer for the change to take effect.
$ApplicationChanged
See Also
$ApplicationVersion

$ApplicationVersion system tag

Contains the current version number of the application. This number changes with every change that can be
saved or undone.
Category
application
Usage
$ApplicationVersion
Remarks
The value associated with the $ApplicationVersion system tag is set to the current version of the InTouch
application. The version changes with every change to the application that can be saved or undone. This tag can
be used to generate a message that informs the operator that the master application has changed.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 26
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Data Type
Real (read only)
Example
If used in an analog display link, this system tag shows the current version of the application that is running
within WindowViewer.
$ApplicationVersion
See Also
$ApplicationChanged

RestartWindowViewer() function
Shuts down WindowViewer, copies the updated master application (if configured to do so), and then restarts
WindowViewer.
Category
system
Syntax
RestartWindowViewer();
Remarks
This function is used to update an application when the automatic update Network Application Development
(NAD) functions are not used.
Use the $ApplicationChanged system tag to determine when a NAD update has occurred.
You use the Notify Clients command to initiate a NAD update. However, the operator may want to delay the
update until a later time. You can use this function with a button action script so that the operator can restart
WindowViewer when it is convenient.
You could instead use the ReloadWindowViewer() function, which updates the View node without shutting down
WindowViewer.
See Also
$ApplicationChanged, ReloadWindowViewer()

ReloadWindowViewer() function
Dynamically updates WindowViewer with the updated master NAD application without any interruption in
service.
Category
system
Syntax
ReloadWindowViewer();
Allows the user control over reloading WindowViewer.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 27
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Remarks
Use this function to update an application when the automatic update Network Application Development (NAD)
functions are not used.
Use the $ApplicationChanged system tag to determine when a NAD update has occurred.
You use the Notify Clients command to initiate a NAD update. However, the operator may want to delay the
update until a later time. You can use this function with a button action script so that the operator can reload the
application in WindowViewer when it is convenient.
See Also
$ApplicationChanged

Application editing locks

To prevent multiple developers from trying to edit an application, WindowMaker locks an application during the
edit session. If you try to open a locked application, an error message is shown. The name of the node editing
the application is included in the message.
If WindowMaker is abnormally shut down with an application loaded, the appedit.lok file may not be deleted.
You can manually remove the lock by deleting the appedit.lok file from the application directory.

Changes to an application during a NAD update

When the WindowViewer node updates an application, it makes every attempt to retain the attributes (read-
only, system, hidden, and so on) of the master application during the copy process.
WindowViewer also copies all files and subfolders of the master application, except for these files: *.WVW,
*.DAT, *.LGH, *.IDX, *.LOG, *.LOK, *.FSM, *.STG, *.DBK, *.CBK, *.HBK, *.KBK, *.LBK, *.NBK, *.OBK, *.TBK, *.WBK,
*.XBK, *.$$$, RETENTIV.X, RETENTIV.D, RETENTIV.A, RETENTIV.S, RETENTIV.H, RETENTIV.T, SSD_, WM.INI, DB.INI,
LINKDEFS.INI, TBOX.INI, GROUP.DEF, and ITOCX.CFG.
Note: WindowViewer recursively deletes all files and sub folders in the destination application folder except
those required for run-time language switching. This folder should be considered a temporary folder. No other
files should be placed in it.
The NAD client starts an update by creating a local list of files and sub-directories that appear in the client
application directory. As it looks for updates in the list of master files, the NAD client removes the corresponding
client file for each master file from the local list. The remaining entries in the local list are obsolete files and sub-
directories that should be deleted from the application.
All downloaded files are copied to a temporary sub-directory called NAD_Temp. Files are only copied from
NAD_Temp to the application directory if all of the new and updated files are copied successfully within the re-
try limits. If the NAD client has to abandon an update, the running application is not corrupted by the partial
introduction of new or updated files.
If contact with the NAD master fails after all new and updated files have been downloaded, the update can still
be completed by copying the updates from NAD_Temp and deleting the obsolete files. This ensures that files are
not erased simply because a lost connection makes it impossible to confirm their existence on the master
application.
NAD can detect whether additional changes have been made to the master application during application
download. If such a situation arises, NAD abandons the download of the application. If you run the Notify Clients

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 28
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

command after the latest update, NAD automatically begins downloading the latest application files at the next
polling period. Otherwise, it waits until the next Notify Clients command issued before an application download
takes place.

Scale the application resolution at run time

You can use Dynamic Resolution Conversion (DRC) so that the distributed applications you create can run on
different screen resolutions.
Each View node can scale the application appropriately, including scaling to a custom resolution. This scaling
takes place while WindowViewer compiles the application and does not require WindowMaker. Because each
View node can use a different DRC setting, each View node must have its own settings configured.
Caution: If you do not use DRC to scale the application, WindowViewer only runs the application if the node's
screen resolution is identical to the screen resolution of the application development node. If the resolutions are
different, WindowViewer prompts the operator to run WindowMaker to convert the application to the node's
resolution. Use caution when doing this if you have set up a UNC path to the master application directory, as this
will only modify the original application.
Configure an application for DRC
1. Start Application Manager.
2. On the Tools menu, select Node Properties. The Node Properties dialog box appears.
3. Select the Resolution tab.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 29
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

4. Select the Allow WindowViewer to dynamically change resolution check box if you want WindowViewer to
locally scale the master application.
5. In the Dynamic Resolution area, select one of the following:
• Select Use application resolution if you want WindowViewer to run the application at the resolution it
was developed for and ignore the node's resolution. For example, if the application was developed at
800x600 and the node's resolution is 1024x768, WindowViewer does not dynamically scale the
application. Instead, the application resolution remains at 800x600.
• Select Convert to screen video resolution if you want WindowViewer to run the application at the
node's resolution and ignore the resolution the application was developed at. For example, if the node is
running at 800x600 and the application was developed at 1280x1024, WindowViewer dynamically scales
the application to fit the node's 800x600 resolution.
• If the target resolution is different from the screen resolution when the application was created,
then WindowViewer will scale to the current screen resolution from the original application
resolution instead. The original application resolution is the screen resolution when the application
was created regardless of the target resolution settings. For example, if the application was
developed at 1920x1080 with a target resolution of 1280x1024 and the view node is running the
application at resolution of 800x600, WindowViewer will dynamically scale the application to use the
original application resolution of 1920x1080. For more information, see Original Application
Resolution.
• Select Custom resolution if you want WindowViewer to run the application at a specific resolution you
specify in the Width (X) and Height (Y) (must be integer values) boxes. The application's resolution and
the node's resolution are both ignored. For example, if Width (X) and Height (Y) are set to 512 and 384,
respectively, the application is dynamically scaled to fit in a 512x384-pixel area on the node's screen.
• If the target resolution is different from the screen resolution when the application was created,
then WindowViewer will scale to the current screen resolution from the original application
resolution instead. The original application resolution is the screen resolution when the application
was created regardless of the target resolution settings.
6. Select OK.

Lock the application resolution

You can configure the WindowMaker properties to lock the size of InTouch application windows. This allows you
to convert applications to a different resolution without scaling the windows and graphics.
If you select this option, the next time you open an application in a computer with a different resolution, the
system prompts you to specify whether you want to convert the application to the new resolution without
scaling the windows and graphic.
You can lock the application resolution from inside WindowMaker or from the Application Manager.
Lock the application resolution from WindowMaker
1. Open WindowMaker.
2. On the File menu, point to Configure, and then select WindowMaker.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 30
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

The WindowMaker configuration screen appears.

3. Select the Lock Window Size check box. By default, the check box is not selected.
4. Select Save.
Lock the application resolution from Application Manager
1. Open Application Manager.
2. Select the application you want to configure.
3. Select File on the menu bar, then select Properties.
The Properties dialog box appears.
4. Select the Lock Window Size switch. By default, the check box is not selected.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 31
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

5. Select OK.

Publish applications to remote nodes

Using Application Publisher, you can create a compressed, self-extracting package file that contains all relevant
files and setup procedures to install an InTouch application on another computer. You use Application Publisher
to publish standalone InTouch applications. You publish managed InTouch applications using the System Platform
IDE.
You have two options to publish applications:
• Run-time only. A run-time only package includes the files needed to run the application, but not to edit the
application.
• Design-time and run-time. A design-time and run-time package includes all files needed to edit and run the
application. Some run-time files, such as compiled *.wvw files, are excluded because they can be re-created
from the design-time files.
You can post published applications to a web server where they can be downloaded and installed. The following
package information is shown for posted applications:
• Package description
• Publisher name

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 32
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

• Published file name (executable)

• Application resolution
For example:
Description Dairy Processing Application
Publisher Navin Johnson
File Name Dairy.exe / Video Resolution…(1024x768)

Description Dairy Processing Application

Publisher Navin Johnson
File Name Dairy_2.exe / Video Resolution…(800x600)

Contents of a published file

The following table lists the included folders, files, and excluded files for all published stand-alone InTouch
applications.

Included Folders Included Files Excluded Files

Main application folder All Backup files. These files have

the .?bk file name extension.
Files with these extensions: Subfolders not in the Special
Directories list
.win, .dat, .lgh, .idx, .log, .fsm, .stg
, .$$$
retentiv.x The appedit.lok file, which
indicates that the application is
retentiv.d
open in WindowMaker.
retentiv.a
retentiv..s (two dots)
retentiv.h
wm.ini
db.ini
linkdefs.ini
tbox.ini
group.def
itocx.cfg
Any files with names of the form Compiled window files with the
SSD_*.xml. file name extension .wvw.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 33
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Included Folders Included Files Excluded Files

Dictionary subfolders for All files with the .xml extension.

run-time language switching

Symbol subfolders All files and subfolders.

wiz.ini file, if there are wizards
installed.
Copy of the wizard executable.
.dll files,
.wdo files
.wdf files
For a run-time only application, all files with a file names of SSD_*.xml are excluded.

Publish a standalone InTouch application

Use the Application Publisher to publish a standalone InTouch application. If you want the published application
to run at a specific screen resolution, set the original application to that resolution before you publish it. To
publish a managed InTouch application, use the System Platform IDE.
Publish a standalone InTouch application
1. Start the Application Publisher.
a. Open WindowMaker.
b. Expand the Tools pane, and expand Applications.
c. Double-click Application Publisher.
The InTouch Application Publisher – Step 1 of 4 dialog box appears.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 34
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

2. Select Next. The InTouch Application Publisher – Step 2 of 4 dialog box appears.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 35
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

1. Configure the package details.

• In the Enter author name box, type the name of the person to contact regarding the application. The
name limit is 256 characters.
• In the Description box, type a description of the application. The limit is 256 characters.
• In the Package Name box, type a unique name for the published application package. The limit is 32
characters. If you use the name of an existing package, the existing package is overwritten.
2. Select Next. The InTouch Application Publisher – Step 3 of 4 dialog box appears.

3. Configure the publishing details.

• In the box, type the path to the InTouch application folder. The default path is the WindowMaker
application folder.
• Select the Runtime only check box to exclude the development WindowMaker files in the published file.
4. Select Next. The InTouch Application Publisher – Step 4 of 4 dialog box appears.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 36
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

5. Configure the details for the executable application package.

• In the first box, verify the executable name in the first box is correct. By default, the executable name is
the same as the package name.
• In the second box, type the path to the folder in which to save the executable file, or select Browse to
select a different folder. By default, the executable is saved in your current temporary folder.
6. Select Finish.

Publish managed InTouch applications

You can publish a managed InTouch application. The published InTouch application is no longer associated with
the InTouchViewApp template.
The published application cannot be edited within the IDE or imported into another InTouchViewApp template.
In other words, you cannot manage it with the IDE or republish it.
The published InTouch application can still communicate with the Galaxy through any embedded Industrial
graphic. You can, for example, write data back to the Galaxy or visualize Galaxy data.
You can edit the Industrial graphic using basic InTouch operations such as copying, cutting, pasting, duplicating,
moving, resizing, flipping, rotating, and configuring with InTouch animation links.
However, the Industrial graphics cannot be modified, nor can new Industrial graphics be embedded into the
InTouch application. These operations are only allowed with managed InTouch applications.
You can do this in environments that do not support the processing requirements of ArchestrA. For example, in
remote plant operations or in small networks.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 37
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Publish a managed InTouch application

You can publish a managed InTouch application from the InTouchViewApp object that is associated with it.
The export consists of a folder containing information about the object and the managed InTouch application.
This is different than exporting the InTouchViewApp object itself. For more information, see Importing and
Exporting an InTouchViewApp Object.
The published InTouch application cannot be reimported into an InTouchViewApp object. A published InTouch
application cannot be edited.
Publish a managed InTouch application
1. Open the System Platform IDE.
2. Locate the InTouchViewApp object that contains the managed InTouch application you want to publish.
3. Right-click the object, and then select Publish InTouch Application. The Browse For Folder dialog box
appears.

4. Specify the folder to publish to the InTouch application to. Do any of the following:
• Browse to an existing folder.
• Select Make New Folder to create a new folder or folder structure.
5. Select OK. The Publish InTouch Application progress dialog box appears.

6. When publishing is complete, select Close. A directory containing the new published InTouch application is
created in the selected folder. You can now copy it to any run-time node.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 38
 AVEVA™ InTouch HMI
Chapter 2 – Distribute applications

Publish applications to Insight

Using the Insight Publisher you can publish an application to the Insight website. You can use the Application
Manager or WindowMaker.
Publish applications to Insight
1. Open Application Manager.
2. On the Tools menu, in the Tools group, select Insight Manager.
The Insight Publisher window appears.
InTouch WindowMaker, you can use the AVEVA Insight Publisher from the Tools pane under Applications.
You can select one of the following options and proceed with the onscreen instructions.
• Publish - Create a new Insight data source from an existing InTouch application.
• Import - Import an Excel spreadsheet listing items from an OPC, MQTT, or OI Server.
• Authorize - Create a data source.
For more information, refer to the Historian Documentation.
Note: You will need an Insight Account to publish the application.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 39
Chapter 3

Use managed InTouch applications at

run time

You can run managed InTouch applications on remote nodes by deploying InTouchViewApp instances to those
nodes.
You can also deploy changes of the InTouch application and contained Industrial Graphics to these nodes and
select whether to accept or decline the changes for each node.
The following graphic shows how managed InTouch applications are deployed to run-time nodes.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 40
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

Deploy a managed InTouch application

You can deploy a managed InTouch application from the System Platform IDE to the local node or a remote node.
After you deploy the application, you can run it in WindowViewer on the remote nodes.
Note: WindowViewer can run only one application at a time. If a platform is deployed on a local node, the
configured styles of the Galaxy will take precedence over any configured styles in any other standalone or
managed applications.

Deploy a InTouchViewApp object for the first time

The first time you deploy an InTouchViewApp object, the associated InTouch application is copied to the node of
the platform that hosts the object. This is called the operator node.
Deploy a managed InTouch application
1. Open the System Platform IDE.
2. Select the instance of the InTouchViewApp for which you want to deploy the managed InTouch application.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 41
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

3. On the Object menu, select Deploy. The Deploy dialog box appears.
4. Select OK. The complete InTouch application is copied to the operator node.

Deploy changes to a managed InTouch application

Note: The Override WindowViewer default configurations option has not been tested on a non-English
language Operating System. Web Client does not support this option.
You can change a managed InTouch application by:
• Changing the references, content, or size of an Industrial Graphic that is used in a managed InTouch
application.
• Changing the managed InTouch application itself by opening WindowMaker from the InTouchViewApp
template.
In both cases, when you save the changes, the changes are propagated from the updated template to the
derived instances. The changes are identified by the Pending Changes icon.
The changes are not immediately reflected in a running WindowViewer session. The operator of each node can
select to accept or decline the changes. For more information, see Accept new application versions at the
operator node.
To deploy changes to a managed InTouch application
1. Open the System Platform IDE.
2. Select the instance of the InTouchViewApp for which you want to deploy the changes of a managed InTouch
application.
3. On the Object menu, select Deploy. The Deploy dialog box appears.
4. Select OK. The changes are copied to the operator node.

Start a managed InTouch application

From the operator node, you can start Application Manager and select the managed InTouch application you
want to run.
You can also set the resolution in Application Manager to run the managed InTouch application in different
resolutions.
Start the managed InTouch application
1. On the node the InTouchViewApp object is deployed to, start the InTouch Application Manager.
2. In the application list, select the managed InTouch application you want to run in WindowViewer.
3. Select the WindowViewer icon. The application starts in WindowViewer after a short while.
Set the dynamic resolution conversion settings
1. Open the InTouch Application Manager.
2. On the Tools menu, select Node Properties. The Node Properties dialog box appears.
3. Select the Resolution tab.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 42
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

4. Select the Allow WindowViewer to dynamically change resolution check box.

If Allow WindowViewer to dynamically change resolution is unchecked, the managed application runs with
the resolution in which it was developed.
5. Configure how you want to run the application. Do any of the following:
• Select Use application resolution to run the managed application at the same resolution as it was
developed in.
• Select Convert to screen video resolution to convert the managed application so that it can run with the
screen resolution.
• Select Custom resolution to convert the managed application to a specified resolution.
6. Select OK.

Control the WindowViewer restart wait period when deploying managed

applications
You can control the delay that occurs before WindowViewer is restarted when managed applications that require
a restart are deployed. Delays are implemented to ensure the proper operation of the alarm subsystem.
The WindowViewer restart delay is controlled by the following parameters in the win.ini file, which is located in
the local C:\Windows folder. All parameter values are in seconds.
• ViewManagedRestartWaitPeriod=0
This parameter controls the WindowViewer restart wait period. The default is 0, or no wait period.
• ViewNADShutdownWaitPeriod=30
For applications managed using Network Application Development (NAD), this parameter controls the delay
before NAD is shutdown. The default is 30 seconds.
• ViewNADRestartWaitPeriod=90
For applications managed using NAD, this parameter controls the delay before NAD is restarted. The default
is 90 seconds.

Accept new application versions at the operator node

If the managed InTouch application is changed and its associated InTouchViewApp instance is deployed, you can
select to accept or decline the changes at the run-time node.
A message appears prompting you if you want to accept the changes to the managed InTouch application:
• When you start WindowViewer from the InTouch Application Manager.
• While WindowViewer is running.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 43
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

Depending on the nature of the change, you may be prompted to restart the WindowViewer application, or just
reload it. You can also set the behavior of WindowViewer for application changes, such as:
• How WindowViewer accepts or rejects these changes.
• How frequently WindowViewer should remind you to reload or restart WindowViewer when changes are
pending.
Accept new application versions at the operator node
• Select Yes. The changes to the managed InTouch application are copied to the operator node and
WindowViewer restarts or reloads.
Set the behavior of WindowViewer for application changes
1. Open the managed InTouch application in WindowMaker.
2. On the File menu, point to Configure, and then select WindowViewer.
The WindowViewer configuration screen appears.
3. Select the Managed Application tab.

4. In the Change Mode area, configure how WindowViewer responds when changes are deployed. Do any of
the following:

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 44
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

• Select Ignore Changes to have WindowViewer ignore any deployed changes. You can manually configure
the RestartWindowViewer() and ReloadWindowViewer() script functions to accept the changes
depending on the $ApplicationChanged system tag.
• Select Restart WindowViewer to have WindowViewer restart automatically.
• Select Prompt user to restart WindowViewer to have WindowViewer prompt you to restart
WindowViewer.
• Select Load changes into WindowViewer to have WindowViewer load the changes automatically.
• Select Prompt user to load changes into WindowViewer to have WindowViewer prompt you to load
changes into WindowViewer.
Note: If you select the Load changes into.. or Prompt user to load.. options, WindowViewer must be restarted
to recognize changes to a managed application. Even with these options selected, you will be prompted to
restart WindowViewer.
1. In the Reminder Interval (sec) box, type how often, in seconds, the user is reminded to load or restart the
changes into WindowViewer. This option is only available when the applicable change mode has been set.
Set the interval to 0 to not remind the user again.
2. Select OK.
Set the default behavior for WindowViewer
1. Open the managed InTouch application in WindowMaker.
2. On the File menu, point to Configure, and then select WindowViewer. The WindowViewer configuration
screen appears.
3. Select the Managed Application tab.
4. Select Restore Defaults. The settings are reset to their default values.
5. Select OK.

Run ArchestrA scripts in embedded industrial graphics

When you run a managed InTouch application in WindowViewer, any ArchestrA scripts associated with elements
or symbol scripts themselves run as expected.
However, some scripts contained in symbols can run for a long time and stop you from interacting with other
InTouch elements.
To prevent this, you can set a script time-out that is applicable for all scripts in the managed InTouch application.
A script time out stops script execution and returns the control to the operator.
By default, scripts time out after 5 seconds.
Set the script time-out
1. Open a managed InTouch application in WindowMaker.
2. On the File menu, point to Configure, and then select WindowViewer. The WindowViewer configuration
screen appears.
3. Select the Managed Application tab.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 45
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

4. In the Script timeout (msec) box, type a value in milliseconds.

5. Select OK.

Deploy the InTouchViewApp object in a Terminal Services

environment
You can run managed InTouch applications in a Terminal Services environment. The main advantage of this
architecture is that you can run multiple InTouch applications on one computer at the same time.
Run managed InTouch applications in a Terminal Services environment
• Use InTouch Terminal Services Edition.
• Deploy each InTouchViewApp instance with its own ViewEngine host, if you have several
InTouchViewApplication instances on the terminal server node.
• Run each managed InTouch application in its own terminal services client session.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 46
 AVEVA™ InTouch HMI
Chapter 3 – Use managed InTouch applications at run time

Note: Only one InTouchViewApp object needs to be deployed on the terminal server node to make the
application available to multiple terminal session clients. There is no need to deploy a separate InTouchViewApp
object on the terminal server node for each client that will use the application.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 47
Chapter 4

Use InTouch HMI applications in AVEVA

Edge

AVEVA Edge provides users the option to deploy and reuse InTouch HMI applications. Using the Application
Manager, you can download applications to AVEVA Edge or upload them to CONNECT.
The downloaded zip files are compressed versions of InTouch HMI applications, suitable for deploying to edge
devices and containers on account of their low file sizes. The same zip can also be uploaded to CONNECT, where
it can be downloaded to other devices.
Note: If the AVEVA Edge related options are not enabled, launch WindowMaker.

Download the AVEVA Edge zip file

1. Select the application.

2. Select the icon.

A compressed (.zip) file will be prepared and ready for download.
3. Save the file.
4. Use the AVEVA Edge Management portal and Add a New Device. Upload the zip file under the Project
Configuration option.
For further deployment and pairing instructions, see the AVEVA Edge Help.
5. Users can use the InTouch HMI Web Client to verify if the application is running correctly. For more
information on the Web Client, see Viewing Application Graphics in a Web Browser.

Upload the AVEVA Edge zip file

1. Select the AVEVA button on the far right of the Application Manager window.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 48
 AVEVA™ InTouch HMI
Chapter 4 – Use InTouch HMI applications in AVEVA Edge

2. Select SIGN IN.

3. Enter your CONNECT credentials.
4. After you are logged in, select the application you want to upload.
Optionally you can change the Drive, but you cannot move applications between drives.

5. Select .
A success message is displayed after the application is uploaded to CONNECT.

The uploaded application is displayed in the application list, prefixed with Cloud | <Application Name>.
The cloud application has the following options:
• Thumbnail
• Delete
• Download
All other options are disabled.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 49
 AVEVA™ InTouch HMI
Chapter 4 – Use InTouch HMI applications in AVEVA Edge

Once the application is uploaded to the Shared Drive it is accessible to all users. Users can then download
and delete the application from the cloud store.

Configure users for Edge device

Users that need to access the InTouch Web Client from the Edge device must be configured in Application
Manager. The same users must be present in the appropriate user groups for web client. You can export or
import the user list to a csv file. The template for the file is as follows:
UserName,Password,IsWrite
TestUser,TestPass#1,1
Add Users

1. Select .
The User Information dialog box appears.
2. Enter the username and password.
3. The password must comply with the following rules:
At least 6 characters long
1 lower case character
1 upper case character
1 number
1 special character
4. Select the access type.
5. Select Save.

6. Select to add new users.

7. Select to remove users.

8. After you have configured all the users, select to export the configured list.
9. In AVEVA Edge Management, upload the list, during the ‘Add a device’ procedure under the User
Configuration option.
After the edge device is configured and paired, the list of users will be created on the edge device. These
users will be able to access the web client and view the application graphics.
Import an existing user list
If you have a list of existing users to be included, prepare a .csv file in the required format.

1. Select and provide the path to the .csv file.

2. The entries in the file will be included in the list of users.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 50
 AVEVA™ InTouch HMI
Chapter 4 – Use InTouch HMI applications in AVEVA Edge

3. Use the AVEVA Edge Management portal and Add a New Device. Upload the .csv file under the User
Configuration option.
For further deployment and pairing instructions, see the AVEVA Edge Help.

© 2015-2024 AVEVA Group Limited or its subsidiaries. All rights reserved. Page 51