3626S62540_IT-Erstellungsschein.pdf

[Seite 1]

Erstellungsschein zum Vorhaben:

1. Vertragsgegenstand

1.1 Erstellungsleistungen

Vereinbart wird:

das Erstellen der Programme mit DV-technischen Feinkonzept, Programmierung, Dokumentation sowie das Herbeiführen der Betriebsbereitschaft der Programme.

das Erstellen des DV-technischen Feinkonzepts einschließlich Dokumentation.

die Programmierung sowie das Herbeiführen der Betriebsbereitschaft der Programme einschließlich Erstellen der Dokumentation.

1.2. Andere vereinbarte Leistungen

Abschlusspräsentation für ein breiteres Publikum

2. Darstellung des Verfahrens (Auflistung aller im Sinne der Definition des fachlichen Feinkonzeptes relevanten Dokumente)

Das Verfahren gliedert sich in drei Phasen:

1. Methoden-Evaluation (AP 1): Auswahl geeigneter KI-Verfahren zur räumlich-zeitlichen Interpolation von anisotropen ODL-Punktmessdaten mit starken Gradienten (Wolkendurchzug)

2. KI-ODL-Interpolationsroutine (AP 2): Implementierung einer lauffähigen Docker-basierten Routine, die stationäre und mobile ODL-Messdaten inklusive Hintergrundkorrektur und Prior- Informationen (RODOS-Ausbreitungsrechnung) auf ein zeitlich-räumliches Gitter interpoliert.

3. Multimodales KI-Modell „Dosisrekonstruktion 2.0“ (AP 3): Erweiterung der Routine/Entwicklung eines Prototyps "Dosisrekonstruktion 2.0" unter Berücksichtigung nuklidspezifischer Daten (Boden-/Luftaktivität) und Niederschlagsradar-Daten, physikalische Prozesse (radioaktiver Zerfall, Nuklidvektor-Interpolation) angelehnt an physikalische Prozesse und Berechnungen des bestehenden, vom BfS programmierten RODOS-Modul "Dosisrekonstruktion"

Relevante Dokumente: Leistungsbeschreibung des Forschungsvorhabens Dokumentation und Quellcode des bestehenden RODOS-Moduls "Dosisrekonstruktion" als fachliche Vorgabe

Seite 1 von 9

[Seite 2]

3. Systemumgebung: (Definition der Systemumgebung des Auftraggebers unter der das Programm betrieben werden soll)

Betriebssystem: Oracle Linux 8 mit Unbreakable Enterprise Kernel (UEK, basierend auf Linux 5.15 LTS) Architektur: x86_64 (64 Bit). Prozessor: AMD EPYC 9554 (3,1 GHz / Boost 3,7 GHz). Hardware-Rahmen: NUMA-Topologie (8 NUMA-Nodes mit jeweils 16 CPU-Kernen)Bitt Laufzeitumgebung: Docker-Container (Container-First Ansatz).

4. Anforderungen an die Programme

4.1 Fachliche Spezifikationen

4.1.1 Funktionale Spezifikationen

4.1.1.1 Informationsbedarf (z. B. Umfang, Zeitpunkt, Ort, Prioritäten)

Umfang/Datenbasis: Bereitstellung mehrerer simulierter Übungsdatensätze durch die Auftraggeberin: Dies umfasst RODOS-Ausbreitungsrechnungen, ODL-Messdaten (stationäre Sonden im 10-Minuten-Takt sowie mobile Messfahrten/Hubschrauber), nuklidspezifische Boden- /Luftaktivitätsmessungen, DWD-Regenradar-Datensätze sowie physikalische Parameterbanken (Halbwertszeiten, Depositionsgeschwindigkeiten, Koeffizienten). Als fachliche Grundlage dienen die Dokumentation und der Quellcode des bestehenden DosRek-Moduls. Zeitpunkt der Bereitstellung: Projektbegleitende Übermittlung der Datensätze in den Phasen AP 1 bis AP 3 Priorität: Höchste Priorität liegt auf der möglichst exakten zeitlich-räumlichen Interpolation während der „Wolkendurchzugsphase“, da Strahlenexpositionen hier dynamisch und gradientenhaft über kurze Distanzen/Intervalle variieren. Darüber hinaus unterliegt das Vorhaben einer hohen strategischen Priorität für die langfristige Modernisierung des bestehenden RODOS-Moduls Dosisrekonstruktion.

4.1.1.2 Informationsbasis (z. B. logische Struktur, Mengengerüst, Verknüpfungen)

Logische Struktur: Eingangsdaten liegen als unregelmäßig verteilte, anisotope Punktmessungen vor (ODL stationär im 10-Minuten-Raster, mobile Messfahrten als diskrete Raumzeitpunkte) sowie RODOS-Ausbreitungsrechnungen und Hintergrundstrahlungsprofile im CSV-Format. Die Interpolation und Modellierung erfolgt auf einem Rechengitter (x,y,t). Das finale Ausgabeformat ist NetCDF (Network Common Data Form). Mengengerüst: Verarbeitung typischer Notfallradien zunächst von ~200 km (ca. 400 × 400 km Gitterfeld). Eingabe: ~1800 stationäre Sonden-Standorte mit kontinuierlichen Zeitreihen, dazu mobile Einzelmessungen (Hubschrauber/Fahrzeuge) sowie Prioren aus RODOS-Szenarien der Auftraggeberin. Ausgabe: ODL-Interpolationsgitter (x,y,t) inkl. separater Ausgabedatei für die reine Wolkendurchzugsphase in AP 2, bzw. nuklidspezifische Werte für Bodenkontamination und Luftaktivität (x,y,t,n) in AP 3 mit frei wählbarer Gitterzellengröße und Zeitintervallen (Standard 1 km / 1 h). Verknüpfungen: Das KI-Modell soll alle verfügbaren Daten-Informationen wie ODL-Messungen, RODOS-Prioren oder physikalische Prozesse verknüpfen, um zunächst eine optimierte ODL- Interpolation (AP 2) und im Anschluss eine optimierte Dosisrekonstruktion (AP 3) zu berechnen. Das Ausgabeformat für die Datenbereitstellung ist NetCDF, bereitgestellt als Docker-Container- fähige Schnittstelle für Oracle Linux. Statische Daten sind direkt ins Image einzubauen. Dynamische Daten sind über Volumes bereitzustellen.

Seite 2 von 9

[Seite 3]

4.1.1.3 Informationsfluss (z. B. Quellen, Ziele, Verzweigungen)

Quellen: ODL-Messdaten (stationäre Sonden im 10-Minuten-Takt, mobile Fahr- bzw. Flugspuren), RODOS-Ausbreitungsrechnungen als Prior (CSV), Hintergrundstrahlungsprofile, nuklidspezifische Boden-/Luftaktivitätsmessungen sowie DWD-Regenradar-Datensätze, weitere Tabellen (Halbwertszeiten, Dosiskoeffizienten etc.) Ziele: Primäres Ausgabeziel ist die Weitergabe als NetCDF-Gitterdatei entweder mit ODL- Interpolations-Werten (AP 2) oder mit nuklidspezifischen Werten für Bodenkontamination und Luftaktivität (x,y,t,n) an das nachgelagerte RODOS-Modul „FDMT“ zur eigentlichen Dosisberechnung (AP 3) Verzweigungen: Die Verarbeitung der Eingangsdaten verzweigt sich auf zwei NetCDF- Ausgabekanäle: Ein vollständiges räumlich-zeitliches ODL-Interpolationsgitter (x,y,t) sowie eine separate Datei für Zeitschritte des Wolkendurchzugs. Für das multimodale 'Dosisrekonstruktions- Modell 2.0' erfolgt die finale Ausgabe als Gitternetz mit nuklidspezifischen Bodenkontaminations- und Luftaktivitätswerten.

4.1.1.4 Verarbeitungsregeln (z. B. für Buchungen, Steuerung, technisch-wissenschaftliche Berechnungen; Darstellung nach Möglichkeit formal, z. B. durch Formeln, Algorithmen, Entscheidungstabellen)

Technisch-wissenschaftliche Berechnungen: In AP 2 erfolgt die zeitlich-räumliche ODL- Interpolation mittels einer adäquaten Methode des maschinellen Lernens, sowohl unter Einbindung von Prior-Informationen (RODOS-Ausbreitungsrechnungen) als auch rein messdatenbasiert ohne Prior. Im Anschluss wird in AP 3 das multimodale Dosisrekonstruktions-Modell ('Dosisrekonstruktion 2.0') berechnet, das nuklidspezifische physikalische Zerfallsprozesse berücksichtigt, sowie weitere Berechnungsregeln wie z.B. die Erweiterung des Nuklidvektors um vermutlich vorhandene, aber nicht gemessene Nuklide. Hierzu sollen die Berechnungsprozesse des bestehenden RODOS-Moduls Dosisrekonstruktion als Grundlage verwendet werden.

4.1.1.5 Schnittstellen Bearbeiter / Programme (z. B. Strukturen und Inhalte von Bildschirm- und Listendarstellungen, Funktionstastenverwendung)

Da es sich bei der zu entwickelnden Software um ein wissenschaftliches Software-Modul handelt, gibt es keine grafische Benutzeroberfläche oder Tastenbefehle wie bei einer Desktop-Applikation. Die Schnittstellen konzentrieren sich daher auf Konfiguration (z.B. Gitterauflösung), Logging und Dateiaustausch (Input als Dateien innerhalb eines gemounteten Docker-Volumes, Output als NetCDF). Schnittstelle zur Docker-Umgebung: Die TLS-Terminierung erfolgt im Regelfall über einen vorgelagerten Reverse-Proxy (z.B. Traefik), der die Container lokal per HTTP anspricht; wenn möglich, werden keine Ports direkt auf den Containern geöffnet, sondern der Zugriff findet per HTTPS über den Proxy statt. Mehr Informationen siehe Leistungsbeschreibung.

4.1.1.6 Sonstige funktionale Spezifikationen

4.1.2 Qualitätsmerkmale

4.1.2.1 Zuverlässigkeit (z. B. Robustheit, Datensicherheit)

Seite 3 von 9

[Seite 4]

Das System muss robust gegenüber unvollständigen Eingangsdaten operieren und plausibel interpolieren, ohne abzustürzen. Jeder Container führt autonom sinnvolle Healthchecks durch, um die Prozessaktivität während des Betriebs zu überwachen. Fehlermeldungen und Statusinformationen werden auf die Standardausgabe (stdout) des Containers ausgegeben, um eine schnelle Diagnose von Ausfällen zu ermöglichen. Die Berechnungsergebnisse müssen physikalisch widerspruchsfrei sein. Das System ist so zu konfigurieren und zu validieren, dass bei der Interpolation von Messdaten mit starken Gradienten (ODL-Werte während des Wolkendurchzugs) kein "Überschießen" (Ausreißer über realistische Grenzen hinaus) stattfindet

4.1.2.2 Benutzungsfreundlichkeit (z. B. Benutzerführung, Unterstützungsfunktionen, Ergonomie)

Die Bedienungsfreundlichkeit des headless-Containers wird durch eine intuitive Konfiguration über Environment-Variablen und eine vorbereitete docker-compose.yml mit sinnvollen Standardwerten sichergestellt. Diagnosefunktionen wie integrierte Healthchecks sowie eine lückenlose Protokollierung auf der Standardausgabe (stdout) ermöglichen dem Betreiber eine schnelle Fehlersuche. Zu jedem Docker-Image muss zudem eine README-Datei mit relevanten Informationen erstellt werden.

4.1.2.3 Zeitverhalten (z. B. Antwort-, Reaktionszeiten, Durchsätze; diese Angaben erfordern die präzise Beschreibung der auszuführenden Funktionen und der jeweiligen vorausgesetzten Randbedingungen wie Hardware-Konfiguration, Systemsoftware, sonstige Programmumgebung, Auslasten von Zentraleinheiten und Kanälen, Datenvolumen)

Das Zeitverhalten der Software muss für einen operativen Einsatz im RLZ gewährleistet sein. Die Berechnungen erfolgen auf einer Architektur mit Oracle Linux 8 (x86_64) und AMD EPYC 9554 Prozessoren in einer NUMA-Topologie (8 Nodes mit je 16 CPU-Kernen). Das System ist innerhalb eines Docker-Containers so zu implementieren, dass es auf den CPU-Kernen einer einzelnen NUMA-Node hochparallel und skalierungseffizient läuft. Die Implementierung muss NUMA-aware sein, insbesondere durch gezielte CPU-Affinität, NUMA-lokale Speicherallokation und Vermeidung unnötiger Speicherzugriffe über NUMA-Grenzen hinweg. Falls eine effektive Parallelisierung unter Docker nicht ausreicht, muss die Anwendung ohne funktionale Änderungen auch nativ unter expliziter CPU-Bindung lauffähig sein, um im Bedarfsfall angemessene Rechenzeiten für die zeitkritischen ODL-Interpolationen im Notfallschutz zu gewährleisten.

4.1.2.4 Pflegefreundlichkeit (Angaben zum zu erwartenden Pflegebedarf: z. B. Änderungsart, -umfang, häufigkeit, Zeitrahmen für Einarbeitung und Durchführung)

Der Wartungsaufwand wird durch den „Container-First“-Ansatz minimal gehalten. Da statische Programmkomponenten direkt ins Image eingebaut werden und dynamische Konfigurationen über Volumes laufen, lassen sich Updates isoliert im Build-Prozess testen und rollback-sicher bereitstellen. Für eine reibungslose und nachhaltige interne Weiterentwicklung nach Programmübergabe durch den Auftragnehmenden ist eine umfassende Dokumentation verbindlicher Vertragsbestandteil. Dies umfasst eine umfangreiche und nachvollziehbare Code-Dokumentation, sowohl im Quellcode selbst als auch in Berichtform, unter Einhaltung der gängigen Qualitätsstandards der DFG zur guten wissenschaftlichen Praxis. Der Quelltext ist in einem für die gewählte Programmiersprache anerkannten Stil zu erstellen und muss übersichtlich sowie nachvollziehbar sein.

4.1.2.5 Portabilität (Angabe der DV-Anlagen und Grundsoftware, mit denen die Programme zusammenwirken können)

Seite 4 von 9

[Seite 5]

Das Programm läuft unter dem Betriebssystem Oracle Linux 8 (UEK) auf x86_64-Hardware (AMD EPYC Prozessor). Es ist primär als Docker-Container konzipiert, muss jedoch technologisch so portabel sein, dass es auch ohne funktionale Änderungen direkt als native Applikation unter Oracle Linux lauffähig ist.

4.1.2.6 Sonstige Qualitätsmerkmale

Die zu erstellende Software ist als Open Source Software unter der X11-Lizenz bereitzustellen. Die Entwicklung muss die gängigen wissenschaftlichen Qualitätsstandards in Anlehnung an die Empfehlungen der Deutschen Forschungsgemeinschaft (DFG) zur guten wissenschaftlichen Praxis erfüllen.

4.2 Technische Spezifikationen

4.2.1 Programmtechnische Vorgaben (z. B. Programmiersprachen, -techniken, -richtlinien, Fachnormen)

Sprache: Favorisiert wird die Programmiersprache Python. Der Quelltext ist in einem anerkannten Programmierstil zu erstellen und muss übersichtlich sowie nachvollziehbar dokumentiert sein, sowohl in der Kurzform direkt im Programmcode als auch in Berichtform. Docker & Container-Spezifikationen: Die Anwendung ist nach dem „Container-First“-Ansatz umzusetzen, eine effektive Parallelisierung und NUMA-Freundlichkeit wird vorausgesetzt. Konkretisierte Anforderungen siehe Leistungsbeschreibung Punkt 4.1. Lizenzierung & Versionierung: Die erstellte Software ist als Open Source Software unter der X11- Lizenz bereitzustellen. Der Programmcode und alle relevanten Eingabe-/Ausgabedaten werden elektronisch über GIT bereitgestellt. Dokumentationsstandards: siehe Punkt 4.3

4.2.2 Vorgaben aufgrund der Hardware und Software-Umgebung (z. B. verfügbare Hardware-Konfiguration, Ablauf- und Datenschnittstellen zu anderen Programmen)

Hardware: Das System wird auf Oracle Linux 8 (mit Unbreakable Enterprise Kernel, UEK) in einer x86_64-Architektur auf AMD EPYC Prozessoren (9554, 3,1 GHz / Boost bis 3,7 GHz) betrieben. Die Zielhardware verfügt über eine NUMA-Topologie mit 8 NUMA-Nodes zu je 16 CPU-Kernen. Das Programm muss innerhalb eines Containers eine effiziente Parallelisierung auf den CPU- Kernen einer einzelnen NUMA-Node ermöglichen und dabei NUMA-aware implementiert sein.

Software-Umgebung: Container-first-Ansatz: Die primäre Laufzeitumgebung ist Docker. Die Anwendung muss vollständig in einem Docker-Container lauffähig sein. Konfigurationen erfolgen ausschließlich über Environment-Variablen und eine mitgelieferte docker-compose.yml zur Definition und Verwaltung. Zudem ist ein nativer Fallback zwingend erforderlich: Falls eine effektive Parallelisierung unter Docker nicht ausreicht, muss die Anwendung ohne funktionale Änderungen direkt auf dem Zielsystem lauffähig sein

Schnittstellenkonfiguration: Die TLS-Terminierung erfolgt im Regelfall in einem vorgelagerten Reverse-Proxy (z. B. Traefik), nicht im Container selbst. Die Kommunikation zwischen Proxy und Container erfolgt lokal per HTTP. Direkt geöffnete Container-Ports werden, wenn möglich, vermieden. Jeder Container muss einen integrierten Healthcheck zur Prozessüberwachung enthalten; das Logging darf ausschließlich auf die Standardausgabe (stdout) des Containers erfolgen.

4.3 Anforderungen an die Dokumentation (Programmentwicklungsdokumentation z. B. nach DIN 66 231, Programmdokumentation z. B. nach DIN 66 230, Richtlinien des Auftraggebers)

Seite 5 von 9

[Seite 6]

Für das FV gelten die Normen DIN 66 231 (Feinkonzept) und DIN 66 230 (Programmdokumentation). Zudem sind die gängigen Qualitätsstandards für wissenschaftliches Arbeiten gemäß den Empfehlungen der Deutschen Forschungsgemeinschaft (DFG) zur guten wissenschaftlichen Praxis einzuhalten Die Dokumentation der Software muss auf zwei Ebenen erfolgen. Einerseits eine Berichtsdokumentation, in dem alle Bearbeitungsschritte präzisiert sind, und andererseits als Code- Dokumentation: Eine übersichtliche und nachvollziehbare Dokumentation, die direkt im Programmcode integriert ist. Es muss außerdem zu jedem Docker-Image eine eigenständige README mit relevanten Informationen bereitgestellt werden. Formalitäten für Berichte: Sämtliche Berichte sind digital, durchsuchbar und in barrierefreier Form nach dem Standard DIN ISO 14289 – PDF/UA sowie in gendergerechter Schreibweise zu erstellen. Grafiken und Fotos sind honorarfrei zur Veröffentlichung zu stellen.

4.4 Unverzichtbare Leistungsmerkmale (Hier sind diejenigen Angaben aus den Ziffern 3.1 und 3.2 zu benennen, die für den Auftraggeber unverzichtbare Leistungsmerkmale sind)

Sämtliche in der Leistungsbeschreibung genannten Anforderungen sind verbindlich und gelten gleichermaßen als unverzichtbare Leistungsmerkmale des Vorhabens. Die nachfolgende Auflistung stellt lediglich exemplarische Schwerpunkte dar. • Kernfunktion: KI-basierte räumlich-zeitliche Interpolation der ODL mit der Möglichkeit einer Prior-Einbindung (AP 2) sowie prototypische Entwicklung eines multimodalen „Dosisrekonstruktions-Modells 2.0“ (AP 3). • Systemarchitektur: Die Software muss unter den 4.2.2 genannten Bedingungen entwickelt werden. • Docker-Ready: Die Anwendung muss vollständig in einem Docker-Container lauffähig sein und für den Containerbetrieb optimiert werden. Ein Native Fallback muss verfügbar sein. Anforderungen an Dockerumgebung siehe auch Leistungsbeschreibung Punkt 4.1. • Output: NetCDF-Ausgabe im Format für ODL-Interpolation (AP 2) bzw. nuklidspezifischer Bodenkontamination und Luftaktivität (inkl. obligater Reduktionsoption auf maximal 48 Zeitschritte) (AP 3). • Lizenzierung und Dokumentation: Lieferung der Software als Open Source unter X11-Lizenz. Lückenlose Dokumentation gemäß DIN 66 231/230 und DFG-Standards zur guten wissenschaftlichen Praxis.

5 Anlagen, Geräte und Programme, die der Auftragnehmer zu liefern hat

Quellcode: Elektronische Bereitstellung aller Programmcodes (Interpolationsroutine nach AP 2 sowie „Dosisrekonstruktion 2.0“ nach AP 3) über ein GIT-Repository und der Open-Source-Lizenz X11, die eine lizenzgebührenfreie Nutzung, Veränderung und Weitergabe erlaubt.

Docker-Container: Fertige Docker-Images (nach Best Practices), inkl. aller benötigten Dockerfiles und einer docker-compose.yml zur Container-Definition und -Verwaltung

Dokumentation: Lückenlose Dokumentation direkt im Programmcode sowie als Bericht, sowie Docker-Images-READMEs. Außerdem sind nach Abschluss jedes Arbeitspakets Zwischenberichte zu erstellen, sowie ein Schlussbericht, der sämtliche Zwischenergebnisse und Berichte zusammenfasst.

6. Fachliche Qualifikation der bei der Vertragserfüllung einzusetzenden Arbeitnehmer

Seite 6 von 9

[Seite 7]

(Qualifikation - z. B. Projektleiter, Systemprogrammierer; Anzahl der Arbeitnehmer je Qualifikationsstufe, Erfahrungen)

Die Auftragnehmenden müssen Personal mit der für die Bearbeitung der Aufgabenstellung erforderlichen Erfahrung (insbesondere Erfahrung in der Entwicklung von Verfahren des maschinellen Lernens) einsetzen. Das Personal muss Erfahrung in der Programmierung im Bereich künstlicher Intelligenz/maschinellem Lernen in einem wissenschaftlichen Umfeld besitzen. Die projektspezifischen Funktionen, Qualifikationen und Erfahrungen der vorgesehenen Arbeitskräfte sind durch den Auftragnehmer im Angebot detailliert auszuweisen (siehe auch Formblatt_Fachkräfte).

7. Ansprechstelle beim Auftragnehmer und Auftraggeber

Ansprechstelle beim Auftraggeber (Namen, Anschrift, Telefon, Vertreter) Benannte Fachbegleitung Ansprechstelle beim Auftragnehmer (Namen, Anschrift, Telefon, Vertreter)

8 Arbeitsbeginn, Übergabe, Herbeiführen der Funktionsfähigkeit

8.1 Fristen, Termine

Der Arbeitsbeginn erfolgt mit Auftragserteilung. Die Gesamtlaufzeit beträgt 24 Monate. Spätestens alle drei Monate sind Projektgespräche zwischen Auftraggeberin und Auftragnehmenden vorzusehen (Form: Präsenz oder Videokonferenz), in denen Arbeitsstände, Zwischenergebnisse und benötigte Abstimmungen dargestellt werden. Mit Ablauf der 24-monatigen Laufzeit erfolgen die finale Funktionsprüfung, Vertragsabnahme und umfassende Übergabe aller vereinbarten Leistungen.

9 Mitwirkung des Auftraggebers Einsatzvoraussetzungen für das Herbeiführen der Funktionsfähigkeit (§ 4 Nr. 2 Abs. 1 Satz 2) (z. B. Bereitstellung von Personal, Mindestanforderungen an Anlagen, Geräte, Programme, benötigte Speicherkapazitäten und Rechenzeiten - Fristen bzw. Termine)

Daten- und Dokumentationsbereitstellung: Die Auftraggeberin stellt sämtliche für Entwicklung, Test und Validierung erforderlichen Datensätze in elektronischer Form bereit. Dies umfasst simulierte Übungsdatensätze (RODOS-Ausbreitungsrechnungen als Prior/Wahrheit, ODL- Hintergrundstrahlung, nuklidspezifische Boden-/Luftaktivität, DWD-Regen-Daten sowie Tabellen zu Halbwertszeiten und Dosisleistungskoeffizienten) . Zudem werden die Dokumentation und der Programmcode des bestehenden RODOS-Moduls „Dosisrekonstruktion“ zur fachlichen Einarbeitung bereitgestellt

Projektsteuerung Mindestens alle drei Monate sind projektbegleitende Gespräche zwischen Auftragnehmer und Auftraggeberin vorzusehen (Präsenz oder Videokonferenz). Nach Abschluss von AP 2 ist seitens des Auftragnehmenden ein formloser schriftlicher Antrag zur Freigabe der Mittel durch die Auftraggeberin für AP 3 zu stellen.

Die finale Funktionsprüfung durch die Auftraggeberin erfolgt direkt auf den bestehenden RODOS- Servern des BfS (RLZ). Es ist keine Installation neuer Infrastruktur, Betriebssysteme oder Softwarekomponenten erforderlich. Die finale Abnahme umfasst die Entgegennahme und Prüfung des Quellcodes, sämtlicher Docker-Container und aller Berichtsdokumentationen.

10 Abnahme

Seite 7 von 9

[Seite 8]

10.1 Art, Umfang und Dauer der Funktionsprüfung der Programme bzw. in sich abgeschlossener Teil der Programme

Dauer der Funktionsprüfungszeit (abweichend von der 30tägigen Frist nach Ziffer 12.3 Satz 1 EVB-IT System-AGB) Dauer der Funktionsprüfungszeit für teilabzunehmende Leistungen (abweichend von der 14tägigen Frist nach Ziffer 12.3 Satz 2 EVB-IT System-AGB) Ort der Funktionsprüfung (abweichend von Ziffer 12.4 EVB-IT System-AGB) Ort der Funktionsprüfung für teilabzunehmende Leistungen (abweichend von Ziffer 12.4 EVB-IT System-AGB) abweichend von Ziffer 12.6 EVB-IT-System-AGB beträgt der Zeitrahmen für erneute Funktionsprüfungen statt 14 Tage jeweils Die Durchführung der Funktionsprüfung erfolgt abweichend von Ziffer 12.4 EVB-IT System- AGB nicht in der Nummer 3 genannten, sondern in folgender Systemumgebung

11 Gewährleistung

11.1 Dauer der Gewährleistung

Es gilt Ziffer 13.3 EVB-IT System-AGB mit der Maßgabe, dass für Sachmängel und Rechtsmängel, die nicht Rechtsmängel der Individualsoftware sind, die Verjährungsfrist statt 24 Monate 0 Monate beträgt. Es gilt Ziffer 13.3 EVB-IT System-AGB mit der Maßgabe, dass für Rechtsmängel der Individualsoftware die Verjährungsfrist statt 36 Monate 0 Monate beträgt. Es gilt Ziffer 13.3 EVB-IT System-AGB mit der Maßgabe, dass die für Rechtsmängel an Individualsoftware vereinbarte Verjährungsfrist für Rechtsmängel an folgenden vereinbarten Systemkomponenten gibt.

11.2 Die Mängelmeldungen sind zu richten an a) während der normalen Geschäftszeit des Auftragnehmers

entfällt

Begründung für das Entfallen der Gewährleistung: Nach erfolgter Überprüfung und Abnahme der Software durch die Auftraggeberin ist vorgesehen, dass die Software durch die Auftraggeberin eigenständig weiterentwickelt, angepasst und verändert wird. Die Verantwortung für diese nachträglichen Änderungen liegt damit außerhalb des Verantwortungsbereichs des Auftragnehmenden. Eine Gewährleistung, die sich auf einen nach der Abnahme eigenständig veränderten Softwarestand erstreckt, wäre daher weder sachgerecht noch eindeutig abgrenzbar. Mit Abschluss des Projekts übergibt der Auftragnehmende einen funktionsfähigen und vertragsgemäßen Softwarestand einschließlich der erforderlichen Dokumentation. Durch die anschließende Abnahme und Überprüfung durch die Auftraggeberin wird bestätigt, dass das vereinbarte Entwicklungsziel erreicht und der vereinbarte Leistungsumfang erfüllt wurde. Eine über die Abnahme hinausgehende Gewährleistungsverpflichtung würde beim Auftragnehmenden eine entsprechende personelle Vorhaltung und entsprechende Rückhaltung von Projektmitteln erfordern, was insbesondere bei befristet beschäftigtem Projektpersonal nicht gewährleistet werden kann und somit einem Projektabschluss entgegenstehen würde.

Vor diesem Hintergrund wird nach erfolgter Abnahme keine über den Zeitpunkt der Abnahme hinausgehende Gewährleistungsfrist vorgesehen.

b) außerhalb der normalen Geschäftszeit des Auftragnehmers

Seite 8 von 9

[Seite 9]

entfällt, siehe 11.2.a

11.3 Unterlagen für die Mängelbeseitigung

Werden Mängel geltend gemacht, müssen folgende Unterlagen zur Einsichtnahme oder Anforderung zur Verfügung stehen:

Mängelbeschreibung Konsolprotokoll Programmdokumentation Generierungs- und Umwandlungsliste ggf. Ein- Ausgabedaten ggf. Zwischenergebnisse Hauptspeicherauszug Quantifizierung unter Angabe der Einsatzbedingungen Programmdokumentation der beeinflussten Programme

11.4 Umfang der Unterstützung durch den Auftraggeber

entfällt, siehe 11.2.a

11.5 Reaktions- und Wiederherstellungszeiten

Für die Zeit bis zur Verjährung der Mängelansprüche (Gewährleistungsfrist) werden folgende Reaktions- und Wiederherstellungszeiten vereinbart:

Reaktions- und Wiederherstellungszeiten beginnen ausschließlich mit dem Zugang der Mängelmeldung während der Servicezeiten nach Ziffer 4.1.2 EVB-IT System-AGB und laufen ausschließlich während der Servicezeiten.

Seite 9 von 9