Toll Collect organisiert als Bundesunternehmen die Maut in Deutschland und betreibt eines der größten satellitengestützten Mautsysteme der Welt, das wir auch für private Mautdienstanbieter öffnen. Darüber hinaus übernimmt Toll Collect im Interesse des Bundes vielfältige Aufgaben zur intelligenten Steuerung des Verkehrs. Hierzu zählen die Bereitstellung digitaler Plattformen, auf denen alle Beteiligten reibungslos zusammenarbeiten können. Zudem berät die Toll Collect mit umfangreichem Technologie-Knowhow ihre Kunden und verbindet mit ihnen gemeinsam Ideen und Dienstleistungen zu einer auf ihre Bedürfnisse zugeschnittenen Gesamtlösung. Weiterhin betreibt und entwickelt Toll Collect umfangreiche IT-Systeme von A bis Z: agil, datenschutzkonform und zuverlässig. Toll Collect schafft Mehrwert für die Gesellschaft. Wir analysieren Daten aus dem Mautsystem, die ein effizientes und nachhaltiges Verkehrsmanagement ermöglichen. Wir machen die Verkehrsinfrastruktur leistungsfähiger und erhöhen die Verkehrssicherheit. Wir verbessern öffentlich verfügbares Kartenmaterial und stellen offene Daten für Dritte bereit. Wir unterstützen den Bund dabei, seine anspruchsvollen Klimaziele zu erreichen. Die Toll Collect GmbH hat ihren Sitz in Berlin und beschäftigt rund 700 Mitarbeitende. Toll Collect betreibt mehrere hundert Kontrollgeräte - darunter Kontrollbrücken, Kontrollsäulen sowie mobile und portable Systeme -, die automatisiert Fahrzeugdaten und Fahrzeugbilder erfassen, sie auswerten und bewerten. Die automatische Kennzeichenerkennung (Automated Number Plate Recognition, kurz ANPR) spielt dabei eine wesentliche Rolle: amtliche Kennzeichen der kontrollierten Fahrzeuge werden aus den Fahrzeugbildern erkannt und es erfolgt eine Ermittlung des Herkunftslands. Dies bildet eines wichtige Grundlage für die Maut- und Verkehrssicherheitskontrolle, insbesondere bei der Datenzuordnung aus verschiedenen Datenquellen. Aktuell wird die Kennzeichenerkennung dezentral auf den einzelnen Kontrollgeräten selbst durchgeführt. Im Rahmen einer Weiterentwicklung der IT-Architektur betrachtet Toll Collect die Möglichkeit, diese Verarbeitungslogik zu zentralisieren und künftig in ihrem eigenen Rechenzentrum zu betreiben. Damit sollen unter anderem Wartbarkeit, Skalierbarkeit und die einheitliche Weiterentwicklung der Erkennungslogik verbessert werden. Als Betriebsplattform setzt Toll Collect auf OpenShift, eine containerbasierte On-Premise-Plattform, die einen flexiblen und sicheren Rechenzentrumsbetrieb ermöglicht. Da mehrere hundert Kontrollgeräte quasi gleichzeitig Anfragen erzeugen können, muss eine zentral betriebene ANPR-Software hochverfügbar und hochskalierbar sein sowie nahtlos in die bestehende IT-Infrastruktur integrierbar sein - ohne dabei die echtzeitnahe Kennzeichenerkennung in sehr hoher Qualität zu gefährden. Toll Collect möchte in Erfahrung bringen, welche Software mit welchen Funktionen und Randbedingungen für einen Rechenzentrumsbetrieb in einer OpenShift-Umgebung am Markt verfügbar sind, welche Schnittstellen sie bieten und insbesondere auch wie anpassbar die Lösungen im laufenden Betrieb sind, wie Optimierungen funktionieren könnten und in welchem Umfang und welchem Modell eine Lizensierung vonnöten wäre. Zur Vorbereitung eines möglichen Vergabeverfahrens führt die Toll Collect eine Markterkundung gemäß § 28 VgV durch. Mit der Anfrage im Rahmen der Markterkundung besteht ausdrücklich keine Absicht zur Verhandlung oder Auftragserteilung.

Markterkundung - Open Shift ANPR Dienst

Für die Maut- und Verkehrssicherheitskontrolle in Deutschland wird eine Software-Lösung benötigt, welche einen ANPR-Service in einer Open Container Plattform (OpenShift) realisiert. Die Lösung muss berücksichtigen, dass von mehreren hundert Kontrollgeräten quasi gleichzeitige Anfragen verarbeitet werden und in der Regel in weniger als einer halben Sekunde die Kennzeichenerkennung erfolgt sein muss. Idealerweise erfüllt die Software folgende Anforderungen: Fachlich-funktional: 1. Verarbeitung von Fahrzeugfront- und Fahrzeugheckbildern mit enthaltenen amtlichen Kennzeichen 2. Verarbeitung von Fahrzeugfront-, Fahrzeugheckbildern und Seitenbildern mit enthaltenen verkehrssicherheitsrelevanten Schildern und Kennzeichnungen 3. Verarbeitung dieser Bilder aus unterschiedlichen Systemen, gekennzeichnet durch verschiedene optische Verzerrungen (Aufnahme Überkopf, von der Seite), Belichtungen und Auflösung 4. Erkennen von Kennzeichentext inkl. Leerzeichen und Erkennen des Herkunftslands (ISO) des amtlichen Kennzeichens 5. Bilden eines Konfidenzwerts für Kennzeichentext und für Herkunftsland, jeweils als Maß für die Wahrscheinlichkeit, dass die Erkennung fehlerfrei war 6. Ausgaben weiterer Ergebniskandidaten für Kennzeichentext und Land (jeweils zweitwahrscheinlichstes Ergebnis mit zugehöriger Konfidenz) 7. Wie geht das System mit mehreren (Kennzeichen-)schildern in einem Bild um - werden mehrere Ergebnisse ausgegeben, welches wird als Hauptergebnis ausgegeben? 8. Kann die Software einen Hyptheseninput verarbeiten (kann ein Abgleich und eine Beeinflussung des Erkennungsergebnisses erfolgen, wenn aus einer anderen Quelle ein recht wahrscheinlicher Kennzeichentext+Nationalität dem System als Input mitgegeben wird?) 9. Wie hoch ist die typische Erkennungsrate für von Menschen eindeutig erkennbaren Kennzeicheninhalten? 10. Was ist die notwendige Bildauflösung (Mindesthöhe von Zeichen und optimale Höhe von Zeichen in Pixeln)? 11. Sieht die Software auch eine Erkennung des Fahrzeugtyps oder bestimmter Fahrzeugeigenschaften vor (speziell im Nutzfahrzeugbereich)? 12. Ist die Software auch in der Lage bestimmte Fahrzeugkennzeichnungen zu erkennen, z.B. Gefahrgut-Warntafeln (ADR-Plaketten)? Fachlich-betrieblich: 1. Berücksichtigung von zulässigen Syntaxen (Es wird davon ausgegangen, dass das System per OCR erkannte Zeichenfolgen mit zulässigen Syntaxen abgleicht und ggf. die erkannte Zeichenfolge anpasst. Dies ist aber keine Anforderung.) 2. Anpassbarkeit von zulässigen Syntaxen (Sofern das System zulässige Syntaxen verwendet, durch wen erfolgt wie die Aktualisierung von zulässigen Syntaxen?) 3. Grundsätzliche Funktionsweise basiert auf maschinellem Lernen? 4. Unmittelbare Einsetzbarkeit bzgl. der zu erwartenden Kennzeichen (kann das System unmittelbar in Deutschland eingesetzt werden oder wären Anpassungen/KI-Learning vorzusehen?) 5. Bildverarbeitung: a. Unmittelbare Einsetzbarkeit bzgl. der zu erwartenden Kennzeichenbilder (kann das System unmittelbar eingesetzt werden, obwohl die Bilder mit enthaltenen Kennzeichen verschiedene Aufnahmeparameter wie Bildwinkel, Bildgrößen, Belichtungen aufweisen oder wären Anpassungen/KI-Learning vorzusehen?) b. Würden Bilder durch das System mit Filter und Verzerrungsverfahren wie z.B. Rekifizierungsalgorithmen vorverarbeitet oder ist dies für das eingesetzte Erkennungsverfahren unnötig? c. Wären Filter und Verzerrungsverfahren wie z.B. Rekifizierungsalgorithmen durch Programmierung oder durch Konfiguration anzupassen, sobald ein neues Kontrollgerät (mit eigenen Bildwinkeln, -größen, -belichtungen) einzusetzen wäre? 6. stetiges Lernen versus projektbasierte Updates versus regelmäßiger Herstellerverbesserungen a. Sieht der Hersteller regelmäßige Updates mit Verbesserungen der Erkennungsleistung vor? b. Sind diese regelmäßigen Updates kostenfrei? c. Sind diese regelmäßige Updates verpflichtend einzusetzen, bzw. wie lange werden 'alte' Versionen supportet? d. Sofern durch den Betreiber Verbesserungspotenziale aufgezeigt werden (z.B. durch Sammlung wiederkehrender systematischer Fehlerkennungen), wer könnte das System verbessern - der Betreiber (Toll Collect) selbst oder nur der Hersteller? e. Unterstützt das System so etwas wie stetiges Lernen / Reinforcement Learning, im Sinne einer regelmäßigen Verbesserung durch systemisch erfasstes Anwenderfeedback, welches schrittweise gesammelt wird und dann in das System eingespielt wird? f. Unterstützt das System so etwas wie stetiges Lernen / Reinforcement Learning, im Sinne einer regelmäßigen Verbesserung durch systemisch erfasstes Anwenderfeedback, welches direkt im produktiven Betrieb in das System je Einzelfall eingeht? 7. Generiert das System eigenständig statistische Informationen im laufenden Einsatz (z.B. Kennwerte entlang der Konfidenzwerte, der Länderverteilung erkannter Kennzeichen, der Verarbeitungsdauer, ..)? Technisch-betrieblich: 1. Lauffähig in einer Open-Container-Plattform (OpenShift), On-Premise. 2. Container-Image basiert auf einer Linux-Distribution (welcher? RHEL oder UBI gegeben oder möglich?) 3. Nutzung von Kubernetes-Operatoren, um den Lebenszyklus (Installation, Update) der Software zu automatisieren 4. Monitoring & Logging des Container kann mittels Prometheus/Grafana erfolgen, Metriken sind über einen HTTP-Endpunkt verfügbar 5. Ressourcenverbrauch: welche Prozessor- und Speicheranforderungen stellt das System entlang verschiedener Mengen zu erkennender Kennzeichen je Sekunde (250, 500, 1000, 2000 Erkennungen/sek) bei einer Antwortzeit < 0,5 Sek 6. Wird eine Hardware-Beschleunigung unterstützt, wie ändern sich die Prozessor- und Speicheranforderungen, wenn NVIDIA-GPUs/GPUaaS genutzt werden können? 7. Realisierung von Schnittstellen mit aktuellen Standards (REST-Schnittstelle gegeben oder möglich?) 8. Hat die Engine eine eigene Datenhaltung, benötigt sie eine Datenbank (ist sie stateless?) 9. Wird eine Logging-Schnittstelle unterstützt (z.B. Splunk)?