Vernetzte Maschinen bringen ein Dokumentationsthema mit, das in klassischen PDF-Ablagen oft untergeht: Was passiert nach der Auslieferung, wenn sicherheitsrelevante Softwarestände, Schwachstellenhinweise oder Update-Informationen dazukommen?
Für docks.io ist das ein naheliegender Anwendungsfall. Sobald Dokumentation per QR-Code oder stabiler URL an einer konkreten Maschine hängt, stellt sich nicht nur die Frage nach der Betriebsanleitung, sondern auch nach aktuellen, maschinenbezogenen Zusatzinformationen: Welcher Softwarestand ist installiert? Bis wann läuft der Support? Welcher Hinweis betrifft genau diese Ausführung?
Warum das regulatorisch relevanter wird
Die Europäische Kommission fasst den Cyber Resilience Act (CRA) so zusammen, dass zusammen mit einem Produkt mit digitalen Elementen unter anderem folgende Angaben bereitgestellt werden sollen:
- ein Identifikationselement wie Typ-, Chargen- oder Seriennummer,
- Name beziehungsweise Marke des Herstellers,
- Postanschrift, E-Mail-Adresse oder andere digitale Kontaktdaten,
- gegebenenfalls die Website des Herstellers,
- Informationen und Anweisungen für Nutzerinnen und Nutzer nach Anhang II,
- einschließlich des Enddatums des Supportzeitraums.
Die Kommission ergänzt außerdem: Der Hersteller muss einen Supportzeitraum für das Produkt festlegen, in dem Schwachstellen wirksam behandelt werden. Das Enddatum des Supportzeitraums soll bereits zum Zeitpunkt des Kaufs klar und verständlich angegeben werden.
Für den Maschinen- und Anlagenbau heißt das nicht automatisch, dass jede Release Note zu einem Rechtsdokument wird. Es heißt aber sehr wohl: Lifecycle-Informationen zu Software und Security gehören nicht mehr nur in interne Ticketsysteme. Sie müssen für Nutzer und Betreiber organisatorisch auffindbar sein.
Warum gerade Release Notes und Update-Hinweise dokumentationsnah werden
Die CRA-Zusammenfassung nennt ausdrücklich die Verbindung von Produktidentität, Nutzerinformation und Supportzeitraum. Genau daraus entsteht ein praktisches Problem im Feld:
- Ein Sicherheitshinweis ist nur hilfreich, wenn klar ist, welche Maschine oder Variante betroffen ist.
- Ein Update ist nur sinnvoll einordenbar, wenn erkennbar bleibt, welcher Stand vorher installiert war.
- Ein Supportzeitraum hilft nur, wenn Service, Betreiber und Instandhaltung ihn am konkreten Produktkontext wiederfinden.
Aus Dokumentationssicht spricht deshalb viel dafür, Release Notes, Sicherheitsmeldungen und Update-Hinweise nicht getrennt von der produktbezogenen Dokumentation zu führen. Gemeint ist nicht, dass jede Maschine ein eigenes Softwareportal braucht. Gemeint ist: Der Weg von der Maschine zur richtigen Information sollte kurz und eindeutig sein.
Was die ENISA/JRC-Analyse für die Praxis zeigt
Die ENISA/JRC-Studie zur CRA-Standardisierung ist für industrielle Dokumentationsprojekte interessant, weil sie eine wichtige Grenze benennt: Die Autorinnen und Autoren haben keinen einzelnen Standard gefunden, der für sich allein alle CRA-Anforderungen vollständig erfüllt. Zugleich wird die IEC-62443-Familie als besonders relevante Referenz für industrielle Kontrollsysteme eingeordnet.
Die Studie beschreibt außerdem Lücken zwischen vorhandenen Standards und den CRA-Anforderungen, etwa dort, wo Schwachstellen nicht nur erkannt, sondern auch wirksam behandelt und gepatcht werden müssen.
Für Hersteller vernetzter Maschinen ist das eine nüchterne, aber wichtige Botschaft:
- Ein gutes Dokumentationssystem allein ist kein CRA-Nachweis.
- Ein Security- oder Entwicklungsprozess allein löst aber auch nicht das Auffindbarkeitsproblem im Feld.
- Gerade im Maschinenumfeld müssen Produktidentität, Softwarestand, Supportzeitraum und Nutzerinformation miteinander verknüpft werden.
Was in der digitalen Dokumentation sichtbar sein sollte
Die Quellen schreiben kein bestimmtes UX-Muster vor. Für die Einführung digitaler Dokumentation ergeben sich aber einige sachlich gut begründbare Anforderungen.
1. Betroffene Ausführung eindeutig markieren
Ein Update-Hinweis sollte nicht nur den Produktnamen nennen, sondern nachvollziehbar an Modell, Variante, Softwarestand oder Serienlogik anschließbar sein. Sonst bleibt unklar, ob der Hinweis die konkrete Maschine überhaupt betrifft.
2. Supportende nicht im Vertragsarchiv verstecken
Wenn der Supportzeitraum zum Kaufzeitpunkt klar benannt werden muss, ist es sinnvoll, diese Information später auch im Dokumentationskontext der Maschine wieder auffindbar zu halten – nicht nur in Angebotsunterlagen oder E-Mails.
3. Sicherheitskontakt neben der Sachinformation zeigen
Wenn ein Hersteller digitale Kontaktdaten für das Produkt bereitstellt, sollten Betreiber bei einem sicherheitsrelevanten Hinweis nicht erst zwischen Portal, Vertriebspostfach und allgemeiner Website suchen müssen. Der Kontaktweg gehört an denselben Ort wie die betroffene Produktinformation.
4. Alte und neue Stände nachvollziehbar trennen
Gerade bei vernetzten Maschinen ist die Verwechslungsgefahr hoch: ein Hinweis gilt für Version A, die Anlage läuft aber bereits auf Version B. Eine digitale Dokumentationsumgebung sollte deshalb alte und aktuelle Informationsstände klar unterscheidbar halten.
Die Grenze: Dokumentation ersetzt keine Vulnerability-Organisation
Auch ein sauberer QR-Code-Zugang ersetzt nicht die eigentliche Facharbeit hinter dem Produkt. Die belastbaren Quellen sprechen eher für eine Arbeitsteilung:
- Die Vulnerability- und Update-Prozesse müssen in Entwicklung, Security und Service belastbar organisiert sein.
- Die digitale Dokumentation sorgt dafür, dass die relevanten Informationen am Produktkontext auffindbar, zuordenbar und langfristig nutzbar bleiben.
Gerade in Maschinenprojekten mit langen Lebenszyklen ist das wichtig. Sonst entsteht genau das Risiko, das in der Praxis häufig zu sehen ist: Das Update wurde intern bearbeitet, aber im Feld bleibt unklar, welcher Hinweis für welche Maschine noch gilt.
Vier Einführungsfragen für Hersteller
- Wo sehen Betreiber heute den aktuellen Software- oder Sicherheitsstand einer konkreten Maschine?
- Ist das Enddatum des Supportzeitraums später noch maschinenbezogen auffindbar?
- Lassen sich Sicherheitsmeldungen eindeutig einer Variante, Version oder Serienlogik zuordnen?
- Sind Update-Hinweise, Ansprechpartner und Dokumentation miteinander verknüpft, oder liegen sie getrennt in Service, IT und technischem Redaktionssystem?
Fazit
Für vernetzte Maschinen wird digitale Dokumentation zunehmend zum Ordnungsrahmen für Lifecycle-Informationen. Die EU-Kommission macht beim CRA deutlich, dass Produktidentität, Nutzerinformation, digitale Kontaktwege und Supportzeitraum zusammen gedacht werden müssen. Die ENISA/JRC-Analyse zeigt gleichzeitig, dass dafür kein einzelner Standard und kein einzelnes Tool alles allein lösen wird.
Gerade deshalb sind maschinenbezogen verknüpfte Dokumentationsumgebungen sinnvoll: Sie machen aus verstreuten Update-Hinweisen, Supportinformationen und Produktständen eine auffindbare und belastbare Informationskette am realen Objekt.