DiMoGro_Leistungsbeschreibung_Stauprognose_Final_2_20260911.pdf

[Seite 1]

Leistungsbeschreibung Einführung eines Wirkungsanalyse-/Stauprognosewerkzeugs für geplante Baumaßnahmen sowie eines Prognosetools für Verkehrsdaten (Stand 15.09.2026)

1 Vorbemerkung Die Stadt Aachen plant im Rahmen des Fördervorhabens „DiMoGro – Digitales Mobilitätsmanagement bei Großveranstaltungen“ die Umsetzung eines innovativen, datenbasierten Verkehrsleitsystems. Ziel des Projekts ist es, durch digitale und adaptive Steuerungsinstrumente eine effiziente, nachhaltige und nutzerorientierte Verkehrsabwicklung für alle Verkehrsträger sicherzustellen. Zur Koordinierung von Baumaßnahmen im öffentlichen Straßenraum nutzt die Stadt Aachen bereits das System ROADS (Roadwork Administration and Decision System)1. ROADS bündelt die Erfassung und Abstimmung von Baumaßnahmen, liefert jedoch keine belastbare Aussage darüber, welche Auswirkungen einzelne oder überlagernde Maßnahmen auf den Verkehrsfluss und die Netzkapazität haben. Zur Schließung dieser Lücke sollen zwei ergänzende Werkzeuge beschafft werden, die beide zwingend mit dem vorhandenen System ROADS kompatibel sein bzw. daran angebunden werden müssen: (1) Ein Tool zur verkehrlichen Wirkungsanalyse bzw. Stauprognose für Baumaßnahmen: Dieses soll auf Basis eines Verkehrsmodells die verkehrlichen Auswirkungen geplanter Baumaßnahmen (Einzel- und Kombinationsmaßnahmen) simulieren und Entscheidungsgrundlagen für Planungsvarianten liefern. (2) Ein KI-gestütztes Prognosetool für Verkehrsdaten: Dieses soll historische und echtzeitnahe Verkehrsdaten zu einer laufenden, kurzfristigen Verkehrs-/Stauprognose nutzen. Das Wirkungsanalyse-/Stauprognosewerkzeug soll als fachliche Grundlage ein geeignetes, mit einer marktüblichen Verkehrsplanungs-Simulationssoftware kompatibles Verkehrsmodell nutzen. Bei der Stadt Aachen wird aktuell das makroskopisches Verkehrsmodell PSV der Firma Helmert verwendet. Da dieses voraussichtlich nicht die für die Baustellen-Wirkungsanalyse erforderliche Netz-, Kapazitäts- und Umlegungslogik enthält bzw. in einer unmittelbar nutzbaren Form abbildet, sollte dieses bestehende Modell in ein kompatibles Modell überführt („übersetzt“) werden oder ein Neuaufbau durchgeführt werden (hierzu sollte das Straßennetz von OpenStreetMaps verwendet werden). Die Entwicklung der ausgeschriebenen Lösungen hat in einem iterativen und gemeinschaftlichen Prozess zwischen Auftraggeber und Auftragnehmer zu erfolgen. Der Auftragnehmer (AN) hat seine Leistungen so zu erbringen, dass fachliche Anforderungen, technische Rahmenbedingungen und Erkenntnisse aus der praktischen Erprobung fortlaufend aufgenommen, abgestimmt und in die weitere Umsetzung überführt werden können. Hierfür ist eine enge Zusammenarbeit mit dem Auftraggeber (AG) während Konzeption, Entwicklung, Erprobung und Weiterentwicklung sicherzustellen. Der AN hat während der Projektlaufzeit regelmäßige Abstimmungs- und Reviewtermine mit dem AG durchzuführen. Zwischenergebnisse sind in geeigneter Form vorzulegen und mit dem AG abzustimmen. Erkenntnisse aus diesen Abstimmungen sind in die weitere Leistungserbringung einzubeziehen.

2 Ausgeschriebene Leistungen Das Ziel dieser Vergabe ist: ▪ Die Bewertung der verkehrlichen Wirkung von in ROADS geplanten Baumaßnahmen (Einzelmaßnahmen und Maßnahmenkombinationen) vor deren Umsetzung. ▪ Die Bereitstellung eines belastbaren, mit ROADS und dem zu beschaffenden Wirkungsanalysewerkzeug kompatiblen Verkehrsmodells für das Aachener Stadtgebiet (inkl. Umland-Verflechtungen, sofern für die Aussagekraft erforderlich). ▪ Die Einführung eines fortlaufenden, mit den städtischen Systemen kompatiblen Prognosetools für Verkehrsdaten zur kurzfristigen Stau- und Reisezeitprognose auf Basis historischer und aktueller Verkehrsdaten. ▪ Die Nutzbarkeit beider Werkzeuge durch Sachbearbeitung ohne vertiefte verkehrstechnische Ausbildung. Der AN hat die nachfolgend beschriebenen Leistungen vollständig zu erbringen.

1 ROADS City

[Seite 2]

2.1 Baustein A – Einführung eines Wirkungsanalyse-/Stauprognosewerkzeugs für Baumaßnahmen (Simulationssoftware) Die Simulationssoftware muss die Auswirkungen von geplanten Baumaßnahmen auf die zu erwartende Verkehrssituation darlegen können, um somit eine Entscheidungshilfen für unterschiedliche Planungsvarianten zu bilden. Hierzu müssen die in ROADS definierten Flächen und Zeiträume von Maßnahmen in das Werkzeug vollautomatisch integriert werden, sodass Voll-/Teilsperrungen aus unterschiedlichen Planungsszenarien im städtischen Verkehrsmodell berücksichtigt und simuliert werden können. Insbesondere ist relevant, dass bei dem Start einer Simulation alle Maßnahmen im gewählten Zeitraum Beachtung finden. Um eine effiziente Bearbeitung zu gewährleisten sind folgende Parameter einzuhalten: ▪ Datenherkunft des Verkehrsmodells: Es ist das bereits vorhandene Verkehrsmodell der Stadt Aachen (PSV der Firma Helmert) als Ausgangsbasis zu verwenden und ggf. um zusätzlich benötigte Informationen zu ergänzen („Übersetzung“) bzw. ein mit der Simulationssoftware kompatibles Modell aufzusetzen. ▪ Schnittstelle: Die Simulationssoftware und ROADS müssen ohne Medienbrüche eine Simulation ermöglichen. ▪ User Experience: Die Software muss so gestaltet sein, dass keine umfangreiche Einarbeitung notwendig ist (Intuitive Benutzeroberfläche). ▪ Darstellung der Ergebnisse: Die Anwendung muss in einer grafischen Oberfläche darlegen, welche Auswirkungen (Verkehrsverdrängung) bei einem Eingriff zum Tragen kommen. Etwaige Kapazitätsübersteigungen müssen dargestellt werden. ▪ Dokumentation der Prognosegüte (z. B. Genauigkeit, Prognosehorizont, bekannte Einschränkungen) sowie Bereitstellung geeigneter Möglichkeiten zur fachlichen Plausibilisierung der Ergebnisse durch die Sachbearbeitung, damit Prognosen nachvollziehbar eingeordnet und im Zweifel fachlich hinterfragt werden können. Die Ergebnisse aus der Verkehrssimulation müssen anhand einer grafischen Darstellung (direkt im System oder ggf. als PlugIn in ROADS) präsentiert werden. Hierbei sollen elementare Bestandteile der Verkehrsmodellierung betrachtet werden. Diese sind: Verkehrsstärke, Netzlast sowie Veränderungen bei den Reisezeiten.

2.2 Baustein B – Prognosetool für Verkehrsdaten Ergänzend zur Simulationsanalyse von einzelnen Baumaßnahmen (Baustein A) soll ein fortlaufend arbeitendes, KI-gestütztes Prognosetool für Verkehrsdaten eingeführt werden. Es bildet unabhängig von konkreten Baumaßnahmen die aktuelle und kurzfristig zu erwartende Verkehrslage im Aachener Stadt-/Straßennetz ab und ergänzt damit die einmalige, planungsbezogene Simulation aus Baustein A um eine laufende, datengetriebene Beobachtung des realen Verkehrsgeschehens. Fachlich soll dabei ein zweistufiger Ansatz zur Anwendung kommen: eine strategische, modellbasierte Abbildung der grundsätzlichen Verkehrsnachfrage, verknüpft mit einer laufenden Fusion aktueller Echtzeitdaten. Im Einzelnen umfasst Baustein B folgende Leistungen: ▪ Bereitstellung/Einrichtung eines KI-gestützten Prognosetools für Verkehrsdaten für das Aachener Stadt- /Straßennetz, kompatibel zu ROADS und den übrigen Bestandssystemen. Das Tool ist so auszulegen, dass es sich ohne Medienbrüche in die bestehende IT-Landschaft der Stadt Aachen einfügt und Ergebnisse mit den in ROADS geführten Baumaßnahmen in Bezug setzen kann. ▪ Anbindung der verfügbaren Verkehrsdatenquellen der Stadt Aachen, insbesondere Verkehrsrechner, stationäre Detektoren, Zähldaten, ggf. Floating-Car- bzw. Mobilfunkdaten sowie einschlägige Open-Data- Quellen. Vorgelagert ist eine Bestandsaufnahme der vorhandenen Schnittstellen und der verfügbaren Datenqualität durchzuführen. Darauf aufbauend sind die technisch und wirtschaftlich sinnvollen Datenquellen für die Prognose auszuwählen und anzubinden. ▪ Floating-Car-Daten (Echtzeitdaten) sollen von den Bietern optional mitangeboten werden. Dabei ist von zentraler Bedeutung, dass die Stadt Aachen berechtigt ist, diese Daten auch außerhalb des Prognosetools zu nutzen – insbesondere zur Anzeige und Nutzung in ihrem Mobilitätsdashboard sowie in einem digitalen Zwilling der Stadt. Entsprechende Nutzungs- und Weiterverarbeitungsrechte sind im Angebot auszuweisen und vertraglich abzusichern. ▪ Netzweite Verkehrslageschätzung: Die angebundenen (Echtzeit-)Daten sollen mit einer strategischen, modellbasierten Abbildung der Verkehrsnachfrage verknüpft werden (z. B. auf Basis typischer Tagestypen wie Werktag, Samstag, Sonntag und geeigneter zeitlicher Aggregation). Ziel ist eine belastbare

[Seite 3]

Einschätzung der Verkehrslage (Verkehrsstärken, Geschwindigkeiten, Reisezeiten) im gesamten Straßennetz – auch dort, wo keine eigenen Echtzeitdaten vorliegen. ▪ Laufende, kurzfristige Stau- und Reisezeitprognose auf Basis der Verknüpfung historischer und aktueller Verkehrsdaten. Die Kurzfristprognose (z. B. für einen Zeithorizont von 30 bis 60 Minuten) soll modellbasierte mit KI-gestützten Verfahren kombinieren, etwa durch den Abgleich aktueller Verkehrsmuster mit automatisiert erlernten, typischen Tagesganglinien, um die Prognosegüte gegenüber einer rein modellbasierten Vorhersage zu erhöhen. Das System soll neu eingehende Daten fortlaufend zur Verbesserung der Prognosequalität nutzen, ohne dass hierfür im Regelbetrieb ein manueller Eingriff der Sachbearbeitung erforderlich ist. ▪ Bereitstellung der Prognoseergebnisse zur Weiterverwendung innerhalb der Stadtverwaltung, etwa für die operative Verkehrslenkung, die Bürgerinformation sowie die Abstimmung und Koordination von Baustellen in Zusammenspiel mit ROADS und dem Werkzeug aus Baustein A. ▪ Dokumentation der Prognosegüte (z. B. Genauigkeit, Prognosehorizont, bekannte Einschränkungen) sowie Bereitstellung geeigneter Möglichkeiten zur fachlichen Plausibilisierung der Ergebnisse durch die Sachbearbeitung, damit Prognosen nachvollziehbar eingeordnet und im Zweifel fachlich hinterfragt werden können. ▪ Optionaler, wünschenswerter Zusatzpunkt (keine Mindestanforderung): grundsätzliche Eignung bzw. Erweiterbarkeit des Prognosetools für eine künftige Online-Entscheidungsunterstützung, etwa zur Empfehlung optimaler Lichtsignalanlagen-Programme auf Basis der Kurzfristprognose. Anforderungen an die beiden Bausteine.

2.3 Funktional ▪ Konsistente (automatisierte) Übernahme von Maßnahmendaten aus ROADS in die Simulationssoftware ohne redundante Doppelerfassung. ▪ Web-basierte, für Fachpersonal ohne Verkehrsmodellierungs-Kenntnisse bedienbare Oberfläche für die Simulationssoftware. ▪ Nachvollziehbare, exportierbare Ergebnisdarstellung (Berichte, Karten) für Abstimmungen mit Baulastträgern, Politik und Öffentlichkeit in beiden Bausteinen. ▪ Beide Systeme müssen responsiv gestaltet sein, sodass eine Nutzung auf Tablets, Desktop-PCs mit entsprechenden üblichen Bildschirmen sowie auf großen Präsentationsbildschirmen (Touchscreen) gleichermaßen möglich ist. ▪ Beide Bausteine müssen über eine Benutzer*innenverwaltung verfügen und jeweils eine parallel Nutzung von 10 Nutzenden ermöglichen.

2.4 Technisch / organisatorisch ▪ Das Hosting-Modell (Cloud/SaaS), die Betriebsverantwortung und die Service-Level sind anzubieten und darzustellen. ▪ Die jeweiligen Schnittstellen zu städtischen Bestandssystemen (z. B. ROADS, Verkehrsrechner, Geodateninfrastruktur) sind zu spezifizieren. ▪ Es sind ausführliche Informationen zum Datenschutz- und IT-Sicherheitskonzept (u.a. Auftragsverarbeitung, Standort der Datenhaltung, Löschkonzept) darzulegen. ▪ Es ist eine Einweisung/Schulung der Nutzenden sowie die Übergabe einer Betriebs- und Pflegedokumentation für das Verkehrsmodell mitanzubieten. ▪ Zuverlässigkeit: Das System soll mindestens Werktags (NRW) im Rahmen der üblichen Arbeitszeiten (07:00 bis 18:00 Uhr) zur Verfügung stehen. Wartungsarbeiten am System sind außerhalb dieser Zeiten vorzunehmen bzw. entsprechende Zeitfenster sind nach Rücksprache gesondert zu vereinbaren. Die Ausfallquote soll wöchentlich 2 % der Bereitstellungszeit nicht überschreiten. Die Bieter haben Angaben zur Verfügbarkeit der Systeme zu machen (z.B. Verfügbarkeits-SLA während der Betriebszeiten, Reaktions- und Wiederherstellungszeiten bei Störungen, Eskalationswege) sowie ihr Konzept für Redundanz, Datensicherung/Backup und Notfallwiederanlauf darzustellen. Einzelne technische Störungen dürfen nicht zum Ausfall der jeweils anderen Komponente (Baustein A bzw. B) führen.

[Seite 4]

▪ Effizienz: Einfach Anfragen an die Systeme (z.B. Abruf von Informationen) sollen in 80 % der Fälle in unter 0,1 s verarbeitet und beantwortet werden. Komplexe Vorgänge (Zoomen in der kartographischen Darstellung, Sichern von Informationen) sollen in 80 % der Fälle in unter 2 s verarbeitet und beantwortet werden. Die Systeme sind so auszulegen, dass Simulationen und Prognosen in für die Praxis handhabbaren Antwortzeiten laufen und mit dem Aachener Gesamtnetz sowie einer wachsenden Zahl gleichzeitiger Baumaßnahmen und Nutzender performant umgehen können. Wiederkehrende Aktualisierungen (z. B. Verkehrsdatenimporte, Modellfortschreibung) sind so weit wie möglich zu automatisieren, um den manuellen Pflegeaufwand für die Stadt Aachen gering zu halten. ▪ Datenschutz/Sicherheit: Die Verarbeitung personenbezogener bzw. personenbeziehbarer Daten (insbesondere im Rahmen von Baustein B, z. B. Floating-Car- oder Mobilfunkdaten) hat im Einklang mit der DSGVO zu erfolgen; ein Auftragsverarbeitungsvertrag ist vorzulegen. Erforderlich sind außerdem Angaben zu Verschlüsselung von Daten bei Übertragung und Speicherung, zu einem Rollen- und Berechtigungskonzept sowie zum Umgang mit Sicherheitsupdates und -vorfällen (u. a. Zeitrahmen für das Einspielen kritischer Patches, Meldewege bei Sicherheitsvorfällen). ▪ Wartungsarbeiten sind am Produktionssystem so durchzuführen, dass die Verfügbarkeit des Systems nicht beeinträchtigt wird (z. B. durch Wartungsfenster außerhalb der Kernnutzungszeiten, redundante Systemkomponenten oder vorherige Ankündigung mit ausreichendem Vorlauf). ▪ Zusammenspiel mit anderen Systemen/Kompatibilität: Da die Systeme als SaaS bereitgestellt werden sollen, kommt es zu keinem direkten Kontakt mit dem im städtischen Netz befindlichen Systemen. Lediglich der Zugang über z.B. den Browser müsste hier betrachtet werden. So ist sicherzustellen, dass bei einem Ausfall/Versagen des städtischen Netzes die in den Systemen in Bearbeitung befindlichen Daten automatisch gesichert werden. Aus Sicherheitsgründen ist ein automatisierter Logout eines inaktiven Nutzers nach 15 Minuten Inaktivität durchzuführen. Auch in einem solchen Fall sind die in Bearbeitung befindlichen Daten zu sichern. Nach erneutem Login des automatisch aus den Systemen ausgeloggten Nutzers ist ein Hinweis auf diesen automatischen Login in Datensicherung zu erfolgen. ▪ Datensicherung: Die im System hinterlegten Daten sind (werk)täglich zu sichern (Sicherungskopie). Sicherungskopien sind für mindestens 20 Werktage aufzubewahren.

2.5 Nicht Gegenstand dieser Leistungsbeschreibung ▪ Beschaffung/Erneuerung der städtischen Verkehrsdetektions- oder Verkehrsrechner-Hardware. ▪ Grundlegende Neuerhebung von Verkehrszähldaten, soweit für die Kalibrierung nicht zwingend erforderlich.

3 Rahmenbedingungen

• Die beiden Bausteine sind in deutscher Sprache bereitzustellen und nach dem aktuellen Stand der Technik umzusetzen.

• Eine erste funktionsfähige Version der beiden Bausteine ist 10 Wochen nach Bereitstellung der städtischen Daten zu erbringen.

• Neben einer ausführlichen Dokumentation sollen die Ergebnisse auch im Rahmen einer ein- bis zweistündigen Präsentation dem AG vorgestellt werden.

• Der AN stellt zum Einführungsbeginn, anhand eines Schulungskonzeptes, eine intensive Grundlagenschulung für ein Kernteam bereit (Online). Die Schulungsinhalte sind insbesondere die Benutzerverwaltung sowie Aufbau und Komponenten der technischen Plattform daneben bietet der Anbieter eine Einsteigerschulung für Nutzer*innen an, welche das System vorstellt und anhand von praktischen Beispielen die Funktionen erklärt.

• Die Kosten für die SaaS-Bereitstellung von einem Jahr sind anzugeben. Kosten für optionale Leistungen sollen positionsweise angegeben werden.

• Der AN muss die Vorgaben der gültigen DSGVO sowie die datenschutzrechtlichen Vorgaben der Stadt Aachen erfüllen. Zwischen dem Anbieter und der Stadt Aachen muss eine Datenschutzvereinbarung gemäß den Vorschriften zur Auftragsdatenverarbeitung nach der EU Datenschutzgrundverordnung (Art. 4 Nr. 2, 8 und Art. 28 DSGVO) geschlossen werden.

[Seite 5]

• Vertragslaufzeit: o Der Vertrag beginnt mit der Abnahme der finalen Lösung gemäß Ziffer 6 (Vertragsbeginn). Die Abnahme der finalen Lösungen erfolgt spätestens 4 Monate nach Bereitstellung der städtischen Daten. Das genaue Datum der Abnahme und damit des Vertragsbeginns wird zwischen AG und AN im Rahmen der Abnahme schriftlich festgehalten. o Die Laufzeit beträgt 1 Jahr ab Vertragsbeginn.

• Die Angebotspreise ist im Formblatt „Preisangebot“ getrennt auszuweisen nach (a) den einmaligen Konzeptionskosten und (b) den jährlichen Lizenz-/Nutzungs- bzw. Pflegekosten.

4 Teilnahmewettbewerb – Eignungsprüfung Im Rahmen des Teilnahmewettbewerbs weisen die Bewerber ihre Eignung insbesondere anhand einer Referenzliste nach. Gefordert werden Angaben zu den wesentlichen, in den letzten drei Jahren vor Veröffentlichung der Auftragsbekanntmachung erbrachten vergleichbaren Leistungen (Umfang/Auftragswert, Ausführungsort, Ausführungszeit, Auftraggeber mit Adressdaten).

• Der Bewerber muss mindestens zwei Referenzprojekte aus den letzten drei Jahren benennen, die mit dem hier ausgeschriebenen Leistungsgegenstand vergleichbar sind (die Referenzstadt muss mindestens 100.000 Einwohner haben), insbesondere im Hinblick auf die Umsetzung von Simulations- bzw. Prognosetools im Kontext der Maßnahmenkoordinierung oder Verkehrsmodellierung (Angabe des Umfangs der Leistung/Auftragswert, Ausführungsort, Ausführungszeit, AG mit Adressdaten). Bewerber, die diese Mindestanforderung nicht erfüllen, werden vom weiteren Verfahren ausgeschlossen. ▪ Ein Referenzprojekt davon ist hierbei ausführlich zu beschreiben. Der Umfang sollte 2 DIN-A4-Seiten nicht überschreiten. ▪ Auswahlkriterium bei Bewerberüberhang: Sofern mehr geeignete Bewerber vorliegen, als zur Angebotsabgabe aufgefordert werden sollen, wählt der AG anhand der Vergleichbarkeit und Aussagekraft der eingereichten Referenzen (Ähnlichkeit der Randbedingungen zu den geforderten Leistungen in Aachen, Auftragswert sowie Komplexität der Arbeiten) die am drei besten geeigneten Bewerber transparent und diskriminierungsfrei aus und fordert diese zur Angebotsabgabe auf. Die Referenzen sind ausschließlich Gegenstand der Eignungsprüfung im Teilnahmewettbewerb. Sie fließen nicht erneut in die Zuschlagsbewertung der Angebote ein (vgl. nachfolgender Abschnitt „Angebotsbewertung“).

5 Angebotsbewertung Das Vergabeverfahren wird nach Verhandlungsvergabe mit Teilnahmewettbewerb nach § 8 UVgO durchgeführt. Hierbei sind folgende Unterlagen einzureichen:

• Umfängliche und vollständige Unterlagen (ggf. mit Bildunterstützung) zur Darstellung der geplanten technischen Umsetzung („Grobkonzept“): o Beschreibung der allgemeinen Herangehensweise zur Erbringung der geforderten Leistungen o Grobe Skizzierung der technischen Lösungen und Umfänge der angebotenen Leistungen o Darstellung eines Zeitplans zur Durchführung der Leistung o Angaben zum Umgang mit personenbezogenen Daten und zur Einhaltung der Datenschutzgrundverordnung (Datenschutz) sowie der IT-Sicherheit Die Wertung der Angebote erfolgt durch ein Gremium von Mitarbeitenden der AG mit Hilfe eines Punktesystems auf Grundlage folgender Matrix:

[Seite 6]

Wertung des Kriteriums „Preis“ (siehe Formblatt Preisangebot): Gewertet wird der Gesamtpreis brutto über die Positionen 1 bis 3. Der Anbieter mit dem niedrigsten Gesamtangebotspreis erhält die maximale Punktzahl (10 Punkte). Die weiteren Angebote erhalten ihren Punktwert nach der Formel: Niedrigstes Angebot ÷ zu wertendes Angebot x Maximalpunktwert (10). Das Ergebnis wird auf 2 Stellen nach dem Komma gerundet Die im Formblatt anzugebenden Stundenlohnsätze für evtl. zusätzlich anfallende Arbeiten, die noch nicht vorhersehbar sind, sind nicht wertungsrelevant. Wertung des Kriteriums „Grobkonzept“: Es ist darzulegen, wie die geforderten Leistungen umgesetzt werden sollen. Gewertet wird die Qualität der angebotenen Leistung, wie sie sich aus dem eingereichten Grobkonzept ergibt. Das Kriterium „Grobkonzept" gliedert sich in vier Unterkriterien, die jeweils einzeln mit einer Punktzahl von 0 Punkten (schlechteste Punktzahl) bis 10 Punkten (beste Punktzahl) bewertet und wie folgt gewichtet werden:

Bewertet werden bei jedem Unterkriterium Nachvollziehbarkeit, Schlüssigkeit und fachliche Qualität der im Grobkonzept dargestellten Umsetzung der jeweiligen funktionalen Leistungen. Die Punktzahl je Unterkriterium wird mit der zugehörigen Gewichtung multipliziert; die Summe der gewichteten Einzelpunktzahlen ergibt die Gesamtpunktzahl für das Kriterium „Grobkonzept".

Für jedes Unterkriterium gilt folgender Bewertungsmaßstab:

[Seite 7]

• 0-2 Punkte: Die Angaben, Erklärungen oder Beschreibungen sind unkonkret, in sich nicht schlüssig oder lassen keine fachlich fundierte Umsetzung erkennen. Eine erfolgreiche Leistungserbringung ist nicht zu erwarten bzw. erscheint zweifelhaft.

• 3-4 Punkte: Die Angaben, Erklärungen oder Beschreibungen sind teilweise unvollständig, in Teilen nicht nachvollziehbar oder lassen nur eine eingeschränkte fachliche Qualität der geplanten Umsetzung erkennen. Eine erfolgreiche Leistungserbringung ist nur bedingt zu erwarten bzw. erscheint zweifelhaft.

• 5-6 Punkte: Die Angaben, Erklärungen oder Beschreibungen sind ausführlich, grundsätzlich nachvollziehbar und lassen eine fachlich schlüssige Umsetzung erkennen. Eine erfolgreiche Leistungserbringung erscheint gewährleistet.

• 7-8 Punkt: Die Angaben, Erklärungen oder Beschreibungen sind vollständig, in den überwiegenden Punkten nachvollziehbar und lassen eine fachlich fundierte und schlüssige Umsetzung erkennen. Sie lassen einen guten Erfolg der Leistungserbringung erwarten.

• 9-10 Punkte: Die Angaben, Erklärungen oder Beschreibungen sind vollständig, in allen Punkten nachvollziehbar und lassen eine fachlich besonders fundierte, schlüssige und durchdachte Umsetzung erkennen. Sie lassen einen sehr guten Erfolg der Leistungserbringung erwarten.

Optionaler Verhandlungstermin:

Nach Auswertung der schriftlichen Angebote entscheidet das Bewertungsgremium über die Notwendigkeit einer persönlichen Vorstellung der Angebotsinhalte (Präsentationstermin). In diesem Falle erhalten die Bieter eine Einladung zu einem Online-Vorstellungstermin. Die Einladung zum evtl. Präsentationstermin erfolgt digital mit einem Vorlauf von mind. 10 Kalendertagen. Im Rahmen eines max. 30-minütigen Vortrag ist folgendes zu präsentieren:

• Unternehmensvorstellung (fließt nicht in die Wertung ein)

• Darstellung des Grobkonzepts (Mindestanforderungen und optionale Leistungen) Anschließend folgen Gespräch und Diskussion (ca. 30 min.) mit dem aus Vertreterinnen der AG bestehenden Auswahlgremium. Nach dem Präsentationstermin entscheidet das Auswahlgremium, ob den Bieterinnen die Möglichkeit eingeräumt wird, ein überarbeitetes (finales) Angebot innerhalb von 7 Werktagen abzugeben. Bewertet wird nicht die Präsentation gesondert, sondern das ggf. im Nachgang der Verhandlung überarbeitete Angebot anhand der o.g. Kriterien.

Zuschlag: Der AG behält sich vor, den Zuschlag auf Grundlage der Erstangebote zu erteilen, ohne zuvor in Verhandlungen einzutreten. Ein Anspruch der Bieter auf eine Verhandlungsrunde besteht nicht. Den Zuschlag erhält die/der Bieter*in mit der höchsten gewichteten Gesamtpunktzahl. Bei Punktgleichheit entscheidet das Los.

6 Abnahme / Nachweis der Leistungserbringung Die Leistung gilt als erbracht, wenn mindestens folgende Nachweise vorliegen: • Bereitstellung der Simulationssoftware (Baustein A) sowie des Prognosetools (Baustein B) • Vorlage einer technischen und fachlichen Dokumentation, • Demonstration der wesentlichen Funktionen, • Durchführung einer Ergebnispräsentation gegenüber dem AG.