Nov 2020

Workgroup Products Product Architecture 2021.1

InfoWorks ICM

ICMLive

InfoAsset Manager

InfoAsset Mobile

InfoWorks WS Pro

IWLive Pro

2

Contents

Overview ............................................................................................................................................................................................................................................................... 3

Workgroup Products Architecture - Key Components ............................................................................................................................................... 4

Key Concepts for Workgroup Clients.......................................................................................................................................................................................... 6

Typical Configurations .............................................................................................................................................................................................................................. 8

InfoWorks ICM Simulation Agent .................................................................................................................................................................................................. 12

IWLive Pro Components ....................................................................................................................................................................................................................... 15

InfoAsset Mobile .......................................................................................................................................................................................................................................... 17

3

Overview

Innovyze Workgroup products are composed of several inter-related parts. These parts may be used independently or together. The particular IT architecture that is used will depend on the needs of the organisation and its users. This document describes some of the common configurations which could be considered.

Note that while the diagrams in this document shows the separate components of the Innovyze Workgroup product, this does not imply that each component is required to be run on a separate computer. The decision on how to distribute the components across machines will depend on the particular requirements of the system.

4

Workgroup Products Architecture - Key Components

Workgroup Clients The Innovyze Workgroup Client provides the user interface for both InfoWorks ICM and InfoAsset Manager. The behaviour of the client and the data which it is able to manipulate will depend on whether the client is run in InfoWorks ICM mode or InfoAsset mode. This mode is controlled by starting the application via the appropriate shortcut under the start menu. InfoWorks WS Pro and the IWLive Operator Client are not installed as part of Innovyze Workgroup Client and are obtained independently, using their own installers. Despite this, these clients are able to interact with the Workgroup Data Server and behave as workgroup clients in their own right. The rest of this document will not distinguish between the different types of workgroup client except where the alternative clients have different behaviours.

Workgroup Data Server (optional) The Workgroup Data Server is a required component for all Workgroup database configurations. The Coordinator runs as a Windows service and manages access for all data in the Master database. See the Workgroup Data Server Administration document for details on configuring this component.

Network License Server (optional) A Network Licence Server can manage the licenses for Workgroup Desktop Clients, Simulation Engines, InfoAsset Mobile Server, InfoAsset Mobile Office, IWLive Server and InfoAsset/ICM Exchange. The server may be run on a separate machine. The server must be visible to all clients which are not using a local/standalone license.

InfoWorks ICM Simulation Agent (InfoWorks ICM only) The InfoWorks ICM Simulation Agent runs as a Windows service and manages communication between the Workgroup Client and the InfoWorks ICM Simulation Engine. The simulation agent (and hence the simulation engine) may be running on the same machine as the workgroup client or on a completely independent machine. This allows simulations to be carried out on standalone machines or shared workstations/servers as desired.

InfoAsset Exchange & ICM Exchange (optional) InfoAsset Exchange & ICM Exchange provide a Ruby Scripting API for automation of data transfers between the databases and 3rd Party systems. InfoAsset Exchange is required by InfoAsset Mobile for communication between the Mobile and Desktop environments. Both products act as a UI-less client, usually under a separate login from normal users.

5

InfoAsset Mobile Server (optional – InfoAsset only) The InfoAsset Mobile Server acts as the point of contact for InfoAsset Mobile Client devices. It monitors the InfoAsset Master Database for new scheduled tasks and other data that should be passed to InfoAsset Mobile devices in the field. It also responds to data uploaded from client devices and updates the InfoAsset Master Database with the latest information generated by Mobile users.

IWLive Pro Server The IWLive Pro Server is used to acquire telemetry data, carry out simulations and process results for an IWLive Pro system. It interacts with the IWLive Pro Operator Client to provide user control over the system.

6

Key Concepts for Workgroup Clients

Master Database The Master Database is the name given within the Workgroup Client application to the primary database in use at any given time. It is possible to access other “Guest” databases in order to enable data transfer between the databases, but editing of the contents of database objects is restricted to objects within the Master Database.

Note that InfoWorks WS Pro and IWLive Pro use a different database schema from InfoWorks ICM/ InfoAsset. Although the Workgroup Data Server can be used to manage databases for all Workgroup Products, workgroup clients will only be able to access those databases with a compatible schema.

There are four types of Master Database supported within the workgroup architecture:

Standalone Database This database is intended for use by individual users. Data transfer between the Workgroup Client application and the database utilises the Windows File Sharing protocol, with none of the performance benefits available when using the other database types. The use of the Windows File Sharing protocol makes this database type appropriate for use only on a stand-alone machine, or over a very reliable and low latency Local Area Network (LAN).

Standard (Workgroup) Database The Standard Database is intended for use with multiple users. This database configuration requires the use of the Workgroup Data Server software, running as a service on the machine hosting the database. All communication between the client and the Workgroup Data Server uses the TCP/IP protocol, providing a robust communication mechanism appropriate for use over Local Area Networks, or via Wide Area Networks. In addition, data is transferred in a compressed format, enhancing the performance for communications with the database.

Oracle (Workgroup) Database If desired, it is possible to host Master Database information within an Oracle database. This configuration also requires the use of the Workgroup Data Server running as a service on a machine local to the Oracle database. Once the Workgroup Data Server is configured, the use of the software and the benefits of the configuration for the end user are the same as for the Standard database. The ability to make use of Oracle’s administration and backup tools can provide additional administrative advantages for an organisation.

Note that the Oracle client software will need to be installed on the machine running the Workgroup Data Server for access to the Oracle database. For details of hosting a master database in an Oracle environment see the “Workgroup Data Server Administration” guide.

SQL Server (Workgroup) Database It is also possible to host Master Database information within a SQL Server database. This configuration also requires the use of the Workgroup Data Server running as a service on a machine local to the SQL Server database. Once the Workgroup Data Server is configured, the use of the software and the benefits of the configuration for the end user are the same as for the Standard database. The ability to make use of SQL Server’s administration and backup tools can provide additional administrative advantages for an organisation.

For details of hosting a master database in a SQL Server environment see the “Workgroup Data Server Administration” guide.

7

Transportable Databases Transportable Databases allow data to be moved between independent Master Databases. Databases objects may be copied from a Master Database into a transportable database for transfer to a remote Master Database where they can be copied into the new Master database.

Transportable databases can only be used for data transfer. It is not possible to open objects directly from a transportable database using the Workgroup Client.

Local Working Folder Each Workgroup Client requires local storage for working files. This is allocated on a per user basis. In a set up where each client runs on a separate machine the default location for this storage will be the user’s local application data directory. Although this location may be changed (for example to allow backups) the location must stay local to the machine running the client or serious performance issues will ensue.

In a Citrix/Terminal Server environment, each user’s Local Working Folder should be configured in a location such that a Workgroup Client running on any Citrix /Terminal Server will have fast access to the data in this folder. The details of this configuration will depend on the particular Citrix/Terminal Services configuration.

Local Results Folder In addition to the Local Working Folder, each user of InfoWorks ICM/InfoWorks WS Pro has a Local Results Folder which provides storage for simulation results. Like the Local Working Folder, the default location for this storage will be the user’s local application data directory and all the comments above in regard to the Local Working Folder apply also to the Local Results Folder. The separation between the two is because results files tend to be very much larger than working files and so it is useful to allow them to be stored in a different location with different backup criteria.

Remote Files Root The Remote Files Root defines an optional storage area for data which is not stored within the database but is referred to by the software. If GIS Layer files and hyperlinked files are stored in the Remote Files Root, Layer list and Hyperlink paths will be saved relative to the Remote Files Root. This allows the location for these items to be changed without breaking links to the files within the software.

Remote Results Root The Remote Results Root defines a storage area for simulation results that is shared between all users. Use of this area is optional (the default is to store each user’s simulation results in their Local Results Folder) and requires appropriate configuration of the InfoWorks ICM Simulation Agent.

Agent Working Folder Each of the simulation Agents for InfoWorks ICM and InfoWorks WS Pro requires a folder in which to keep working files for managing jobs, input files for the simulation engine and simulation results files awaiting transfer to a different agent. The default location is the standard location for ‘Program Data’ on the machine that the agent is running on. This location varies according to the version of Windows – on Windows 7 and later. For ICM Agents it would be C:\ProgramData\Innovyze\InfoWorksAgent and for WS Pro Agents it would be C:\ProgramData\Innovyze\WSAgent.

The agent automatically deletes results files after they have been downloaded and other files are removed after the job has completed or as part of a housekeeping process if they are older than a certain age (by default, 14 days). On remote agents there is potential for results files to build up if agents that request jobs do not connect and download the results in a timely manner. In this case, it may be desirable to choose a non-default location for the agent working folder in order to increase storage and/or manage backup (backup of the working folder is not recommended, due to the large and transitory nature of the files stored in it.)

8

Typical Configurations

Four typical workgroup configurations are described below. These are:

• Standalone database (no Workgroup Data Server)

• Workgroup database with standard database

• Workgroup database using Oracle/SQL database

• Workgroup database (any type) with Citrix/Terminal Server clients

These typical configurations include optional InfoAsset components but not the InfoWorks ICM Simulation Agent. Configuration of InfoWorks ICM Simulation Agents is largely independent of database configuration and is described in a separate section of this document.

Standalone Database Standalone databases are designed for use by a single user, they are not recommended for concurrent use by multiple users. Standalone databases may be located on the hard drive of the client PC or maybe located on a file server provided that the network connection to the file server is fast and reliable. Standalone databases should not be used where the link between the client PC and the file server is via a WAN connection i.e. where the client PC and the file server are not in the same location. In this circumstance a workgroup data server should be used, even if only one user is using the software.

Workgroup

Desktop

Clients(s)

Network

License

Server

Data Store

Remote

Files/Result

Root

InfoAsset

Exchange

InfoAsset

Mobile

Server

TCP/IP

File Sharing

File server

9

The diagram above shows the relationship between the key elements of a standalone database configuration using a Local Area Network. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines. Note that if the database is to be used by only a single client, it is possible for the database to be located on the client machine rather than on a network drive.

Workgroup Database – Standard The diagram below shows the relationship between the key elements of a standard InfoAsset setup using a Local Area Network. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines.

Workgroup

Desktop

Clients(s)

Network

License

Server

Workgroup

Data Server

Data Store

Remote

Files/Result

Root

InfoAsset

Exchange

InfoAsset

Mobile

Server

TCP/IP

File Sharing

File server Database Server

10

Workgroup Database – Oracle / SQL Server The diagram below shows the relationship between the key elements of a standard InfoAsset setup using a Local Area Network. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines.

File server

Workgroup

Desktop

Clients(s)

Network

License

Server

Workgroup Data

Server

Oracle/

SQL Server

Database

Remote

Files/Result

Root

InfoAsset

Exchange

InfoAsset

Mobile

Server

TCP/IP

File Sharing

WGC

Data Store

Database Server

11

Workgroup Database – Citrix / Terminal Server Setup The diagram below shows the relationship between the key elements of a Citrix or Terminal Server based InfoAsset setup. Optional elements are shown with a dashed border. Communications made using the TCP/IP protocol are shown as solid lines. Communications using the Windows File Sharing protocol are shown as dashed lines.

Note that unlike other configurations, a network dongle is required for use within a CITRIX or Terminal Services environment.

Desktop

Clients

Network License

Server Workgroup

Client

InfoAsset

Exchange

InfoAsset

Mobile

Server

Workgroup Data

Server

Data Store/

Oracle/

SQL Server

Database

Remote

Files/Result

Root

Citrix/Terminal Server

Workgroup

Client

TCP/IP

File Sharing

Database server File server

12

InfoWorks ICM Simulation Agent The InfoWorks ICM simulation agent (InfoWorksAgent.exe) manages the execution of simulation jobs on the client machine and/or on remote workstations or servers. It runs as a Windows service under the Local System account (by default) and so an agent on a client machine (a Local Agent) can continue to prepare and run simulation jobs even after the Workgroup Client has disconnected and the user has logged off. Similarly, agents running on non-client machines (Remote Agents) do not require a logged-in user in order to carry out simulation jobs as directed by a single, central agent (the Simulation Agent Coordinator).

The following diagram shows the principal processes, user accounts, storage areas and communication protocols involved in carrying out simulations using a single client machine communicating with remote machines running a Simulation Agent Coordinator and a Remote Agent. A Workgroup Data Server is optional (a standalone database can also be used). The use of Remote Agents and/or the Result Files Root is also optional but, if used, one of the agents must be configured as the Simulation Agent Coordinator. ‘File Sharing’ refers to both local and network file storage.

When launching a simulation job, the user selects which agent (or group of agents) the job will be submitted to and the agents do the rest, placing the results in either the Local Results Folder or the Remote Results Root as specified by the user. The full sequence of events involved in running a job is shown in the boxed text below.

Network License Server

Workgroup

Client

Client machine

TCP/IP

File Sharing

User

Account Local

System

Account

Local Agent Remote Agent

Agent

Working

Folder

Local

Results

Folder

Agent

Working

Folder

Simulation

Agent

Coordinator

Agent

Working

Folder

Pipe

Standalone

or

Workgroup

Database

Remote

Results

Root

Database server

Server

Workstation or Server

Server

File server

13

For simplicity, the above diagram shows a Local Agent, Simulation Agent Coordinator and Remote Agents running on separate machines. However, any agent can act in any of these roles if appropriately configured (although only one can be Coordinator). Thus an agent can be a Local Agent for clients on the same machine and at the same time act as a Remote Agent for clients on other machines.

Simulation agents can manage multiple simulation jobs from the same or different Master Databases at the

Steps involved in running a simulation job

• The user, logged-in under a user account and running the Workgroup Client, creates a Run object in the Master Database and uses this to schedule one or more simulation jobs on either the same computer or on a selected group of agents.

• The Workgroup client passes the job details to the Local Agent via a pipe and the agent places the job in its job queue.

• For each job in the queue, in turn, the Local Agent runs the Simulation Pre-processor, which extracts the necessary data from the Master Database and prepares the input files needed by the Simulation Engine.

• If the job is to run locally, it waits in the queue for a simulation slot to become available. If it is to run remotely, the Local Agent passes the job details to the Simulation Agent Coordinator.

• For a remote job, the Simulation Agent Coordinator checks whether any of the agents in the specified group is ready to run a simulation. If so, it instructs the Local Agent to upload the input files directly to the Remote Agent. Otherwise, the input files are uploaded to the Coordinator, where they wait in a queue for a Remote Agent to become available. When it does, the Coordinator uploads the input files to that agent.

• When a job, local or remote, is ready to run on an agent, the agent runs the Simulation Engine, which acquires a licence from the local or network dongle, reads the input files and starts producing results. Progress information is sent to the agent(s) and if the Workgroup Client is still connected, the user can monitor the progress of the simulation, pause it and step through it as required. Otherwise the job simply runs to completion and notifies the agent(s) and client that it has finished.

• For a local job with local results, the results files are written directly to the Local Results Folder and are available immediately for viewing by the user.

• For any other jobs, the results files are automatically downloaded from their initial location (the agent’s working folder) to their final location (the Local Results Folder or Remote Results Root as appropriate). The Simulation Agent Coordinator manages downloads to the Remote Results Root and the Local Agent manages downloads to the Local Results Root. Once these downloads have completed, the results are available for viewing by the user.

• The computers involved in running a simulation job can disconnect from one another at any time without disrupting the simulation process – if necessary, the agents simply wait for the connection to be remade in order to resume the job and can continue to process other jobs in the meantime. Likewise, if a computer is shut down it will resume processing jobs when it restarts (although any simulation already running in the engine will have to start again from the beginning).

14

same time. The only components that need to access a Master Database directly are the Workgroup Client and the Simulation Pre-processor (simprep.exe). The latter is required for any agent that is to be a Local Agent and is included in a full install of InfoWorks ICM. It is not required for an agent that is to be used only as a Remote Agent or Coordinator and so is not included in the smaller and simpler Agent-only install of InfoWorks ICM.

Note that the Simulation Agent Coordinator (which coordinates simulations across agents) should not be confused with the Workgroup Data Server (which manages access to the Master Database from Workgroup Clients).

For details of installation and configuration options refer to the document “InfoWorks ICM Simulation Agents – Installation and Configuration Guide”.

15

IWLive Pro Components

The diagram below is the system for IWLive Pro. The agent system (WS Marshaller and WS Agent) is used in IWLive Pro but for clarity these services are compressed within the diagram.

IWLive Pro exists in two versions: for IWLive Pro (IF) InfoWater and for IWLive Pro (WS) for InfoWorks WS Pro. The system diagram applies to both versions. (Note that the appropriate modelling software is used to administer IWLive Pro. This is either IWLive Pro (IF) Config, or InfoWorks WS Pro.)

IWLive Pro Operator is the user interface. This is used to view results of to run requested projection runs or incident and response runs (i.e. “what-if?”). IWLive Server is a windows service that performs projection runs on a schedule.

Network License

Server Workgroup Client

IWLive Pro Operator

WS Marshaller WS Agent

IWLive Pro Operator (s)

TCP/IP

File Sharing

User

Account

Local system

or IWLive

account

Remote Agents

Coordinator

Coordina

Pipe Workgroup

Database

Remote

Results

Root

Database server

Workstations, Servers

Server

File server

Workgroup Client

IWLive Pro Server

WS Marshaller WS Agent

IWLive

account

Telemetry Export

Database

connection

16

Despite the difference in their functionality both IWLive Pro Operator and IWLive Pro Server both have similar system requirements: they must access the master database and file servers, and also the telemetry database. Both IWLive Pro Operator and IWLive Pro Server will have a WS Marshaller and a WS Agent to assist them.

IWLive Pro accesses telemetry from a data warehouse or specialist time series database. Data is imported to initialise the model and also for “verification”: comparison with observed data. A variety of database types and connections is possible, such as OCI, OLEDB or ODBC. Similarly, summary results may be exported (usually by IWLive Pro Server) and these may be directed to databases, GIS, or text files.

IWLive Pro must only be used with Workgroup databases. Use of Standalone databases is not supported.

IWLive Pro Server must access the master database and the file server, for results. It will need access to the telemetry database, and perhaps to an export location (a different database or file server). Therefore, a default local system account will not suffice. It is usual to provide a special account, such as “My-IWLive” for example, with appropriate permissions, and to use this as the logon for IWLive Pro Server and its WS Marshaller and WS Agent.

IWLive Pro Operator requires the same level of access as IWLive Server. (Of course, some users may just act as viewers. These user accounts will need to read the results from the file server. They will need access to the master database, including write access to allow the user to save preferences or selections.) The user’s account must have suitable permissions. The WS Marshaller and WS Agent on the user’s machine will require similar permissions also, and it is advised to configure them to use the “My-IWLive” logon that is set up for IWLive Pro Server.

17

InfoAsset Mobile

Key InfoAsset Mobile Components

ISRM_S - Routing Service This is a “soft router” and has one port exposed typically to the internet. ISRM_S then decides whether a received message is valid and will try to forward the message to the relevant service if deemed to be valid, otherwise the message will be ignored.

MDS_S - Mobile Data Server Processes requests and streams data for all InfoAsset Mobile and image based requests. Also handles login requests etc.

Writes versioned files and streams files to/from InfoAsset extras directory.

WIA_S - InfoAsset Adapter Service Manages and controls all interaction with InfoAsset by invoking InfoAsset Exchange and creating/processing supporting and resultant files. Controls all work builds / report generation etc. Commands are processed in a queue

Databases These are interacted / connected to only by MDS and WIA_S. Client applications make no direct contact to the SQL databases. Main databases are the User database, MeterStream and ISInfonet.

Service Interface The service interface application can be used to monitor the status and some control of the services MDS_S and WIA_S. It communicates through ISRM_S, so a remote connection through existing ports is established.

Important Note The constituent components to run InfoAsset Mobile as a standalone system (i.e. not integrated with InfoAsset) are ISRM_S and MDS_S with the SQL Server databases. For an integrated system then WIA_S is also required.

The system is designed to be modular and so each component may reside on the same or different machines.

Communications All data transfer between client applications and ISRM_S, and ISRM_S to MDS_S and WIA_S are tcp/ip. The payload of the data is encrypted (typically Rijndael on Windows devices) to protect the contents and data message integrity is provided by a checksum.

Data connectivity to the SQL Server system is typically tcp/ip connected.

Only the services MDS_S and WIA_S connect directly to the SQL Server databases.

18

Operational Overview: Scenario - A work order is created in InfoAsset Manger.

In order for a report to be created in InfoAsset Mobile a form must exist that is a “template” for the report, i.e. we are to create a report with information from InfoAsset Manager. A decision must therefore be made as to which form should be used for this information to create a pre-filled-out report?

Assuming we have a “template”, then a report is created and as much data as is exported from InfoAsset Manager will be entered into the data fields of that report. The report would then be downloaded by a mobile client application, where the filled in data would be visible. The remaining data required can then be entered and the report saved/finished. Until the report is uploaded from the client to the server, the server and any other users do not know of the newly entered data. Once uploaded, the report data can be acted upon and formatted into csv data files and imported into InfoAsset Manager.

Following this an export of the changes (or a specified export if no changes occurred) can be instigated and the resulting exported data compared to the data that was imported. This is termed the validation of the report. Mismatches / truncations of the data are noted and can be reported back to the server administrator.

DMZ

MDS_S

ISRM_S

ISInfoNet User Database

Stored Procedures

External / Mobile Devices

MeterStream

WIA_S

InfoAsset

Exchange

SQL Server Databases

WGC

Data Store

Network

License

Server

19

Report Versions in InfoAsset Mobile Report versions start at version 1 whether originating from InfoAsset Manager or from the mobile application.

Consider a report created in InfoAsset Manager and subsequently created in InfoAsset Mobile. If user A downloaded the report and user B downloaded the report, they would both have version 1 of the report.

Assume now that user A fills out some data and uploads the report… creating version 2. Now user B fills out some data and uploads the report, this would create version 3 and overwrite any data in InfoAsset Manager.

Consider a report created in InfoAsset Manager and then in InfoAsset Mobile as version 1. Then the data in InfoAsset Manager was changed; if the report version 1 had not been downloaded by any end user then the version 1 content would be updated. If however a user had downloaded the report version 1 then a version 2 would be created.