Error tolerance and stability
Continuous improvements are made concerning the error tolerance and reliability. This page gives an overview and description of the changes. Additional information can be found in the further chapters of the documentation.
Change | Description |
---|---|
Overload regulation for drivers | The overload regulation serves for preventing an instability of the complete system caused by a driver which generates data faster than it can be handled in the system. Normally the output queue to the Event Manager would increase until no memory can be allocated more since the driver generates the data faster than the data Manager can pick up. In order to prevent this the Event Manager has to acknowledge the messages with new values and the output queue is restricted by the [driver] config setting "maxOutputQueueSize". This parameter defines the number of value changes in the queue (one value per DPE change ). When the number of the value changes exceeds this limit the messages are moved into a second queue (=overload queue). In this queue data of same DPE is overwritten. This means that the query cannot increase arbitrarily. If the first queue is emptied the data of the overload queue is moved into the first queue and the overwriting is stopped. In case of analog values the overwriting causes loss of data. An impulse at digital values (for example, 0-1 changes) remains and is not overwritten in the overflow queue. The driver can send a specific number of messages in advance without waiting for the acknowledgement. This parameter can be set via the "commitCount" config entry. This means that if commitCount is 10 the driver can send 10 messages and waits afterwards for the acknowledgement of the first message. Further chapters: Configuration file - Driver |
Message queue container in the Event Manager (in the receiving direction) | Via the config entries "maxInputMsgCount" and "msgQueueLimitTimeout" in the [event] section the number of messages in the queue and the time of the timeout (time during which the limit may be exceeded) can be defined. After the timeout has elapsed and if the number of the messages is still exceeded an emergency handling takes effect. The emergency handling closes the connection to the specific manager unless it is Data or Event Manager (the Event Manager closes the connection and this should cause the manager itself to stop). Further chapters: Configuration file - Event Manager |
BCM output queue in all managers (in the sending direction) | With the config entries "maxBcmBufferSize" and "bcmBufferLimitTimeout" in the [general] section the size of the BCM output queue and the time of the timeout (time during which the limit may be exceeded) can be defined. After the timeout has elapsed and if the size of the queue is still exceeded an emergency handling takes effect. The emergency handling closes the connection to the specific manager unless it is Data or Event Manager (the Event Manager closes the connection and this should cause the manager itself to stop). Further chapters: Configuration file - General settings |
Time limitation for the Event Manager queries | In order to prevent a complete block of the event M when processing queries the processing time of the queries (at the Event Manager) can be set via the "maxParseTime" entry. Further chapters: Configuration file - Event Manager |
Restriction of the query size with values at the Event Manager | Historical queries that query more than the maximum of set values of elements (number of rows x number of columns)are canceled as soon as possible and an error message is returned. (the number of maximum elements to be queried is set via the config entry "maxValueRequestCount" for dpQuery() and "maxValueConnectCount" for dpQueryConnect() in the [event] section. Further chapters: Configuration file - Event Manager |
Restriction of the query size with alarms at the Event Manager | Historical queries that query more than the maximum of set values of elements (number of rows x number of columns)are canceled as soon as possible and an error message is returned. (the number of maximum elements to be queried is set via the config entry "maxAlertRequestCount"for dpQuery() and "maxAlertConnectCount" for dpQueryConnect() in the [event] section. ) Further chapters: Configuration file - Event Manager |
Restriction of the query size with values at the Data Manager | Historical queries that query more than the maximum of set values of elements (number of rows x number of columns)are canceled as soon as possible and an error message is returned. (the number of maximum elements to be queried is set via the config entry "maxValueRequestCount" in the [data] section ) This is valid for queries with dpGetPeriod() and dpQuery(). The restriction can also be set via manipulation at the internal data point "_Config.MaxValueRequestCount" (when DPE is -1 the default value = 1000000 elements , 0 = no restriction). Further chapters: Configuration file - Data Manager |
Restriction of the query size with alarms at the Data Manager | Historical queries that query more than the maximum of set values of elements (number of rows x number of columns)are canceled as soon as possible and an error message is returned. (the number of maximum elements to be queried is set via the config entry "maxAlertRequestCount" in the [data] section). This is valid for queries with alertGetPeriod(), dpQuery() and OLE DB. The restriction can also be set via changes on the internal data point "_Config.MaxAlertRequestCount" (when DPE is -1 the default value = 1000000 elements , 0 = no restriction). Further chapters: Configuration file - Data Manager |
Restriction of the query size with values from the History DB |
Historical queries that query more than the maximum of set values of rows in 1 or more archives of the History DB are canceled as soon as possible and an error message is returned. (the number of maximum rows to be queried and the timeout is set via the config entry "queryTimeout" and "queryMaxValues" in the [valarch] section. This is valid for queries with dpGetPeriod(), dpQuery() and OLE DB. Further chapters: Configuration file - Archive Manager |
Calculation of statistical functions |
If the Event Manager does not manage to calculate the statistical functions in time (for example, because of overload), all older periods in the buffer beginning from a delay of n intervals (regardless of possible delay time!) are discarded, a message is shown and the last n interval is calculated. n can be specified via the config entry "statFctMaxIntervalsInPast" (Default is 3). 3 intervals are considered (interval beginning from the end of the interval until the current time). This is valid also for functions with delayed calculation. These have to be executed within 3 periods otherwise the lapsed periods are discarded. Further chapters: Configuration file - General settings resp. Statistical functions |
Check of message connection | Each message of a WinCC OA manager contains a header which identifies the message. Connection attempts of others than WinCC OA managers (for example, Port scans, Telnet)are terminated immediately. |
Error handler | Multiple repeats of the same error message are discarded . This results in decrease of the needless flow of messages (Log Viewer). |