[Seite 1]
| VORLÄUFIGE VERSION | |||
|---|---|---|---|
| PROJEKT | Einführung eines ID-basierten Ticketings - Bargeld- und papierloser ÖPNV im Verbundgebiet des Verkehrsverbundes Mittelschwaben (VVMBestPreis) | ||
| LASTENHEFT | VERSION 0.2 | Stand: 21.12.2025 | |
| AUFTRAGGEBER | VVM Verkehrsverbund Mittelschwaben GmbH Hans-Lingl-Str. 1 86381 Krumbach | ||
| VERGABENUMMER | 26.001.31 | ||
| BIETER | Unternehmensname/ Anschrift/ Unterschrift |
[Seite 3]
| ANMERKUNGEN ZUM LASTENHEFT Der AG verwendet das vorliegende Schema zur Sicherstellung, dass die angebotende ID-basierte Ticketinglösung den Anforderungen entspricht. Aus diesem Grund ist dieses Dokument komplett auszufüllen. Eigene abweichende Beschreibungen haben, wenn nicht explizit gefordert, nur ergänzenden Charakter. Tabellenstruktur des Anforderungskataloges: | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DATENFELD | # | TEILLASTENHEFT | KATEGORIE | SUB-KATEGORIE | ID | BESCHREIBUNG ANFORDERUNG | TYP ANFORDERUNG | HINWEIS | MAX. PUNKTZAHL | SELBSTEINSCHÄTZUNG | BEMERKUNG | |
| BESCHREIBUNG | Nr. des Teillastenhefts | Name des Teillastenhefts | Kategorien im jeweiligen Teillastenheft | Sub-Kategorie in der jeweiligen Kategorie | Spezifische ID-Nr. pro Anfordung. Beschreibungen zu Informationszwecken sind mit "I" markiert und stellen keine zu bewertene Anforderung dar.* | Beschreibung der Anforderung** | Unterscheidung in M = Mindestanforderung N = Nachweis (Darlegung in separatem Nachweis) I = Information (zusätzliche Information/Kontext) | Zusätzliche Hinweise für den Bieter | Maximale Punktzahl, die bei vollständiger Erfüllung erreicht werden kann | Selbsteinschätzung des Bieters. | Erläuterungen bei abweichendem Erfüllungsgrad "B" oder "C" | |
| NUMMERISCHE PUNKTZAHL | FREITEXTFELD | |||||||||||
| Anforderungen sind in unterschiedliche Typen klassifiziert: M = Mindestanforderung N = Nachweis --> Bieter muss die Anforderung in einem separaten Nachweis darlegen (eine Übersicht über alle erforderlichen Nachweise ist im Tabellenblatt "Konzepte u I = Information --> zusätzliche Informationen und Kontext, jedoch keine zu erfüllende Anforderung Selbsteinschätzung durch den Bieter: A = in vollem Umfang erfüllt B = teilweise erfüllt C = nicht erfüllt Im Rahmen der Angebotslegung wird ein vollständiges Angebot abgegeben. Hierbei wird grundsätzlich die im Folgenden aufgeführte Differenzierung (A, B, C) eingetrage Bieter durch Selbsteinschätzung fest, in welchem Umfang die beschriebenen Funktionalitäten durch das vorgelegte Angebot abgedeckt sind. * Für Anforderungen vom Typ "Soll" gilt: Abweichungen vom geforderten Erfüllungsgrad („B und C“) sind detailliert zu beschreiben. Sie werden grundsätzlich in der Spalte B Bei nicht beschriebenen Abweichungen/Alternativen behält sich der Auftraggeber eine Beurteilung als "Nicht erfüllt (C)" vor. * Anforderung vom Typ "M" sind Mindestanforderungen. Eine Abweichung („B“ oder „C“) bei einer Mindestanforderung führt zum Ausschluss aus dem Vergabeverfahren. Anforderungen vom Typ "Nachweis": Das Fehlen von Nachweisen, die im Tabellenblatt "Nachweise" wie folgt gekennzeichnet sind: "Der Nachweis wird nicht bewertet. Eine zum Ausschluss aus dem Vergabeverfahren.", führt zum Ausschluss aus dem Vergabeverfahren. Jeder Nachweis muss als separates Dokument mit einer eindeutigen Bez * Die Anforderungs-ID "##-XX-##-##" setzt sich wie folgt zusammen: "lfd. Nr. für das jeweilige Teillastenheft" - lfd. Buchstabe für die Kategorie - lfd. Nr. für Sub-Kategorie Anforderungen der gleichen Sub-Kategorie ** Zusätzliche Begriffserklärung können der Arbeitsmappe Glossar entnommen werden. | nd Nachweise" vermerkt) n. Durch diese Angabe stellt der emerkung eingetragen. Nichtabgabe des Nachweises führt eichnung eingereicht werden. - lfd Nr. für unterschiedliche |
[Seite 4]
| BEGRIFF | ERLÄUTERUNG | |
|---|---|---|
| 2D-Barcode (QR-Code) | Ein 2D-Barcode ist ein zweidimensionaler Barcode, der im Vergleich zu herkömmlichen eindimensionalen Strichcodes (z. B. EAN- oder UPC- Codes) mehr Informationen auf kleinerem Raum speichern kann. Er besteht aus einer Matrix aus kleinen Quadraten oder Punkten, die sowohl in horizontaler als auch in vertikaler Richtung Daten enthalten. | |
| 5-LAN-Port (Router) | Ein 5-LAN-Port-Router ist ein Router, der über fünf LAN-Ports (Local Area Network) verfügt. Diese Ports ermöglichen die kabelgebundene Verbindung von bis zu fünf Geräten (wie Computer, Drucker, Smart- TVs oder Netzwerk-Switches) mit dem lokalen Netzwerk und bieten eine stabile und schnelle Internetverbindung. | |
| Acquirer | Ein Acquirer ist ein Finanzinstitut oder Zahlungsdienstleister, der für die Annahme und Verarbeitung von Kartenzahlungen im Auftrag eines Händlers verantwortlich ist. Der Acquirer arbeitet mit den Kartenorganisationen (z. B. Visa, Mastercard) zusammen, um Transaktionen zu autorisieren, Zahlungen zu verarbeiten und die Gelder vom Konto des Karteninhabers auf das Konto des Händlers zu überweisen. | |
| Acquiring Service Fee (ASF) | Eine Gebühr, die ein Zahlungsabwickler (Acquirer) einem Händler, in diesem Fall dem AG, für die Verarbeitung von Kartenzahlungen in Rechnung stellt. Sie deckt Kosten für den Betrieb und die Sicherheit des Zahlungssystems ab. | |
| Aggregation | Das Zusammenführen von einzelnen Transaktionen mit dem Ziel einer zentralisierten Abrechnungen (kumulierte Abrechnung von Einzeltransaktionen), z. B. zum Tagesende für die Gewährung eines Bestpreises. | |
| Akzeptanzstelle | Eine Akzeptanzstelle ist ein Ort oder eine Plattform, an der bestimmte Zahlungsmittel, wie Kreditkarten, Debitkarten oder spezielle digitale Bezahlsysteme, für Transaktionen akzeptiert werden. Dies kann ein physisches Geschäft, ein Online-Shop oder ein Dienstleister sein, der ein bestimmtes Zahlungssystem unterstützt. Im Kontext des öffentlichen Verkehrs könnte dies auch ein Validator oder Ticketautomat sein, der kontaktlose EMV-Karten oder mobile Zahlungssysteme wie Google Pay oder Apple Pay akzeptiert. | |
| APK-Kontrolllösung (Android Package Kit) | Eine APK-Kontrolllösung bezieht sich auf eine Softwarelösung, die im öffentlichen Verkehr oder bei ähnlichen Anwendungen verwendet wird, um Android-basierte Kontrollgeräte oder Apps zu verwalten, die als APK (Android Package Kit) bereitgestellt werden. Eine APK ist das Dateiformat, mit dem Android-Anwendungen verteilt und installiert werden. | |
| Apple Pay | Apple Pay ist ein mobiler Bezahldienst von Apple, der es Nutzern ermöglicht, kontaktlose Zahlungen mit ihrem iPhone, iPad, Apple Watch oder Mac zu tätigen. Der Dienst verwendet NFC-Technologie (Near Field Communication), um Transaktionen an kontaktlosen Zahlungsterminals zu ermöglichen, ähnlich wie bei Kredit- und Debitkarten. Apple Pay ist in Geschäften, in Apps und online verfügbar. | |
| Auftraggeber (AG) | Der Auftraggeber in einem Vergabeverfahren ist die Person, Organisation oder öffentliche Institution, die einen Auftrag ausschreibt und das Vergabeverfahren durchführt, um eine Leistung, Lieferung oder Bauleistung zu vergeben. In dem vorliegenden Vergabeverfahren ist der Auftraggeber (AG) die "VVM Verkehrsverbund Mittelschwaben GmbH". | |
| Ausführungsplanung | Ausführungsplanung ist ein Synonym für Pflichtenheft. | |
| Autorisierung(-stransaktion) | Eine Autorisierungstransaktion ist der Prozess, bei dem ein Zahlungsdienstleister (z. B. eine Bank oder Kartenorganisation) überprüft, ob eine Debit- oder Kreditkartentransaktion vom Karteninhaber genehmigt werden kann. Bei dieser Transaktion wird geprüft, ob die Karte gültig ist und ob genügend Guthaben oder Kredit vorhanden ist, um die Zahlung abzudecken. | |
| Bankkarte | Eine von einem Finanzinstitut oder einer Bank herausgegebene EMV Karte. | |
| Barrierefreiheitsstärkungsgesetz | Das Barrierefreiheitsstärkungsgesetz (BFSG), das im Juli 2021 in Deutschland verabschiedet wurde, dient dazu, die Barrierefreiheit für Menschen mit Behinderungen in verschiedenen Lebensbereichen zu verbessern. Es setzt die Anforderungen der EU- Richtlinie 2019/882 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen um. | |
| Bestpreisberechnung | Bestpreisberechnung im ID-based Ticketing bezeichnet einen Tarifmechanismus, bei dem die Transaktionen ("Taps" mit EMV-Karten) eines Fahrgasts am Ende eines Tages aggregiert werden, um den günstigsten Gesamtpreis für die genutzten Fahrten zu berechnen. Statt den Fahrgast für jede Fahrt einzeln zu belasten, analysiert das System die Anzahl und Art der Fahrten und wendet automatisch den besten verfügbaren Tarif an, wie z. B. Tageshöchstgrenzen oder Rabatte für Vielfahrer. | |
| Bieter | Ein Bieter in einem Vergabeverfahren ist eine Person, ein Unternehmen oder eine Organisation, die ein Angebot einreicht, um einen öffentlichen oder privaten Auftrag zu erhalten. Bieter müssen bestimmte formale Anforderungen erfüllen, die in den Vergabeunterlagen festgelegt sind. | |
| BIN | Die Abkürzung BIN bedeutet Bank Identification Number und stellt die erste 4-6 Stellen einer Kartennummer da, die von einer Bank auf Grundlage der Vorgaben der internationalen Kartenorganisationen herausgegeben wird. Eine BIN identifiziert die Kartenherausgebende Bank bzw. das Finanzinstitut. | |
| BIN-Range | BIN-Range (Bank Identification Number Range) bezeichnet den Bereich von Bankidentifikationsnummern, die einer bestimmten Bank oder einem Kartenherausgeber zugewiesen sind. Die BIN, bestehend aus den ersten sechs Ziffern einer Kredit- oder Debitkartennummer, identifiziert das Kreditinstitut oder den Issuer der Karte. Die BIN- Range umfasst also die Serie von Kartennummern, die von dieser Bank ausgegeben werden. | |
| Blacklist (Sperrliste) | Eine Blacklist (auch als "Sperrliste" bezeichnet) ist eine Liste von Karten, Tokens oder Identifikationsmedien, die für den Zugang zu einem System oder Dienst gesperrt wurden. Im Kontext eines ID-basierten Ticketingsystems enthält die Sperrliste Fahrkarten oder EMV-Karten, die aus bestimmten Gründen (wie ungültige Zahlungen, abgelaufene Tickets oder Sicherheitsbedenken) nicht mehr akzeptiert werden. Validatoren greifen auf diese Liste zu, um zu verhindern, dass gesperrte Karten zur Validierung genutzt werden, und verweigern entsprechend den Zugang zum Verkehrssystem. Die Sperrliste wird regelmäßig aktualisiert und an alle relevanten Geräte, wie stationäre und mobile Validatoren, verteilt. | |
| Card-present Payment Gateway | Ein Card-present Payment Gateway ist eine Zahlungsplattform, die speziell für Transaktionen entwickelt wurde, bei denen die Karte physisch vorhanden ist, d. h. "card-present". Das Payment Gateway verarbeitet die Zahlung, indem es die Kartendaten sicher an den Acquirer und dann an das Kartenunternehmen weiterleitet, um die Transaktion zu autorisieren. | |
| CAT7-Kabel | Ein CAT7-Kabel ist ein Ethernet-Netzwerkkabel, das für die Übertragung von Daten in Hochgeschwindigkeitsnetzwerken ausgelegt ist. Es unterstützt Bandbreiten von bis zu 600 MHz und ermöglicht Datenübertragungsraten von bis zu 10 Gbit/s auf Entfernungen von bis zu 100 Metern. CAT7- Kabel bieten eine bessere Abschirmung gegen elektromagnetische Störungen im Vergleich zu älteren Kabelstandards wie CAT5e oder CAT6, da sie über eine zusätzliche Abschirmung für jede Adernpaarung und eine Gesamtabschirmung verfügen. | |
| CE-Norm | Die CE-Norm oder CE-Kennzeichnung ist ein Hinweis darauf, dass ein Produkt den grundlegenden Anforderungen der europäischen Richtlinien entspricht und die notwendigen Sicherheits-, Umwelt- und Gesundheitsstandards erfüllt. Die CE- Kennzeichnung ist in der Europäischen Union (EU) und dem Europäischen Wirtschaftsraum (EWR) verpflichtend für viele Produkte, die in diesen Märkten in Verkehr gebracht werden. | |
| cEMV | cEMV (Contactless Europay, Mastercard, Visa) ist ein Standard für kontaktlose Kartenzahlungen. Es ist eine Erweiterung des EMV-Standards, der ursprünglich für Chip-basierte Kartenzahlungen entwickelt wurde, und ermöglicht kontaktlose Transaktionen durch Near Field Communication (NFC). cEMV ermöglicht es Karteninhabern, ihre Kredit- oder Debitkarte einfach zu "tappen", also in die Nähe eines NFC- fähigen Zahlungsterminals zu halten, um Zahlungen zu tätigen, ohne die Karte physisch einstecken zu müssen. | |
| cEMV UPOS Terminal | Ein cEMV UPOS Terminal ist ein Point-of-Sale- Terminal (UPOS = Unified Point of Sale), das den cEMV-Standard (Contactless Europay, Mastercard, Visa) für kontaktlose Zahlungen unterstützt. Dieses Terminal ermöglicht es Händlern, kontaktlose Transaktionen durchzuführen, indem Kunden ihre cEMV-fähigen Karten oder Geräte (wie Smartphones mit digitalen Wallets) einfach am Terminal „tappen“, ohne die Karte physisch einzustecken. | |
| Check-in | Check-in im Kontext von ID-based Ticketing oder kontaktlosen Zahlungssystemen bezeichnet den Moment, in dem ein Fahrgast durch das "Tappen" einer EMV-Karte oder eines mobilen Geräts (z. B. Smartphone) an einem Validator seine Fahrt beginnt. Dieser Vorgang erfolgt, wenn der Fahrgast das Transportmittel betritt oder an einer Haltestelle einsteigt. Das "Tap" dient als Registrierung im System, dass der Fahrgast die Reise angetreten hat. | |
| Check-in/Be-out | Check-in/Be-out ist ein Ticketing-Mechanismus im öffentlichen Verkehr, bei dem der Fahrgast nur beim Einsteigen durch ein "Tap" (Check-in) an einem Validator registriert wird. Beim Be-out steigt der Fahrgast einfach aus, ohne erneut tappen zu müssen. Es erfolgt keine automatische Erkennung, dass der Fahrgast ausgestiegen ist. Der Fahrpreis wird basierend auf dem Check-in und den damit verbundenen Tariflogiken berechnet, jedoch ohne einen expliziten Check-out durch den Fahrgast. | |
| Check-in/Check-out (CiCo) | Check-in/Check-out (CiCo) ist ein Ticketing- Mechanismus im öffentlichen Verkehr, bei dem der Fahrgast sowohl beim Einsteigen als auch beim Verlassen des Transportmittels eine Aktion ausführen muss. Der Fahrgast tappt beim Einsteigen am Validator (Check-in), um die Fahrt zu registrieren, und muss beim Aussteigen erneut tappen (Check- out), um die Fahrt zu beenden. Auf Grundlage des Check-ins und Check-outs berechnet das System die zurückgelegte Strecke und den entsprechenden Fahrpreis. | |
| Check-out | Check-out im Kontext von ID-based Ticketing oder kontaktlosen Zahlungssystemen bezeichnet den Moment, in dem ein Fahrgast seine Fahrt durch das "Tappen" einer EMV-Karte oder eines mobilen Geräts (z. B. Smartphone) an einem Validator beendet. Dieser Vorgang erfolgt, wenn der Fahrgast das Transportmittel verlässt oder an einer Haltestelle aussteigt. Das "Tap" beim Check-out dient als Registrierung im System, dass der Fahrgast die Reise abgeschlossen hat. Dadurch kann das System die Fahrtstrecke und den Fahrpreis basierend auf dem Check-in und Check-out genau berechnen. | |
| Clearing-Anfrage | Eine Clearing-Anfrage ist der Prozess, bei dem Zahlungsinformationen zwischen verschiedenen beteiligten Finanzinstituten oder Parteien (wie Issuer und Acquirer) ausgetauscht werden, um Transaktionen abzuwickeln und zu verrechnen. Im Kontext des elektronischen Zahlungsverkehrs, wie beispielsweise bei Kreditkarten- oder EMV- Kartenzahlungen, wird eine Clearing-Anfrage gestellt, um die Einzelheiten einer abgeschlossenen Transaktion zu übermitteln, zu überprüfen und abzurechnen. | |
| Closed Loop | Closed Loop bezeichnet ein geschlossenes Zahlungssystem, bei dem eine spezifische Karte oder ein Token nur innerhalb eines bestimmten, begrenzten Netzwerks verwendet werden kann. Im Gegensatz zu Open Loop-Systemen, bei denen Kredit- oder Debitkarten weltweit bei verschiedenen Händlern und Diensten eingesetzt werden können, ist ein Closed Loop-System auf eine bestimmte Organisation oder Region beschränkt. | |
| Closed Loop EMV Karte | Eine Closed Loop EMV-Karte ist eine kontaktlose Chipkarte, die den EMV-Standard verwendet und nur innerhalb eines spezifischen Netzwerks oder Systems genutzt werden kann, z. B. in einem öffentlichen Verkehrssystem, einem Unternehmen oder einer begrenzten Region. Im Gegensatz zu einer Open Loop EMV-Karte (wie eine Debit- oder Kreditkarte, die global in verschiedenen Netzwerken akzeptiert wird), ist die Closed Loop EMV-Karte ausschließlich für die Nutzung in einem festgelegten System bestimmt, beispielsweise bei einem Verkehrsunternehmen oder einem Einzelhändler. | |
| Debitkarte | Eine Debitkarte ist eine Zahlungskarte, die direkt mit dem Bankkonto des Karteninhabers verknüpft ist. Wenn die Karte verwendet wird, sei es an einem Point-of-Sale (POS) Terminal oder bei Online- Transaktionen, wird der Betrag sofort vom verknüpften Konto des Karteninhabers abgebucht. Debitkarten bieten eine direkte und bequeme Möglichkeit, Zahlungen zu tätigen, ohne dass der Karteninhaber einen Kredit aufnehmen muss. | |
| Debt Recovery | Debt Recovery Transaktionen beziehen sich auf spezielle Zahlungsprozesse, bei denen versucht wird, ausstehende Beträge von einem Karteninhaber einzuziehen, wenn eine vorherige Transaktion aufgrund von unzureichender Kontodeckung oder anderen Zahlungsproblemen fehlgeschlagen ist. Diese Art von Transaktion wird typischerweise von Zahlungsdienstleistern oder Issuers initiiert, um fällige Beträge nachträglich zu erhalten. | |
| DSGVO | Die DSGVO (Datenschutz-Grundverordnung) ist eine Verordnung der Europäischen Union, die seit dem 25. Mai 2018 in Kraft ist. Sie regelt den Schutz personenbezogener Daten innerhalb der EU und stärkt die Rechte von Einzelpersonen bezüglich ihrer Daten. Die DSGVO legt fest, wie Unternehmen und Organisationen mit den persönlichen Daten von Bürgern der EU umgehen dürfen. | |
| E1 Zulassung Kraftfahrtbundesamt | Die E1-Zulassung wird vom Kraftfahrt-Bundesamt (KBA) in Deutschland erteilt und ist ein Teil des internationalen Homologationsverfahrens, das die Übereinstimmung von Fahrzeugkomponenten oder - systemen mit bestimmten technischen Vorschriften gewährleistet. Das "E1" kennzeichnet, dass die Zulassung durch die deutsche Zulassungsbehörde erfolgt ist. Diese Zulassung stellt sicher, dass ein Produkt, wie z. B. Fahrzeugteile, Sicherheitskomponenten oder Elektroniksysteme, den EU-weiten Anforderungen für den Straßenverkehr entspricht | |
| Elektromagnetische Verträglichkeit | Elektromagnetische Verträglichkeit (EMV) bezieht sich auf die Fähigkeit eines elektrischen oder elektronischen Geräts, in seiner elektromagnetischen Umgebung ordnungsgemäß zu funktionieren, ohne durch elektromagnetische Störungen (EMI) beeinträchtigt zu werden oder selbst solche Störungen zu verursachen. Das Ziel der EMV ist es, sicherzustellen, dass Geräte nicht nur untereinander kompatibel sind, sondern auch keine schädlichen elektromagnetischen Emissionen freisetzen, die andere Geräte oder Systeme beeinträchtigen könnten. | |
| EMV Chip | Der EMV-Chip (Europay, Mastercard, Visa) ist ein Sicherheitsstandard für Zahlungskarten, der die Karten mit einem kleinen Mikroprozessor-Chip ausstattet. Dieser Chip erhöht die Sicherheit von Kartenzahlungen im Vergleich zu älteren Magnetstreifen-Technologien. Der EMV-Chip verschlüsselt sensible Zahlungsinformationen und generiert für jede Transaktion einen einmaligen Code, der nur einmal verwendet werden kann, was Betrug und Missbrauch erschwert. | |
| EMV-Bankkarte (EMV- Chipkarte/EMV-Karte) | Eine EMV-Bankkarte ist eine Debit- oder Kreditkarte, die mit einem EMV-Chip (Europay, Mastercard, Visa) ausgestattet ist. Der EMV-Chip ersetzt die traditionelle Magnetstreifentechnologie und bietet ein höheres Maß an Sicherheit bei Kartenzahlungen, indem er für jede Transaktion einen einzigartigen verschlüsselten Code generiert. Diese Karten werden weltweit verwendet und ermöglichen sichere Transaktionen sowohl bei physischen als auch bei Online-Einkäufen. | |
| EMV-Zertifizierungslevel 1 | EMV-Zertifizierungslevel 1 bezieht sich auf die Zertifizierung des physischen und elektrischen Verhaltens von EMV-Chipkarten und Lesegeräten (wie Terminals) im Rahmen des EMV-Standards. Dieser Zertifizierungsprozess stellt sicher, dass die Hardware von Karten und Terminals nach den internationalen EMV-Spezifikationen korrekt funktioniert und miteinander kompatibel ist. | |
| EMV-Zertifizierungslevel 2 | EMV-Zertifizierungslevel 2 bezieht sich auf die Zertifizierung der Software und funktionalen Aspekte von EMV-Chipkarten und Terminals. Während Level 1 die Hardware-Spezifikationen prüft, konzentriert sich Level 2 darauf, sicherzustellen, dass die Software auf den Terminals die Transaktionen gemäß den EMV- Spezifikationen korrekt verarbeitet. | |
| EMV/EMVco | EMVCo ist ein globales technisches Gremium, das die weltweite Interoperabilität und Akzeptanz sicherer Zahlungstransaktionen durch die Verwaltung und Weiterentwicklung der EMV-Spezifikationen und damit verbundenen Testprozesse erleichtert. | |
| Entwertergrundplatte | Die Entwertergrundplatte ist die feste Basiskomponente, die für die Montage eines Entwerters (auch als Fahrkartenentwerter bezeichnet) in öffentlichen Verkehrssystemen genutzt wird. Sie dient als Trägerelement, das den Entwerter stabil und sicher an Fahrzeugen, Stationen oder anderen festgelegten Positionen befestigt. | |
| ERP-System | Ein Enterprise-Resource-Planning-System (ERP- System) unterstützt viele/sämtliche in einem Unternehmen ablaufenden Geschäftsprozesse, wie z. B. SAP oder Oracle. | |
| EVB-IT Systemvertrag | Der EVB-IT Systemvertrag ist ein standardisierter Vertrag, der speziell für IT-Dienstleistungen im öffentlichen Sektor in Deutschland entwickelt wurde. EVB-IT steht für "Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen". Der Systemvertrag wird verwendet, wenn es darum geht, komplexe IT-Systeme zu beschaffen, die aus verschiedenen Komponenten bestehen, wie Hardware, Software und Dienstleistungen, die gemeinsam als ein Gesamtprojekt geliefert und installiert werden sollen. | |
| Fahrpreisberechnungsmodul (Preisermittlungsservice) | Das Fahrpreisberechnungsmodul, auch bekannt als Preisermittlungsservices, ist ein zentraler Bestandteil des Vertriebshintergrundsystems, das vom Systemintegrator bereitgestellt wird. Dieses Modul berechnet den Fahrpreis basierend auf den im ID- based Ticketing implementierten Tariflogiken. | |
| Gerätekomponente | Als Gerätekomponenten werden alle Einzelteile bezeichnet, die in selbigem Gerät verbaut sind. | |
| Gerätenummer (Seriennummer) | Eine eindeutige Nummer zur Identifikation eines Produkts oder Gerätekomponenten. | |
| Gesamtlösung | Die Gesamtlösung setzt sich aus allen Anforderungen, Konzepten und Informationen aller Teillastenhefte zusammen. | |
| Google Wallet | Google Wallet ist eine digitale Geldbörse, die es Nutzern ermöglicht, ihre Kreditkarten, Debitkarten, sowie digitale Tickets, Loyalitätskarten und Geschenkkarten auf ihrem mobilen Gerät zu speichern. Die App verwendet Near Field Communication (NFC), um kontaktlose Zahlungen in Geschäften zu ermöglichen, indem der Nutzer sein Smartphone oder seine Smartwatch an ein Zahlungsterminal hält. | |
| Graphical User Interface (GUI) | Ein Graphical User Interface (GUI) ist eine grafische Benutzeroberfläche, die es Benutzern ermöglicht, mit einem Computer oder einem Gerät über visuelle Elemente wie Symbole, Schaltflächen, Fenster und Menüs zu interagieren, anstatt über reine Textbefehle (wie in einer Command Line Interface). GUIs sind heute der Standard für die Interaktion mit Betriebssystemen, Anwendungen und mobilen Geräten. | |
| Grundplatte | Die (Validator-)Grundplatte ist die feste Basiskomponente, auf der ein Validator im öffentlichen Verkehrssystem montiert wird. Sie dient als mechanische Schnittstelle zwischen dem Validator (dem Gerät, das Fahrkarten oder Tokens prüft) und der physikalischen Infrastruktur des Verkehrsmittels oder der Station, wie z. B. Bussen, Bahnen oder Stationsterminals. | |
| Härtung | (System-)Härtung (auch bekannt als Hardening) bezeichnet den Prozess, ein Computersystem, Netzwerk oder eine Software zu schützen, indem potenzielle Schwachstellen minimiert werden. Ziel der Härtung ist es, die Angriffsfläche eines Systems zu verkleinern, sodass es weniger anfällig für Cyberangriffe, Malware und andere Bedrohungen ist. | |
| Hintergrundsystem (Vertriebshintergrundsystem) | Zur zentralen Überwachung der Gerätezustände (Fehlerspeicher) und Datenbestände (u. a. Version, etc.) ist eine leicht verständliche, übersichtliche Benutzeroberfläche vorhanden. Es wird eine automatisierte Meldung bei erkannten Störungen in Echtzeit angezeigt. | |
| Host-To-Host Anbindung | Eine Host-to-Host-Anbindung ist eine direkte, elektronische Verbindung zwischen zwei Computersystemen (Hosts), die den sicheren Datenaustausch zwischen Unternehmen oder Institutionen ermöglicht. Diese Verbindung wird oft im Bank- und Zahlungsverkehr verwendet, um große Mengen von Transaktions- oder Zahlungsdaten zwischen Systemen auszutauschen, ohne einen Zwischenhändler oder eine manuelle Eingabe zu benötigen. | |
| IBIS-IP (VDV 301) | IBIS-IP steht für Integrated Board Information System - Internet Protocol und ist ein Kommunikationsstandard für den Datenaustausch in öffentlichen Verkehrsmitteln, insbesondere für Busse und Bahnen. IBIS-IP wird verwendet, um verschiedene IT-Komponenten im Fahrzeug miteinander zu vernetzen und die Kommunikation zwischen Fahrzeug und Leitstelle zu ermöglichen. | |
| IBIS Slave | Der IBIS-Slave ist eine Komponente im IBIS (Integriertes Bordinformationssystem)-Netzwerk, die untergeordnete Funktionen innerhalb des Kommunikationssystems eines Fahrzeugs übernimmt. Im öffentlichen Nahverkehr wird das IBIS- System genutzt, um verschiedene Geräte und Systeme im Fahrzeug, wie beispielsweise Fahrscheindrucker, Haltestellenanzeigen oder Türsteuerungen, miteinander zu verbinden und zu steuern. | |
| IBIS VDV 300 | IBIS VDV 300 ist ein Kommunikationsstandard, der von der VDV (Verband Deutscher Verkehrsunternehmen) entwickelt wurde, um den Datenaustausch in öffentlichen Verkehrsmitteln, insbesondere in Bussen und Bahnen, zu standardisieren. IBIS steht für Integrated Board Information System und dient der einheitlichen Kommunikation zwischen den verschiedenen technischen Systemen in Fahrzeugen und der Leitstelle. | |
| IBIS Wagenbus | Der IBIS Wagenbus ist ein Kommunikationssystem im öffentlichen Nahverkehr, das dazu dient, verschiedene Bordsysteme eines Fahrzeugs miteinander zu verbinden und zu steuern. "IBIS" steht für Integriertes Bordinformationssystem, und der Wagenbus bildet die Basis für den Datenaustausch zwischen den Fahrzeugkomponenten, wie z. B. Fahrscheindrucker, Haltestellenanzeigen, Fahrgastinformationssysteme und andere relevante Systeme. | |
| ID basiertes Ticketing (IDBT) | ID basiertes Ticketing (IDBT), bei dem die Identität des Nutzers zur Abrechnung verwendet wird. Beim ID basierten Ticketing (IDBT) ist die verschlüsselte Bankkartennummer das digitale Ticket. Es ermöglicht den Fahrgästen die papier- und bargeldlose Bezahlung im ÖPNV: Fahrten werden durch das Tappen einer Bankkarte mit EMV Chip oder eines Smartphones über die NFC-Funktion am Einstiegs- und gegebenenfalls am Ausstiegspunkt validiert. | |
| IDBT (ID basiertes Ticketing) | IDBT (ID basiertes Ticketing), bei dem die Identität des Nutzers zur Abrechnung verwendet wird. Beim ID basierten Ticketing (IDBT) ist die verschlüsselte Bankkartennummer das digitale Ticket. Es ermöglicht den Fahrgästen die papier- und bargeldlose Bezahlung im ÖPNV: Fahrten werden durch das Tappen einer Bankkarte mit EMV Chip oder eines Smartphones über die NFC-Funktion am Einstiegs- und gegebenenfalls am Ausstiegspunkt validiert. | |
| Interoperable Token- und Transitdatenbank (Token- und Transitdaten-Hub Plattform) | Der Interoperable Token- und Transitdaten-Hub ist eine zentrale, landesweite Plattform, die die ID-based Ticketing (IDBT)-Daten (wie Token- und Transitdaten) verschiedener Verkehrsunternehmen und Verkehrsverbünde speichert und verwaltet. Diese Plattform ermöglicht es Fahrgästen, nahtlos zwischen verschiedenen Verkehrsunternehmen zu wechseln, auch wenn unterschiedliche IDBT-Systemanbieter (z. B. verschiedene Transit Payment Service Provider) im Einsatz sind. Über standardisierte Schnittstellen können Verkehrsunternehmen ihre Token-Daten an die Plattform übermitteln und gleichzeitig aktuelle Informationen wie Sperr- und Akzeptanzlisten abrufen. Dies stellt sicher, dass ein einheitliches und übergreifendes IDBT-Ticketing und Kontrollieren über alle beteiligten Verkehrsunternehmen hinweg möglich ist, wodurch der Fahrgast von einem durchgängigen und interoperablen Ticketing-System profitiert. | |
| Kartenherausgeber | Ein Kartenherausgeber, auch als Issuer bezeichnet, ist eine Bank oder Finanzinstitution, die Kredit- oder Debitkarten an Verbraucher ausgibt. Der Issuer verwaltet die Konten der Karteninhaber, genehmigt Transaktionen, stellt Karten bereit und ist für das Risiko der Kreditvergabe verantwortlich. Bei jeder Transaktion überprüft der Kartenherausgeber, ob der Karteninhaber über ausreichend Kredit oder Guthaben verfügt, und autorisiert die Zahlung. | |
| Kartenkontenverwaltungssystem (Card Account Management Modul) | Das Kartenkontenverwaltungssystem (Card Account Management Modul) wird vom Systemintegrator bereitgestellt und ist entscheidend für die Verwaltung von Closed Loop EMV-Karten sowie die Abwicklung von Closed Loop-Transaktionen. Es ermöglicht die Erstellung, Aktualisierung und Nachverfolgung der Kartenkonten, verwaltet das auf den Karten gespeicherte Guthaben und sorgt für eine sichere, reibungslose Abwicklung der Transaktionen innerhalb eines geschlossenen Systems. Das System gewährleistet die effiziente Verwaltung von Karten und Transaktionen, ohne dass eine direkte Anbindung an externe Zahlungsnetzwerke erforderlich ist, da Kartendaten und Guthaben lokal verarbeitet werden. | |
| Kartennummer (PAN) | Die Kartennummer, auch PAN (Primary Account Number) genannt, ist die eindeutige Nummer, die auf einer Kredit- oder Debitkarte geprägt ist. Sie besteht in der Regel aus 16 Ziffern und identifiziert das Konto des Karteninhabers bei der Bank. | |
| Kartenorganisation | Eine Kartenorganisation ist ein Unternehmen, das Zahlungsnetzwerke betreibt und die globalen Standards sowie Regeln für den Einsatz von Kredit- und Debitkarten festlegt. Beispiele für Kartenorganisationen sind Visa, Mastercard, American Express, und Discover. Diese Organisationen ermöglichen die weltweite Akzeptanz und Abwicklung von Kartenzahlungen, indem sie Händler, Zahlungsdienstleister, Banken und Karteninhaber miteinander vernetzen. | |
| Kartentoken | Ein Kartentoken ist eine verschlüsselte Version der ursprünglichen EMV-Kartendaten (Open Loop EMV Kredit- oder Debitkarte sowie Closed Loop EMV Karten), die während einer Transaktion verwendet wird. Anstelle der echten Kartennummer (PAN) wird ein einmaliger Token generiert, der die sensiblen Kartendaten ersetzt. Der Token dient als Pseudonym für die eigentlichen zu schützenden Daten (z.B. Kartendaten). Ein mathematischer Zusammenhang (z.B. auf Grundlage eines Algorithmus) zwischen Originaldaten und Token besteht in der Regel nicht, bzw. ist den Teilnehmern im Zahlungsfluss nicht bekannt. Somit ist auch keine rechnerische Rückwandlung des Tokens möglich. | |
| Key exchange | Der Key Exchange beschreibt den Austausch von kryptografischer Schlüssel zwischen Kommunikationspartnern. | |
| Kiosk Modus | Der Kiosk-Modus in einer App ist eine spezielle Betriebsart, bei der die App auf einem Gerät so eingeschränkt wird, dass nur eine bestimmte Funktion oder Anwendung genutzt werden kann. In diesem Modus können Benutzer das Gerät nur für die vordefinierte App oder Funktion verwenden, während andere Funktionen oder Anwendungen gesperrt sind. Der Kiosk-Modus wird oft in öffentlichen Bereichen oder für spezifische Anwendungsfälle wie Informationsstände, Selbstbedienungsterminals oder im öffentlichen Verkehr genutzt, um eine fokussierte und kontrollierte Nutzung sicherzustellen. | |
| Known Fare Transaction | Eine Known Fare Transaction wird auch als Retail-like Transaction bezeichnet. Bei dieser wird der bereits festgelegte Ticketpreis durch das Anhalten einer kontaktlose Kreditkarte oder eine mobile Zahlungslösung (z. B. Google Pay, Apple Pay) an ein Lesegerät am Eingang des ÖPNV-Fahrzeugs automatisch abgebucht, ohne dass ein separates Ticket gekauft werden muss. | |
| Kundenportal | Ein Kundenportal, bereitgestellt vom Transit Payment Service Provider (PSP), ermöglicht es Fahrgästen, ihre Fahrten einzusehen, Rechnungsbelege herunterzuladen und Prozesse wie Reklamationen abzuwickeln. Es bietet eine zentrale Plattform zur Verwaltung und Nachverfolgung von Transaktionen und Fahrten. | |
| Mass transport transaction (MTT) | Die Visa Transit Rules im Kontext von Mass Transit Transactions sind spezielle Richtlinien, die Mastercard entwickelt hat, um die Zahlungsabwicklung im öffentlichen Verkehr zu erleichtern. Diese Regeln passen die typischen Kredit- und Debitkartentransaktionen an die besonderen Anforderungen von Transit-Systemen an, indem sie schnelle, kontaktlose Zahlungen und besondere Verarbeitungsprozesse ermöglichen. | |
| Merchant Category Code | Ein Merchant Category Code (MCC) ist ein vierstelliger Zahlencode, der von Kreditkartenorganisationen wie Visa, Mastercard und American Express verwendet wird, um die Art eines Geschäfts oder Dienstleistungsanbieters zu klassifizieren. Jede Branche oder Handelsaktivität hat ihren eigenen MCC, der von Zahlungsprozessoren verwendet wird, um die Art der Transaktion zu bestimmen und entsprechende Gebühren oder Vergünstigungen anzuwenden. | |
| Mobiler Validator | Ein mobiler Validator ist ein Gerät im öffentlichen Verkehrssystem, das im Fahrzeug (z. B. Bus, Zug oder Straßenbahn) installiert ist und zur Prüfung und Validierung von EMV-Karten dient. Fahrgäste können ihre kontaktlose Karte (z. B. Kredit- oder Debitkarte) am Validator "tappen", um ihre Fahrten zu bezahlen. | |
| Mobilfunk-/4G-/LTE-Modul | Ein Mobilfunk-/4G-/LTE-Modul ist eine elektronische Komponente, die z.B. in Validatoren, integriert wird, um über das Mobilfunknetz zu kommunizieren. Dieses Modul ermöglicht eine drahtlose Verbindung zu 4G- oder LTE-Netzwerken, um Daten in Echtzeit zu übertragen. | |
| Motics (UIC/VDV-KA) | Der Motics-Standard (auch UIC/VDV-KA genannt) ist ein offener, interoperabler Standard für elektronische Fahrkartensysteme, der von der Internationalen Eisenbahnunion (UIC) und dem Verband Deutscher Verkehrsunternehmen (VDV) entwickelt wurde. | |
| NFC | NFC (Near Field Communication) ist eine drahtlose Kommunikationstechnologie, die den Datenaustausch zwischen Geräten über kurze Distanzen von bis zu etwa 4 cm ermöglicht. NFC wird hauptsächlich für kontaktlose Zahlungen, Zugangskontrollen, Ticketing und Datenaustausch genutzt. | |
| NFC Wallets/ Consumer Devices | NFC Wallets (Near Field Communication Wallets) und Consumer Devices sind digitale Geldbörsen oder Endgeräte, die NFC-Technologie nutzen, um kontaktlose Zahlungen zu ermöglichen. Beispiele für NFC Wallets sind Apple Pay, Google Pay oder Samsung Pay, die auf mobilen Geräten wie Smartphones oder Smartwatches installiert sind. | |
| ODA, Deferred Authorization | Die Offline-Kartendatenvalidierung ist ein Prozess, bei dem ein Validator im öffentlichen Verkehr die Daten einer EMV-Karte prüft, ohne eine direkte Verbindung zu einem Zahlungsnetzwerk herzustellen. Dies wird häufig im öffentlichen Verkehr verwendet, um schnelle und reibungslose Transaktionen zu ermöglichen, auch wenn keine Echtzeitverbindung zum Hintergrundsystem verfügbar ist. | |
| Offline-Kartendatenvalidierung | Die Überprüfung von Kartendaten ohne direkte Verbindung zum Netzwerk. | |
| Open Loop | Ein offenes Zahlungssystem, bei dem verschiedene Karten und Zahlungsmethoden verwendet werden können. Als Open Loop Systeme werden die Zahlungsnetzwerke der internationalen Kartenorganisationen angesehen. | |
| PAN (Primary Account Number) | Die Primary Account Number (PAN) auf einer Open Loop EMV Debit-/ Kreditkarte oder auf einer Closed Loop EMV Karte ist eine 16-stellige eindeutige Kartenummer. | |
| PAR (Abgleich) | Eine Payment Account Reference (PAR) ist ein EMV- Standardwert, der zur Verknüpfung tokenisierter und PAN-basierter Transaktionen ohne PAN als Verknüpfungsmechanismus verwendet wird. | |
| Pay as you go (PAYG) transactions | Die Mastercard Transit Rules im Kontext von Pay As You Go (PAYG) Transaktionen sind spezielle Richtlinien, die Mastercard entwickelt hat, um die Zahlungsabwicklung im öffentlichen Verkehr zu erleichtern. Diese Regeln passen die typischen Kredit- und Debitkartentransaktionen an die besonderen Anforderungen von Transit-Systemen an, indem sie schnelle, kontaktlose Zahlungen und besondere Verarbeitungsprozesse ermöglichen. | |
| PCI-DSS | Der Payment Card Industry Data Security Standard (PCI-DSS) ist ein international anerkannter Sicherheitsstandard, der entwickelt wurde, um den sicheren Umgang mit Kredit- und Debitkartendaten zu gewährleisten. Er wurde von den großen Kreditkartenorganisationen (Visa, Mastercard, American Express, Discover und JCB) eingeführt und umfasst eine Reihe von Sicherheitsanforderungen, die Unternehmen erfüllen müssen, die Kartenzahlungen verarbeiten, speichern oder übertragen. | |
| Preisermittlungsservice (Fahrpreisberechnungsmodul) | Der Preisermittlungsservice, auch bekannt als Fahrpreisberechnungsmodul, ist ein zentraler Bestandteil des Vertriebshintergrundsystems, das vom Systemintegrator bereitgestellt wird. Dieses Modul berechnet den Fahrpreis basierend auf den im ID-based Ticketing implementierten Tariflogiken. | |
| Retail-like Transaction (Known Fare Transaction) | Eine Retail-like Transaction wird auch als Known Fare Transaction bezeichnet. Bei dieser wird der bereits festgelegte Ticketpreis durch das Anhalten einer kontaktlose Kreditkarte oder eine mobile Zahlungslösung (z. B. Google Pay, Apple Pay) an ein Lesegerät am Eingang des ÖPNV-Fahrzeugs automatisch abgebucht, ohne dass ein separates Ticket gekauft werden muss. | |
| Scheme Transit Rules | Scheme Transit Rules, auch als Transitparameter bezeichnet, sind festgelegte Regeln und Richtlinien, die von Zahlungsnetzwerken (wie Mastercard, Visa etc.) im Kontext von öffentlichen Verkehrstransaktionen definiert werden. Diese Parameter regeln, wie Transaktionen im öffentlichen Verkehr, insbesondere bei der Nutzung von EMV- Karten (kontaktlose Debit- und Kreditkarten), verarbeitet werden sollen. Sie umfassen spezifische Anforderungen für die Abwicklung von Fahrten, wie z. B. Höchstbeträge für Transaktionen, Vorautorisierungen, Verzögerungen bei der finalen Abrechnung oder Regelungen für Offline-Transaktionen, um schnelle und reibungslose Abläufe im Verkehrssystem zu gewährleisten. Die Transitparameter sorgen dafür, dass die Zahlungsabwicklung sowohl für Fahrgäste als auch für Verkehrsbetriebe effizient und sicher ist." | |
| Security Application Module (SAM) | Ein Security Application Module (SAM) ist ein spezialisiertes Hardwaremodul, das in sicherheitskritischen Anwendungen verwendet wird, um kryptografische Operationen durchzuführen und sensible Daten zu schützen. Es wird häufig in Zahlungssystemen, insbesondere im öffentlichen Verkehr und bei kontaktlosen Transaktionen, eingesetzt. Das SAM dient zur sicheren Speicherung von kryptografischen Schlüsseln und zur Ausführung von Authentifizierungs- und Verschlüsselungsprozessen, um die Sicherheit bei der Kommunikation zwischen Karten, Validatoren und Hintergrundsystemen zu gewährleisten. Es schützt vor Manipulation und gewährleistet, dass nur autorisierte Karten oder Tokens verwendet werden können. SAMs sind besonders in geschlossenen Systemen, wie z. B. Closed Loop EMV-Kartensystemen, weit verbreitet. | |
| Seriennummer (Gerätenummer) | Eine eindeutige Nummer zur Identifikation eines Produkts oder Gerätekomponenten. | |
| SIM (-Karte) | Eine Karte, die in Mobilgeräten verwendet wird, um das Gerät im Netz zu registrieren. | |
| SoftPOS Lösung | Eine SoftPOS-Lösung (Software Point of Sale) ist eine softwarebasierte Kassenlösung, die es Händlern ermöglicht, Zahlungen direkt über ein handelsübliches Smartphone oder Tablet zu akzeptieren, ohne dass zusätzliche Hardware wie ein herkömmliches Kartenterminal erforderlich ist. Diese Technologie nutzt die NFC-Funktion (Near Field Communication) des Geräts, um kontaktlose Zahlungen mit EMV-Karten (Kredit- und Debitkarten) sowie digitalen Wallets (z. B. Apple Pay oder Google Pay) durch "Tappen" zu akzeptieren. | |
| Software Development Kit (SDK) | Ein Software Development Kit (SDK) ist eine Sammlung von Softwaretools, Bibliotheken, Dokumentationen und Codebeispielen, die Entwicklern zur Verfügung gestellt wird, um Anwendungen oder Softwarelösungen für eine bestimmte Plattform, ein Betriebssystem oder eine Technologie zu erstellen. Ein SDK erleichtert die Entwicklungsarbeit, indem es grundlegende Funktionen und Schnittstellen bereitstellt, die Entwickler in ihre eigenen Programme integrieren können. | |
| Sperrliste (Blacklist) | Eine Sperrliste (auch als "Blacklist" bezeichnet) ist eine Liste von Karten, Tokens oder Identifikationsmedien, die für den Zugang zu einem System oder Dienst gesperrt wurden. Im Kontext eines ID-basierten Ticketingsystems enthält die Sperrliste Fahrkarten oder EMV-Karten, die aus bestimmten Gründen (wie ungültige Zahlungen, abgelaufene Tickets oder Sicherheitsbedenken) nicht mehr akzeptiert werden. Validatoren greifen auf diese Liste zu, um zu verhindern, dass gesperrte Karten zur Validierung genutzt werden, und verweigern entsprechend den Zugang zum Verkehrssystem. Die Sperrliste wird regelmäßig aktualisiert und an alle relevanten Geräte, wie stationäre und mobile Validatoren, verteilt. | |
| Stationärer Validator | Stationäre Validatoren sind fest installierte Geräte, die in ID-basierten Ticketingsystemen an Haltestellen oder Bahnhöfen zur Validierung von Fahrgästen genutzt werden. Fahrgäste können ihre EMV-Karten kontaktlos am Validator "tappen", um ihre Fahrt zu beginnen oder zu bestätigen (siehe auch Validator/ mobiler Validator). | |
| Systemintegrator | Ein Systemintegrator ist ein Anbieter, der für die Bereitstellung und Integration von technologischen Lösungen verantwortlich ist. Im Kontext eines ID- basierten Ticketingsystems übernimmt der Systemintegrator die Lieferung und Installation der Validatoren (Geräte zur Ticketprüfung) sowie des Vertriebshintergrundsystems (das zentrale System, das die Verwaltung von Ticketverkäufen und - kontrollen steuert). Der Integrator sorgt dafür, dass beide Komponenten nahtlos zusammenarbeiten und mit anderen Systemen wie Zahlungsabwicklern, Kontrolllösungen und Transitdienstleistern vernetzt sind, um einen reibungslosen und effizienten Betrieb des Ticketingsystems zu gewährleisten. | |
| Tap | Das kontaktlose Bezahlen durch kurzes Auflegen oder Anhalten der EMV Karte auf oder an einem Kartenlesegerät, Validator/ Terminal. | |
| Teillastenheft | Als Teillastenheft werden alle Anforderungen und Informationen bezeichnet, die unter der jeweils gleichen Kategorie aufgelistet sind, wie z.B. bei "Allgemeinen Anforderungen" ergeben allen Anforderungen und Informationen von 00- Information bis 00-C-02 zusammen das Teillastenheft "0 Allgemeine Anforderungen". | |
| Terminal-Management-System | Ein System zur Verwaltung und Aktualisierung von Zahlungsterminals. | |
| Terminalapplikation | Eine Anwendung des Transit PSP, die auf einem Zahlungsterminal installiert wird, um Transit Transaktionen abzuwickeln. | |
| Token | Bei der Tokenisierung handelt es sich um den Prozess, bei dem vertrauliche persönliche Informationen durch einen Ersatzwert ersetzt werden, den Token. | |
| Token-basierte Interoperabilität | Die Verwendung von Token zur Abwicklung undn Zuordnung von Transaktionen und Zahlungen zwischen verschiedenen Systemen. | |
| Tokendatenbank | Eine Datenbank, die Tokens zur sicheren Verwaltung von Zahlungsinformationen speichert. | |
| Transaction Type Indicator | Der Transaction Type Indicator (TTI) ist ein Datenfeld in einer Zahlungstransaktion, das den spezifischen Typ der Transaktion angibt. Es wird verwendet, um zu kennzeichnen, ob es sich um eine bestimmte Art von Transaktion handelt, wie z. B. eine reguläre Zahlung, eine Vorautorisierung, eine Offline-Transaktion oder eine Transit-Transaktion. | |
| Transaktion | Eine Transaktion ist der Prozess, bei dem eine finanzielle Bewegung zwischen zwei Parteien stattfindet, wie z. B. der Kauf einer Ware oder Dienstleistung mit einer Debit- oder Kreditkarte. | |
| Transaktions-ID | Eine eindeutige Kennung für eine Transaktion. | |
| Transaktionsreferenz | Eine eindeutige Transaktionsreferenz ist eine einmalige Kennung, die jeder Zahlung oder Transaktion zugeordnet wird, um sie von allen anderen Transaktionen zu unterscheiden. Diese Referenznummer dient zur Nachverfolgung und Identifizierung einer spezifischen Transaktion innerhalb eines Zahlungs- oder Buchungssystems und ist für den Händler, den Kunden sowie die beteiligten Zahlungsdienstleister von Bedeutung. | |
| Transaktionstyp | Als Transaktionstypen sind spezielle Arten von Transaktionen gemeint, z.B. Known Fare Transaction | |
| Transit | Transit wird im Kontext dieses Lastenheftes synonmy mit dem öffentlichen Nahverkehr verwendet. | |
| Transit Payment Service Provider (Transit PSP) | Ein Transit Payment Service Provider (TPSP) ist ein spezialisierter Zahlungsdienstleister, der für die Abwicklung von Zahlungen im öffentlichen Verkehr verantwortlich ist. Der TPSP ermöglicht es Fahrgästen, mit EMV-Karten (kontaktlose Kredit- oder Debitkarten), mobilen Zahlungsdiensten oder anderen digitalen Zahlungsmethoden ihre Fahrten zu bezahlen. Er sorgt dafür, dass die Transaktionen gemäß den spezifischen Anforderungen des Transitmodus abgewickelt werden, wie z. B. schnelle, kontaktlose Zahlungen, verzögerte Abrechnungen und die Einhaltung der Regeln von Zahlungsnetzwerken (z. B. Visa, Mastercard). Der TPSP fungiert als Schnittstelle zwischen Verkehrsbetrieben, Acquirern und Kartenorganisationen und stellt sicher, dass alle Zahlungen sicher und effizient verarbeitet werden, um einen reibungslosen Fahrgastfluss zu gewährleisten. | |
| Transit Payment Service Provider Back-end | Das Back-end eines Transit Payment Service Providers (TPSP) ist die zentrale Infrastruktur, die die Zahlungsabwicklung für öffentliche Verkehrstransaktionen unterstützt. Es handelt sich um das technische System im Hintergrund, das für die Verarbeitung von Zahlungen, die Verwaltung von Kundendaten und die Integration mit den Zahlungsnetzwerken (z. B. Visa, Mastercard) verantwortlich ist. Das TPSP-Back-end übernimmt Aufgaben wie die Verifizierung von EMV-Kartentransaktionen, die Abwicklung von Vorautorisierungen, das Zusammenfassen von Fahrten für spätere Abrechnungen und die Kommunikation mit Acquirern und Issuern. Es sorgt dafür, dass die Transaktionen sicher und effizient abgewickelt werden, und stellt sicher, dass die Zahlungen gemäß den spezifischen Transitparametern und -richtlinien verarbeitet werden. | |
| Transit-ready Acquirer | Ein Transit-ready Acquirer ist ein Zahlungsabwickler, der von den Kartenorganisationen (wie Mastercard, Visa etc.) zertifiziert wurde, um Transit-Transaktionen abwickeln zu können. Dies bedeutet, dass der Acquirer die speziellen Anforderungen und Richtlinien für den Transitmodus erfüllt, einschließlich der schnellen und sicheren Verarbeitung von EMV- Kartentransaktionen in öffentlichen Verkehrssystemen. Ein solcher Acquirer ist in der Lage, Transaktionen wie kontaktlose Zahlungen im öffentlichen Nahverkehr zu unterstützen, bei denen eine sofortige Autorisierung und Abrechnung erforderlich sind, um einen reibungslosen Fahrgastfluss zu gewährleisten. | |
| Transitdaten | Transitdaten sind spezifische Daten, die beim Einsatz von ID-based Ticketing oder EMV-Karten im öffentlichen Verkehr an einen Transit Payment Service Provider (Transit PSP) übermittelt werden und beinhalten z.B. Token, Transaktionsreferenz, Zeitstempel, Ort (Haltestelle, Kurs, Linie), Tarifinformationen, Kartenart usw. Die Transitdaten werden via IBIS Wagenbus vom IBIS Master abgerufen. | |
| Transitmodus | Der Transitmodus ist eine spezielle Betriebsart bei der Verwendung von EMV-Karten (kontaktlosen Kredit- oder Debitkarten) im öffentlichen Verkehr. In diesem Modus werden Transaktionen anders als bei normalen Einzelhandelszahlungen verarbeitet, um eine schnelle und reibungslose Nutzung in Verkehrssystemen zu ermöglichen. Im Transitmodus können Fahrgäste ihre EMV-Karte einfach tappen, ohne dass eine PIN-Eingabe oder Unterschrift erforderlich ist. Diese Transaktionen können sofort freigegeben werden, ohne eine direkte Online-Verbindung für die Autorisierung. Der Transitmodus berücksichtigt außerdem spezielle Regeln wie das Zusammenfassen von Transaktionen (Batch Processing) oder eine verzögerte Abrechnung, um die Fahrgastabfertigung zu beschleunigen und den Verkehrsfluss zu optimieren. | |
| Transitparameter (Scheme Transit Rules) | Transitparameter, auch als Scheme Transit Rules bezeichnet, sind festgelegte Regeln und Richtlinien, die von Zahlungsnetzwerken (wie Mastercard, Visa etc.) im Kontext von öffentlichen Verkehrstransaktionen definiert werden. Diese Parameter regeln, wie Transaktionen im öffentlichen Verkehr, insbesondere bei der Nutzung von EMV- Karten (kontaktlose Debit- und Kreditkarten), verarbeitet werden sollen. Sie umfassen spezifische Anforderungen für die Abwicklung von Fahrten, wie z. B. Höchstbeträge für Transaktionen, Vorautorisierungen, Verzögerungen bei der finalen Abrechnung oder Regelungen für Offline-Transaktionen, um schnelle und reibungslose Abläufe im Verkehrssystem zu gewährleisten. Die Transitparameter sorgen dafür, dass die Zahlungsabwicklung sowohl für Fahrgäste als auch für Verkehrsbetriebe effizient und sicher ist. | |
| UIC/VDV-KA (Motics-Standard) | Der UIC/VDV-KA-Standard (auch Motics genannt) ist ein offener, interoperabler Standard für elektronische Fahrkartensysteme, der von der Internationalen Eisenbahnunion (UIC) und dem Verband Deutscher Verkehrsunternehmen (VDV) entwickelt wurde. | |
| Validator | Ein Validator ist ein Gerät im öffentlichen Verkehrssystem, das EMV-Karten prüft und validiert. Fahrgäste können ihre Karte kontaktlos "tappen", und der Validator überprüft, ob das Ticket oder die Zahlung gültig ist. Es ermöglicht eine schnelle und bargeldlose Nutzung von Verkehrsdiensten. | |
| Validatorgrundplatte | Die (Validator-)Grundplatte ist die feste Basiskomponente, auf der ein Validator im öffentlichen Verkehrssystem montiert wird. Sie dient als mechanische Schnittstelle zwischen dem Validator (dem Gerät, das Fahrkarten oder Tokens prüft) und der physikalischen Infrastruktur des Verkehrsmittels oder der Station, wie z. B. Bussen, Bahnen oder Stationsterminals. | |
| Vodafone CDA | Vodafone Corporate Data Access (CDA) ist ein mobiles IP-VPN (Virtual Private Network), das entwickelt wurde, um mobile Teilnehmer sicher in das Firmennetzwerk einzubinden, ohne dass zusätzliche Software oder VPN-Clients erforderlich sind. | |
| Vorautorisierungstransaktionen | Eine Vorautorisierungstransaktion ist eine temporäre Reservierung eines bestimmten Betrags auf einer Kredit- oder Debitkarte, ohne dass dieser Betrag sofort abgebucht wird. Sie wird häufig verwendet, um die Gültigkeit der Zahlungsmethode zu überprüfen und sicherzustellen, dass ausreichende Mittel für eine spätere Transaktion verfügbar sind. Im Kontext des ID-basierten Ticketings kann eine Vorautorisierungstransaktion durchgeführt werden, um zu bestätigen, dass ein Fahrgast über genügend Guthaben verfügt, bevor der tatsächliche Betrag für die Fahrt abgerechnet wird. | |
| VPN-Tunnel | Eine verschlüsselte Verbindung zwischen zwei Netzwerken, die über das Internet erfolgt. | |
| Whitelist | Eine Whitelist ist eine Liste von Tokens (tokenisierte EMV Karten), die im Validator gespeichert sind. Wenn ein Fahrgast seinen Karte am Validator präsentiert, prüft dieser die Whitelist lokal, um festzustellen, ob der Token zugelassen ist und die Transaktion freigegeben werden kann, ohne eine Online- Verbindung zum Hintergrundsystem herzustellen. | |
| Zahlkarte | Eine Zahlkarte ist eine Karte, die von einem Finanzinstitut oder einer Bank herausgegeben wird. Eine Closed Loop Zahlungskarte muss nicht zwingend von einem Finanzinstitut oder einer Bank herausgegeben werden, da keine Banklizenz erforderlich ist. | |
| Zahlungsfenster | Zeitraum in dem Transaktionen gesammelt werden, die im Anschluss an das Zahungsfenster abgerechnet werden. |
[Seite 54]
| UNTERNEHMENSVORSTELLUNG VVM VERKEHRSVERBUND MITTELSCHWABEN GMBH | |
|---|---|
| Der Verkehrsverbund Mittelschwaben GmbH (VVM) mit Sitz in Krumbach wurde 1995 gegründet und bündelt den öffentlichen Personennahverkehr in den Landkreisen Günzburg, Unterallgäu sowie der Stadt Memmingen. Als Gemeinschaft von Landkreisen und Verkehrsunternehmen sorgt der VVM für einheitliche Tarife, abgestimmte Fahrpläne und einen durchgängigen Service über Landkreisgrenzen hinweg. Rund 96 Linien mit etwa 1.000 Haltestellen sichern die Mobilität in der Region. Neben klassischen Busverbindungen bietet der VVM mit dem bedarfsorientierten FLEXIBUS ein innovatives Angebot, das besonders den ländlichen Raum stärkt. Ziel des Verbunds ist ein einfaches, verlässliches und kundenfreundliches Mobilitätssystem mit einem Fahrschein für alle Verkehrsmittel und Strecken. Durch enge Kooperation mit Verkehrsunternehmen, Landkreisen und Kommunen fördert der VVM nachhaltige, klimafreundliche Mobilität und leistet einen wichtigen Beitrag zur Daseinsvorsorge in Mittelschwaben. |
[Seite 55]
| # | TEILLASTENHEFT | KATEGORIE | SUB-KATEGORIE | ID | ANFORDERUNGSBESCHREIBUNG | TYP ANFORDERUNG | ||
|---|---|---|---|---|---|---|---|---|
| 0 | Allgemeine Anforderungen | Information | 00-0-Information | Dieses Teillastenheft enthält Anforderungen, die sich auf die gesamthaft gelieferte System inkl. Hard- und Software beziehen. In der Anlage XXX (Konzept VVMBestPreis) finden Sie ausführliche Informationen zum Projekt. | I | |||
| 0 | Allgemeine Anforderungen | Generelle Anforderungen | Ausführungsplanung | 00-A-01-01 | Das Lastenheft bildet die inhaltliche und strukturelle Basis für die Ausführungsplanung. | M | ||
| 0 | Allgemeine Anforderungen | Anforderungen an die Gesamtlösung | Ganzheitliche Funktionsfähigkeit | 00-B-01-01 | Die vollständige Funktionsfähigkeit der gelieferten Gesamtlösung, inkl. aller Hard-/ Softwarekomponenten sowie deren Schnittstellen, ist gemäß den Spezifikationen der Kartenorganisation (KFT/Retail-like und MTT/PAYG) sowie den Anforderungen des Lastenheftes mit allen dazugehörigen Teillastenheften zu gewährleisten. | M | ||
| 0 | Allgemeine Anforderungen | Anforderungen an die Gesamtlösung | Transit PSP | 00-B-02-01 | Der AG hat bereits sfey Pay OÜ mit der Erbringung der Transit PSP Leistungen beauftragt. Der Bieter muss die vollständige technische Integration von sfey Pay OÜ bis 3 Monate nach Beauftragung abgeschlossen haben. Der AG behält sich ein Rücktrittsrecht vom Vertrag vor, wenn die Integration nicht bis zum vereinbarten Zeitpunkt (3 Monate nach Beauftragung) abgeschlossen ist. | M | ||
| 0 | Allgemeine Anforderungen | Anforderungen an die Gesamtlösung | Transit PSP | 00-B-02-02 | Der Bieter hat mit dem Angebot ein schlüssiges und prüffähiges Konzept vorzulegen, das die geplante technische Integration und Anbindung an den bereits beauftragten Transit PSP sfey Pay OÜ beschreibt. Das Konzept muss nachvollziehbar darlegen, dass die vollständige technische Integration innerhalb von drei Monaten nach Beauftragung umgesetzt und abgeschlossen werden kann. Das Konzept muss mindestens folgende Inhalte umfassen: - Beschreibung der Systemarchitektur und der relevanten Schnittstellen - Darstellung der Integrationsschritte, inkl. Abhängigkeiten, Meilensteinen und Zeitplan, aus dem die Umsetzung innerhalb von drei Monaten hervorgeht - Beschreibung der Datenflüsse, Datenformate und Kommunikationsprotokolle - Darstellung der Integrations- und Abnahmetests, inkl. Testumgebungen und Abnahmekriterien - Maßnahmen zur Sicherstellung der Betriebsstabilität nach erfolgreicher Integration - Darstellung wesentlicher Integrationsrisiken sowie geplanter Maßnahmen zur Risikominimierung, insbesondere in Bezug auf die fristgerechte Umsetzung innerhalb von drei Monaten | K | ||
| 0 | Allgemeine Anforderungen | Anforderungen an Generalunternehmer | Gewährleistung | 00-B-03-01 | Es muss ein ordnungsgemäßer Zustand nach Erbringung der Dienstleistung/des Aufwandes zur Integration der gesamten Hardware des AG für 36 Monate gewährleistet werden. | M | ||
| 0 | Allgemeine Anforderungen | Anforderungen an Generalunternehmer | Produktverfügbarkeit | 00-B-04-01 | Der Bieter muss eine ganzheitliche Produktverfügbarkeit von 10 Jahren sicherstellen, respektive sicherstellen, dass abwärtskompatible Produkte, Bau- und Ersatzteile verfügbar sind. Dieses muss alle benötigen Dienstleistungen wie Softwarewartung und Reparatur umfassen. | M | ||
| 0 | Allgemeine Anforderungen | Rechtliche Anforderungen | Datenschutz | 00-C-01-01 | Die zu beschaffenden Systeme unterliegen der EU-DSGVO. Die Vorgaben der EU-DSGVO sind verpflichtend einzuhalten. Es wird vom Bieter erwartet, dass die Grundsätze der DSGVO (Transparenz, Zweckbindung, Datenminimierung, Authentizität, Speicherbegrenzung, Integrität, Vertraulichkeit und Revisionsfähigkeit) in allen Systembereichen gewährleistet sind. Die Anforderungen sind über den gesamten Produktlebenszyklus einzuhalten. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Anwendungs-/ Plattformsicherheit | 00-D-01-01 | Der Bieter verpflichtet sich, ein dem Stand der Technik entsprechendes Sicherheitsniveau entlang der kompletten IT-Infrastruktur des bargeldlosen Zahlungssystems nachweislich einzuhalten und aufrechtzuerhalten. Der Nachweis zum Sicherheitsniveau basiert auf der ISO 27001:2022. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als Nachweis akzeptiert. | N | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Anwendungs-/ Plattformsicherheit | 00-D-01-02 | Es muss ein Informationssicherheitskonzept existieren bzw. im Laufe der Auftrags (Einführungs- und Betriebsphase) erstellt werden. Im Informationssicherheitskonzept sind die ergriffenen Sicherheitsmaßnahmen zur Gewährleistung der Informationssicherheit aufzuzeigen - sog. technische und organisatorische Maßnahmen (z. B. Einsatz von Firewall und Intrusion-Detection/Prevention-Systemen, Systemhärtungen). Die Sicherheitsmaßnahmen aus dem Informaionssicherheitskonzept werden regelmäßig auf Wirksamkeit durch eine unabhängige Stelle überprüft. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Anwendungs-/ Plattformsicherheit | 00-D-01-03 | Der Bieter verpflichtet sich, regelmäßige IT-Sicherheitsaudits und/oder Penetrationstests durchzuführen, so dass die Einhaltung des vereinbarten Sicherheitsniveaus entlang der kompletten IT-Infrastruktur des bargeldlosen Zahlungssystems überprüft werden kann. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Datensicherheit | 00-D-02-01 | Der Bieter verpflichtet sich, sichere Verfahren zur Verschlüsselung der abgelegten Daten ("data in rest" und "data in use") gemäß dem Stand der Technik einzusetzen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Datensicherheit | 00-D-02-02 | Der Bieter verpflichtet sich, sichere Verschlüsselungs- und Signaturverfahren zur Absicherung der Kommunikation bzw. der Datenflüsse („data in motion“) entlang der kompletten IT-Infrastruktur einzusetzen. Dies hat gemäß dem Stand der Technik zu erfolgen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Datensicherheit | 00-D-02-03 | Bei sämtlichen Anmeldevorgängen entlang der kompletten IT-Infrastruktur sind sichere Authentisierungsmechanismen gemäß Stand der Technik zu implementieren. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Datenverfügbarkeit | 00-D-03-01 | Es muss die Möglichkeit geben, die beim Bieter abgelegten AG-eigenen Daten (z. B. bei Beendigung der Geschäftsbeziehung) in einer geeigneter Form mitzunehmen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Datenverfügbarkeit | 00-D-03-02 | Es muss die Möglichkeit geben, die beim Bieter abgelegten AG-eigenen Daten (z. B. bei Beendigung der Geschäftsbeziehung) in einer geeigneter Form mitzunehmen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Rechenzentrum-Sicherheit | 00-D-04-01 | Der Bieter setzt zur Erbringung der vereinbarten Dienstleistungen ein Rechenzentrum /Rechenzentren ein, dessen Sicherheit der ISO 27001:2022 entspricht. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-01 | Der Bieter muss für sämtliche eingesetzten IT-Systeme und Infrastrukturbestandteile umfassende Härtungsmaßnahmen implementieren, die den aktuell anerkannten Sicherheitsstandards entsprechen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-02 | Die Härtung hat mindestens folgende Anforderungen abzudecken: - Absicherung von Betriebssystemen, Anwendungen und Middleware, - Deaktivierung nicht benötigter Dienste und Schnittstellen, - sichere Konfiguration aller Komponenten nach Best Practices (z. B. CIS Benchmarks, BSI-Empfehlungen), - Umsetzung von Netzwerksegmentierung und Zugriffsbeschränkungen | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-03 | Alle Systemkomponenten müssen so konfiguriert sein, dass sie gegen gängige Angriffsszenarien geschützt sind und ein minimales Angriffsprofil aufweisen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-04 | Der Bieter muss automatisierte oder standardisierte Verfahren vorsehen, um die Härtung dauerhaft durchzusetzen und zu überwachen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-05 | Sicherheitsupdates, Patches und Konfigurationsänderungen müssen zeitnah umgesetzt und automatisiert ausgerollt werden, sofern dies technisch möglich ist. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-06 | Der Bieter hat Kontrollmechanismen einzurichten, die die Einhaltung der Härtungsmaßnahmen fortlaufend überprüfen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-07 | Es sind technische Maßnahmen vorzusehen, die sicherstellen, dass sicherheitskritische Konfigurationsänderungen erkannt, protokolliert und bewertet werden. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-08 | Der Bieter muss die Härtungsmaßnahmen für alle Systemkomponenten vollständig dokumentieren. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-09 | Die Dokumentation muss mindestens enthalten: - angewendete Sicherheitsrichtlinien und Standards, - konfigurierte Sicherheitsmaßnahmen je Systemkomponente, - durchgeführte Patches, Updates und Änderungen, - Ergebnisse durchgeführter Härtungskontrollen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-10 | Die Dokumentation ist stets aktuell zu halten und dem Auftraggeber auf Anfrage bereitzustellen. | M | ||
| 0 | Allgemeine Anforderungen | Informationssicherheit | Systemhärtung | 00-D-05-11 | Der Bieter muss sicherstellen, dass die Härtungsprozesse regelmäßig überprüft und bei neuen Bedrohungslagen angepasst werden. | M | ||
| 1 | Mobiler Validator | Information | 01-00-Information | Das Teillastenheft 1 beschreibt die Anforderungen an den mobilen Validator, inkl. QR Code Leseeinheit. Alle mobilen Validatoren werden mit einem cEMV UPOS Terminal bestellt. Es müssen 400 mobile Validatoren vom Bieter geliefert werden. Fahrezuge vom Typ "Kleinbus" werden mit 1 mobilen Validator pro Fahrzeug ausgestattet. Fahrzeuge vom Typ "Solobus" werden mit 2 mobilen Validatoren pro Fahrzeug ausgestattet. Fahrzeuge vom Typ "Gelenkbus" werden mit 3 mobilen Validatoren pro Fahrzeug ausgestattet. | I | |||
| 1 | Mobiler Validator | Generelle Anforderung | Datenblatt | 01-A-01-01 | Ein aussagekräftiges Datenblatt ist beizulegen. | N | ||
| 1 | Mobiler Validator | Funktionalität | Anzeige | 01-B-01-01 | Am Startbildschirm muss die Check-In/Check-Out Funktion angezeigt werden. Mögliche weitere Tickets müssen über ein Untermenü erworben werden. Dazu ist die Anzeige der Ticketauswahl auf dem Display obligatorisch. Die umzusetzenden Tickets können XXX (Konzept VVMBestPreis) entnommen werden. | M | ||
| 1 | Mobiler Validator | Funktionalität | Guthabenanzeige Closed Loop EMV Karte | 01-B-02-01 | Der mobile Validator muss die Funktion bieten den letzten aktuellen Guthabenbestand bei CheckIn (mit minimalem zeitlichem Verzug) der Closed Loop EMV Karte anzeigen zu lassen. | M | ||
| 1 | Mobiler Validator | Funktionalität | Optisches Signal | 01-B-03-01 | Der Fahrgast muss durch ein optisches Signal über den (Nicht-)Erfolg des Taps informiert werden, wobei das optische Signal inviduell konfigurierbar sein muss. | M | ||
| 1 | Mobiler Validator | Funktionalität | Akustisches Signal | 01-B-04-01 | Der mobile Validator muss ein akustisches Signal/Ton ausgegeben können, um über den (Nicht-)Erfolg des Taps zu informieren, wobei das Signal/der Ton inviduell konfigurierbar sein muss. | M | ||
| 1 | Mobiler Validator | Funktionalität | PKM | 01-B-05-01 | Der Validator muss PKM-konforme Kontrollmodule (nach Fraunhofer-IVI-Standard) verarbeiten können. Er muss die in den PKM-Modulen enthaltenen Regeln und Daten zur Ticketprüfung (z. B. Gültigkeit, räumliche und zeitliche Bedingungen, Produktmerkmale) interpretieren und anwenden können. Taps werden angereichert durch Transitdaten (Linie, Haltstelle, Fahrtweg, Zonenzuordnung, etc.) an das Hintergrundsystem und von dort an den Tarifrechner nach PKM gesendet. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | cEMV UPOS Terminal | 01-C-04-01 | Im mobilen Validator muss ein integriertes cEMV UPOS Terminal gemäß den Anforderungen aus TLH 4 verbaut sein. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Gehäuse | 01-C-05-01 | Das Gehäuse des mobilen Validators besitzt keine Fugen, die größer als 1 mm sind. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Gehäuse | 01-C-05-02 | Der mobile Validator muss in einem robusten, für den ÖPNV geeigneten Kunststoffgehäuse verbaut sein. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Geräte- und Seriennummer | 01-C-06-01 | Die Geräte- und die Seriennummer ist in Klarschrift und als Barcode auf dem Typenschild des mobilen Validators dauerhaft anzubringen. Außerdem ist die Gerätenummer in der Speichereinheit im mobilen Validator dauerhaft abzulegen. Sie bleibt während der gesamten Lebensdauer des Gerätes unveränderbar. Dies muss auch bei späteren Ergänzungslieferungen Berücksichtigung finden. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Gewicht | 01-C-07-01 | Das Maximalgewicht des mobilen Validators darf 5 kg nicht überschreiten. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Größe | 01-C-08-01 | Die Abmessungen des mobilen Validators exkl. Halteplatte, ohne Schutzverkleidung in Millimeter dürfen folgende Maße nicht überschreiten: 150 mm (Breite) X 330 mm (Höhe) X 100 mm (Tiefe). | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-01 | Das Kundendisplay ist als ein vollgrafikfähiges hintergrundbeleuchtetes PCAP TFT-Touch-Farbdisplay vorgesehen. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-02 | Das PCAP TFT-Touch-Farbdisplay ist im Gehäuse des Geräts so zu integrieren, dass auch unter schlechten Lichtverhältnissen sowie bei Sonneneinstrahlung die Lesbarkeit für den Kunden gewährleistet ist. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-03 | Das PCAP TFT-Touch-Farbdisplay passt die Helligkeit automatisch der Umgebung an. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-04 | Der PCAP TFT-Touch-Farbdisplay beugt Spiegelungen vor. Hierfür darf keine Folie verwendet werden. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-05 | Das PCAP TFT-Touch-Farbdisplay hat eine Größe von mind. 5 Zoll (Bildschirmdiagonale) und eine Auflösung von 640*480 Pixel (VGA) oder besser. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-06 | Das PCAP TFT-Touch-Farbdisplay muss im Hochformat verbaut sein. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-07 | Der Ablesewinkel des PCAP TFT-Touch-Farbdisplay beträgt sowohl horizontal als auch vertikal 150 - 170 Grad (gemessen von der Mittelachse), sodass der Bildschirminhalt aus jeder Sichtposition des Kunden abgelesen werden kann. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kundendisplay | 01-C-09-08 | Die Innenseite des PCAP TFT-Touch-Farbdisplay darf nicht anlaufen oder verschmutzen. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Konfiguration GUI | 01-C-10-01 | Tastenkombinationen oder Bedienhandlungen durch unberechtigtes Personal, die einen Wechsel auf Betriebssystemebene auslösen können, sind nicht möglich. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kühlung | 01-C-11-01 | Gegebenenfalls während des Betriebes innerhalb des Gehäuses entstehende Eigenwärme darf die Funktionalität der Baugruppen nicht beeinträchtigen. Eine aktive Kühlung (z. B. durch einen Lüfter) ist unzulässig. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Kühlung | 01-C-11-02 | Gegebenenfalls während des Betriebes innerhalb des Gehäuses entstehende Eigenwärme darf die Funktionalität der Baugruppen nicht beeinträchtigen. Eine aktive Kühlung (z. B. durch einen Lüfter) ist unzulässig. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Information | 01-C-11-Information | Die Konnektivität der Geräte erfolgt ausschließlich über eSIM. Die eSIM wird durch den Auftraggeber (AG) bereitgestellt; der entsprechende Mobilfunkvertrag wird ebenfalls durch den AG abgeschlossen. Eine Ausstattung mit physischen SIM-Karten ist nicht vorgesehen. | I | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Lackierung | 01-C-12-01 | Der mobile Validator muss in der Farbe RAL XXXX geliefert werden. | M | ||
| 1 | Mobiler Validator | Hardware Anforderungen | Mobilfunkmodul | 01-C-13-01 | Die mobilen Validatoren müssen zur Datenfernübertragung mit einem 4G/LTE Modul oder besser ausgestattet sein. Der Bieter gibt die voraussichtliche Datenmenge pro Tap und Systemupdates, Listenmanagement getrennt voneinander in der Spalte "Bemerkung" an. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Datenfernübertragung | 01-D-01-01 | Zur Datenfernübertragung im mobilen Validator werden zwei Wege vorgesehen: Die Datenfernübertragung muss über ein integriertes 4G-Modul (oder höherwertig) via eSIM im Validator hergestellt werden. Die Datenfernübertragung muss über einen Router im Fahrzeug via LAN-Verkabelung hergestellt werden. Dabei werden Router und Validator über einen Switch verbunden. (ANZAHL DER SWITCHE) xx Router (RUT956) der Fa. TELTONIKA und xx 10-Port-Switche (ROQSTAR Unmanaged Gigabit PoE Switch, 10 Ports / M12, Produktnummer: 006-130-116) der Fa. TRONTEQ GmbH sind hierfür vom Bieter optional zu beschaffen und einzubauen. Die Datenblätter sind den Vergabeunterlagen als Anlage beigefügt. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Elektrische Anschlüsse | 01-D-02-01 | Der AG meint mit situationsbedingter Adaptierung die Verbindung zwischen Kabel und Endgerät. Diese muss rüttelfest und entsprechend der geltenden Normen vom Bieter bereitgestellt werden. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Kabelanforderungen | 01-D-03-01 | Bereits im Fahrzeug vorhandene Kabel müssen vom Bieter verwendet werden. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Kabelanforderungen | 01-D-03-02 | Für die Spannungsversorgung muss folgender Kabeltyp verwendet werden: Bus, 1,5 mm²: - Dauerplus, Leitungsfarbe rot - geschalteter Plus, Leitungsfarbe weiß - Minus, Leitungsfarbe braun Die verwendeten Leitungen entsprechen den aktuellen Normen und Richtlinien zum Einbau in Fahrzeuge des ÖPNV. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Kabelanforderungen | 01-D-03-03 | Für die Datenversorgung mit IBIS Daten müssen folgender Kabeltypen verwendet werden: *Netzwerkkabel (CAT-5) mit situationsabhängiger Adaptierung für IBIS IP *IBIS (IBIS Wagenbus 4 x 0,75 mm^2 (LiYCY)) mit situationsabhängiger Adaptierung Die verwendeten Leitungen entsprechen den aktuellen Normen und Richtlinien zum Einbau in Fahrzeuge des ÖPNV. Hinweis: Die Busunternehmen BBS, Dirr, Gruber, Klaus, Miller, RBA werden mit IBIS Daten via IBIS IP versorgt. Die Busunternehmen Braunmiller, Steber, Kirchweihtal und Probst-Bus mit IBIS Daten via IBIS Wagenbus. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Kabelanforderungen | 01-D-03-04 | Für die Datenfernübertragung muss folgender Kabeltyp verwendet werden: * Netzwerkkabel (CAT-5) mit situationsabhängiger Adaptierung Hinweis: Dies gilt für die Busunternehmen, die mit IBIS IP versorgt werden. Die Datenfernübertragung bei den anderen Busunternehmen muss via LTE-Modul im Validator erfolgen. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | Kabelanforderungen | 01-D-03-05 | Leitungen sind entsprechend den im Betrieb zu erwartenden mechanischen Belastungen bemessen, verlegt und abgestützt. Leitungen, die ständigen Verwindungen ausgesetzt sind, sind so flexibel und weisen ausreichend freie Länge auf, dass sie den Anforderungen dauerhaft (10 Jahre) genügen. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | IBIS-Wagenbus | 01-D-04-01 | Der mobile Validator wird als IBIS-Slave am vorhandenen IBIS-Wagenbus betrieben und übernimmt mit minimalen Zeitverzug (<1s) in mitlesender Funktion die auf dem IBIS-Wagenbus zur Verfügung stehenden Informationen, soweit sie für den Betrieb erforderlich sind. Hinweis: Dies gilt für die Firmen, die via IBIS Wagenbus die IBIS Daten vom Bordrechner erhalten. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | IBIS-Wagenbus | 01-D-04-02 | Es müssen verschiedene IBIS Sendetelegramme verarbeitet werden können: Razzia Statusabfrage Route Number Special Characters Run Number Destination Number Stopname Route Path Number Zone, min. Fare Customer specific Last Stop Point Time Date Car number Techn. Vehicle Number Stop / Extended Stop Range / Stop Index PositionCode / Odometer Stopname, Transfer Text, Special Text Stop Information Device | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | IBIS-Wagenbus | 01-D-04-03 | Der mobile Validator muss das Protokoll VDV 300 (IBIS-Wagenbus) unterstützen. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | IBIS-Wagenbus | 01-D-04-04 | Ist die Verbindung zum IBIS-Wagenbus unterbrochen oder der mobile Validator stromlos, werden Datum und Uhrzeit durch eine selbstlaufende Uhr fortgeführt. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | IBIS-IP | 01-D-05-01 | Der mobile Validator muss das Protokoll VDV 301-1 (IBIS-IP) unterstützen. | M | ||
| 1 | Mobiler Validator | Anbindung & Konnektivität | IBIS-IP | 01-D-05-02 | Bei IBIS-IP muss der mobile Validator als aktiver Teilnehmer in der Bordrechnersoftware implementiert werden. | M | ||
| 1 | Mobiler Validator | Energieversorgung | Überspannungsschutz | 01-E-01-01 | Ein Überspannungsschutz sowie ein Stromspitzenschutz müssen vorhanden sein und führen nicht zu einer Fehlfunktion oder zu gefährlichen Betriebszuständen bei den mobilen Validatoren und seinen Komponenten. Allenfalls schalten sich die mobilen Validatoren selbstständig ab. Der mobile Validator fährt nach Beseitigung der Störung (z. B. Wiederherstellung der Spannungsversorgung) wieder ordnungsgemäß in den Verkaufsmodus hoch. | M | ||
| 1 | Mobiler Validator | Energieversorgung | Nennleistung | 01-E-02-01 | Die Nennleistungsaufnahme ist max. 60 Watt. | M | ||
| 1 | Mobiler Validator | Energieversorgung | Spannungsversorgung | 01-E-03-01 | Die bestehende Spannungsversorgung beträgt 24 V Gleichspannung (+20%, -15%). | M | ||
| 1 | Mobiler Validator | Energieversorgung | Spannungsversorgung | 01-E-03-02 | Der mobile Validator ist für die in Fahrzeugen des ÖPNV auftretenden elektrischen Belastungen mit Schwankungen bis +36VDC Spikes ausgelegt. Ein Puffermodul dient zur kurzfristigen Spannungsversorgung des Validators bei Störungen der regulären Eingangsspannung. Bei einer Spannungsunterbrechung oder Absinken der Betriebsspannung unter den zulässigen Mindestwert übernimmt das Puffermodul die Energieversorgung bis ein evtl. eingeleiteter Verkaufsvorgang ordnungsgemäß abgeschlossen ist. Danach geht der mobile Validator „außer Betrieb“ bis die Spannung wieder in ausreichender Höhe vorhanden ist. Der mobile Validator geht wieder selbstständig in betriebsbereiten/verkaufsbereiten Zustand sobald erneut Spannung anliegt. Die Anforderungen für eletromagnetischer Verträglichkeit nach UN ECE R10 müssen sichergestellt werden. Die Anforderungen für Brennverhalten im Innenraum nach UN ECE R118 müssen sichergestellt werden. | M | ||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Grundplatte | 01-F-01-01 | Der mobile Validator muss mittels einer mitzuliefernden Validatorgrundplatte an einer vorhandenen Haltestange am Ein-/Ausstieg montierbar sein. | M |
[Seite 61]
| # | TEILLASTENHEFT | KATEGORIE | SUB-KATEGORIE | ID | ANFORDERUNGSBESCHREIBUNG | TYP ANFORDERUNG | |||
|---|---|---|---|---|---|---|---|---|---|
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Grundplatte | 01-F-01-02 | In die Grundplatte ist eine Codiermöglichkeit integriert, die ein Einstellen der Fahrzeugnummer und einer mindestens 2-stelligen weiteren Nummer (Validatorposition im Fahrzeug) gestattet. Der Tausch eines mobilen Validators von Fahrzeug zu Fahrzeug ist damit gewährleistet (Übernahme der neuen Fahrzeugnummer beim Wechsel). | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Grundplatte | 01-F-01-03 | Die Grundplatte des mobilen Validators wird im Fahrzeug fest verbaut. Für die Erstinstallation sind für die Zeit, in denen die Grundplatten schon verbaut sind, aber der Validator noch nicht produktiv in Betrieb genommen wurde bzw. noch nicht angebracht wurde, Abdeckplatten für die Grundplatte leihweise mitzuliefern. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Grundplatte | 01-F-01-04 | Die rückwärtige Fläche der Grundplatte muss mit einer Schutzverkleidung versehen sein. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Verschlusseinrichtung | 01-F-02-01 | Aus Sicherheitsgründen verfügt der mobile Validator über eine Verschlusseinrichtung an der Verbindung zur Grundplatte. Grundplatte und Schloss schützen den mobilen Validator wirksam gegen Diebstahl. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Verschlusseinrichtung | 01-F-02-02 | Das Schloss ist ohne Öffnen des mobilen Validators zugänglich. Der Schlüssel für die Verschlusseinrichtung sowie ein ggf. zum Öffnen des mobilen Validators vorgesehener Schlüssel sind identisch. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Verschlusseinrichtung | 01-F-02-03 | Der Schlüssel zum Öffnen des Geräts ist für alle mobilen Validatoren identisch. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | Mechanische Anforderungen | 01-F-03-01 | Die gesamte Befestigung muss so konstruiert sein, dass im Falle eines Unfalls weder das Gerät noch einzelne Teile aus der Halterung gerissen werden. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | (De-)montage | 01-F-04-01 | Die (De-)montage des mobilen Validators erfolgt ohne Spezialwerkzeug. | M | |||
| 1 | Mobiler Validator | Befestigungs- und montagerelevante Anforderungen | (De-)montage | 01-F-04-02 | Der mobile Validator ist ohne Abschalten der Stromversorgung des Fahrzeugs auswechselbar. Es muss eine unterbrechungsfreie Stromversorgung verbaut sein. | M | |||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Information | 01-G-Information | Der mobile Validator mit seinen Komponenten und Anschlussverbindungen erfüllen folgende Normen: | I | |||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | CE-Norm | 01-G-01-01 | Konformitätserklärung nach aktueller CE-Norm Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N |
[Seite 62]
| # | TEILLASTENHEFT | KATEGORIE | SUB-KATEGORIE | ID | ANFORDERUNGSBESCHREIBUNG | TYP ANFORDERUNG | ||
|---|---|---|---|---|---|---|---|---|
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Umgebungseinflüsse und klimatische Bedinungen | 01-G-02-01 | *DIN EN 60068-2-1 – Prüfung A: Kälte *DIN EN 60068-2-2 – Prüfung B: Trockene Wärme *DIN EN 60068-2-6 – Widerstandsfähigkeit gegen mechanischen Erschütterung *DIN EN 60068-2-27 – Prüfung von mechanischen Schockfestigkeit *DIN EN 60068-2-30 – Prüfung von Feuchtigkeitswechsel Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben sein. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Elektromagnetsiche Verträglichkeit | 01-G-03-01 | Der Validator und seine Komponenten müssen die Anforderungen der UN/ECE-Regelung Nr. 10, Revision 6 (06 series of amendments) erfüllen. Der Bieter legt den entsprechenden Nachweis dem Angebot bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Korrosionsschutz | 01-G-04-01 | Korrosionsfestigkeit nach DIN EN ISO 9227 Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Zuverlässigkeit | 01-G-05-01 | Zuverlässigkeit und Langlebigkeit durch die Gewährleistung von DIN EN 61709 Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Temperaturen | 01-G-06-01 | Der Validator mit seinen Komponenten und Anschlussverbindungen funktionieren bei einer Temperatur von -10 ° C - +55 °C ordnungsgemäß. Direkte Sonneneinstrahlung ist berücksichtigt. Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben. Die Funktionsfähigkeit muss bei einer Lagerungstemperatur von -10 °C - +55 °C sichergestellt sein. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Luftfeuchtigkeit | 01-G-07-01 | Der Validator mit seinen Komponenten und Anschlussverbindungen funktionieren bei einer relativen Luftfeuchtigkeit im Monatsmittel von 80%, gelegentlich bis zu 100% (DIN 50019). Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben. Bei einer relativen Luftfeuchte von 20 % - 85 % darf während des Betriebs keine Kondensation auftreten. Bei einer relativen Luftfeuchte von 3 % - 95 % darf während der Lagerung keine Kondensation auftreten. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Lackierung | 01-G-08-01 | Die Lackierung des mobilen Validators genügt dem Wert G1 nach DIN 53151. Alternativ kann das Kunststoffgehäuse des mobilen Validators auch durchgefärbt werden. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Vandalismus | 01-G-09-01 | Der mobile Validator besitzt ein bruchsicheres/schlagfestes PCAP TFT-Touch-Farbdisplay. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Vandalismus | 01-G-09-02 | Der mobile Validator besitzt ein bruchsicheres/schlagfestes Gehäuse. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Betriebssicherheit | 01-G-10-01 | Der angebotene mobile Validator erfüllt die Sicherheitsanforderungen für Audio-/Videogeräte sowie Informations- und Kommunikationstechnologie nach EN 62368-1. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Anschlussverbindungen | 01-G-11-01 | Der Anschluss aller Steuer- und Energieversorgungsleitungen wird über Anschlussverbindung(en) rüttel- und korrosionssicher hergestellt. Die elektrische Zuleitung ist so konstruiert, dass Wackelkontakte und Kurzschlüsse vermieden werden. Leitungsanschlüsse an elektrischen Betriebsmitteln sind so ausgeführt, dass sie sich durch die im Betrieb vorkommenden mechanischen Stoß- und Schwingungsbeanspruchungen nicht lockern. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Information | 01-G-12-Information | Die in den Bussen verwendeten Kabel müssen zusätzlich folgende Normen erfüllen: | I | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Kabel | 01-G-12-01 | - ISO 6722 | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Kabel | 01-G-12-02 | - ISO 19642 | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Brandschutz | 01-F-13-01 | Alle Komponenten müssen die Vorschrift UN ECE R118 zum Brandschutz im Innenraum von Fahrzeugen erfüllen. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Brandschutz | 01-G-13-02 | Für alle elektrische Bauteile (Validator, Kabel, Anschlussverbindungen) müssen die Brandschutzanforderungen für Schienenfahrzeuge gemäß DIN EN 45545-2 eingehalten werden. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Betriebserlaubnis Straßen- und Schienenverkehr | 01-G-14-01 | Der Validator sowie alle übrigen Geräte und Komponenten sind für den Einbau in im Straßenverkehr zugelassenen Fahrzeugen geeignet. Durch den Einbau des Validators und zugehöriger Komponenten wird die Funktionalität der Fahrzeuge in keiner Weise beeinträchtigt. Der Einbau führt nicht zum Erlöschen der Betriebserlaubnis. | M | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Betriebserlaubnis Straßen- und Schienenverkehr | 01-G-14-02 | Der mobile Validator verfügt über eine E1 Zulassung des Kraftfahrtbundesamts oder eine gleichwertige Zulassung. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 1 | Mobiler Validator | Normen, Richtlininen & Zertifizierungen | Schwingungs- und Stoßbeanspruchung | 01-G-15-01 | Der mobile Validator hält die Schwingungs- und Stoßbeanspruchungen nach DIN VDE 0115 ein. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Information | 02-00-Information | Das Teillastenheft 2 beschreibt die Anforderungen an den stationären Validator, inkl. QR Code Leseeinheit und 4G Modul mit integrierter Antenne. Alle stationären Validatoren werden mit einem cEMV UPOS Terminal bestellt. Der Bieter liefert 55 stationäre Validatoren. Alle stationären Validatoren werden sich im Freien befinden. | I | |||
| 2 | Stationärer Validator | Generelle Anforderung | Datenblätter | 02-A-01-01 | Für beide Ausbauvarianten (siehe Information 02-B-00-Information) sind technische Datenblätter inkl. Maße der Validatoren und Säulen/Winkelsäulen, Anschlüsse sowie deren Position, Gewichte und weitere Informationen zum Solarpanel beizulegen. | N | ||
| 2 | Stationärer Validator | Funktionalität | Anzeige | 02-B-01-01 | Am Startbildschirm muss die Check-In/Check-Out Funktion angezeigt werden. Mögliche weitere Tickets müssen über ein Untermenü erworben werden. Dazu ist die Anzeige der Ticketauswahl auf dem Display obligatorisch. Die umzusetzenden Tickets können XXX (Konzept VVMBestPreis) entnommen werden. | M | ||
| 2 | Stationärer Validator | Funktionalität | Guthabenanzeige Closed Loop EMV Karte | 02-B-02-01 | Der stationäre Validator muss die Funktion bieten den letzten aktuellen Guthabenbestand bei CheckIn (mit minimalem zeitlichem Verzug) der Closed Loop EMV Karte anzeigen zu lassen. | M | ||
| 2 | Stationärer Validator | Funktionalität | Optisches Signal | 02-B-03-01 | Der Fahrgast muss durch ein optisches Signal über den (Nicht-)Erfolg eines Taps informiert werden, wobei das optische Signal inviduell konfigurierbar sein muss. | M | ||
| 2 | Stationärer Validator | Funktionalität | Akustisches Signal | 02-B-04-01 | Der stationäre Validator muss ein akustisches Signal/Ton ausgegeben können, um über den (Nicht-)Erfolg eines Taps zu informieren, wobei das Signal/Ton inviduell konfigurierbar sein muss. | M | ||
| 2 | Stationärer Validator | Funktionalität | PKM | 02-B-05-01 | Der stationäre Validator muss PKM-konforme Kontrollmodule (nach Fraunhofer-IVI-Standard) verarbeiten können. Er muss die in den PKM-Modulen enthaltenen Regeln und Daten zur Ticketprüfung (z. B. Gültigkeit, räumliche und zeitliche Bedingungen, Produktmerkmale) interpretieren und anwenden können. Taps werden angereichert durch Transitdaten (Linie, Haltstelle, Fahrtweg, Zonenzuordnung, etc.) an das Hintergrundsystem und von dort an den Tarifrechner nach PKM gesendet. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Information | 02-C-Information | Es werden vom AG zwei Ausbauvarianten geplant. Ausbauvariante 1: Befestigung des stationären Validators mittels Winkelsäule am stationären Ticketautomaten und Stromversorgung über den stationären Ticketautomaten (17 stationäre Validatoren) Ausbauvariante 2: Befestigung des stationären Validators mittels Bodenbefestigung in einem Fundament im Erdreich und Stromversorgung über ein Solarpanel (38 stationäre Validatoren) | I | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Winkelsäule | 02-C-01-01 | Ausbauvariante 1: Es ist eine Befestigung über eine Winkelsäule aus gebürstetem Edelstahl am stationären Ticketautomaten vorzusehen. Die Winkelsäule ist vom Bieter bereitzustellen. Die Anbringung der Säule erfolgt durch die DB Vertrieb GmbH. Anbringung und Inbetriebnahme der Validatoren ist durch den Bieter durchzuführen. Die Säule muss über einen ausreichend großen Flansch verfügen, um die Befestigung an einem Beton- oder Stahlsockel so zu ermöglichen, sodass diese auch Vandalimuseinwirkung (Hebelwirkung der Säule) stand hält ohne den Sockel zu beschädigen. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Bodenbefestigung | 02-C-02-01 | Ausbauvariante 2: Der stationäre Validator muss einen Bodenbefestigung aus gebürstetem Edelstahl haben. Das Fundament stellt der AG zur Verfügung. Die Edelstahlsäule und das Solarpanel sowie der Akku sind vom Bieter anzubieten. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | cEMV UPOS Terminal | 02-C-03-01 | Im stationären Validator muss ein integriertes cEMV UPOS Terminal gemäß den Anforderungen des TLH 4 verbaut sein. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Mobilfunkmodul | 02-C-04-Information | SIM-Karten werden durch den AG beschafft, es wird ein entsprechender Vertrag durch den AG abgeschlossen. Eine Ausstattung mit eSIM ist vorzusehen. | I | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Mobilfunkmodul | 02-C-04-01 | Die Konnektivität der Geräte erfolgt ausschließlich über eSIM. Die eSIM wird durch den Auftraggeber (AG) bereitgestellt; der entsprechende Mobilfunkvertrag wird ebenfalls durch den AG abgeschlossen. Eine Ausstattung mit physischen SIM-Karten ist nicht vorgesehen. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Datenfernübertragung | 02-C-05-01 | Die Datenfernübertragung muss über ein 4G Modul (oder besser) via eSIM im Validator hergestellt werden. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Gehäuse | 02-C-06-01 | Das Gehäuse des stationären Validators besitzt keine Fugen, die größer als 1 mm sind. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Gehäuse | 02-C-06-02 | Der stationäre Validator muss in einem robusten, für den ÖPNV geeigneten Kunststoffgehäuse verbaut sein. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Geräte- und Seriennummer | 02-C-07-01 | Die Geräte- und die Seriennummer ist in Klarschrift und als Barcode auf dem Typenschild des stationären Validators dauerhaft anzubringen. Außerdem ist die Gerätenummer in der Speichereinheit im stationären Validator dauerhaft abzulegen. Sie bleibt während der gesamten Lebensdauer des Gerätes unveränderbar. Dies muss auch bei späteren Ergänzungslieferungen Berücksichtigung finden. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Gewicht | 02-C-08-01 | Das Maximalgewicht des stationären Validators darf 5 kg nicht überschreiten, wobei die Bodenbefestigung/Winkelsäule nicht in das Maximalgewicht einbezogen wird. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Größe | 02-C-09-01 | Die Abmessungen des stationären Validators inkl. Halteplatte, ohne Schutzverkleidung in Millimeter dürfen folgende Maße nicht überschreiten: 150 mm (Breite) X 330 mm (Höhe) X 100 mm (Tiefe). | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Höhe | 02-C-10-01 | Die bedienbaren Komponenten des stationären Validators müssen sich in einer Höhe zwischen 700 und 1200mm befinden. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-01 | Das Kundendisplay ist als ein vollgrafikfähiges hintergrundbeleuchtetes PCAP TFT-Touch-Farbdisplay vorgesehen. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-02 | Das PCAP TFT-Touch-Farbdisplay ist im Gehäuse des Geräts so zu integrieren, dass auch unter schlechten Lichtverhältnissen sowie bei Sonneneinstrahlung die Lesbarkeit für den Kunden gewährleistet ist. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-03 | Das PCAP TFT-Touch-Farbdisplay passt die Helligkeit automatisch der Umgebung an. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-04 | Der PCAP TFT-Touch-Farbdisplay beugt Spiegelungen vor. Hierfür darf keine Folie verwendet werden. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-05 | Das PCAP TFT-Touch-Farbdisplay hat eine Größe von mind. 5 Zoll (Bildschirmdiagonale) und eine Auflösung von 640*480 Pixel (VGA) oder besser. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-06 | Das PCAP TFT-Touch-Farbdisplay muss im Hochformat verbaut sein. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-07 | Der Ablesewinkel des PCAP TFT-Touch-Farbdisplay beträgt sowohl horizontal als auch vertikal 150 - 170 Grad (gemessen von der Mittelachse), sodass der Bildschirminhalt aus jeder Sichtposition des Kunden abgelesen werden kann. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kundendisplay | 02-C-11-08 | Die Innenseite des PCAP TFT-Touch-Farbdisplay darf nicht anlaufen oder verschmutzen. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Konfiguration GUI | 02-C-13-01 | Tastenkombinationen oder Bedienhandlungen durch unberechtigtes Personal, die einen Wechsel auf Betriebssystemebene auslösen können, sind nicht möglich. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Kühlung | 02-C-14-01 | Gegebenenfalls während des Betriebes innerhalb des Gehäuses entstehende Eigenwärme darf die Funktionalität der Baugruppen nicht beeinträchtigen. Eine aktive Kühlung (z. B. durch einen Lüfter) ist unzulässig. | M | ||
| 2 | Stationärer Validator | Hardware Anforderungen | Lackierung | 02-C-15-01 | Der stationäre Validator muss in der Farbe RAL XXXX geliefert werden. | M | ||
| 2 | Stationärer Validator | Energieversorgung | Spannungsversorgung | 02-D-01-01 | Die bestehende Spannungsversorgung beträgt 24 V Gleichspannung (+20%, -15%). Es ist ein Netzteil in Schutzklasse II mitzuliefern, welches je nach Befestigungart im Ticketautomaten (Ausbauvariante 1) oder im Sockel (Ausbauvariante 2) eingebaut wird. | M | ||
| 2 | Stationärer Validator | Energieversorgung | Spannungsversorgung | 02-D-01-02 | Im Falle eines direkten Anschlusses an die 230V Versogungsspannung ist ein allpoliger FI-LS-Schalter vereinigen Fehlerstrom-Schutzeinrichtung und Leitungsschutzschalter vorzusehen. Der Anschlusspunkt sowie der FI/LS mus über eine Revsionsklappe von außen zugänglich sein. | M | ||
| 2 | Stationärer Validator | Stromverbrauch | Stromverbrauch | 02-D-02-01 | Der stationäre Validator muss nach einer vom AG definierten Zeit automatisch in einen energiesparenden Ruhemodus wechseln. Der Bieter gibt den voraussichtlichen Stromverbrauch eines stationären Validators in der Spalte "Bemerkung" an (Annahme: 24/7 Betrieb). | M | ||
| 2 | Stationärer Validator | Energieversorgung | Nennleistung | 02-D-03-01 | Die Nennleistungsaufnahme ist max. 60 Watt. | M | ||
| 2 | Stationärer Validator | Energieversorgung | Überspannungsschutz | 02-D-04-01 | Ein Überspannungsschutz sowie ein Stromspitzenschutz müssen vorhanden sein und führen nicht zu einer Fehlfunktion oder zu gefährlichen Betriebszuständen bei den stationären Validatoren und seinen Komponenten. Allenfalls schalten sich die stationären Validatoren selbstständig ab. Der Validator fährt nach Beseitigung der Störung (z. B. Wiederherstellung der Spannungsversorgung) wieder ordnungsgemäß in den Verkaufsmodus hoch. | M | ||
| 2 | Stationärer Validator | Befestigungs- und montagerelevante Anforderungen | Verschlusseinrichtung | 02-E-01-01 | Der Schlüssel zum Öffnen des Geräts ist für alle stationären Validatoren identisch. | M | ||
| 2 | Stationärer Validator | Befestigungs- und montagerelevante Anforderungen | Verschlusseinrichtung | 02-E-01-02 | Das Schloss ist ohne Öffnen des stationären Validators zugänglich. Der Schlüssel für die Verschlusseinrichtung sowie ein ggf. zum Öffnen des Validators vorgesehener Schlüssel sind identisch. | M | ||
| 2 | Stationärer Validator | Befestigungs- und montagerelevante Anforderungen | Grundplatte | 02-E-02-01 | Der stationäre Validator muss mittels einer mitzuliefernden Validatorgrundplatte an der Säule/Winkelsäule befestigt werden. Für die Erstinstallation sind für die Zeit, in denen die Grundplatten schon verbaut sind, aber der Validator noch nicht produktiv in Betrieb genommen wurde bzw. noch nicht angebracht wurde, Abdeckplatten für die Grundplatte leihweise mitzuliefern. | M | ||
| 2 | Stationärer Validator | Befestigungs- und montagerelevante Anforderungen | Grundplatte | 02-E-02-02 | Die rückwärtige Fläche der Grundplatte muss mit einer witterungsbeständigen Schutzverkleidung versehen sein. | M | ||
| 2 | Stationärer Validator | Befestigungs- und montagerelevante Anforderungen | Mechanische Anforderungen | 02-E-03-01 | Die gesamte Befestigung muss so konstruiert sein, dass im Falle von staker Krafteintwirkung weder das Gerät noch einzelne Teile aus der Halterung gerissen werden. | M | ||
| 2 | Stationärer Validator | Befestigungs- und montagerelevante Anforderungen | (De-)montage | 02-E-04-01 | Die (De-)montage erfolgt ohne Spezialwerkzeug. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Information | 02-F-Information | Der stationäre Validator mit seinen Komponenten und Anschlussverbindungen erfüllen folgende Normen: | I | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | CE-Norm | 02-F-01-01 | Konformitätserklärung nach aktueller CE-Norm Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Schutzklasse | 02-F-02-01 | Der stationäre Validator muss gemäß Schutzklasse II (DIN EN 61140) ausgeführt werden. Die Kennzeichnung muss mit der CE-Kennzeichnung sichtbar am stationären Validator angebracht werden. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Umgebungseinflüsse und klimatische Bedinungen | 02-F-03-01 | *DIN EN 60068-2-1 – Prüfung A: Kälte *DIN EN 60068-2-2 – Prüfung B: Trockene Wärme *DIN EN 60068-2-6 – Widerstandsfähigkeit gegen mechanischen Erschütterung *DIN EN 60068-2-27 – Prüfung von mechanischen Schockfestigkeit *DIN EN 60068-2-30 – Prüfung von Feuchtigkeitswechsel Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben sein. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Aufbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Elektromagnetsiche Verträglichkeit | 02-F-04-01 | *DIN EN 61000-4-2 Elektromagnetische Verträglichkeit – Elektrostatische Entladung – Prüfung der Störfestigkeit *DIN EN 61000-4-3 Elektromagnetische Verträglichkeit – Hochfrequente elektromagnetische Strahlungsfelder – Prüfung der Störfestigkeit *DIN EN 61000-4-4 Elektromagnetische Verträglichkeit – Schnelle transiente elektrische Störgröβen/Burst – Prüfung der Störfestigkeit *DIN EN 61000-4-5 Elektromagnetische Verträglichkeit – Prüfung der Störfestigkeit gegen Stoßspannungen (Surge) *DIN EN 61000-4-6 Elektromagnetische Verträglichkeit – Störfestigkeit gegen leitungsgeführte Störgröβen, induziert durch hochfrequente Felder *DIN EN 55032 Ed.3 Elektromagnetische Verträglichkeit von Multimediageräten – Anforderungen an die Störaussendung Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Aufbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Korrosionsschutz | 02-F-05-01 | Korrosionsfestigkeit nach DIN EN ISO 9227 Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Aufbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Zuverlässigkeit | 02-F-06-01 | Zuverlässigkeit und Langlebigkeit durch die Gewährleistung von DIN EN 61709 Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Aufbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Temperaturen | 02-F-07-01 | Der stationäre Validator mit seinen Komponenten und Anschlussverbindungen funktionieren bei einer Temperatur von -20°C - +55°C ordnungsgemäß. Direkte Sonneneinstrahlung ist berücksichtigt. Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben. Die Funktionsfähigkeit muss bei einer Lagerungstemperatur von -20°C - +55°C sichergestellt sein. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Luftfeuchtigkeit | 02-F-08-01 | Der stationäre Validator mit seinen Komponenten und Anschlussverbindungen funktionieren bei einer relativen Luftfeuchtigkeit im Monatsmittel von 80%, gelegentlich bis zu 100% (DIN 50019). Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben. Bei einer relativen Luftfeuchte von 20% - 85% darf während des Betriebs keine Kondensation auftreten. Bei einer relativen Luftfeuchte von 3% - 95% darf während der Lagerung keine Kondensation auftreten. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Lackierung | 02-F-09-01 | Die Lackierung des stationären Validators genügt dem Wert G1 nach DIN 53151. Alternativ kann das Kunststoffgehäuse des Validators auch durchgefärbt werden. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Vandalismus | 02-F-10-01 | Der stationäre Validator besitzt ein bruchsicheres/schlagfestes Display. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Vandalismus | 02-F-10-02 | Der stationäre Validator besitzt ein bruchsicheres/schlagfestes Gehäuse. | M | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Betriebssicherheit | 02-F-11-01 | Der angebotene mobile Validator erfüllt die Sicherheitsanforderungen für Audio-/Videogeräte sowie Informations- und Kommunikationstechnologie nach EN 62368-1. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Aufbaus von Hardware anzufordern. | N | ||
| 2 | Stationärer Validator | Normen, Richtlininen & Zertifizierungen | Anschlussverbindungen | 02-F-12-01 | Der Anschluss aller Steuer- und Energieversorgungsleitungen wird über Anschlussverbindung(en) rüttel- und korrosionssicher hergestellt. Die elektrische Zuleitung ist so konstruiert, dass Wackelkontakte und Kurzschlüsse vermieden werden. | M | ||
| 2 | Stationärer Validator | Solarpanel | Information | 02-G-Information | Es muss eine Lösung zur autarken Stromversorgung über Solarpanels angeboten werden, um den Betrieb der stationären Validatoren unabhängig vom Stromnetz zu ermöglichen. | I | ||
| 2 | Stationärer Validator | Solarpanel | Allgemeine Anforderungen | 02-G-01-01 | Das Solarpanelsystem muss eine zuverlässige, autarke Energieversorgung für stationäre Validatoren im Außenbereich sicherstellen. Die konkreten Standorte werden im Projektverlauf festgelegt. Es handelt sich um unbeschattete, nicht überdachte Standorte am Bahnsteig oder im Zugangsbereich zu den Bahnhöfen. | M | ||
| 2 | Stationärer Validator | Solarpanel | Allgemeine Anforderungen | 02-G-01-02 | Der Betrieb muss ganzjährig gewährleistet sein – auch bei geringer Sonneneinstrahlung und in kritischen Klimabedingungen. | M | ||
| 2 | Stationärer Validator | Solarpanel | Allgemeine Anforderungen | 02-G-01-03 | Das Gesamtsystem muss modular, wartungsarm und vandalismussicher ausgeführt sein. | M | ||
| 2 | Stationärer Validator | Solarpanel | Leistungsanforderungen | 02-G-02-01 | Die installierte Photovoltaikleistung (Wp) pro Validator muss so ausgelegt sein, dass mindestens 120 % des durchschnittlichen Tagesenergiebedarfs des Validators erzeugt werden. | M | ||
| 2 | Stationärer Validator | Solarpanel | Leistungsanforderungen | 02-G-02-02 | Die Panels müssen in Kombination mit einem Batteriespeicher mindestens 72 Stunden Autarkie bei voller Funktionsfähigkeit des Validators ermöglichen. | M | ||
| 2 | Stationärer Validator | Solarpanel | Leistungsanforderungen | 02-G-02-03 | Die Panels müssen in Kombination mit einem Batteriespeicher zwischen 72 und 120 Stunden Autarkie bei voller Funktionsfähigkeit des Validators ermöglichen. Dabei kann zugrunde gelegt werden, dass der Validator insbesondere in Nachtzeiten/ außerhalb der Betriebszeiten und/oder bei längerer Inaktivität selbsttätig in einen Ruhemodus schalten kann und jederzeit durch den Fahrgast wieder aktiviert werden kann. Die jeweiligen Zeitintervalle müssen konfigurierbar sein. | M | ||
| 2 | Stationärer Validator | Solarpanel | Leistungsanforderungen | 02-G-02-04 | Die Energieversorgung muss auch bei diffusem Licht (z. B. Bewölkung, Nebel) ausreichend stabil sein. | M | ||
| 2 | Stationärer Validator | Solarpanel | Anforderungen an die Solarmodule | 02-G-03-01 | Die Module müssen zertifiziert sein nach IEC 61215 (Design Qualification). | M | ||
| 2 | Stationärer Validator | Solarpanel | Anforderungen an die Solarmodule | 02-G-03-02 | Die Module müssen zertifiziert sein nach IEC 61730 (Sicherheitszertifizierung). | M | ||
| 2 | Stationärer Validator | Solarpanel | Anforderungen an die Solarmodule | 02-G-03-03 | Die Frontseite muss gehärtetes, reflektionsarmes Glas aufweisen. | M | ||
| 2 | Stationärer Validator | Solarpanel | Anforderungen an die Solarmodule | 02-G-03-04 | Die Module müssen eine Lebensdauer von mindestens 10 Jahren garantieren (Leistungsabfall max. 20 % über 10 Jahre). | M | ||
| 2 | Stationärer Validator | Solarpanel | mechanische Ausführung und Montage | 02-G-04-01 | Die Halterung muss korrosionsbeständig und witterungsfest sein (Material: Edelstahl oder eloxiertes Aluminium). | M | ||
| 2 | Stationärer Validator | Solarpanel | mechanische Ausführung und Montage | 02-G-04-02 | Die Konstruktion muss Windlasten bis mindestens 120 km/h und Schneelasten entsprechend DIN EN 1991-1-3/4 standhalten. | M | ||
| 2 | Stationärer Validator | Solarpanel | mechanische Ausführung und Montage | 02-G-04-03 | Die Module dürfen durch Vandalismus nicht zerstörbar oder leicht demontierbar sein (z. B. verschraubt mit Spezialköpfen, ESG-Glas). | M | ||
| 2 | Stationärer Validator | Solarpanel | Batteriesystem | 02-G-05-01 | Das Batteriesystem muss mindestens 72 Stunden Pufferspeicher bei Volllast des stationären Validators bieten. Der Batteriespeicher wird nicht in die Größen- und Gewichtsvorgaben des Validators eingerechnet und kann separat an der mit anzubietenden Säule installiert werden. | M | ||
| 2 | Stationärer Validator | Solarpanel | Batteriesystem | 02-G-05-02 | Einsatzbereich: -20 °C bis +60 °C (mit integriertem Temperaturmanagement). | M | ||
| 2 | Stationärer Validator | Solarpanel | Batteriesystem | 02-G-05-03 | Die Batterien müssen über ein intelligentes BMS (Battery Management System) mit Schutz vor Tiefentladung, Überladung und Kurzschluss verfügen. | M | ||
| 2 | Stationärer Validator | Solarpanel | Batteriesystem | 02-G-05-04 | Gehäuse: Schutzart mindestens IP65, UV-beständig. | M | ||
| 2 | Stationärer Validator | Solarpanel | Energiemanagementsystem | 02-G-06-01 | Ein MPPT-Laderegler (Maximum Power Point Tracking) ist zu verwenden. | M | ||
| 2 | Stationärer Validator | Solarpanel | Energiemanagementsystem | 02-G-06-02 | Die Energieverteilung zwischen Panel, Batterie und Verbraucher muss automatisch geregelt werden. | M | ||
| 2 | Stationärer Validator | Solarpanel | Energiemanagementsystem | 02-G-06-03 | Fernwartungsfähigkeit über Mobilfunknetz (GSM/LTE) zur Überwachung von Ladezustand, Temperatur, Fehlerstatus muss gewährleistet werden. | M | ||
| 3 | Tragbarer Validator | Information | 03-00-Information | Das Teillastenheft 3 beschreibt die Anforderungen an einen tragbaren Validator, der im On-Demand-Angebot "Flexibus" des AG zum Einsatz kommt. Als tragbarer Validator werden tragbare Kartenlesegeräte auf Android- Basis mit 2D/3D- sowie NFC-Schnittstelle, sowie aktuellen EMV L1, L2 sowie PCI Zertifizierungen verstanden. Es müssen 30 tragbare Validatoren angeboten werden. | I | |||
| 3 | Tragbarer Validator | Generelle Anforderungen | Datenblatt | 03-A-01-01 | Ein aussagekräftiges technisches Datenblatt ist beizulegen. | N | ||
| 3 | Tragbarer Validator | Generelle Anforderungen | Nutzungszeitraum | 03-A-02-01 | Der Bieter stellt sicher, dass die im Projekt eingesetzten 'Tragbaren Validatoren' während der gesamten Vertragslaufzeit von mindestens 10 Jahren durchgängig funktionsfähig einsatzbereit bleiben. Dies umfasst insbesondere: - sichere Verfügbarkeit von Ersatzgeräten oder eines kompatiblen Nachfolgemodells, - ein belastbares Reparatur- und Wartungskonzept, - die fortlaufende Versorgung mit notwendigen sicherheits- und zertifizierungrelevanten (z. B. EMVCo, PCI, Betriebssystem), sowie funktionalen Updates. - sowie die Gewährleistung der vollständigen Systemkompatibilität im Projektkontext. Der Bieter erläutert in Spalte "Bemerkung" detailliert, durch welche technischen und organisatorischen Maßnahmen diese Nutzbarkeit über 10 Jahre gewährleistet wird. | M | ||
| 3 | Tragbarer Validator | Funktionalität | Speicherkapazität | 03-B-01-01 | Der tragbare Validator muss mindestens 2 GB RAM Speicher umfassen. | M | ||
| 3 | Tragbarer Validator | Funktionalität | Speicherkapazität | 03-B-01-02 | Der tragbare Validator muss mindestens 16 GB Flash-Speicher umfassen. | M | ||
| 3 | Tragbarer Validator | Funktionalität | Speicherkapazität | 03-B-01-03 | Als externer Speicher muss eine Micro SD Karte in einem Mico SD Kartenslot eingeführt werden können. | M | ||
| 3 | Tragbarer Validator | Funktionalität | Anzeige | 03-B-02-01 | Am Startbildschirm muss die Check-In/Check-Out Funktion angezeigt werden. Mögliche weitere Tickets müssen über ein Untermenü erworben werden. Dazu ist die Anzeige der Ticketauswahl auf dem Display obligatorisch. Die umzusetzenden Tickets können XXX (Konzept VVMBestPreis) entnommen werden. | M | ||
| 3 | Tragbarer Validator | Funktionalität | Optisches Signal | 03-B-03-01 | Der Fahrgast muss durch ein optisches Signal über den (Nicht-)Erfolg des Taps informiert werden. | M | ||
| 3 | Tragbarer Validator | Funktionalität | Akustisches Signal | 03-B-04-01 | Der Validator muss ein akustisches Signal/Ton ausgegeben können, um über den (Nicht-)Erfolg des Taps zu informieren. | M | ||
| 3 | Tragbarer Validator | Betriebssystem | Allgemeine Anforderung | 03-C-01-01 | Der tragbare Validator muss mind. Android 10 als Betriebssystem aufgespielt haben. | M | ||
| 3 | Tragbarer Validator | Datenerfassung | PKM | 03-D-01-01 | Der Validator muss PKM-konforme Kontrollmodule (nach Fraunhofer-IVI-Standard) verarbeiten können. Er muss die in den PKM-Modulen enthaltenen Regeln und Daten zur Ticketprüfung (z. B. Gültigkeit, räumliche und zeitliche Bedingungen, Produktmerkmale) interpretieren und anwenden können. Taps werden angereichert durch Transitdaten (Linie, Haltstelle, Fahrtweg, Zonenzuordnung, etc.) an das Hintergrundsystem und von dort an den Tarifrechner nach PKM gesendet. | M | ||
| 3 | Tragbarer Validator | Datenerfassung | Geopositionierung | 03-D-02-01 | Der tragbare Validator muss über ein integriertes GNSS-Modul (Global Navigation Satellite System) verfügen. | M | ||
| 3 | Tragbarer Validator | Datenerfassung | Geopositionierung | 03-D-02-02 | Es muss mindestens GPS unterstützt werden. | M | ||
| 3 | Tragbarer Validator | Datenerfassung | Geopositionierung | 03-D-02-03 | Der tragbare Validator muss Assisted-GPS (A-GPS) zur beschleunigten Standortbestimmung bei schwachem Satellitensignal unterstützen. | M | ||
| 3 | Tragbarer Validator | Datenerfassung | Geopositionierung | 03-D-02-04 | Die Positionsbestimmung muss eine Genauigkeit von mindestens <5 Metern unter freiem Himmel ermöglichen. | M | ||
| 3 | Tragbarer Validator | Datenerfassung | Geopositionierung | 03-D-02-05 | Die erste Standortbestimmung nach Kaltstart darf maximal 60 Sekunden dauern (unter normalen Umgebungsbedingungen). | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Gehäuse | 03-E-01-01 | Der tragbare Validator muss in einem robusten, für den ÖPNV geeigneten Kunststoffgehäuse verbaut sein. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Geräte- und Seriennummer | 03-E-02-01 | Die Geräte- und die Seriennummer ist in Klarschrift und als Barcode auf dem Typenschild des tragbaren Validators dauerhaft anzubringen. Außerdem ist die Gerätenummer in der Speichereinheit im Validator dauerhaft abzulegen. Sie bleibt während der gesamten Lebensdauer des Gerätes unveränderbar. Dies muss auch bei späteren Ergänzungslieferungen Berücksichtigung finden. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Gewicht | 03-E-03-01 | Das Maximalgewicht des Validators darf 0,5 kg nicht überschreiten. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Größe | 03-E-04-01 | Die Abmessungen des tragbaren Validators in Millimeter dürfen folgende Maße nicht überschreiten: 200 mm (Breite) X 100 mm (Höhe) X 100 mm (Tiefe). | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-01 | Das Display ist als ein vollgrafikfähiges hintergrundbeleuchtetes CAP TFT-Touch-Farbdisplay vorgesehen. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-02 | Das CAP TFT-Touch-Farbdisplay ist im Gehäuse des Geräts so zu integrieren, dass auch unter schlechten Lichtverhältnissen sowie bei Sonneneinstrahlung die Lesbarkeit gewährleistet ist. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-03 | Das CAP TFT-Touch-Farbdisplay passt die Helligkeit automatisch der Umgebung an. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-04 | Der PCAP TFT-Touch-Farbdisplay beugt Spiegelungen vor. Hierfür darf keine Folie verwendet werden. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-05 | Das CAP TFT-Touch-Farbdisplay hat eine Größe von mind. 5 Zoll (Bildschirmdiagonale) und eine Auflösung von 1280*720 Pixel oder besser. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-06 | Das CAP TFT-Touch-Farbdisplay muss im Hochformat verbaut sein. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kundendisplay | 03-E-05-07 | Die Innenseite des CAP TFT-Touch-Farbdisplays darf nicht anlaufen oder verschmutzen. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Konfiguration GUI | 03-E-06-01 | Tastenkombinationen oder Bedienhandlungen durch unberechtigtes Personal, die einen Wechsel auf Betriebssystemebene auslösen können, sind nicht möglich. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | Kartenakzeptanz | 03-E-07-01 | EMV-Kartenlesung – Unterstützung von EMV-Contactless (NFC): Das Gerät muss in der Lage sein, Zahlungskarten gemäß EMV-Standard zu lesen und Transaktionen zuverlässig durchzuführen. Folgende Verfahren sind zu unterstützen: - Kontaktloses Bezahlen (EMV Contactless / NFC): Unterstützung für kontaktlose Zahlungen gemäß EMVCo Contactless Specification, insbesondere für Kartentransaktionen per NFC-fähiger Bankkarte oder Smartphone/Smartwatch (z. B. Apple Pay, Google Pay). Das Gerät muss in der Lage sein, kontaktlose EMV-Transaktionen gemäß den Anforderungen der Zahlungsnetzwerke (z. B. Mastercard, Visa) durchzuführen. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | NFC-Leseeinheit | 03-E-08-01 | Das kontaktlose NFC-Lesegerät muss ISO / IEC 14443 Type A / B unterstützen. Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | SAM | 03-E-09-01 | Der tragbare Validator muss über mindestens 2 SAM-Steckplätze verfügen. | M | ||
| 3 | Tragbarer Validator | Hardware Anforderungen | cEMV UPOS Terminal | 02-F-10-01 | Im tragbaren Validator muss ein integriertes cEMV UPOS Terminal gemäß den Anforderungen des TLH 4 verbaut sein. | M | ||
| 3 | Tragbarer Validator | Anbindung & Konnektivität | Mobilfunkmodul | 03-F-11-Information | Die Konnektivität der Geräte erfolgt über eine SIM-Karte oder eSIM. Diese wird durch den Auftraggeber (AG) bereitgestellt; der entsprechende Mobilfunkvertrag wird ebenfalls durch den AG abgeschlossen. | I | ||
| 3 | Tragbarer Validator | Anbindung & Konnektivität | Mobilfunkmodul | 03-F-11-01 | Die tragbaren Validatoren müssen zur Datenfernübertragung mit einem 4G/LTE Modul oder besser ausgestattet sein. Der Bieter gibt die voraussichtliche Datenmenge pro Tap und Systemupdates, Listenmanagement getrennt voneinander in der Spalte "Bemerkung" an. | M | ||
| 3 | Tragbarer Validator | Anbindung & Konnektivität | Datenfernübertragung | 03-F-12-01 | Die Datenfernübertragung muss über ein 4G Modul (oder besser) via Sim-Karte im Validator hergestellt werden. | M | ||
| 3 | Tragbarer Validator | Anbindung & Konnektivität | Datenfernübertragung | 03-F-12-02 | Zur Herstellung der Datenfernübertragung sind zwei Wege vorgesehen: 1. Via mind. 4G Modul mit Sim-Karte im tragbaren Validator 2. W-LAN nach aktuellem Standard Der Bieter ist verpflichtet, beide Varianten für den tragbaren Validator zur Verfügung zu stellen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Allgemeine Anforderung | 03-G-01-01 | Der tragbare Validator muss über eine integrierte, wiederaufladbare Batterien, z. B. Lithium-Ionen, verfügen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Laufzeit | 03-G-02-01 | Der tragbare Validator muss mit einer Akkuladung mindestens 8 Stunden Dauerbetrieb ermöglichen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Ladezeit | 03-G-03-01 | Die vollständige Aufladung darf maximal 4 Stunden dauern. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Sicherheitsfunktion | 03-G-04-01 | Der Akku muss über integrierten Schutz vor Überladung verfügen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Sicherheitsfunktion | 03-G-04-02 | Der Akku muss über integrierten Schutz vor Tiefentladung verfügen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Sicherheitsfunktion | 03-G-04-03 | Der Akku muss über integrierten Schutz vor Kurzschluss verfügen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Sicherheitsfunktion | 03-G-04-04 | Der Akku muss über integrierten Schutz vor Überhitzung verfügen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Akkutausch | 03-G-05-01 | Der Akku muss werkzeuglos austauschbar sein oder durch autorisiertes Personal ersetzt werden können. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Lebensdauer | 03-G-06-01 | Der Akku muss mindestens 500 Ladezyklen ohne wesentlichen Kapazitätsverlust (<20 %) überstehen. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Ladegerät | 03-G-07-01 | Zum Betrieb und zur Aufladung des tragbaren Validatos ist ein geeignetes Ladegerät (Netzteil) mitzuliefern. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Ladegerät | 03-G-07-02 | Das Ladegerät muss für den dauerhaften Einsatz im professionellen Umfeld ausgelegt sein und eine sichere, stabile Energieversorgung gemäß den Anforderungen des Herstellers gewährleisten. | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Ladegerät | 03-G-07-03 | Die Netzspannung muss 100–240 V AC unterstützen (automatische Spannungsanpassung), mit einem Ausgangsstrom passend zum Gerät (z. B. 5V/2A oder gemäß Spezifikation des Geräts). | M | ||
| 3 | Tragbarer Validator | Energieversorgung | Ladegerät | 03-G-07-04 | Das Netzteil muss über ein ausreichend langes Anschlusskabel (mind. 1,5 m) verfügen und CE-konform sein. | M | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | Kartenorganisationen | 03-H-01-01 | Alle hard- und softwarebezogenen Vorgaben sowie jeweils aktuellen Richtlinien und Zertifizierungsvorgaben der Kreditkartenorganisationen sind zu berücksichtigen. Der Bieter legt die entsprechenden Nachweise für alle betroffenen, notwendigen und aktuellen Zulassungen und Zertifizierungen der Kreditkartenorganisationen für den tragbaren Validator bei. Eigenerklärungen werden nicht akzeptiert. | N | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | EMV-Zertifizierung | 03-H-02-01 | Es müssen alle zum Zeitpunkt der Angebotsabgabge aktuellen Anforderungen der EMV-Zertifizierungslevel L2 für Visa und Mastercard Kernel eingehalten werden. | M | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | EMV-Zertifizierung | 03-H-02-02 | Es müssen alle zum Zeitpunkt der Angebotsabgabge aktuellen Anforderungen der EMV-Zertifizierungslevel L2 für Amex, Discover, JCB und UPI/CUP Kernel eingehalten werden. Der Bieter beschreibt mögliche Abweichungen in der Spalte Bemerkung. Für jede einzelne bestätigte Verfügbarkeit erhält der Bieter 1 Punkt. Es sind also insgesamt 4 Punkte für diese Anforderung zu erreichen. | S | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | NFC-Leseeinheit | 03-H-03-01 | Das kontaktlose NFC-Lesegerät muss EMV Contactless L1 v3.0 zertifiziert sein. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt der Inbetriebnahme der ersten Geräte zum Produktivtest anzufordern. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | CE-Norm | 03-H-04-01 | Der tragbare Validator mit seinen Komponenten und Anschlussverbindungen erfüllt die Konformitätserklärung nach aktueller CE-Norm. Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. Für den Fall, dass der Zuschlag beabsichtigt ist, behält sich der AG vor, die entsprechenden Zertifikate einzufordern. | N | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | Temperaturen | 03-H-05-01 | Der tragbare Validator mit seinen Komponenten und Anschlussverbindungen funktionieren bei einer Temperatur von -10 °C - +50 °C ordnungsgemäß. Direkte Sonneneinstrahlung ist berücksichtigt. Bei den angegebenen Grenzwerten ist jederzeit eine einwandfreie Funktion gegeben. Die Funktionsfähigkeit muss bei einer Lagerungstemperatur von -20 °C - +70 °C sichergestellt sein. | M | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | Luftfeuchtigkeit | 03-H-06-01 | Bei einer relativen Luftfeuchte von 10 % - 90 % darf während des Betriebs und bei Lagerung keine Kondensation auftreten. | M | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | PCI-PTS | 03-H-07-01 | Der tragbare Validator muss mindestens eine aktuelle PCI-PTS 6.x Zertifizierung besitzen. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | Vandalismus | 03-H-08-01 | Stoßfestigkeit gemäß EN/IEC 62262: Das mobile Fahrscheinkontrollgerät muss eine Stoßfestigkeit nach Schutzgrad IK04 aufweisen. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | Vandalismus | 03-H-08-02 | Schutz gegen Fremdkörper gemäß EN/IEC 60529: Das mobile Fahrscheinkontrollgerät muss mindestens den Schutzgrad IP30 erfüllen. Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. Für den Fall, dass der Zuschlag beabsichtigt ist, behält sich der AG vor, die entsprechenden Zertifikate einzufordern. | N | ||
| 3 | Tragbarer Validator | Normen, Richtlininen & Zertifizierungen | Falltest | 03-H-09-01 | Falltest: Der tragbare Validator muss Falltests gemäß IEC 60068-2-31 bestehen bzw. diese Anforderung erfüllen. Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. Für den Fall, dass der Zuschlag beabsichtigt ist, behält sich der AG vor, die entsprechenden Zertifikate einzufordern. | N | ||
| 4 | cEMV UPOS Terminal | Information | 04-00-Information | Das Teillastenheft 4 beschreibt die Anforderungen an das cEMV UPOS Terminal, das in den mobilen (TLH 1) und stationären Validatoren (TLH 2) verbaut wird. | I | |||
| 4 | cEMV UPOS Terminal | Unterstützung IDBT- Funktionalität | Funktionalität | 04-A-01-01 | Das cEMV UPOS Terminal muss die spezifischen Transaktionstypen KFT (Known Fare Transaction)/Retail-like und MTT (Mobility and Transport Transaction)/PAYG (Pay-As-You-Go) der Kartenorganisationen für Transittransaktionen unterstützen. | M | ||
| 4 | cEMV UPOS Terminal | Unterstützung IDBT- Funktionalität | Funktionalität | 04-A-01-02 | Die Verarbeitung von EMV-Bankkarten muss die Annahme, Prüfung und Belastung folgender bargeldloser Zahlungsmittel gewährleisten: -Kontaktlose (NFC) Debit- und Kreditkarten mit EMV Chip mindestens der Kartenorganisationen MasterCard und Visa - NFC Wallets/Consumer Devices (CD) (z. B. Google Wallet, Apple Pay) - Kontaktlose (NFC) Prepaidkarten mit EMV Chip (sog. Closed Loop EMV) | M | ||
| 4 | cEMV UPOS Terminal | Generelle Anforderung | Tap Geschwindigkeit | 04-B-01-01 | Das cEMV UPOS Terminal darf gemeinsam mit der Terminalapplikation des Transit PSP (TLH 7) pro Tap zwischen Erkennen der EMV Karte und dem Abschluss der Verarbeitung der EMV Karte in der Teminalapplikation nicht länger als 700ms benötigen. | M | ||
| 4 | cEMV UPOS Terminal | Terminalapplikation | Transit PSP Terminalapplikation | 04-C-01-01 | Das cEMV UPOS Terminal ist mit der entsprechenden Terminalapplikation zu liefern, die die Verbindung zum Transit PSP gewährleistet. | M | ||
| 4 | cEMV UPOS Terminal | Schnittstellen und Protokolle | Protokoll Terminal - Validator | 04-D-01-01 | Der Bieter muss sicherstellen, dass cEMV UPOS Terminal und Validator sicher miteinander kommunizieren und Transit Daten austauschen können ("Kassenschnittstelle"). | M | ||
| 4 | cEMV UPOS Terminal | Schnittstellen und Protokolle | Protokoll Terminal - Validator | 04-D-01-02 | Der Bieter muss sicherstellen, dass das eingesetzte Kommunikationsprotokoll zwischen Validator und cEMV UPOS Terminal stabil, performant und fehlertolerant ist. | M | ||
| 4 | cEMV UPOS Terminal | Schnittstellen und Protokolle | Protokoll Terminal - Validator | 04-D-01-03 | Die Kommunikation muss in Echtzeit oder Near-Realtime erfolgen. | M | ||
| 4 | cEMV UPOS Terminal | Schnittstellen und Protokolle | Protokoll Terminal - Validator | 04-D-01-04 | Der Bieter muss sicherstellen, dass das Protokoll vollständig kompatibel mit den Funktionsanforderungen des IDBT-Verfahrens ist. | M | ||
| 4 | cEMV UPOS Terminal | Schnittstellen und Protokolle | Protokoll Terminal - Validator | 04-D-01-05 | Der Bieter benennt das genutzte Protokoll in der Spalte "Bemerkung". | M | ||
| 4 | cEMV UPOS Terminal | Schnittstellen und Protokolle | Protokoll VDV-KA | 04-D-02-01 | Das cEMV-UPOS-Terminal muss eine offene und dokumentierte Schnittstelle zur späteren Integration von VDV-KA bzw. (((etiCORE bereitstellen. | M | ||
| 4 | cEMV UPOS Terminal | Security Application Module | Anzahl SAM Steckplätze | 04-E-01-01 | Es müssen mindestens zwei verschiedene SAM-Steckplätze verfügbar sein, um zwei verschiedene Sicherheitsmodule (Security Application Module - SAM) aufnehmen bzw. hinzufügen zu können. | M | ||
| 4 | cEMV UPOS Terminal | Anschlüsse | Verfügbare Anschlüsse | 04-F-01-01 | Die vorhandenen Anschlüsse des cEMV UPOS Terminals müssen in einem Datenblatt dargelegt werden. | N | ||
| 4 | cEMV UPOS Terminal | Firmware | Updatefähigkeit | 04-G-01-01 | Die cEMV UPOS Terminals haben eine Funktionalität zur Durchführung von Firmware-Updates im eingebauten Zustand bereitzustellen. Ein Ausbau oder Einsendung der Geräte zum Update ist nicht zulässig. | M | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | Kartenorganisationen | 04-H-01-01 | Alle hard- und softwarebezogenen cEMV UPOS Terminal-Vorgaben sowie jeweils aktuellen Richtlinien und Zertifizierungsvorgaben der Kartenorganisationen sind zu berücksichtigen. Der Bieter legt die entsprechenden Nachweise für alle betroffenen, notwendigen und aktuellen Zulassungen und Zertifizierungen der Kartenorganisationen für das cEMV UPOS Terminal bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | EMV-Zertifizierung | 04-H-02-01 | Es müssen alle zum Zeitpunkt der Angebotsabgabge aktuellen Anforderungen der EMV-Zertifizierungslevel L2 für Visa und Mastercard Kernel an das cEMV UPOS Terminal eingehalten werden. | M | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | EMV-Zertifizierung | 04-H-02-02 | Es müssen alle zum Zeitpunkt der Angebotsabgabge aktuellen Anforderungen der EMV-Zertifizierungslevel L2 für Amex, Discover, JCB und UPI/CUP Kernel eingehalten werden. Der Bieter beschreibt mögliche Abweichungen in der Spalte Bemerkung. Für jede einzelne bestätigte Verfügbarkeit erhält der Bieter 1 Punkt. Es sind also insgesamt 4 Punkte für diese Anforderung zu erreichen. | S | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | EMV-Zertifizierung | 04-H-02-03 | Das cEMV UPOS Terminal muss mindestens eine EMV Contactless Level 1 Version 3.1 Zertifizierung besitzen. Der Bieter legt den entsprechenden Nachweis bei. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. Der Auftraggeber behält sich vor, die entsprechenden Zertifikate zum Zeitpunkt des ersten Einbaus von Hardware anzufordern. | N | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | PCI-PTS | 04-H-03-01 | Das cEMV UPOS Terminal muss mindestens eine PCI-PTS 6.x Zertifizierung besitzen. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | CEN/TS | 04-H-04-01 | Das cEMV UPOS Terminal muss mindestens als CEN/TS 16794-1:2017 Class D zugelassen sein. Alternativ muss es ISO/IEC TS 24192-1:2021 Class D zugelassen sein. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | Feuchtbeanspruchung und Staub | 04-H-05-01 | Das cEMV UPOS Terminal müssen gegen Eindringen von Flüssigkeiten und Staub gemäß IP65 nach IEC 60529 abgedichtet sein. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | Vandalismus | 04-H-06-01 | Das cEMV UPOS Terminal müssen den Anforderungen mindestens dem Standard IK10 (IEC 62262) entsprechen. Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 4 | cEMV UPOS Terminal | Normen, Richtlininen & Zertifizierungen | ISO | 04-H-07-01 | Das cEMV UPOS Terminal muss den ISO Standard 14443 A/B unterstützen. Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | N | ||
| 5 | Closed Loop EMV | Information | 05-00-Information | Der AG stellt seinen Fahrgästen eine Closed Loop EMV Guthabenkarte zur Verfügung. Er fungiert als Herausgeber der Closed Loop EMV Karte. Diese Karte hat eine Prepaid-Funktion, d. h. es kann Guthaben aufgeladen werden, das zur Bezahlung des Beförderungsentgelts genutzt wird. Es werden initial 10.000 Closed Loop EMV Karten bestellt. | I | |||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Größe | 05-A-01-01 | Die Größe der Closed Loop EMV Karte entspricht der ISO Standard 7810 ID-1 Norm. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Farbe und Design | 05-A-02-01 | Die Closed Loop EMV Karte muss im Design des AG mehrfahrbig (RAL-Farben) auf der Vorder- und Rückseite und mit NFC-Piktogramm (Vorderseite) bedruckt ausgeliefert werden. Designvorschläge, an denen sich der Bieter orientieren können, werden in der Phase der Ausführungsplanung gemeinsam abgestimmt. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Funktion | 05-A-03-01 | Die Closed Loop EMV Karte muss die cEMV Funktionalität erfüllen. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Kartenummer | 05-A-04-01 | Jede Closed Loop EMV Karte muss mit einer eindeutig zuortenbaren mehrstelligen Kartennummer (PAN) auf der Vorderseite bedruckt und programmiert sein. Die Kartennummern dürfen sich nicht doppeln. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Kartenummer | 05-A-04-02 | Die PAN der Closed Loop EMV Karte muss ebenfalls als Barcode auf die Karte gedruckt werden, sodass diese beim Verkauf mittels Scanner eingelesen werden können. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Kartenummer | 05-A-04-03 | Die Closed Loop EMV Karten müssen mit einer identifizierbaren BIN Range geliefert werden, sodass der Transit PSP die entsprechenden Karten und Transaktionen identifizieren und der Systemintegrator diese über ein Kartenkontoverwaltungssystem abwickeln kann. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Kartengültigkeit | 05-A-05-01 | Die Closed Loop EMV Karten haben eine Gültigkeitsdauer von fünf (5) Jahren. | M | ||
| 5 | Closed Loop EMV | Closed Loop EMV Karte | Kartengültigkeit | 05-A-05-02 | Die Closed Loop EMV Karten haben ein aufgedrucktes Gültigkeitsdatum (MM/JJ). | M | ||
| 5 | Closed Loop EMV | Kommerzielle Lieferbedingungen | Kartenbeschaffung | 05-B-01-01 | Der Bieter muss die Closed Loop EMV Karten bei einem zertifizierten EMV Kartenhersteller bestellen. Der Bieter gibt in der Spalte Bemerkung den EMV zertifizierten Kartenhersteller an, mit dem er zusammenarbeitet. Hinweis: Der EMV zertifizierte Kartenhersteller muss zum Zeitpunkt der Veröffentlichung der Vergabeunterlagen der hier beschriebenen IDBT-Gesamtlösung eine EMV Zertifizierung und eine Lizenz zur Produktion von Closed Loop EMV der jeweiligen Kartenorganisationen, z. B. M/Chip von Mastercard, besitzen. | M | ||
| 5 | Closed Loop EMV | Kommerzielle Lieferbedingungen | Kartenauslieferung | 05-B-02-01 | Die Closed Loop EMV Karten müssen zentral an den AG geliefert werden. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | zentrales IDBT- Hintergrundsystem | 06-A-01-01 | Es muss ein zentrales IDBT-Hintergrundsystem für den AG implementiert werden, das alle Informationen der verschiedenen Teilhintergrundsysteme integriert, konsolidiert und einheitlich bereitstellt und mit einem zentralen Login zugänglich ist. Dieses zentrale Hintergrundsystem muss als einzige verbindliche Datenquelle dienen und sicherstellen, dass redundante Datenhaltung sowie Inkonsistenzen vermieden werden. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-01 | Der Bieter muss für alle eingesetzten IT-Systeme ein differenziertes Rollenmodell implementieren, das alle erforderlichen Rollen und Verantwortlichkeiten vollständig abdeckt. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-02 | Die Vergabe von Berechtigungen hat nach dem Least-Privilege-Prinzip zu erfolgen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-03 | Zugriffe dürfen ausschließlich autorisierten Personen ermöglicht werden; unbefugte Zugriffe müssen durch geeignete technische und organisatorische Maßnahmen ausgeschlossen werden. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-04 | Rollen und Berechtigungen sind klar voneinander abzugrenzen; funktionstrennende Anforderungen sind einzuhalten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-05 | Der Bieter muss sicherstellen, dass die Berechtigungsvergabe nur durch befugtes Personal erfolgt und technisch dokumentiert wird. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-06 | Der Bieter muss sämtliche Rollen, Rechte, Benutzerkonten und deren Vergabeprozesse nachvollziehbar dokumentieren. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-02-07 | Der Bieter verpflichtet sich, die Dokumentation aktuell zu halten und dem AG auf Anfrage zur Verfügung zu stellen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-01 | Der Bieter muss für alle relevanten Systeme und Daten eine vollständige und belastbare Backup-Strategie implementieren. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-02 | Die Datensicherung muss mindestens folgende Aspekte gewährleisten: - regelmäßige, automatisierte Backups aller relevanten Daten und Konfigurationsparameter, - Festlegung eines geeigneten Backup-Intervalls, - Einhaltung definierter Aufbewahrungsfristen (Retention), unter Berücksichtigung gesetzlicher Anforderungen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-03 | Backups sind an sicheren, redundanten Speicherorten abzulegen, so dass Daten auch bei Systemausfall, Hardwaredefekt oder Sicherheitsvorfällen verfügbar bleiben. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-04 | Der Bieter muss sicherstellen, dass verlorene oder beschädigte Daten vollständig, korrekt und zeitnah wiederhergestellt werden können. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-05 | Der Wiederherstellungsprozess muss so gestaltet sein, dass der Geschäftsbetrieb bei einem Ausfall schnellstmöglich wieder aufgenommen werden kann. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-06 | Der Bieter muss regelmäßige Tests von Backup- und Wiederherstellungsprozessen durchführen, um deren Funktionsfähigkeit jederzeit sicherzustellen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-07 | Ein kontinuierliches Monitoring der Backup-Jobs (Erfolg/Misserfolg, Vollständigkeit, Integrität) ist einzurichten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-08 | Fehlgeschlagene Backups müssen automatisch erkannt, dokumentiert und unverzüglich korrigiert werden. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-09 | Der Bieter muss sämtliche Backup- und Restore-Prozesse vollständig dokumentieren. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-10 | Die Dokumentation muss nachvollziehbar darstellen: - welche Daten gesichert werden, - in welchen Intervallen, - wo die Backups gespeichert werden, - wie und in welchen Zeiträumen Daten wiederhergestellt werden können. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Back Up und Wiederherstellung | 06-A-03-11 | Die Dokumentation ist aktuell zu halten und dem Auftraggeber auf Anfrage zur Verfügung zu stellen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-01 | Der Bieter muss für alle eingesetzten IT-Systeme Prozesse implementieren, die die dauerhafte, vollständige und rechtssichere Löschung von Daten gewährleisten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-02 | Die Löschung hat sich auf sämtliche Datenarten zu erstrecken, einschließlich: - produktiver Daten, - Protokoll- und Metadaten, - personenbezogener Daten, - Datenbestände in Backups und Archivsystemen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-03 | Es müssen definierte Lösch-Trigger (z. B. Ablauf von Aufbewahrungsfristen) sowie Löschzeitpunkte implementiert sein. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-04 | Die Löschung hat entsprechend den datenschutzrechtlichen Vorgaben zu erfolgen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-05 | Der Bieter muss sichere und etablierte technische Löschverfahren einsetzen, die eine irreversible Datenlöschung gewährleisten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-06 | Die Löschverfahren müssen gewährleisten, dass Daten endgültig entfernt werden und nicht wiederhergestellt werden können. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-07 | Für Backup-Systeme sind Verfahren zu verwenden, die eine termingerechte und vollständige Löschung von Backup-Daten sicherstellen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-08 | Die Löschung sowie deren Erfolg sind protokollarisch zu erfassen („Löschprotokolle“) und müssen für Prüfungen verfügbar sein. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-09 | Der Bieter muss eindeutige Rollen und Verantwortlichkeiten für die Durchführung, Kontrolle und Freigabe von Löschvorgängen definieren. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-10 | Der Bieter muss sämtliche Löschprozesse vollständig dokumentieren und revisionssicher nachhalten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-11 | Die Dokumentation muss enthalten: - Art und Umfang der gelöschten Daten, - Zeitpunkt und Auslöser der Löschung, - eingesetzte Löschmethoden, - beteiligte Rollen/Personen, - technische Protokolle der erfolgreichen Löschung | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-12 | Die Löschdokumentation ist jederzeit für Datenschutz- und Compliance-Prüfungen verfügbar zu halten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Datenlöschung | 06-A-04-13 | Der Bieter muss sicherstellen, dass die Prozesse zur Datenlöschung regelmäßig überprüft und im Fall regulatorischer Änderungen angepasst werden. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-01 | Der Bieter muss für alle eingesetzten IT-Systeme ein differenziertes Rollenmodell implementieren, das alle erforderlichen Rollen und Verantwortlichkeiten vollständig abdeckt. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-02 | Die Vergabe von Berechtigungen hat nach dem Least-Privilege-Prinzip zu erfolgen. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-03 | Zugriffe dürfen ausschließlich autorisierten Personen ermöglicht werden; unbefugte Zugriffe müssen durch geeignete technische und organisatorische Maßnahmen ausgeschlossen werden. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-04 | Rollen und Berechtigungen sind klar voneinander abzugrenzen; funktionstrennende Anforderungen sind einzuhalten. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-05 | Der Bieter muss sicherstellen, dass die Berechtigungsvergabe nur durch befugtes Personal erfolgt und technisch dokumentiert wird. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-06 | Der Bieter muss sämtliche Rollen, Rechte, Benutzerkonten und deren Vergabeprozesse nachvollziehbar dokumentieren. | M | ||
| 6 | Hintergrundsystem | Generelle Anforderung | Rollen und Berechtigungen | 06-A-05-07 | Der Bieter verpflichtet sich, die Dokumentation aktuell zu halten und dem AG auf Anfrage zur Verfügung zu stellen. | M | ||
| 6 | Hintergrundsystem | Verwaltung und Steuerung Validatoren | Störungsmanagement Flotte | 06-B-01-01 | Zur zentralen Überwachung der Gerätezustände (Fehlerspeicher) und Datenbestände (Version) ist eine leicht verständliche, übersichtliche Benutzeroberfläche vorhanden. Es wird eine automatisierte Meldung bei erkannten Störungen in Echtzeit angezeigt. | M | ||
| 6 | Hintergrundsystem | Verwaltung und Steuerung Validatoren | Störungsmanagement Flotte | 06-B-01-02 | Die Weitergabe von Meldungen an ein Ticketsystem muss möglich sein. Die Weitergabe an das Ticketsystem kann mittels Dateiablage erfolgen. Mögliche Dateiformate sind csv, xml, json, jpg/png. | M | ||
| 6 | Hintergrundsystem | Verwaltung und Steuerung Validatoren | Integriertes Hintergrundsystem | 06-B-01-01 | Die gesamte Hardware muss mittels einer integrierten Software verwalt- und steuerbar sein. Die Benutzeroberfläche wird mit dem AG in der Phase der Ausführungsplanung abgestimmt, um sicherzustellen, dass alle für den Betrieb des Systems notwendigen Informationen vorhanden sind. | M | ||
| 6 | Hintergrundsystem | Verwaltung und Steuerung Validatoren | Integriertes Hintergrundsystem | 06-B-01-02 | Softwareupdates für Betriebssystem und Applikation werden zentral im Hintergrundsystem bereitgestellt und automatisiert über die zur Verfügung stehenden Kommunikationskanäle 4G oder besser bzw. WLAN an die Geräte fortlaufend während des gesamten Lebenszyklus verteilt. Der AG erhält eine Möglichkeit, die Softwareupdates eigenständig zu verteilen. | M | ||
| 6 | Hintergrundsystem | Verwaltung und Steuerung Validatoren | Integriertes Hintergrundsystem | 06-B-01-03 | Wie im Teillastenheft 1 "mobiler Validator" spezifiziert, müssen die Validatoren mit mind. einem 4G Modul versehen werden. Das Hintergrundsystem muss ebenfalls die Zuordnung der SIM-Karten zum Validator bzw. zum Fahrzeug leicht nachvollziehbar sicherstellen, indem die SIM-Kartennummer vom Validator ausgelesen wird. | M | ||
| 6 | Hintergrundsystem | Fahrpreisberechnung | Information | 06-C-Information | Der Fahrpreis wird anhand der aktuell gültigen Ticketpreise und -regeln berechnet. Diese Informationen finden die Bieter unter: Weiterhin stehen die Anlagen xxx (VVM Beförderungsbedingungen) und yyy (VVM Tarifzonenplan) zur Verfügung. | M | ||
| 6 | Hintergrundsystem | Fahrpreisberechnung | Allgemeine Anforderung | 06-C-01-01 | Der Bieter muss sicherstellen, dass alle für die korrekte Ticketpreisberechnung erforderlichen Transitdaten vollständig, korrekt und fristgerecht an die Systeme HighQ und OMNIPART weitergeleitet werden. Die Umsetzung hat gemäß den Vorgaben in Anlage xxx „Schnittstelle HighQ“ sowie Anlage xxx „Schnittstelle OMNIPART“ zu erfolgen. | M | ||
| 6 | Hintergrundsystem | Fahrpreisberechnung | Allgemeine Anforderung | 06-C-01-02 | Der Bieter muss eine Schnittstelle zu OMNIPART herstellen, über die die Entsorgung der Verkaufsdatensätze aus dem System erfolgt. Die Schnittstelle dient nicht der Ticketabbildung auf dem Validator, sondern der ordnungsgemäßen Weiterverarbeitung bzw. Ausleitung der Verkaufsdaten. Die Umsetzung hat gemäß den Vorgaben der Anlage xxx „Schnittstelle HighQ“ zu erfolgen. | M | ||
| 6 | Hintergrundsystem | Fahrpreisberechnung | PKM | 06-C-02-01 | Das Hintergrundsystem muss eine Schnittstelle zu einem PKM-Tarifmodul (Tarifrechner) bereitstellen, die nach dem Standard des Fraunhofer IVI sämtliche tariflichen Daten und die zugehörige Logik (Verkauf, Preiskalkulation, Kontrolle) enthalten und geräteunabhängig nutzbar sind. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Funktionsbeschreibung | 06-D-01-01 | Das Kartenkontoverwaltungssystem gewährleistet eine kontinuierliche Verwaltung der Closed Loop EMV Karten, wobei jeweils nach Abschluss der Kartentransaktion und erfolgreicher Fahrpreisberechnung, der Endbetrag gegen das referenzierte Kartenkonto der Closed Loop EMV Karte läuft und nicht über den Transit PSP an den Acquirer zur Abwicklung übertragen wird. Das Guthaben wird jeweils nach Closed Loop EMV Karteneinsatz vom referenzierten Guthaben des Kartenkontos abgebucht. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Funktionsbeschreibung | 06-D-01-02 | Das Kartenkontoverwaltungssystem hat eine Datenbank, um referenziertes Kartenguthaben zu verwalten. Hinsichtlich der Anzahl an Guthabenkonten gibt es keine Einschränkungen. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Funktionsbeschreibung | 06-D-01-03 | Wie im IDBT/Open Loop Ticketing-Transaktionsablauf wird der abzurechende Betrag über den Preisermittlungsservice (Fahrpreisberechnungsmodul) auf Basis der vom Fahrgast gefahrenen Strecke/gewähltem Ticket ermittelt. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Funktionsbeschreibung | 06-D-01-04 | Der referenzierte Kontostand der jeweiligen Closed Loop EMV Kartenkonten muss um den angeforderten Betrag reduziert werden. Falls das Kontoguthaben unter dem Mindestbetrag bzw. Mindestguthaben, der über die IDBT- Preisermittlung abrechenbar ist, sinkt, muss das Kartenkontoverwaltungssystem dem Transit PSP die PAN der entsprechenden Closed Loop EMV Karte melden, damit diese Karte auf der Sperrliste vermerkt wird. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Funktionsbeschreibung | 06-D-01-05 | Nach dem Check-In im Fahrzeug identifiziert der Transit PSP durch seine Terminalapplikation im cEMV UPOS Terminal anhand der ‘BIN Range’ der PAN, dass es sich um eine aktive Closed Loop EMV Karte handelt und sendet die Karten- und Transaktionsdaten an das Kartenkontoverwaltungssystem. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Funktionsbeschreibung | 06-D-01-06 | Das Kartenkontoverwaltungssystem muss in regelmäßigen Zeitintervallen (aller 5 Minuten) dem Hintergrundsystem und der Validatorensoftware die aktuellen Listen entsprechend des Listenmanagements übermitteln. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Front-End Verwaltung | 06-D-02-01 | Das Kartenkontoverwaltungssystem muss ein Frontend für den AG haben, sodass Prozesse selbstständig verwaltet werden können. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenbestellung und -registrierung | 06-D-03-01 | Bestellte Closed Loop EMV Karten werden im Kartenkontoverwaltungssystem registriert. Der initiale Registrierungsprozess muss ebenfalls für Nachbestellungen von Closed Loop EMV Karten sichergestellt werden. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenvertrieb | 06-D-04-01 | Das Kartenkontoverwaltungssystem muss es dem AG und seinen Vertriebspartnern ermöglichen als Stand-alone Lösung, Closed Loop EMV Karten zu verwalten und zu aktivieren sowie Guthaben aufzuladen und zurückzugeben. Dabei müssen die folgenden Funktionen sichergestellt werden: * Erreichbarkeit des Kartenkontoverwaltungssystems als Web-Applikation * Login mit Benutzername und Passwort vom Kundencenter-Mitarbeitenden/Vertriebspartner * Buchung des Wunschbetrags * Kulanzprozesse | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenvertrieb | 06-D-04-02 | Das Kartenkontoverwaltungssystem muss die folgende Funktion sicherstellen: *Einlesen/ Scannen des 2D/3D-Barcodes der auf der Closed Loop EMV Karte aufgedruckt ist durch das Vertriebssystem des AG und seiner Vertriebspartner zum Zugriff auf/Übermittlung der PAN an das zugehörige Kartenkonto. Der Bieter erläutert im Detail die Abweichungen von den genannten Anforderungen in der Spalte Bemerkung. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenvertrieb | 06-D-04-03 | Die Kartenausgabe erfolgt anonym, sodass im Kartenkonto innerhalb des Kartenkontoverwaltungssystem keine weiteren Fahrgastinformationen oder persönliche Daten gespeichert werden müssen. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenvertrieb | 06-D-04-04 | Perspektivisch muss eine Ausgabe und Verwaltung personalisierter Closed Loop EMV Karten möglich sein. Es muss das Aufdrucken von sowohl persönlicher Merkmale (z. B. Name, Geburtsdatum) als auch von bestimmten Fahrtberechtigungsmerkmalen und die digitale Verknüpfung dieser Merkmale mit dem Kartentoken möglich sein. Hinweis: Eine Personalisierung der Karte wird z. B. bei Schülertickets auf Basis von Closed Loop EMV notwendig. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Guthabenabfrage | 06-D-05-01 | Der Kunde des AG (Fahrgast) muss den Guthabenstand des Closed Loop Karten Kontos an der Vorverkaufsstelle im Kundencenter/beim Vertriebspartner einsehen. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Guthabenabfrage | 06-D-05-02 | Der aktuelle Status des Kartenkontos hinsichtlich Aktivierung, Guthabenbetrag und Karte werden durch den AG aus dem Kartenkontoverwaltungssystem abgefragt. Eine revisionssichere Dokumentation der Vorgänge muss gewährleistet sein. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenaufladung | 06-D-06-01 | Das Kartenkonto muss mit einem individuellen Betrag aufgeladen werden. Der maximaler Aufladebetrag beträgt 150 Euro. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartenaufladung | 06-D-06-02 | Es muss möglich sein, dass der Fahrgast seine Closed Loop EMV Guthabenkarte über eine Webanwendung (z.B. Kundenportal) selbst auflädt. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Reklamation | 06-D-07-01 | Es muss möglich sein, dass der Kartenkontostand manuell, z. B. aus Kulanzgründen, korrigiert wird, z. B. wenn ein Fehler bei der Abrechung am referenzierten Kartenkonto vorgefallen ist. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartensperrung | 06-D-08-01 | Es muss möglich sein, die Closed Loop EMV Karte, respektive das dazugehörige Kartenkonto zeitweise oder gänzlich zu sperren. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Kartensperrung | 06-D-08-02 | Closed Loop EMV Karten, die aufgrund von unzureichendem Guthaben gesperrt wurden, werden automatisch wieder entsperrt, nachdem ein ausreichendes Guthaben aufgeladen wurde und der ausstehende Betrag vom Closed Loop EMV Kartenkonto des Fahrgasts abgezogen wurde. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Prozess Guthabenrückgabe | 06-D-09-01 | Es muss möglich sein, dass dem Kunden (Fahrgast) des AG das aufgeladene Guthaben wieder ausgezahlt wird. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Guthabenverfall | 06-D-10-01 | Es muss konfigurierbar sein, wann nach den Vorgaben des AG das Guthaben einer Closed Loop EMV Karte verfällt. Dieses muss systemseitig transparent und auswertbar sein. | M | ||
| 6 | Hintergrundsystem | Kartenkontoverwaltungs- system | Vertriebsschnittstelle | 06-D-11-01 | Grundsätzlich muss die Möglichkeit bestehen, das Kartenkontoverwaltungssystem in eine Webanwendung eines Drtittanbieters zu integrieren. | M | ||
| 6 | Hintergrundsystem | Schnittstellen | Anbindung Transit Payment Service Provider | 06-E-01-01 | Das Hintergrundsystem muss eine Anbindung zum Transit PSP bereitstellen und den fehlerfreien IDBT-Prozessfluss sicherstellen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Allgemeine Anforderung | 06-F-01-01 | Die Anwendung des Bieters muss dem AG als cloudbasierte Lösung zur Verfügung gestellt werden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Allgemeine Anforderung | 06-F-01-02 | Die Cloud-Infrastruktur muss skalierbar, sicher, rechtskonform und stabil betrieben werden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Cloud-Architektur | 06-F-02-01 | Die Infrastruktur muss Lastspitzen im Ticketingumfeld ohne Funktionsverlust bewältigen können. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Cloud-Architektur | 06-F-02-02 | Es sind Mechanismen vorzusehen, die eine automatische Skalierung von Rechenleistung, Speicher und Netzwerkressourcen ermöglichen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Cloud-Architektur | 06-F-02-03 | Der Bieter hat sicherzustellen, dass sämtliche eingesetzten Cloud-Komponenten modular, wartungsfähig und unabhängig vom Betrieb vor Ort funktionieren. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Sicherheit der Cloud- Infrastruktur | 06-F-03-01 | Der Bieter muss aktuelle Sicherheitsstandards einhalten, insbesondere in den Bereichen: *Verschlüsselung *Netzwerksegmentierung und Firewalls *Zugriffskontrollmechanismen *Härtung der Cloud-Komponenten | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Sicherheit der Cloud- Infrastruktur | 06-F-03-02 | Die Cloud-Umgebung muss vor Angriffen geschützt sein und regelmäßige Sicherheitsupdates sowie automatisierte Patching-Prozesse unterstützen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Sicherheit der Cloud- Infrastruktur | 06-F-03-03 | Es sind Sicherheitsmaßnahmen einzusetzen, die Manipulation, unbefugten Zugriff und Datenverlust verhindern. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Sicherheit der Cloud- Infrastruktur | 06-F-03-04 | Der Bieter muss sicherstellen, dass zentrale Sicherheitsprotokolle aktiv genutzt werden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Sicherheit der Cloud- Infrastruktur | 06-F-03-05 | Ein umfangreiches Monitoring muss eingerichtet sein, das die Verfügbarkeit, Performance und Sicherheit aller relevanten Dienste überwacht. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Betriebsprozesse | 06-F-04-01 | Der Bieter muss ein Incident-Management-Verfahren bereitstellen, das: *Fehler schnell erkennt, *priorisiert, *bearbeitet, *die Wiederherstellung in definierten Zeitfenstern sicherstellt. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Betriebsprozesse | 06-F-04-02 | Service-Unterbrechungen, Ausfälle und Störungen sind nachvollziehbar zu dokumentieren und dem Auftraggeber transparent zu melden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Dokumentation | 06-F-05-01 | Der Bieter muss eine vollständige technische Dokumentation zur Cloud-Architektur, Topologie, Sicherheitsmaßnahmen und Betriebsprozessen bereitstellen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Dokumentation | 06-F-05-02 | Änderungen an der Cloud-Infrastruktur sind transparent festzuhalten. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Dokumentation | 06-F-05-03 | Die Dokumentation ist aktuell zu halten und dem Auftraggeber auf Anfrage bereitzustellen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Cloud-Zugriff | 06-F-06-01 | Der Zugriff zum Cloud-System ist Proxy-fähig und die Kommunikation findet über verschlüsselte Wege statt. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-01 | Für Systemtests ist eine Testumgebung vorhanden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-02 | Das Testsystem wird vom Bieter lizenzfrei zur Verfügung gestellt. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-03 | Der Bieter muss technische und organisatorische Verfahren bereitstellen, die eine kontrollierte und nachvollziehbare Datenübernahme zwischen Test- und Produktivumgebung ermöglichen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-04 | Diese Verfahren müssen sowohl die Übernahme in das Testsystem (z. B. zur realistischen Testdatenerzeugung) als auch aus dem Testsystem (z. B. bei Migrationen) abdecken. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-05 | Datenübernahmen müssen dokumentiert, versioniert und ausschließlich durch autorisierte Rollen durchführbar sein. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-06 | Es sind Mechanismen vorzusehen, die verhindern, dass fehlerhafte oder unvollständige Daten in die Produktivumgebung gelangen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-07 | Test- und Produktivsysteme müssen technisch voneinander getrennt betrieben werden | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-08 | Die Testumgebung muss so gestaltet sein, dass sie technisch und funktional hinreichend vergleichbar mit der Produktivumgebung ist (z. B. gleiche Versionen, Dienste, Parameter). | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-09 | Der Bieter muss sicherstellen, dass die Testumgebung stabil betrieben wird und ausreichend Kapazitäten zur Durchführung von Tests (inkl. Last- und Integrationstests) bereitstehen. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-10 | Änderungen am Produktivsystem (Updates, Migrationen, Releases) müssen zuerst in der Testumgebung validiert werden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-11 | Der Bieter muss sämtliche Datenübernahmen zwischen Test- und Produktionssystemen vollständig dokumentieren, einschließlich: *Art und Umfang der übertragenen Daten, *Verantwortliche Rollen/Personen, *Zweck der Übernahme, *technische Verfahren, *Zeitpunkt und Ergebnis. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Testumgebung | 06-F-07-12 | Dokumentationen zur Test- und Produktivarchitektur müssen jederzeit aktuell gehalten werden. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Systemarchitektur | 06-F-08-01 | Das System bietet eine Funktion zur Archivierung. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Datenaustausch | 06-F-09-01 | Sollte ein Datenaustausch notwendig sein, wird dieser über aktuelle verschlüsselte Wege umgesetzt. Zudem werden, wenn personenbezogene Daten verwendet werden, diese verschlüsselt abgelegt. Passwörter in Konfigurationsdateien oder an anderen Stellen dürfen nicht im Klartext hinterlegt sein, sondern sind verschlüsselt. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Berechtigungen | 06-F-10-01 | Es sind Standardberechtigungsgruppen vorkonfiguriert, welche anpassbar sind. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Skalierbarkeit | 06-F-11-01 | Das System muss mehr Nutzer oder Anfragen automatisch verarbeiten können, ohne dass es langsamer wird. | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Skalierbarkeit | 06-F-11-02 | Es muss möglich sein, kurzfristig (innerhalb von ca. 2 Minuten) zusätzliche Server-Ressourcen automatisch zuzuschalten (Autoscaling). | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Skalierbarkeit | 06-F-11-03 | Das System muss mindestens die dreifache Standard-Last problemlos verarbeiten können (z. B. wenn plötzlich viele Kunden gleichzeitig auf das System zugreifen). | M | ||
| 6 | Hintergrundsystem | Cloud-Anforderungen | Verfügbarkeit | 06-F-12-01 | Die Cloudlösung muss so gebaut sein, dass ein Ausfall eines einzelnen Rechenzentrums automatisch abgefangen wird. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Information | 07-00-Information | Der AG unterliegt gesetzlichen Anforderungen aus dem Handelsgesetzbuch sowie den Grundsätzen ordnungsgemäßer Buchführung und Aufbewahrung für die Finanzbuchhaltung. Darüber hinaus muss der AG in der Lage sein, das IDBT-Geschäft mit üblichen Instrumenten und Analysen des Controllings steuern zu können. Bereitgestellte Daten und Auswertungs-Tools des Bieters müssen dieses uneingeschränkt gewährleisten. | I | |||
| 7 | Nebenbuchhaltung & Controlling | Datenmodell & Datensätze | Übergreifende Datenstruktur | 07-A-01-01 | Um gesetzliche Anforderungen zu erfüllen, müssen transaktionale Daten aller Dienstleister (Systemintegrator, Transit Payment Service Provider und Acquirer) zusammenführbar sein. Es ist entscheidend, dass das Thema Daten gesamtheitlich gedacht wird in einem übergreifenden Datenmodell über alle beteiligten Quellen. Der Bieter muss sicherstellen, dass die Daten aller beteiligten Dienstleister (inkl. Systemintegrator, Transit Payment Service Provider und Acquirer) auf Einzeltransaktionsebene zusammengeführt werden könnnen. Dieses schließt spätere oder rückwirkende Zahlungsabwicklung, wie Refunds, Debt Recovery oder Chargebacks mit ein, sodass diese der ursprünglichen Transaktion zugeorndet werden können. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenmodell & Datensätze | Übergreifende Anforderungen | 07-A-02-01 | Der Bieter verpflichtet sich das Datenmodell, inkl. Datensätzen, Datenfelder und Ausprägungen im Detail mit dem AG in der Ausführungsplanungsphase zu erarbeiten, zu definieren und sicherzustellen, dass alle Anforderungen des AG erfüllt sind. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenmodell & Datensätze | Übergreifende Anforderungen | 07-A-02-02 | Der Bieter muss alle Datensätze in einem konsistenten Datenformat bereitstellen, sodass sich diese nahtlos mit einem Analytics Tool zusammenführen und auswerten lassen. Der Bieter verpflichtet sich, in der Ausführungsplanung mit dem AG die Datenformate zu konkretisieren. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenmodell & Datensätze | Übergreifende Anforderungen | 07-A-02-03 | Der Bieter muss alle Datensätze in deutscher Sprache mit üblichen Formatierungen und Formaten (z. B. Datums-, Währungsformat) aus dem deutschsprachigen Raum zur Verfügung stellen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenmodell & Datensätze | Übergreifende Anforderungen | 07-A-02-04 | Der Bieter liefert zu allen Datensätze eine entsprechende Dokumentation, die alle Datenfelder und Ausprägungen erläutert, inkl. Abkürzungen, Codes und Geschäftslogik dahinter. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Umsatzerfassung | 07-B-01-01 | Jede Transaktion muss als Einzelaufzeichnung erfasst werden und nachvollziehbar dokumentiert werden, sodass diese über die Transitdaten einer spezifischen Beförderungsdienstleistung zugeordnet werden kann. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Umsatzerfassung | 07-B-01-02 | Jeder Transaktion muss der erhobene Umsatzsteuersatz zugeordnet werden, wobei der Transaktionsbetrag in brutto ausgewiesen werden muss. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Umsatzerfassung | 07-B-01-03 | Jede Transaktion muss eindeutig aufzeigen, ob eine Open Loop EMV oder Closed Loop EMV Guthabenkarten als Zahlungsmittel eingesetzt wurde. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Belegpflicht, Dokumentation und Archivierung | 07-B-02-01 | Zugriffsrechte auf Originaldaten müssen gewährleistet sein. Die Aufbewahrungsfrist ist 10 Jahre. Die Daten müssen dem AG auch bei einem potentiellen Wechsel des Dienstleister uneinschränkt zur Verfügung stehen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Belegpflicht, Dokumentation und Archivierung | 07-B-02-02 | Alle Daten müssen für die Archivierung unveränderbar, maschinell auswertbar und zugriffsbereit bereitgestellt werden. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Periodengerechte Abgrenzung | 07-B-03-01 | Transaktionen müssen nach dem Verursachungsprinzip dem richtigen Abrechnungszeitraum zugeordnet werden. Dieses schließt die Zuordnungsbarkeit von Refunds, Debt Recovery und Chargebacks mit ein. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Guthabenkarte & -bestände | 07-B-04-01 | Aufgrund der buchhalterischen Behandlung von Guthabenkarten muss der Guthabenbestand (inkl. Veränderungen duch Aufladung, Rückerstattungen, Rückgaben, Chargebacks) stichtagsbezogen auswertbar sein. Davon getrennt auswertbar müssen die Guthabenverbrauche auswertbar sein, um diese entsprechend bilanztechnisch zur Auflösung von Verbindlichkeit und zur Verbuchung von Umsätzen behandeln zu können. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Guthabenverfall | 07-B-05-01 | Es muss jederzeit Transparenz über den Verfallsstatus von Guthaben aller Guthabenkarten bestehen, sodass dieser bilanztechnisch entsprechend behandelt werden kann. Regeln für den Guthabenverfall werden in der Ausführungsplanung definiert. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Kontroll- und Nachvollziehbarkeitspflichten | 07-B-06-01 | Im Rahmen der Kontroll- und Nachvollziehbarkeitspflichten muss es uneingeschränkt möglich sein die Korrektheit aller abgerechneten Beträge über alle Datenquellen hinweg zu überprüfen, z.B. in dem gemeldete Einnahmen des Acquirers mit der Verkaufs- und Transitdaten des Systemintegrators oder Tap- und Autorisierungsdaten des Transit Payment Service Providers abgeglichen werden können. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Kontroll- und Nachvollziehbarkeitspflichten | 07-B-06-02 | Darüber hinaus muss es nachweisbar sein, dass Abweichungen oder Fehler (z. B. abgelehnte Zahlungen, Rückerstattungen, Chargebacks) dokumentiert und berücksichtigt wurden. Diese müssen ebenfalls der ursprünglichen Transaktion zugeordnet werden können. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Kontroll- und Nachvollziehbarkeitspflichten | 07-B-06-03 | Jeder Transaktion können alle erhobenen Gebühren der involvierten Dienstleister zugeordnet werden. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Revisionssicherheit | 07-B-07-01 | Der lückenlose Auslesungsnachweis für sämtliche Verkaufsvorgänge und der automatisierte revisionssichere Datenabrufprozess bilden die Grundlage für die Einnahmesicherheit, wobei die Grundsätze für ordnungsgemäße Buchführung und Speicherbuchführung eingehalten werden müssen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Gesetzliche Anforderungen | Revisionssicherheit | 07-B-07-02 | Einnahmen müssen revisionssicher erfasst, gespeichert und nachvollziehbar ausgewertet werden können. Alle hierfür erforderlichen Prozesse und Verfahren zum revisionssicheren Datenabruf müssen bereitgestellt und funktionsfähig implementiert sein. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Metadaten | 07-C-01-01 | Alle Transaktionen müssen nach den den folgenden Metadaten auswertbar sein: * Geräteart/Vertriebsweg * Gerätenummer * Wagennummer * Verkaufsdatum * Verkaufsuhrzeit * Übertragungsdatum * Übertragungsuhrzeit * Produkt * Produkttext * Fahrbereich/Preisstufe * Stückzahl * Einzelpreis (Ticketpreis) * Gesamtpreis * Zahlart (Closed Loop EMV Karte oder Bankkarte, Kartenschemes) * Transaktions-ID Zahlung * Bankkartennummer (maskiert, 6 + x + 3) * Linie * Kurs * Kategorie Verkehrsmittel: Bus/Straßenbahn/Stadtbahn/Unternehmer * Haltestelle (Nummer und Name, Check-In bzw. Check-Out) * EMV-Kartenstatus (akzeptiert, abgelehnt, abgebrochen) * SIM-Kartennummer * Übertragungsfehler (Im Falle nicht erfolgreicher Übertragung Fehlercode) * Ticket Gültig ab * Ticket Gültig bis * Vorgang (Verkauf, Storno, Gutschrift) * Betrag Gutschrift | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Metadaten | 07-C-01-02 | Daten sind mindestens für die Zeiträume täglich, wöchentlich, monatlich, jährlich verfügbar; Transaktionen sind darüber hinaus unterscheidbar nach Verkehrsunternehmen, respektive Sub-Unternehmen sowie Kartentyp: Mastercard, Visa oder Closed Loop EMV Karte. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Technische Reports | 07-C-02-01 | Der AG muss in der Lage sein, jederzeit den Status jedes Validators abrufen können, inkl. der folgenden Informationen: *Versionsnummer *Tarifstand * Zustand | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Technische Reports | 07-C-02-02 | Der AG muss in der Lage sein, jederzeit automatisiert die Mobilfunk- und eSIM-Informationen je Validator abzurufen, sofern der Validator mit einer eSIM ausgestattet ist. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-01 | Dem AG müssen Abfrage- und Auswertungs-Tools zur Verfügung gestellt werden, die das Erstellen von Berichten und Ad-hoc-Abfragen ermöglichen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-02 | Dem AG muss es möglich sein, alle Daten des Systemintegrators und des TPSP aus einem einzigen Abfrage- und Auswertungs-Tool zu beziehen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-03 | Das Auswertungs-Tool muss eine intuitive und übersichtliche Bedienung bieten, welche es Nutzern ohne Vorkenntnisse ermöglicht, Aufgaben effizient und mit minimalem Aufwand zu erledigen. Die Benutzeroberfläche muss klar strukturiert, fehlertolerant und zugänglich gestaltet sein. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-04 | Das Auswertungs-Tool wird in deutscher Sprache zur Verfügung gestellt. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-05 | Das Auswertungs-Tool ermöglicht verschiedene Filtereinstellungen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-06 | Die Auswertungsdaten müssen grafisch in Form von Diagrammen dargestellt werden. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Controlling | Abfrage- & Auswertungstools | 07-C-03-07 | Die Reports müssen mind. in csv, Excel und pdf exportiert werden können. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenbereitstellung | Schnittstelle | 07-D-01-01 | Der Bieter muss die Möglichkeit von Datenexports in Drittsysteme sicherstellen. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenbereitstellung | Schnittstelle | 07-D-01-02 | Der Bieter muss eine sichere File Server Lösung bereitstellen, von dem der AG alle Datensätze automatisiert beziehen kann. | M | ||
| 7 | Nebenbuchhaltung & Controlling | Datenbereitstellung | Schnittstelle | 07-D-01-03 | Der Bieter muss in der Lage sein alle Daten auf einen File Server des AGs automatisiert und sicher zu übertragen. | M | ||
| 8 | Dienstleistungen | Projektmanagement | Projektrealisierung | 08-A-01-01 | Der Bieter ist als Generalunternehmer verpflichtet, den fach- und termingerechten Projektfortschritt aktiv zu überwachen und steuernd einzugreifen. Diese Verpflichtung schließt die Leistungen aller Subunternehmer und Lieferanten mit ein. | M | ||
| 8 | Dienstleistungen | Projektmanagement | Projektteam und Verantwortlichkeiten | 08-A-02-01 | Der Bieter hat einen Projektleiter sowie zwei Vertreter zu benennen, welcher bis zur vollständigen Abnahme der Leistungen als verantwortlicher und entscheidungsbefugter Ansprechpartner den Bieter im Rahmen der Realisierung der Leistungen und Services vertritt. | M | ||
| 8 | Dienstleistungen | Projektmanagement | Projektteam und Verantwortlichkeiten | 08-A-02-02 | Der Bieter muss mindestens eine Niederlassung mit Sitz in Deutschland haben. | M | ||
| 8 | Dienstleistungen | Projektmanagement | Projektteam und Verantwortlichkeiten | 08-A-02-03 | Zu den Aufgaben des Projektleiters zählen: - Projektleitung - Projekt Controlling - Projekt Koordination - Ausführungsplanung - Erstversorgung, Konfiguration - technische Dokumentation - Testbetrieb/Abnahme - wöchentliche Regeltermine mit dem AG Die Projektleitertätigkeit ist in deutscher Sprache zu erbringen. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Allgemeine Anforderungen | 08-B-01-01 | Die Lieferung der erforderlichen Gerätekomponenten erfolgt gemäß im Vertrag angegebenen Zeitplan. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Allgemeine Anforderungen | 08-B-01-02 | Der Bieter ist verpflichtet, eine Bestandsanalyse der vorhandenen und zu beschaffenden Kabel zu erstellen. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Allgemeine Anforderungen | 08-B-01-03 | Die Verkabelung aller mobilen Validatoren, Router und Switche sowie deren Komponenten erfolgt optional durch den Bieter. Vorhandene Kabel sind dabei mit zu verwenden. Die dazu erforderliche Detailplanung für die verschiedenen Fahrzeugtypen (siehe B04 - Stammdatenblatt) ist Bestandteil der Vergabeunterlagen. Die Fahrzeuge werden dem Bieter in Abhängigkeit des Betriebsablaufes in Absprache mit der Betriebsdisposition und unter Berücksichtigung der jeweils aktuellen Betriebssituation zur Verfügung gestellt. Bei nicht beendeter Installation der Gerätekomponenten muss die Einsatzbereitschaft des Fahrzeugs hergestellt werden. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Allgemeine Anforderungen | 08-B-01-04 | Die Umrüstung der Fahrzeuge erfolgt an den Betriebshöfen der Mitgliedsverkehrsunternehmen des AG (siehe A01 - Stammdatenblatt). | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Allgemeine Anforderungen | 08-B-01-05 | Der Bieter hat bei der Ausführung der Dienstleistung beziehungsweise bei der Installation oder Lieferung den AG bei Verzögerung des Umsetzungsplanes sofort zu informieren und bei Eigenverschulden sofortige Gegenmaßnahmen einzuleiten. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Mobiler Validator | 08-B-02-01 | Falls an der Haltestange eine Entwertergrundplatte vorhanden ist, wird diese durch die Grundplatte des Validators ersetzt. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Sternpunkte | 08-B-03-01 | Im Bus muss jeder Validator vom Sternpunkt eine eigene IBIS-Wagenbus Verkabelung und Spannungsversorgung erhalten. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Wellrohre | 08-B-04-01 | Für die Verlegung der Leitungen zwischen zwei Wagenteilen bei Gelenkbussen sind ggf. weitere Wellrohre zu berücksichtigen. | M | ||
| 8 | Dienstleistungen | Installation und Lieferung | Stationärer Validator | 08-B-05-01 | Das Fundament sowie der Aufbau der Bodenbefestigung bzw. die Anbringung der Winkelsäule obliegen dem AG. Der Bieter ist verantwortlich für das Anbringen, das Verkabeln und die Inbetriebnahme des stationären Validators. | M | ||
| 8 | Dienstleistungen | Reparaturen & Wartung | Ersatzteillieferung | 08-C-01-01 | Der Bieter hat innerhalb von 10 Werktagen nach Eingang bei ihm die eingesendeten Reparaturteile (für max. 5 Stück) in repariertem Zustand wieder zur Post zu geben. Für die Dauer von 10 Jahren sind die Kosten für den Hin- und Rückversand vom Bieter zu tragen. | M | ||
| 8 | Dienstleistungen | Reparaturen & Wartung | Hardwarewartung | 08-C-02-01 | Der AG ist berechtigt, alle vorgeschriebenen Prüf- und Wartungsarbeiten der Hardware nach den bestehenden Prüf- und Wartungsempfehlungen des Bieters ohne Einschränkung der Gewährleistung von geschultem Fachpersonal des AG durchführen zu lassen. | M | ||
| 8 | Dienstleistungen | Reparaturen & Wartung | Softwarewartung | 08-C-03-01 | Der Bieter übernimmt die vollständige fachliche, technische und organisatorische Verantwortung für die Wartung aller Softwarekomponenten. | M | ||
| 8 | Dienstleistungen | Reparaturen & Wartung | Softwarewartung | 08-C-03-02 | Es gelten die im Vertrag festglegten Bedingungen für die Softwarewartung. | M | ||
| 8 | Dienstleistungen | Schulungen | Allgemeine Anforderungen | 08-D-01-01 | Die Mitarbeiter des AG sind in deutscher Sprache zu schulen. Die Schulungen sind als Festpreis anzubieten und erfolgen als Anwenderschulung. Schulungen erfolgen an den Dienstsitzen des AG. Der Auftraggeber bestimmt die Schulungstermine nach billigem Ermessen. Er versucht hierbei, Terminwünsche des Auftragnehmers zu berücksichtigen. Grundsätzlich muss als Kriterium für die Terminierung der Zeitraum zwischen Schulung und Inbetriebnahme möglichst kurz sein. Der Schulungsumfang einer (1) Schulung beträgt 1 Arbeitstag (8h). | M | ||
| 8 | Dienstleistungen | Schulungen | Allgemeine Anforderungen | 08-D-01-02 | Es muss eine Nachschulung in deutscher Sprache eingeplant werden. Die Nachschulung findet 1 bis 3 Monate nach der Inbetriebnahme statt und dient der Klärung von aufgetretenen Fragen oder der Vertiefung von Anwendungsprozessen. Für eventuelle weitere Nachschulungen vor Ort oder online kommen die gleichen Tagessätze zur Geltung für die verbindlich bestellten Schulungen. | M | ||
| 8 | Dienstleistungen | Schulungen | Schulungsgruppen | 08-D-02-01 | Folgende Gruppen sind zu schulen: - Anwenderschulung Betrieb - Anwenderschulung für Buchhaltung, Revision, Vertriebscontrolling - Anwenderschulung für die Werkstatt (Techniker) - Anwenderschulung Kundensupport - Anwenderschulung Vertrieb und Verkaufspersonal - Anwenderschulung Kontrollpersonal/Fahrausweisprüfer - Anwenderschulung für die Adminstratoren | M | ||
| 8 | Dienstleistungen | Schulungen | Schulungsunterlagen | 08-D-03-01 | Für jede Schulung sind Schulungsunterlagen in deutscher und englischer Sprache zu erstellen und dem AG in elektronischer Form (PDF und docx) zur Verfügung zu stellen. | M | ||
| 8 | Dienstleistungen | Mitwirkung | Mitwirkungspflichten AG | 08-E-01-01 | Für die Umsetzung des Projekts ist ein strukturiertes Mitwirkungskonzept einzureichen, das Art, Umfang und Zeitpunkte der Mitwirkungspflichten des Auftraggebers eindeutig festlegt. | N | ||
| 8 | Dienstleistungen | Technische Dokumentation | Allgemeine Anforderungen | 08-F-01-01 | Der Bieter hat eine vollständige und ausführliche Dokumentation zur technischen Systemlösung mit folgenden Inhalten zu erstellen: - Funktions- und Systembeschreibung - Gerätebeschreibungen mit Gerätebedienung - Fehlermanagement / Fehlerbehebungsmaßnahmen - Prüfprotokolle und Zertifikate von Aufsichtsbehörden - Wartungshandbuch (Wartungsintervalle und Anleitungen) - Ersatzteillisten - Dokumentation der Verkabelung - Softwareanwendung (Hintergrundsystem, Transit PSP, Fahrpreisberechnungsmodul, Kartenkontoverwaltungssystem, Cloudlösung) - Beschreibung implementierter Härtungsmaßnahmen zur IT-Sicherheit - Informationssicherheitskonzept - Dokumentation/Offenlegung aller Schnittstellen - Dokumentation Buchhaltung & Controlling | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Sprache | 08-F-02-01 | Die Dokumentation ist in deutscher Sprache abgefasst und ist dem AG spätestens zwei Wochen vor der Endabnahme in einfacher Ausfertigung elektronisch (PDF und docx) zu übergeben. Der Auftraggeber hat das Recht, die Dokumentation für eigene Zwecke zu vervielfältigen. Für den Betrieb erforderliche Unterlagen sind bereits mit der Schulung vor der Inbetriebnahme zu übergeben. Bis zur Endabnahme ist ggf. eine Aktualisierung vorzunehmen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Sicherheit der Schnittstellen/der gemeinsam genutzten Infrastruktur | 08-F-03-01 | Je Schnittstelle/je gemeinsam genutzte Infrastrukturkomponente sind Sicherheitsmaßnahmen gemäß Stand der Technik zu definieren, in deutscher Sprache zu dokumentieren und umzusetzen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Sicherheit der Schnittstellen/der gemeinsam genutzten Infrastruktur | 09-F-03-02 | Die Schnittstellen/die gemeinsam genutzten Infrastrukturkomponenten zwischen dem Bieter und der AG müssen in deutscher Sprache dokumentiert werden. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-01 | Das Notfallvorsorge- und Notfallmanagement muss sämtliche relevanten Infrastrukturkomponenten, Anwendungen, Datenbanken, Netzwerke und Schnittstellen entlang der kompletten IT-Infrastruktur des bargeldlosen Zahlungssystems umfassen. Dies schließt insbesondere ein: *Backend-Systeme, *Cloud-Infrastruktur, *Schnittstellen zu Acquirern, PSP/TPSP, *Validatoren, Terminals und Peripherie, *Clearing-, Abrechnungs- und Monitoring-Systeme. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-02 | Abhängigkeiten zwischen den Systemkomponenten sind vollständig zu berücksichtigen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-03 | Der Bieter muss eine umfassende Notfallstrategie für den Betrieb des Systems umsetzen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-04 | Es sind mindestens folgende Notfall- und Krisenszenarien abzudecken: *Totalausfall einzelner Systeme oder Rechenzentren, *Teilausfälle kritischer Komponenten, *Cyberangriffe und Sicherheitsvorfälle, *Datenverluste, *Ausfälle externer Dienstleister oder Schnittstellenpartner. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-05 | Für jedes relevante Szenario sind definierte Maßnahmen zur: *unmittelbaren Schadensbegrenzung, *Stabilisierung des Betriebs, *Wiederherstellung des Regelbetriebs verbindlich vorzusehen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-06 | Der Bieter muss sicherstellen, dass der Geschäftsbetrieb auch in Störungssituationen aufrechterhalten oder schnellstmöglich wiederhergestellt werden kann. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-07 | Redundanzen, Ausweichsysteme und Wiederanlaufverfahren sind so vorzuhalten, dass ein längerer Systemstillstand ausgeschlossen wird. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-08 | Der Bieter muss klare Zuständigkeiten, Rollen und Vertretungsregelungen für Notfall- und Krisensituationen definieren. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-09 | Es müssen verbindliche Eskalationsstufen und Entscheidungswege festgelegt sein. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-10 | Für jede Eskalationsstufe sind: *eindeutige Ansprechpartner, *Erreichbarkeiten, *Kommunikationswege (z. B. Telefon, E-Mail, Notfallkanäle) verbindlich zu hinterlegen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-11 | Der Bieter muss regelmäßige Tests und Notfallübungen durchführen, um die Funktionsfähigkeit der Notfallprozesse nachzuweisen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-12 | Die Ergebnisse der Tests sind zu dokumentieren, auszuwerten und zur kontinuierlichen Verbesserung zu nutzen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-13 | Festgestellte Schwachstellen sind verpflichtend in angemessener Frist zu beseitigen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-14 | Der Bieter muss sämtliche Maßnahmen zur Notfallvorsorge und zum Notfallmanagement vollständig, aktuell und transparent dokumentieren. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-15 | Die Dokumentation muss mindestens enthalten: *Notfallszenarien, *Wiederanlaufpläne, *Eskalationsstufen, *Zuständigkeiten und Ansprechpartner, *Kommunikationswege, *Testergebnisse und Verbesserungsmaßnahmen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-16 | Der Bieter muss sicherstellen, dass das Notfallvorsorge- und Notfallmanagement regelmäßig überprüft und fortgeschrieben wird. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-17 | Änderungen an Systemarchitektur, Schnittstellen oder Betriebsmodellen sind unverzüglich in den Notfallprozessen zu berücksichtigen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Notfall- und Notfallvorsorgekonzept | 08-F-04-18 | Die Dokumentation ist dem Auftraggeber auf Anfrage jederzeit zur Verfügung zu stellen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Aktualisierung | 08-F-05-01 | Die Dokumentation wird für die Dauer des Vertrags regelmäßig aktualisiert (mindestens zu jedem Major- Releasewechsel) und dem AG unaufgefordert zur Verfügung gestellt. Der AG benennt hierfür einen Ansprechpartner. Änderungen müssen zum besserem Verständnis immer kenntlich gemacht werden und beim nächsten Releasewechsel normal eingegliedert werden. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Prozesse zur Aufrechterhaltung der Informationssicherheit | 08-F-06-01 | Es muss festgelegt werden, welche internen und externen Kommunikationspartner welche Informationen übermitteln und erhalten dürfen. | M | ||
| 8 | Dienstleistungen | Technische Dokumentation | Prozesse zur Aufrechterhaltung der Informationssicherheit | 08-F-06-02 | Es sind Kommunikationswege und Ansprechpartner bei Fragen zur Informationssicherheit zu benennen, insb. im Hinblick auf: * Festlegung von Verantwortlichen zu den Belangen der Informationssicherheit * Änderung und Überprüfung der Sicherheitsmaßnahmen bzw. des Sicherheitskonzepts (z. B. im Falle einer veränderten Risikolage) * Verfahren zur rechtzeitungen Meldung und Behebung von Sicherheitsvorfällen (insb. Notfälle) * Festlegung und Abstimmung von Vertretungsregelungen | M |
[Seite 89]
| Angabe, ob Nachweis Angabe HINWEIS: Alle geforderteten Dokumente müssen als separate Dateien mit einer eindeutigen Bezeichnung eingereicht werden. mit eingereicht wurde Dokumentenname | |||||||
|---|---|---|---|---|---|---|---|
| # | TEILLASTENHEFT | NAME | BESCHREIBUNG | INHALTLICHE VORGABEN | NACHWEIS EINGEREICHT | DOKUMENTENVERWEIS | |
| 0 | Allgemeine Anforderungen | Nachweis Anwendungs-/Plattform- sicherheit | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 0 | Allgemeine Anforderungen | Integrations- und Anbindungskonzept für die technische Integration an den bereits beauftragten Transit PSP sfey Pay OÜ | Der Bieter stellt ein schlüssiges und prüffähiges Integrations- und Anbindungskonzept für die technische Integration des von ihm angebotenen Systems an den bereits beauftragten Transit PSP sfey Pay OÜ dar. Das Konzept muss sicherstellen, dass die vollständige Integration innerhalb von drei Monaten nach Beauftragung umgesetzt und abgeschlossen werden kann und alle relevanten Systemkomponenten, Schnittstellen, Integrationsschritte, Tests sowie wesentlichen Integrationsrisiken nachvollziehbar berücksichtigt sind. | Das Integrations- und Anbindungskonzept darf maximal 6 DIN-A4-Seiten in Schriftgröße 11 umfassen. Unterkriterien: - Die Systemarchitektur und Schnittstellen sind vollständig, konsistent und nachvollziehbar dargestellt und zur Erfüllung der Aufgabenstellung geeignet. - Die Integrationsschritte, inkl. Abhängigkeiten, Meilensteinen und Zeitplan, sind schlüssig beschrieben und belegen, dass die vollständige Integration innerhalb von drei Monaten nach Beauftragung realistisch umsetzbar ist. - Datenflüsse, Datenformate und Kommunikationsprotokolle sind beschrieben und für eine sichere und stabile Systemintegration geeignet. - Das Test- und Abnahmevorgehen ist vollständig beschrieben und gewährleistet eine erfolgreiche technische Integration. - Maßnahmen zur Sicherstellung der Betriebsstabilität nach erfolgreicher Integration sind dargestellt und nachvollziehbar. - Integrationsrisiken sind identifiziert und mit geeigneten Maßnahmen zur Risikominimierung adressiert, insbesondere im Hinblick auf Termin- und Integrationsrisiken. Bewertung: Gesamtnote 1–5, umgerechnet in maximal 10 Punkte. | |||
| 1 | Mobiler Validator | Datenblatt mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis KVPT Zertifizierung | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. | |||
| 1 | Mobiler Validator | Nachweis CE-Konformität mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis Umgebungseinflüsse und klimatische Bedinungen mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis elektromagnetische Verträglichkeit mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis Korrisionsschutz mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. |
[Seite 90]
| 1 | Mobiler Validator | Nachweis Zuverlässigkeit mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
|---|---|---|---|---|---|---|---|
| 1 | Mobiler Validator | Nachweis Betriebssicherheit mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis Brandschutz mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis Betriebserlaubnis mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 1 | Mobiler Validator | Nachweis Schwingungs- und Stoßbeanspruchung mobiler Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Dattenblätter stationäre Validatoren | Der Bieter legt den entsprechenden Nachweis bei. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Nachweis CE-Konformität stationärer Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen des Bieters werden als vorläufiger Nachweis akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Nachweis Umgebungseinflüsse und klimatische Bedinungen stationärer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Nachweis elektromagnetische Verträglichkeit stationärer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Nachweis Korrosionsschutz stationärer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Nachweis Zuverlässigkeit stationärer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 2 | Stationärer Validator | Nachweis Betriebssicherheit stationärer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Datenblatt tragbarer Validator | Der Bieter legt den entsprechenden Nachweis bei. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. |
[Seite 91]
| 3 | Tragbarer Validator | Nachweis ISO Standard tragbarer Validator | Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
|---|---|---|---|---|---|---|---|
| 3 | Tragbarer Validator | Nachweis Kartenorganisationen tragbarer Validator | Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Nachweis EMV Zertifizierung tragbarer Validator | Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Nachweis CE-Konformität tragbarer Validator | Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Nachweis PCI-PTS tragbarer Validator | Der Bieter legt die entsprechenden Nachweise für alle betroffenen, notwendigen und aktuellen Zulassungen und Zertifizierungen der Kartenorganisationen für das cEMV UPOS Terminal bei. Eigenerklärungen werden nicht akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Nachweis Stoßfestigkeit tragbarer Validator | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Nachweis Fremdkörper tragbarer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. Für den Fall, dass der Zuschlag beabsichtigt ist, behält sich der AG vor, die entsprechenden Zertifikate einzufordern. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 3 | Tragbarer Validator | Nachweis Falltest tragbarer Validator | Der Bieter legt den entsprechenden Nachweis bei, Eigenerklärungen des Bieters werden akzeptiert. Für den Fall, dass der Zuschlag beabsichtigt ist, behält sich der AG vor, die entsprechenden Zertifikate einzufordern. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 5 | cEMV UPOS Terminal | Datenblatt Anschlüsse cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis bei. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. |
[Seite 92]
| 5 | cEMV UPOS Terminal | Nachweis Kartenorganisationen cEMV UPOS Terminal | Der Bieter legt die entsprechenden Nachweise für alle betroffenen, notwendigen und aktuellen Zulassungen und Zertifizierungen der Kartenorganisationen für das cEMV UPOS Terminal bei. Eigenerklärungen werden nicht akzeptiert. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
|---|---|---|---|---|---|---|---|
| 5 | cEMV UPOS Terminal | Nachweis EMV Zertifizierung cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 5 | cEMV UPOS Terminal | Nachweis PCI-PTS Zertizierung cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 5 | cEMV UPOS Terminal | Nachweis CEN/TS Zulassung cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 5 | cEMV UPOS Terminal | Nachweis IP Schutzklasse cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 5 | cEMV UPOS Terminal | Nachweis IK Schutzklasse cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis bei. Eigenerklärungen werden nicht akzeptiert. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 5 | cEMV UPOS Terminal | Nachweis ISO Standard cEMV UPOS Terminal | Der Bieter legt den entsprechenden Nachweis als Eigenerklärungen bei. Alternativ kann auch ein EMV Level 1 Zertifikat als Nachweis eingereicht werden. Der Nachweis darf nur in Deutscher oder Englischer Sprache beigelegt werden. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. | |||
| 11 | Dienstleistungen | Nachweis Mitwirkungspflichten | Für die Umsetzung des Projekts ist ein strukturiertes Mitwirkungskonzept einzureichen, das Art, Umfang und Zeitpunkte der Mitwirkungspflichten des Auftraggebers eindeutig festlegt. Dazu zählen insbesondere Informationsbereitstellung, Abstimmungen, Freigaben sowie die Beteiligung an Tests und Abnahmen. | Der Nachweis wird nicht bewertet. Eine Nichtabgabe des Nachweises führt zum Ausschluss aus dem Vergabeverfahren. |