Operating Conditions

1. Introduction

WinCC OA needs proper settings and engineering in the hosting environment for high-perfomance and reliable operation in productive installations.

This list of highly recommended settings is the basic operation condition for WinCC OA.

The settings provide a basic guideline for system engineering, independent of the actual field of application. The operating conditions for safety projects are defined separately in the WinCC OA Safety manual. For safety projects the safety manual takes precedence over this document. Security requirements are summarized in the Security Guide for WinCC OA. Safety and security-relevant documentation is available for download on the WinCC OA portal for currently supported versions of WinCC OA.

Operating WinCC OA projects in environments with other than the given conditions may lead to reduced support or warranty void. Errors reported on systems operating with other than the given conditions may not be analyzed or corrected.

2. Highly Recommended Operating Conditions for Production Installations

• WinCC OA is not intended for the use as a real-time control system.
• WinCC OA should only be run with a valid license. Licenses with a demo Period in production systems are excluded.
• Each individual computer (either dedicated hardware or virtual machine) must run only one project at a time.
• A WinCC OA project should run exclusively on one computer. Combinations of WinCC OA with other services (e.g. Active Directory) will decrease performance significantly.
• WinCC OA must only be run on approved operating systems (Version and service pack as defined in chapter "Software Requirements").
• WinCC OA installations should be kept up-to date regarding WinCC OA patches over the lifetime of the project. New installations should be shipped including the most recent patch level of WinCC OA.
• The same version and patch level of WinCC OA must be installed on both server and client-side. UIs are excluded from this rule when the UI version is the same or higher than the server version.
• It’s imperative to only use hardware as specified in chapter "Hardware requirements" when running WinCC OA. This is especially important for the use of the Mobile UI. For mobile devices, also the correct OS version must be used.
• Each computer must have a distinct host name. Host names that contain (-) must be avoided.
• Teaming-network must not be installed.
• An uninterruptible power supply must be installed on the server WinCC OA is running on.
• The system time on all computers that are part of a WinCC OA system must be synchronized. When multiple WinCC OA systems are configured in a distributed architecture, the system time must be the same for all servers in this distributed system setup. Exceptions are allowed for user interface clients (especially mobile devices). The use of an NTP server is recommended.
• The system time sequence must be monotonically increasing. Synchronization jumps higher than Alive Timeout / 2 should be avoided as this leads to connection loss of WinCC OA managers.
• Directories compressed on the OS-Level must not be used for storing any WinCC OA related data (e.g. project folder).
• All project directories must be local, including directories for sub-projects (no network share).
• Hard disk- and RAM-space are monitored in WinCC OA. This monitoring must be configured to match the project environment (e.g. monitor correct drive) and must not be deactivated.
• Virtual memory should be configured to have a fixed size. When virtual memory is spread across several devices (e.g. hard disks) all settings should have a fixed size.
• OS-functions for a dynamic CPU frequency must be deactivated
• Functions to limit data retrieval (Data, HDB, Event, Drivers) must remain activated. Limits can be customized to meet project needs.
• Functions to limit message buffers must remain activated. Limits can be customized to meet project needs.
• Only a dedicated operating system user may be used to run WinCC OA as a service. The local system account in Windows or root account in Linux must not be used since access and permission problems might occur.
• It is recommended to use redundant network connections for redundant server setups.
• The Raima database must be periodically backed up with the WinCC OA Online Backup tool. It is recommended to back up the value archives regularly.
• The use of external backup tools or scripts for copying the Raima database of a running project is prohibited.
• VMWare backup functions shall not be used as backup for WinCC OA project VMs. VM Snapshot and restore functionality is also not suitable as backup for WinCC OA appliances.
• When running Vmware vSphere only vSphere HA can be used. vMotion must not be used. Furthermore, vSphere HA works only in combination with a redundant WinCC OA system.
• Only WinCC OA versions covered by mainline support should be used to guarantee the availability of patches.
• The polling intervals must be adjusted to peripheral conditions. Polling intervals should not be configured shorter than required to avoid unnecessary system load.
• For optimal operation performance the debug output at runtime may only be activated temporarily when the system is under strict surveillance for debugging purposes.

3. Recommended Operating Conditions

• Personnel responsible for engineering and maintenance of WinCC OA projects should be trained to an appropriate level (e.g. ETM Certified Engineer for WinCC OA).
• The use of a virtual machine as a basis for operating a WinCC OA system is allowed for only one WinCC OA project per virtual machine. In the case of a redundant WinCC OA project, two virtual machines on different hardware are required.
• The communication network for the control system must be separated from other networks (e.g. office communication).
• A redundant server configuration (hot stand-by configuration) and a fully-redundant network including the components should be considered to increase availability.
• To ensure automatic startup of WinCC OA the Process Monitor should be running as an operating system service and an automatic restart of managers must be configured for the service.
• In order to assure secure command and alert channels between the managers either the SSL communication mechanism OR the Kerberos Security with the mode “integrity” must be activated.
• It is recommended to avoid implicit type casts in CTRL/CTRL++. To check the current type of a variable the control function getType() is available.
• It is recommended to configure smoothing mechanisms and old/new comparison mechanisms in drivers and optionally on value archive to reduce the amount of processed data in the system.
• The main memory limit for the emergency mode should be configured in such a way that it is reached before swapping, to avoid a big impact on performance. Therefore, the availability of the virtual main memory should be limited.
• It is recommended to limit the usage of data point functions to a minimum as they impact the overall performance of the Event Manager. Functions which do not have a defined and fixed runtime behavior (e.g. dynContains()), should not be used for data point functions.
• The average CPU load occupied by the Event Manager process in normal operation should be < 20 %.
• The summarized average CPU load of all WinCC OA related processes in normal operation should be < 50 %.
• Technical Limits of the WinCC OA system are listed in the table below. For recommended hardware requirements refer to section “Hardware requirements”.

¹Fat Client UI, Desktop UI, Mobile UI, ULC UX.

¹How can you determine the number of possible clients for your machine?

Start a UI with the plant project, log in and measure the CPU/memory consumption after a few hours of runtime and UI operation. The measured values and the number of clients determine the minimum requirements for the hardware, especially the RAM.

²Redundant or non-redundant WinCC OA server configuration

³Depending on the limited number of files that can be saved on a computer.

⁴This hard limit only applies to the RAIMA database and not the SQLite database. For both RAIMA and SQLite projects, the number of possible data points may vary due to several factors, not only the number of elements. Consider the following factors for the maximum number of data point elements as well as the maximum size of your projects:

• The resource usage (RAM, CPU)
• The startup times
• The number of value changes per second which need to be processed. The higher the number of DP elements in your system, the higher the number of value changes.
• The amount of disc space needed to save data.

The number of possible data points may vary due to several factors, not only the number of elements. Consider the following factors for the maximum number of data point elements as well as the maximum size of your projects:

• The resource usage (RAM, CPU)
• The startup times
• The number of value changes per second which need to be processed. The higher the number of DP elements in your system, the higher the number of value changes.
• The amount of disc space needed to save data.

For a rough estimation you can use the information described in the WinCC OA Portal:

https://www.winccoa.com/knowledge-base/detail/how-many-bytes-are-needed-at-the-hard-disc-to-save-a-value-or-alarm.html