Anomalie-Wächter an der Maschine

Vorab gerechnet

Sensordaten lernen den Normalzustand; die KI meldet das Lager, das anders klingt, bevor es steht. Wir möchten das als internen Prototyp für unser Unternehmen umsetzen.

Gerechnet am 11.09.2026 um 22:18 Uhr

Ihr erster Prototyp · Festpreis netto

8.100 €

Prototyp Aufwand 78 / 100 · ca. 6 Wochen

So haben wir Sie verstanden

Ein interner Prototyp soll aus Sensordaten den Normalzustand von Lagern lernen und akustische Anomalien vor dem Ausfall melden.

Was der Prototyp enthält

Ein Sensor/Lager wird kontinuierlich überwacht, das Modell lernt dessen Normalzustand und meldet Abweichungen über eine einfache Oberfläche.

78/100

Aufwands-Meter — 100 heißt maximaler Aufwand und maximaler Preis, keine Note.

KI-gestützte Anomalieerkennung mit Echtzeitdaten und ungeklärter Datenlage bedeutet hohen Aufwand schon für den Prototyp

Danach: Vollausbau

Vollausbau ab 109.000 € · indikativ bis 141.500 € · 7 Wochen · Team aus 3

Komponenten

Datenanbindung Sensorik5,5 PT
Normalzustand-Modell / Anomalieerkennung9,75 PT
Alarmierung & Anzeige4,25 PT
Datenhaltung & Historie2,75 PT
Testaufbau mit realen Daten2,75 PT

Besetzung

Principal Developer (Principal Engineer)
Senior Developer (Senior .NET-Entwickler)
Inventive Engineer (Architektur)

Annahmen hinter dem Preis

Sensordaten sind bereits digital verfügbar (z. B. über Schnittstelle oder Datei-Export)
Es wird zunächst nur ein Lager/eine Maschine als Pilot betrachtet
Historische Daten für Normalzustand-Training liegen in ausreichender Menge vor

Was wir zu Beginn klären

Welche Sensoren liefern die Daten und über welche Schnittstelle/welches Protokoll?
Wie viele Lager/Maschinen sollen langfristig überwacht werden?

Der Fahrplan — was in welcher Woche fertig ist

zu spät im Plan

Woche 1 Kickoff Abstimmung, Zugänge, Feinschnitt des Umfangs
Woche 2 Datenanbindung Sensorik 5,5 PT
Woche 3 Normalzustand-Modell / Anomalieerkennung 9,75 PT
Woche 4 Alarmierung & Anzeige 4,25 PT
Woche 5 Datenhaltung & Historie 2,75 PT
Woche 5 Testaufbau mit realen Daten 2,75 PT
Woche 6 Abnahme Übergabe nach Abnahme und Restzahlung

Verstärkung: Köpfe auf Abschnitte legen

1 Woche früher, Abnahme in Woche 5 statt 6: „Normalzustand-Modell / Anomalieerkennung“ +1 Senior Developer (Senior .NET-Entwickler), „Testaufbau mit realen Daten“ +1 Tester · +200 €
2 Wochen früher, Abnahme in Woche 4 statt 6: „Datenanbindung Sensorik“ +2 Senior Developer (Senior .NET-Entwickler), „Normalzustand-Modell / Anomalieerkennung“ +1 Senior Developer (Senior .NET-Entwickler), „Alarmierung & Anzeige“ +1 Senior Developer (Senior .NET-Entwickler), „Testaufbau mit realen Daten“ +2 Tester · +440 € hilft am meisten

Legen Sie Köpfe auf die Abschnitte, die schneller fertig werden sollen: dieselben Stunden, mehr Köpfe, weniger Wochen — wie bei den Tempopaketen, ein Kopf mehr +5 %, zwei +8 %, drei +10 %, vier +12 % auf den Anteil des Abschnitts am MVP-Festpreis. Entwickler kommen nicht auf Abschnitte, die andere zusammenführen, und nicht auf, was erst im letzten Drittel beginnt — dort macht ein weiterer Entwickler ein Projekt langsamer. Auf den letzten Abschnitt vor der Abnahme legen Sie stattdessen Tester. Wer die Köpfe sind, wählen wir.

Lastenheft und Pflichtenheft

Ziel Ein lauffähiger interner Prototyp erkennt akustische Abweichungen an einem Lager und meldet diese vor einem möglichen Ausfall.

Lösungsweg Sensordaten werden per Schnittstelle erfasst, in SQL Server gespeichert, ein KI-Modell lernt daraus den Normalzustand und meldet Abweichungen in Echtzeit über eine Weboberfläche.

Was gefordert istDas System muss Sensordaten (Geräusch/Schwingung) eines Lagers kontinuierlich erfassen.

Wie wir es umsetzenAnbindung der Sensordaten über REST-Schnittstelle in ein .NET-Backend
Was gefordert istDas System muss aus den erfassten Daten einen Normalzustand lernen.

Wie wir es umsetzenTrainieren eines Normalzustand-Modells mittels KI-Anbindung auf Basis gesammelter Messreihen
Was gefordert istDas System muss Abweichungen vom Normalzustand erkennen und melden.

Wie wir es umsetzenLaufende Bewertung neuer Messwerte gegen das Modell mit Schwellenwert-Alarmierung
Was gefordert istDas System muss die Meldungen für Nutzer sichtbar machen.

Wie wir es umsetzenAnzeige der Sensorwerte und Alarme in Echtzeit per SignalR in einer Razor-Oberfläche

Rahmenbedingungen

Interner Prototyp, kein Produktivbetrieb
Zunächst ein Lager/eine Messstelle im Fokus
Zeitrahmen: ca. 6 Wochen bis Prototyp

Nicht im Umfang

Keine Anbindung mehrerer Lager oder Standorte im Prototyp
Keine mobile App
Kein automatisierter Wartungsauftrag oder ERP-Anbindung
Keine Zertifizierung für sicherheitskritischen Dauerbetrieb

Woran Sie die Abnahme messen

System erkennt mindestens einen simulierten oder realen Anomaliefall korrekt
Alarm erscheint innerhalb weniger Sekunden nach Erkennung in der Oberfläche
Normalzustand wird aus mindestens einem vollständigen Trainingsdatensatz abgeleitet
Historische Messdaten sind über mindestens 7 Tage abrufbar

Meilensteine

Woche 2: Datenanbindung Sensorik
Woche 3: Normalzustand-Modell / Anomalieerkennung
Woche 4: Alarmierung & Anzeige
Woche 5: Datenhaltung & Historie
Woche 5: Testaufbau mit realen Daten
Woche 6: Abnahme

Technologien, die wir einsetzen

Minimal APIs & REST / Web API
Microsoft.Extensions.AI
SignalR & WebSockets
SQL Server 2025
ASP.NET Core MVC & Razor Pages
ML.NET & ONNX Runtime
MQTT & OPC UA

REST-Schnittstelle (JSON)Anbindung der Sensordaten-Quelle an das Backend
KI-AnbindungLernen des Normalzustands und Erkennen akustischer Abweichungen
SignalREchtzeit-Anzeige von Messwerten und Alarmen ohne Neuladen
SQL ServerSpeicherung der Sensor- und Trainingsdaten
ASP.NET Core MVCBackend und Weboberfläche für die Prototyp-Anwendung
Razor ViewsDarstellung der Sensorwerte und Meldungen für Nutzer
ML.NET & ONNX RuntimeDas Modell, das den Normalzustand des Lagers lernt
MQTT & OPC UAAnbindung der Sensoren an der Maschine

← Zurück zum Portfolio

NAVIGATION