Home
Business Logic / Control
Endless possibilities in data processing for your projects.
NextGen Archiver Backend-API
This chapter describes the NextGen Archiver Backend API
Redundancy
Describes the NGA redundancy.
Overview
The main aspect of NGA redundancy is to avoid losing historical data due to single hardware or software failures.

Version Information
Release Notes, Update information, Certifications and Frequently Asked Questions.
Concepts
Your first step into modern and powerful process visualization.
Deployment
Topics, you need to know, before using WinCC OA.
Security
Go beyond the norm in cybersecurity.
Engineering
Powerful tools for easy or complex engineering tasks.
Data Management
Classify, structure and archive your data.
Business Logic / Control
Endless possibilities in data processing for your projects.
- Introduction to CTRL
  An introduction to the product's own programming language Control(CTRL).
- Control Classes
  The overview of classes available in Control.
- Types of Control Functions
  An overview of the types of functions distinguished within Control.
- Control graphics
- CONTROL Functions
- CtrlExtension
  The CtrlExtension allows the addition of custom C++ code.
- CTRL Debugger
  You can use the CTRL debugger to debug the Control programming language. The debugger can be used via its own panel, which also enables the monitoring and setting of variable values during the execution of a script.
- SQL in CONTROL
  The database functions enable you to quickly carry out value queries on data points and elements.
- API Manager
  The WinCC OA API (Application Programming Interface) offers a number of functions adding special Managers to this process control system.
- NextGen Archiver Backend-API
  This chapter describes the NextGen Archiver Backend API
  - Architecture
    This chapter provides an overview of the NGA system architecture.
  - Backend
    Description of what is a backend.
  - Segment Management
    The segments are used for NGA archiving. In order to keep the data manageable, NGA structures the data of each archive group into segments.
  - Requirements
    Contains the requirements for the NGA Backend API.
  - Project structure
    This chapter describes the project structure of the TemplateNextGenArchBackend project (lib, exe and plugin projects as well as the dplist directory).
  - Build steps
    Build steps contains the steps Create new project and Updating third-party libraries in an existing project.
  - Work modes
    The backend can work in various modes.
  - Backend API architecture
    This chapter describes what classes you must implement to implement your backend.
  - Redundancy
    Describes the NGA redundancy.
    - Overview
      The main aspect of NGA redundancy is to avoid losing historical data due to single hardware or software failures.
    - NGA redundancy for non-redundancy-capable databases
      This chapter describes NGA redundancy for non-redundancy-capable databases.
    - NGA redundancy for redundancy-aware databases
      This chapter describes NGA redundancy for redundancy-aware databases.
  - Backend lifetime
    This chapter describes the backend lifetime consisting of the different steps for starting and stopping such as Create a CommonBackend instance and Get DatabaseParameters.
Data Visualization
User interfaces, Trends and Reports for every purpose and device.
Southbound Interfaces
The process connection to the actual machines/sensors.
Northbound Interfaces
Your portal to the cloud or supervising systems.
Web Connectivity / Network Interfaces
Data exchange, APIs and web technologies
User Management
All about authorization, authentication and login-customization.
Availability
How to get your system uptime to the maximum.
Reporting
Create state of the art project reports without limits.
Addons
Useful tools and enhancements for special demands.
Reference Tables
Detailed and extensive content for special project adaptation.
Videos & Tutorials
Explore the capabilities of WinCC OA with our carefully selected collection of video tutorials and guides.
WinCC OA Documentation
Basic information about terms and functions within the documentation.
Disclaimer
A brief clarification of liability exclusions or legal notices.

Overview

The main aspect of NGA redundancy is to avoid losing historical data due to single hardware or software failures.

WinCC OA can run in redundant mode where two WinCC OA servers (called "left" and "right" in the following context) are used and the failure of one of these systems is compensated by the other. One of the servers is always the "active" one, sending data to peripheral devices and handling user interfaces, the other server is the "passive" one, maintaining a copy of the state of the active server.

The main aspect of NGA redundancy is to avoid losing historical data due to single hardware or software failures. The implementation is intended to be able to cope with single failures, not multiple parallel ones (e.g. hard disk crash on both servers). Another aspect of NGA redundancy is to provide historical read access for remote user interfaces even if one redundant WinCC OA node or one database node is down (if the database is redundant and located on a separate server).

There is also a special mode for redundancy called "split mode", where both servers will be active and when ending split mode one of them is designed to stay active, the other one will be restarted, and a recovery is made (standard WinCC OA redundancy function when a server project is restarted). This option will (currently) not be supported by NextGen Archiver.

Each redundant server has an "error state" (also called "health state") which normally should be identical on both servers. If not, the server with the better "health" state will get active, possibly causing a "switchover" between active and passive server. If a server has stopped, it has to be synchronized at the next restart to have the same "state" (data point values, alert states etc.) as the currently running one. This is called recovery.

For using NextGen Archiver in a redundant system two different schemas – depending on the redundancy support of the used database(s) – are possible:

If the database is not able to do redundancy on its own (e.g. the open source version of InfluxDB), the database must be running on both nodes, which are independent of each other (as far as the database is concerned).
If the database is capable of redundant operation (i.e. PostgreSQL) then both redundant NGA instances can talk to a common database instance which will perform redundant operations (switchover, recovery) on its own.