C_12485_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

1.1 Beschreibung des optimierten KT-Update-Prozesses

1.1.1 Default-Verhalten

1.1.2 Change-Window-Verhalten

1.1.3 Pflege des Update Schedules

1.1.4 Feedback von den Anbietern

2 Änderung in gemF_Highspeed-Konnektor

2.1 5.1.3.1 KSR-Client

2.1.1 5.1.3.1.1 Eingeschränkte Nutzung des KSR

Der Highspeed-Konnektor nutzt den KSR um Updates für Kartenterminals zu laden und auf angeschlossenen Kartenterminals zu installieren. Die Software des Highspeed-Konnektors wird nicht über den KSR aktualisiert, sondern durch Upload am Highspeed-Konnektor. Der Highspeed-Konnektor kann in Teilen aktualisiert werden, bspw. das zugrundeliegende Betriebssystem oder die Virtualisierungsfunktionalität unabhängig vom eigentlichen Anwendungskonnektor. In jedem Fall muss die Integrität und Authentizität der Highspeed-Konnektor-Updates vor deren Anwendung geprüft werden.

HSK: unverändert

TIP1-A_4832-03 - TUC_KON_280 „Konnektoraktualisierung durchführen“

Der Highspeed-Konnektor MUSS den technischen Use Case TUC_KON_280 „Konnektoraktualisierung durchführen“ umsetzen.

Tabelle 1: TAB_KON_664 – TUC_KON_280 „Konnektoraktualisierung durchführen“

Element
Beschreibung
Name
TUC_KON_280 „Konnektoraktualisierung durchführen“
Beschreibung
Dieser TUC aktualisiert den Konnektor oder Teile des Konnektors mit einem Update, dessen Update-Dateien direkt übergeben wurden
Auslöser
  • Der Administrator hat ein lokales Updatepaket bezogen und zur Anwendung übergeben.
Vorbedingungen

Eingangsdaten
  • Updatepaket (herstellerspezifisch, von lokaler Datenquelle, mit enthaltenen FirmwareFiles)
Komponenten
Konnektor,
Ausgangsdaten
Keine
Nachbedingungen
Der Konnektor arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version.
Standardablauf
Der Konnektor MUSS das zur Anwendung übergebene Updatepaket wie folgt anwenden:
  1. Integrität und Authentizität jeder der Im Updatepaket enthaltenen FirmwareFiles prüfen (Mechanismus ist herstellerspezifisch)
  2. Bei Aktualisierung des Anwendungskonnektors: Prüfen auf Zulässigkeit des Updates basierend auf der Firmware-Gruppe (siehe [gemSpec_OM#2.5]
    Bei Aktualisierung der zugrundeliegenden Systemanteile: Prüfung auf Basis eines herstellerspezifischen Mechanismus, dass alte, ggf. Schwachstellen aufweisende Versionen nicht erneut eingespielt werden können. (Der Rollback bei Fehlern im Update-Prozess ist davon ausgenommen.)
  3. Anwenden der zur Verfügung stehenden FirmwareFiles
    1. Herstellerspezifischer Mechanismus zur Aktualisierung der internen Konnektorsoftware durch die FirmwareFiles inklusive anschließender Prüfung auf Erfolg.
    2. Bestehende Konfigurationsdaten des Konnektors MÜSSEN erhalten bleiben und sofern erforderlich und möglich automatisch auf die Definitionen der neuen Firmware angepasst werden.
    3. Ist ein händischer Anpassungs- oder Ergänzungsbedarf der Konfigurationsdaten erforderlich, so MUSS der Administrator hierüber geeignet informiert werden
Varianten/Alternativen

Fehlerfälle
(1) Integritätsprüfung eines FirmwareFiles fehlgeschlagen, Fehlercode: 4183
( 2) Firmwaregruppenprüfung fehlgeschlagen, Fehlercode: 4185
(3a) Interne Aktualisierung fehlgeschlagen, dann:
          1. Rollback auf vorherige Version
          2. Abbruch mit Fehlercode: 4184
Nichtfunktionale Anforderungen

Zugehörige Diagramme

Tabelle 2: TAB_KON_665 Fehlercodes TUC_KON_280 „Konnektoraktualisierung durchführen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4183
Security
Error
Integritätsprüfung UpdateFiles fehlgeschlagen.
4184
Security
Error
Anwendung der UpdateFiles fehlgeschlagen (<Details>).
4185
Security
Error
Firmware-Version liegt außerhalb der gültigen Firmware-Gruppe

[<=]

HSK: unverändert

A_23476 - Zentrale Umsetzung von KSR-Client, NTP und Namensdienst

Der HSK MUSS die Funktionen KSR-Client, NTP und Namensdienst zentral für alle HSK-Instanzen oder einen Cache für alle Instanzen implementieren.
[<=]

Hinweis zum Datenschutz: Der nutzende Leistungserbringer muss mit Vertragsabschluss einwilligen, dass die Daten über seine HSK-Instanzen zugreifbarer SMC-B im TI-Gateway verarbeitet werden und dem Portal-Nutzer der zugeordneten HSK-Instanzen angezeigt werden. Die Daten anderer Karten dürfen vom HSK nicht an das Zugangsmodul gesendet werden.
Durch die obige Anforderung soll die Last auf den zentralen Diensten KSR, NTP und Namensdienst begrenzt werden.

Neues Kapitel mit neuen und geänderten Anforderungen für den HSK

2.1.2 5.1.3.1.2 Planung und Durchführung der KT-Updates

Der Administrator kann Wartungsfenster (Change Windows) anlegen bis zu ein Jahr im Voraus. Ein Wartungsfenster öffnet sich mit Eintritt seiner Startzeit und schließt sich mit Eintritt seiner Endezeit.

Der Konnektor verwaltet automatisch einen Update Schedule, indem er Update-Einträge im Update Schedule erzeugt, ändert und löscht. Die konfigurierten Start- und Endzeiten eines Wartungsfensters fließen in den Update Schedule ein. Die Vorlaufzeit eines Wartungsfensters bestimmt, bis zu welchem Zeitpunkt der Konnektor Update-Einträge für das jeweilige Wartungsfenster in den Update Schedule schreibt (Startzeit minus Vorlaufzeit).

Wenn keine Wartungsfenster angelegt sind, verwendet der Konnektor konfigurierte Default-Startzeiten für Einträge im Update Schedule. Wenn keine Admin-PIN hinterlegt ist, markiert der Konnektor den Eintrag im Update Schedule entsprechend und deaktiviert die automatische Ausführung des Updates.

Der Administrator kann Update Einträge im Update Schedule erzeugen, ändern und löschen.

Abbildung 1 KT-Update-Prozess

2.1.2.1 5.1.3.1.2.1 Wartungsfenster (Change Window)

HSK: neu

A_28937 - Wartungsfenster für KT-Updates

Der HSK MUSS dem Administrator ermöglichen, Wartungsfenster (Change Windows) anzulegen mit Parametern gemäß TAB_KON_1001.
Der HSK MUSS das Anlegen von Wartungsfenstern für mindestens ein Jahr im Voraus erlauben.

Tabelle 3 TAB_KON_1001 Change Window Parameter

Parameter Bedeutung Datentyp/Wertebereich
CW_Start_Date Start-Datum des Wartungsfensters
CW_End_Date Ende-Datum des Wartungsfensters
CW_Start_Time Startzeit des Wartungsfensters
CW_End_Time Endezeit des Wartungsfensters
CW_Lead_Time Vorlaufzeit Zeitintervall. Default: 14 Tage

[<=]

HSK: neu

A_28995 - Löschen abgelaufener Wartungsfenster

Der Konnektor MUSS Wartungsfenster löschen, wenn CW_End_Date/CW_End_Time überschritten wurde. [<=]

2.1.2.2 5.1.3.1.2.2 Update Schedule

HSK: neu

A_28938 - Update Schedule für KT-Updates

Der HSK MUSS einen Update Schedule verwalten. Ein Eintrag im Update Schedule (Update Entry) MUSS folgende Parameter unterstützen:

Tabelle 4 TAB_KON_1002 Update Entry Parameter

Parameter Bedeutung Wertebereich
CT.ID Kartenterminal-ID
CT.Hostname Friendly Name des Kartenterminals
UE_Start_Date Startdatum für die Ausführung des FW-Updates
UE_End_Date Enddatum für die Ausführung des FW-Updates
UE_Start_Time Startzeit für die Ausführung des FW-Updates
UE_End_Time Endezeit für die Ausführung des FW-Updates
UE_Update_Is_Enabled Kennzeichnung, ob das automatische FW-Update für das KT aktiviert ist [ja | nein]
UE_Admin_PIN_Available Kennzeichnung, ob Admin-PIN für das KT im Konnektor hinterlegt ist [ja | nein]
UE_Target_FW_Version FW-Version, auf die das KT updated werden soll
[<=]

HSK: neu

A_28939 - Einträge im Update Schedule erzeugen

Wenn gemäß TIP1-A_4836* ein FW-Update für ein KT existiert, MUSS der HSK für jedes vom FW-Update betroffene KT einen Update Entry im Update Schedule erzeugen, vorausgesetzt das FW-Update wurde bereits vom KSR heruntergeladen und liegt im HSK vor. [<=]

HSK: neu

A_28940 - Maximal ein Update Entry pro KT

Der HSK MUSS sicherstellen, dass für ein KT maximal ein Update Entry im Update Schedule vorhanden ist. [<=]

HSK: neu

A_28941 - Startzeit für Update Entries festlegen

Der HSK MUSS für Einträge im Update Schedule CW_Start_Date und CW_Start_Time des zeitlich nächstliegenden Wartungsfensters unter Berücksichtigung von CW_Lead_Time verwenden. Wenn CW_Lead_Time des zeitlich nächstliegenden Wartungsfensters bereits unterschritten ist, MUSS der HSK die Parameter des nächstfolgenden Wartungsfensters verwenden.
Wenn kein Wartungsfenster vorhanden ist, MUSS der HSK MGM_KSR_AUTO_UPDATE_TIME als Werte für UE_Start_Date und UE_Start_Time verwenden.
[<=]

HSK: neu

A_28942 - Kennzeichnung wenn Admin-PIN für KT nicht konfiguriert

Wenn für ein betroffenes KT im HSK keine Admin-PIN konfiguriert ist, MUSS der HSK im Update Entry "UE_Admin_PIN_Available = nein" und "UE_Update_Is_Enabled= nein" setzen. In der Übersicht des Update-Schedule müssen diese Einträge als Fehler hervorgehoben werden. [<=]

HSK: neu

A_28945 - Push-Nachricht an Zugangsmodul bei Änderungen am Update Schedule

Der HSK MUSS nach jedem Ablauf von TUC_KON_282 eine Push-Nachricht an das TI-Gateway-Zugangsmodul senden, wenn Änderungen am Update Schedule vorgenommen wurden. Die Push-Nachricht MUSS pro Tupel (ProductVendorID, ProductName, FirmwareVersion) die Anzahl neu erzeugter Einträge im Update Schedule enthalten.
[<=]

HSK: neu

A_28991 - Ausgeführte Update Entries automatisch löschen

Der Konnektor MUSS Update Entries löschen, wenn das Update erfolgreich ausgeführt wurde.
[<=]

HSK: neu

A_28992 - Löschen aktivierter Update Entries nach Ablauf des Zeitfensters

Der Konnektor MUSS aktivierte Update Entries löschen, wenn UE_End_Date/UE_End_Time erreicht wurde und das Update nicht ausgeführt wurde.
[<=]

HSK: neu

A_28993 - Beibehalten deaktivierter Update Entries nach Ablauf des Zeitfensters

Der Konnektor DARF deaktivierte Einträge nicht automatisch löschen, wenn UE_End_Date/UE_End_Time erreicht wurde. [<=]

HSK: neu

A_28994 - Ersetzen deaktivierter Update Entries bei höherer FW-Version

Wenn eine höhere FW-Version gefunden wurde und im Konnektor vorhanden ist, MUSS der Konnektor deaktivierte Einträge für die Vorversion durch neue, aktivierte Einträge für die höhere Version ersetzen. [<=]

2.1.2.3 5.1.3.1.2.3 Pflege des Update Schedules

HSK: neu

A_28943 - Admin: Änderung am Update Schedule für Kartenterminals

Der HSK MUSS dem Administrator ermöglichen, Änderungen am Update Schedule für einzelne KTs und für Gruppen von KTs vorzunehmen. Der HSK MUSS dem Administrator Auswahlmöglichkeiten für KTs anbieten und ihm erlauben, Update- Entry-Parameter gemäß TAB_KON_1002 für alle ausgewählten KTs gleichzeitig zu ändern. [<=]

HSK: neu

A_28944 - Admin: Update Entries erzeugen, ändern, löschen

Der HSK MUSS dem Administrator ermöglichen, Update Entries zu erzeugen, zu ändern und zu löschen. Der Administrator MUSS Update-Entry-Parameter gemäß TAB_KON_1001 ändern und Update Entries löschen können, solange das Update noch nicht begonnen wurde.
[<=]

HSK: neu

A_28989 - Updates automatisch auslösen

Wenn für ein Update Entry im Update Schedule UE_Start_Date/UE_Start_Time erreicht wird, MUSS der Konnektor das Update auslösen, wenn folgende Bedingungen erfüllt sind:

[<=]

HSK: neu

A_29003 - Deaktivieren aller Update Entries einer KT-FW-Version

Der Highspeed-Konnektor MUSS dem Basisadministrator eine Liste auf dem KSR verfügbarer KT-Updates anzeigen und die Möglichkeit bieten, eine FW-Version auszuwählen und nach einer Bestätigungsabfrage die Funktion "KT-Update in allen vInstanzen deaktivieren" auszulösen. In der Folge MÜSSEN die vInstanzen alle Einträge dieser FW-Version im Update Schedule auf "UE_Update_Is_Enabled = nein" setzen.
[<=]

HSK: neu

A_29006 - Reaktion auf Eintragen von KT-Credentials

Der Konnektor MUSS beim Speichern von neuen oder geänderten KT-Admin-Credentials (CT.ADMIN_USERNAME und CT.ADMIN_PASSWORD):

[<=]

2.1.2.4 5.1.3.1.2.4 TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Hier wird TIP1-A_4833-03 eingefügt (s. u.)

2.1.2.5 5.1.3.1.2.5 TUC_KON_282 „UpdateInformationen beziehen“

Hier wird TIP1-A_4834-03 eingefügt (s. u.)

2.1.2.6 5.1.3.1.2.6 TUC_KON_284 KSR-Client initialisieren

Hier wird TIP1-A_5938-02 eingefügt (s. u.)

2.2 5.1.4 Integration in das TI-Gateway

HSK: editorisch geändert (Typo MGM_KSR_AUTODOWNLOAD)

A_23432 - Verpflichtendes Auto-Update

Der Highspeed-Konnektor in einem TI-Gateway MUSS im Modus [MGM_KSR_AUTO_UPDATE=Enabled] und [MGM_KSR_AUTODOWNLOAD=Enabled] betrieben werden, was global am Basissystem des HSK durch die Rolle "Hersteller" im Rahmen der Inbetriebnahme konfiguriert werden muss und nicht durch andere Administrator-Rollen (Basissystem-Administrator, Zugangsmodul, Administratoren von HSK-Instanzen) deaktivierbar sein darf. [<=]

3 Änderung in gemSpec_Kon

Für den HSK geänderte Anforderungen werden nach gemF_Highspeed-Konnektor verschoben.

3.1 3.1.1 Software- und Konfigurationsaktualisierung (KSR-Client)

Die Umsetzung des KSR-Clients bezüglich des Mechanismus zur Durchführung der Aktualisierungen, sowie die Art der Darstellung an der Managementschnittstelle sind herstellerspezifisch.

Innerhalb der Software- und Konfigurationsaktualisierung (KSR-Client) werden folgende Präfixe für Bezeichner verwendet:

3.1.1 3.1.1.1 Funktionsmerkmalweite Aspekte

Der Konnektor muss einen KSR-Client bereitstellen, über den der Administrator sowohl den Konnektor selbst als auch die vom Konnektor verwalteten Kartenterminals (CT-Objects in CTM_CT_LIST mit CT.CORRELATION>=„gepairt“ und CT.VALID_VERSION=True und CT.IS_PHYSICAL = Ja) softwareseitig aktualisieren kann.

Weiterhin muss über den KSR-Client eine Aktualisierung von ausgewählten Konfigurationsdaten möglich sein.

EBK

TIP1-A_4829 - Vollständige Aktualisierbarkeit des Konnektors

Die Software-Aktualisierung des Konnektor SOLL sicherstellen, dass alle Software-Bestandteile des Konnektors aktualisiert werden können, damit eine ungehinderte Nachnutzung der Hardware-Basis im Feld mit neuen Funktionalitäten nicht durch nichtaktualisierbare Software-Bestandteile gefährdet wird. Weicht ein Hersteller für sein Konnektormodell von dieser Forderung in Teilen ab, so MUSS er im Rahmen der Zulassung nachweisen, dass dies auf Grund von Sicherheitsaspekten für sein eingereichtes Konnektormodell zwingend erforderlich ist.

[<=]

HSK: unverändert

TIP1-A_5657-02 - Freischaltung von Softwareupdates

Der Konnektor MUSS die Möglichkeit bieten, dass Softwareupdates durch den Nutzer bzw. einen von ihm beauftragten Administrator einzeln freigeschaltet werden.
[<=]

EBK

A_18387 - Automatische Softwareupdates

Der Konnektor MUSS die Möglichkeit bieten, die automatische Installation von Softwareupdates pro Gerät (Konnektor und Kartenterminals) ein- und auszuschalten. [<=]

HSK: unverändert

A_18389 - Nur Nutzung von zugelassenen Versionen

Der Hersteller des Konnektors MUSS in seinem Handbuch den Nutzer darauf hinweisen, dass er sich bei der Arbeit mit dem Konnektor vergewissern muss, dass er mit einer zugelassenen Version arbeitet und beschreiben, wie der Nutzer diese Information mittels seines Primärsystems erhalten kann.
[<=]

EBK

TIP1-A_6476 - Lieferung von Softwareupdates

Der Hersteller des Konnektors MUSS jede zugelassene Firmware-Version umgehend als Update-Paket über die in [gemSpec_KSR] definierte Schnittstelle P_KSRS_Upload im Konfigurationsdienst (KSR) ablegen.
Der Hersteller des Konnektors MUSS in den jeweiligen UpdateInformation/Firmware/FirmwareReleaseNotes eine Internet-URL zum Download des FW-Updates bereitstellen.

[<=]

EBK

TIP1-A_6026 - Anzeige URL zum Download des FW-Updates an der Managementschnittstelle

Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Internet-URL zum Download des FW-Updates anzeigen.
[<=]

3.1.2 3.1.1.2 Durch Ereignisse ausgelöste Reaktionen

HSK: geändert

TIP1-A_4831-01 - KT-Update nach Wiedererreichbarkeit erneut anstoßen

Wenn für ein Kartenterminal ein Update Entry vorhanden ist mit den Eigenschaften

und für dieses Kartenterminal tritt das Ereignis „CT/CONNECTED“ ein, so MUSS TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ für dieses KT gerufen werden.

[<=]

HSK: abgelöst

TIP1-A_4831 - KT-Update nach Wiedererreichbarkeit erneut anstoßen

Wenn aus (TIP1-A_4840 Auslösen der durchzuführenden Updates) heraus für ein Kartenterminal noch ein ausstehendes Updates vorhanden ist, dessen Ausführungszeitpunkt nicht gesetzt oder überschritten ist, und für dieses Kartenterminal das Ereignis „CT/CONNECTED“ eintritt, so MUSS TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ für dieses KT gerufen werden.

[<=]

3.1.3 3.1.1.3 Interne TUCs, nicht durch Fachmodule nutzbar

3.1.3.1 3.1.1.3.1 TUC_KON_280 „Konnektoraktualisierung durchführen“

EBK

TIP1-A_4832-02 - TUC_KON_280 „Konnektoraktualisierung durchführen“

Der Konnektor MUSS den technischen Use Case TUC_KON_280 „Konnektoraktualisierung durchführen“ umsetzen.

Tabelle 5: TAB_KON_664 – TUC_KON_280 „Konnektoraktualisierung durchführen“

Element
Beschreibung
Name
TUC_KON_280 „Konnektoraktualisierung durchführen“
Beschreibung
Dieser TUC aktualisiert den Konnektor mit einem Update, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden
Auslöser
  • Der Administrator hat UpdateInformation zur Anwendung ausgewählt und bestätigt bzw. ein lokales Updatepaket bezogen und zur Anwendung übergeben.
  • automatisches Softwareupdate [A_18387] 
Vorbedingungen

Eingangsdaten
  • UpdateInformation (gemäß [gemSpec_KSR#5.2])
oder
  • Updatepaket (herstellerspezifisch, von lokaler Datenquelle, mit enthaltenen FirmwareFiles)
Komponenten
Konnektor, Konfigurationsdienst
Ausgangsdaten
Keine
Nachbedingungen
Der Konnektor arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version.
Standardablauf
Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
  1. Integrität und Authentizität der UpdateInformation prüfen (Mechanismus ist herstellerspezifisch)
  2. Download aller in UpdateInformation.FirmwareFiles gelisteten Dateien. Dabei wird die Komprimierung des File Transfers vom Konfigurationsdienst über http „Content Coding“ [RFC2616] „gzip“ genutzt.
  3. Integrität und Authentizität jeder der via UpdateInformation/FirmwareFiles heruntergeladenen Dateien prüfen (Mechanismus ist herstellerspezifisch)
  4. Prüfen auf Zulässigkeit des Updates basierend auf der Firmware-Gruppe (siehe [gemSpec_OM#2.5]
  5. Anwenden der zur Verfügung stehenden FirmwareFiles
    1. TUC_KON_256{
          topic = „KSR/UPDATE/START“;
          eventType = Sec;
          severity = Info;
          parameters = („Target=Konnektor,
                                Name=$MGM_KONN_HOSTNAME“)}
      (betroffene Fachmodule und Basisdienste reagieren und stoppen sich)
    2. Herstellerspezifischer Mechanismus zur Aktualisierung der internen Konnektorsoftware durch die FirmwareFiles inklusive anschließender Prüfung auf Erfolg.
    3. Bestehende Konfigurationsdaten des Konnektors MÜSSEN erhalten bleiben und sofern erforderlich und möglich automatisch auf die Definitionen der neuen Firmware angepasst werden.
    4. Ist ein händischer Anpassungs- oder Ergänzungsbedarf der Konfigurationsdaten erforderlich, so MUSS der Administrator hierüber geeignet informiert werden
    5. TUC_KON_256 {
          topic = „KSR/UPDATE/SUCCESS”;
          eventType = Sec;
          severity = Info;
          parameters = („Target=Konnektor,
                      Name= $MGM_KONN_HOSTNAME,
                      NewFirmwareversion =
                              UpdateInformation.FirmwareVersion,
                      ConfigurationChanged=<Ja/Nein>,
                      ManualInputNeeded=<Ja/Nein>„) }
Der TUC endet in jedem Fall mit:
TUC_KON_256 {
    topic = „KSR/UPDATE/END“;
    eventType = Sec;
    severity = Info;
    parameters = („Target=Konnektor,
                           Name=$MGM_KONN_HOSTNAME“) }
(betroffene Fachmodule und Basisdienste reagieren und starten sich)
Varianten/Alternativen
Sofern direkt ein Updatepaket (mit enthaltenen FirmwareFiles) übergeben wurde beginnt der Ablauf ab Nummer 4 mit der Integritätsprüfung des Updatepakets
Fehlerfälle
Fehler in den folgenden Schritten des Ablaufs führen zu:
a) Aufruf von TUC_KON_256 {
          topic = „KSR/ERROR“;
          eventType = $ErrorType;
          severity = $Severity;
          parameters = („Target=Konnektor,
                 Name= $MGM_KONN_HOSTNAME,
                 Error=$Fehlercode,
                 Bedeutung=$Fehlertext“) }
b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes

(1) Integritätsprüfung UpdateInformation fehlgeschlagen, Fehlercode: 4181
(2) Fehler bei der Downloaddurchführung, Fehlercode: 4182
(3) Integritätsprüfung eines FirmwareFiles fehlgeschlagen, Fehlercode: 4183
( 4) Firmwaregruppenprüfung fehlgeschlagen, Fehlercode: 4185
(5b) Interne Aktualisierung fehlgeschlagen, dann:
          1. Rollback auf vorherige Version
          2. Abbruch mit Fehlercode: 4184
Nichtfunktionale Anforderungen
Der laufende Updatevorgang MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt mindestens für die Schritte 1-5b dargestellt werden.
Zugehörige Diagramme
Abbildung PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen

Tabelle 6: TAB_KON_665 Fehlercodes TUC_KON_280 „Konnektoraktualisierung durchführen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4181
Security
Error
Integritätsprüfung UpdateInformation fehlgeschlagen.
4182
Security
Error
Download nicht aller UpdateFiles möglich.
4183
Security
Error
Integritätsprüfung UpdateFiles fehlgeschlagen.
4184
Security
Error
Anwendung der UpdateFiles fehlgeschlagen (<Details>).
4185
Security
Error
Firmware-Version liegt außerhalb der gültigen Firmware-Gruppe



Abbildung 2: PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen  

[<=]

3.1.3.2 3.1.1.3.2 TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Im Vergleich zur Durchführung des Konnektor-Update (TUC_KON_280), werden die Updates der Kartenterminals nur durch den Konnektor initiiert. Der Konnektor liefert dem Kartenterminal das Updatefile, der eigentliche Updatevorgang (inklusive der Prüfung des Updatepakets auf Integrität und Authentizität) erfolgt ausschließlich und eigenverantwortlich auf Seiten des Kartenterminals.

HSK: geändert

TIP1-A_4833-03 - TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Der Konnektor MUSS den technischen Use Case TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ umsetzen.

Tabelle 7: TAB_KON_666 – TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Element
Beschreibung
Name
TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
Beschreibung
Dieser TUC fordert ein Kartenterminal auf einen Update durchzuführen, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden
Auslöser
  • Der Administrator hat ein Update für ein Kartenterminal über den Update Schedule zur Anwendung ausgewählt und bestätigt bzw. ein lokales Updatepaket für ein Kartenterminal bezogen und zur Anwendung übergeben [TIP1-A_4840*].
  • automatisches Softwareupdate [A_18390*, A_28989] 
Vorbedingungen
  •     CT(ctId).IS_PHYSICAL=Ja
  •     CT(ctId).CORRELATION>=”gepairt”
Eingangsdaten
  •       ctId (ID des Ziel-KTs)
  •       UpdateInformation (gemäß [gemSpec_KSR]) oder
  •       Updatepaket (herstellerspezifisch, von lokaler Datenquelle, mit enthaltenen FirmwareFiles)
Komponenten
Konnektor, Kartenterminal
Ausgangsdaten
Keine
Nachbedingungen
Das Kartenterminal arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version.
Standardablauf
Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
  1. Download der in UpdateInformation/FirmwareFiles gelisteten Datei (für KT-Updates darf nur genau ein FirmwareFile angegeben werden)
  2. TUC_KON_256{
    topic = „KSR/UPDATE/START”;
        eventType = Sec;
        severity = Info;
        parameters = („Target=KT, CtID=$ctId“) }
  3. Durchführen des KT-Updates durch:
a)         Wechsel in eine Admin-Session durch TUC_KON_050
     „Beginne Kartenterminalsitzung“{role=„Admin“; ctId}
b)         Senden der SICCT Kommandos: SICCT CT Download INIT,
     SICCT CT Download DATA (Übermittlung des UpdateFiles) und
     SICCT CT Download FINISH an ctId
c)         TUC_KON_256{
          topic = „KSR/UPDATE/SUCCESS”;
          eventType = Sec;
          severity = Info;
          parameters = („Target=KT,
                 Name= $CT.HOSTNAME, CtID =$ctId,
                 NewFirmwareversion =
                          <UpdateInformation.FirmwareVersion>„}

Der TUC endet in jedem Fall mit:
  • TUC_KON_256 {
            topic = „KSR/UPDATE/END”;
            eventType = Sec;
            severity = Info;
            parameters = („Target=KT, CtID =$ctId“) }
Varianten/Alternativen
Wenn das FirmwareFile bereits vom KSR bezogen wurde, kann das im Konnektor vorliegende FirmwareFile verwendet werden.
Sofern direkt ein Updatepaket (mit enthaltenem FirmwareFile) übergeben wurde beginnt der Ablauf ab Nummer 2 mit Signalisierung des Beginns des KT-Updates
Fehlerfälle
Fehler in den folgenden Schritten des Ablaufs führen zu:
a)           Aufruf von TUC_KON_256 {
           topic = „KSR/ERROR”;
           eventType = $ErrorType;
           severity = $Severity;
           parameters = („Target=KT, Name=$CT.HOSTNAME,
                       CtID =$ctId, Error=$Fehlercode,
                       Bedeutung=$Fehlertext“) }
b)           Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
(1) Download fehlgeschlagen, Fehlercode: 4186
(3b) SICCT-Download fehlgeschlagen, Fehlercode: 4187
Nichtfunktionale Anforderungen
Die Durchführung eines KT-Updates DARF die weitere Operation des Konnektors NICHT behindern (weder auf Schnittstellenebene noch in der Managementschnittstelle).
Der laufende Updatevorgang eines KT MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt dargestellt werden.
Der Konnektor MUSS mindestens 5 Kartenterminal-Updates parallel durchführen können.
Zugehörige Diagramme
keine

Tabelle 8: TAB_KON_667 Fehlercodes TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4186
Security
Error
Download nicht aller UpdateFiles möglich.
4187
Security
Error
KT-Update fehlgeschlagen (<Fehlerinfo gemäß SICCT>)
[<=]

HSK: abgelöst

TIP1-A_4833-02 - TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Der Konnektor MUSS den technischen Use Case TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ umsetzen.

Tabelle 9: TAB_KON_666 – TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Element
Beschreibung
Name
TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
Beschreibung
Dieser TUC fordert ein Kartenterminal auf einen Update durchzuführen, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden
Auslöser
  • Der Administrator hat UpdateInformation für ein Kartenterminal zur Anwendung ausgewählt und bestätigt bzw. ein lokales Updatepaket für ein Kartenterminal bezogen und zur Anwendung übergeben.
  • automatisches Softwareupdate [A_18387] 
Vorbedingungen
  •     CT(ctId).IS_PHYSICAL=Ja
  •     CT(ctId).CORRELATION>=”gepairt”
Eingangsdaten
  •       ctId (ID des Ziel-KTs)
  •       UpdateInformation (gemäß [gemSpec_KSR]) oder
  •       Updatepaket (herstellerspezifisch, von lokaler Datenquelle, mit enthaltenen FirmwareFiles)
Komponenten
Konnektor, Kartenterminal
Ausgangsdaten
Keine
Nachbedingungen
Das Kartenterminal arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version.
Standardablauf
Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
  1. Download der in UpdateInformation/FirmwareFiles gelisteten Datei (für KT-Updates darf nur genau ein FirmwareFile angegeben werden)
  2. TUC_KON_256{
    topic = „KSR/UPDATE/START”;
        eventType = Sec;
        severity = Info;
        parameters = („Target=KT, CtID=$ctId“) }
  3. Durchführen des KT-Updates durch:
a)         Wechsel in eine Admin-Session durch TUC_KON_050
     „Beginne Kartenterminalsitzung“{role=„Admin“; ctId}
b)         Senden der SICCT Kommandos: SICCT CT Download INIT,
     SICCT CT Download DATA (Übermittlung des UpdateFiles) und
     SICCT CT Download FINISH an ctId
c)         TUC_KON_256{
          topic = „KSR/UPDATE/SUCCESS”;
          eventType = Sec;
          severity = Info;
          parameters = („Target=KT,
                 Name= $CT.HOSTNAME, CtID =$ctId,
                 NewFirmwareversion =
                          <UpdateInformation.FirmwareVersion>„}

Der TUC endet in jedem Fall mit:
  • TUC_KON_256 {
            topic = „KSR/UPDATE/END”;
            eventType = Sec;
            severity = Info;
            parameters = („Target=KT, CtID =$ctId“) }
Varianten/Alternativen
Sofern direkt ein Updatepaket (mit enthaltenem FirmwareFile) übergeben wurde beginnt der Ablauf ab Nummer 2 mit Signalisierung des Beginns des KT-Updates
Fehlerfälle
Fehler in den folgenden Schritten des Ablaufs führen zu:
a)           Aufruf von TUC_KON_256 {
           topic = „KSR/ERROR”;
           eventType = $ErrorType;
           severity = $Severity;
           parameters = („Target=KT, Name=$CT.HOSTNAME,
                       CtID =$ctId, Error=$Fehlercode,
                       Bedeutung=$Fehlertext“) }
b)           Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
(1) Download fehlgeschlagen, Fehlercode: 4186
(3b) SICCT-Download fehlgeschlagen, Fehlercode: 4187
Nichtfunktionale Anforderungen
Die Durchführung eines KT-Updates DARF die weitere Operation des Konnektors NICHT behindern (weder auf Schnittstellenebene noch in der Managementschnittstelle).
Der laufende Updatevorgang eines KT MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt dargestellt werden.
Der Konnektor MUSS mindestens 5 Kartenterminal-Updates parallel durchführen können.
Zugehörige Diagramme
keine

Tabelle 10: TAB_KON_667 Fehlercodes TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4186
Security
Error
Download nicht aller UpdateFiles möglich.
4187
Security
Error
KT-Update fehlgeschlagen (<Fehlerinfo gemäß SICCT>)
[<=]

3.1.3.3 3.1.1.3.3 TUC_KON_282 „UpdateInformationen beziehen“

HSK: geändert

TIP1-A_4834-03 - TUC_KON_282 „UpdateInformationen beziehen“

Der Konnektor MUSS den technischen Use Case TUC_KON_282 „UpdateInformationen beziehen“ umsetzen.

Tabelle 11: TAB_KON_668 – TUC_KON_282 „UpdateInformationen beziehen“

Element
Beschreibung
Name
TUC_KON_282 „UpdateInformationen beziehen“
Beschreibung
Dieser TUC ermittelt vom zentralen Konfigurationsdienst für alle vom Konnektor verwalteten Kartenterminals die verfügbaren UpdateInformationen.
Auslöser
  • Manuell durch den Administrator
  • Automatisch [TIP1-A_4836]
Vorbedingungen
Keine
Eingangsdaten
Keine
Komponenten
Konnektor, Konfigurationsdienst
Ausgangsdaten
Keine
Nachbedingungen
Der Konnektor verfügt über alle aktuellen UpdateInformationen.
Standardablauf
Der Konnektor MUSS folgende Schritte durchlaufen:
1. Der Konnektor MUSS die TLS-Verbindungen zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
TUC_KON_037 „Zertifikat prüfen“ {
    certificate = C.ZD.TSL-S;
    qualifiedCheck = not_required;
    offlineAllowNoCheck = true;
    policyList = oid_zd_tls_s;  
    intendedKeyUsage= intendedKeyUsage(C.ZD.TSL-S);
    intendedExtendedKeyUsage = id-kp-serverAuth;
    validationMode = OCSP}
auf Gültigkeit prüfen.
Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.

2. Der Konnektor MUSS für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=„gepairt“, das in den letzten 7 Tagen "connected" war, folgende Schritte durchlaufen:
    1.         Belegen von listUpdatesRequest mit den korrekten Werten für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion
    2.         Aufruf von I_KSRS_Download::list_Updates

      Liefert der Aufruf mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/FWVersion > aktuelle Version der Kartenterminalsoftware, deren UpdateInformation/Firmware/FWPriority = „Kritisch“, dann geht der Konnektor über in den Betriebszustand EC_CardTerminal_Software_Out_Of_Date.
3. Beenden der TLS-Verbindung

Varianten/Alternativen
Keine
Fehlerfälle
Fehler in den folgenden Schritten des Ablaufs führen zu:
a)          Aufruf von TUC_KON_256 {
           topic = „KSR/ERROR“;
           eventType = $ErrorType;
           severity = $Severity;
           parameters = („Error=$Fehlercode; Bedeutung=$Fehlertext“)}

b)          Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
(1) Konfigurationsdienst nicht erreichbar, Fehlercode: 4188
(1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
(2b) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190
Nichtfunktionale Anforderungen
Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.
Zugehörige Diagramme
keine

Tabelle 12: TAB_KON_669 Fehlercodes TUC_KON_282 „UpdateInformationen beziehen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten:
4188
Technical
Error
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
4189
Security
Fatal
Konfigurationsdienst liefert falsches Zertifikat
4190
Technical
Error
Fehler beim Beziehen der Updatelisten

[<=]

HSK: abgelöst

TIP1-A_4834-02 - TUC_KON_282 „UpdateInformationen beziehen“

Der Konnektor MUSS den technischen Use Case TUC_KON_282 „UpdateInformationen beziehen“ umsetzen.

Tabelle 13: TAB_KON_668 – TUC_KON_282 „UpdateInformationen beziehen“

Element
Beschreibung
Name
TUC_KON_282 „UpdateInformationen beziehen“
Beschreibung
Dieser TUC ermittelt vom zentralen Konfigurationsdienst sowohl für den Konnektor als auch für alle durch ihn verwalteten Kartenterminals die verfügbaren UpdateInformationen
Auslöser
  • Manuell durch den Administrator
  • Automatisch
Vorbedingungen
Keine
Eingangsdaten
Keine
Komponenten
Konnektor, Konfigurationsdienst
Ausgangsdaten
Keine
Nachbedingungen
Der Konnektor verfügt über alle aktuellen UpdateInformationen
Standardablauf
Der Konnektor MUSS folgende Schritte durchlaufen:
1. Der Konnektor MUSS die TLS-Verbindungen zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
TUC_KON_037 „Zertifikat prüfen“ {
    certificate = C.ZD.TSL-S;
    qualifiedCheck = not_required;
    offlineAllowNoCheck = true;
    policyList = oid_zd_tls_s;  
    intendedKeyUsage= intendedKeyUsage(C.ZD.TSL-S);
    intendedExtendedKeyUsage = id-kp-serverAuth;
    validationMode = OCSP}
auf Gültigkeit prüfen.
Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.

2. Der Konnektor MUSS sowohl für sich wie auch für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=„gepairt“, das in den letzten 7 Tagen "connected" war, folgende Schritte durchlaufen:
    1.         Belegen von listUpdatesRequest mit den korrekten Werten für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion
    2.         Aufruf von I_KSRS_Download::list_Updates

      Liefert der Aufruf mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/FWVersion > aktuelle Version der Konnektorsoftware, deren UpdateInformation/Firmware/FWPriority = „Kritisch“, dann geht der Konnektor über in den Betriebszustand EC_Connector_Software_Out_Of_Date.

      Liefert der Aufruf mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/FWVersion > aktuelle Version der Kartenterminalsoftware, deren UpdateInformation/Firmware/FWPriority = „Kritisch“, dann geht der Konnektor über in den Betriebszustand EC_CardTerminal_Software_Out_Of_Date.
3. Beenden der TLS-Verbindung

Varianten/Alternativen
Keine
Fehlerfälle
Fehler in den folgenden Schritten des Ablaufs führen zu:
a)          Aufruf von TUC_KON_256 {
           topic = „KSR/ERROR“;
           eventType = $ErrorType;
           severity = $Severity;
           parameters = („Error=$Fehlercode; Bedeutung=$Fehlertext“)}

b)          Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
(1) Konfigurationsdienst nicht erreichbar, Fehlercode: 4188
(1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
(2b) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190
Nichtfunktionale Anforderungen
Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.
Zugehörige Diagramme
keine

Tabelle 14: TAB_KON_669 Fehlercodes TUC_KON_282 „UpdateInformationen beziehen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten:
4188
Technical
Error
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
4189
Security
Fatal
Konfigurationsdienst liefert falsches Zertifikat
4190
Technical
Error
Fehler beim Beziehen der Updatelisten

[<=]

3.1.4 3.1.1.4 Interne TUCs, auch durch Fachmodule nutzbar

3.1.4.1 3.1.1.4.1 TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

obsolet

Die Anforderung wird aus gemSpec_Kon entfernt.

TIP1-A_6018 - TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

Der Konnektor MUSS den technischen Use Case TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“ umsetzen.

Tabelle 15: TAB_KON_833 – TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

Element
Beschreibung
Name
TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
Beschreibung
Dieser TUC ermittelt vom zentralen Konfigurationsdienst für ein Fachmodul die verfügbaren UpdateInformationen eines angegebenen SW-Pakets.
Auslöser
  •         Aufruf durch Fachmodul
Vorbedingungen
  • Verbindung zum VPN-Konzentrator der TI wurde erfolgreich aufgebaut
Eingangsdaten
  •         productVendorID [String] -
    (Identifiziert den Hersteller des Produkts, für welches auf Updates geprüft werden soll.)
  •         productCode [String] –
    (Identifiziert das Produkt zusammen mit ProductVendorID, für welches auf Updates geprüft werden soll.)
  •         hwVersion [String]
    (Identifiziert die Hardware zusammen mit ProductCode und ProductVendorID, für welches auf Updates geprüft werden soll. [gemSpec_OM] beschreibt dieses Element ausführlich.)
  •         fwVersion [String]
    aktuell im Produkt verwendete Firmwareversion
Hinweis: Definition von productVendorID, productCode, hwVersion, fwVersion (entspricht FWVersion) siehe [gemSpec_KSR#TIP1-A_3331]
Komponenten
Konnektor, Konfigurationsdienst
Ausgangsdaten
  • listOfUpdates [listUpdatesResponse]
    Liste von Update Informationen der verfügbaren Pakete für das angegebene Produkt;
    Datentyp listUpdatesResponse definiert in Konfigurationsdienst.xsd siehe [gemSpec_KSR]
Nachbedingungen
keine
Standardablauf
Der Konnektor MUSS folgende Schritte durchlaufen:
  1. Der Konnektor MUSS die TLS-Verbindung zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
    TUC_KON_037 „Zertifikat prüfen“ {
        certificate = C.ZD.TSL-S;
        qualifiedCheck = not_required;
        offlineAllowNoCheck = true;
        policyList = oid_zd_tls_s;  
        intendedKeyUsage = intendedKeyUsage(C.ZD.TSL-S);
        intendedExtendedKeyUsage = id-kp-serverAuth;
        validationMode = OCSP}
    auf Gültigkeit prüfen.
    Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.
  1. Belegen von listUpdatesRequest mit den korrekten Werten für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion = fwVersion
  2. Aufruf von I_KSRS_Download::list_Updates gemäß [gemSpec_KSR#TIP1-A_3331]
  3. Beenden der TLS-Verbindung
Varianten/Alternativen
Keine
Fehlerfälle
Fehler in den folgenden Schritten des Ablaufs führen zu:
(1)    Konfigurationsdienst nicht erreichbar, Fehlercode: 4188
(1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
(3) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190
Nichtfunktionale Anforderungen
Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.
Zugehörige Diagramme
keine

Tabelle 16: TAB_KON_834 Fehlercodes TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten:
4188
Technical
Error
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
4189
Security
Fatal
Konfigurationsdienst liefert falsches Zertifikat
4190
Technical
Error
Fehler beim Beziehen der Updatelisten

[<=]

3.1.4.2 3.1.1.4.2 TUC_KON_286 „Paket für Fachmodul laden“

obsolet

Die Anforderung wird aus gemSpec_Kon entfernt.

TIP1-A_6019 - TUC_KON_286 „Paket für Fachmodul laden“

Der Konnektor MUSS den technischen Use Case TUC_KON_286 „Paket für Fachmodul laden“ umsetzen.

Tabelle 17: TAB_KON_835 – TUC_KON_286 „Paket für Fachmodul laden“

Element
Beschreibung
Name
TUC_KON_286 „Paket für Fachmodul laden“
Beschreibung
Dieser TUC lädt ein bestimmtes SW-Paket für ein Fachmodul vom zentralen Konfigurationsdienst.
Auslöser
Aufruf durch Fachmodul
Vorbedingungen
  • Verbindung zum VPN-Konzentrator der TI wurde erfolgreich aufgebaut
Eingangsdaten
  •       filename
    (Filename des SW-Pakets, welches vom KSR geladen werden soll)
Komponenten
Konnektor, Konfigurationsdienst
Ausgangsdaten
  • swPackage
    (das durch filename am KSR identifizierte SW-Paket wurde heruntergeladen)
Nachbedingungen
keine
Standardablauf
  1. Der Konnektor MUSS die TLS-Verbindung zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
    TUC_KON_037 „Zertifikat prüfen“ {
        certificate = C.ZD.TSL-S;
        qualifiedCheck = not_required;
        offlineAllowNoCheck = true;
        policyList = oid_zd_tls_s;  
        intendedKeyUsage = intendedKeyUsage(C.ZD.TSL-S);
        intendedExtendedKeyUsage = id-kp-serverAuth;
        validationMode = OCSP}
    auf Gültigkeit prüfen.
Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.
  1. Herunterladen der Softwarepakets swPackage mittels I_KSRS_Download::get_File (MGM_KSR_FIRMWARE_URL /$filename)
  2. Beenden der TLS-Verbindung
  3. swPackage an Aufrufer zurückgeben
Varianten/Alternativen
keine
Fehlerfälle
( 1) Verbindung zum KSR konnte nicht aufgebaut werden; Fehlercode: 4188
( 1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
( 2) Wenn Größe des Pakets größer als 25MB, Fehlercode: 4242
( 2) Sonstige Fehler beim Download: Das Paket konnte nicht geladen werden, Fehlercode: 4238
Nichtfunktionale Anforderungen
Keine
Zugehörige Diagramme
Keine

Tabelle 18: TAB_KON_836 Fehlercodes TUC_KON_286 „Paket für Fachmodul laden“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
4188
Technical
Error
Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
4189
Security
Fatal
Konfigurationsdienst liefert falsches Zertifikat
4238
Technical
Error
Der Download des Pakets vom KSR ist fehlgeschlagen.
4242
Technical
Error
Der Download des Pakets vom KSR ist fehlgeschlagen. Das Paket ist größer als 25MB.

[<=]

3.1.5 3.1.1.5 Operationen an der Außenschnittstelle

Keine.

3.1.6 3.1.1.6 Betriebsaspekte

HSK: unverändert

A_21899 - Kein Restart des Konnektors nach Aktualisierung der Bestandsnetze.xml

Der Konnektor DARF NICHT nach einer Aktualisierung der Datei Bestandsnetze.xml einen Restart durchführen.
[<=]

HSK: unverändert

A_21900 - Minimale Anzahl von Reboots

Der Konnektor MUSS die Anzahl der Reboots minimieren. [<=]

3.1.6.1 3.1.1.6.1 TUC_KON_284 KSR-Client initialisieren

HSK: geändert

TIP1-A_5938-02 - TUC_KON_284 „KSR-Client initialisieren“

Der Konnektor MUSS in der Bootup-Phase TUC_KON_284 „KSR-Client initialisieren“ durchlaufen.

Tabelle 19: TAB_KON_864 – TUC_KON_284 „KSR-Client initialisieren“

Element
Beschreibung
Name
TUC_KON_284 ”KSR-Client initialisieren”
Beschreibung
Der Konnektor muss während des Bootups die Downloadpunkte für Konfigurationsdaten und Firmware ermitteln.
Eingangsanforderung
Keine
Auslöser
Bootup
Eingangsdaten
Keine
Komponenten
Konnektor
Ausgangsdaten
  • MGM_KSR_KONFIG_URL
  • MGM_KSR_FIRMWARE_URL
Standardablauf
 -             Falls MGM_LU_ONLINE=Enabled:
            -              Durch DNS-Anfragen an den DNS-Forwarder zur
                 Auflösung der SRV-RR und TXT-RR mit den Bezeichnern
                „_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ und
                „_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ erhält
                 der Konnektor URLs der Downloadpunkte des KSR für
                Konfigurationsdaten (MGM_KSR_KONFIG_URL) und für
                Firmware (MGM_KSR_FIRMWARE_URL).

Varianten/Alternativen
Keine
Fehlerfälle
Keine
Nichtfunktionale Anforderungen
Keine
Zugehörige Diagramme
Keine

Tabelle 20: TAB_KON_822 Fehlercodes TUC_KON_284 „KSR-Client initialisieren“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

[<=]

HSK: abgelöst

TIP1-A_5938 - TUC_KON_284 „KSR-Client initialisieren“

Der Konnektor MUSS in der Bootup-Phase TUC_KON_284 „KSR-Client initialisieren“ durchlaufen.

Tabelle 21: TAB_KON_864 – TUC_KON_284 „KSR-Client initialisieren“

Element
Beschreibung
Name
TUC_KON_284 ”KSR-Client initialisieren”
Beschreibung
Der Konnektor muss während des Bootups die Downloadpunkte für Konfigurationsdaten und Firmware ermitteln.
Eingangsanforderung
Keine
Auslöser und Vorbedingungen
Bootup
Verbindung zum VPN-Konzentrator TI muss aufgebaut sein
Eingangsdaten
Keine
Komponenten
Konnektor
Ausgangsdaten
  • MGM_KSR_KONFIG_URL
  • MGM_KSR_FIRMWARE_URL
Standardablauf
 -             Falls MGM_LU_ONLINE=Enabled:
            -              Durch DNS-Anfragen an den DNS-Forwarder zur
                 Auflösung der SRV-RR und TXT-RR mit den Bezeichnern
                „_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ und
                „_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ erhält
                 der Konnektor URLs der Downloadpunkte des KSR für
                Konfigurationsdaten (MGM_KSR_KONFIG_URL) und für
                Firmware (MGM_KSR_FIRMWARE_URL).

Varianten/Alternativen
Keine
Fehlerfälle
Keine
Nichtfunktionale Anforderungen
Keine
Zugehörige Diagramme
Keine

Tabelle 22: TAB_KON_822 Fehlercodes TUC_KON_284 „KSR-Client initialisieren“

Fehlercode
ErrorType
Severity
Fehlertext
Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

[<=]

HSK: geändert

TIP1-A_4835-03 - Konfigurationswerte des KSR-Client

Der Administrator MUSS die in TAB_KON_670 aufgelisteten Parameter über die Managementschnittstelle konfigurieren bzw. ausschließlich einsehen und die in TAB_KON_820 aufgelisteten Parameter ausschließlich einsehen können.

Tabelle 23: TAB_KON_670 Konfigurationsparameter der Software-Aktualisierung

ReferenzID
Ausprägung Belegung
Bedeutung und Administrator-Interaktion
MGM_KSR_AUTODOWNLOAD HSK im Eigenbetrieb Enabled/Disabled Der Administrator MUSS den automatischen Download verfügbarer Update-Pakete über den Konfigurationsparameter MGM_KSR_AUTODOWNLOAD an- und abschalten können.
Default-Wert: Enabled
HSK im TI-Gateway Enabled Der Administrator MUSS den Konfigurationsparameter ausschließlich einsehen können.
MGM_KSR_AUTO_UPDATE HSK im Eigenbetrieb Enabled/Disabled Der Administrator MUSS pro Gerät (Kartenterminal) das automatische Softwareupdate ein- und ausschalten können.
Default-Wert: Enabled
Falls MGM_KSR_AUTO_UPDATE=Enabled wird MGM_KSR_AUTODOWNLOAD=Enabled gesetzt.
HSK im TI-Gateway Enabled Der Administrator MUSS den Konfigurationsparameter ausschließlich einsehen können.
MGM_KSR_AUTO_UPDATE_TIME HSK im Eigenbetrieb
HSK im TI-Gateway
Wochentag(e) / Uhrzeit
Oder
täglich / Uhrzeit		 Der Administrator MUSS den oder die Wochentage und Uhrzeit einstellen können, wann automatische Softwareupdates durchgeführt werden.
Alternativ zu einzelnen Wochentagen MUSS der Administrator auch eine Uhrzeit für eine tägliche Prüfung auf Aktualität und gegebenenfalls Durchführung von Softwareupdates einstellen können.
Default-Wert: Dienstag / 1:00 Uhr

MGM_KSR_AUTO_UPDATE_TIME ist nur relevant wenn der Administrator keine Wartungsfenster gemäß A_28937* angelegt hat.

Tabelle 24: TAB_KON_820 Einsehbare Konfigurationsparameter der Software-Aktualisierung

ReferenzID
Belegung
Bedeutung und Administrator-Interaktion
MGM_KSR_
KONFIG_URL
URL
SOAP-Endpunkt des Konfigurationsdienstes zum Download von Konfigurationsdaten
MGM_KSR_
FIRMWARE_URL
URL
SOAP-Endpunkt des Konfigurationsdienstes zum Download der Firmware
[<=]

HSK: abgelöst

TIP1-A_4835-02 - Konfigurationswerte des KSR-Client

Der Administrator MUSS die in TAB_KON_670 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_820 aufgelisteten Parameter ausschließlich einsehen können.

Tabelle 25: TAB_KON_670 Konfigurationsparameter der Software-Aktualisierung

ReferenzID
Belegung
Bedeutung und Administrator-Interaktion
MGM_KSR_
AUTODOWNLOAD
Enabled/
Disabled
Der Administrator MUSS den automatischen Download verfügbarer Update-Pakete über den Konfigurationsparameter MGM_KSR_AUTODOWNLOAD an- und abschalten können.
Default-Wert: Enabled
MGM_KSR_SHOW_
TRIAL_UPDATES
Enabled /
Disabled
Der Administrator MUSS einschalten können, dass zusätzlich zur Anzeige von Update-Paketen für den Online-Produktivbetrieb auch die Anzeige von Erprobungs-Update-Paketen erfolgt.
Wenn MGM_KSR_SHOW_TRIAL_UPDATES von Disabled auf Enabled gesetzt wird, muss ein Warnhinweis angezeigt werden, dass die Installation von Erprobungs-Update-Paketen nur für Teilnehmer der Erprobungen vorgesehen ist.
Default-Wert: Disabled
MGM_KSR_AUTO_UPDATE Enabled / Disabled Der Administrator MUSS pro Gerät (Konnektor und Kartenterminals) das automatische Softwareupdate ein- und ausschalten können.
Default-Wert: Enabled
Falls MGM_KSR_AUTO_UPDATE=Enabled wird MGM_KSR_
AUTODOWNLOAD=Enabled gesetzt.
MGM_KSR_AUTO_
UPDATE_TIME		 Wochentag / Uhrzeit
Oder
täglich / Uhrzeit		 Der Administrator MUSS den Wochentag und die Uhrzeit einstellen können, wann automatische Softwareupdates durchgeführt werden.
Als Wochentag MUSS es neben den einzelnen Wochentagen auch einen Wert für eine tägliche Prüfung auf Aktualität und gegebenenfalls Durchführung von Softwareupdates geben.
Default-Wert: Montag / 1:00 Uhr

Tabelle 26: TAB_KON_820 Einsehbare Konfigurationsparameter der Software-Aktualisierung

ReferenzID
Belegung
Bedeutung und Administrator-Interaktion
MGM_KSR_
KONFIG_URL
URL
SOAP-Endpunkt des Konfigurationsdienstes zum Download von Konfigurationsdaten
MGM_KSR_
FIRMWARE_URL
URL
SOAP-Endpunkt des Konfigurationsdienstes zum Download der Firmware
[<=]

Hinweis: Die Adressen des Konfigurationsdienstes werden im Rahmen des VPN-Verbindungsaufbaus ermittelt (siehe [gemSpec_VPN_ZugD#5.1.1.2 TUC_VPN-ZD_0001])

HSK: geändert

TIP1-A_4836-03 - Automatische Prüfung und Download von Update-Paketen

Der Konnektor MUSS täglich die folgenden Schritte durchführen:

  1. TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
  2. pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf angeschlossenen Kartenterminals vorhanden
  3. Ist für wenigstens ein angeschlossenes Kartenterminal eine neuere Version vorhanden, MUSS der Konnektor darüber via    
    TUC_KON_256 „Systemereignis absetzen“ {
            topic = „KSR/UPDATES_AVAILABLE“;     
            eventType = Op;     
            severity = Info;     
            parameters  = (<Param>);    
            doLog=false }    
    informieren. Je gefundenem Update MUSS <Param> mit folgenden Werten belegt sein:    
    <Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                         ProductCode= $UpdateInformation/ProductCode;
                         ProductName=$UpdateInformation/ProductName;
                         FirmwareVersion=$UpdateInformation/FirmwareVersion;
                         Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                         FWPriority=$UpdateInformation/Firmware/FWPriority;
                         FirmwareReleaseNotes=
                                          $UpdateInformation/Firmware/FirmwareReleaseNotes“
  4. Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor in den Betriebszustand EC_FW_Update_Available übergehen.
  5. Die listUpdateResponse mit neueren Firmwareversionen MÜSSEN für eine spätere Einsichtnahme durch den Administrator bereitgehalten werden (via (TIP1-A_4837*) „Übersichtsseite des KSR-Client). Ein neuerlicher Abruf dieser Informationen DARF NICHT erforderlich sein.
  6. Der Konnektor SOLL pro KT-Modell das Updatepaket mit der höchsten Firmware Version über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
  7. Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.
Der Konnektor MUSS immer nur die neusten Update-Pakete für eine Nutzung vorhalten. Eventuell vorhandene ältere, nicht genutzte Update-Pakete KÖNNEN überschrieben werden.
Nach einem erfolgreichen Download DÜRFEN die Namen der Dateien eines Update-Paketes beim Abspeichern NICHT verändert werden. [<=]

HSK: abgelöst

TIP1-A_4836-02 - ab PTV4: Automatische Prüfung und Download von Update-Paketen

Der Konnektor MUSS täglich die folgenden Schritte durchführen:

  1. TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
  2. pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf dem zugehörigen Gerät (Konnektor selbst oder Kartenterminal) vorhanden
  3. Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor darüber via    
    TUC_KON_256 „Systemereignis absetzen“ {
            topic = „KSR/UPDATES_AVAILABLE“;     
            eventType = Op;     
            severity = Info;     
            parameters  = (<Param>);    
            doLog=false }    
    informieren. Je gefundenem Update MUSS <Param> mit folgenden Werten belegt sein:    
    <Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                         ProductCode= $UpdateInformation/ProductCode;
                         ProductName=$UpdateInformation/ProductName;
                         FirmwareVersion=$UpdateInformation/FirmwareVersion;
                         Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                         FWPriority=$UpdateInformation/Firmware/FWPriority;
                         FirmwareReleaseNotes=
                                          $UpdateInformation/Firmware/FirmwareReleaseNotes“
  4. Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor in den Betriebszustand EC_FW_Update_Available übergehen.
  5. Die listUpdateResponse mit neueren Firmwareversionen MÜSSEN für eine spätere Einsichtnahme durch den Administrator bereitgehalten werden (via (TIP1-A_4837) „Übersichtsseite des KSR-Client). Ein neuerlicher Abruf dieser Informationen DARF NICHT erforderlich sein.
  6. Sofern ein Update-Paket für den Konnektor selbst vorliegt, MUSS der Konnektor die mit diesem Paket gelieferten Parameter Priority (entspricht UpdateInformation/Firmware/FWPriority) und Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) auswerten und bei KSR:Priority=Kritisch persistent ablegen.
  7. Sofern MGM_KSR_AUTODOWNLOAD = Enabled, MUSS der Konnektor bei Update-Paketen, die den Konnektor selbst betreffen, das Updatepaket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
  8. Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.
  9. Ist der Download von Update-Paketen für den Konnektor abgeschlossen, MUSS der Konnektor darüber via
TUC_KON_256 „Systemereignis absetzen“ {
        topic = „KSR/UPDATE/KONNEKTOR_DOWNLOAD_END“;
        eventType = Op;     
        severity = Info;     
        parameters  = (<Param>)}    
informieren. Je heruntergeladenem FW-Paket MUSS <Param> mit folgenden Werten belegt sein:    
<Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                     ProductCode= $UpdateInformation/ProductCode;
                     ProductName=$UpdateInformation/ProductName;
                     FirmwareVersion=$UpdateInformation/Firmware/FWVersion;
                     Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                     FWPriority=$UpdateInformation/Firmware/FWPriority;
                     FirmwareReleaseNotes
                                     =$UpdateInformation/Firmware/FirmwareReleaseNotes“
  1. Sofern MGM_KSR_AUTODOWNLOAD = Enabled, SOLL der Konnektor bei Update-Paketen, die Kartenterminals betreffen, pro KT-Modell das Updatepaket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
  2. Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.

Der Konnektor MUSS immer nur die neusten Update-Pakete für eine Nutzung vorhalten. Eventuell vorhandene ältere, nicht genutzte Update-Pakete KÖNNEN überschrieben werden.
Nach einem erfolgreichen Download DÜRFEN die Namen der Dateien eines Update-Paketes beim Abspeichern NICHT verändert werden. [<=]

HSK: unverändert

TIP1-A_7220 - Konnektoraktualisierung File Transfer Ranges

Der Konnektor KANN für den Download von Update-Paketen über I_KSRS_Download::get_Updates die Option Range Requests [RFC7233#3.1] zur Fortsetzung von unterbrochenen Transfers nutzen. [<=]

HSK: geändert

TIP1-A_4837-01 - Übersichtsseite des KSR-Clients

Die Administrationsoberfläche des KSR-Clients MUSS dem Administrator eine Übersichtsseite anbieten, die eine Liste von Geräteeinträgen für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=„gepairt“ enthält.
Der Administrator MUSS die Liste der Kartenterminals nach Kartenterminalmodellen gruppieren können (gleiche Werte für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion).
Je Geräteeintrag MÜSSEN die über „Automatische Prüfung und Download von Update-Paketen“ ermittelten listUpdatesResponse bereitstehen.
Je Geräteeintrag MUSS die Version der aktuell installierten Software dargestellt werden. Sind Bestandteile der installierten Software unabhängig aktualisierbar, so MUSS für jedes der Bestandteile die Version angezeigt werden.
Der Administrator MUSS eine Aktualisierung aller listUpdatesResponse über TUC_KON_282 „UpdateInformationen beziehen“ auslösen können.
Geräteeinträge, die über listUpdatesResponse mit neuerer Firmwareversion als das zugehörige Gerät verfügen, MÜSSEN hervorgehoben werden.
[<=]

HSK: abgelöst

TIP1-A_4837 - Übersichtsseite des KSR-Client

Die Administrationsoberfläche des KSR-Clients MUSS dem Administrator eine Übersichtseite anbieten, die einen Geräteeintrag für den Konnektor selbst, sowie eine Liste von Geräteeinträgen für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=„gepairt“ enthält.

Der Administrator MUSS die Liste der Kartenterminals nach Kartenterminalmodellen gruppieren können (gleiche Werte für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion).

Je Geräteeintrag MÜSSEN die über „Automatische Prüfung und Download von Update-Paketen“ ermittelten listUpdatesResponse bereitstehen.

Je Geräteeintrag MUSS die Version der aktuell installierten Software dargestellt werden. Sind Bestandteile der installierten Software unabhängig aktualisierbar, so MUSS für jedes der Bestandteile die Version angezeigt werden.

Der Administrator MUSS eine Aktualisierung aller listUpdatesResponse über TUC_KON_282 „UpdateInformationen beziehen“ auslösen können.

Geräteeinträge, die über listUpdatesResponse mit neuerer Firmwareversion als das zugehörige Gerät verfügen, MÜSSEN hervorgehoben werden.

Je Geräteeintrag MUSS die Zugehörigkeit der installierten Software und der Software-Updates zum Online-Produktivbetrieb oder zu einer Erprobung (inklusive Name der Erprobung) dargestellt werden.

[<=]

HSK: unverändert

TIP1-A_4838 - Einsichtnahme in Update-Informationen

Für alle Geräteeinträge MUSS der Administrator zu den listUpdatesResponse sowohl die FirmwareGroupReleaseNotes als auch jedes enthaltene UpdateInformation-Element einsehen können. Dazu MUSS der Konnektor

[<=]

HSK: geändert

TIP1-A_4839-02 - Auswahl und Pflege manuell durchzuführender Updates

Der Administrator MUSS im Update Schedule einzelne Geräteeinträge bzw. Gruppen mit der jeweiligen UE_Target_FW_Version für die sofortige Durchführung eines Updates markieren können.
Zusätzlich MUSS der Administrator für markierte Geräteeinträge Update-Pakete lokal einspielen können (etwa durch ein Upload- bzw. Download-Interface in der Administrationsoberfläche). Das Einspielen von Update-Paketen für markierte Geräteeinträge überschreibt UE_Target_FW_Version für diese Einträge.
[<=]

HSK: abgelöst

TIP1-A_4839-01 - Festlegung der durchzuführenden Updates

Der Administrator MUSS in der Übersichtsliste einzelne Geräteeinträge bzw. Gruppen mit der jeweils anzuwendenden UpdateInformation für die Durchführung eines Updates markieren können.
Alternativ MUSS der Administrator neben der Markierung je Geräteeintrag bzw. Gruppe Update-Pakete lokal einspielen können (etwa durch ein Upload- bzw. Download-Interface in der Administrationsoberfläche).
Je Geräteeintrag MUSS der Administrator einen individuellen Ausführungszeitpunkt für die Durchführung des Updates einstellen können.
Der Administrator MUSS für den Geräteeintrag Konnektor festlegen können, ob dieses Update erst gestartet werden darf, wenn zuvor alle festgelegten KT-Updates erfolgreich durchlaufen wurden.
Der Administrator MUSS zu jeder Zeit die gerätebezogene Festlegung für ein Update ändern bzw. löschen können, sofern dieses konkrete Update noch nicht begonnen wurde.
Je Geräteeintrag MUSS der Administrator automatische Softwareupdates aktivieren und deaktivieren können.
[<=]

HSK: geändert

TIP1-A_4840-02 - Manuelles Auslösen von Updates

Der Administrator MUSS für markierte Update Entries im Update Schedule ein gesammeltes, unverzügliches Update auslösen können. Dabei MUSS der Konnektor für alle markierten Update Entries mittels TUC_KON_281 Updates anstoßen. Dabei überschreibt die Vorgabe des Administrators UE_Date, UE_Start_Time, UE_Update_Is_Enabled der markierten Update Entries. Wenn Update Entries mit UE_Admin_PIN_Available=nein unter den markierten sind, muss der Konnektor dem Administrator eine Warnung anzeigen.



[<=]

HSK: abgelöst

TIP1-A_4840-01 - Manuelles Auslösen der durchzuführenden Updates

Der Administrator MUSS für die Liste der markierten Geräteeinträge ein gesammeltes Update auslösen können. Dieses MUSS nach folgendem Muster ablaufen:

  1. Alle Kartenterminaleinträge abarbeiten. Pro markiertem Kartenterminal:
  1. Sofern die KonnektorUpdate-Abhängigkeit von KT-Updates nicht gesetzt wurde oder wenn alle vorgesehenen Kartenterminal-Updates durchgeführt wurden, MUSS das Konnektor-Updates mittels TUC_KON_280 „Konnektoraktualisierung durchführen“ wie folgt begonnen werden:
Wenn der Administrator ein Erprobungs-Update zur Installation auswählt, MUSS er über einen Warnhinweis darüber informiert werden,
dass, falls die Institution oder Organisation des Gesundheitswesens nicht an der Erprobung teilnimmt und dennoch das Update installiert wird, es zu funktionalen Einschränkungen des Konnektors kommen kann. [<=]

EBK 

A_18390 - Automatisches Auslösen der durchzuführenden Updates

Wenn für mindestens ein Gerät das automatische Softwareupdate aktiviert ist, MUSS der Konnektor zur MGM_KSR_AUTO_UPDATE_TIME die Updates nach folgendem Muster durchführen:

[<=]

HSK: unverändert

A_18391 - Automatisches Updates nicht nachholen

Sofern der Konnektor zu MGM_KSR_AUTO_UPDATE_TIME nicht in Betrieb war, DÜRFEN die automatischen Updates später NICHT nachgeholt werden. [<=]

EBK

A_18779 - Hinweise in KSR Update Paket zu Auto-Update

Wenn mit einem Update erstmalig MGM_KSR_AUTO_UPDATE=Enabled aktiv wird, MUSS der Konnektorhersteller über das entsprechende KSR-Paket den Admin an der Konnektor Oberfläche darauf hinweisen, dass mit diesem Update der automatische Softwareupdate aktiv wird.
[<=]