Introduction

This document specifies requirements and recommendations for implementing a WATS Solution. A WATS Solution consists of minimum one server, and one or more test stations. The WATS Structure can extend to as many levels as required – possibly reflecting the customer’s organization structure including out-sourcing partners. This structure is dynamic, and can expand with the customer’s growth. The top-level server at any time will be known as Master Server, other servers in the hierarchy are known as Local Server(s). Test stations can report to any server in the hierarchy – preferably the closest possible server.

See Also:  
WATS On-premise system monitoring

Implementation size

This table must be treated as guidelines. Different customers have different needs, and different products may require more or less storage space. This table presumes that an average report require 50KB of storage space.

Multiple server scenario (scale-out)

WATS server can be split into several tiers. For medium to large implementations, it is recommended to split database server from application server. Application server also consists of several parts – possibly split onto several servers. This is recommended for Medium/Large implementations. Database server is a Microsoft SQL Server.

Storage

For medium to large implementations, server-internal storage is adequate. For larger implementations, a SAN Solution is recommended. Redundant disk arrays are highly recommended for high availability.

Network and infrastructure

General information

WATS Communication is based on RESTful WebAPI over https. For on-premise installations it is possible to use non-encrypted channel (http) if no internal pki is available, and the use and handling of external certificates is considered unnecessary.

All communication with the WATS Server is http based, either tcp port 80 for http or tcp port 443 for https.

Communication between Application server (IIS) and Database server (MSSQL) depends on database settings. Normally Microsoft SQL Server use port 1433/tcp. This information is useful in scenarios where WebService and Database servers are separated using a firewall.

Security

All (external) WATS communication is running https / TLS 1.2 All clients should be upgraded to 5.1 or later as soon as possible. Starting from server release 2019.2, 4.2 client are no longer supported. Starting from server release 2023.1, 5.0 clients are no longer supported

We recommend that all servers are set up with https/tls even if the server is not publicly available. It is recommended to use an Enterprise CA / Internal PKI to issue the required certificates. If you have clients running Windows XP, TLS 1.0 must be enabled. This is considered a security risk and it is highly recommended to upgrade to a fully supported OS as soon as possible.

Communication scenarios

Site-to-site tunnel using hardware VPN Router.

Two networks are connected using VPN Router connecting to a VPN Termination point. VPN termination points are sometimes implemented in firewalls.

The figure below shows a typical communication strategy, where the Database server is further protected using a secondary firewall.

Teststation with VPN Client.

A single teststation connects to the VPN Termination point using VPN Client software installed on the teststation. In this case the teststation becomes a master-client.

Local Server with VPN Client software.

The local server connects directly to the VPN Termination point, using locally installed VPN Client. This implies the need for VPN “autoconnection” feature in the VPN Client.

Directly connected Teststation

In this scenario the teststation directly communicates with a Datacenter exposed to public using a DMZ network.

DMZ Buffer

The DMZ Buffer act as a local server between the sites and the master server. By implementing the DMZ Buffer, there will be no need for additional incoming rules on the firewall. The front-end firewall must allow incoming tcp/443 (https). The transfer agent will then be installed inside the corporate network, extracting data from the buffer database into master. The secondary firewall must allow outgoing tcp/1433.

Recommended communication strategy

For secure and reliable communication, the recommended interconnection method is site-to-site tunneling using hardware VPN routers. This communication network may further be protected using a firewall to separate corporate internal network from external partner networks.

Summary

Connection between client (or local server) to master server requires tcp port 443 to be allowed (or tcp/80 if https/tls is waived).

Connection between webserver (datacenter) and Database server requires incoming connection on port 1433 for MS SQL Server.

Hardware requirements

WATS is built using Microsoft technology, running on Intel platform. All application logic is built using Microsoft .NET framework, and can easily be ported to other hardware platforms supported by Microsoft .NET Framework 4.8. The recommended platform for WATS Servers is Intel Xeon running in Native 64-bit mode.

Recommended server specifications

These specifications must be treated as guidelines for medium to large implementations. For larger systems a thorough requirement analysis must be performed.

Master server recommendation (physical)

A typical master server hardware specification for a medium server

• 2U Chassis with 8 hot plug 2.5" drives
• Xeon E5-24xx processor (rec. minimum E5-2407)
• 2x 8 GB Memory (add more memory to database server for better performance)
• Hardware RAID Controller
• 2x 300GB SAS 10K drives in RAID 1 for OS/System
• 4x 300GB SAS 15K drives in RAID 10 for data (Database server only)
• Windows Server 2019
• Dual hot-plug PSU

Local server recommendation (physical)

A typical local server hardware specification

• 1U/2U Chassis with 4 hot plug drives
• Xeon E5-24xx processor (rec. minimum E5-2407)
• 1-2x 8GB Memory
• Hardware RAID Controller
• 2x 300GB SAS 10K drives in RAID-1
• Windows Server 2019
• Dual hot-plug PSU

For larger sites, refer to master server spec, and consider splitting application and database server.

Server consolidation

For medium to large implementations, server consolidation can be an option. For customers already running a virtualized environment this can reduce implementation time, and increase manageability. Even if a virtualized environment is desired, it is still recommended to use separate servers for database and application for large implementations. For larger implementations Database and data warehouse servers should be considered running on separate non-virtualized hardware while application can be hosted on virtual server(s).

Software requirements

The WATS system is built on Microsoft technology. Microsoft .NET Framework is an essential component in the entire system, currently version 4.8 is in use – future releases may require newer framework version.

Server requirements

Operating system

Recommended server operating system is Microsoft Windows 2019 Server. Minimum required version of Windows Server is 2012 R2.

Database and data warehouse

Microsoft SQL Server 2017 (starting from release 2019.1) is required. It is recommended that WATS is running a separate instance to avoid conflicts with other systems. 

Application logic

Application logic is built on Microsoft .NET Framework 4.8, future releases may require newer versions.

WATS Server hierarchy

When upgrading or installing server, the servers must be upgraded top-down. It is not supported to upgrade a local server to a version with a higher version number than its parent server.

It is always recommended to keep all servers in the hierarchy on the same version. No servers in the hierarchy should differ in more than one release versions.

For example when upgrading master to 2018.3, all children must be upgraded to minimum 2018.2.

Client requirements

Operating system

Recommended test station operating system is Microsoft Windows 10. 64-bit versions is recommended to avoid memory limitations of 32 bit OS. Windows XP can be used, but is scheduled for termination in WATS 5.1. WATS Client is a standalone application, however currently no sequencer is embedded with the client. TestStand is the recommended test sequencer, and is tightly integrated with WATS. Recommended TestStand acquisition adapter is NI LabView. NI LabView is integrated with WATS Client as well.

For supported NI TestStand and NI LabView versions, refer to WATS Client Release note https://virinco.zendesk.com/hc/en-us/articles/207491836-Download-the-WATS-Client

Database Specification

The WATS database is designed as a very flexible structure where the main entity is a report. A WATS report can take numerous forms. Each report is bound to a unit – specified by Part number and Serial number. A Unit can be related to zero or more subunits.

The database structure is flexible and well suited for reporting. The data mining functionality further extends the reporting possibilities.

Backup

When the WATS server is running locally you also need to manage backup locally.

Refer to WATS on-premises backup recommendations for details and recommendations regarding on-premises backup strategies.

Transfer technology

The WATS System may consist of several servers in a hierarchy. The WATS Transfer technology use Service Oriented Architecture (SOA) for transferring data. Each server below master level communicates with its parent server through RESTful webAPIs. Communication is usually protected using TLS1.2 (https).

The communication between servers is https-based, minimizing the need for firewall configuration changes and is encrypted by x509 Certificates. For increased flexibility and security, the traffic can be routed through VPN tunnels or MPLS networks.

High-latency connections are often an issue for VPN connections between continents and many replication-methods does not perform well under such conditions. The usage of Service oriented architecture solves this problem, utilizing the capacity of high-latency connections, while ensuring data integrity.