Audioereigniserkennung & akustische Überwachung

Mikrofone sind günstig, funktionieren im Dunkeln und um die Ecke und hören Dinge, die Kameras und Schwingungssensoren übersehen: Glasbruch, Alarme, ein defektes Lager, einen Sturz, einen Ruf. Modelle zur Audioklassifikation machen aus kontinuierlichem Schall einzelne, zeitgestempelte Ereignisse, die Alarme oder Wartungstickets auslösen. Die Technik ist ausgereift; schwierig sind Fehlalarme in realen akustischen Umgebungen und vor allem der Datenschutz: Ein Mikrofon, das Sprache aufnehmen kann, ist rechtlich ein Überwachungsgerät.

Problem & Nutzen

• Heute: Sicherheitspersonal beobachtet Kamerawände; die Instandhaltung verlässt sich auf feste Kontrollgänge oder einen erfahrenen Techniker, der einer Maschine "zuhört"; Alarmtöne werden nur von anwesenden Menschen bemerkt; Städte messen Lärm mit wenigen Schallpegelmessern, die Dezibel melden, aber keine Ursachen.
• KI-Nutzen: Rund-um-die-Uhr-Abdeckung für rein akustische Ereignisse, Frühwarnung bei mechanischen Fehlern (akustische Signaturen ändern sich, bevor Schwingungs- oder Temperaturgrenzen erreicht werden), Zuordnung von Schallquellen in der Lärmkartierung und Überprüfung von Alarmen, bevor Personal ausrückt.
• Evidenzbasis: Die Schallereigniserkennung ist ein seit langem etabliertes Forschungsfeld mit jährlichen Benchmark-Wettbewerben (DCASE); auf AudioSet trainierte Modelle klassifizieren 527 Geräuschklassen, mit veröffentlichten Bestwerten um 0,50 mAP. Das zeigt, dass offenes Sound-Tagging bei Weitem nicht gelöst ist und standortspezifische Anpassung nötig bleibt [1][2][3]. Es werden hier keine Herstellerangaben zum ROI zitiert.

Varianten

• Gebäude- und Objektsicherheit: Glasbruch, Überprüfung von Alarmtönen, Aufprallerkennung (als Audio-Erweiterung in vorhandenen IP-Kameras).
• Industrielle akustische Zustandsüberwachung: Erkennung auffälliger Geräusche bei Pumpen, Lüftern, Getrieben, Förderbändern → PRED-006 / ANOM-005. Oft unüberwacht: Nur "normale" Geräusche liegen vor.
• Smart City & Umgebungslärm: Klassifikation von Lärmquellen, ereignisbasierte Lärmkartierung nach der Umgebungslärmrichtlinie 2002/49/EG, Beschwerden über Verkehrs- und Industrielärm.
• Pflege & altersgerechte Assistenzsysteme: Sturzaufprall, Hilferuf, Erkennung von Rauchmeldern und Türklingeln, Husten-Erkennung; datenschutzfreundliche Sensoren, die nie Sprache speichern.
• Öffentliche Sicherheit: Erkennung von Schüssen oder Aggression im öffentlichen Raum: sensibel, siehe Risiken.
• Barrierefreiheit / private Nutzung: Telefon- oder Uhrenfunktionen, die gehörlose und schwerhörige Nutzer über Alarme, Türklingeln, Babyweinen und Sirenen informieren (Geräuscherkennung auf Betriebssystemebene).
• Wildtiere und Ökologie: siehe SPEECH-015. Notrufe: siehe SPEECH-016.

So funktioniert es

1. microphone / sensor (edge)
2. audio capture (16 kHz mono, 1–10 s sliding windows) + level gating
3. log-mel spectrogram
4. audio model (tagging: multi-label, or detection: frame-level onset/offset; or anomaly score)
5. post-processing (thresholds per class, smoothing, debouncing, site calibration)
6. event store (timestamp, class, score, optional short clip)
7. routing (VMS / alarm panel / CMMS ticket / dashboard / phone push)
8. human verification & feedback labels

• Modelle: vortrainierte Audio-Transformer oder CNNs, feingetunt auf AudioSet-artige Klassen (AST, PaSST, BEATs, PANNs, CLAP-artige Audio-Text-Modelle für Zero-Shot-Klassen). Die Erkennung auf Frame-Ebene braucht stark beschriftete Daten. Industrielle Anomalien nutzen meist Autoencoder oder Embedding-Abstandsverfahren, die nur auf normalen Geräuschen trainiert werden.
• Edge zuerst: Die Inferenz läuft auf dem Sensor oder einem Gateway; nur Ereignis-Metadaten (oder ein kurzer Clip nach einem Auslöser) verlassen den Standort. Das ist der wichtigste Hebel für Datenschutz durch Technikgestaltung.
• Mensch-in-der-Schleife (Human-in-the-Loop): Ein Bediener bestätigt sicherheitsrelevante Alarme vor dem Einsatz; Techniker bestätigen akustische Fehleralarme und beschriften die Ursache, die dann zu Trainingsdaten wird.

Datenaufbereitung

Benötigte Daten: kontinuierliches Audio von IP-Kameras, speziellen Akustiksensoren oder an Maschinen montierten Mikrofonen sowie einige beschriftete Beispiele der Zielereignisse (Alarm, Glasbruch, quietschendes Lager). In einem KMU existiert dieses Audio bisher nirgends: Es muss erfasst werden, meist über Kameras, die bereits an ein VMS angebunden sind, und Ereignislabels stehen in Wartungsprotokollen, CMMS-Tickets oder in den Köpfen der Techniker.

Typische Lücken: keine Referenzaufnahmen normaler Hintergrundgeräusche, keine Labels, Mikrofone mit ungünstiger Platzierung oder Übersteuerung und unklare Regeln, ob Sprache überhaupt aufgezeichnet werden darf. Aufbewahrung und Zugriffsrechte für Audio sind selten geregelt.

Vorbereitungsschritte: 1. Pro Standort ein bis vier Wochen Audio unter Normalbedingungen aufzeichnen und bekannte Vorfälle markieren (mit PREP-020 Labels aus Wartungstickets und Alarmprotokollen gewinnen). 2. Mit Technikern einen kleinen Testdatensatz aufbauen (PREP-018) und die Ereigniskategorien festlegen, bevor Alarme konfiguriert werden (PREP-019). 3. Das System so konfigurieren, dass nur kurze Ereignisclips und keine fortlaufende Sprache gespeichert werden; PREP-022 anwenden, wo Clips Stimmen enthalten können. 4. Zweck und Rechtsgrundlage klären (PREP-025).

Aufwandsanteil: etwa 30 bis 40 Prozent des Projekts, überwiegend standortspezifische Referenzaufnahmen und Schwellenwert-Abstimmung. Wer Rückmeldungen des Bedienpersonals zu Fehlalarmen erfasst (PREP-021), hält diesen Aufwand nach dem Start gering.

Umsetzungswege

Welcher Weg für wen

• smb: Weg A, weil VMS- und Kamerahersteller (z. B. Axis) ausgereifte Audioanalysen anbieten, die per Lizenz oder Firmware-Update ergänzt werden.
• enterprise: Weg B, weil Maschinengeräusche und standortspezifische Ereignisse eine Integration mit CMMS, SIEM und eigenen Sensoren erfordern, die kein einzelnes Produkt abdeckt.
• developer: Weg C, weil offene Audiomodelle (z. B. PANNs, AST, BEATs) auf HW1-Edge-Geräten laufen und sich an einen Standort anpassen lassen.
• public: Weg C, weil Audio in öffentlichen Räumen oder Pflegeeinrichtungen sensibel ist und die Beschaffung souveräne Verarbeitung vor Ort (On-Premises) bevorzugt.

Weg A — Kaufen (Standardsoftware; für die meisten KMU empfohlen)

• Sicherheits-/Video-Ökosystem: Audioanalysen in VMS- und Kameraplattformen wie Axis (Audioanalysen in Kameras und "AXIS Audio Analytics"), Bosch, Hanwha, Genetec, Milestone- Integrationen; Produkte zur Alarmverifizierung anhand von Geräuschklassen. EU-Verfügbarkeit prüfen und ob das Audio auf dem Gerät verarbeitet wird.
• Spezialanbieter: Sound Intelligence (NL, EU: Erkennung von Aggression/Schreien/Schüssen in Sicherheitssystemen), Audio Analytic (UK: eingebettete Geräuscherkennung, lizenziert an Gerätehersteller), Sensory, Anbieter kommunaler Lärmüberwachung vom Typ Soundtrace sowie Anbieter industrieller akustischer Zustandsüberwachung (z. B. Siemens, SKF, Brüel & Kjær / HBK, Cetim-artige Angebote aus Sensorik plus Analytik). Aktuelle Angebote vor der Beschaffung prüfen.
• Verbraucher-/Betriebssystemebene: Apple Sound Recognition und Android Sound Notifications für Barrierefreiheit auf Telefonen.
• A wählen, wenn: die Geräuschklassen Standard sind (Glas, Alarm, Sirene, Schrei) und bereits eine Video- oder Alarmplattform vorhanden ist.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Audio-Tagging über multimodale Modelle: Gemini (Audioeingabe), Googles Audiomodelle auf Vertex AI (EU-Standort) und Modelle der OpenAI-Klasse mit Audioeingabe können Clips beschriften; nützlich für die Offline-Analyse von Archiven, nicht für kontinuierliche Ströme (Latenz, Kosten, Datenexport).
• Pipeline: Azure IoT / AWS IoT Greengrass / Google Distributed Cloud Edge für die Erfassung, Cloud für Feintuning und Flottenverwaltung; Dienste wie Amazon Lookout for Equipment wurden in der Vergangenheit eingestellt oder geändert, daher den Lebenszyklus prüfen, bevor man sich darauf stützt.
• B wählen, wenn: Sie eigene Klassen mit wenigen Entwicklern brauchen und das Roh-Audio am Edge behalten können, sodass nur Embeddings oder Ereignisclips gesendet werden.

Weg C — Selbst betreiben (Open Source)

• Modelle: AST (MIT/BSD-artig über Hugging Face), BEATs (Microsoft, unilm), PANNs, PaSST, CLAP (LAION / Microsoft), YAMNet (TensorFlow Hub, Apache-2.0), BirdNET für Vögel (siehe SPEECH-015). Die Lizenz jedes Checkpoints prüfen: Manche sind nur für Forschung freigegeben.
• Werkzeuge: PyTorch/torchaudio, Hugging Face Transformers (audio-classification- Pipeline), ONNX Runtime, TensorFlow Lite, Baselines zur Schallereigniserkennung aus der DCASE- Challenge (DESED), MQTT + Node-RED oder n8n für Alarmierung, Grafana für Dashboards.
• Hardware: HW1 reicht für die Inferenz: Raspberry Pi 5, Jetson Orin Nano oder industrielle Gateways führen quantisierte kleine Audiomodelle in Echtzeit für mehrere Kanäle aus. Training oder Feintuning passt auf eine Workstation-GPU (HW2).

Weg D — Eigenes Training

Lohnt sich für standortspezifische Geräusche (Ihr Maschinentyp, Ihre Alarmtöne, die Akustik Ihres Gebäudes). Benötigt Hunderte beschrifteter Ereignisclips pro Klasse sowie viele Stunden Hintergrund- Audio, um Fehlalarmraten abzuschätzen; für die industrielle Anomalieerkennung genügen Geräusche des normalen Betriebs. Einen vortrainierten Audio-Encoder feintunen, statt von Grund auf zu trainieren; mit Raumimpulsantworten und Rauschmischung augmentieren.

Stand der Technik (2026)

• Vortrainierte Audio-Encoder (AST, BEATs, PaSST), auf AudioSet vortrainiert, dominieren die DCASE-Aufgaben zur Schallereigniserkennung und zum Tagging; stark beschriftete AudioSet-Teilmengen verbessern die zeitliche Genauigkeit auf Frame-Ebene [2][3].
• Audio-Sprachmodelle (CLAP-Familie und große Audio-Sprachmodelle) ermöglichen Zero-Shot- und per Text abfragbare Geräuschklassen sowie Audiobeschreibungen; die Genauigkeit bei seltenen oder sicherheitskritischen Klassen liegt noch unter der spezialisierter, abgestimmter Detektoren.
• Erkennung auffälliger Geräusche bei Maschinen ist eine etablierte DCASE-Aufgabe, mit Embedding-basierten Verfahren, die nur mit normalen Daten arbeiten [1].
• Grenzen und Fehlerbilder: Domänenverschiebung (ein auf AudioSet abgestimmtes Modell versagt in einem halligen Lager), überlagerte Quellen, geringer Störabstand, Klassenverwechslung (Schrei vs. Jubel) sowie gezielte oder zufällige Auslöser. Die Fehlalarmrate pro Tag und Mikrofon, nicht die Genauigkeit, ist die entscheidende Kennzahl. Aggressions- oder "Emotions"-Erkennung aus der Stimme ist wissenschaftlich umstritten und rechtlich sensibel.

Gemeinsame Bausteine & Kombinationen

• Gleicher Audio-Stack (audio-classification, edge-runtime): SPEECH-015 Bioakustik, SPEECH-008 Sprachverbesserung als Vorverarbeitung, SPEECH-023 Moderation von Sprach-Chats, SPEECH-016 Analyse von Notrufen.
• Nachgelagert: PRED-006 (vorausschauende Wartung), ANOM-005 (Prozess-Anomalieerkennung), VIS-004 (Anlagenüberwachung) für multimodale Fusion mit Kamera- und Schwingungsdaten.
• Hardware: eine HW1-Edge-Flotte plus eine gemeinsame HW2-Trainings-Workstation versorgt alle Anwendungsfälle der Audioklassifikation.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen; Lizenz pro Kamera/Kanal oder pro Sensor, plus Integration in VMS/Alarmzentrale.
• Weg B: 2–4 Monate; Kosten durch Datenabfluss, Beschriftung und Flottenverwaltung bestimmt.
• Weg C/D: 3–6 Monate inkl. Datenerhebung, Feldpilot und Schwellenwert-Abstimmung; Sensorhardware und Installation dominieren oft die Kosten.
• Kennzahlen: Precision und Recall pro Klasse, Fehlalarme pro Mikrofon und Tag, Erkennungs- latenz, Anteil der von Menschen bestätigten Alarme, mittlere Zeit bis zur Fehlererkennung, vermiedene ungeplante Stillstände, Arbeitsbelastung des Bedienpersonals.

Menschen & Veränderung

Beziehen Sie zuerst Geschäftsleitung und Fachabteilungsleitung (Sicherheit, Instandhaltung) ein, um den Zweck festzulegen: Schutz von Eigentum und Maschinen, nicht Beobachtung von Mitarbeitenden. IT und IT-Sicherheit folgen für Netzwerk, Mikrofonplatzierung und Alarmintegration; die oder der Datenschutzbeauftragte sollte den Aufbau prüfen, bevor ein Mikrofon installiert wird, da Audio Gespräche erfassen kann. Eine DSFA ist wahrscheinlich nötig, wo Mikrofone Arbeitsplätze oder Pflegeumgebungen abdecken, und mit jedem Cloud-Analyseanbieter ist ein AVV erforderlich.

Betriebsrat: ja. Dauerhaft laufende Mikrofone am Arbeitsplatz sind objektiv geeignet, Verhalten und Leistung zu überwachen, was die Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG auslöst (BAG: objektive Eignung genügt). Unterrichten Sie ihn früh nach §90 Abs. 1 Nr. 3; die Sachverständigenoption nach §80 Abs. 3 steht offen. Öffentlicher Dienst: Personalrat. Vereinbaren Sie in einer Betriebsvereinbarung, dass nur Ereignisse, keine Sprache, gespeichert werden und keine individuelle Leistungsbewertung stattfindet.

Kommunizieren Sie offen mit Hinweisschildern und einer Erklärung, was aufgezeichnet wird und was nicht. Starten Sie einen Pilot in einer Halle oder einem Gebäude mit einigen Endanwendern und Technikern, die Alarme prüfen. Typische Bedenken sind Überwachung und Fehlalarme: Begegnen Sie ihnen mit der Betriebsvereinbarung und einem abgestimmten Alarmschwellenwert. Bediener bestätigen einen Alarm immer, bevor gehandelt wird. Maßnahmen zur KI-Kompetenz sollten die Mitarbeitenden dabei unterstützen, die Grenzen der Erkennung zu verstehen (Art. 4 KI-Verordnung).

Siehe GUIDE-004, GUIDE-005 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Einstufung hängt von der Nutzung ab. Maschinengeräusch-Überwachung und Barrierefreiheits- Alarme: minimales Risiko. Sicherheitskomponenten kritischer Infrastruktur (Anhang III Nr. 2) können Hochrisiko sein. Biometrische Echtzeit-Fernidentifizierung und Emotionserkennung am Arbeitsplatz und in der Bildung sind nach Art. 5 verboten: Das Ableiten von Emotionen oder Stress aus den Stimmen von Beschäftigten ist in diesen Umgebungen unzulässig, daher darf Aggressions- oder "Emotions"-Erkennung nicht bei Beschäftigten eingesetzt werden. Der Einsatz durch Strafverfolgungsbehörden (z. B. Schussdetektion, die polizeiliches Handeln auslöst) kann unter die Hochrisiko- Regeln von Anhang III Nr. 6 fallen; diese Datei behandelt keine operativen polizeilichen Details.
• DSGVO: Schall, der Sprache enthalten kann, ist personenbezogen Daten, auch wenn das System nur Ereignisse will. Bevorzugen Sie Sensoren, die verständliche Sprache nicht rekonstruieren können (Inferenz auf dem Gerät, bandbegrenzte oder rein spektrale Verarbeitung, keine Speicherung von Roh-Audio), ein dokumentiertes berechtigtes Interesse oder eine Rechtsgrundlage, DSFA (Art. 35, systematische Überwachung öffentlicher Bereiche), Hinweisschilder und die Mitbestimmung des Betriebsrats in Deutschland (§87 BetrVG). Die Aufnahme nichtöffentlich gesprochener Worte kann zudem strafbar sein (§201 StGB, Deutschland), daher ist eine rechtliche Prüfung zwingend.
• ePrivacy / Fernmeldegeheimnis kann gelten, wenn Audio übertragen wird; kommunale Lärmüberwachung braucht eine Rechtsgrundlage im nationalen Recht.
• Sicherheit: Akustische Erkennung darf nicht die alleinige Sicherheitsfunktion sein; verpasste Ereignisse sind zu erwarten.
• Gegenmaßnahmen: Verarbeitung am Edge, kurze Aufbewahrung von Belegclips, Zugriffsprotokollierung, Zweckbindung, regelmäßige Fehlalarm-Audits, menschliche Bestätigung vor dem Handeln.

Erste Schritte

1. Die genauen Ereignisse und die jeweils ausgelöste Entscheidung festlegen; Anwendungsfälle ablehnen, die Sprachinhalte oder Emotionsableitung benötigen.
2. Frühzeitig eine rechtliche Prüfung und DSFA durchführen (Betriebsrat, Hinweisschilder, Aufbewahrung), bevor Mikrofone installiert werden.
3. 1–2 Wochen Hintergrund-Audio vor Ort mit den echten Sensoren aufnehmen, um die Referenz zu messen.
4. Ein vortrainiertes Modell (AST/BEATs/YAMNet) und ein kommerzielles Produkt gegen diese Daten testen; Fehlalarme pro Tag vergleichen.
5. Pilot mit von Menschen bestätigten Alarmen, Rückmeldungen protokollieren, dann Schwellenwerte abstimmen oder feintunen.

Quellen

1. DCASE Community — Detection and Classification of Acoustic Scenes and Events challenges — https://dcase.community/
2. Gong et al. — AST: Audio Spectrogram Transformer — https://arxiv.org/abs/2104.01778
3. Chen et al. — BEATs: Audio Pre-Training with Acoustic Tokenizers — https://arxiv.org/abs/2212.09058
4. Google Research — AudioSet ontology and dataset — https://research.google.com/audioset/
5. Hugging Face — Audio classification task documentation — https://huggingface.co/docs/transformers/tasks/audio_classification
6. Regulation (EU) 2024/1689 (AI Act), Art. 5 and Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. EDPB — Guidelines 3/2019 on processing of personal data through video devices (principles apply to audio monitoring) — https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en
8. Directive 2002/49/EC on environmental noise — https://eur-lex.europa.eu/eli/dir/2002/49/oj