Was man bewusst nicht tut

  • Kein 24/7‑Rohdatenstream in die Cloud “für den Fall der Fälle”. Das ist teuer, rechtlich heikel und operativ fragil.

  • Kein Modellwechsel ohne Shadow‑Phase. Selbst “besser” im Labor kann im Feld schlechter heißen.

  • Keine Edge‑Geräte ohne Remote‑Management. Handarbeit am Schaltschrank skaliert nicht über eine Halle, geschweige denn über eine Flotte.

Organisatorisches: von PoC zu Produktion

  • Build‑once‑run‑everywhere gilt nur, wenn Edge‑Abstraktion stimmt: Gleicher Container, parametrisiert nach Maschine/Zug. Artefakte signieren.

  • Versionierung auf allen Ebenen: Feature‑Code, Modell, Kalibrierung, Schwellen, Gerätetyp.

  • Teststrategie:

  • Unit‑Tests für Feature‑Berechnung gegen Referenzsignale.

  • HIL‑Tests (Hardware‑in‑the‑Loop) mit aufgezeichneten Rohfenstern.

  • Canary‑Rollout mit klaren Abbruchkriterien.

  • Zusammenarbeit mit Instandhaltung:

  • Alarme ohne Handlungsanweisung sind Lärm. Jede Stufe braucht klare nächste Schritte.

  • Feedbackschleife: Was war tatsächlich defekt? Labels aus der Werkstatt sind Gold für das nächste Retraining.

On‑Premise‑Anforderungen und Datensouveränität

  • In DACH‑Industrien und bei Betreibern kritischer Infrastruktur sind On‑Prem‑Deployments mit klaren Datenflüssen Standard. Das bedeutet:

  • Keine Abhängigkeit von US‑Cloud‑Diensten.

  • Auditierbare Pipeline: von der Sensorprobe bis zum Instandhaltungsauftrag.

  • Lokale Skalierung: K3s/Kubernetes on‑prem für zentrale Services ist erprobt, Edge bleibt leichtgewichtig.

  • Als Engineering‑Partner bauen wir genau solche Systeme: Requirements sauber erfassen, Softwarearchitektur definieren, robuste Implementierung, Qualitätssicherung bis zur Abnahme. Kein “API‑Reselling”, sondern produktionsreife Industrielösungen (→ alpitype.de/leistungen/).

Checkliste für den Start

  • Welche Entscheidungen müssen lokal in <1 s fallen? Alles andere ist “nice to have”.

  • Welche Sensorik ist mechanisch/elektrisch sauber nachrüstbar? Vibration ohne solide Montage ist verschwendetes Budget.

  • Welche Kontextsignale sind verfügbar (Drehzahl, Last, Temperatur) und wie werden sie synchronisiert?

  • Wie groß ist das Uplink‑Fenster realistisch? Planen Sie mit 0.1× der Marketingzahlen des Netzbetreibers.

  • Wie sieht der Weg für OTA‑Updates, Rollbacks und Shadow‑Inferenz aus? Vor dem ersten Sensor montieren.

  • Wer pflegt Modell‑Schwellen pro Produkt/ Strecke? Ohne Ownership veralten Baselines.

FAQ
1) Wie rolle ich Modell‑Updates aus, ohne die Produktion zu riskieren?

  • Shadow‑Inferenz: Neues Modell läuft parallel, Scores werden zentral verglichen. Define‑Ahead‑Metriken (z. B. KL‑Divergenz der Score‑Verteilung, Alarmrate pro 24 h). Rollout in Batches mit automatischem Rollback, wenn Metriken außerhalb definierter Bänder liegen. Edge‑seitig immer das alte Modell behalten, bis das neue explizit “promoted” ist.

2) Wie viel Rechenleistung brauche ich am Edge?

  • Für 2–4 Vibrationskanäle à 10–25 kHz plus einfache Modelle reicht oft ein 4‑Kern‑ARM oder lüfterloser x86‑IPC. Zielwerte: <30 % CPU im Mittel, damit genug Headroom für Peaks/NEON/AVX‑beschleunigte FFTs bleibt. Quantisierte 1D‑CNNs mit <1 Mio. Parametern laufen typischerweise im einstelligen Millisekundenbereich pro Fenster.

3) Kann ich RUL (Remaining Useful Life) am Edge schätzen?

  • Nur, wenn ausreichend Degradationsverläufe vorliegen und der Prozess langsam altert. In vielen realen Setups ist eine robuste Zustandsklassifikation mit Trendverfolgung sinnvoller. RUL‑Modelle trainiert man zentral; am Edge läuft dann eine leichte Approximation oder ausschließlich die Zustandsbewertung mit zentraler RUL‑Aggregation.

4) Welche Daten muss ich dauerhaft speichern?

  • Nicht alle. Bewährt hat sich: Telemetrie verdichtet (Sekunden-/Minutenraster) für alle Assets; Rohfenster nur ereignisbasiert (vor/nach Alarm) plus Stichproben (“Golden Windows”) für regelmäßige Qualitätsprüfung. Speicherfristen technisch erzwingen (z. B. 90/180 Tage nach Asset‑Klasse), um Compliance einzuhalten.

5) Wie gehe ich mit variabler Drehzahl um?

  • Ohne Ordnungsanalyse produzieren Sie Fehlalarme. Nutzen Sie Drehzahlsignale (Inkrementalgeber, virtueller Tacho über Stromfrequenz), rechnen Sie Features auf Ordnungen um, skalieren Sie Schwellen drehzahlabhängig. Falls kein sauberes Drehzahlsignal vorhanden ist, erwägen Sie schmalbandige Features, die drehzahlrobust sind, und konservativere Alarmlogik.

Fazit
Edge‑Inferenz ist kein Hype‑Gegengewicht zur Cloud, sondern eine nüchterne Antwort auf physikalische, regulatorische und betriebliche Randbedingungen in der Industrie. Wer Feature‑Berechnung und Entscheidungen nah an die Maschine legt, spart Bandbreite, gewinnt Latenz und behält die Hoheit über seine Daten. Die zentrale Ebene bleibt wichtig – für Training, Flottensteuerung und Governance –, aber sie gehört nicht in den kritischen Pfad der Entscheidung. Entscheidend ist, die Architektur vom Problem her zu schneiden: Welche Entscheidung, in welcher Zeit, mit welchen Daten – und was kostet ein Fehler? Wenn diese Fragen sauber beantwortet sind, wird aus dem PoC ein System, das Jahre stabil läuft. Als Engineering‑Partner bauen wir genau diese Art von industrieller KI – on‑premise, souverän, produktionsreif (→ alpitype.de/leistungen/).