Diese Basisaufgabe von SmartCollect ist recht einfach und auch dessen Verwendung ist nicht kompliziert. Jedoch wurde

während der Entwicklung ein großer Schwerpunkt auf die Leistung, die funktionale Zuverlässigkeit und die inhärenten

Selbstreparatureigenschaften der Anwendung gelegt. Letztere bedeutet, dass wenn zum Beispiel ein Problem mit der

Kommunikation mit einer Quelle auftritt, die Anwendung diese überprüft und versucht, das Problem zu lösen. Die Umsetzung

wird im untenstehenden Modell dargestellt.

ggf. das Senden von E-Mails zum Systemadministrator kümmert.

Wenn diese aufwändigen Prozesse laufen, wird für jede Quelle ein neuer Thread gestartet, der nur für die Werte dieser Quelle

zuständig ist. Der Ausdruck „Quelle“ bezieht sich auf jegliche Art an Geräten, aus denen Daten ausgelesen werden. Dafür

startet der Controller einen WriterProxy, der sicherstellt, dass alle Quellen für den Controller gleich aussehen. Der WriterProxy

selbst nutzt eine bestimmte Art Vermittler, je nachdem, was für jede spezifische Quelle definiert wurde. Im obigen Modell

werden zwei Modbus-TCP-Geräte ausgelesen.

Wenn alles gestartet ist prüft der Controller, ob die verschiedenen Threads (d. h. die Quellen) ihre Daten zur richtigen Zeit an

den DbProxy liefern. Wenn der Controller feststellt, dass dies nicht der Fall ist, wird dieser Thread angehalten und nach einer

konfigurierbaren Zeit neu gestartet. Wenn der Thread dann immer noch keine Daten liefert, wird das Anhalten und Neustarten

des Prozesses eine anpassbare Anzahl an Versuchen wiederholt, bis die Daten wieder erscheinen. Wenn all dies immer noch

Modbus-TCP 21 Geräte (d. h. Quellen) ausgelesen, die jeweils 12 Datenkanäle enthielten. Beim Lesen dieser 252 Kanäle

betrug das maximal erreichbare Intervall 3 Sekunden, was bedeutet, dass jede Stunde 302.400 Werte (7,2 Millionen Werte

pro Tag) in der Datenbank registriert werden. Während dieses Tests betrug die durchschnittliche CPU-Auslastung des Dienstes

ca. 2-3%. Der Engpass während des Tests, aufgrund dessen eine Geschwindigkeit von unter 3 Sekunden nicht möglich war,

war die Geschwindigkeit, mit der die Quellen die Daten liefern konnten. Da die Hardware jedoch schneller werden wird, ist es

sehr wahrscheinlich, dass mit neuen Geräten eine noch größere Geschwindigkeit für das Lesen von Daten erreicht werden

kann. Außerdem läuft diese Testkonfiguration nun schon mehrere Jahre ohne Probleme, was beweist, dass diese

Geschwindigkeit in der Praxis erzielbar ist.

Das schnellste Intervall, das SmartCollect zum Auslesen von Geräten verwenden kann, hängt stark von den

Hardwarefähigkeiten und der Leistung der verbundenen Geräte, den verwendeten Protokollen und der Anzahl an Werten ab,