C_12485_Anlage_V1.0.0
C_12485_Anlage
Inhaltsverzeichnis
1 Änderungsbeschreibung
1.1 Beschreibung des optimierten KT-Update-Prozesses
1.1.1 Default-Verhalten
- Der Konnektor findet auf dem KSR ein Update für ein angeschlossenes Kartenterminal.
- Der Konnektor prüft für jedes Kartenterminal, ob die Admin-PIN hinterlegt ist. Wenn diese fehlt, wird die Information in den Update-Schedule eingetragen und das Update deaktiviert.
- Der Konnektor plant das Update gemäß MGM_KSR_AUTO_UPDATE_TIME in den Update_Schedule ein.
- (optional) Der Konnektor sendet eine Email-Benachrichtigung zum Update_Schedule.
- (optional) Der Administrator editiert den Update Schedule: Anpassung von Datum/Uhrzeit, Einträge de/aktivieren.
- Zum geplanten Update_Schedule (oder beim nachfolgenden Verbinden) wird das KT aktualisiert.
1.1.2 Change-Window-Verhalten
- Der Konnektor findet auf dem KSR ein Update für ein angeschlossenes Kartenterminal.
- Der Konnektor prüft für jedes Kartenterminal, ob die Admin-PIN hinterlegt ist. Wenn diese fehlt, wird die Information in den Update-Schedule eingetragen und das Update deaktiviert.
- Der Konnektor findet in den hinterlegten Change_Windows ein Wartungsfenster, dessen Startzeit größer oder gleich "jetzt + Lead_Time" ist.
- Der Konnektor plant das Update für das nächste Wartungsfenster nach der Lead_Time ein.
- (optional) Der Konnektor sendet eine Email-Benachrichtigung zum Update_Schedule.
- (optional) Der Administrator editiert den Update Schedule: Anpassung von Datum/Uhrzeit, Einträge de/aktivieren.
- Der Konnektor updated nach dem Update_Schedule.
1.1.3 Pflege des Update Schedules
- Der Administrator kann zum Editieren einzelne oder auch mehrere KTs auswählen.
- Es können Datum/Uhrzeit auf einen Zeitpunkt in den nächsten 12 Monaten gesetzt und Einträge de/aktiviert werden.
- Zu jedem KT kann es nur einen Eintrag im Update_Schedule geben.
- Ausgeführte Einträge werden entfernt.
- Für geschlossene Zeitfenster werden aktivierte Einträge entfernt. Wurde kein Update durchgeführt, werden mit der nächsten KSR-Abfrage neue Einträge im Update_Schedule angelegt.
- Deaktivierte Einträge werden nicht entfernt, es sei denn, eine höhere FW-Version wird gefunden. Dann wird der deaktivierte Eintrag entfernt und durch einen neuen, aktivierten Eintrag ersetzt.
1.1.4 Feedback von den Anbietern
- E-Mail-Benachrichtigungen sollten über das Zugangsmodul versendet werden, weil da schon E-Mail-Adresse bzw. Nutzer bekannt sind.
- Der Betreiber möchte eine Möglichkeit haben, ein KT-Update für alle vKon zu blockieren, wenn ein übergreifendes Problem mit dem Update erkannt wird.
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
|
|
| Vorbedingungen
|
|
| Eingangsdaten
|
|
| 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:
|
| 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:
- UE_Update_Is_Enabled=ja
- UE_Admin_PIN_Available=ja
- UE_End_Date/UE_End_Time ist noch nicht erreicht bzw. nicht vorhanden
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):
- dem Administrator die Möglichkeit geben, die KT-Admin-Credentials durch Aufbauen einer Adminsession zu überprüfen
- im zugehörigen Update Entry "UE_Admin_PIN_Available = ja" setzen
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:
- Events (Topic Ebene 1):„KSR“
- Konfigurationsparameter: „MGM_“
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
- UE_Update_Is_Enabled=ja
- UE_Start_Date/UE_Start_Time nicht gesetzt oder überschritten
- UE_End_Date/UE_End_Time nicht gesetzt oder noch nicht erreicht
[<=]
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
|
|
| Vorbedingungen
|
|
| Eingangsdaten
|
|
| 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:
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
|
|
| Vorbedingungen
|
|
| Eingangsdaten
|
|
| 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:
„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:
|
| 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
|
|
| Vorbedingungen
|
|
| Eingangsdaten
|
|
| 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:
„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:
|
| 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
|
|
| 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:
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
|
|
| 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:
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
|
|
| Vorbedingungen
|
|
| Eingangsdaten
|
|
| Komponenten
|
Konnektor, Konfigurationsdienst
|
| Ausgangsdaten
|
|
| Nachbedingungen
|
keine
|
| Standardablauf
|
Der Konnektor MUSS folgende Schritte durchlaufen:
|
| 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
|
|
| Eingangsdaten
|
|
| Komponenten
|
Konnektor, Konfigurationsdienst
|
| Ausgangsdaten
|
|
| Nachbedingungen
|
keine
|
| Standardablauf
|
|
| 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
|
|
| 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
|
|
| 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:
- TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
- pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf angeschlossenen Kartenterminals vorhanden
- 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“ - Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor in den Betriebszustand EC_FW_Update_Available übergehen.
- 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.
- 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.
- 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.
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:
- TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
- 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
- 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“ - Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor in den Betriebszustand EC_FW_Update_Available übergehen.
- 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.
- 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.
- 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.
- 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.
- Ist der Download von Update-Paketen für den Konnektor abgeschlossen, MUSS der Konnektor darüber via
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;
=$UpdateInformation/Firmware/FirmwareReleaseNotes“
- 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.
- 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
-
alle Felder der Struktur verständlich umsetzen und strukturiert anzeigen (inkl. der Notes für jedes Firmwarefiles- und Documentationsfiles-Element)
-
jedes über das Documentationfiles-Element erreichbare Dokument auf Anforderung des Administrator herunterladen und anzeigen. Es MÜSSEN dabei mindestens die folgenden Dokumentenformate zur Anzeige gebracht werden können: Text, PDF, JPEG, TIFF
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:
- Alle Kartenterminaleinträge abarbeiten. Pro markiertem Kartenterminal:
- Wenn Ausführungszeitpunkt nicht gesetzt:
Anwenden des definierten Updates mittels TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ - Wenn Ausführungszeitpunkt gesetzt:
Anwenden des definierten Updates mittels TUC_KON_281 sobald der Ausführungszeitpunkt erreicht ist oder, sofern der Konnektor zum Ausführungszeitpunkt nicht in Betrieb war, überschritten wurde. Konnte das Kartenterminal nicht erreicht werden, so MUSS das gesetzte Update im KSR-Client für eine spätere Anwendung erhalten bleiben (wird ereignisgesteuert neu ausgelöst).
- 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 Ausführungszeitpunkt nicht gesetzt: TUC-Aufruf direkt
- wenn Ausführungszeitpunkt gesetzt: TUC-Aufruf direkt sobald der Ausführungszeitpunkt erreicht ist oder, sofern der Konnektor zum Ausführungszeitpunkt nicht in Betrieb war, überschritten wurde
- dass es sich um ein Erprobungs-Update handelt,
- für welche Erprobung es vorgesehen ist,
- dass das Update-Paket nur installiert werden sollte, wenn die Institution oder Organisation des Gesundheitswesens an der Erprobung teilnimmt,
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:
- Alle Geräte (Kartenterminals und Konnektor), für die MGM_KSR_AUTO_UPDATE=Enabled ist, werden markiert
- Alle Kartenterminaleinträge abarbeiten
- Pro markiertem Kartenterminal: Anwenden des automatischen Updates mittels TUC_KON_281 „Kartenterminalaktualisierung anstoßen"
- Sofern die Konnektorupdate-Abhängigkeit von KT-Updates nicht gesetzt wurde oder wenn alle vorgesehenen Kartenterminal-Updates durchgeführt wurden, MUSS für einen markierten Konnektor das Konnektor-Update mittels TUC_KON_280 „Konnektoraktualisierung durchführen“ begonnen werden.
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.
[<=]