Häufig gestellte Fragen

Es handelt sich hierbei um eine vereinfachte Form des NTP und wird im RFC 2030 beschrieben. Der Hauptunterschied liegt darin, dass sich SNTP auf einfachere Algorithmen stützt und man einen Zeitserver verwenden muss.

Unter PTP versteht man das „Precision Time Protocol“, welches in der IEEE 1588 definiert ist. Im Gegensatz zu NTP handelt es sich hierbei um ein Netzwerkprotokoll, welches sich durch deutlich höhere Genauigkeiten (bis in den Nanosekundenbereich) auszeichnet und in der Regel in lokal begrenzten Netzwerken (z.B. Mess-/Steuer-/Regeltechnik, Automatisierungstechnik usw.) zum Einsatz kommt. Im Vordergrund steht dabei nicht die absolut korrekte Zeitinformation, sondern vielmehr die hochpräzise “Taktung” miteinander in Verbindung stehender Geräte in derartigen Industrie- oder Rechnernetzwerken. Man spricht im Zusammenhang mit der PTP-Netzorganisation und Uhrentypen zunächst von Grandmaster Clocks (bestmögliches Referenzgerät) und Boundary Clocks (Geräte mit Master- und Slave-Funktion), deren Rollenverteilung über den Best Master Clock-Algorithmus ermittelt wird. Hingegen werden den Ordinary Clocks klar definierte Rollen (entweder als Master oder Clients) zugewiesen, sogenannte Transparent Clocks leiten den PTP-Zeitstempel dann lediglich gegebenenfalls korrigiert weiter. Die Laufzeitkorrektur wird über aufwendige Rechenalgorithmen sichergestellt. Es ist also nicht so, dass ein Verfahren durch das andere ersetzt werden soll: NTP und PTP haben unterschiedliche Funktionsschwerpunkte, deshalb haben beide auch zukünftig eine Berechtigung und können gegebenenfalls auch parallel in Computer-Netzwerken zum Einsatz kommen.

In der Regel senden NTP-Clients maximal alle 64 Sekunden ein Anfragepaket. Bei einer Gerätekennzahl von 100 “Anfragen pro Sekunde” könnte man also bereits 6.400 NTP-Clients im Netzwerk synchronisieren. Verwendet man zum Beispiel den DTS4160-Zeitserver mit 10.000 “Anfragen pro Sekunde”, so ergibt sich sogar eine Zahl von 640.000 Clients, die man mit diesem Zeitservertyp im Netzwerk synchronisieren könnte. Da aktuellere NTP-Versionen das Abfrage-Intervall bei stabiler Zeitsynchronisation bis um den Faktor x 16 vergrößern, resultiert daraus eine noch weitaus größere Anzahl der möglichen NTP-Endgeräte. Man sollte also diesen Sachverhalt bei der Auswahl der für den konkreten Bedarfsfall wirklich notwendigen Gerätespezifikation entsprechend berücksichtigen. Bei größeren Netzwerken ist darüber hinaus üblich, dass man hierarchisch aufgebaute Zeitserver-Strukturen – bestehend aus mehreren Netzwerk-Segmenten bzw. -Ebenen mit jeweils zugeordnetem Zeitserver – erstellt. So synchronisieren sich die Zeitserver der jeweils unteren Ebene immer auf die höhere Ebene bis hin zum zentralen Zeitserver. Dieser zentrale Zeitserver weist typisch die höchsten Leistungsmerkmale auf und ist häufig auch redundant aufgebaut.

Derartige Überlegungen sind bei hierarchisch aufgebauten Zeitserver-Strukturen von Bedeutung. Als Stratum Level “0” wird immer der Zeitserver auf der obersten Ebene bezeichnet, der zum Beispiel mittels exakter DCF-/GPS-Synchronisierung als Referenzzeitquelle des Gesamtsystems fungiert. Die darunter liegende Ebene nebst den darin befindlichen Zeitservern – die sich selbst wiederum auf den Level „0“ synchronisieren – erhält demgemäß den Stratum-Level “1”. Weiter darunter liegende Ebenen addieren folglich den Stratum-Level “n+1”. In der Regel sind maximal 16 Stratum-Level festgelegt.

Die DTS-Geräte sind bei redundantem Aufbau dafür ausgerüstet, miteinander in Verbindung zu stehen und einen permanenten Zeitabgleich zu fahren. Dieser Abgleich ist notwendig, um technisch unvermeidliche Unterschiede beim Quarzdrift der beiden Geräte vermittels Softwaretrimmung auszugleichen. Würde man diesen Abgleich nicht fahren, bestünde bei theoretisch möglichem Ausfall der DCF-/GPS-Synchronisation und “Free-Running-Mode” (in der Praxis teilweise nicht sofort wahrgenommen) das Risiko, dass beim Defekt des ersten Zeitservers und dem darauf folgenden Umschalten auf DTS-Zeitserver Nr. 2 im Netzwerk ein entsprechender Zeitsprung entsteht. Jedoch sind derartige Zeitsprünge in IT-Netzwerken generell unerwünscht, da diese einen undefinierten Zustand und Instabilität hervorrufen. Um dabei nicht vom IT-Netzwerk selbst abhängig zu sein, wird die eingangs genannte Verbindung vermittels “optischem Link”, d.h. mit separater Technik und nicht über LAN/WAN hergestellt.

Die DTS-Geräte sind dahingehend einstellbar, dass eine interne Plausibilitätsprüfung gemacht wird. Man kann demnach einen Grenzwert im Gerät einstellen, der dann als Kontrollgrenze bezüglich eingehender DCF-/GPS-Werte dient. Sofern nun ein Eingangswert außerhalb dieser Grenzen liegt, wird a) dieses Signal nicht übernommen und b) der Server setzt eine entsprechende Fehlermeldung ab (z.B. E-Mail, SNMP-Trap, potenzialfreier Kontakt).

Seitens MOBATIME würde man hier den DTS4160 mit 4 unabhängigen LAN-Ports empfehlen. Die Marke von max. +/- 1 Sek. pro Jahr wäre mit dem DOCXO-Quarz zu schaffen (Version B). Bei besonders kritischen und ggf. noch genaueren Anwendungen sollte man die Ausführung mit Rubidium-Quarz bevorzugen (Version C).

Die meisten Zeitzonen der Welt basieren auf der „Coordinated Universal Time“ (UTC, internationaler Zeitstandard). Jedoch verläuft die Erdrotation nicht so regelmäßig und ist minimal kleiner, als bei der Definition dieses Zeitstandards festgelegt wurde. Aus diesem Grund werden von Zeit zu Zeit sogenannte „Schaltsekunden“ in die UTC-Zeitskala eingefügt. Da die Eigenrotation der Erde nicht perfekt konstant ist, erfolgt die Einfügung von Schaltsekunden jedoch bei Bedarf und nach keinem festen Muster. Schaltsekunden werden in so einem Bedarfsfall vom Internationalen Dienst für Erdrotation und Referenzsysteme (International Earth Rotation and Reference Service, IERS) festgelegt. Zuständig für die amtliche Zeit eines jeweiligen Landes ist jedoch meist die zuständige, staatliche Einrichtung. In Deutschland ist dies die „Physikalisch Technische Bundesanstalt“ (PTB).

Grundsätzlich gibt es zwei Möglichkeiten, die Schaltsekunde im eigenen IT-Zeitsystem zu berücksichtigen. Die erste Lösung besteht darin (DTS4160, DTS4210), dass die Schaltsekunde automatisch über den GPS-Empfänger eingelesen wird und der Zeitserver dies beim ausgegebenen NTP-Zeitstempel umsetzen kann. Hintergrund dieses Geräte-Automatismus ist, dass die GPS-Satellitenbetreiber in der Regel die IERS-Festlegung entsprechend berücksichtigen, was über eine Vorankündigung und die eigentliche Schaltsekunde selbst gewährleistet wird. Nur auf Grundlage beider Bestandteile können GPS-Empfänger und Zeitserver die Schaltsekunde dann korrekt und zum exakt richtigen Zeitpunkt verarbeiten und auch systemtechnisch umsetzen.
Einige Betreiber kritischer Infrastrukturen bevorzugen hingegen das manuelle Verfahren, da bezüglich sicherem Empfang beider oben genannter Bestandteile ein gewisses Restrisiko besteht und man die Schaltsekunde ohnehin in der Regel auch bei anderen IT-Systemen separat nachführen muss. Auch handelt es sich bei der Festlegung von Schaltsekunden um kein Standardverfahren, so dass auch dies gegebenenfalls eher für einen bewussten, dann manuell vorgenommenen Vorgang auf Seiten des Anwenders spricht. Bei dieser alternativen Lösung der manuellen Einstellung kann man bei unseren DTS-Geräten, zum Beispiel über MOBA NMS oder Telnet SSH, rechtzeitig eine entsprechende Einstellung vornehmen, wobei der DTS-Zeitserver dann auf dieser Basis die Schaltsekunde sicher verarbeitet und auch entsprechend umsetzt.

MiFID ist innerhalb der Europäischen Union seit November 2007 die einschlägige Direktive, wenn es um die Regulierung des Finanzsektors geht. Hierfür ist die ESMA (European Securities and Markets Authority, siehe www.esma.europa.eu) als Behörde zuständig. Zunächst etabliert als MiFID I, wurden die relevanten Vorschriften fortlaufend weiterentwickelt und finden nun als MiFID II – nach längeren Debatten und Anpassungen – endgültig seit Januar 2018 verbindliche Anwendung. Davon betroffen sind zum Beispiel Finanz-Handelsplätze, Investmentgesellschaften und andere Finanzmarktakteure wie natürlich auch Banken (siehe https://www.esma.europa.eu/policy-rules/mifid-ii-and-mifir).

Ein Bestandteil dieser neuen MiFID II-Direktiven besteht darin, dass unter anderem die technischen Standards recht detailliert vorgegeben werden (siehe https://ec.europa.eu/info/sites/info/files/mifid-mifir-its-rts-overview-table_en.pdf). Darin enthalten sind auch ganz spezifische Vorschriften, die unter dem Kapitel RTS 25 auf den „Level of Accuracy of Business Clocks“, also die Zeitsynchronisation und die Beschaffenheit notwendiger Zeitstempel im IT-System, abstellen (siehe http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2017.087.01.0148.01.ENG&toc=OJ:L:2017:087:TOC).

In groben Zügen zusammengefasst, gibt es dabei elementare Änderungen zum bisherigen Status Quo. Wie bisher soll für „Business Clocks used by Operators“ – darunter würde man in der Praxis wohl vereinfacht die finanztechnischen IT-Infrastrukturen verstehen – auch weiterhin die „Coordinated Universal Time“ (UTC) als Zeitstempel-Referenzzeit dienen. Im Gegensatz zu früher lässt man aber nur noch eine Abweichung von 100 µs zu, was die Genauigkeit gegenüber UTC auf Anwendungsebene betrifft. Ebenso verschärft wurden die Anforderungen im Bezug auf die Auflösung des Zeitstempels, die häufig nur noch 1 µs betragen darf. Details hierzu sind den Tabellen 1 und 2 des o.g. Standards RTS 25 zu entnehmen.

Ganz konkret auf den Einsatz von Zeitserver-Geräten bezogen folgt daraus, dass herkömmliche NTP-Server für die präzise Zeitsynchronisation derartiger Finanzsysteme und ihrer Prozess-Laufzeiten nicht mehr ausreichend sind. Als in der Fachwelt durchweg akzeptiert gilt mittlerweile die Erkenntnis, dass man zur Umsetzung oben genannter MiFID II-Anforderungen nunmehr PTP-Zeitserver laut IEEE 1588 einsetzen muss. Weitere Details zu UTC, NTP und PTP sind übrigens unseren FAQs zu entnehmen.

Bei der praktischen Umsetzung dieser geschäftsspezifischen Uhrenvorschriften gibt es allerdings in den Finanzunternehmen häufig Klärungsbedarf. Was genau ist im konkreten Fall unter „business clocks“ zu verstehen, welche IT-Infrastruktur gilt es zu synchronisieren, wie und wo entstehen überhaupt relevante Laufzeiten? Wie kann man diese Laufzeiten dann sinnvoll und belegbar messen, welche Prozesslaufzeit entsteht in der Standard-Software, wie macht man die „Trading-Maschine“ (Hard- und Software) also insgesamt wirklich MiFID II-konform? Wie kommt man darüber hinaus der gesetzlichen Auflage nach, die „Vereinbarkeit des Rückverfolgbarkeitssystems“ jährlich zu überprüfen?

Es ist voraussichtlich kaum möglich, nur eine standardisierte und einheitliche System- und Gerätelösung für alle Anwendungen anzubieten. Denn nicht nur die reine Produktspezifikation des PTP-Zeitservers – bei uns wäre dies der DTS 4160.grandmaster – ist dafür wichtig, sondern darüber hinaus noch eine Fülle projektspezifischer Belange. Gerne stehen wir Ihnen hierfür als spezialisierter Projektpartner zur Verfügung.

Alle Daten werden in der Datenbank des Microsoft Azure-Cloud-Dienstanbieters gespeichert und regelmäßig an drei geografisch unterschiedlichen Standorten gesichert und archiviert.

Daten werden durch moderne Verschlüsselungsprotokolle geschützt. Die Verbindung verwendet das Protokoll TLS 1.2. Es wird unter Verwendung des AES_256_CBC-Standards mit Nachrichtenauthentifizierungsalgorithmus und Schlüsselaustauschmechanismus verschlüsselt.

Ja, Standarddaten können in csv, xml, pdf exportiert werden.

Die Anzahl der in einem System angeschlossenen und registrierten Arbeitsplätze und Terminals ist unbegrenzt. Sie zahlen immer für die Anzahl der Mitarbeiter, unabhängig von der Anzahl der Arbeitsplätze.

Die Anzahl der Mitarbeiter ist nicht begrenzt.

Nein, eine Internetverbindung reicht.

Nein, es muß nichts installiert werden. Sie können sich von jedem Computer mit Internetverbindung in Ihren Nutzer-Account einloggen.

Möchten Sie das System testen, kontaktieren Sie bitte unseren Vertrieb. Auf Wunsch erhalten Sie auch gerne eine Online-Präsentation des Systems.

Das System ist sehr flexibel und erfüllt dank seiner vielfältigen Einstellungsmöglichkeiten die meisten Anforderungen. Wenn Ihnen noch ein individuelles Feld fehlt, das Sie für Ihr Geschäft benötigen, wenden Sie sich bitte an unsere Verkaufsabteilung. Als Systemhersteller können wir Ihnen die Entwicklung dieser Sonderanfertigungen anbieten.

Das System wird ständig weiterentwickelt. Wir sind uns der Dynamik der Gegenwart bewusst und deshalb wird das System ständig auf der Grundlage neu entstehender Bedürfnisse aktualisiert. Ein eigenes, umfangreiches Entwicklungsteam stellt sicher, dass das ZWS-Web-Anwesenheitssystem immer auf dem neusten Stand ist und hohe Anforderungen an Funktionalität und Qualität erfüllt.

Eine mehrstufige Hilfedatenbank ist auf dem System verfügbar. Wenn Sie die Antworten auf Ihre Fragen darin nicht finden, können Sie unseren technischen Support per Telefon und E-Mail kontaktieren.