---
adr: ADR-0001
title: Architekturprinzipien von YachtMemory
category: Grundlagen
status: Accepted
version: 1.0
date: 2026-08-11
pdf: ADR-0001-Architekturprinzipien-v1.0.pdf
---

# ADR-0001 - Architekturprinzipien von YachtMemory

## 1. Zweck dieses Dokuments

Dieses Dokument beschreibt die grundlegenden Architekturprinzipien von YachtMemory. Es bildet die fachliche und konzeptionelle Grundlage für die nachfolgenden Architecture Decision Records des Projekts.

Im Unterschied zu den späteren ADRs behandelt dieses Dokument keine einzelne technische Entscheidung. Es beschreibt die Überlegungen, aus denen sich die Architektur des Gesamtsystems entwickelt hat, und legt die Grundsätze fest, an denen weitere Architekturentscheidungen gemessen werden sollen.

Die hier beschriebenen Prinzipien wurden nicht vor Beginn der Implementierung vollständig festgelegt. Sie sind während der Entwicklung von YachtMemory schrittweise entstanden. Unterschiedliche Ansätze wurden implementiert, mit realen Telemetriedaten erprobt und teilweise wieder verändert. Erst nachdem sich bestimmte Strukturen im praktischen Betrieb bewährt hatten, wurden sie als allgemeine Architekturprinzipien erkannt.

Diese ADR dokumentiert daher keine Zielarchitektur, die erst noch umgesetzt werden soll. Sie beschreibt die wesentlichen Eigenschaften einer Architektur, die bereits implementiert und praktisch erprobt ist.

Das Dokument richtet sich an Entwickler und Architekten, die YachtMemory verstehen oder weiterentwickeln. Kenntnisse der eingesetzten Technologien sowie grundlegende Kenntnisse der Bordtechnik moderner Yachten und der praktischen Fahrtenschifffahrt werden vorausgesetzt. Die ADR ersetzt weder die technische Dokumentation einzelner Komponenten noch die Dokumentation des Quellcodes.

## 2. Ausgangssituation

Moderne Yachten verfügen über eine große Zahl von Sensoren und elektronischen Systemen.

Navigationssysteme erfassen Position, Kurs, Geschwindigkeit und Wassertiefe. Wetterinstrumente messen Wind, Luftdruck sowie Luft- und Wassertemperatur. Maschinensteuerungen stellen Drehzahlen, Temperaturen, Drücke, Betriebsstunden und Verbrauchswerte bereit. Batteriesysteme liefern Spannung, Strom, Ladezustand, Zellspannungen und weitere elektrische Größen.

Je nach Ausstattung des Schiffes kommen zahlreiche weitere Messgrößen hinzu.

Diese Systeme erfüllen ihre jeweilige Aufgabe sehr gut. Sie messen und zeigen an. Viele Systeme besitzen zusätzlich Alarmierungs-, Diagnose- oder begrenzte Aufzeichnungsfunktionen.

Die Daten werden jedoch überwiegend aus der Perspektive des jeweiligen Systems betrachtet.

Der Plotter kennt die Position und die Geschwindigkeit des Schiffes. Das Batteriesystem kennt den aktuellen Strom und Ladezustand. Die Maschinensteuerung kennt Drehzahl und Leistung. Das Windinstrument kennt Windgeschwindigkeit und Windrichtung.

Jeder einzelne Messwert kann dabei vollkommen korrekt sein.

Was in der Regel fehlt, ist der Zusammenhang zwischen diesen Beobachtungen über längere Zeit.

Genau an dieser Stelle setzt YachtMemory an.

## 3. Der gemeinsame Zeitstrahl

Die grundlegende Idee von YachtMemory besteht darin, die Beobachtungen unterschiedlicher Systeme dauerhaft zu erfassen und auf einen gemeinsamen Zeitbezug zu legen.

Dadurch verändert sich die Bedeutung der Daten.

Aus einzelnen Messwerten entstehen zeitlich miteinander vergleichbare Beobachtungen des Schiffes und seiner Umgebung.

Ein Wert für die Antriebsleistung ist für sich genommen zunächst lediglich eine technische Messgröße. Wird gleichzeitig betrachtet, mit welcher Geschwindigkeit sich das Schiff bewegt, welcher Wind herrscht und unter welchen weiteren Bedingungen die Fahrt stattfindet, entsteht ein Zusammenhang.

Dieser Zusammenhang kann über Tage, Monate und schließlich Jahre untersucht werden.

Damit werden Informationen zugänglich, für die an Bord kein unmittelbarer Sensor existiert.

Ein anschauliches Beispiel ist der hydrodynamische Widerstand des Unterwasserschiffes.

Für den normalen Betrieb einer Yacht existiert kein Sensor, der unmittelbar den Bewuchs des Rumpfes misst. Die Auswirkungen eines zunehmenden Bewuchses sind jedoch in anderen Messgrößen enthalten.

Benötigt ein Schiff unter vergleichbaren äußeren Bedingungen im Laufe der Zeit zunehmend mehr Antriebsleistung, um dieselbe Geschwindigkeit zu erreichen, hat sich eine Eigenschaft des Gesamtsystems verändert. Werden Wind und andere relevante Einflussgrößen berücksichtigt, kann die Entwicklung dieser Relation einen Hinweis auf eine Veränderung des hydrodynamischen Widerstands geben.

YachtMemory misst den Bewuchs dabei nicht.

Es bewahrt die Beobachtungen, aus denen eine solche Veränderung später abgeleitet werden kann.

Diese Unterscheidung ist wesentlich. Die Architektur soll nicht bereits bei der Datenerfassung entscheiden müssen, welche Erkenntnisse später aus den Daten gewonnen werden. Zum Zeitpunkt einer Messung kann eine spätere Fragestellung noch vollkommen unbekannt sein.

Die langfristige Speicherung erhält deshalb nicht nur historische Messwerte. Sie erhält die Möglichkeit, später Zusammenhänge zu untersuchen, an die bei der Erfassung noch niemand gedacht hat.

Der gemeinsame Zeitstrahl ist damit keine bloße technische Eigenschaft der Datenspeicherung. Er gehört zu den grundlegenden fachlichen Eigenschaften von YachtMemory.

## 4. Das digitale Langzeitgedächtnis

Der Begriff des digitalen Langzeitgedächtnisses beschreibt diesen Gedanken genauer als der Begriff eines Datenloggers.

Ein Datenlogger zeichnet Messwerte auf. Ein Langzeitgedächtnis muss darüber hinaus ermöglichen, Beobachtungen aus unterschiedlichen Zeiten und unterschiedlichen Quellen später wieder miteinander in Beziehung zu setzen.

Der Unterschied wird insbesondere bei langen Betrachtungszeiträumen deutlich.

Während einer Fahrt sind die aktuellen Werte entscheidend. Der Skipper interessiert sich für die gegenwärtige Windgeschwindigkeit, die verfügbare Batteriekapazität oder die aktuelle Wassertiefe.

Für eine langfristige Betrachtung sind dagegen häufig nicht die einzelnen Werte interessant, sondern ihre Entwicklung und ihre Beziehungen untereinander.

Wie hat sich der Energiebedarf des Schiffes verändert?

Unter welchen Bedingungen treten bestimmte Belastungen auf?

Wie verändert sich die Batteriekapazität über mehrere Jahre?

Welche Betriebsbedingungen führen regelmäßig zu erhöhten Temperaturen?

Wie unterscheiden sich vergleichbare Fahrzustände vor und nach einer Wartung?

Solche Fragen lassen sich nicht beantworten, indem lediglich der aktuelle Zustand gespeichert wird. Sie setzen voraus, dass die ursprünglichen Beobachtungen über lange Zeiträume erhalten bleiben und später unter neuen Fragestellungen ausgewertet werden können.

Daraus folgt eine wichtige Eigenschaft von YachtMemory:

Die spätere Fragestellung darf nicht bereits bei der Datenerfassung bekannt sein müssen.

Das unterscheidet langfristige Telemetrie wesentlich von vielen klassischen Monitoring-Systemen.

## 5. Beobachtung und Interpretation

Aus dem Konzept des Langzeitgedächtnisses ergibt sich eine grundlegende Trennung innerhalb der Architektur:

Beobachtung und Interpretation sind unterschiedliche Arten von Daten.

Eine Beobachtung ist ein Messwert, der zu einem bestimmten Zeitpunkt empfangen wurde.

Eine Interpretation entsteht durch die Verarbeitung einer oder mehrerer Beobachtungen.

Diese Unterscheidung erscheint zunächst selbstverständlich, hat jedoch weitreichende Konsequenzen.

Eine gemessene Windgeschwindigkeit ist eine Beobachtung.

Eine aus Positionsdaten erkannte Fahrtstrecke ist eine Interpretation.

Eine gemessene Kettenlänge ist eine Beobachtung.

Ein aus Position, Geschwindigkeit, Aufenthaltsdauer und weiteren Messgrößen erkannter Ankeraufenthalt ist eine Interpretation.

Eine gemessene elektrische Leistung ist eine Beobachtung.

Eine langfristige Veränderung des Leistungsbedarfs bei vergleichbaren Fahrzuständen ist eine Interpretation.

Die Architektur behandelt diese beiden Ebenen bewusst unterschiedlich.

Beobachtungen bilden die Grundlage, auf der Interpretationen entstehen. Eine Interpretation darf jedoch nicht rückwirkend die Beobachtung verändern, aus der sie entstanden ist.

Nur dadurch bleibt eine spätere Neubewertung möglich.

## 6. Rohdaten bleiben erhalten

Aus der Trennung zwischen Beobachtung und Interpretation folgt das erste zentrale Architekturprinzip:

Die ursprünglichen Telemetriedaten werden durch fachliche Auswertungen nicht verändert.

Eine neue Berechnungsmethode darf zu einem anderen Ergebnis kommen. Sie darf jedoch nicht die Messwerte anpassen, damit sie besser zu diesem Ergebnis passen.

Dieser Grundsatz ist für ein Langzeitgedächtnis wesentlich.

Algorithmen entwickeln sich weiter. Fachliche Annahmen können sich ändern. Fehler in einer Auswertung können erkannt werden. Neue Erkenntnisse können dazu führen, dass historische Daten unter völlig anderen Gesichtspunkten betrachtet werden.

Solange die ursprünglichen Beobachtungen vorhanden sind, kann jede dieser Auswertungen erneut durchgeführt werden.

Werden dagegen die Rohdaten durch spätere Interpretationen verändert, geht diese Möglichkeit verloren.

Das bedeutet nicht, dass Telemetriedaten unter allen Umständen unantastbar wären. Technische Datenfehler können auftreten und müssen gegebenenfalls korrigiert werden. Eine solche Korrektur ist jedoch eine Datenreparatur und keine fachliche Auswertung. Sie muss als bewusster Eingriff behandelt, abgesichert und überprüft werden.

Damit bleibt die Richtung der Abhängigkeit erhalten:

Beobachtung -> Auswertung -> fachliches Ergebnis

und niemals umgekehrt.

## 7. Fachliche Objekte sind reproduzierbare Ableitungen

Nicht jede Information muss bei jedem Aufruf erneut aus Millionen Rohdaten berechnet werden.

YachtMemory verwendet deshalb neben den ursprünglichen Telemetriedaten auch abgeleitete fachliche Objekte.

Ein Beispiel dafür sind erkannte Ankeraufenthalte.

Ein Ankeraufenthalt besitzt Eigenschaften wie Beginn und Ende, Position, Dauer, maximale Wassertiefe, Schwoikreis oder während des Aufenthalts beobachtete maximale Kettenlänge. Diese Informationen sind für spätere Anwendungen wesentlich geeigneter als die zugrunde liegenden einzelnen Telemetriedatensätze.

Entscheidend ist jedoch:

Das fachliche Objekt ersetzt nicht seine Quelldaten.

Es stellt eine reproduzierbare Interpretation dieser Daten dar.

Diese Eigenschaft erlaubt es, Berechnungsverfahren weiterzuentwickeln. Wird beispielsweise die Erkennung eines Ankeraufenthalts verbessert, können vorhandene fachliche Objekte verworfen und aus den ursprünglichen Messdaten neu aufgebaut werden.

Das ist ein grundlegender Unterschied zu einer Architektur, in der einmal berechnete Ergebnisse selbst zur einzigen Datenquelle späterer Verarbeitung werden.

YachtMemory versucht, die Herkunft fachlicher Aussagen nachvollziehbar zu erhalten.

## 8. Zeit ist die gemeinsame Integrationsdimension

Sensoren an Bord arbeiten nicht synchron.

Ein Positionswert kann im Sekundentakt eintreffen, ein Batteriewert einmal pro Minute und ein anderer Messwert nur bei einer Änderung. Manche Datenquellen besitzen unterschiedliche Abtastraten, andere fallen zeitweise vollständig aus.

Eine gemeinsame Datensatzstruktur, in der zu jedem Zeitpunkt sämtliche Messgrößen vorhanden sein müssen, würde dieser Realität nicht entsprechen.

YachtMemory behandelt deshalb den Zeitbezug als gemeinsame Integrationsdimension.

Die Messgrößen dürfen zunächst unabhängig voneinander eintreffen und gespeichert werden. Erst bei einer fachlichen Auswertung werden die relevanten Beobachtungen auf geeignete gemeinsame Zeitbereiche bezogen.

Die Größe dieser Zeitbereiche hängt von der Fragestellung ab.

Eine Live-Anzeige benötigt eine andere zeitliche Auflösung als eine Monatsauswertung. Eine Jahresanalyse benötigt keine Sekundenwerte, darf aber langfristige Entwicklungen nicht durch ungeeignete Verdichtung verfälschen.

Daraus folgt, dass zeitliche Aggregation keine reine Darstellungsfrage ist.

Sie gehört zur fachlichen Verarbeitung der Telemetriedaten.

Dieses Prinzip bildet die Grundlage der später separat dokumentierten Zeitreihenarchitektur.

## 9. Rohdaten, Verarbeitung und Darstellung werden getrennt

Aus den bisherigen Überlegungen ergibt sich eine klare Richtung des Datenflusses:

Sensoren und Bordsysteme
        |
        v
Telemetrie-Rohdaten
        |
        v
fachliche Verarbeitung
        |
        v
fachliche Information
        |
        v
API
        |
        v
Portal / Widget / Anwendung

Die einzelnen Ebenen haben unterschiedliche Verantwortlichkeiten.

Die Telemetrieebene bewahrt Beobachtungen.

Die Verarbeitungsebene erkennt Zusammenhänge, aggregiert Daten oder erzeugt fachliche Objekte.

Die API stellt diese Informationen in einer für Anwendungen geeigneten Form bereit.

Das Widget stellt sie dar.

Diese Trennung wurde während der Entwicklung zunehmend konsequent umgesetzt. Frühere Ansätze, bei denen Darstellungslogik und Datenverarbeitung enger miteinander verbunden waren, erwiesen sich als schlecht wiederverwendbar und schwer konsistent zu halten.

Daraus entstand ein weiteres Grundprinzip:

Die Darstellung soll fachliche Informationen verwenden, aber nicht selbst erzeugen.

Ein Widget darf entscheiden, wie eine Windgeschwindigkeit dargestellt wird. Es soll nicht entscheiden, wie aus Rohmessungen eine fachlich gültige Windstatistik entsteht.

Ein Kartenwidget darf einen Ankerplatz darstellen. Es soll nicht anhand von GPS-Punkten selbst entscheiden, ob dort ein Ankeraufenthalt stattgefunden hat.

Diese Trennung hält die Benutzeroberfläche austauschbar und die fachliche Logik wiederverwendbar.

## 10. APIs bilden die Grenze zur Darstellung

Die öffentlichen APIs von YachtMemory sind nicht lediglich ein technischer Transportweg zwischen PHP und JavaScript.

Sie bilden eine bewusste Architekturgrenze.

Ein Widget kennt die fachliche API, nicht die Struktur der Telemetriedatenbank.

Dadurch wird verhindert, dass Wissen über Tabellen, Kategorien oder schiffsspezifische Datenquellen in die Darstellung durchsickert.

Diese Entkopplung ist besonders wichtig, weil YachtMemory unterschiedliche Schiffe unterstützen soll.

Zwei Schiffe können dieselbe fachliche Messgröße aus unterschiedlichen technischen Quellen erhalten. Für die Darstellung ist diese Unterscheidung unerheblich. Ein Widget benötigt beispielsweise eine Batteriespannung oder eine Windgeschwindigkeit, nicht die Kenntnis darüber, aus welcher Tabelle oder welchem Bussystem der Wert ursprünglich stammt.

Die API übersetzt deshalb zwischen der internen Datenorganisation und dem fachlichen Informationsbedarf der Anwendung.

Diese Grenze ermöglicht zugleich, dieselbe fachliche Logik in unterschiedlichen Oberflächen zu verwenden.

Ein öffentliches Widget, eine Portalseite oder eine spätere Analyseanwendung können auf dieselben fachlichen Daten zugreifen, ohne deren Erzeugung jeweils neu implementieren zu müssen.

## 11. Fachlogik gehört nicht in Widgets

Widgets sind bewusst kleine, eigenständige Darstellungseinheiten.

Sie besitzen Verantwortung für Layout, Interaktion, Skalierung, Sprache und die visuelle Aufbereitung der von einer API gelieferten Informationen.

Sie besitzen keine Verantwortung für die Interpretation der Telemetrie.

Diese Entscheidung entstand nicht aus einem abstrakten Schichtenmodell, sondern aus praktischer Erfahrung.

Sobald fachliche Berechnungen in JavaScript oder in einzelnen Widgets stattfinden, entstehen mehrere Probleme:

Die gleiche Berechnung wird an verschiedenen Stellen unterschiedlich implementiert. Änderungen müssen mehrfach durchgeführt werden. Ergebnisse können voneinander abweichen. Und eine spätere Verwendung derselben Information außerhalb des Widgets erfordert eine erneute Implementierung.

Die konsequente Verlagerung fachlicher Verarbeitung auf die Server- und Serviceebene vermeidet diese Abhängigkeit.

Ein Widget soll im Zweifelsfall ersetzbar sein, ohne dass dadurch fachliches Wissen verloren geht.

## 12. Schiffsspezifische Datenquellen werden gekapselt

YachtMemory ist nicht auf ein einzelnes Schiff beschränkt.

Gleichzeitig ist es unrealistisch anzunehmen, dass alle Schiffe ihre Telemetrie identisch organisieren.

Deshalb darf die Zuordnung zwischen einem fachlichen Schiff und seiner konkreten Telemetriedatenbank nicht über den gesamten Quellcode verteilt sein.

Diese Verantwortung wird zentral gekapselt.

Ein Dienst, der Daten für ein Schiff benötigt, fragt nach dem Schiff. Er soll nicht selbst wissen müssen, welche konkrete Datenbank dahinterliegt.

Damit entsteht eine wichtige Trennung:

fachliche Identität des Schiffes
              |
              v
       Datenbank-Routing
              |
              v
konkrete Telemetriedatenbank

Diese Entscheidung reduziert nicht nur technische Redundanz. Sie verhindert auch, dass die physische Organisation der Datenbanken Teil der Fachlogik wird.

Die konkrete Umsetzung dieses Prinzips durch den TelemetryDbRouter wird in einer eigenen ADR beschrieben.

## 13. Auflösung richtet sich nach der Fragestellung

Langzeitdaten stellen zwangsläufig Anforderungen an die Datenmenge.

Eine Yacht kann innerhalb eines Jahres Millionen einzelner Positions- oder Sensormessungen erzeugen. Es wäre weder sinnvoll noch notwendig, sämtliche Rohpunkte für jede Darstellung an den Browser zu übertragen.

Gleichzeitig darf eine Optimierung die fachliche Aussage nicht verfälschen.

Daraus folgt:

Die erforderliche zeitliche und räumliche Auflösung wird durch die jeweilige Fragestellung bestimmt.

Die Entwicklung des Live-Track-Widgets hat dieses Prinzip besonders deutlich gemacht.

Für die Darstellung einer Jahresroute ist eine reduzierte Anzahl von Positionspunkten ausreichend und aus Performancegründen notwendig. Beim Hineinzoomen in einen Küstenabschnitt reicht dieselbe grobe Auflösung jedoch nicht mehr aus. Gerade dort können durch die Verbindung weit auseinanderliegender Punkte scheinbare Fahrwege über Land entstehen.

Die Lösung besteht nicht darin, grundsätzlich alle Positionsdaten zu übertragen.

Stattdessen wird die Auflösung an den Betrachtungsmaßstab angepasst. Die Übersicht verwendet eine reduzierte Datenmenge. Bei detaillierter Betrachtung werden für den sichtbaren Ausschnitt feinere Daten nachgeladen.

Dasselbe Prinzip gilt allgemeiner für Zeitreihen.

Eine Jahresanalyse benötigt eine andere Aggregation als eine Sechs-Stunden-Ansicht.

Performance und fachliche Genauigkeit stehen damit nicht grundsätzlich im Widerspruch. Die Architektur muss lediglich den erforderlichen Detaillierungsgrad kennen.

## 14. Fehlende Daten sind Information

Bei einem real betriebenen Schiff sind Datenreihen nicht vollkommen.

Sensoren können ausfallen. Kommunikationsverbindungen können unterbrochen sein. Ein Gerät kann abgeschaltet werden. Messwerte können zeitweise nicht zur Cloud übertragen werden.

Eine Architektur, die solche Lücken automatisch durch plausible Werte ersetzt, würde Beobachtung und Vermutung miteinander vermischen.

YachtMemory behandelt fehlende Messwerte deshalb grundsätzlich als fehlende Messwerte.

Eine Lücke darf dargestellt, bei einer Berechnung berücksichtigt oder fachlich bewertet werden. Sie soll jedoch nicht unbemerkt mit einem angenommenen Wert gefüllt werden.

Dieser Grundsatz hat unmittelbare Bedeutung für spätere Wissensfunktionen.

Eine Aussage ist nur so belastbar wie die Beobachtungen, auf denen sie beruht. Die Kenntnis darüber, dass für einen Zeitraum keine Messung vorliegt, kann deshalb ebenso wichtig sein wie ein vorhandener Messwert.

## 15. Datenqualität hat Vorrang vor scheinbarer Vollständigkeit

Ein Langzeitgedächtnis gewinnt seinen Wert nicht durch die bloße Menge gespeicherter Daten, sondern durch deren Nachvollziehbarkeit.

Deshalb wird eine erkennbare Datenlücke einer scheinbar vollständigen, aber nicht belegbaren Zeitreihe vorgezogen.

Dasselbe gilt für fachliche Ergebnisse.

Wenn eine Aussage aus den vorhandenen Beobachtungen nicht zuverlässig abgeleitet werden kann, soll das System dies erkennen können, anstatt eine Genauigkeit vorzutäuschen, die nicht vorhanden ist.

Dieses Prinzip wird mit zunehmender analytischer Tiefe wichtiger.

Bei einer einfachen Anzeige ist ein fehlender Messwert unmittelbar sichtbar. Bei einer statistischen oder später wissensbasierten Aussage kann dagegen leicht verborgen bleiben, auf welcher Datenbasis sie entstanden ist.

Die Architektur muss deshalb langfristig nicht nur Ergebnisse, sondern auch deren Datenbasis und Qualität berücksichtigen können.

## 16. Das System muss neue Fragestellungen zulassen

Ein wesentliches Ziel der Architektur besteht darin, heutige Messdaten für Fragestellungen nutzbar zu halten, die erst später entstehen.

Das ist insbesondere auf einer Yacht relevant, weil sich Ausstattung, Nutzung und technische Fragestellungen über viele Jahre verändern.

Ein heute aufgezeichneter Wert kann in mehreren Jahren Teil einer Analyse werden, deren fachliches Modell heute noch nicht existiert.

Daraus folgt eine gewisse Zurückhaltung bei frühzeitiger Verdichtung.

Verdichtete Daten sind für bestimmte Aufgaben effizient. Sie können jedoch Informationen verlieren, die für eine spätere, heute noch unbekannte Fragestellung relevant wären.

Die ursprünglichen Beobachtungen bleiben deshalb die langfristige Referenz. Aggregationen, fachliche Objekte und Analysen dürfen zusätzlich gespeichert werden, ersetzen aber nicht diese Referenz.

Das ist die Voraussetzung dafür, dass YachtMemory mit der Erfahrung des Schiffes wachsen kann.

## 17. Berechnetes Wissen muss grundsätzlich neu berechenbar bleiben

Aus den bisherigen Prinzipien ergibt sich eine weitere Konsequenz.

Fachliche Erkenntnisse sind keine unveränderlichen Wahrheiten des Systems.

Sie sind Ergebnisse eines bestimmten Verfahrens auf einer bestimmten Datenbasis.

Wird das Verfahren verbessert, muss es möglich sein, dieselben historischen Beobachtungen erneut auszuwerten.

Dieses Prinzip wurde bei der Ankerplatzerkennung praktisch angewendet. Die Tabelle der erkannten Ankerplätze kann neu aufgebaut werden, wenn sich der Algorithmus oder die zugrunde liegenden Daten ändern.

Dasselbe Prinzip soll auch für zukünftige Analysen gelten.

Ein späteres Modell zur Erkennung von Veränderungen des Unterwasserschiffes wird sich wahrscheinlich weiterentwickeln. Neue Einflussgrößen können hinzukommen. Vergleichsverfahren können verbessert werden. Eine zunächst einfache Korrelation kann später durch ein besseres Modell ersetzt werden.

Solange die ursprünglichen Beobachtungen erhalten bleiben, ist diese Entwicklung möglich.

YachtMemory speichert deshalb nicht nur Ergebnisse.

Es erhält die Möglichkeit, zu neuen Ergebnissen zu kommen.

## 18. Erkenntnisse müssen nachvollziehbar bleiben

Je weiter YachtMemory von der reinen Anzeige in Richtung Analyse und Wissen entwickelt wird, desto wichtiger wird die Nachvollziehbarkeit einer Aussage.

Wenn das System später beispielsweise feststellt, dass sich der Energiebedarf des Schiffes unter vergleichbaren Bedingungen verändert hat, genügt die Aussage allein nicht.

Es muss zumindest prinzipiell nachvollziehbar sein,

- welche Messgrößen betrachtet wurden,
- welcher Zeitraum zugrunde lag,
- welche Daten ausgeschlossen wurden,
- welche Vergleichsbedingungen verwendet wurden und
- welches Verfahren zur Aussage geführt hat.

Das bedeutet nicht, dass jede Benutzeroberfläche sämtliche Details darstellen muss.

Die Architektur soll jedoch vermeiden, Wissen zu erzeugen, dessen Herkunft nicht mehr rekonstruierbar ist.

Dies ist eine direkte Fortsetzung der Trennung zwischen Beobachtung und Interpretation.

## 19. Reale Schiffe bestimmen die Architektur

YachtMemory wird für reale Schiffe entwickelt und muss deren Unvollkommenheiten akzeptieren.

Sensoren liefern nicht immer ideale Werte. Netzwerke sind nicht permanent verfügbar. Datenquellen unterscheiden sich zwischen Schiffen. Umbauten verändern die technische Ausstattung. Ein Sensor kann ersetzt werden, während die fachliche Messgröße dieselbe bleibt.

Eine Architektur, die ausschließlich von idealen, synchronen und dauerhaft verfügbaren Datenquellen ausgeht, wäre für diesen Einsatz ungeeignet.

Deshalb werden Robustheit gegenüber fehlenden Daten, zeitlich versetzten Messungen und unterschiedlichen technischen Quellen nicht als Sonderfälle betrachtet.

Sie gehören zum normalen Betriebsmodell.

Dieser Grundsatz ist auch der Grund dafür, dass die Architektur fachliche Messgrößen langfristig von ihren konkreten technischen Quellen trennen muss.

Ein Schiff kann sich technisch verändern, ohne dass dadurch seine historische Erinnerung verloren gehen darf.

## 20. Architektur wird an realen Daten überprüft

Die Architektur von YachtMemory wurde nicht vollständig vor der Implementierung festgelegt.

Viele der heute geltenden Prinzipien wurden erst während der Entwicklung sichtbar.

Die Arbeit an den öffentlichen Widgets war dafür besonders aufschlussreich.

Die Windhistorie zeigte Anforderungen an die zeitliche Aggregation.

Die Kettenkrafthistorie zeigte, dass Messgrößen fachlich ereignisbezogen sein können und nicht jede Größe sinnvoll als kontinuierliche Zeitreihe betrachtet werden sollte.

Das Batteriesystem zeigte die Notwendigkeit, unterschiedliche technische Datenquellen in eine gemeinsame fachliche Darstellung zu überführen.

Die Ankerplatzerkennung zeigte die Trennung zwischen Rohmessung und reproduzierbarem fachlichem Objekt.

Der Live-Track zeigte schließlich, dass selbst die notwendige Datenauflösung von der jeweiligen Betrachtung abhängt.

Diese Erfahrungen führten nicht zu voneinander unabhängigen Sonderlösungen. Vielmehr machten sie gemeinsame Architekturprinzipien sichtbar.

Das ist ein wesentlicher Grund dafür, diese ADR erst jetzt zu schreiben.

Die beschriebenen Grundsätze sind keine Vorgaben für eine noch zu entwickelnde Software. Sie sind eine Zusammenfassung dessen, was sich in der bisherigen Entwicklung als tragfähig erwiesen hat.

## 21. Architekturentscheidungen werden nach ihrer Bewährung dokumentiert

Aus dieser Erfahrung ergibt sich auch eine Regel für die weitere Architekturarbeit.

YachtMemory verwendet ADRs nicht dazu, jede frühe Idee bereits als Architekturentscheidung festzuschreiben.

Bei neuen Fragestellungen dürfen zunächst unterschiedliche Ansätze untersucht und praktisch erprobt werden. Erst wenn eine Entscheidung fachlich verstanden, implementiert und in einem hinreichend realistischen Umfeld überprüft wurde, soll sie als dauerhafte Architekturentscheidung dokumentiert werden.

Das bedeutet nicht, dass Architektur erst nach dem Programmieren bedacht wird.

Im Gegenteil: Architekturfragen werden vor und während der Implementierung ausdrücklich diskutiert.

Die formale Festschreibung erfolgt jedoch erst dann, wenn ausreichend praktische Erkenntnisse vorliegen.

Damit soll verhindert werden, dass eine theoretisch elegante Entscheidung zum Dogma wird, obwohl die praktische Erfahrung inzwischen etwas anderes zeigt.

## 22. Konsequenzen für die Weiterentwicklung

Die in dieser ADR beschriebenen Prinzipien begrenzen zukünftige Lösungen bewusst.

Eine neue Funktion sollte nicht allein danach beurteilt werden, ob sie technisch funktioniert.

Sie muss auch in das bestehende Informationsmodell passen.

Insbesondere sind bei zukünftigen Entwicklungen folgende Fragen zu stellen:

Ist die verwendete Information eine Beobachtung oder bereits eine Interpretation?

Bleiben die ursprünglichen Beobachtungen erhalten?

Kann ein berechnetes Ergebnis später aus denselben Rohdaten neu erzeugt werden?

Ist die Fachlogik unabhängig von ihrer Darstellung?

Ist die konkrete technische Datenquelle ausreichend von der fachlichen Bedeutung getrennt?

Werden zeitlich unterschiedliche Messgrößen auf eine fachlich sinnvolle Weise zusammengeführt?

Bleiben fehlende oder unsichere Daten als solche erkennbar?

Kann eine spätere Analyse nachvollziehen, worauf ihre Aussage beruht?

Diese Fragen sind wichtiger als die Wahl eines konkreten Frameworks oder einer einzelnen Implementierungstechnik.

Technologien können ersetzt werden.

Die grundlegende Bedeutung der gespeicherten Informationen sollte dabei erhalten bleiben.

## 23. Bewährungsnachweis

Die beschriebenen Prinzipien sind im aktuellen Entwicklungsstand von YachtMemory in mehreren Bereichen praktisch umgesetzt.

Die Telemetriedaten verschiedener Bordsysteme werden langfristig gespeichert und über einen gemeinsamen Zeitbezug ausgewertet.

Der Zugriff auf schiffsspezifische Telemetriedaten ist von den aufrufenden Anwendungen gekapselt.

Öffentliche Widgets greifen über definierte APIs auf fachlich aufbereitete Daten zu und besitzen keinen direkten Datenbankzugriff.

Zeitreihen werden abhängig vom Betrachtungszeitraum aggregiert.

Fachliche Objekte wie erkannte Ankeraufenthalte werden aus den ursprünglichen Telemetriedaten erzeugt und können bei Änderungen der Datenbasis oder des Berechnungsverfahrens neu aufgebaut werden.

Die öffentliche Schiffseite verwendet dieselben grundlegenden Daten- und API-Strukturen für unterschiedliche, voneinander unabhängige Widgets.

Die adaptive Auflösung des Live-Tracks zeigt darüber hinaus, dass auch Performanceoptimierungen innerhalb derselben Architektur vorgenommen werden können, ohne die fachliche Datenbasis zu verändern.

Diese Anwendungen stellen keinen Beweis dafür dar, dass jede zukünftige Fragestellung bereits gelöst ist.

Sie zeigen jedoch, dass die grundlegende Trennung zwischen Beobachtung, Verarbeitung und Darstellung in unterschiedlichen fachlichen Bereichen funktioniert.

## 24. Abgrenzung

Diese ADR legt keine konkreten Datenbankschemata fest.

Sie definiert keine API-Endpunkte.

Sie beschreibt keine Widget-Schnittstellen und keine Programmierrichtlinien.

Sie legt auch nicht fest, mit welchen mathematischen oder statistischen Verfahren zukünftige Analysen durchgeführt werden.

Diese Fragen werden dort entschieden, wo die jeweilige fachliche und technische Problemstellung ausreichend bekannt ist.

ADR-0001 definiert stattdessen die Bedingungen, unter denen solche Entscheidungen mit der Gesamtarchitektur von YachtMemory vereinbar sind.

## 25. Beziehung zu den folgenden ADRs

Die weiteren ADRs konkretisieren einzelne der hier beschriebenen Prinzipien.

Insbesondere werden separate Entscheidungen benötigt für:

- die Trennung und Organisation der Telemetriedatenbanken,
- das Routing zwischen Schiff und Telemetriedatenbank,
- die Verarbeitung heterogener Telemetriedaten,
- die Bildung gemeinsamer Zeitreihen aus asynchron eintreffenden Messgrößen,
- die Architektur der öffentlichen APIs,
- die Architektur der Widgets,
- die Internationalisierung der Widgets,
- die Generierung öffentlicher Schiffsseiten,
- die Erkennung und Modellierung von Ankeraufenthalten,
- die Ankerplatzanalyse,
- die Darstellung und Aggregation von Batteriesystemen,
- sowie die adaptive räumliche Auflösung langfristiger Tracks.

Diese ADRs sollen die jeweiligen Entscheidungen genauer beschreiben, ohne die hier festgelegten Grundgedanken erneut begründen zu müssen.

## 26. Zusammenfassung der Architekturprinzipien

Aus den bisherigen Erfahrungen lassen sich die grundlegenden Prinzipien von YachtMemory wie folgt zusammenfassen:

1. YachtMemory betrachtet Telemetrie als langfristige Beobachtung des Schiffes und seiner Umgebung.

2. Messwerte unterschiedlicher Systeme werden über einen gemeinsamen Zeitbezug miteinander in Beziehung gesetzt.

3. Die ursprünglichen Beobachtungen bleiben die langfristige Referenz und werden nicht durch spätere Interpretationen ersetzt.

4. Beobachtung und Interpretation sind unterschiedliche Ebenen des Informationsmodells.

5. Fachliche Objekte und Analysen sind reproduzierbare Ableitungen aus den Beobachtungen.

6. Zeitliche Aggregation richtet sich nach der fachlichen Fragestellung und nicht allein nach der Darstellung.

7. Fachliche Verarbeitung, API und Darstellung besitzen getrennte Verantwortlichkeiten.

8. Widgets stellen Informationen dar, erzeugen jedoch keine eigenständige fachliche Wahrheit.

9. Die konkrete technische Datenquelle eines Schiffes wird von ihrer fachlichen Bedeutung getrennt.

10. Fehlende Daten bleiben als fehlende Daten erkennbar.

11. Datenqualität und Nachvollziehbarkeit haben Vorrang vor scheinbarer Vollständigkeit.

12. Die Datenbasis soll auch Fragestellungen ermöglichen, die zum Zeitpunkt ihrer Erfassung noch nicht bekannt waren.

13. Berechnete Erkenntnisse müssen grundsätzlich aus den ursprünglichen Beobachtungen neu erzeugt werden können.

14. Mit zunehmender analytischer Tiefe muss die Herkunft einer Aussage nachvollziehbar bleiben.

15. Performance wird durch eine der Fragestellung angemessene Auflösung erreicht, nicht durch den Verlust der ursprünglichen Datenbasis.

16. Architekturentscheidungen werden an realen Schiffsdaten überprüft und erst nach ihrer Bewährung dauerhaft dokumentiert.

## 27. Schlussbemerkung

YachtMemory wurde nicht entwickelt, um Sensordaten anzuzeigen. Die vorhandenen Bordsysteme können dies bereits und erfüllen diese Aufgabe in ihrem jeweiligen Bereich sehr gut.

Die Aufgabe von YachtMemory beginnt dort, wo die unmittelbare Anzeige endet.

Das System bewahrt die Beobachtungen unterschiedlicher Systeme über lange Zeiträume und stellt zwischen ihnen einen gemeinsamen zeitlichen Zusammenhang her. Dadurch können Beziehungen untersucht werden, die kein einzelner Sensor messen und kein einzelnes Bordsystem erkennen kann.

Der langfristige Wert der Daten liegt deshalb nicht allein darin, einen vergangenen Zustand wieder anzeigen zu können.

Er liegt in der Möglichkeit, später neue Fragen an die Vergangenheit zu stellen.

Aus dieser Überlegung ergeben sich die wesentlichen Architekturentscheidungen des Systems: die Erhaltung der ursprünglichen Beobachtungen, die Trennung von Beobachtung und Interpretation, die zeitliche Zusammenführung heterogener Messgrößen, die reproduzierbare Ableitung fachlicher Informationen und die Trennung dieser Verarbeitung von ihrer Darstellung.

Diese Prinzipien bilden die Grundlage für den nächsten Entwicklungsschritt von YachtMemory.

Bislang hat das System vor allem gezeigt, dass Beobachtungen langfristig erfasst, zusammengeführt und fachlich sinnvoll dargestellt werden können.

Darauf aufbauend kann nun untersucht werden, wie aus diesen Beobachtungen systematisch Zusammenhänge, Erfahrungen und schließlich Wissen über das Schiff gewonnen werden können.
