HOME / TEST CONDITIONS

Test Conditions

Preparation

What prerequisites must manufacturers fulfill?

In preparation for testing, we recommend manufacturers to consider the integration of a system data analysis interface (debug interface) or a visualisation tool for operational parameters.

Col1	Col2	Col3
	Network configuration of the devices
	DHCP and AutoIP are mandatory, whereas static IP is optional.	The requirements outlined in the "EEBUS TS Additional Requirements For Ship Nodes" specification form the basis for the tests. This document is available for download on eebus.org.
	Support for Use Cases
	Device-specific Use Cases encompass LPC, LPP, MGCP, and MPC.	Additional information can be found in the whitepaper on "EEBUS Solutions", as well as the technical Use Case specifications, and the Implementation Guideline available for download on eebus.org. The requirements outlined in these documents form the basis for the tests.
	Terms of Use
	Participation requires a written consent to the Terms of Use.	The Terms of Use can be downloaded here.

Execution

Which criteria are examined in the course of the tests?

1st Module – Integrations test (virtual environment)

Col1	Col2
Testing the functionality of the Use Case (Solution Power Limitation); including SPINE and SHIP
Automated testing using a test tool in accordance with EEBus test specifications.	Conforms to the VDE-AR-E 2829-6; Parts 1 to 4. Our test specifications are available for download on eebus.org. These have been submitted to the DKE to be incorporated into VDE-AR-E 2829-6 Part 5. Our current testing capabilities can be viewed here.

2nd Module – System test (real reference setup)

Col1	Col2
Testing the network configuration
Support for dynamic IP address allocation (DHCP and AutoIP). If not available, fallback to static IP.
Testing the installation process with a counterpart
Establishing a connection with the counterpart: - Establishing a trust relationship - Initiation of the connection establishment	Optical extraction of the device's Subject Key Identifier (SKI) through a QR code for utilisation in certificate verification. Providing one's own mDNS service (Announcement) and the required information in the "TXT-Record" data field. Serves to enable the counterpart to identify one's own device at the IP level within the network. Verification of whether the counterparts appear correctly within one's own manufacturer application, the device-specific web user interface, or on the device display. Devices can be viewed and confirmed – ideally in just 3 menu steps (Settings → EEBUS → Device List). In the device list, the counterpart can be confirmed.
Testing the Solution Power Limitation
§ 14a specifications (System test of SMGW, control box/CLS-Gateway, EMS, and controllable device)	Power Limitation: Power limitation P_Lim necessitates the acceptance of the specified limit, with the physical parameters needing consideration according to the best practice table (see below). The actual power consumption is measured in accordance with the recommended physical parameters. This is determined over a specified period and must not exceed the value of the transmitted power limitation on average. An effective energy management system (EMS) plays a crucial role in adhering to power limitation in complex systems. Therefore, the EMS receives a power limitation P_Lim, which it must distribute to controllable devices. The actual power consumption of all devices is measured. This is determined over a specified period and must not exceed the value of the transmitted power limitation on average, implying that the sum of the measured powers of the controllable devices must always be less than or equal to P_Lim. Fulfillment of Acknowledgment: The acknowledgment (ACK) from the limited device confirms to the counterpart that the limit has been accepted. The correct transmission and reception of the ACK are verified. An Energy Management System (EMS) can pursue two strategies in this regard: The EMS sends an ACK to its counterpart only after it has received all ACKs from the connected devices. As long as an EMS is confident that it can achieve a just-received power limitation, it responds immediately with an ACK. Failsafe Limit: In the configuration of failsafe mechanisms, it is imperative to accept the received value and ensure this acceptance through (persistent) storage. This ensures a reliable application of the defined limits, particularly in the event of a connection loss. To achieve this, the counterpart is disconnected from the device, and based on the actual power consumption, it is verified whether the device under test enters the failsafe state.
MPC	The transmitted power value is compared with the actually measured power.

Post-assessment

What comes next?

Col2	Col3	Col1
	Adding to the compatibility list (Functionality according to LPC Use Case interoperability)
	Successful tests enable inclusion in the list of EEBUS Devices.

Best Practice Table

The timings and power values may vary depending on the device.
A value within this range is to be selected based on the specific power range of the device.
A maximum time duration is to be selected depending on the type of device until the power limitation is achieved.

	EVSE	HP	EMS
LPC limit reaction time	The limit is reached after: 60s	The limit is reached after: 300s (5min)	Limit(s) forwarded after: 30s
The accuracy of the LPC limit (10s average)	+/-5% (P_SteuVE / 10s ≤ P_Lim)	+/-5% (P_SteuVE / 10s ≤ P_Lim)	+/-5% (∑P_SteuVE / 10s ≤ P_Lim)
Response time ACK (specified in the SPINE protocol specification)	up to 10s	up to 10s	up to 10s
Time until transitioning to failsafe state in absence of received heartbeat	120s	120s	120s (EMS with LPC server functionality)
Failsafe Duration Minimum (minimal duration in the failsafe state)	7200s (120min)	7200s (120min)	-
Failsafe Consumption Active Power Limit (Default value; actual value adjusted during operation)	According to § 14a: 4.2kW	According to § 14a: Calculation formula of the BNetzA	According to § 14a: 4.2kW
Accuracy of the transmitted MPC power value	+/-5%	+/-5%	-