TIP1-A_3312 - Nur zugelassene Update-Pakete im Downloadbereich der PU

Der Konfigurationsdienst MUSS sicherstellen, dass nur Update-Pakete in den Downloadbereich der Produktivumgebung der TI (PU) gelangen

• deren Bereitstellung im Downloadbereich der PU durch den SBV-TIP beauftragt wurde und

• die eine Zulassung durch die gematik besitzen.

TIP1-A_5157 - Nur freigegebene Konfigurationsdatenfiles im Downloadbereich der PU

Der Konfigurationsdienst MUSS sicherstellen, dass nur Konfigurationsdatenfiles in den Downloadbereich der Produktivumgebung der TI (PU) gelangen

• deren Bereitstellung im Downloadbereich der PU durch den SBV-TIP beauftragt wurde.

TIP1-A_3313 - Anzahl Update-Pakete pro dezentralem Produkt

Der Konfigurationsdienst MUSS für alle dezentralen Produkte mindestens die Update-Pakete speichern können, die der Hersteller in der aktuellen Firmware-Gruppen-Informationen referenziert. Der Speicherplatz für die Update-Pakete muss skalierbar sein.

TIP1-A_6129 - Bereitzustellende Dateien pro Update-Paket

Der Konfigurationsdienst MUSS für jedes freigegebene Update-Paket die folgenden Dateien im KSR Downloadbereich zur Übertragung mit Operation I_KSRS_Download::getUpdates für den KSR Client bereitstellen:

• Die in UpdateInfo.xml referenzierten Dateien

• Die optionale detached Signatur „UpdateInfo.sig

TIP1-A_3314 - Inhalt Update-Paket – Hersteller-Update-Informationen

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN in jedem Firmware-Update-Paket ein File mit Namen UpdateInfo.xml mit Hersteller-Update-Informationen gemäß Element UpdateInformation aus Konfigurationsdienst.xsd (siehe auch Abbildung Abb_KSR_005 und Tabellen Tab_KSR_004-009, Tab_KSR_012-020) liefern.

TIP1-A_3895 - Inhalt Update-Paket – Konnektor FirmwareFiles

Hersteller von Konnektoren MÜSSEN in jedem Firmware-Update-Paket 0 bis maximal 999 Firmwarefile(s) liefern.

TIP1-A_5158 - Inhalt Update-Paket – Kartenterminal FirmwareFiles

 Hersteller von Kartenterminals MÜSSEN in jedem Firmware-Update-Paket genau ein Firmware File liefern.
[<=]

TIP1-A_3315 - Inhalt Update-Paket – DokumentationFiles

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN in jedem Firmware-Update-Paket bis maximal 999 Files mit Dokumentationen für das Update liefern.

TIP1-A_5159 - Inhalt Update-Paket – Firmware-Gruppen-Information

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN in jedem Firmware-Update-Paket ein File mit der aktuell gültigen Firmware-Gruppen-Information gemäß „Abb_KSR_007 Firmware-Gruppen-Informationen“ liefern. Diese Firmware-Gruppen-Information muss der im Firmwarefile enthaltenen Information entsprechen.

TIP1-A_3347 - Integrität und Authentizität

Der Konfigurationsdienst MUSS die Integrität und Authentizität der durch den Hersteller von Komponenten, die den KSR nutzen, übermittelten Update-Pakete (Gesamtpaket) bis zur Übertragung an den KSR-Client durch die Prüfung der Update-Paket – Signatur (TIP1-A_6123) gewährleisten.

TIP1-A_6777 - KSR, Hersteller von Konnektoren, Deadline und alternative URL

Hersteller von Konnektoren MÜSSEN im Update-Paket in der Datei UpdateInfo.xml im Element KSR:FirmwareReleaseNotes eine URL für einen separaten Downloadpunkt des Update-Pakets im Internet angeben und, wenn das Element KSR:Priority den Wert „Kritisch“ hat, im Element UpdateInformation das Element KSR:Deadline mit einem gültigen Wert befüllen.

TIP1-A_6778 - KSR, SBV-TIP, Deadline und alternative URL

Der SBV-TIP MUSS im Rahmen der Freigabe eines Konnektor-Update-Pakets für die PU prüfen, dass das Update-Paket in der Datei UpdateInfo.xml im Element KSR:FirmwareReleaseNotes eine URL für einen separaten Downloadpunkt des Update-Pakets im Internet enthalten ist und, wenn das Element KSR:Priority den Wert „Kritisch“ hat, im Element UpdateInformation das Element KSR:Deadline mit einem gültigen Wert enthalten ist.

Wenn die Deadline (bei KSR:Priority = „Kritisch“) oder die URL nicht enthalten sind, muss die Freigabe abgelehnt werden.

TIP1-A_3896 - Signatur der Update-Informationen durch Konnektorhersteller

Konnektorhersteller MÜSSEN die Update-Informationen (UpdateInfo.xml) signieren. Dazu kann er das Element UpdateInformationSignature in den Update-Informationen oder eine detached Signatur nutzen.

TIP1-A_3897 - Keine Signatur der Update-Informationen durch Kartenterminalhersteller

Kartenterminalhersteller SOLLEN die Update-Informationen (UpdateInfo.xml) NICHT signieren.

TIP1-A_3316 - Firmware-Gruppenkonzept Informationen für den Konfigurationsdienst

Der Hersteller einer dezentralen Komponente, welche das Firmware-Gruppenkonzept unterstützt und Firmware an den Konfigurationsdienst liefert, MUSS dem Konfigurationsdienst Informationen über die aktuelle Firmware-Gruppe bereitstellen.
Der Hersteller MUSS für die aktuelle Firmware-Gruppe folgende Informationen bereitstellen:

Abbildung 10: Abb_KSR_007 Firmware-Gruppen-Informationen

Tabelle 22: Tab_KSR_021 Firmware-Gruppen-Information – Element FirmwareGroupID

Tabelle 23: Tab_KSR_022 Firmware-Gruppen-Information – Element FirmwareGroupVersion

Tabelle 24: Tab_KSR_023 Firmware-Gruppen-Information – Element FirmwareGroupReleaseNotes

Tabelle 25: Tab_KSR_024 Firmware-Gruppen-Information – Element FirmwareGroupSignature

TIP1-A_6131 - FirmwareGroupInfo.xml und UpdateInfo.xml - Format

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die Datei FirmwareGroupInfo.xml und UpdateInfo.xml nach folgenden Vorgaben prüfen bzw. bereitstellen:

• Die Datei verwendet das charset-encoding „UTF-8“

• Die Datei definiert den Namespace http://ws.gematik.de/ksr/v1.1 als Default-Namespace.

• Es ist keine „schemaLocation“ enthalten. Die Validierung erfolgt ausschließlich mit lokalen Schemadateien im jeweiligen System.

• Die Datei kann erfolgreich gegen das XSD-Schema „Konfigurationsdienst.xsd“ validiert werden.

TIP1-A_3317 - Firmware-Gruppenkonzept – Lieferung mit Firmware

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die Firmware-Gruppen-Information zusammen mit dem Firmware-Update, welches die neue Firmware-Gruppe enthält an den Konfigurationsdienst übergeben.

TIP1-A_3908 - Firmware-Gruppenkonzept – Streichung Firmware

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN eine aktualisierte Firmware-Gruppen-Information an den Konfigurationsdienst übergeben, wenn eine bisher enthaltene Firmwareversion ungültig (z.B. Sicherheitsproblem, fehlerhafte Firmware, nicht mehr unterstützte Firmware,…) wird.

TIP1-A_3318 - Firmware-Gruppenkonzept – Lieferung ohne Firmware

Hersteller von Komponenten, die den KSR nutzen, KÖNNEN die Firmware-Gruppen-Information ohne Zusammenhang zu einem Firmware-Update an den Konfigurationsdienst übergeben, falls zu dieser Firmware-Gruppen-Information kein Firmware-Update gehört.

TIP1-A_3319 - Firmware-Gruppenkonzept – Aktive Firmware-Gruppen-Information

Der Konfigurationsdienst MUSS für jedes Produkt vom Produkttyp Konnektor und eHealth-Kartenterminal genau eine „aktive“ Firmware-Gruppen-Information verwalten.

Ein Produkt ist eindeutig identifiziert über die Attribute

• Hersteller-/Anbieter-ID

• Produktkürzel

• Hardwareversion.

TIP1-A_3320 - Firmware-Gruppenkonzept - Übernahme Firmware-Gruppe

Der Konfigurationsdienst MUSS die in einem Update enthaltene bzw. einzeln gelieferte Firmware-Gruppen-Information übernehmen, wenn

• eine Freigabe für das Update-Paket, welches die Firmware-Gruppen-Information enthält, bzw. die einzeln gelieferte Firmware-Gruppen-Information vorliegt und

• die Firmware-Gruppen-Information eine höhere Versionsnummer hat als die der aktuell vorliegenden Firmware-Gruppen-Information und

• Integrität und Authentizität der Firmware-Gruppen-Information erfolgreich geprüft wurde.

TIP1-A_3321 - Firmware-Gruppenkonzept – Unterstützte Firmware Versionen

Der Konfigurationsdienst MUSS für jedes Produkt ausschließlich die Firmware-Versionen der „aktiven“ Firmware-Gruppen-Information zum Download anbieten.

TIP1-A_3322 - Firmware-Gruppenkonzept – Integritäts- und Authentizitätsschutz

Der Konfigurationsdienst MUSS – zusammen mit dem Hersteller von Komponenten, die den KSR nutzen, – die Integrität und Authentizität der Firmware-Gruppen-Information für die gesamte Lebenszeit dieser Informationen gewährleisten.

TIP1-A_6108 - FirmwareGroupInfo.xml Signatur

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN die Detached-Signature der FirmwareGroupInfo.xml und das in TIP1-A_6133 definierte FirmwareGroupInfo.xml - Element „FirmwareGroupSignature“ unterstützen bzw. prüfen.  

TIP1-A_6132 - Detached-Signature der FirmwareGroupInfo.xml

Bei Verwendung einer Detached-Signatur MÜSSEN Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst eine Detached-Signature (UTF-8-kodierte XML-Datei) zur Datei „FirmwareGroupInfo.xml“ mit folgenden Eigenschaften bereitstellen bzw. prüfen:

• Die Signatur hat die XAdES-Form. Optionale XAdES-Attribute sind erlaubt, werden aber bei der Signaturprüfung ignoriert.

• Die Signatur erfolgt über das gesamte XML-Dokument nach Kanonisierung. Ein etwaig angegebenes URI-Attribut des zugehörigen Reference-Elements wird bei der Signaturprüfung akzeptiert, aber nicht geprüft.

• Es werden alle Kanonisierungsverfahren gemäß [XML-DSIG] unterstützt.

• Eine Transformationsvorschrift im Reference-Element über das Dokument

<ds:Transform Algorithm=""http://www.w3.org/2000/09/xmldsig#enveloped-signature""></ds:Transform>

wird akzeptiert, aber nicht verlangt und bei der Prüfung ignoriert.

• Die Signatur enthält das Signierer-Zertifikat im XML-Block des XML-Elementes KeyInfo.

• Die Signatur ist konform mit der Anforderung [gemSpec_Krypt# GS-A_4370] und verwendet den Signatur-Algorithmus "RSASSA-PKCS1-v1_5 mit SHA256" oder "RSASSA-PSS mit SHA256". Die Signatur-Algorithmen sind in der [gemSpec_Krypt# GS-A_4371] definiert.

• Für die Signatur ist das gleiche Zertifikat zu verwenden mit dem auch das Update-Paket signiert ist.

TIP1-A_6133 - FirmwareGroupInfo.xml - Element „FirmwareGroupSignature“

Bei Verwendung des Elements „FirmwareGroupSignature“ in der Datei „FirmwareGroupInfo.xml“ MÜSSEN Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst den Inhalt nach folgender Vorgabe bereitstellen bzw. prüfen:

• Die Signatur wurde als Detached-Signature [TIP1-A_6132] erstellt.

• Die erstellte Signatur wurde in einer UTF-8 kodierte XML-Datei gespeichert und diese als Base64-Codierter String in das Feld „FirmwareGroupSignature“ geschrieben.

TIP1-A_5154 - Konfigurationsdatenfiles zur Anbindung von Bestandsnetzen

Der Anbieter des Konfigurationsdienstes MUSS für die über Aufträge bereitgestellten Konfigurationsdaten zur Anbindung von Bestandsnetzen Konfigurationsdatenfiles erstellen. Die Konfigurationsdatenfiles MÜSSEN auf dem XML-Schema [InfrastrukturKonfig.xsd] entsprechend Abb_KSR_014 basieren und den Vorgaben aus Tabelle Tab_KSR_045 genügen.

TIP1-A_6134 - Konfigurationsdatenfile - Format

Der Konfigurationsdienst DARF NICHT von folgenden Vorgaben abweichende Formate akzeptieren:

• Die Datei verwendet das charset-encoding „UTF-8“

• Es ist keine „schemaLocation“ enthalten. Die Validierung erfolgt ausschließlich mit lokalen Schemadateien im jeweiligen System.

• Die Datei kann erfolgreich gegen das XSD-Schema „InfrastrukturKonfig.xsd“ validiert werden.

TIP1-A_3323 - Konfigurationsdienst TLS-Authentisierung

Der Konfigurationsdienst MUSS bei der Absicherung der Verbindung zum Konnektor durch TLS die einseitige Serverauthentisierung unter Nutzung des X.509-Komponentenzertifikats mit der TLS-Server-Identität ID.ZD.TLS_S zur Serverauthentisierung umsetzen.

TIP1-A_3324 - Konfigurationsdienst TLS-Zertifikatserstellung

Der Anbieter des Konfigurationsdienstes MUSS beim zuständigen PKI-Registrierungsdienst über die Schnittstelle I_Cert_Provisioning [gemKPT_Arch_TIP] das X.509-Komponentenzertifikat mit der TLS-Server-Identität ID.ZD.TLS_S zur TLS Serverauthentisierung beantragen.

TIP1-A_3325 - Konfigurationsdienst Keine Verbindungen ohne TLS

Der Konfigurationsdienst MUSS an der Schnittstelle zum Konnektor ausschließlich Verbindungen mit TLS akzeptieren.

TIP1-A_3326 - IPv4 und Ipv6 Unterstützung

Der Konfigurationsdienst MUSS IPv4 und IPv6 parallel unterstützen (Dual-Stack-Modus).

TIP1-A_6130 - Bereitstellung DNS Resource Records

Der Anbieter des KSR MUSS SRV und optional TXT Resource Records im DNS bereitstellen. Wenn die TXT Resource Records nicht existieren MÜSSEN die <PFAD1> und <PFAD2> Anteile der URL leere Strings sein.
Im DNS sind dazu folgende Einträge durch den KSR Anbieter einzutragen:

Owner                                  TTL Class Type Data
_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL1> <IN> <SRV> <Priorität1>  <Gewicht1>  <Port1>  <FQDN1>
_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL2> <IN> <TXT> "txtvers=<VERSION1>" "path=<PFAD1>"
_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL3> <IN> <SRV> <Priorität2>  <Gewicht2>  <Port2>  <FQDN2>
_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI> <TTL4> <IN> <TXT> "txtvers=<VERSION2>" "path=<PFAD2>"

TOP_LEVEL_DOMAIN_TI: in der PU = telematik.; in der RU/TU = telematik-test.
[<=]

TIP1-A_3328 - Logging Datenänderungen im Konfigurationsdienst

Der Konfigurationsdienst MUSS für alle Aktionen (sowohl intern wie auch an den Außenschnittstellen) mit Update-Paketen und Firmware-Gruppen-Informationen und Konfigurationsdatenfiles Log-Informationen erfassen. Dabei MUSS mindestens folgende Information gespeichert/bereitgestellt werden:

• Wer hat etwas getan

• Was hat er getan

• Mit welchem Informationsobjekt

• Zeitpunkt der Aktion  

TIP1-A_6135 - Löschen der Logging-Daten

Der Konfigurationsdienst MUSS die gesammelten Logging-Daten nach einer konfigurierten Zeitspanne, spätestens aber nach 90 Tagen aus dem Konfigurationsdienst entfernen.
[<=]

TIP1-A_6136 - Umfang der gespeicherten Logdaten

Der Konfigurationsdienst MUSS die in Tabelle 26 „Logdatenformat“ enthaltenen Felder entsprechend ihrer Definition füllen und persistent speichern.

Tabelle 26 Tab_KSR_048 Logdatenformat

Tabelle 27 Tab_KSR_049 Werte im Feld InfoID zu Action

TIP1-A_6102 - Datei-Format Logging- und Statistik-Daten

Der Konfigurationsdienst MUSS die Logging- und Statistik-Daten im CSV-Format bereitstellen.

• Die Datei verwendet UTF-8 Codierung
  
• Die Zeilenenden schließen mit dem LF-Zeichen (0x10) ab.
  
• Das Trennzeichen zwischen den Werten ist „;“
  

TIP1-A_5038 - FehlerLog

Der Konfigurationsdienst MUSS lokal erkannte Fehler und Remote-Fehler im lokalen Protokollspeicher (FehlerLog) protokollieren.

TIP1-A_5039 - Remote-Fehlerbehandlung

Der Konfigurationsdienst MUSS für empfangene Fehlermeldungen von anderen Komponenten folgende allgemeine Vorgaben berücksichtigen:

• Empfangene Fehlermeldungen sind als Remote-Fehler zu protokollieren.

• Durch empfangene Fehlermeldungen resultierende Folgefehler KÖNNEN an die Fehlermeldung angefügt werden.

TIP1-A_3353 - Inhalt der statistischen Daten

Der Anbieter des Konfigurationsdienstes MUSS in den statistischen Daten des Konfigurationsdienstes, die pro Produkt im Downloadbereich angefragten Updates (Operation I_KSRS_Download::listUpdates inklusive aller Parameter des Requests) und bereitgestellten Updates (Operation I_KSRS_Download::getUpdates inklusive UpdateID und Filename) inklusive aller Anfragen bei KSR Download Cache Servern, aufgeschlüsselt nach Produkt und Update-Paket (Element „UpdateID“) im zeitlichen Verlauf entsprechend Tab_KSR_046 auflisten.

Tabelle 28: Tab_KSR_046 Statistikdatenformat

TIP1-A_3354 - KSR-Statistiken – Format

Der Anbieter des Konfigurationsdienstes MUSS alle Download-Berichte und Berichte über die listUpdates Abfragen im CSV-Format bereitstellen. Die CSV-Datei MUSS im durch TIP1-A_3353 definierten Format vorliegen.

TIP1-A_5040 - Schlüssel sicher speichern

Der Konfigurationsdienst MUSS Schlüssel sicher speichern und ihr Auslesen verhindern.

TIP1-A_3909 - Bereitstellung I_KSRS_Download

Der Konfigurationsdienst MUSS für Clients den Dienst I_KSRS_Download entsprechend der Tabelle Tab_KSR_025 bereitstellen.

Tabelle 29: Tab_KSR_025 Konfigurationsdienst

TIP1-A_6103 - SOAP-Version

Der Konfigurationsdienst und der Konnektor (KSR-Client) MÜSSEN ausschließlich „SOAP über http“, Version 1.1 für ihre Kommunikation verwenden.
[<=]

TIP1-A_3330 - I_KSRS_Download::listUpdates

Der Konfigurationsdienst MUSS die logische Operation listUpdates entsprechend der Tabelle Tab_KSR_026 implementieren.

Tabelle 30: Tab_KSR_026 Operation I_KSRS_Download::listUpdates

TIP1-A_3331 - I_KSRS_Download::listUpdates Request

Für den Konfigurationsdienst MUSS die Operation I_KSRS_Download::listUpdates Request mit folgenden Parametern bereitstellen:

Abbildung 12: Abb_KSR_008 Operation I_KSRS_Download::listUpdates Request

Tabelle 31: Tab_KSR_027 I_KSRS_Download::listUpdates Request

Tabelle 32: Tab_KSR_028 Hersteller-Update-Informationen – Element ProductVendorID

Tabelle 33: Tab_KSR_029 Hersteller-Update-Informationen – Element ProductCode

Tabelle 34: Tab_KSR_030 Hersteller-Update-Informationen – Element HWVersion

Tabelle 35: Tab_KSR_031 Hersteller-Update-Informationen – Element FWVersion

TIP1-A_3332 - I_KSRS_Download::listUpdates Response

Der Konfigurationsdienst MUSS die Operation I_KSRS_Download::listUpdates Response mit folgenden Parametern (siehe Abb_KSR_009, Tab_KSR_032, Tab_KSR_033, Tab_KSR_034) bereitstellen:

Abbildung 13: Abb_KSR_009 Operation I_KSRS_Download::listUpdates Response

Tabelle 36: Tab_KSR_032 I_KSRS_Download::listUpdates – Response

Tabelle 37: Tab_KSR_033 I_KSRS_Download::listUpdates – Element FirmwareGroupReleaseNotes

Tabelle 38: Tab_KSR_034 I_KSRS_Download::listUpdates – Element UpdateInformation

TIP1-A_3333 - Konfigurationsdienst SOAP-Fehlercodes

Der Konfigurationsdienst MUSS für seine SOAP-Schnittstelle die generischen Fehlercodes

• Code 2: Verbindung zurückgewiesen

• Code 3: Nachrichtenschema fehlerhaft

• Code 4: Version Nachrichtenschema fehlerhaft

• Code 6: Protokollfehler

aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM] im SOAP-Fault verwenden. Erkannte Fehler auf Transportprotokollebene müssen auf gematik SOAP Faults (Code 6 aus Tabelle Tab_Gen_Fehler aus [gemSpec_OM]) abgebildet werden.

TIP1-A_3334 - I_KSRS_Download::getUpdates

Der Konfigurationsdienst MUSS die Operation I_KSRS_Download::getUpdates für die Übertragung von Aktualisierungspaketen an dezentrale Komponente der TI-Plattform durch den Konfigurationsdienst entsprechend Tabelle Tab_KSR_035 bereitstellen.

Tabelle 40: Tab_KSR_035 Operation I_KSRS_Download::getUpdates

TIP1-A_5160 - I_KSRS_Download::get_Ext_Net_Config

Der Konfigurationsdienst MUSS die Operation I_KSRS_Download::get_Ext_Net_Config für die Übertragung von Konfigurationsdatenfiles an dezentrale Komponenten der TI-Plattform durch den Konfigurationsdienst entsprechend Tabelle Tab_KSR_044 bereitstellen.

Tabelle 41: Tab_KSR_044 Operation I_KSRS_Download::get_Ext_Net_Config

TIP1-A_5375 - Filename des Konfigurationsdatenfiles zur Anbindung von Bestandsnetzen

Der Konfigurationsdienst MUSS das Konfigurationsdatenfile zur Anbindung von Bestandsnetzen unter dem Filenamen „Bestandsnetze.xml“ zum Download bereitstellen.

TIP1-A_5161 - TUC_KSR_001 „Get File“

Der Konfigurationsdienst MUSS den technischen Use Case für die Übertragung von Files an dezentrale Komponente der TI-Plattform durch den Konfigurationsdienst entsprechend Tabelle Tab_KSR_043 TUC_KSR_001 „Get File“ bereitstellen.

Tabelle 42: Tab_KSR_043 TUC_KSR_001 „Get File“

TIP1-A_3335 - Konfigurationsdienst File Transfer HTTP Request

Der Konfigurationsdienst MUSS den Download eines Files mit einem http GET unterstützen. Dafür MUSS ein http URL-Schema entsprechend [RFC1738] sowie Tabellen Tab_KSR_036 und Tab_KSR_037 unterstützt werden:

https://<host>/<path>

Tabelle 43: Tab_KSR_036 File Transfer HTTP Request – Element host

Tabelle 44: Tab_KSR_037 File Transfer HTTP Request – Element path

TIP1-A_3336 - File Transfer HTTP Response

Der Konfigurationsdienst MUSS in das http-Response die notwendigen http-Header-Datenfelder gemäß [RFC2616] aufnehmen. Im http-Body MUSS der Konfigurationsdienst das angeforderte File zurückgeben.

TIP1-A_4120 - File Transfer HTTP Status Codes

Der Konfigurationsdienst MUSS die http Status Codes entsprechend [RFC2616] unterstützen.

TIP1-A_5162 - http Status Code „Retry After“

Wenn der Konfigurationsdienst den getUpdates Request wegen temporärer Überlast oder Maintenance nicht verarbeiten kann, MUSS er den http Status Code 503 Server Unavailable an den Client zurückgeben. Falls dem Konfigurationsdienst der Zeitraum der Nichtverfügbarkeit bekannt ist, SOLL er den Retry-After Header zur Information des Clients nutzen. Der Retry-After Header KANN ebenfalls bei Überlast zur zeitlichen Lastverteilung genutzt werden.

TIP1-A_3910 - Konfigurationsdienst File Transfer http Komprimierung

Der Konfigurationsdienst MUSS die Komprimierung des File Transfers über http unterstützen. Dazu muss er das „Content Coding“ [RFC2616] „gzip“ implementieren.

TIP1-A_7221 - Konfigurationsdienst File Transfer Range Requests

Der Konfigurationsdienst MUSS für den File Transfers über http die Option Range Requests [RFC7233#3.1] zur Fortsetzung von unterbrochenen Transfers unterstützen. [<=]

TIP1-A_6104 - KSR Download Cache Server

Der Konfigurationsdienst MUSS für jeden SZZP der VPN-Zugangsdienste einen KSR Download Cache Server vorsehen. Jeder einzelne dieser KSR Download Cache Server MUSS dabei autark laufen und sich eigenständig synchronisieren. Für die zentralen Komponenten des Konfigurationsdienstes MUSS das Vorhandensein und die Anzahl von KSR Download Cache Servern transparent sein.

Die KSR Download Cache Server MÜSSEN folgende Eigenschaften haben:

• Jede Instanz MUSS separat in den Umgebungen deploybar sein.

• Jede Instanz MUSS eine eigene lokale Datenhaltung besitzen.

• Jede Instanz MUSS die Anfragen dezentraler Komponenten ohne die Kommunikation mit anderen Instanzen beantworten können.

TIP1-A_6105 - KSR Download Cache Server Transparenz

Der Konfigurationsdienst MUSS für die dezentralen Komponenten die Transparenz der KSR Cache Server sicherstellen. Mit den KSR Download Cache Servern MUSS die gleiche Schnittstelle I_KSRS_Download bereitgestellt werden wie sie der KSR selbst unterstützt. Der Konfigurationsdienst MUSS sicherstellen, dass Hinzufügen, Entfernen und Ausfall (Redundanzfall) eines KSR Download Cache Servers keinerlei Anpassungen in dezentralen Komponenten erfordert.

TIP1-A_6106 - KSR Download Cache Server Redundanz

Der Konfigurationsdienst MUSS für die KSR Download Cache Server eine redundante Lösung vorsehen. Der Konfigurationsdienst MUSS sicherstellen, dass Aktivieren und Deaktivieren der Redundanzlösung keinerlei Anpassungen in dezentralen Komponenten erfordert.

TIP1-A_6125 - KSR Störungsampel Monitoringdaten

Der Konfigurationsdienst MUSS für alle seine Komponenten inklusive der KSR Download Cache Server Monitoringdaten an die Störungsampel senden [gemSpec_St_Ampel] (Schnittstelle I_Monitoring_Update).

TIP1-A_6109 - KSR Nutzung des zentralen Netzes während Redundanz

Der Konfigurationsdienst KANN während des Ausfalls eines KSR Download Cache Servers für die Übertragung der Update-Pakete zu den dezentralen Komponenten das zentrale Netz verwenden.

TIP1-A_6107 - Bereitstellung Registrierungsinterface

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Akteuren die Registrierung für die Nutzung der organisatorischen KSR-Schnittstellen ermöglichen und ihnen die nötigen Zugangsdaten bereitstellen.
[<=]

TIP1-A_6110 - Authentisierung und Autorisierung

Der Konfigurationsdienst MUSS Akteure der organisatorischen KSR-Schnittstellen authentisieren und autorisieren.

TIP1-A_6111 - Gruppen und Berechtigungen

Der Konfigurationsdienst MUSS den Akteuren der organisatorischen KSR-Schnittstellen jeweils Rollen gemäß ihrer Gruppenzugehörigkeit und Umgebung entsprechend Tab_KSR_011 zuweisen.

Tabelle 45 Tab_KSR_011 Gruppen und Berechtigungen

TIP1-A_3342 - Bereitstellung P_KSRS_Upload

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Herstellern dezentraler Komponenten der TI, dem Servicebetriebsverantwortlichen TI-Plattform (PU) und den Testbetriebsverantwortlichen TU/RU eine Möglichkeit zum Übermitteln von Update-Paketen und zugehörigen Firmware-Gruppen-Informationen entsprechend Tabelle Tab_KSR_039 zur Verfügung stellen (P_KSRS_Upload).

Tabelle 47: Tab_KSR_039 P_KSRS_Upload Schema

TIP1-A_3343 - Berechtigung P_KSRS_Upload

Der Anbieter des Konfigurationsdienstes MUSS sicherstellen, dass nur berechtigte Akteure (berechtigte Hersteller von Komponenten, die den KSR nutzen, Servicebetriebsverantwortlicher TI-Plattform (PU), Testbetriebsverantwortlicher TU und Testbetriebsverantwortlicher RU) auf P_KSRS_Upload der jeweiligen Umgebung zugreifen können.

TIP1-A_3348 - Form und Inhalt Upload-Interface

Der Anbieter des Konfigurationsdienstes MUSS die Form  des Upload-Interfaces  definieren und mit den berechtigten Akteuren abstimmen.

TIP1-A_5042 - P_KSRS_Upload parallel nutzbar

Der Konfigurationsdienst SOLL die Kommunikationsschnittstelle von KSR-Upload so implementieren, dass sie parallel durch mehrere Aufrufer nutzbar ist.

TIP1-A_3345 - KSR Logging – Upload-Interface

Der Konfigurationsdienst MUSS mindestens für folgende Vorgänge Logging-Daten erfassen:

• Upload von Update-Paketen und Firmware-Gruppen-Informationen

• Ergebnis der Eingangsprüfung

Ein Log-Eintrag MUSS mindestens folgende Informationen erfassen:

• Wer hat etwas getan

• Was wurde getan

• Zeitpunkt

• Updatepaket.UpdateInformation.UpdateID bzw. FirmwareGroupInformation.FirmwareGroupID

TIP1-A_6065 - KSR Fortschrittsinformation im Interface P_KSRS_Upload

Der Konfigurationsdienst MUSS während des Übermittelns von Update-Paketen den Nutzer über den Fortschritt des Filetransfers informieren.

TIP1-A_3346 - Eingangsprüfung

Der Konfigurationsdienst MUSS die übermittelten Update-Pakete und Firmware-Gruppen-Informationen einer Eingangsprüfung unterziehen.

Die Eingangsprüfung MUSS folgende Prüfungen enthalten:

• Prüfung der Integrität und Authentizität

  • Die Signatur des Update-Paketes muss beim Übergang zwischen Upload-Bereich und Konfigurationsbereich geprüft werden. Die Prüfung muss mindestens die folgende Schritte umfassen:

    • Prüfung der Gültigkeit des Zertifikats über den zuständigen OCSP-Responder,

    • Prüfung der Zertifikatstyp-OID auf Zulässigkeit,

    • Prüfung der mathematischen Korrektheit des Zertifikats.

  • Die Integrität des ZIP-Containers

  • Der Konfigurationsdienst MUSS – im Sinne Integrität und Authentizität - fehlerhafte Update-Pakete ohne weitere Prüfung ihrer Inhalte  ablehnen.

• Prüfung auf syntaktische Korrektheit (Update-Informationen und Firmware-Gruppen-Informationen)

  • Sofern die Datei UpdateInfo.xml im Container enthalten ist, wird die XML-Struktur validiert. Die in dem Element „Files“ angegebenen Dateien müssen im Container enthalten sein, die Pfadangaben müssen dem in Anforderung „TIP1-A_6122 Pfadreferenz“ definiertem Format entsprechen. Alle Pflichtfelder müssen mit korrekten Werten belegt sein, die angegebene ProductVendorID muss mit der ID des übertragenden Herstellers identisch sein, außer es handelt sich um ein Update-Paket, das durch den TBV/SBV-TIP eingestellt wurde.

  • Die Datei „FirmwareGroupInfo.xml“ wird mit dem XSD-Schema validiert und sichergestellt, dass die Version aktueller ist, als die bereits vorhandene.

• Prüfung auf Vollständigkeit (Vorhandensein aller aus den Update-Informationen referenzierten Files)

  • Das Update-Paket wird geöffnet und festgestellt, dass alle notwendigen Dateien im ZIP-Container enthalten sind. (FirmwareGroupInfo.xml, optional UpdateInfo.xml)

  • Es dürfen nicht mehr Dateien im Container enthalten sein, als die in 6.2.3.1 definierten Elemente. Die Firmware- und Dokumentationsdateien müssen alle durch UpdateInfo.xml referenziert werden. Update-Pakete mit Dateien ohne Referenz werden abgelehnt. Die optionalen detached Signaturen „UpdateInfo.sig“ und „FirmwareGroupInfo.sig“ können – ohne Referenz - im Update-Paket enthalten sein.

• Prüfung ob der eingeloggte Nutzer die Berechtigung hat das Update-Paket zu übermitteln. Der Nutzer muss zu der Organisation gehören welche das Update-Paket signiert hat oder die TBV bzw. SBV Rolle für die jeweilige Umgebung besitzen.

TIP1-A_6112 - Name des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN den Dateinamen so wählen, das er dem Pattern „[A-Za-z0-9_-.]*“ entspricht und nicht länger als 32 Zeichen ist und der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen.

TIP1-A_6113 - Definition Update-Paket-Struktur

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN Update-Pakete mit den in Tab_KSR_010 (Struktur Update-Paket) definierten Elementen in Form eines ZIP-Containers nach dem Standard [ZIP-APP] erzeugen und der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen.

TIP1-A_6114 - Passwort des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, DÜRFEN NICHT den ZIP-Container mit einem Passwort schützen und der Konfigurationsdienst DARF NICHT passwortgeschützte ZIP-Container akzeptieren.

TIP1-A_6115 - Größe des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, DÜRFEN NICHT Update-Pakete hochladen, deren entkomprimierte Paketgröße den abgestimmten Maximalwert übersteigt und der Konfigurationsdienst DARF NICHT Update-Pakete akzeptieren welche diesen Maximalwert übersteigen.
[<=]

TIP1-A_7253 - KSR – Konfigurierbare Maximalgröße von Update-Paketen

Der Konfigurationsdienst MUSS die Konfiguration der maximalen Größe von Update-Paketen erlauben. Der initiale Wert für diesen Konfigurationsparameter MUSS 1500 Mbyte betragen. Die Änderung des Wertes dieses Konfigurationsparameters durch die gematik MUSS ermöglicht werden. [<=]

TIP1-A_7346 - KSR – Löschen von deaktivierten Update-Paketen

Der Konfigurationsdienst SOLL bei Deaktivierung von Update-Paketen die – vom Hersteller gelieferten – Daten des Update-Paketes im Konfigurationsdienst löschen und die im Konfigurationsdienst vorhandenen Metadaten (Daten über das Update-Paket, welche im GUI angezeigt oder in Logfiles und Reports enthalten sind) entsprechend der vorgegebenen Speicherdauer für diese Daten weiterhin zur Verfügung stellen. [<=]

TIP1-A_7347 - KSR – Anzahl Update-Pakete

Der Konfigurationsdienst MUSS pro Hersteller von dezentralen Produkttypen mindestens 10 Update-Pakete speichern und zum Download anbieten können.
Diese Anzahl muss erweiterbar sein. [<=]

TIP1-A_6116 - Update-Paket - Dateinamen und Unterverzeichnisse

Der Konfigurationsdienst und Hersteller von Komponenten, die den KSR nutzen, MÜSSEN folgende Vorgaben im ZIP-Container gewährleisten und fehlerhafte Update-Pakete MÜSSEN abgelehnt werden:

• Die Dateinamen innerhalb des Paketes sind eindeutig.

• Es existieren keine Unterverzeichnisse innerhalb des ZIP-Containers.

TIP1-A_6117 - Referenzierungen des Update-Paketes

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN Update-Pakete erstellen, in denen alle Firmware- und Dokumentationsdateien in der Datei UpdateInfo.xml referenziert werden.

Der Konfigurationsdienst MUSS die Update-Pakete auf die Referenzierung aller Firmware- und Dokumentationsdateien in der Datei UpdateInfo.xml prüfen und fehlerhafte Update-Pakete ablehnen.

TIP1-A_6118 - Zusätzliche Dateien im Update-Paket

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN das Update-Paket so erstellen, das nur die in Tab_KSR_010 definierten Elemente in ihr enthalten sind.

Der Konfigurationsdienst MUSS prüfen, dass Update-Pakete nur die in Tab_KSR_010 definierten Elemente enthalten und fehlerhafte Update-Pakete ablehnen.

TIP1-A_6119 - Update-Paket – Übertragung „Firmware-Gruppen-Information“

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN, sofern es sich um ein Update einer Firmware-Gruppen-Information ohne neue Firmware handelt, das Update-Paket ausschließlich mit dem Element „Firmware-Gruppen-Information“ und dem optionalen Element „FirmwareGroupInfo-Signature“ füllen.

Der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen und fehlerhafte Update-Pakete ablehnen.

TIP1-A_6120 - Update-Paket – Dateinamen der UpdateInformation Detached-Signatur

Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst MÜSSEN, sofern das Update-Paket eine Detached-Signatur der Datei UpdateInfo.xml enthält, die Signatur in der Datei mit dem Namen „UpdateInfo.sig“ erstellen bzw. prüfen und fehlerhafte Update-Pakete ablehnen.

TIP1-A_6121 - Update-Paket – Dateinamen der FirmwareGroupInfo Detached-Signatur

Hersteller von Komponenten, die den KSR nutzen, und der Konfigurationsdienst MÜSSEN, sofern das Update-Paket eine Detached-Signatur der Datei FirmwareGroupInfo.xml enthält, die Signatur in der Datei mit dem Namen „FirmwareGroupInfo.sig“ erstellen bzw. prüfen und fehlerhafte Update-Pakete ablehnen.

TIP1-A_6128 - Vollständige Update-Pakete

Der Konfigurationsdienst DARF unvollständige Update-Pakete NICHT verarbeiten.
[<=]

TIP1-A_6122 - Pfadreferenz

Hersteller von Komponenten, die den KSR nutzen, MÜSSEN alle Pfadangaben nach folgenden Vorgaben erstellen, der Konfigurationsdienst MUSS die Einhaltung dieser Definition prüfen und fehlerhafte Update-Pakete ablehnen:

• Schema: /<ProductVendorId>/<ProductCode>/<UpdateID>/<Filename>

• Als Trennzeichen muss das Zeichen „/“ verwendet werden.

• <Filename> entspricht dem Pattern „[A-Za-z0-9_-.]*“  und ist nicht länger als 32 Zeichen.

TIP1-A_6123 - Update-Paket – Signatur

TIP1-A_6124 - Bereitstellung KSR Update-Paket Zertifikat

Der KSR-Anbieter MUSS für die Hersteller dezentraler Komponenten X.509-Zertifikate und zugehörige private Schlüssel zum Signieren der Update-Pakete bereitstellen und ihnen Vorgaben machen wie diese Zertifikate beantragt werden können. Hersteller von Komponenten, die den KSR nutzen, MÜSSEN den privaten Schlüssel des bereitgestellten X.509-Zertifikats zum Signieren ihrer Update-Pakete verwenden.
[<=]

TIP1-A_6127 - Fehlerhafte Signaturen

Der Konfigurationsdienst DARF Pakete mit einer fehlerhaften oder nicht verifizierten Signatur NICHT weiter verarbeiten.
[<=]

TIP1-A_6066 - KSR Bereitstellung "Signier-Tool"

Der Anbieter des Konfigurationsdienstes MUSS berechtigten Herstellern dezentraler Komponenten der TI, dem Servicebetriebsverantwortlichen TI-Plattform (PU) und den Testbetriebsverantwortlichen TU/RU ein Tool zur Signatur von Update-Paketen bereitstellen.
[<=]

TIP1-A_3349 - Organisatorische Schnittstelle zur Erteilung von Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS eine Schnittstelle bereitstellen, über die berechtigte Akteure Aufträge zur Aufnahme und Löschung von Update-Paketen und Konfigurationsdatenfiles in die Download-Bereiche der von ihnen verantworteten Umgebungen erteilen können.

TIP1-A_3350 - Organisatorische Schnittstelle Form und Inhalt von Aufnahme-Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt eines Auftrags zur Aufnahme eines Update-Pakets/Firmware-Gruppen-Informationen und Konfigurationsdatenfiles in den Download-Bereich definieren und mit den berechtigten Akteuren abstimmen. Folgende Informationen MÜSSEN zwingend enthalten sein:

• Auftraggeber

• Umgebung, in der der Auftrag ausgeführt werden soll

• Eindeutige Referenz auf das bereitzustellende Update-Paket „UpdateID“, Firmware-Gruppen-Informationen „FirmwareGroupID“ bzw. die Konfigurationsdaten.

TIP1-A_6126 - Organisatorische Schnittstelle Form und Inhalt Ergebnisse von Aufnahme-Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt des Ergebnisses eines Auftrags definieren und mit den berechtigten Akteuren abstimmen. Folgende Informationen MÜSSEN mindestens zwingend enthalten sein:

• Umgebung, in der der Auftrag ausgeführt wurde.

• Eindeutige Referenz des verarbeiteten Update-Pakets „UpdateID“, Firmware-Gruppen-Information „FirmwareGroupID“ bzw. Konfigurationsdaten.

• Status des verarbeiteten Update-Pakets „UpdateID“, Firmware-Gruppen-Information „FirmwareGroupID“ bzw. Konfigurationsdaten nach Auftragsabarbeitung entsprechend Tab_KSR_050.

• Datum und Uhrzeit der Auftragsabarbeitung.

• Ergebnis der Auftragsabarbeitung.

TIP1-A_5163 - Organisatorische Schnittstelle zur Übergabe von Konfigurationsdaten

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt eines Auftrags zur Übergabe von Konfigurationsdaten definieren und mit den berechtigten Akteuren abstimmen. Folgende Informationen MÜSSEN zwingend enthalten sein:

• Auftraggeber

• Umgebung, in der der Auftrag ausgeführt werden soll

• Name des Konfigurationsdatenfiles

• Format für die Übergabe der zugehörigen Konfigurationsdaten

Die übergebenen Konfigurationsdaten ersetzen (nach Freigabe durch die verantwortliche Instanz) die aktuellen Konfigurationsdaten.

TIP1-A_3913 - Organisatorische Schnittstelle Form und Inhalt von Lösch-Aufträgen

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt eines Auftrags zur Löschung eines Update-Pakets/Firmware-Gruppen-Informationen aus dem Download-Bereich definieren und mit den berechtigten Akteuren abstimmen. Folgende Informationen MÜSSEN zwingend enthalten sein:

• Auftraggeber

• Umgebung, in der der Auftrag ausgeführt werden soll

• Eindeutige Referenz auf das bereitzustellende Update-Paket „UpdateID“ bzw. Firmware-Gruppen-Informationen „FirmwareGroupID“

TIP1-A_3355 - Schutz Managementschnittstelle

Der Anbieter des Konfigurationsdienstes MUSS die Kommunikationsschnittstelle P_KSRS_Operations gegen unberechtigte Nutzung schützen. Dazu muss der Anbieter des Konfigurationsdienstes den Auftraggeber identifizieren und authentisieren. Der Anbieter des Konfigurationsdienstes kann weitere Schutzmaßnahmen definieren.

TIP1-A_3914 - Berechtigungen für Aufträge PU-Download-Bereich

Der Anbieter des Konfigurationsdienstes DARF NICHT Aufträge für den Download-Bereich der PU von anderen Auftraggebern als dem Servicebetriebsverantwortlichen der TI-Plattform verarbeiten.

TIP1-A_3915 - Berechtigungen für Aufträge TU-Downloadbereich

Der Anbieter des Konfigurationsdienstes DARF NICHT Aufträge für den Download-Bereich der TU von anderen Auftraggebern als dem Testbetriebsverantwortlichen der TU verarbeiten.

TIP1-A_3916 - Berechtigungen für Aufträge RU-Downloadbereich

Der Anbieter des Konfigurationsdienstes DARF NICHT Aufträge für den Download-Bereich der RU von anderen Auftraggebern als dem Testbetriebsverantwortlichen der RU verarbeiten.

TIP1-A_3917 - Keine Aufnahme von invaliden Update-Paket bzw. Firmware-Gruppen-Informationen

Ist ein zur Aufnahme beauftragtes Update-Paket bzw. Firmware-Gruppen-Informationen technisch nicht valide (siehe Eingangsprüfung), so DARF der Anbieter des Konfigurationsdienstes es NICHT in den entsprechenden Download-Bereich einstellen.

TIP1-A_3918 - Aufnahme von validen Update-Paket bzw. Firmware-Gruppen-Informationen

Ist ein zur Aufnahme beauftragtes Update-Paket bzw. eine Firmware-Gruppen-Information technisch valide, so MUSS der Anbieter des Konfigurationsdienstes es nach erfolgreicher Prüfung des Auftrags in den entsprechenden Download-Bereich einstellen.

TIP1-A_3919 - Durchführungsbestätigung eines Auftrags

Nach Ausführung eines Auftrags MUSS der Anbieter des Konfigurationsdienstes den Auftraggeber die erfolgreiche Durchführung des Auftrages bestätigen bzw. über aufgetretene Fehler informieren.

TIP1-A_3920 - Form und Inhalt der Durchführungsbestätigung eines Auftrags

Der Anbieter des Konfigurationsdienstes MUSS Form und Inhalt der Durchführungsbestätigung eines Auftrags definieren und mit den berechtigten Akteuren abstimmen.

TIP1-A_3921 - Logging der Auftragsbearbeitung

Der Anbieter des Konfigurationsdienstes MUSS die Durchführung des Prozesses einschließlich der Beauftragung und Bestätigung in Log-Dateien dokumentieren.

TIP1-A_3351 - Organisatorische Schnittstelle zur Bereitstellung von PU-Log-Daten

Der Anbieter des Konfigurationsdienstes MUSS dem Servicebetriebsverantwortlichen der TI-Plattform auf Anforderung die Log-Dateien des Upload- und Download-Bereiches der Produktivumgebung (PU) übermitteln.

TIP1-A_3922 - Organisatorische Schnittstelle zur Bereitstellung von RU-Log-Daten

Der Anbieter des Konfigurationsdienstes MUSS dem Testbetriebsverantwortlichen RU auf Anforderung die Log-Dateien des Upload- und Download-Bereiches der Referenzumgebung (RU) übermitteln.

TIP1-A_3923 - Organisatorische Schnittstelle zur Bereitstellung von TU-Log-Daten

Der Anbieter des Konfigurationsdienstes MUSS dem Testbetriebsverantwortlichen TU auf Anforderung die Log-Dateien des Upload- und Download-Bereiches der Testumgebung (TU) übermitteln.

TIP1-A_3352 - Organisatorische Schnittstelle zur Bereitstellung von statistischen Daten der PU

Der Anbieter des Konfigurationsdienstes MUSS dem Servicebetriebsverantwortlichen der TI-Plattform zyklisch jeden Monat und zusätzlich auf Anfrage adhoc einen Bericht mit den statistischen Daten der Produktivumgebung (PU) übermitteln.

TIP1-A_3924 - Organisatorische Schnittstelle zur Bereitstellung von statistischen Daten der RU

Der Anbieter des Konfigurationsdienstes MUSS dem Testbetriebsverantwortlichen RU zyklisch jeden Monat und zusätzlich auf Anfrage adhoc einen Bericht mit den statistischen Daten der Referenzumgebung (RU) übermitteln.

TIP1-A_3925 - Organisatorische Schnittstelle zur Bereitstellung von statistischen Daten der TU

Der Anbieter des Konfigurationsdienstes MUSS dem Testbetriebsverantwortlichen TU zyklisch jeden Monat und zusätzlich auf Anfrage adhoc einen Bericht mit den statistischen Daten der Referenzumgebung (TU) übermitteln.

TIP1-A_5043 - Organisatorische Schnittstellen parallel nutzbar

Der Konfigurationsdienst SOLL die organisatorischen Schnittstellen so realisieren, dass sie parallel durch mehrere Aufrufer nutzbar sind.

TIP1-A_6067 - Organisatorische Schnittstelle zur Bereitstellung von KSR Statusberichten der PU

Der Anbieter des Konfigurationsdienstes MUSS dem Servicebetriebsverantwortlichen der TI-Plattform einen Statusbericht im XML-Format mit den Informationen aller auf dem KSR vorliegenden Firmware-Pakete der Produktivumgebung (PU) übermitteln. Dieser Statusbericht MUSS bei jeder Änderung der enthaltenen Daten übermittelt werden.

TIP1-A_6074 - Organisatorische Schnittstelle zur Bereitstellung von KSR Statusberichten der PU – Inhalt

Der Anbieter des Konfigurationsdienstes MUSS in dem Statusbericht zu jedem Firmware-Paket mindestens folgende Informationen liefern:

• Timestamp (Zeitstempel des Hochladens auf den KSR)
  
• Kurzbeschreibung (beim Hochladen auf den KSR eingegebene Kurzbeschreibung)
  
• FirmwareGroupInformation
  
• FirmwareGroupID
  
• ProductVendorID
  
• ProductCode
  
• HWVersion
  
• FirmwareGroupVersion
  
• CreationDate
  
• FirmwareGroupReleaseNotes
  
• Liste von Firmwareversionen (FWVersion)
  
• Aktive FG (Kennzeichen ob diese Firmwaregruppe aktiv ist)
  
• UpdateInformation
  
• UpdateID
  
• ProductVendorID
  
• ProductCode
  
• HWVersion
  
• ProductName
  
• CreationDate
  
• DeploymentInformation
  
• StartDate
  
• Deadline
  
• Firmware
  
• FWVersion
  
• FWPriority
  
• FirmwareReleaseNotes
  
• Status
  
• Status-Beschreibung
  

TIP1-A_6075 - Organisatorische Schnittstelle zur Bereitstellung von KSR- Statusberichten der PU – Anhänge

Der Anbieter des Konfigurationsdienstes MUSS mit dem Statusbericht als Anlage alle weiteren aktuell gültigen Konfigurationsdateien hinzufügen, welche die Auswahl von Update-Paketen beeinflussen.

TIP1-A_6076 - Organisatorische Schnittstelle zur Bereitstellung von KSR- Statusberichten der PU – Excel-Import

Der Anbieter des Konfigurationsdienstes MUSS den Statusbericht in einem XML-Format liefern, welches den Excel-Import und die weitere Analyse des Reports in Excel ermöglicht.