Skip to content

Test Conditions


What prerequisites must manufacturers fulfill?

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
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 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.


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 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 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.


What comes next?

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

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