Eine vollständige Knotenabschaltung ist nicht der einzige Weg zur Energieeinsparung im Netzwerk. Die meisten Mikrocontroller enthalten bereits heute Stromsparmodi, in denen Teile des Mikrocontrollers in einen Low-Power-Modus versetzt werden können, während andere Funktionsblöcke aktiv bleiben. Heute wird das nur selten genutzt, da Energiesparen bisher in der Systemdefinition nur eine untergeordnete Rolle gespielt hat. Manchmal werden zwar Peripherie-Funktionen eines Steuergerätes abgeschaltet, wenn sie nicht benutzt werden; der Mikrocontroller bleibt aber in der Regel unberührt und verschwendet Energie bei der Abarbeitung von Warteschleifen.
ECU Degradation und Pretended Networking sind zwei neue AUTOSAR-Konzepte, mit denen Funktionen im Mikrocontroller bei laufendem Betrieb des Steuergerätes abgeschaltet werden können, das Betriebssystem des Steuergeräts aber weiterläuft und die Kommunikationsschnittstellen zumindest teilweise aktiv bleiben. ECU Degradation erlaubt erstmalig die Nutzung von Energiespar-Modi in AUTOSAR; die Möglichkeit, integrierte Module eines Mikrocontrollers abzuschalten, wird zu einer Standardfunktion. Darüber hinaus hat der Software-Entwickler nun die Möglichkeit, Funktionen energiesparend zu implementieren, indem der Takt eines Mikrocontroller-Moduls reduziert wird. Das ist ein erster, wichtiger Schritt in Richtung Energieeinsparung.
In Zukunft wird ein Steuergerät nicht nur für eine Applikation zuständig sein. Um unerwünschte Interaktionen zwischen Applikationen zu vermeiden, müssen Mikrocontroller-Module gegen den unerlaubten Zugriff einzelner Rechenkerne geschützt werden können. ECU Degradation lässt auch zu, dass ein einzelner Kern in den Halt- bzw. Idle-Modus versetzt wird. Außerdem beinhaltet dieses Konzept Switching Runnables; das sind kleine, unabhängige Software-Komponenten, die vor einem Wechsel in einen Energiesparzustand deaktiviert werden können. Dabei muss allerdings jederzeit sichergestellt sein, dass der störungsfreie Betrieb des AUTOSAR-Stacks in den Energiesparzuständen gewährleistet ist.
Eine weitere Möglichkeit, Energie zu sparen, wurde dagegen nach einigen Diskussionen im AUTOSAR-Gremium verworfen. Mit einer zentralen Frequenzskalierung könnte jedes Steuergerät theoretisch zwischen zwei verschiedenen Taktfrequenzen (Betrieb mit voller Rechenleistung und Energiesparmodus) hin- und herschalten (Bild 2). Solange kein zusätzlicher (unveränderter) Takt für die Kommunikation existiert, müssten dann die Übertragungsraten der Kommunikationsschnittstellen entsprechend umgeschaltet werden. Die Bedenken waren zu groß, dass eine solche Umschaltung sowohl die Kommunikation als auch die Applikation im Mikrocontroller ungewollt beeinflussen könnte, obwohl moderne Mikrocontroller-Familien wie z.B. Infineons Aurix eine zentrale Frequenzskalierung bei stabilen Übertragungsraten unterstützen. ECU Degradation unterstützt lediglich die lokale Absenkung der Taktfrequenz auf Modulebene, soweit die Kommunikationsschnittstellen nicht beeinflusst werden.
Pretended Networking nutzt die Energiesparmechanismen von ECU Degradation und erweitert diese um die Definition des Kommunikationsverhaltens und der Wake-up-Prozeduren. Dabei sind zwei verschiedene Wege möglich. Das erste, einfachere Konzept nutzt die Mechanismen von ECU Degradation zur Energieeinsparung, Pretended Networking definiert die Kommunikationsebene. Das zweite Konzept basiert auf unterschiedlichen Spannungsversorgungsbereichen (Power Domains) im Mikrocontroller. Eine der Domänen beinhaltet dabei die Kommunikationsmodule, während eine andere den Rechenkern sowie weitere Module versorgt. Bei beiden Konzepten läuft die Kommunikation in den Energiesparmodi ohne Einschränkungen weiter, allerdings mit einem reduzierten Kommunikationskatalog und vorab definierten Weckquellen. Dies können sowohl Hardware- als auch Software-Ereignisse sein.
Weckereignisse sind dabei nicht nur vordefinierte Identifier von CAN-Botschaften. Es kann z.B. auch auf spezielle Bits im Datenbereich von CAN-Botschaften oder aber auf eine fehlerhafte Datenlänge der CAN-Botschaft geweckt werden. Bei Verwendung des ersten, einfacheren Konzepts ist es dazu notwendig, dass der Rechenkern den Halt-Modus kurz verlässt, um das Weckereignis zu analysieren. Dabei muss aber nicht notwendigerweise der komplette Software-Stack gestartet werden, wenn ein Weckereignis als für das eigene Steuergerät nicht zutreffend identifiziert wurde. Der Übergang vom Halt- in den Run-Modus eines Rechenkerns benötigt nur sehr wenige Taktzyklen; somit ist ein sehr schnelles Aufwecken möglich. Beim Konzept mit verschiedenen Spannungsversorgungsbereichen ist dagegen der Rechenkern normalerweise abgeschaltet, demzufolge müssen die notwendigen Operationen in einer zusätzlichen Hardware implementiert werden. In diesem Fall ist die Aufweckzeit bei einem regulären Aufweck-Ereignis länger, wenn der komplette Software-Stack neu geladen und der Mikrocontroller neu initialisiert werden muss.
Pretended Networking setzt voraus, dass ein CAN-Modul (oder auch künftig ein FlexRay-Modul) die ganze Zeit läuft. Deshalb werden CAN-Botschaften zwischengespeichert und können nach dem Aufwecken der Software zur Verfügung gestellt werden.
Um eine Integration in bestehende Netzwerke zu ermöglichen, muss das Netzwerk-Management auch von Steuergeräten bedient werden, die sich im Pretended-Networking-Modus befinden. Ausbleibende Botschaften in einem bestehenden Netzwerk würden sonst zu Netzwerkfehlern führen. Deshalb muss ein Steuergerät im Pretended-Networking-Modus in der Lage sein, Botschaften zyklisch unter Verwendung eines internen oder externen Timers zu versenden. Am effizientesten wäre es, wenn dieses zyklische Senden ohne Nutzung des Rechenkerns erfolgen würde. Dies ist allerdings im Pretended-Networking-Konzept nur optional vorgesehen, um auch Mikrocontroller einsetzen zu können, die das nicht unterstützen.
Infineons Aurix-Mikrocontroller-Familie basiert auf dem ersten der oben genannten Konzepte ohne zusätzliche Spannungsversorgungsbereiche. Die Spezifikation von Pretended Networking hat die Definition des Aurix-CAN-Moduls direkt beeinflusst. Dieses Modul MultiCAN+ ist eine Weiterentwicklung des erfolgreichen MultiCAN-Moduls, das bereits in der zuletzt implementierten Version zwei verschiedene Taktdomänen unterstützt hat (Bild 3). MultiCAN+ beinhaltet darüber hinaus für jedes einzelne Message Object separat konfigurierbare Interrupts sowie die Möglichkeit, Message Objects zu überschreiben. Außerdem wird nun das „Network Management Time-out“ von Pretended Networking unterstützt. Für jeden CAN-Knoten ist ein Time-out verfügbar, was mehrfache Message Objects pro Knoten erlaubt. Wird keines der vorprogrammierten Objekte während einer konfigurierbaren Zeit empfangen, wird ein Time-out erzeugt und damit ein Interrupt generiert. Ein ähnlicher Mechanismus wird zum Senden von Netzwerk-Management-Botschaften verwendet. Hierzu werden drei programmierbare Timer verwendet. Ein Steuergerät ist damit in der Lage, drei verschiedene Botschaften ohne jede Interaktion mit der Software zyklisch zu unterschiedlichen Zeiten zu versenden; der Rechenkern kann dabei im Halt- bzw. Idle-Modus verharren.