Skip to content

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 visualization tool for operational parameters.
Network configuration of the devicesDHCP and AutoIP are mandatory, whereas static IP is optional.Please refer to the document "EEBUS TS Additional Requirements For Ship Nodes," which is available for download in the download section on
Support for Use CasesDevice-specific Use Cases encompass LPC, LPP, MGCP, and MPC.Additional information can be obtained from the whitepaper on "EEBUS Solutions", as well as the technical Use Case documentation and Implementation Guideline available for download on
Regulatory frameworkParticipation 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)
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
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)
Testing the network configurationSupport 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 utilization in certificate verification.
Providing one's own mDNS service (Announcement) and the required information in the "txtRecord" 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 PLim 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 PLim, 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 PLim.
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.
MPCThe transmitted power value is compared with the actually measured power.
Post-assessment (What comes next?)
Inclusion in the compatibility list (Functionality according to LPC Use Case interoperability)Successful tests enable inclusion in the compatibility list.

Best Practice Table:

The timing 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 duration, depending on the device type, is to be chosen until the power reduction is reached.
Best Practice
LPC limit reaction time
The limit is reached after: 60s
The limit is reached after: 300s (5min)
Limit(s) forwarded after:
The accuracy of the LPC limit

(PSteuVE / 10s ≤ PLim)

(PSteuVE / 10s ≤ PLim)

(∑PSteuVE / 10s ≤ PLim)
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 (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:
According to § 14a:
Calculation formula of the BNetzA
According to § 14a:
Accuracy of the transmitted MPC power value