VTScada Services Reference

When planning your server configuration, you should consider the balance between services that are I/O intensive and those that place a heavy load on hard drive access. In larger systems, there can be significant benefit to distributing the load to separate these types of services. Your design should also consider system redundancy for risk management planning.

Each of the following VTScada services can be assigned its own server list. Some place a heavier load on data I/O while others require more disk access. Some of the services listed here place minimal load on a system, and therefore may be assigned to servers at your discretion.

every system will have different requirements and different priorities. No single guideline can be used for the design of all systems.

Alarm Notification

Used to decide which workstation should dispatch alarm notifications. This service is registered only on workstations that have the alarm notification feature enabled in their license key. Backup servers will assume the role if the higher-level servers don't have alarm notification feature enabled.

Configuration

The service responsible for distributing deployed changes to all workstations. In a working system, configuration changes usually do not occur often, but may place some load on disk access when they do. Some developers prefer to keep the configuration server separate from the primary server for tag I/O in larger applications.

ControlTokenManager

The service that monitors for stale control tokens.

Device Drivers

All I/O will route through the current primary server to reach the attached device. Ensure that listed server can connect to your devices. In a larger application, consider separating these services from those that require intensive hard drive activity such as Historians. If there are several device drivers on a server, consider creating a set of named Driver Server Lists for ease of configuration.

DriverDiscovery

Currently, applies to the BACnet driver discovery feature.

Modem Manager

Used in VTScada installations that include the Alarm Notification System option. Provides data and voice telephony services for standard VTScada applications and enables modems connected to different machines to be managed as a common pool. This service seldom places a heavy load on a system.

MultiSpeakRPCService

Ensures that only the designated server will send out a notification to Milsoft-OMS when a tag value changes.

Network Values

This service is in charge of updating changes on all PCs for multi-server applications when a change to a Network Value variable has occurred. Involves data transfers to all PCs in the network therefore there is little advantage to separating this service from others.

OAuth2

Servers to be contacted for OAuth 2.0 authentication. These do not need be thin client servers.

Page Parameters

Responsible for (in part) synchronizing task bar page buttons. Places minimal load on a system.

Service Control

May be used by custom code to provide application-level control of RPC servership.

SlippyMapService

Identifies the server where map tiles are stored. All other workstations will obtain their tiles from this server rather than downloading from the Internet.

SMS Manager

Used in VTScada installations that include the Alarm Notification System option. Provides SMS messaging services for alarm notifications. This service seldom places a heavy load on a system.

System Alarm Historian

The System Alarm Historian service takes care of alarm storage and retrieval. This service will not place the same load on system resources as Historians logging process I/O. This historian is normally configured so that a local copy of data is maintained on all workstations, allowing alarms to function normally on a workstation that is separated from the current primary server.

System Historian

The System Historian service takes care of data storage and retrieval. This service is disk access intensive and is often separated from services that involve tag I/O and alarming.

User-Defined Historians

Developers may create their own Historian tags in addition to the SystemHistorian, thereby distributing the task of logging data. In a large application, setting different servers for each Historian is an effective way of distributing the load of disk access.

Value Synchronization Service

Used only in the Totalizer tag, Counter tag,  Selector Switch and (possibly) user-defined custom tags. Places minimal load on most systems.