54900.jpg

Die Begriffe Partial- und Pretended-Networking stammen aus der Autosar-Welt und sind Konzepte des Efficient Energy Management (EEM). Während die weitgehend zentralisiert arbeitende Lösung Partial-Networking durch ein übergeordnetes Netzwerk-Management (NM) einzelne Netzknoten per CAN-Message abschaltet, basiert Pretended-Networking auf lokalen Entscheidungen und lokaler Intelligenz des einzelnen Netzknotens.

Partial-Networking

Auf dem 15. Fachkongress „Fortschritte in der Automobilelektronik“ im Juni 2011 kündigten die E/E-Leiter es an: Partial-Networking, das CAN-Teilnetzwerk, wird übergreifend eingeführt und der dafür einzusetzende CAN-Transceiver wird normiert. Deshalb benötigt Partial-Networking nach bisherigem Wissensstand einen speziellen CAN-Transceiver nach ISO 11898 6, der den Rest einer Embedded Control Unit (ECU) per Kommando abschaltet, nachdem er vorher auf ein bestimmtes Wake-Up-Pattern (WUP) programmiert worden ist. Auf diese Weise verbleibt vom Energieverbrauch der ECU lediglich der Transceiver selbst. Da der Netzknoten nun aber nicht mehr auf andere Nachrichten reagiert, muss das NM darüber Bescheid wissen. So wird schnell klar, dass die Einführung von Partial-Networking ein Upgrade des NM aller Netzknoten zur Folge hat. Alle beteiligten ECUs müssen neue Software bekommen – ein nicht unerhebliches Risiko.

Bild 1: Stromaufnahme des RH850/F1L beim Empfang für Pretended-Networking Level 2.

Bild 1: Stromaufnahme des RH850/F1L beim Empfang für Pretended-Networking Level 2.Renesas

Pretended-Networking

Pretended-Networking hingegen arbeitet ausschließlich lokal. Jeder Netzknoten (de facto die ECU) entscheidet für sich, ob und welcher Power-Save-Mode benutzt wird oder nicht – in Abhängigkeit von den aktuellen Aufgaben. Dabei gilt natürlich: egal welcher Power-Save-Mode benutzt wird, muss nach außen (zum Netzwerk) hin alles so aussehen, als wäre der Netzknoten ganz normal aktiv und funktionsbereit. Der Nachteil dieses Konzepts besteht darin, dass der Energieverbrauch niemals so weit reduziert werden kann wie mit Partial Networking. Dem gegenüber gibt es aber auch etliche Vorteile: Pretended-Networking ist skalierbar – von der reinen Software-Implementation („Level 1″) mit geringer Energieverbrauchsreduktion bis hin zur speziellen Hardware-Lösung mit Hilfe des Intelligent Communications Controllers (ICOM) des „Level 2″. Des Weiteren kann Pretended-Networking sukzessive eingeführt werden, wodurch das Risiko überschaubarer bleibt.

Energiebilanzen

Abgesehen von Risiken und Machbarkeitsabschätzungen gibt es rein technische Kriterien, welches Konzept das Bessere für die jeweilige Anwendung ist. Wie Bild 1 zeigt, ist Partial-Networking effektiver, wenn lange Stand-By-Phasen auftreten können und eine schnelle Reaktion beim Aufwachen nicht notwendig ist. Die Werte beziehen sich auf die gemeinsame Stromaufnahme eines aktuellen Mikroprozessors und eines daran angeschlossenen CAN-Transceivers.

Bei Partial-Networking wird eine niedrigere Stromaufnahme im Standby-Mode der ECU erreicht, aber dafür dauert es länger, bis die ECU aus diesem Standby-Mode wieder aufwacht und ihre Aufgaben wieder aufnehmen kann. Pretended-Networking reagiert schneller auf Betriebszustandswechsel, kann aber die Stromaufnahme nicht so weit reduzieren. Da es auch im Standby-Modus noch Kommunikation aufrechterhalten muss, entstehen periodische Phasen höherer Stromaufnahme, die das Gesamtergebnis verschlechtern.

Entscheidend für die Auswahl des geeigneten Konzepts ist aber in jedem Fall der Mittelwert des Energieverbrauchs der ECU während des normalen oder typischen Betriebs, oder beim Prüfzyklus des NEDC (New European Driving Cycle).

Bild 2: Mikrocontroller RH850/F1L bei Pretended-Networking Level 2.

Bild 2: Mikrocontroller RH850/F1L bei Pretended-Networking Level 2.Renesas

Software-Emulation beider Konzepte

Partial- und Pretended-Networking gehen jeweils von entsprechenden Hardwarevoraussetzungen aus:

•          Partial Networking:                           ISO 11898-6 CAN-Transceiver

•          Pretended-Networking Level 2:        ICOM (Intelligenter CAN Controller, CPU-unabhängig)

Diese Hardware zu emulieren erfordert Leistung von der CPU, die wiederum Energie erfordert, und somit die Effektivität reduziert. Es sei denn, dass der Mikrocontroller konzeptionell dafür optimiert worden ist. Renesas hat bei der neuen Produktfamilie RH850/F1L diesen Aspekt berücksichtigt und für den CAN-Controller eine neuartige Systemintegration geschaffen. Dadurch wird es möglich, den CAN-Controller ohne CPU weiterlaufen zu lassen; sogar die Abschaltung der PLL ist in diesem Zustand möglich. Gleichzeitig hat der CAN-Controller ein neues Filtersystem bekommen sowie eine eigene separate Taktversorgung über den Quarzoszillator. Das neue Filtersystem ermöglicht eine 100%-Filterung der eingehenden Nachrichten bei bis zu 256 Emfangsregeln.

Pretended-Networking Level 2 – Emuliert in Software

Der ICOM basiert auf einem normalen CAN-Controller und nutzt zusätzliche Software. Die Emulation umfasst sowohl die Auswertung von Kriterien zum Verlassen des Standby-Modes für sechs gefilterte Nachrichten als auch die periodische Aussendung der NM-Alive-Nachricht (damit das NM keine Fehler meldet).

Es wird des Weiteren davon ausgegangen, dass sowohl die gefilterten Nachrichten mit den Aufweck-Kriterien als auch die NM-Nachricht alle 100 ms auf dem Bus erscheinen. Ansonsten kann der CAN-Bus eine beliebig hohe Buslast aufweisen, da das Filter zu 100% filtert.

Damit die Energieverbrauchswerte vergleichbar sind, setzen wir voraus, dass die CPU – abgesehen von der Emulation – keine weiteren Aufgaben hat. Das Element ist somit im tiefst möglichen Stand-By. Die Gesamtfunktion dieses Emulationsbeispiels ergibt sich aus Bild 2.

Die darin erwähnten Werte wurden für den Mikrocontroller und einen marktüblichen aktiven Standard-CAN-Transceiver gemessen. Das Ergebnis kann sich sehen lassen: Vergleicht man diesen Standby-Mode mit der normalen Aktivität des Mikrocontrollers, zeigt sich ein Potential von 89% Energieverbrauchsreduktion.

Bild 3: Stromaufnahmen bei Partial- und Pretended-Networking im Vergleich (Mikrocontroller und Transceiver).

Bild 3: Stromaufnahmen bei Partial- und Pretended-Networking im Vergleich (Mikrocontroller und Transceiver).Renesas

Partial-Networking – Emulation mit Standard-CAN-Transceiver

Im Vergleich mit Pretended-Networking Level 2 ergibt sich für die Emulation von Partial-Networking lediglich der Unterschied, dass nun nur noch eine einzige Nachricht das Filter passieren kann (die Nachricht des WUP), und keine NM-Nachrichten mehr versandt werden. De facto verharrt die Emulation also im Wartezustand, und die CPU bleibt gestoppt.

Das Messergebnis zeigt eine Senkung des Energieverbrauchs um 90%, also ähnlich wie bei Pretended-Networking Level 2. Der Stromverbrauch des Standard-CAN-Transceivers lässt sich nämlich nicht weiter reduzieren, und der Energieverbrauch der CPU für die Bearbeitung der Nachrichten von Pretended-Networking Level 2 ist recht gering.

Verwendete CAN-Transceiver bei der Emulation

Renesas empfiehlt, einen Standard-CAN-Transceiver im „Receive-Only“-Mode zu betreiben – und zwar mit der Ausnahme, dass zur Zeit des Sendens der NM-Nachricht bei Pretended-Networking Level 2 der normale Betriebsmodus kurzfristig aktiviert wird. Ein neuer CAN-Transceiver nach ISO 11898-6 kann im speziellen Partial-Networking-Standby-Modus seinen Energieverbrauch nochmals um den Faktor 10 reduzieren. Hier sind der Emulation somit Grenzen gesetzt. Gleichzeitig zeigt sich hier Verbesserungspotential für Standard-CAN-Transceiver.

Pretended-Networking

Die Emulation von Pretended-Networking Level 2 erreicht sehr gute Werte bei der Energieeffizienz – und zwar bei gleichzeitig schneller Reaktionszeit. Damit tritt sie in Konkurrenz zum klassischen Ansatz mit Partial-Networking und CAN-Transceiver-Hardware gemäß ISO 11898-6. Die Software-Emulation von Pretended-Networking Level 2 weist unter anderem die folgenden Vorteile auf: Das Risiko sinkt, die Flexibilität steigt und die Kosten verteilen sich zeitlich.

Ein Blick auf die Messung

Bild 3 zeigt die Stromaufnahme des Mikrocontrollers allein: während einer aktiven Empfangs- und Datenverarbeitungsphase bei Pretended-Networking Level 2. Die meiste Zeit verbleibt der Mikrocontroller im Ruhezustand bei 1,5 mA Stromaufnahme. Nur während der kurzen Phase der Prüfung der Aufwachkriterien wird die CPU aktiv, wie es hier vergrößert dargestellt ist. Der Mittelwert (für 60 Nachrichten pro Sekunde – also Phasen dieser Art) liegt dann bei 1,58 mA.

Das Diagramm offenbart ein weiteres Detail des neuen Mikrocontrollers: Seine internen Spannungsregler sind auf die verschiedenen Betriebszustände optimiert. So kommt es, dass vor dem eigentlichen Start der CPU eine „VR Stabilization“ notwendig ist, und beim Wiedereintreten in den Standby-Mode (STOP) ebenfalls deutliche Stufen in der Stromaufnahme zu sehen sind. Diese spezielle Konditionierung der internen Spannungsregler (VR) trägt effektiv zu den geringen Energieverbrauchswerten bei.

Bild 4: Stromaufnahme von Mikroprozessor und Transceiver im Normalbetrieb.

Bild 4: Stromaufnahme von Mikroprozessor und Transceiver im Normalbetrieb.Renesas

Die Ergebnisse im Überblick

Eine Reduktion des Energieverbrauchs um zirka 90 % bei der Emulation von Pretended-Networking Level 2 ist ein guter Wert, der den Vergleich mit Partial-Networking und ISO-11898-6-Transceiver nicht zu scheuen braucht. Bild 4 zeigt eine Zusammenfassung. Der Mikroprozessor läuft mit 80 MHz bei eingeschalteter PLL, und der CAN-Transceiver ist permanent im Normalbetrieb. Die Stromaufnahme teilt sich wie folgt: 40 mA für den Prozessor, 25 mA für den Transceiver.

Beim Pretended-Networking Level 1 bewegt sich nicht viel. Der HALT-Mode des Prozessors reduziert die Stromaufnahme nur wenig, der CAN-Transceiver kann die meiste Zeit im Receive-Only-Mode betrieben werden. Dieser Betrieb erfordert keine Emulation,sondern er ist bereits de facto eine Software-Lösung, wie sie auch bald unter Autosar zur Verfügung stehen wird. Positiv ist, dass die Reaktion des Systems auf Wake-Up-Bedingungen sehr schnell erfolgt, so das nicht einmal die PLL reaktiviert werden muss.

Beim Pretended-Networking Level 2 (emuliert) ist die Reduktion des Stromverbrauchs groß, bei gleichzeitiger immer noch schneller Reaktionszeit des Systems. Das Datenblatt des RH850/F1L weist eine Startzeit von 112 µs für die PLL aus, die Reaktionszeit auf die CAN-Message liegt bei (hier gemessenen) 270 µs. Insgesamt sind es somit nur zirka 0,4 ms Reaktionszeit.

Keine spezielle Hardware notwendig?

Partial- und Pretended Networking (Level 2) setzen besondere Hardware voraus – so werden die Definitionen ausgelegt. Es geht aber auch anders: Neue Generationen von Microcontrollern machen es möglich.

Alles was man braucht, sind geeignete Low-Power Modi mit aktivierten Kommunikationsschnittstellen. Wenn die eingehende Kommunikation effektiv gefiltert werden kann, und gleichzeitig die Low-Power Modi sehr niedrige Stromverbrauchswerte aufweisen, ist die Emulation möglich und eine echte Alternative zu teureren und risikoreicheren Hardwarelösungen.

Bei gleicher Reaktionszeit wie Pretended-Networking Level 2 und ähnlichem Stromverbrauch ist Partial-Networking (emuliert) eine Alternative, die aufgrund der grundsätzlichen Auslegung des Gesamtnetzwerks für Partial-Networking in Erwägung gezogen werden kann.

Mit der Hardwarelösung nach ISO für das Partial-Networking fällt die Stromaufnahme um 98 bis 99 %. Dies kann durch die Emulationen nicht erreicht werden. Allerdings sind dafür auch Nachteile bei der Reaktionszeit des Systems in Kauf zu nehmen. Wird der Mikrocontroller komplett durch den Transceiver von der Stromversorgung getrennt, sind je nach Betriebssystem Anlaufzeiten von 10 bis 100 ms zu kalkulieren.

Fazit

Software-Lösungen lassen sich durch Upgrades nachbessern. Das Risiko gegenüber speziellen Hardware-Lösungen ist geringer. Des Weiteren ist eine umfassende Änderung des NM gegenüber Partial-Networking nicht nötig. Somit bleibt das Risiko immer auf die ECUs beschränkt, die entsprechend ausgerüstet werden.

Außerdem lässt sich die Emulation leicht an Randbedingungen anpassen. Es existiert immer ein Trade-Off zwischen Reaktionszeit und Energieeffizienz, so dass individuelles Justieren möglich ist.

Bei Pretended-Networking können die Entwickler jede einzelne ECU separat zur Steigerung ihrer Energieeffizienz in Angriff genommen werden, so dass keine Umstellung des Gesamtsystems im Fahrzeug erforderlich ist: Die Kosten verteilen sich zeitlich.

Roland Lieder

ist Principal Engineer für Networks & Prototyping der ABG bei Renesas

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Renesas Electronics Europe GmbH-1

Karl-Hammerschmidt-Str. 42
85609 Aschheim-Dornach
Germany