Feature Meaning Possible error / possible reason
Ability of process to con‐
tinue to be controlled and
monitored even when a
server switchover occurs.
If an OS server fails, the system switches
over to the configured redundant partner
server. All OS clients are automatically
switched over to the now activate OS part‐
ner server. The process can continue to be
controlled and monitored through the OS
clients even during the switchover period.
Failure of the OS server
Examples:
● Operating system failure
● Hard disk defect
Display of the master /
standby identification of
the OS server.
Information about the master / standby
identification of the OS server can be re‐
quested and visualized using the OS cli‐
ents.
The master / standby identification changes if the
active OS server (master) fails.
No loss of data; gap-free
data archiving.
The project data are saved according to the
interval configured.
Failure of the OS server, for example, due to a hard
disk defect.
Permanent operability of
the control process by
configuring a preferred
server for each OS client.
The failure of some OS clients can be tol‐
erated if the remaining clients continue to
be connected to the process.
One or more client operator stations fail, for exam‐
ple, due to a hardware or software error.
Duration of the switchover of the OS clients to the
redundant OS server
Replacement of faulty
components and recon‐
nection to the system in
runtime.
The failed components can be replaced
without influencing the ongoing process
and subsequently reconnected. A redun‐
dancy update is then performed.
OS client failure: e.g., operating system
OS server failure: e.g., network adapter
Plant bus failure: e.g., wire break
Central rack failure: e.g., PS, CPU, synchronization
line, CP, SM
Fieldbus failure: e.g., defective PROFIBUS bus
connector
Failure of the distributed I/O device: e.g., PS, IM,
SM
Update of faulty compo‐
nent with current system
status after being reinte‐
grated into the system.
Redundancy synchronization is performed
for all high availability components, for ex‐
ample, a CPU or a server after return to
operation.
Switching on a redundant component after a redun‐
dancy fault. Example: Startup of the module after a
CPU is replaced with subsequent data synchroni‐
zation on the CPU conducting the process.
System upgrades and ex‐
pansions in runtime
Redundantly designed components can be
upgraded, expanded or replaced in run‐
time.
Copying BIOS versions to redundant PC stations
Software updates for redundant PC stations with‐
out utilization of new functions
Displays and documenta‐
tion
Documentation of availability, for example,
testing based on the mean time between
failure (MTBF) residual time with optional
printout.
Displays and documentation of a potential compo‐
nent failure in advance.
Basics of high availability
3.6 Features for the commissioning and operation phases
High Availability Process Control Systems (V9.0)
28 Function Manual, 05/2017, A5E39221836-AA
To Next Page
Loading...
