WBSO-Beispiele: Software und Programmierung (8)
Matching-Plattform mit Latenzgrenze
Situation: Ein SaaS-Unternehmen muss 250.000 Kandidaten in Echtzeit vergleichen.
Programmiertechnisches Problem: Bestehende Datenstrukturen erreichen die erforderliche Latenz innerhalb des verfügbaren Speicherbudgets nicht.
Eigenentwicklung: Neue Partitionierungs- und Bewertungsmethode, umgesetzt in eigener Software.
Warum möglicherweise WBSO: Technisch neuartiges informationstechnologisches Funktionsprinzip + technische Unsicherheit.
Fällt nicht unter S&O: Benutzeroberfläche, standardmäßige API-Anbindungen und Cloud-Konfiguration.
KI-Inferenz auf Edge-Hardware
Situation: Ein Bildverarbeitungsmodell muss auf der verfügbaren Edge-Hardware eine ausreichende Bildrate erreichen.
Programmiertechnisches Problem: Das bestehende Modell überschreitet die Vorgaben für Speicher- und Energieverbrauch; Standard-Laufzeitumgebungen bieten keine Lösung.
Eigenentwicklung: Eigene Software für Verarbeitung, Ablaufplanung und Modellausgabe.
Warum möglicherweise WBSO: Das technische Problem liegt in der eigenen Software, nicht in der Anwendung des Modells.
Fällt nicht unter S&O: Ein bestehendes KI-Modell über eine API integrieren.
Verteilte Datenplattform für Sensordatenströme
Situation: Millionen von Sensoren liefern kontinuierlich Telemetriedaten, die in Echtzeit analysiert werden müssen.
Programmiertechnisches Problem: Bestehende Message-Broker und Datenbanken erreichen die erforderliche Kombination aus Durchsatz und Konsistenz nicht.
Eigenentwicklung: Eigene Verteilungs- und Konsistenzschicht mit einer neuen Verarbeitungspipeline.
Warum möglicherweise WBSO: Neues informationstechnologisches Funktionsprinzip + Skalierungsunsicherheit.
Fällt nicht unter S&O: Eine bestehende Plattform lediglich horizontal skalieren.
Eingebetteter Regelalgorithmus für ein autonomes Fahrzeug
Situation: Ein Aggregat soll mit begrenzter Rechenleistung autonom navigieren.
Programmiertechnisches Problem: Bestehende Planungsalgorithmen sind für die Embedded-Zielplattform zu langsam oder zu umfangreich.
Eigenentwicklung: Eigener reduzierter Algorithmus mit einer neuen Speicher- und Timingarchitektur.
Warum möglicherweise WBSO: Programmiertechnischer Engpass + ungewisse Realisierbarkeit auf der Zielplattform.
Fällt nicht unter S&O: Standard-Navigationssoftware lediglich parametrisieren.
Eigenes Datenbankschema für Zeitreihen
Situation: Eine industrielle Plattform muss hochfrequente Messdaten sekundengenau speichern und unmittelbar abfragen können.
Programmiertechnisches Problem: Generische Datenbanken verlieren bei dieser Kombination aus Schreib- und Lesevorgängen an Leistung.
Eigenentwicklung: Eigene Speicher- und Indexierungsstruktur für Zeitreihen.
Warum möglicherweise WBSO: Neue Datenstruktur mit ungewisser Leistung unter Produktionslast.
Fällt nicht unter S&O: Eine bestehende Zeitreihendatenbank installieren und konfigurieren.
Sicherheitsarchitektur mit Zero-Knowledge-Verifizierung
Situation: Eine Fintech-Plattform muss Transaktionen verifizieren, ohne vertrauliche Daten weiterzugeben.
Programmiertechnisches Problem: Bestehende Protokolle erfüllen die Anforderungen an Geschwindigkeit und Beweisgröße nicht gleichzeitig.
Eigenentwicklung: Eigenes Verifikationsprotokoll und eigene kryptografische Implementierung.
Warum möglicherweise WBSO: Technisch neuartiges Funktionsprinzip in der Software + ungewisse Leistungsfähigkeit.
Fällt nicht unter S&O: Standard-TLS und bestehende Bibliotheken einsetzen.
Modellkomprimierung für Echtzeitprognosen
Situation: Ein Vorhersagemodell muss in einer Produktionsumgebung innerhalb von Millisekunden Ergebnisse liefern.
Programmiertechnisches Problem: Vollständige Modelle sind zu langsam; bestehende Komprimierungstechniken führen zu einem zu hohen Genauigkeitsverlust.
Eigenentwicklung: Eigene Kompressions- und Quantisierungsmethode unter Beibehaltung der Genauigkeit.
Warum möglicherweise WBSO: Programmiertechnischer Engpass + ungewisser Zielkonflikt bei der Genauigkeit.
Fällt nicht unter S&O: Ein kleineres Standardmodell aus einem Katalog auswählen.
Skalierbare Rendering-Engine für Konfiguratoren
Situation: Ein 3D-Konfigurator soll auf durchschnittlicher Hardware fotorealistische Vorschauen im Browser rendern.
Programmiertechnisches Problem: Bestehende Engines erreichen die erforderliche Kombination aus Qualität und Bildrate nicht ohne ressourcenintensive Plug-ins.
Eigenentwicklung: Eigene Rendering-Pipeline mit einer neuen Level-of-Detail-Strategie.
Warum möglicherweise WBSO: Neues informationstechnologisches Funktionsprinzip + Leistungsunsicherheit.
Fällt nicht unter S&O: Eine bestehende Engine lediglich über ihre Einstellungen abstimmen.
Formale Programmiersprache: Die technisch neuartige Lösung wird tatsächlich als Software in einer formalen Programmiersprache umgesetzt. Es bleibt nicht bei einem Algorithmus, einer Architektur oder einem funktionalen Entwurf.
→ WBSO-Software und -Programmierung · ausführliches Matching-Fallbeispiel ansehen