| Col1 | Col2 | Col3 | ||
|---|---|---|---|---|
Vorbereitung (Welche Voraussetzungen müssen Hersteller erfüllen?) | ||||
In der Vorbereitung auf Tests empfehlen wir Herstellern die Integration einer Schnittstelle zur Systemdatenanalyse (Debug-Schnittstelle) oder eines Visualisierungstools für Betriebsparameter. | ||||
| Netzwerkkonfiguration der Geräte | DHCP und AutoIP sind erforderlich, statische IP ist optional. | Siehe auch Dokument "EEBUS TS Additional Requirements For Ship Nodes"; wird Januar 2024 auf www.eebus.org/download bereitstehen. | ||
| Unterstützung der Use Cases | Gerätespezifische Use Cases umfassen LPC, LPP, MGCP und MPC. | Siehe Solution "Power Limitation" der EEBus Initiative e.V.. | ||
| Rechtlicher Rahmen | Unterschrift erforderlich für: - Living Lab Cologne Participation Agreement - Permission for Compatibility List Inclusion | Finale Dokumente werden Januar 2024 auf livinglabcologne.com veröffentlicht. | ||
Durchführung (Welche Kriterien werden im Rahmen der Tests untersucht?) | ||||
| 1. Schritt – Integrationstest (virtuelle Umgebung) | ||||
| Testen der Use Case Funktionalität; inklusive SPINE und SHIP | Automatisierte Tests mittels Testtool gemäß EEBus-Testspezifikationen | Entspricht der VDE-AR-E 2829-6; Teil 1 bis 4. Pre-Releases der Testspezifiaktionen: Diese liegen dem DKE vor, um zukünftig in die VDE-AR-E 2829-6 Teil 5 überführt zu werden. | ||
| 2. Schritt – Systemtest (Musterhaus) | ||||
| Testen der Netzwerkkonfiguration | Unterstützung von dynamischer IP-Adressvergabe (DHCP und AutoIP) Falls nein, Fallback: statische IP | |||
| Testen des Installationsprozess mit einer Gegenstelle | Aufbau einer Verbindung zur Gegenstelle: - Herstellung eines Vertrauensverhältnisses - Initiierung des Verbindungsaufbaus | Optisches Auslesen des eigenen Geräte-SKI (Subject Key Identifier) mittels QR-Code zur Verwendung in der Zertifikatsüberprüfung. | ||
| Bereitstellen des eigenen mDNS-Dienstes (Announcement) und der geforderten Informationen im Datenfeld „txt-Record“. Dient der Gegenstelle, das eigene Gerät auf IP- Ebene im Netzwerk zu identifizieren. | ||||
| Kontrolle, ob die Gegenstellen korrekt in der eigenen Hersteller-App, der gerätespezifischen Web-Benutzeroberfläche oder auf dem Geräte-Display erscheinen. | ||||
| Geräte sehen und bestätigen – idealerweise in nur 3 Menüschritten (Einstellungen → EEBUS → Geräteliste). In der Geräteliste kann die Gegenstelle bestätigt werden. | ||||
| Testen der Solution Leistungslimitierung (Power Limitation) | §14a Vorgaben Test gegen Steuerbox/CLS-Gateway, SMGW und EMS | Leistungslimitierung: Die Leistungslimitierung erfordert das Akzeptieren des festgelegten Limits, wobei die physikalischen Parameter gemäß der Best-Practice-Tabelle (siehe unten) berücksichtigt werden müssen. Es wird die reale Leistungsaufnahme entsprechend der empfohlenen physikalischen Parametern gemessen. | ||
| Nachweiserfüllung: Das Acknowledge (ACK) des limitierten Gerätes bestätigt der Gegenstelle, dass das Limit akzeptiert wurde. Es wird das korrekte Senden und Empfangen des ACK überprüft. | ||||
| Failsafe Limit: Für die Failsafe-Konfiguration ist es essenziell, den empfangenen Wert zu akzeptieren und diese Akzeptanz durch eine (persistente) Speicherung sicherzustellen. Dies gewährleistet eine zuverlässige Anwendung der festgelegten Limits, insbesondere im Falle eines Verbindungsabbruchs. Hierfür wird die Gegenstelle vom Gerätes getrennt und anhand der realen Leistungsaufnahme überprüft, ob das zu testende Gerät den Failsafe State einnimmt. | ||||
| MPC | Die Überprüfung, ob der Use Case unterstützt wird, bezieht sich sowohl auf die Unterstützung der relevanten Datenpunkte als auch auf die Überprüfung, dass die Leistungswerte je nach Gerätetyp korrekt gesendet bzw. empfangen werden. | |||
| MGCP | Die Überprüfung, ob der Use Case unterstützt wird, bezieht sich sowohl auf die Unterstützung der relevanten Datenpunkte als auch auf die Überprüfung, dass die Leistungswerte je nach Gerätetyp korrekt gesendet bzw. empfangen werden. | |||
Nachbereitung (Wie geht es weiter?) | ||||
| Compatibility list inclusion (Funktionalität gemäß LPC Use Case – Interoperabilität) | Erfolgreiche Tests gewährleisten die Interoperabilität des Geräts und qualifizieren es somit für die Aufnahme in die Interop-Liste. | |||
| Im Falle fehlgeschlagener Tests wird eine Handlungsempfehlung bereitgestellt. | ||||
Best Practice Tabelle:
| Col1 | Col2 | Col3 | Col4 | |||
|---|---|---|---|---|---|---|
Die Zeiten sowie die Leistungswerte können je nach Gerät variieren.
Je nach spezifischen Leistungsbereich des Geräts ist ein Wert innerhalb dieses Bereichs zu wählen.
Bis zum Erreichen der Leistungsreduzierung ist eine maximale Zeitdauer je nach Gerätetyp zu wählen.
| ||||||
Timings | ||||||
EVSE | HP | EMS | ||||
| Reaktionszeit LPC Limit | Limit erreicht nach: 60s | Limit erreicht nach: 300s (5min) | Limit(s) weitergereicht nach: 30s | |||
| Genauigkeit des LPC-Limits | +/-5% | +/-5% | +/-5% | |||
| Antwortzeit ACK (Vorgabe SPINE Protocol Specification) | up to 10s | up to 10s | up to 10s | |||
| Zeit bis Wechsel in den failsafe state ohne empfangenen Heartbeat | 120s | 120s | 120s (EMS mit LPC Server Funktionalität) | |||
| Failsafe Duration Minimum (Minimale Dauer im Failsafe State) | 7200s (120min) | 7200s (120min) | - | |||
| Failsafe Consumption Active Power Limit (Default-Wert; realer Wert wird im laufenden Betrieb angepasst) | Gemäß §14a: 4.2kW | Gemäß §14a: Berechnungsformel BNetzA | Gemäß §14a: 4.2kW | |||