Abhärtung von Programmen in fehleranfälligen WSNs

Einleitung

Sensornetze sind sehr flexibel einsetzbare Rechnernetze aus Sensorknoten. Diese lassen sich sehr vielseitig einsetzen z. B. als Temperatur-, Luftfeuchtigkeit- oder auch Schadstoffsensor. Ein Problem dabei ist, dass diese Sensorknoten, sobald die eingebaute Batterie leer ist, keine weiteren Daten liefern können und gewartet werden müssen. Um diese Wartungszyklen zu vergrößern, kann entweder die Laufzeit der Batterie verlängert oder der Energieverbrauch der Sensorknoten verringert werden.

Auf modernen Mikrocontrollern, die in diesen Sensorknoten eingesetzt werden, gibt es jedoch nur noch wenige Möglichkeiten, diese Energieeffizienz weiter zu steigern. Eine Mög- lichkeit dazu ist das Undervolting, dabei wird der Mikrocontroller mit einer Spannung unterhalb der vom Hersteller spezifizierten Höhe versorgt und dadurch die Lebenszeit des Sensorknotens um bis zu 42% verlängert. Dadurch können jedoch Fehler bei der Ausführung von Aufgaben auf dem Mikrocontroller entstehen, die die ausgegebenen und berechneten Daten verfälschen.

Das Ganze könnte Anwendung finden in Sensorknoten, die beständig Daten senden müssen, z. B. ein Temperatursensor, der alle 10 Sekunden einen Wert sendet um Waldbrände zu erkennen. Bei diesen kann ein einzelner falsch positiver Wert ignoriert werden, ein falsch negativer Wert sollte jedoch nie ausgegeben sein. Momentan kann aber nicht sichergestellt werden, dass im kritischen Fall der Mikrocontroller nur zuverlässig arbeitet. Es muss also eine Art abgesicherter Modus eingeführt werden, der aufgerufen wird, sobald hier z. B. eine bestimmte Temperatur gemessen wird, in dem die Funktionen keine Fehler hervorbringen, die durch Undervolting verursacht werden könnten.

Um dies zu erreichen, wird in dieser Arbeit versucht solch sicherheitskritischen Funktionen auf eine sichere, aber schwächere, Microcontroller Unit (MCU) auszulagern, während eine Haupt-MCU, die mit Undervolting betrieben wird die normalen Funktionen ausführt. Um die Sicherheit der Daten auch auf der fehlerbehafteten MCU zu gewährleisten werden die internen Variablen durch selbst entwickelte Reliable Types vor Fehlern abgesichert.

Aufgabenstellung

ür die generelle Funktion des Undervolting, dient der ATtiny84 in dieser Arbeit als sichere Instanz und soll neben den periodischen Selbsttests nur bei Bedarf geweckt werden. Nach Außen soll der ATtiny84 als I2C EEPROM erscheinen. Er kann also einfach beschrieben und ausgelesen werden, indem man eine Adresse angibt. Intern besitzt der ATtiny84 zwei Puffer, aus denen die empfangenen Daten ausgelesen bzw. in die die zu sendenden Daten hineingeschrieben werden.

Um die Datenerhaltung auf dem potenziell fehlerbehafteten ATmega1284p zu garantieren, werden sogenannte Reliable Types eingeführt. Diese sollen zuerst für verschiedene kleine Payloadgrößen (1, 2, 4, 8 Bytes) implementiert werden. Anschließend soll das Konzept erweitert und generisch für beliebige Größen implementiert werden. Die Sicherheit dieser Typen wird dadurch hergestellt, dass sämtliche Daten in einem Container mit einer Prüfsumme versehen werden (Abb. 1 links). Der Zugriff auf die Daten kann nur über geeignete Methoden nicht aber direkt erfolgen, dadurch wird sichergestellt, dass die Daten vor jeglicher Nutzung mit der Prüfsumme verglichen und nur eine korrekte Variable herausgegeben wird . Über den I2C Bus, der zur Kommunikation zwischen den MCUs benutzt wird, werden jedoch nur die ungesicherten Variablen gesendet, um einerseits Zeit zu sparen und da andererseits der I2C Bus als sichere Übertragung angesehen wird. Beim Erstellen der Container kann zusätzlich eine Notfall-Funktion mitgegeben werden, die aufgerufen wird, sollte ein Fehler in der Variable gefunden werden. Dies kann z. B. ein Abbruch des Funktionsaufrufes oder das Setzen der Variable auf einen Standardwert sein.

Allgemein sollen die Reliable Types Funktionen zum Allozieren des Speichers, Updaten der Variablen, Kopieren der Variablen eines Reliable Types in einen anderen, Vergleichen zweier Reliable Types und zum Ausgeben der Variable besitzen. Die Kontrolle, ob die Variable mit der Prüfsumme übereinstimmt, wird bei der Ausgabe, dem Kopieren und dem Vergleich zweier Reliable Types vorgenommen.

Sobald ein Funktionsaufruf eintritt wird zuerst daraufhin geprüft, ob der Aufruf zuverlässig ausgeführt werden soll, also auf dem ATtiny84. Falls dem so ist, werden alle nötigen Daten aus dem Reliable Type zusammen mit dem Funktionsaufruf über den I 2 C Bus übertragen. In einer Erweiterung sollen für die Ausführung eventuell benötigte statische und globale Variablen mit an die sichere MCU versendet werden. Der ATtiny84 führt dann die Funktion mit den entsprechenden Daten aus und platziert das Ergebnis in seinem Ausgangspuffer. Von dort liest der ATmega1284p die Daten ein, verpackt diese wieder in einen Reliable Type und gibt die Ausgabe gegebenenfalls nach außen hin weiter. Die Daten werden ansonsten in den Reliable Types aufbewahrt und bis zu einer etwaigen Nachfrage gelagert.

Intern bekommt jede Funktion eine individuelle Kennung, mit der sie auf dem ATtiny84 vom ATmega1284p aufgerufen werden kann. Die gesendeten Pakete enthalten dann dementsprechend diese Kennung mit den nötigen Daten und zusätzlich eine fortlaufende Nummer, mit der sich mehrere gleiche Funktionsaufrufe voneinander unterscheiden lassen. Die Funktionsaufrufe werden im Eingangspuffer des ATtiny84 in Form einer Queue abgelegt, wobei ein Element die Funktionskennung mit ID und Variablen umfasst. Nach der Ausführung wird ein Paket mit Funktionskennung, ID und gegebenenfalls Rückgabewert in den Ausgangspuffer abgelegt (Abbildung s.o.). Durch Setzen eines Pins kann der ATtiny84 dem ATmega1284p mitteilen, dass Daten bereit liegen, dadurch muss der ATmega1284p nicht andauernd die I2C Leitung belegen und nachfragen, ob der Puffer belegt ist.

Links

• INGA
• Undervolting in WSNs
• Hinweise zur Durchführung von studentischen Arbeiten am IBR