KESO: Konstruktiver Speicherschutz für Eingebettete Systeme
Language
Document Type
Issue Date
Issue Year
Authors
Editor
Abstract
Embedded systems are often produced in great numbers, and the cost of every item is a deciding factor for the required profit to be achieved. Hence the preferred microcontrollers in this area are small and cost saving with a word width of 8 or 16 bit and a working memory of just a few kilobytes. Further possibilities for reducing cost, apart from solely hardware, are required and used. One good example is the embedded systems in cars. With AUTOSAR serveral manufacturers cooperate to promote the reusability of software in cars --- thereby at the same time reducing cost. By detaching the software from the hardware components, it should be possible to place the software as freely as possible. Hence it will be possible to place the software sensibly according to its functionality and its local conditions. For example, the control logic for the measurement of the tyre pressure can fulfill its task together with the control logic for the indicator on one control unit. Merging software components of different manufacturers in one microcontroller, however, leads to new challenges for the system software. Microcontrollers usually lack the ability to protect the working memory from uncontrolled or unintended memory access. Programming errors of one software component might hence endanger the stability of the entire software. The objective of this work was therefore to develop a memory protection that fulfills the specific requirements of this application area. following requirements were particularly considered: low resource consumption, high hardware independence, real-time capability. The approach was through a purely software-based solution. This is implementable on different microcontrollers and does not require any additional support by the hardware. The basis for this forms an OSEK/VDX based operating system, as comparable systems are already established in the car industry. In order meet the objectives of this project, a Java runtime environment was delevoped that enabled the concurrent running of several applications on an OSEK/VDX system while being isolated. The applications are divided onto several protected domains. Every domain represents an independent JVM, with an independent memory management and individual global variables. The security of the Java bytecode ensures that the application cannot access the memory on an invalid memory location. The additional division into domains prohibits an unintentional change of global conditions in another application and enables the running of several instances of one application software on the same microcontroller. To enable communication between the domains, KESO implements portals. The portals in KESO are comparable to Java RMI. The portal invocation follows a lean implementation and is therefore only marginally more expensive than a regular method invocation. The architectur can be expanded to several microcontrollers of fixed composition. The domains are assigned to a node in the composition. The domains can be transferred by reconfiguration. Communication between domains is still via portals. As each domain represents its own JVM, the application software can be translated with every translator that generate standard Java bytecode. The Java bytecode makes it possible for the application to be delivered independent of hardware. The actual sources do not have to be disclosed. The translator which has been created for this project produces a C- programme and a OSEK/VDX compatible configuration. KESO therefore fits into the translation process of OSEK/VDX via the C-programming language. During the translation, the bytecode is being analysed, and the data structure matched to the requirements of the application. In addition to that, the application software is being optimized. Due to the global sight and type safety of Java, this is easier than it would be in the c-compiler. The runtime environment was used in various architectures. A Unix with a Pentium-compatible processor served as a base during the development phase and for comparative measurements; for the prototypes a Tricore TC1796 and an AVR Atmega8535 were used. Hence a wide choice of possible architectures were covered.
Abstract
Eingebettete Systeme werden oft in großen Stückzahlen produziert, und die Kosten für jedes gefertigte Stück sind ein entscheidender Faktor für den zu erzielenden wirtschaftlichen Gewinn. Es werden daher bevorzugt kleine und kostengünstige Mikrocontroller mit einer Wortbreite von 8 oder 16 Bit und nur wenigen Kilobyte an Arbeitsspeicher in diesem Bereich eingesetzt. Neben den reinen Hardwarekosten werden jedoch auch weitere Möglichkeiten zur Kostenreduktion gesucht und genutzt. Ein gutes Beispiel hierfür sind die eingebetteten Systeme im Automobil. Durch die AUTOSAR-Initiative wird hier die Wiederverwendbarkeit von Software im Automobil gefördert und damit auch das Ziel einer Kostenreduktion verfolgte. Durch das Loslösen der Software von ihren Hardwarekomponenten soll es in Zukunft möglich werden, die Software möglichst frei zu platzieren. So wird es möglich, die Software abhängig von ihrer Funktionalität und den örtlichen Gegebenheiten sinnvoll zu platzieren. Zum Beispiel kann die Steuerlogik für die Messung des Reifendrucks auf einem Steuergrät zusammen mit der Steuerlogik für den Blinker ihre Aufgabe erfüllen. Das Zusammenführen von Softwarekomponenten unterschiedlicher Hersteller auf einem Mikrocontroller führt jedoch auch zu neuen Herausforderungen an die Systemsoftware. So fehlt auf den Mikrocontrollern in der Regel die Möglichkeit, den Arbeitsspeicher vor fehlerhaften und ungewollten Speicherzugriffen zu schützen. Programmierfehler in einer Softwarekomponente gefährden so die Stabilität der gesamten auf einem Controller laufenden Software. Das Ziel dieser Arbeit war es daher, einen Speicherschutz zu entwickeln, welcher die besonderen Anforderungen des Anwendungsgebietes berücksichtigt. Folgende Anforderungen wurden besonders berücksichtigt: Geringer Ressourcenbedarf, Hardwareunabhängigkeit, Echtzeitfähigkeit. Als Ansatz wurde eine rein softwarebasierte Lösung verfolgt, da diese auf den unterschiedlichen Mikrocontrollern umsetzbar ist und keine zusätzliche Unterstützung durch die Hardware benötigt. Als Grundlage diente dabei ein OSEK/VDX-basiertes Betriebssystem, da vergleichbare Systeme im Automobilbereich bereits etabliert sind. Um die Ziele der Arbeit zu erreichen wurde eine Java Laufzeitumgebung entwickelt, die es ermöglicht, mehrere Anwendung voneinander isoliert auf einem OSEK/VDX-System laufen zu lassen. Die Anwendungen werden hierzu auf einzelne Schutzräume aufgeteilt, die als Domänen bezeichnet werden. Jede Domäne stellt aus der Sicht der Anwendung eine eigenständige JVM dar, mit einer eigenständigen Speicherverwaltung und eigenen globalen Variablen. Die Typsicherheit vom Java Bytecode stellt sicher, dass die Anwendung keinen Speicherzugriff auf eine ungültige Speicherstelle durchführen kann. Die zusätzliche Unterteilung in Domänen verhindert eine unbeabsichtigte Veränderung von globalen Zuständen in einer anderen Anwendung und ermöglicht es, mehrere Instanzen von einer Anwendungssoftware auf dem gleichen Mikrocontroller ablaufen zu lassen. Zur Kommunikation zwischen den Domänen implementiert KESO Portale. Die Protale in KESO sind zu RMI Aufrufen vergleichbar. Der lokale Aufruf wurde bei KESO besonders schlanker umgesetzt, so dass er nur geringfühgig teuerer ausfällt als ein regulärer Methodenaufruf. Die Architektur kann auf mehrere Mikrocontroller die einen festen zusammenhängenden Verbund bilden ausgeweitet werden. Die Domänen werden dabei einem Knoten im Verbunden zu gewiesen. Durch Umkonfiguration können die Domänen verlagert werden. Die Kommunikation zwischen den Domänen erfolgt dabei weiterhin über die Protale. Die Anendungssoftware kann mit jedem Übersetzer, der standardkonformen Java Bytecode erzeugt, übersetzt werden. Der Java-Bytecode ermöglicht es, dass die Anwendung in einer von der Hardware unabhängigen Form und ohne die eigentlichen Quellen offen zu legen weitergeben werden können. Der im Rahmen der Arbeit entwickelte Übersetzer erzeugt aus dem Bytecode der Anwendung und einer Konfiguration ein C-Programm und eine passende Konfiguration für OSEK/VDX. Durch den Umweg über die C-Programmiersprache passt sich in den Übersetzungsprozess von OSEK/VDX ein. Der Bytecode wird während der Übersetzung analysiert, und die Datenstrukturen werden auf die Anforderungen der Anwendung abgestimmt. Zusätzlich erfolgen Optimierungen der Anwendungssoftware, die aufgrund der globalen Sicht und der Typsicherheit von Java einfacher möglich sind als dies im C-Übersetzer der Fall wäre. Die Laufzeitumgebung wurde in sehr unterschiedlichen Architekturen eingesetzt. In der Entwicklungsphase und für Vergleichsmessungen diente ein Unix mit einem Pentium-kompatiblen Prozessor als Grundlage. Für die Prototypen wurde Tricore TC1796 und ein AVR Atmega8535 verwendet. Damit wurde ein sehr weiter Bereich an möglichen Architekturen abgedeckt.