openWB Pro / Wie ist ISO 15118 implementiert?

[aiole]

Also zunächst gilt wie schon seit dem Bestehen von oWB:
SW open source
HW closed source

Das es so ist weiß ich, auch die Begründung dafür habe ich mir schon öfter gelesen, ich Frage mich nur ob das noch sinnvoll ist (in der Anfangsphase wenn noch kein Produkt auf dem Markt ist es absolut nachvollziehbar, damit man nicht von jemand anderem "überholt" wird, aber jetzt mit etabliertem Produkt und Förderung durch die KfW?)

Ich denke ja. Warum?
Weil es sich bewährt hat.
btw: Privatförderung ruht gerade.

openWB richtet sich ja zentral an technik-affine Kunden, die gerne wissen was sie kaufen, hätte ich nicht an anderer Stelle detaillierte Bilder vom Inneren der openWB gesehen würde ich mir ernsthaft überlegen eine zu kaufen. Und mit entsprechender Lizenz kann man den kommerziellen Nachbau verbieten (es gibt ja nicht nur closed und open source, auch sowas wie "shared source" (der Begriff wurde glaube ich von MS eingeführt für ihre Lizenzen die genau so sind: Ihr dürft euch den source anschauen um zu verstehen wie es funktioniert und Verbesserungen einreichen, aber nichts eigenes damit machen)).

Jein.
Die oWB richtet sich vorrangig an "normale" Kunden. Sie kann aber auch auf "Nerd-Niveau" eingesetzt werdern .
Des Weiteren will sich das oWB-Team auf das Produkt zum Wohle der Anwender und nicht auf Lizenzüberwachung konzentrieren. Dies würde mehrere (teure) Juristen bedingen.

Du machst es Dir mit Deinen Ideen/Vorschlägen leider zu einfach. Das funktioniert so nicht in der Praxis.
Ich glaube, die meisten Leute mögen ein gutes Produkt mit community-unterstützter Weiterentwicklung. Wie jedoch HW im Detail realisiert wird, muss man dem Hersteller überlassen, da hier Haftungsfragen eine Rolle spielen.

Ein ordentlicher 15118-20-Ladecontroller mit PLC und Sonderfeatures ist kein Massenprodukt und wird schon ordentlich etwas kosten. Dafür bekommt man ein abgeschlossenes, getestetes Modul mit passenden Ansteuerschnittstellen.

Noch nicht Ich denke wenn in 1 bis 2 Jahren alle Neuwagen da einen großen Mehrwert bieten mit V2H/V2G und sich hoffentlich die Lieferketten wieder Normalisieren wird das anders werden. Die Hardware kostet wie gesagt nicht viel, wenn es ein Massenprodukt wäre könnte ein großer Hersteller so ein Controller für deutlich unter 100€ auf den Markt werfen, im Moment natürlich noch nicht.

Das ist Glaskugelphilosophie.
VW forciert beispielsweise separate DC-WB mit max. 22kW (Preis steht noch aus) und keine AC-bidi-OBC im EV, die das Thema bidi vernünftig, schnell und wirtschaftlich lösen könnten. Dahingehend sehe ich dort noch einen langen, steinigen Weg.

Da ich selbst HW entwickle, weiß ich, dass die alleinige Betrachtung noch das geringste Problem ist. Das perfekte Zusammenspiel mit der SW macht es erst zu einem soliden Produkt. Aufgrund der vielen Varianten, die oWB bietet, ist hier ein großes Testszenario gegeben, dass viel Zeit, Ressourcen und Abstimmungen beansprucht. So etwas findet sich dann im WB-Preis wieder. Oder anders - der alleinige Blick auf die HW-Komponenten spiegelt nicht annähernd die realen Aufwendungen wider.

[stefan_o]

Jein.
Die oWB richtet sich vorrangig an "normale" Kunden. Sie kann aber auch auf "Nerd-Niveau" eingesetzt werdern .

Sicher sind die Allermeisten nicht auf meinem "Nerd-Niveau", aber das meine ich nicht mit technik-affin, sondern einfach Menschen die sich mit der Technik auseinandersetzen und zumindest eine grobe Idee davon haben wollen wie es funktioniert. Wer nicht technik-affin ist sagt dem Elektriker nur ich brauch ne WallBox die mein Auto laden kann, der interessiert sich für den Preis, wie das Teil aussieht, ob die Bedienung einfach ist und die Länge des Ladekabels, etwas wie modularen Aufbau weiß der nicht zu schätzen (das ist nicht böse gemeint, es gibt verschiedene Menschen, es gibt auch viele Dinge die andere ganz toll finden, die ich nicht zu schätzen weiß). Wenn ich mich mit eher nicht technik-affinen Bekannten unterhalte und das Thema auf eigene Wallboxen kommt, dann a) haben sie schon eine oder zumindest schon bestellt und wissen nichtmal was für eine b) "wenn ich ein E-Auto kaufe wird man die bestimmt passend dazu kaufen können" c) wenn ich denen von der openWB erzählt habe und relevante Vorteile wie PV-Überschussladung erwähne: Nachdem sie danach recherchiert haben sind sie abgeschreckt: "ja für dich ist so ein Teil toll, aber ich kenne mich damit ja nicht aus, das soll einfach nur funktionieren, willst du dann immer kommen wenns nicht geht und man da was Einstellen muss?".
Es gibt halt Menschen die nennen den FI-Schalter Hauptsicherung und wissen nicht warum es an der Steckdose mehr als einen Kontakt benötigt.

Des Weiteren will sich das oWB-Team auf das Produkt zum Wohle der Anwender und nicht auf Lizenzüberwachung konzentrieren. Dies würde mehrere (teure) Juristen bedingen.

Ist bei Software doch das gleiche, da würde ich die Wahrscheinlichkeit sogar für viel höher halten, dass jemand das GUI etwas ändert, alle Hinweise auf openWB entfernt und dass dann mit seiner eigenen Hardware günstig verkauft. Und alles eben nicht unter einen freien Lizenz.

Du machst es Dir mit Deinen Ideen/Vorschlägen leider zu einfach. Das funktioniert so nicht in der Praxis.
Ich glaube, die meisten Leute mögen ein gutes Produkt mit community-unterstützter Weiterentwicklung. Wie jedoch HW im Detail realisiert wird, muss man dem Hersteller überlassen, da hier Haftungsfragen eine Rolle spielen.

Solange man es nicht ausprobiert ist das schwer zu beurteilen, es gibt ja Open-Hardware-Produkte die (auch wirtschaftlich) gut funktionieren. community-unterstützte Weiterentwicklung ist toll, ist aber eben schwierig wenn die HW nicht dokumentiert ist.

VW forciert beispielsweise separate DC-WB mit max. 22kW (Preis steht noch aus) und keine AC-bidi-OBC im EV, die das Thema bidi vernünftig, schnell und wirtschaftlich lösen könnten. Dahingehend sehe ich dort noch einen langen, steinigen Weg.

Interessant, das wusste ich nicht. Ich vermute mal die openWB pro hat keinen Wechselrichter integriert (dann wäre der Preis extrem günstig), aber dass wäre dann ein sinnvoller Schritt: openWB bekommt eine Schnittstelle an welcher dann ein Wechselrichter angeschlossen werden kann, der Schütz schaltet dann auf den Wechselrichter um. Je nach Spannung/Strom des EV eignet sich vielleicht ein gewöhnlicher PV-Wechselrichter, der dann von der openWB in Abhängigkeit vom Ladestatus des EV, des Netzbezuges etc. geregelt werden kann.

Da ich selbst HW entwickle, weiß ich, dass die alleinige Betrachtung noch das geringste Problem ist. Das perfekte Zusammenspiel mit der SW macht es erst zu einem soliden Produkt. Aufgrund der vielen Varianten, die oWB bietet, ist hier ein großes Testszenario gegeben, dass viel Zeit, Ressourcen und Abstimmungen beansprucht. So etwas findet sich dann im WB-Preis wieder. Oder anders - der alleinige Blick auf die HW-Komponenten spiegelt nicht annähernd die realen Aufwendungen wider.

Dem habe ich nie widersprochen

[aiole]

Glaube mir - Du bist ein typischer Nerdvertreter (<10% der oWB-Gesamtnutzer) und dafür die closed source HW nach 3 erfolgreichen Jahren plötzlich auf open source umzustellen, birgt ein viel zu hohes Risiko inkl. erheblicher Zusatzaufwendungen. Zum Schluss kopiert sich noch ein Chinese die HW und das war's dann mit oWB. Nein - das würde ich aktuell nicht gutheißen.

OpenWB ist (noch) nicht die RPi-Foundation, die Millionen RPi's verkauft. Man muss einen guten Mittelweg finden, der in einer WIN/WIN-Lösung mündet. Ich denke, die ist momentan gegeben.
VG

[E-lmo]

Die erste sinnvolle Funktion wäre die Übertragung des Ladestandes über das Ladekabel. Gibt es hierzu schon Erkenntnisse?

[aiole]

Wenn's das EV bietet, sollte das gehen.

[HSC]

Die erste sinnvolle Funktion wäre die Übertragung des Ladestandes über das Ladekabel. Gibt es hierzu schon Erkenntnisse?

Beim EQS ist es wohl schon an Bord.
Wann es mal in normale EV und somit in die Breite kommt, steht noch in der Sternen.
VG

[openWB]

@stefan_o

Um auf die Überschrift einzugehen:

Nach dem Standard ist es implementiert.
Zusätzlich wird das soweit aufbereitet das ein Vehicle Identifier wie ein RFID Tag verarbeitet werden kann und über die Schnittstelle ausgegeben wird.

Wenn ich dann auch mal provokativ sein darf, gerne darfst du die Hardware entwickeln als Addon, die Komponenten beschaffen, das ganze durchtesten / zertifizieren lassen, gegen gängige Fahrzeuge testen, mit Herstellern interagieren, in Gremien für die neue Technik aktiv sein, die Software nach Standard implementieren, das auf Plugfests widerum testen wie/wer den Standard implementiert hat, das ganze produzieren und uns als fertiges Addon mit Software für 100€ zur Verfügung stellen. Zusätzlich natürlich die kontinuierliche Pflege übernehmen da stetig anpassen und Weiterentwicklungen nötig sind. Da nehme ich direkt 20.000 von ab...

Die erste sinnvolle Funktion wäre die Übertragung des Ladestandes über das Ladekabel. Gibt es hierzu schon Erkenntnisse?

Ja die gibt es. Bei einer DC Ladung ist es Standard den SoC übermittelt zu bekommen. Die selbe Kommunikation (über PLC) auf AC Seite hat den SoC als optionales Flag. Es steht dem Hersteller also frei ob er diesen mit ausgeben möchte oder nicht. Jetzt dürft ihr 3mal raten was passiert....

Wir sind natürlich dran das hinzubekommen.

[stefan_o]

Nach dem Standard ist es implementiert.
Zusätzlich wird das soweit aufbereitet das ein Vehicle Identifier wie ein RFID Tag verarbeitet werden kann und über die Schnittstelle ausgegeben wird

Ok, vielleicht war meine Frage nicht präzise genug: Was ist wo implementiert? Wenn ich jetzt mal das OSI-Schichtenmodell heranziehe, diese Module mit dem Qualcom-Chip implementieren Layer 1 und 2, ist das in der OpenWB pro ähnlich? Also ist da lediglich ein Modul welches das "HomePlug Green Phy" auf reguläres Ethernet übersetzt ohne den Inhalt zu verarbeiten? Oder ist es ein Modul, welches die komplette Kommunikation mit dem EV übernimmt, so dass die openWB Software dann nicht mit dem Fahrzeug kommuniziert, sondern mit diesem Modul?
Im ersteren Fall könnten neue Features die irgendwann kommen und noch nicht spezifiziert sind einfach in die openWB-Software integriert werden, im letzteren Fall kann man hoffen das der Hersteller des Moduls dann ein Firmware-Update bereitstellt.
Natürlich wäre der erste Fall von der Software-Entwicklung vermutlich deutlich mehr Arbeit (ich kenne das Protokoll nicht, aber das ist naheliegend).

Wenn ich dann auch mal provokativ sein darf, gerne darfst du die Hardware entwickeln als Addon, die Komponenten beschaffen, das ganze durchtesten / zertifizieren lassen, gegen gängige Fahrzeuge testen, mit Herstellern interagieren, in Gremien für die neue Technik aktiv sein, die Software nach Standard implementieren, das auf Plugfests widerum testen wie/wer den Standard implementiert hat, das ganze produzieren und uns als fertiges Addon mit Software für 100€ zur Verfügung stellen. Zusätzlich natürlich die kontinuierliche Pflege übernehmen da stetig anpassen und Weiterentwicklungen nötig sind. Da nehme ich direkt 20.000 von ab...

Wie schon gesagt, mein Kritikpunkt ist nicht, dass es teuer ist, ich kann deine Punkte sehr gut nachvollziehen, sondern das für mich nicht hervorgeht was ich für mein Geld bekomme. Bei der "normalen" openWB weiß ich es Dank der Fotos vom Inneren die man an anderer Stelle findet und ich kann nachvollziehen, wie die openWB vom Prinzip (welche Komponenten verbaut sind, für was sie da sind und wie sie interagieren) funktioniert. Bei der openWB pro kann ich das leider nicht.

[openWB]

Oder ist es ein Modul, welches die komplette Kommunikation mit dem EV übernimmt, so dass die openWB Software dann nicht mit dem Fahrzeug kommuniziert, sondern mit diesem Modul?

Exakt. Die openWB Pro spuckt über die API für die openWB heraus: "Fahrzeug XY"

im letzteren Fall kann man hoffen das der Hersteller des Moduls dann ein Firmware-Update bereitstellt.

Da täuscht du dich. Wir haben alles "in der Hand". Sprich nur ein Software Update.

Bei der openWB pro kann ich das leider nicht.

Die Möglichkeit mit dem Fahrzeug per HLC zu kommunizieren, was im Umkehrschluss weitere Features in der Zukunft bringt.
Das steht halt alles noch am Anfang, ist aber die Zukunft.

[stefan_o]

Da täuscht du dich. Wir haben alles "in der Hand". Sprich nur ein Software Update.

Es handelt sich also um ein Modul von oder für openWB, auf welchem openWB-eigene Software läuft, die anders als die "normale" openWB-Software nicht open-source ist? (oder bin ich zu doof den source code finden?)
Das wäre insofern besser, als meine Annahme, dass man nicht von einem Dritthersteller abhängig ist, aber sollte openWB mal eingestellt werden kann keiner den Code forken und weiterentwickeln. Und natürlich ein bisschen die Sorge, das mehr und mehr Funktionalität in den closed-source Teil wandert und der quelloffene Teil am Ende verkümmert.
Bei der "normalen" openWB mache ich mir da keine Sorgen, weil praktisch alles handelsübliche Komponenten sind und die Software open-source.

Die Möglichkeit mit dem Fahrzeug per HLC zu kommunizieren, was im Umkehrschluss weitere Features in der Zukunft bringt.
Das steht halt alles noch am Anfang, ist aber die Zukunft.

Ich meinte nicht (zukünftige) Funktionen, sondern die konkrete Hardware/Software im Moment.

Ich hab ein bisschen das Gefühl im Nebel zu stochern für ein paar Antworten zur Funktionsweise der openWB pro. Ich habe keine Ahnung ob es so ist, aber so ähnlich stelle ich es mir jetzt vor, es wäre schön so einen Text irgendwo zu finden, der hätte 95% meiner Fragen beantwortet:

Die openWB Pro verfügt über einen eigenen, speziell entwickelten Ladecontroller, welcher die Kommunikation mit dem EV nach ISO 15118 übernimmt, die Schütze schaltet und über ModBus den MID-Zähler ausliest. Die Software/Firmware des Ladecontrollers wurde von openWB entwickelt, steht jedoch nicht als open-source zur Verfügung. Der Ladecontroller verfügt über eine Ethernet-Schnittstelle, über die mit der quelloffenen openWB-Software kommuniziert werden kann. Es ist daher nicht zwingend ein Raspberry Pi für die openWB pro erforderlich, für bestimmte Funktionen wie PV-geführtes Laden jedoch an anderer Stelle (andere nicht-pro openWB-Wallbox oder als Standalone).

Ich hoffe natürlich ich liege falsch und ich war wirklich nur zu doof den Code zu finden