Remote- und Wireless-HMI-Hardware entwickeln: Architektur, Funk und Validierung

Remote-HMI und Wireless-HMI sind zwei verschiedene Entwicklungsentscheidungen

Ein Remote-HMI stellt eine Bedienoberfläche räumlich entfernt dar oder bedient sie über eine Client-Server-Verbindung. Ein Wireless-HMI ersetzt dagegen den physischen Datenleiter durch Funk. Beides kann zusammen auftreten, muss es aber nicht. NIST definiert ein HMI ausdrücklich als Hardware oder Software, über die ein Bediener mit einem Controller interagiert; die Spannweite reicht vom Tastenfeld bis zum Industrie-PC mit HMI-Software (NIST HMI Glossary).

Diese Begriffsgrenze verhindert typische Fehlstarts. Ein fest eingebautes Panel kann per Ethernet einen entfernten Server anzeigen und bleibt vollständig kabelgebunden. Ein WLAN-Panel kann die Visualisierung lokal ausführen und ist trotzdem kein Remote-Client. Ein mobiles Gerät kann beides sein. Wer zuerst „WLAN-Modul ja oder nein?“ fragt, hat Bedienpfad, Energiequelle und Rückfallebene noch nicht festgelegt.

Für HMI-Baugruppen umfasst die herstellbare Hardware den Frontaufbau mit Display, Touchsensor oder Tasten, Grafikoverlay, Schaltung, Steckverbindern sowie mechanischen und elektrischen Schnittstellen zum Gehäuse. Remote-Access-Software, PLC-/SCADA-Programmierung, OT-Netzwerkbetrieb und die Freigabe von Maschinen-Safety liegen außerhalb dieses Baugruppenumfangs. Eine grundlegende Einordnung der physischen Ebenen bietet ergänzend Was ist ein HMI-Panel? Hardwareaufbau.

Vor der Hardwareauswahl werden deshalb vier Fragen freigegeben: Wo wird gerechnet? Wo liegt die maßgebliche Prozessinformation? Welcher Pfad überträgt Bedien- und Statusdaten? Welcher unabhängige Mechanismus bringt die Maschine bei Verbindungsverlust in den geforderten Zustand?

Die HMI-Architektur muss Energie-, Daten- und Bedienpfad getrennt zeigen

Eine prüfbare Remote-/Wireless-HMI-Architektur zeichnet Nutzdaten, Energie, Safety und Servicezugriff als getrennte Pfade. Erst diese Darstellung zeigt, welche Komponente bei Funkverlust weiterarbeitet und welche Verantwortung nicht bei der Frontpanel-Baugruppe liegt.

                         autorisierter Remote-Service
                         über OT-Sicherheitsarchitektur
                                      │
                                      ▼
[Visualisierungsserver / Edge-PC] ── OT-Netz ── [PLC / Prozess]
             │                                       │
             │ Nutzdaten                             │ Safety-Logik
             ▼                                       ▼
      [AP / Ethernet-Switch]              [qualifiziertes Safety-System]
             │                                       │
       WLAN oder PoE                         separater Safety-Pfad
             │                                       │
             ▼                                       ▼
┌─────────────────────────────────────────────────────────────┐
│ HMI-Baugruppe: Antenne – Funk/Ethernet – Rechner – Display │
│                 Touch/Tasten – Overlay – Dichtung          │
└─────────────────────────────────────────────────────────────┘
             ▲
             │ Energie: PoE ODER lokale DC ODER Akku/Dock
             └───────────────────────────────────────────────

Die Zeichnung muss auch den Rechenort festlegen. Bei einem Thin Client liegen Anwendung und Datenhaltung überwiegend auf einem Server; das HMI braucht dennoch genügend Rechenleistung für Dekodierung, Rendering, Touchverarbeitung, Security-Funktionen und Diagnose. Beim Embedded-HMI läuft mehr lokal, wodurch Speicher, Wärmeabfuhr, Bootzeit und Softwarepflege stärker in die Hardwareauslegung eingreifen. Die angrenzende Entscheidung ist in Embedded-HMI und Panel-PC-Hardware integrieren vertieft.

PoE, lokale DC-Versorgung und Akku lösen unterschiedliche Hardwareprobleme

Wireless ersetzt nur den Datenleiter; es liefert dem HMI keine Betriebsenergie. Ein festes WLAN-Panel braucht weiterhin lokale DC-Versorgung. Ein mobiles Panel braucht Akku, Ladeelektronik und ein Nutzungskonzept. PoE bleibt deshalb oft die einfachere „Remote“-Hardware: Ein Kabel trägt Daten und Leistung, ohne Funkplanung und Batterielebenszyklus.

Für PoE ist nicht die Switch-Werbung maßgeblich, sondern die am Powered Device garantierte Leistung unter der vorgesehenen Kanallänge. Das Microchip-Whitepaper zu IEEE 802.3bt nennt für einen 100-m-Cat-5e-Kanal folgende Mindestleistungen am PD; höhere Werte innerhalb der Type-3-/Type-4-Spanne setzen die im Dokument beschriebenen Bedingungen für Extended Power voraus (Microchip DS00002992A, 2019).

Das Lastprofil wird an der Eingangsklemme des Serienaufbaus gemessen. Es umfasst Display bei maximal freigegebener Helligkeit, Rechner, Touchcontroller, Funk- oder Ethernet-Schnittstelle, angeschlossene USB-Geräte, Audio, Statusleuchten, Speicherzugriffe und Wandlungsverluste. Einschaltstrom, Bootphase, Funk-Sendespitzen und eine mögliche Heizfunktion gehören in getrennte Lastfälle. Der Nennwert eines Prozessors oder Panels ersetzt diese Messung nicht.

Bei lokaler DC-Versorgung sind Spannungsbereich, Polaritätsschutz, Brownout-Verhalten, Massekonzept, Kabelquerschnitt, Steckverbinder und Ableitpfade zeichnungsrelevant. Bei PoE kommen PD-Klasse, PSE-Kompatibilität, Kabelkategorie, Kanallänge, thermische Belastung der Buchse und das Verhalten bei Leistungsneuverhandlung hinzu. Die dazugehörigen Daten- und Steckerentscheidungen gehören in die industriellen HMI-Kommunikationsprotokolle und Hardware-Schnittstellen, nicht in eine unspezifizierte „WLAN-fähig“-Zeile.

Für Akku-Geräte wird zuerst das Einsatzprofil beschrieben: aktive Bedienzeit, Standby, Displayhelligkeit, Funklast, Schichtdauer, Ladefenster, minimale Temperatur, Alterungsreserve und erlaubter Akkutausch. Aus mittlerer Leistung und geforderter Zeit folgt die benötigte nutzbare Energie; Zellchemie, Entladetiefe, Wandlungswirkungsgrad und Alterung werden anschließend projektspezifisch angesetzt. Ein Dock benötigt zusätzlich Kontaktlebensdauer, Verschmutzungstoleranz, Verpolschutz, mechanische Führung und eine eindeutige Ladezustandsanzeige. „Acht Stunden Laufzeit“ ohne diese Bedingungen ist keine Spezifikation.

Die Antenne ist ein mechanisches Bauteil und kein nachträgliches Funkzubehör

Die Antenne beeinflusst Leiterplatte, Gehäusematerial, Dichtung, Kabelweg, Montageabstand und Zulassung. u-blox empfiehlt deshalb, Antennenintegration bereits früh in der Produktentwicklung zu behandeln; bei mehreren Funksystemen hängen Störungen unter anderem von der gegenseitigen Isolation ab. Räumliche Trennung, Polarisation, Richtwirkung oder angepasste Sendeleistung sind mögliche Maßnahmen, müssen aber für das konkrete Produkt bewertet werden (u-blox Antenna Integration, R02).

Für ein Metallgehäuse ist eine interne PCB-Antenne selten eine reine Layoutfrage. Das u-blox-Integrationshandbuch zur MAYA-W2-Serie nennt externe Antennen ausdrücklich als geeignete Option für Produkte in Metallgehäusen (MAYA-W2 System Integration Manual). Damit werden aber neue mechanische Risiken erzeugt: Koaxstecker, Durchführung, Dichtung, Zugentlastung, Antennengeometrie und Schutz gegen Beschädigung müssen Teil der Stückliste und der Gehäuseprüfung sein.

In Deutschland sind WLAN-Bereiche bei 2,4 und 5 GHz allgemein zugeteilt; die konkreten Teilbänder und Betriebsbedingungen ergeben sich aus den jeweils gültigen Verfügungen der Bundesnetzagentur. Für 2,4 GHz weist die Behörde darauf hin, dass kein Anspruch auf Schutz vor Störungen besteht. Eine Funkzulassung oder ein Wi-Fi-Logo garantiert folglich weder Abdeckung noch Reaktionszeit am späteren Maschinenstandort.

Der RF-Entwurf braucht mindestens diese Eingaben:

• CAD-Daten und Werkstoffe des finalen Gehäuses einschließlich Lack, metallisierter Beschichtung, Displayrahmen und Befestigern;
• Antennentyp, Frequenzbänder, Kabel, Stecker, Massebezug, Keep-out-Zone und zulässige Einbaulagen;
• Positionen von Displaykabel, DC/DC-Wandler, CPU, Speicher, Motoren, Relais und weiteren Sendern;
• Bedienhaltung, Handabdeckung, Wandhalterung, Dock, Maschinenrahmen und bewegte Orientierungen;
• Access-Point-Topologie, Kanalplanung, Roamingbedarf, relevante Fremdnetze und Störquellen.

Freigegeben wird nicht das Funkmodul auf dem Labortisch, sondern das geschlossene HMI in repräsentativer Montage. Gemessen werden Durchsatz nur ergänzend, vorrangig Paketverlust, Latenzverteilung, Jitter, Wiederverbindungszeit und Funktionsverhalten in allen vorgesehenen Orientierungen.

Frontpanel, Display, Touch und Gehäuse bilden einen gekoppelten Stack

Der Frontstack bestimmt gleichzeitig Bedienbarkeit, Optik, Dichtheit, EMV-Verhalten und mechanische Last. Eine Änderung an Frontglas oder Overlay kann daher Touchreserve, Klebstoffdicke, Antennenabstand, Gehäusevorspannung und Displaytemperatur verschieben.

Infineon zeigt für kapazitive Sensorik, dass die Empfindlichkeit mit wachsender Overlay-Dicke sinkt, leitfähige Materialien das elektrische Feld stören und Luftspalte zwischen Sensor und Overlay vermieden werden sollten. Die im Dokument genannten Dickenwerte gelten für die beschriebenen PSoC-CAPSENSE-Aufbauten und dürfen nicht als universelle Grenze für jedes projiziert-kapazitive Display übernommen werden (Infineon AN64846, Rev. AA). Der richtige RFQ-Input lautet deshalb nicht „Touch durch Glas“, sondern Material, Dicke, Klebstoff, Controller, Handschuhtyp, Flüssigkeit, Temperatur und gewünschte Gesten.

Auch optisch klare Klebstoffe sind spezifizierte Bauteile. 3M weist für OCA 8171 und 8172 beispielsweise 25 µm beziehungsweise 50 µm Klebstoffdicke aus; diese Zahlen gelten nur für die genannten Produkte (3M Technical Data). Die Engineering-Folge ist allgemeiner: Materialcode, Dicke und Laminierprozess gehören in Zeichnung und Stückliste, nicht in eine austauschbare Bemerkung „optisch gebondet“.

IEC 60529 klassifiziert den Schutz durch Gehäuse, IEC 62262 den Schutz von Gehäusen gegen äußere mechanische Einwirkung. Eine dichte Frontfolie oder ein robustes Deckglas beweist daher noch keinen IP- oder IK-Grad des fertigen Geräts. Die geprüfte Konfiguration umfasst Rahmen, Dichtung, Schrauben, Antennen- und Kabeldurchführungen, Lüftung, Druckausgleich und alle Serviceöffnungen. Die HMI-Panel-Konstruktion: Checkliste mit 10 Freigabekriterien hilft, diese Schnittstellen vor der Musterfreigabe zu schließen.

Wahrgenommene Latenz muss Ende zu Ende und unter Störung gemessen werden

Der Bediener spürt die Summe aus Touchscan, Eingabeverarbeitung, Rendering, Netzwerk-Warteschlange, Funkübertragung, Server- oder Controller-Reaktion, Rückmeldung und Displayaktualisierung. Ein niedriger Ping misst nur einen Teil davon. NIST beschreibt Latenz als Zeit zwischen zwei Ereignissen und weist für Fabriknetze darauf hin, dass interne Gerätearchitektur und Protokollstack einen großen Anteil verursachen können (NIST TN 1755).

Ein Prüfplan braucht daher mindestens zwei Ende-zu-Ende-Messgrößen: Touch-to-visible-feedback für die erste erkennbare Reaktion und command-to-confirmed-state für die bestätigte Prozessänderung. Beide werden als Verteilung dokumentiert, etwa Median sowie hohe Perzentile, unter Leerlauf, definierter Netzlast, schwachem Nutzsignal, Kanalwechsel, Roaming und Wiederverbindung. Grenzwerte stammen aus Bedienaufgabe und Risikobeurteilung, nicht aus einer pauschalen Zahl für alle HMIs.

Auch ein aktueller Funkstandard ersetzt diese Prüfung nicht. In einem NIST-Versuch mit IEEE 802.11ax, TCP und variabler Update-Rate verbesserte der untersuchte OFDMA-Algorithmus die Latenz nicht, sondern erhöhte sie. Das Ergebnis gilt für diesen Versuchsaufbau; seine Engineering-Bedeutung liegt darin, Feature-Namen nicht mit Systemleistung gleichzusetzen (NIST, 2024).

Fehlerpfade werden sichtbar gestaltet: Linkverlust, eingefrorener Bildinhalt, veralteter Prozesswert, doppelte Betätigung nach Reconnect, falsche Maschinenzuordnung und leere Batterie brauchen eindeutige Anzeigen und definierte Zustände. Eine lokale Eingabe darf nicht scheinbar erfolgreich sein, wenn der entfernte Befehl nie bestätigt wurde.

Cybersecurity und Functional Safety brauchen benannte Eigentümer

Wireless-Konnektivität erweitert die Angriffsfläche, während Remote Access Identitäten, Sitzungen und häufig standortübergreifende Netze einführt. Diese Aufgaben lassen sich nicht mit „verschlüsselt“ in einer Funkmodulzeile erledigen. IEC 62443-4-1 ordnet sichere Entwicklung, Verifikation, Fehler-, Patch- und End-of-Life-Management dem Produktentwickler und Maintainer zu; IEC 62443-3-2 behandelt dagegen Systemrisiko, Zonen und Conduits. Die Rollen sind verschieden.

NIST SP 800-82 Rev. 3 behandelt OT-Security ausdrücklich unter den zusätzlichen Anforderungen an Performance, Zuverlässigkeit und Safety. Für die HMI-Hardware bedeutet das: Netzwerkports, Debugzugänge, Massenspeicher, Secure-Boot-/Schlüsselspeicher-Fähigkeit, Recovery und physischer Zugriff werden früh spezifiziert; die tatsächliche Rechtevergabe und Fernzugangsarchitektur bleiben beim Systembetreiber bzw. Integrator.

Für Produkte mit digitalen Elementen im EU-Markt ist außerdem der Cyber Resilience Act ein Planungseingang. Die Verordnung (EU) 2024/2847 erfasst Hardware- und Softwareprodukte einschließlich bestimmter Remote-Datenverarbeitung; Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle gelten ab 11. September 2026, die allgemeine Anwendung ab 11. Dezember 2027 (EUR-Lex). Die konkrete Produktklassifizierung ist rechtlich zu prüfen. Funkgeräte müssen zusätzlich die einschlägigen Anforderungen der Richtlinie 2014/53/EU an Sicherheit, EMV und Spektrumsnutzung erfüllen.

Functional Safety bleibt eine eigene Grenze. ISO 13850 definiert Prinzipien für die Not-Halt-Funktion; IEC 61784-3 beschreibt Safety-Kommunikationsprofile nach dem Black-Channel-Ansatz für Safety-Geräte. Ein Not-Halt oder Zustimmtaster wird deshalb nicht dadurch sicher, dass sein Telegramm über normales WLAN übertragen wird. Benötigt werden qualifizierte Safety-Komponenten, eine passende Kommunikationsarchitektur, Fehlerreaktion und die Validierung der Maschine.

Die Validierung muss das Seriengerät und die reale Einbausituation abbilden

Eine belastbare Freigabe prüft den vollständigen HMI-Stack mit Serienmaterialien, Serienfirmware, finaler Antenne, Dichtung, Kabeln und Montage. Grundnormen liefern Verfahren, aber nicht automatisch das richtige Prüflevel: IEC 61000-4-2:2025 überlässt die Auswahl der ESD-Schärfe der Produktspezifikation; IEC 60068-2-6 beschreibt sinusförmige Vibration mit festzulegenden Schärfen. Diese Bedingungen müssen im Lastenheft stehen.

Die Prüf- und Validierungsplanung sollte bereits vor dem ersten seriennahen Muster Messpunkte, Betriebszustände und Akzeptanzkriterien benennen. Ein frühes Funktionsmuster kann Antennenposition, Touchreserve und thermischen Pfad klären; die formale Freigabe erfolgt jedoch erst am repräsentativen Stack. Prototyping und Musterfreigabe verbindet diese Lernschleifen mit kontrollierten Zeichnungs- und Stücklistenständen.

Wireless ist nicht für jede HMI-Aufgabe die richtige Wahl

Ein Wireless-HMI ist ungeeignet, wenn ein einfacher Kabelweg vorhanden ist und die Mobilität keinen messbaren Bedienvorteil bringt. Kabel oder PoE vermeiden Akkuwartung, Standortfunkplanung, Roaming und einen großen Teil der Funkdiagnose. Das gilt besonders bei fest montierten Panels, hohen Dauerlasten oder Umgebungen mit stark wechselnder Belegung des Funkspektrums.

Auch sicherheitskritische Echtzeitfunktionen gehören nicht ohne qualifiziertes Safety-Konzept auf einen gewöhnlichen WLAN-Pfad. Bei metallisch abgeschirmten Einbauorten, fehlender Antennenfreiheit, nicht beherrschbarer Funkkoexistenz oder unzulässigem Verhalten bei Linkverlust ist die kabelgebundene Variante die bessere Architektur. Remote Access ist ebenfalls kein Selbstzweck: Wenn Identitäts-, Update-, Logging- und Abschaltprozesse nicht betrieben werden können, vergrößert er nur die Systemgrenze.

Die Entscheidung darf deshalb „kein Wireless“ lauten. Ein robustes Pflichtenheft dokumentiert diese Ausschlussentscheidung genauso sauber wie die Auswahl eines Funkmoduls.

Häufige Fragen zu Remote- und Wireless-HMI-Hardware

Was ist der Unterschied zwischen Remote-HMI und Wireless-HMI?

Ein Remote-HMI zeigt oder bedient eine Anwendung, die auf einem entfernten Rechner, Server oder Controller läuft. Ein Wireless-HMI beschreibt den physischen Datenweg per Funk. Ein kabelgebundenes Panel kann Remote-HMI sein; ein WLAN-Panel kann seine Anwendung lokal ausführen. Für die Hardwareauslegung müssen Rechenort, Datenweg und Energiequelle getrennt spezifiziert werden.

Wann ist PoE für ein industrielles HMI besser als WLAN?

PoE ist meist besser, wenn ein Ethernet-Kabel zulässig ist, die am Powered Device garantierte Leistung ausreicht und das Panel fest montiert bleibt. Es vereint Daten und Energie, vermeidet Akku und Funkabdeckung und vereinfacht die Fehlerdiagnose. WLAN ist sinnvoller, wenn der Datenleiter die Bewegung oder Montage tatsächlich behindert; lokale Energie bleibt trotzdem erforderlich.

Kann ein Wireless-HMI vollständig ohne Kabel arbeiten?

Nur ein Akku-HMI kann während des Betriebs vollständig kabellos sein. Ein festes WLAN-HMI benötigt weiterhin eine lokale Versorgung, ein mobiles Gerät zusätzlich Ladegerät oder Dock. Zur Spezifikation gehören Schichtprofil, minimale Laufzeit, Ladefenster, Temperatur, Alterung, Wechselstrategie und Verhalten bei niedrigem Ladezustand. Das Funkmodul allein beantwortet keine dieser Fragen.

Wo gehört die WLAN-Antenne bei einem HMI im Metallgehäuse hin?

Bei einem weitgehend geschlossenen Metallgehäuse ist häufig eine externe oder hinter einem definierten nichtmetallischen RF-Fenster platzierte Antenne erforderlich. Die endgültige Position hängt von Massefläche, Koaxweg, Display, Kabeln, Handabdeckung und Maschinenrahmen ab. Freigegeben wird die Antenne durch Messungen am geschlossenen Gerät in allen vorgesehenen Montage- und Bedienlagen.

Welche Latenz ist für ein Remote-HMI akzeptabel?

Es gibt keinen universellen Millisekundenwert für alle Bedienaufgaben. Festgelegt werden getrennte Grenzen für die erste sichtbare Reaktion und den bestätigten Prozesszustand. Gemessen wird Ende zu Ende, nicht nur per Ping, und als Verteilung unter Normalbetrieb, Netzlast, schwachem Signal, Roaming und Wiederverbindung. Die Risikobeurteilung bestimmt, welche Verzögerung noch zulässig ist.

Darf ein Not-Halt über normales WLAN übertragen werden?

Ein gewöhnlicher WLAN-Nutzdatenkanal ist kein ausreichender Nachweis für eine Not-Halt-Funktion. Safety-bezogene Kommunikation benötigt eine qualifizierte Architektur, geeignete Safety-Geräte, definierte Fehlerreaktionen und eine Validierung nach der Maschinenrisikobeurteilung. Funk kann Transportbestandteil eines zertifizierbaren Safety-Systems sein; die Safety-Eigenschaft entsteht jedoch nicht aus WLAN, Verschlüsselung oder Signalstärke allein.

Reicht ein vorgeprüftes Funkmodul für die CE-Konformität des fertigen HMI?

Nein. Ein vorgeprüftes Modul kann Prüfaufwand reduzieren, wenn Referenzlayout, Antenne, Sendeparameter und Integrationsbedingungen eingehalten werden. Das fertige Funkgerät muss dennoch als Gesamtprodukt bewertet werden, einschließlich Antenne, Gehäuse, EMV, Sicherheit und Spektrumsnutzung. Abweichende Antenne, Koaxleitung, Metallumgebung oder gleichzeitige Sender können zusätzliche Nachweise auslösen.

Welche Angaben braucht ein Lieferant, um Remote- und Wireless-HMI-Hardware zu entwickeln?

Erforderlich sind Displaygröße und aktive Fläche, Frontplattenzeichnung, Touch-/Tastenanforderung, Interface-Stack, Rechenort, Energiequelle, Funkbänder und Antenne, Gehäusematerial, Einbaulage, Umgebung, Reinigungsmittel, EMV-/IP-/IK-Ziele, Latenz- und Linkverlustverhalten, Security-/Safety-Verantwortung, Validierungsplan sowie Prototypen- und Jahresmenge. Ohne diese Inputs bleibt ein Angebot technisch unvergleichbar.

Projektinputs für Zeichnungsprüfung und Angebot

Eine technische Anfrage sollte nicht mit „10-Zoll-WLAN-HMI“ enden. Für eine belastbare Prüfung werden folgende Daten gemeinsam übergeben:

• Displaygröße, aktive Fläche, Auflösung, Helligkeitsmodus und vorgesehener Displaylieferant;
• 2D-Frontplattenzeichnung und, falls vorhanden, 3D-Gehäusedaten mit Material, Beschichtung, Dichtkontur und Schraubfolge;
• vollständiger Interface-Stack: Touch, Tasten, LEDs, Display-FPC, Ethernet/PoE, USB, serielle oder feldseitige Schnittstellen;
• Energiearchitektur mit Spannungsbereich, PoE-Typ oder Akku-/Dock-Profil sowie gemessenen Lastfällen;
• Funkbänder, Antenne, Koax/Stecker, Access-Point-Umgebung, Montage- und Bedienlagen;
• Temperatur, Feuchte, Vibration, Fall-/Stoßrisiko, Wasser, Staub, UV, Handschuhe und Reinigungschemie;
• Rechenort, Remote-Protokollgrenze, gewünschtes Verhalten bei Boot, Linkverlust, Roaming und Reconnect;
• Security-, OT- und Safety-Eigentümer einschließlich geforderter Nachweise;
• Prototypenmenge, geplanter Freigabeablauf und Jahresvolumen.

OEM-Teams können diese Unterlagen über Zeichnungen zur technischen Prüfung senden. Für die erste Engineering-Bewertung genügen Displaygröße, Frontplattenzeichnung, Interface-Stack, Einsatzumgebung und Jahresvolumen; offene Grenzwerte werden anschließend als prüfbare Anforderungen geschlossen. Wenn Architektur und Lieferumfang bereits definiert sind, lässt sich ein technisches Angebot anfragen.

Referenzen

1. NIST, Human-Machine Interface, CSRC Glossary, Abruf 24.08.2026.
2. Microchip Technology, Next-Generation PoE: IEEE 802.3bt, DS00002992A, 2019.
3. Bundesnetzagentur, 2,4 GHz, 5 GHz und 5,8 GHz sowie Allgemeinzuteilung WLAN 2,4 GHz, Abruf 24.08.2026.
4. u-blox, Antenna Integration, UBX-18070466 R02, 2020.
5. u-blox, MAYA-W2 Series System Integration Manual, UBX-22011459, R04.
6. Infineon, AN64846 Getting Started with CAPSENSE, Rev. AA, 12.04.2024.
7. 3M, Optically Clear Adhesive 8171 and 8172 Technical Data, 2016.
8. IEC 60529, Degrees of protection provided by enclosures (IP Code), Ed. 2.1 mit AMD2:2013.
9. IEC 62262:2002+AMD1:2021, Degrees of protection provided by enclosures against external mechanical impacts (IK code).
10. IEC 61000-4-2:2025, Electrostatic discharge immunity test.
11. IEC 60068-2-6:2007, Test Fc: Vibration (sinusoidal).
12. IEC 61784-3:2021, Functional safety fieldbuses — General rules and profile definitions.
13. ISO 13850:2015, Safety of machinery — Emergency stop function — Principles for design.
14. IEC 62443-4-1:2018, Secure product development lifecycle requirements.
15. IEC 62443-3-2:2020, Security risk assessment for system design.
16. NIST SP 800-82 Rev. 3, Guide to Operational Technology Security, September 2023.
17. Europäische Union, Verordnung (EU) 2024/2847, Cyber Resilience Act, 20.11.2024.
18. Europäische Union, Richtlinie 2014/53/EU, Radio Equipment Directive, 22.05.2014.
19. NIST Technical Note 1755, Factory Equipment Network Testing Framework, 2012.
20. NIST, Latency-Sensitive Networked Control Using 802.11ax OFDMA Triggering, 22.08.2024.