SunSpec, Modbus RTU oder CAN Bus? Protokollwahl für Multi-Inverter-Systeme

CAN Bus: Stärke aus dem Automotive-Bereich

CAN Bus wurde für Anwendungen entwickelt, bei denen Geschwindigkeit und Zuverlässigkeit keine Kompromisse dulden. Mit bis zu 1 Mbit/s und Zykluszeiten von deutlich unter 1 ms ist CAN eine andere Klasse von Kommunikation – und genau das macht es für zeitkritische Aufgaben in Energiesystemen so relevant.

Stärken: CAN ist ein echter Multi-Master-Bus mit nicht-destruktiver bitweiser Arbitrierung: Statt Kollisionen zu reparieren wie bei klassischem Ethernet, gewinnt die Nachricht mit der höchsten Priorität (niedrigster Identifier) sofort den Bus – ohne Datenverlust, ohne Wiederholung. Es ist deterministisch, fehlertolerant durch integriertes Error-Frame-Handling und für sicherheitskritische Anwendungen konzipiert. In Batteriemanagementsystemen ist CAN nach wie vor die erste Wahl – vor allem wenn es um Echtzeit-Überwachung von Zellspannungen, Temperaturen und State-of-Charge geht. Mit 1 Mbit/s erreicht CAN Zykluszeiten von deutlich unter 1 ms.

Schwächen: CAN ist in der Solarbranche nicht standardisiert. Jeder BMS-Hersteller implementiert seinen eigenen CAN-Stack mit proprietären Objektverzeichnissen. Das macht Interoperabilität aufwendig und erfordert für jede Gerätekombination individuelle Integrationsarbeit. Außerdem: CAN ist für kurze Distanzen mit wenigen Knoten ausgelegt. Über RS485 geht man problemlos 1.200 Meter weit – bei CAN mit 1 Mbit/s sind es maximal 40 Meter; erst bei deutlich reduzierten Bitraten steigt die zulässige Buslänge auf praxistaugliche Werte.

Geschwindigkeit als Systemgrenze: Warum CAN und Modbus verschiedene Aufgaben übernehmen

Das ist kein gradueller Unterschied – es ist ein qualitativer. Modbus RTU arbeitet mit typischen Baudraten von 9.600 bis 115.200 Baud. CAN Bus läuft mit bis zu 1 Mbit/s. Das ist ein Faktor von bis zu 100 – und dieser Faktor bestimmt, welche Aufgabenklassen überhaupt erreichbar sind.

Modbus im Sekundenbereich kann Aufgaben wie Leistungsvorgaben, Betriebsmodusumschaltung, Statusabfragen und Abregelungsbefehle sehr gut abbilden. Diese Vorgänge ändern sich langsam, eine sequenzielle Abarbeitung der Slaves ist akzeptabel, und die Latenz spielt keine Rolle.

CAN im Millisekundenbereich eröffnet eine vollständig andere Welt: synchrone Regelschleifen über mehrere Geräte, Echtzeit-Zustandsübertragung, sicherheitsrelevante Reaktionen auf Fehlerzustände und – entscheidend für den Inselbetrieb – die synchrone Phasen- und Frequenzkoordination zwischen parallelen Wechselrichtern. Diese Aufgaben sind mit Modbus strukturell nicht lösbar, unabhängig von der Baudrate.

Die Konsequenz für das Systemdesign: CAN und Modbus konkurrieren nicht – sie ergänzen sich auf unterschiedlichen Zeitebenen.

SunSpec über Modbus: Interoperabilität als Systemarchitektur

SunSpec ist kein eigenes Protokoll – es ist eine Standardisierungsschicht auf Modbus RTU (und TCP). Die SunSpec Alliance hat definiert, welche Informationen in welchen Registern liegen müssen. Geräteklassen, Modell-IDs, Skalierungsfaktoren – alles normiert.

Was bedeutet das in der Praxis? Ein SunSpec-konformer Wechselrichter von Hersteller A und einer von Hersteller B lassen sich mit demselben Code auslesen und steuern. Kein herstellerspezifisches Mapping mehr, kein Reverse Engineering von Datenblättern.

Stärken: Das SunSpec-Modell 123 (Immediate Inverter Controls) standardisiert die wichtigsten Steueraufgaben herstellerübergreifend: maximale Wirkleistungsbegrenzung (WMaxLimPct), Blindleistungsvorgabe, Leistungsfaktor-Einstellung und der Netzanschlussbefehl (Conn) sprechen auf jedem SunSpec-konformen Gerät dieselbe Sprache. Wer heute ein EMS entwickelt, das SunSpec spricht, kann morgen beliebige Fremdhersteller-Inverter integrieren – ohne Codeänderung.

Schwächen: Echtzeit-Anforderungen kann Modbus strukturell nicht erfüllen. Synchronisierte Sollwertvorgaben an mehrere Inverter werden sequenziell abgearbeitet – jedes Gerät bekommt seinen Befehl zu einem leicht anderen Zeitpunkt. Für die Leistungssteuerung im Sekundenbereich ist das irrelevant; für synchronisiertes Umschalten in den Inselbetrieb ist es unzureichend.

Inselbetrieb: Hier trennen sich die Architekturen grundlegend

Genau an diesem Punkt zeigt sich der tiefste architektonische Unterschied zwischen beiden Ansätzen – mit direkten Auswirkungen auf die Netzschutz-Compliance nach VDE-AR-N 4105.

SunSpec/Modbus: Das öffentliche Netz als Referenz für jeden Wechselrichter

In einer SunSpec-basierten Multi-Inverter-Architektur ist jeder Wechselrichter eigenständig am öffentlichen Stromnetz angeschlossen. Jedes Gerät besitzt seinen eigenen NA-Schutz, seine eigene Inseldetektionselektronik und seinen eigenen Kuppelschalter. Für den Netzbetreiber sind es mehrere unabhängige Erzeugungseinheiten – jede erfüllt VDE-AR-N 4105 individuell.

Die Steuerung der Wechselrichter – Leistungsvorgabe, Blindleistung, Abregelung – wird von einem übergeordneten EMS über Modbus koordiniert, mit dem öffentlichen Netz als gemeinsamer Spannungs- und Frequenzreferenz. Das SunSpec-Modell 123 stellt dafür die standardisierten Steuerbefehle bereit; die neueren DER-Modelle der 700er-Serie sehen darüber hinaus explizit „Intentional Island Categories” für geplante Inselnetzbetriebsmodi vor.

Die Grenze liegt in der Reaktionszeit: Die Abschaltung innerhalb der vorgeschriebenen 200 ms (VDE-AR-N 4105: Gesamtabschaltzeit NA-Schutz + Kuppelschalter-Eigenzeit) muss hardwareseitig im Inverter selbst implementiert sein – das kann Modbus nicht übernehmen. Im Fehlerfall agiert jeder Inverter dezentral für sich. Die anschließende Umschaltung in einen koordinierten Ersatzstrombetrieb dauert in der Praxis je nach Hersteller 5 bis 30 Sekunden. Für unterbrechungsempfindliche Lasten ist eine zusätzliche USV zwingend.

CAN Bus: Die Steuerung findet zwischen den Wechselrichtern statt – und der Master kann die Netzreferenz selbst erzeugen

Eine CAN-basierte Parallelarchitektur verfolgt einen grundlegend anderen Ansatz. Ein Master-Wechselrichter übernimmt die zentrale Rolle: Er kann die Verbindung zum öffentlichen Netz halten und dessen Spannungs- und Frequenzreferenz übernehmen – er kann diese Referenz aber auch vollständig selbst erzeugen. Genau das macht ihn zu einem Grid-Forming Inverter. Die Slave-Inverter synchronisieren sich in beiden Fällen ausschließlich auf den Master, nicht auf das externe Netz. Leistungsaufteilung, Blindleistungskompensation und Zustandskoordination werden direkt zwischen den Invertern über CAN geregelt, ohne Umweg über ein übergeordnetes EMS.

Daraus ergeben sich drei Betriebszustände, die das System nahtlos beherrscht:

Im Netzbetrieb synchronisiert sich der Master auf das öffentliche Netz und gibt diese Referenz per CAN an die Slaves weiter. Das System verhält sich nach außen wie ein einziger größerer Wechselrichter.

Bei Netzausfall wechselt der Master innerhalb von Millisekunden in den Grid-Forming-Modus: Er erzeugt jetzt eigenständig Spannung und Frequenz. Für die Slaves ändert sich nichts – sie folgen weiterhin ihrer CAN-Referenz. CAN mit 1 Mbit/s erreicht Zykluszeiten von deutlich unter 1 ms, ausreichend um alle Einheiten synchron umzuschalten, bevor die 200-ms-Grenze der VDE-AR-N 4105 verletzt wird. Konkurrierende Inseldetektionsalgorithmen gibt es nicht, weil nur der Master das Netz beobachtet.

Im geplanten Inselbetrieb – etwa in netzfernen Anlagen oder Microgrids – kann der Master die Spannungs- und Frequenzreferenz von Beginn an selbst erzeugen, ohne dass je eine Netzverbindung bestanden hat. Das System funktioniert dann vollständig autark.

Der Preis für dieses saubere Systemverhalten liegt in der Anwendungsschicht: CAN als physikalischer Standard (ISO 11898) ist offen und herstellerneutral. Das Problem liegt eine Ebene höher – CAN definiert nur, wie Bits übertragen werden, nicht was die Nachrichten bedeuten. Welche Object-IDs verwendet werden, wie der Master-Slave-Handshake abläuft, welche Zustandsinformationen ausgetauscht werden – das ist nicht normiert. In der Praxis implementiert deshalb jeder Hersteller seine eigene Anwendungsschicht, was eine gemischte Installation mit Geräten unterschiedlicher Hersteller faktisch unmöglich macht.

Es gibt mit CANopen (CiA 301) einen offenen Anwendungsschicht-Standard mit definierten Geräteprofilen, der herstellerübergreifende Kommunikation ermöglichen würde. In der Solarbranche ist CANopen jedoch kaum verbreitet – anders als in der Automatisierungstechnik oder Medizintechnik. Hier zeigt sich der direkte Vergleich mit SunSpec besonders deutlich: SunSpec löst genau dieses Normierungsproblem für Modbus und hat damit breite Marktakzeptanz erreicht. Eine vergleichbare, etablierte Standardisierungsschicht für CAN existiert in der Solarbranche bislang nicht.

Und der Master bleibt weiterhin ein kritischer Punkt: Fällt er aus, verlieren alle Slaves ihre Synchronisierungsreferenz – weshalb Master-Redundanz in professionellen Systemen zwingend ist.

Die Kernaussage: Bei SunSpec/Modbus ist das öffentliche Netz die unverzichtbare gemeinsame Referenz, auf die jeder Inverter individuell reagiert. Bei CAN Bus übernimmt der Master-Inverter diese Rolle – er kann sie vom Netz ableiten oder vollständig selbst erzeugen. Die Slaves bekommen davon nichts mit. Das ist der fundamentale Unterschied.

Master-Redundanz: Den Single Point of Failure eliminieren

Da CAN von Haus aus ein Multi-Master-Bus ist, lässt sich Master-Redundanz sauber in die Architektur integrieren. Ein designierter Backup-Inverter überwacht den primären Master über regelmäßige Heartbeat-Nachrichten auf dem CAN-Bus. Bleibt die Heartbeat-Nachricht aus – typisch nach 2–5 fehlenden Zyklen, also wenigen Millisekunden – übernimmt der Backup automatisch die Master-Rolle: Er aktiviert seinen eigenen Grid-Forming-Modus und erzeugt die Spannungs- und Frequenzreferenz für die verbleibenden Slaves.

Damit das ohne Spannungssprünge funktioniert, muss der Backup-Inverter im Standby bereits synchronisiert sein – also dieselbe Phasenlage und Frequenz halten wie der primäre Master. In der Praxis wird das als „Hot Standby” bezeichnet: Der Backup ist jederzeit bereit zu übernehmen, ohne dass die Slaves den Wechsel bemerken. Der Single Point of Failure ist damit eliminiert – allerdings auf Kosten eines zusätzlichen Inverters, der im Normalbetrieb keine Leistung beisteuert.

CAN und Modbus in Kombination: Der Standardfall in professionellen Systemen

In gut designten Hybridspeichersystemen ist die Kombination beider Protokolle nicht die Ausnahme, sondern die Regel – und sie passt exakt zur beschriebenen Schichtenarchitektur.

Die interne CAN-Ebene übernimmt alle zeitkritischen Aufgaben: Synchronisation zwischen den Invertern, BMS-Kommunikation, Grid-Forming-Koordination, Inselbetrieb-Management und Master-Redundanz. Alles, was Millisekunden erfordert, bleibt auf dem CAN-Bus.

Die externe Modbus/SunSpec-Ebene übernimmt alle übergeordneten Steueraufgaben: Leistungsvorgaben vom EMS, Netzbetreiber-Fernsteuerung, Cloud-Monitoring und Systemkonfiguration. Alles, was im Sekunden- oder Minutenbereich gesteuert wird, läuft über Modbus.

Ein Gateway-Inverter oder ein dedizierter Controller übersetzt dabei zwischen beiden Welten. Er spricht intern CAN mit den Invertern und nach außen SunSpec über Modbus TCP mit dem übergeordneten EMS. Das externe System sieht dabei – wie bereits beschrieben – nur einen einzigen logischen Wechselrichter, unabhängig davon, wie viele Einheiten intern per CAN koordiniert werden.

Diese Kombination vereint die Stärken beider Welten: die Echtzeit-Koordinationsfähigkeit von CAN intern mit der offenen Interoperabilität von SunSpec nach außen.

Empfehlung: Schichtenmodell statt entweder/oder

In der Praxis haben sich folgende Ebenen bewährt:

Ebene 1 – Interne Gerätekommunikation (BMS ↔ Inverter): CAN Bus. Kurze Leitungen, deterministisches Timing, bewährte Fehlererkennung und Master-Redundanz über Heartbeat.

Ebene 2 – Gerät-zu-Gerät-Kommunikation (Inverter ↔ Inverter, Inverter ↔ Gateway): CAN Bus intern für Echtzeit-Koordination; Modbus RTU mit SunSpec-Konformität für die Anbindung externer Geräte und Gateways.

Ebene 3 – Systemintegration (Gateway ↔ Cloud/EMS): Modbus TCP über SunSpec oder alternativ MQTT/REST für IoT-Integration. Viele EMS-Systeme sprechen SunSpec nativ.

Fazit

Die Frage „Welches einzelne Protokoll nehme ich?” ist bereits falsch gestellt. Modernes Multi-Inverter-Design braucht eine klare Protokollarchitektur auf mehreren Ebenen.

SunSpec über Modbus hat die Solarbranche ein entscheidendes Stück weitergebracht – weg vom proprietären Registerchaos, hin zu echter Interoperabilität. Wer heute ein Gerät entwickelt und es in fremde Systeme integrierbar machen möchte, kommt an SunSpec-Konformität nicht vorbei.

CAN bleibt dort, wo es hingehört: in der schnellen, sicherheitsrelevanten Gerätekommunikation auf kurzen Strecken – und überall dort, wo mehrere Inverter als eine koordinierte Einheit agieren sollen.

Und Modbus RTU? Es ist kein modernes Protokoll. Aber es funktioniert – solange man weiß, wo seine Grenzen sind.

Welche Erfahrungen habt ihr mit der Protokollwahl in Multi-Inverter-Systemen gemacht? Ich freue mich auf den Austausch in den Kommentaren.

Werner Böhme | Geschäftsführer awb-it GmbH | Embedded Systems & Energiespeicher #SunSpec #ModbusRTU #CANBus #Hybridwechselrichter #Energiespeicher #EmbeddedSystems #Solarenergie #MultiInverter #awbit