Certification & Devices
Certification FAQ
Interested in getting certified? Browse through our FAQs to learn more about the EEBUS Certification process, requirements, and next steps.
General Questions & Process
Certification in the area of Certified Power Limitation is aimed at all manufacturers of controllable systems (e.g. heat pumps, wallboxes, battery storage) as well as manufacturers of energy management systems (EMS) and control units that want to operate securely and in compliance with § 14a EnWG and § 9 EEG in the German market.
Lead times vary depending on current lab capacity. We recommend submitting the application 4 to 6 weeks before the desired testing period. Applications are scheduled on a first-come, first-served basis and subject to availability. In case of scheduling conflicts, priority is given in the order: members → non-members → retake tests.
The actual testing in the lab usually takes only a few days, provided the device is well prepared. The overall effort from application to final certificate issuance depends heavily on the quality of the manufacturer's preparation. We recommend applying early to secure a lab slot in good time.
Physical device testing takes place at our EEBUS Living Lab Cologne, in Cologne. At EEBus Initiative e.V., Deutz-Mülheimer Str. 183, 51063 Cologne, Germany.
In most cases, no. After successful scheduling, you send your physical device (DUT) including the necessary configuration data to Cologne. Provided that your device gives us access to the relevant runtime signals and a way to reset the LPC/LPP use case state machine, our lab team can carry out the specification tests independently. If that access is not available, we will agree with you on how to run the tests together.
The technical review and testing at the EEBUS Living Lab Cologne is entirely free of charge, as part of our non-profit mission. A one-time administrative fee of €1,500 (net, plus VAT), payable to the certification body (Issuer, EEBUService GmbH) for the formal evaluation of the documents, the official issuance of the certificate, and the product's entry into the public certification database.
The procedure does not stop. Thanks to the required developer interface and transparent insight into the runtime signals, our lab team can locate the error in most cases. You receive detailed feedback and the opportunity to improve the software. A retest can be carried out once. If it is not passed, a new application is required.
The process is clearly separated: the EEBUS Living Lab Cologne carries out the tests and issues the technical Test Report. With this report, the applicant turns to EEBUService GmbH – the official certification body (Issuer), which evaluates the documents and issues the certificate.
The Pilot Qualification was an essential first step on the way to a full certification scheme – it validated the approach in practice and laid the groundwork. Building on that experience, EEBUS Certification now provides a more robust and verifiable proof of conformity and secures a higher standard. A pilot qualification is therefore not equivalent to certification. The Pilot Qualification phase has ended. Previously pilot-qualified devices remain available in our archive for transparency and reference.
Scope, Roles & Documents
Only the EEBUS communication is tested; the device under test (DUT) is the EEBUS Communication Unit (EECU). Certification is always granted for a specific product, based on the scope of the tests passed at the Living Lab Cologne.
The EEBUS Certificate is valid for five years from the date of issue. It is not renewed automatically. A recertification is required when the certificate expires, when the product changes in a way that affects the certified scope, or when an updated specification breaks backward compatibility. The fee for a recertification is €500 (net).
Yes. The manufacturer accompanies the tests, and the respective products of the distributors can then be certified based on those results.
If a product family uses a structurally identical EECU, the EECU is tested only once. Two cases apply:
The EECU is an integral part of the product: the certificate can be issued for all listed products in the product family.
The EECU is a separate product: the certificate applies to the EECU, and compatible products are listed underneath it (with the remark "only in connection with EECU").
The device under test (DUT) takes on predefined roles depending on device type and intended use:
Control (SPINE level):
LPC (Limitation of Power Consumption) – § 14a EnWG: LPC CS (the controllable end device that receives and applies limits) or LPC EG (the higher-level control system that receives limits and forwards them to consumers)
LPP (Limitation of Power Production) – § 9 EEG: LPP CS (the generation system/storage that can be curtailed) or LPP EG (the control system that coordinates curtailment commands)
Monitoring:
MPC (Monitoring of Power Consumption): MU (Monitored Unit) – the device that provides its own measurement data · MA (Monitoring Appliance) – the system that receives the data
MGCP (Monitoring of Grid Connection Point): GCP (Grid Connection Point) – the device that provides the measurement data at the grid connection point · MA (Monitoring Appliance) – the system that receives the data
The SHIP Pairing Service eliminates manual configuration effort on site. Instead of manually entering cryptographic keys (SKIs) on both sides, commissioning is based on a one-time, automated exchange via mDNS and DNS-SD. The end device (DevA) securely listens for the encrypted pairing request and validates it cryptographically; the control box (DevZ) sends the authenticated request to establish a lasting trust relationship. For identity verification and the TLS handshake, the SHIP Pairing Service uses secure SHA-256 certificate fingerprints – in line with current requirements from IT security authorities. It complements the established SHIP pairing methods rather than replacing them.
That depends on the device type and the use cases it supports. The two scenarios below show how roles and required documents come together in practice:
Example A – a connected heat pump (§ 14a EnWG + monitoring): processes power limits from the grid and reports consumption data to a higher-level system.
Roles (DUT): SHIP Pairing Service DevA, control LPC CS, monitoring MPC MU
Implementation Guides: LPC, SHIP + SPINE
Test specifications: SHIP, SPINE, SPS, LPC, MPC
Parameter Sheets: SHIP, SPINE, SPS, LPC (CS), MPC (MU)
Example B – an energy management system / EMS (§ 14a EnWG + § 9 EEG + monitoring): acts as the central control unit of a building – processes commands from the grid operator, throttles consumers, curtails generators and aggregates data.
Roles (DUT): SHIP Pairing Service DevA; upstream interface LPC CS + LPP CS; downstream interface LPC EG + LPP EG; monitoring hub MPC MA
Implementation Guides: LPC, LPP, SHIP, SPINE
Test specifications: SHIP, SPINE, SPS, LPC, LPP, MPC
Parameter Sheets: SHIP, SPINE, SPS, LPC (CS and EG), LPP (CS and EG), MPC (MA)
Not sure which roles or documents apply to your product? Just let us know in the contact form when reaching out – we will be happy to help.
Technical Preparation & Requirements
The key to fast certification lies in upfront validation: use the official Implementation Guides (SHIP, SPINE, LPC, LPP) from the specification download area and validate your implementation in advance using the EEBUS Tester in your own development environment. The EEBUS Tester can be licensed via EEBUService GmbH.
Testing is carried out using the standardised EEBUS Tester at the Living Lab Cologne, strictly against the official test specifications.
No. No physical tests with real third-party devices are carried out. Testing is based purely on the official EEBUS test specifications. We verify whether your device behaves exactly in line with the specification at the protocol and application level.
To conduct the tests independently (which significantly reduces the effort for both sides), we need access to the relevant runtime signals. Example for an LPC CS implementation: lpc:limit, lpc:duration, lpc:isActive, lpc:state, lpc:failsafe:limit, failsafe:duration, visibledevice:heartbeat (timestamp of the last received heartbeat). Without transparency into these signals, it is very difficult to validate communication behaviour effectively. We also need a way to reset the LPC/LPP use case state machine, so that this function can reliably be returned to its Init state – a required precondition for many of our tests. This is not a device-wide reset.
Your device must start the commissioning process with an active DHCP client (for both IPv4 and IPv6). Static IP addresses are not permitted in the lab for the initial connection.
EEBUS devices do not find each other on the network via fixed IP addresses, but dynamically via Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD). The device must broadcast a standardised "SHIP TXT record". Mandatory entries include the unique SHIP-ID, the certificate SKI and the device category (Cat); brand, model and serial number are recommended in addition.
Parameter Sheets are manufacturer declarations in which you state the values and capabilities your device actually supports. There is one Parameter Sheet per test specification – for the Use Cases (LPC, LPP, MPC, MGCP) as well as for SHIP, SPINE and the SHIP Pairing Service. Your entries determine which of the specified test cases apply to your device, so the completed sheets need to be available before the test scope can be finalised and a test slot confirmed. The templates are available in the download area on eebus.org.
