embedded power for your project embedded power for your project

| Home | Software | Services | ProductManager | Contact |

 Embedded Prozessor
   8-Bit Prozessoren
   16-Bit Prozessoren
   32-Bit Prozessoren
   64-Bit Prozessoren
   ARM
   DSPs
   FPGA
   Intel
   MIPS
   PowerPC
 Tool Information
   BDM/JTAG tool
   Emulator
   Hardware design
   Logikanalysator
   Eval Boards
   Simulator
   Compiler
   Real Time OS
   Software Tools
   Debugger
 Services
   Consulting
   Product Manager
   Verkauf
   Links
   Literatur

Automotive Embedded Engineering Information

Embedded system design für Automobilanwendungen - was ist so speziell daran?

Microkontroller haben seit den frühen 80er Jahren den Weg ins Auto gefunden - trotz vieler automobilspezifischen Problemzonen die mit fortschreitender Technologisierung nicht unbedingt weniger werden.
Zur Zeit der ersten Mondlandung - Sommer 1969 für diejenigen die damals nicht den Lifeübertragungen im ersten oder zweiten deutschen Fernsehen beigewohnt haben - gab es in Automobilen kaum Elektronik, schon gar keine Digitalelektronik. Wer sich noch dunkel an die ersten PCs erinnert - wahre IC-Friedhöfe im Vergleich zu heutigen Designs - kennt auch gleich die Gründe warum automotive embedded erst in den 90ern richtig populär wurde. Dabei gab es Mitte der 80er Jahre durchaus die eine oder andere elektronische Motorsteuerung mit ICs auf Stecksockeln und Platinen-Klapp-Mechanismus um die ICs vor dem Herausfallen zu sichern.
Neben den Vibrationen ist der Temperaturbereich ein wesentliches Killer-kriterium für den Auto-Einsatz, meist werden -40°C..+85°C gefordert, im Motorraum gerne auch bis +110°C. Dies galt bislang meist auch für die Fahrgastzelle, wird aber mit zunehmendem Einzug von Klimaanlage und Standheizung nebst mitgebrachter Consumer-Elektronik mehr und mehr für menschliche Temperaturbereiche verweichlicht, äh, angepasst.
Was geht der Elektronik-Hardware im Auto noch so richtig an die Nieren? ESD und EMV sind die ersten Stichwörter für gelernte Elektrotechniker. Für diese beiden Bedrohungen gibt es seit Jahren bewährte Schaltungstricks, meist schon in Interface-Bausteine integriert, denn automobile Elektronik soll ja mindestens 10 Jahre halten und jedes externe Bauteil verringert die Zuverlässigkeit. Eine sichere stabile Spannungsversorgung ist auch ein Thema, sollen die meisten Steuergeräte auch beim Anlassen und in Schubphasen funktionieren. Mit dem Einzug von elektrischen Hilfsmotoren, äh, hybriden Powertrain-Konzepten gibt es noch mehr Unruhe auf dem sogenannten 12 Volt Bordnetz, welches in der Realität 9 bis 16 Volt bedeutet, dies ist der Bereich in dem die meisten Autos voll funktionsfähig sein sollen. Der elektrische Super-GAU für einige Steuergeräte ist die Nähe zu den Airbags, allerdings sind die meisten Fahrzeuge nach Zünden der Airbags nicht mehr fahrbereit.
Welche Bedrohung gilt der Software? Ob von innen oder aussen - was immer passiert - meist ist ein Watchdog nicht weit und verhindert Schlimmstes durch einen Neustart des Steuergerätes. Im täglichen Fahrbetrieb macht sich dies selten durch mehr oder weniger zufällige Ausfälle von Komfortfunktionen bemerkbar, welche nach Anhalten und Zündung aus/ein wieder einwandfrei funktionieren als ob nichts gewesen wäre. Wenn der Fehler nicht wieder auftritt bleibt es der Erinnerung der Fahrzeugnutzer überlassen, denn die Fehlerspeicher der meisten Steuergeräte vergessen lapidare Fehler nach einer Weile automatisch wieder.
Für sicherheitsrelevante Steuergeräte - und angefangen bei den schon erwähnten Airbags gibt es inzwischen oft ein gutes Dutzend davon - sind weitergehende Maßnahmen notwendig um die einwandfreie Funktion zu gewährleisten: Zum Beispiel kontrolliert ein zweiter Micro den Hauptprozessor, kostengünstiger agiert ein redundanter Rechnerkern im selben Controller, manchmal reicht auch ein einfacher 8-Bitter um an strategischen Stellen die Kennwerte der ECU zu überprüfen. Die erste Alarmstufe für das Automobil sind die sogenannten Check-Control Meldungen die den Fahrer via Informationsdisplay über leichte Anomalien benachrichtigen. Wenn es schlimmer ist, folgt eine Meldung mit akustischem Signal und dann ist es nicht mehr weit bis zum "limp home" Modus, der zum Beispiel von der Abgasüberprüfung aktiviert werden kann. Meist wird eine Drehzahl- und Leistungsbegrenzung wirksam um größeren Schaden zu verhindern, aber trotzdem das Auto in sichere Gefilde - Parkplatz auf der Autobahn - oder gar nach Hause zu bewegen, daher der Name.
Software-Schaden kann von innen kommen: Aus Kostengründen werden in automotive Steuergeräten meist Microcontroller mit on-board memory - Speicher auf dem Chip - verwendet, um externe Bauelemente einzusparen und die Zuverlässigkeit zu erhöhen. Wenn dieser interne Speicher aus FLASH Speicherzellen besteht, um beispielsweise eine Nachprogrammierung des Autos auch ausserhalb der Fabrik zu ermöglichen, dann haben wir das Hauptproblem für langlebige Software gefunden: Flashspeicher kann Bits verlieren. Die meisten Hersteller garantieren eine Anzahl Schreib-Lese-Zyklen und sagen auch daß einmal programmiert das Flash über Jahrzehnte seine Information behalte, doch diese Vorhersagen beruhen auf thermischer Simulation, d.h. die Bausteine werden künstlich gealtert und danach untersucht. Kommt es bei immer kleineren Geometrien dann durch Fertigungsfehler, mangelnde Schichtdicke, Verunreinigungen, etc dazu, daß doch einmal geschwächte Flashzellen ausgeliefert werden dann sind die Konsequenzen für normale Software oft katastrophal. Da Flash-Bitfehler meist einzeln auftreten hilft schon die Berechnung einer Checksumme zur Erkennung solcher Fehler. Komfortabler ist die Implementierung von Error-Check-Codes welche die erwarteten Bitfehler dynamisch kompensieren können. Allerdings, jede Maßnahme zur Absicherung gegen Flash-Bitkipper zieht auch Kosten nach sich, sei es langsames Startverhalten, erhöhter Speicherbedarf oder höhere Prozessorauslastung und längere Nachlaufzeit.
Ein weiterer Kostenfaktor und damit mögliche Ursache für vermeidbage Fehler ist die Anzahl der Prozessorpins. Erste Opfer der Kostenoptimierung sind meist die Anschlüsse für JTAG-Debugger, so umständlich dann auch die Fehlersuche in Vorserienprodukten wird, bei Millionenstückzahlen über die Produktionsdauer lohnt sich die Einsparung auch halber Cents. In diesem Sinne ist es auch nicht verwunderlich weshalb wenn irgend möglich, Hardware durch Software ersetzt wird - Beispiel ist die Reifendrucküberwachung durch Auswertung der Rad-Dreh-Signale im Zusammenspiel mit der elektronischen Fahrzeugstabilisierung - jeder Hersteller hat da seine eigene Abkürzung für solche Features die mit wenig Hardware und viel Software oft ganze Seiten in Hochglanzprospekten füllen. Der Trend in der Oberklasse geht derzeit zur reichhaltigen Ausstattung mit Radar- und Videosensoren, die automatische Abstandsfunktion ist nur ein Vorgeschmack auf Dinge die noch kommen werden.
In unserer schnelllebigen Zeit wird auch automotive Software häufig ohne verfügbare Hardware entwickelt, basierend auf sich täglich ändernden Anforderungen und mit einem Team das "learning on the job" mit Beteiligung von engagierten aber meist unerfahrenen jungen Leuten in Billiglohnländern betreibt. Zum Glück steuert die Automobilindustrie gegen und hat eine Handvoll allgemein anerkannter Standards geschaffen mit denen dem beliebigen Unsinn wie ihn Assembler- oder C-Programmierung zulässt ein erster Riegel vorgeschoben wird:
1.) MISRA - DIE Codierregeln der Automobilindustrie. Wer heutzutage noch C-Code ohne ein OK vom Codechecker in die Produktion gibt, schießt sich über kurz oder lang ins Knie. Lint war in den 90ern der Klassiker für sicherheitskritische Anwendungen. Seit sich herumgesprochen hat das qualitativ besserer Code sich auch betriebswirtschaftlich rechnet, gibt es ein reichhaltiges Angebot kommerzieller Tools zur Überprüfung diverser Codierstandards für jeden Anspruch und Geldbeutel.
2.) OSEK (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug) - eine Initiative der ehemals allumfassenden Siemens AG - war ein wichtiger Schritt in Richtung geregelte Schnittstellen und damit mögliche Modularisierung und Entflechtung immer komplexerer Software insbesondere wenn Zulieferer und Autobauer gemeinsam Code für ein Steuergerät erstellen. Basierend darauf und mit Input aus weiteren Normierungsinitiativen ASAM, HIS, und nicht zuletzt MSR, ergab sich Anfang des 21sten Jahrhunderts eine neue Philosophie für automotive embedded software: AUTOSAR.
3.) AUTOSAR - die derzeit aktuelle Gemeinschaftsaktion der Automobilindustrie um die stetig wachsende Komplexität der automobilen Software in den Griff zu bekommen. Und in der Tat ist Autosar ein weiterer Schritt in die richtige Richtung, wenn es auch manchmal so aussieht als ob das Ziel aus den Augen verloren ist. Wie heisst es unter Wanderern? Der Weg ist das Ziel.
AUTOSAR hat mit Release 2 die Eignung für praktische Anwendung gezeigt, seit 2008 - Release 3.1 - ist es allgemein anwendbar und einige der angebotenen Software-Werkzeugkästen halten offenbar was sich die Anwender davon versprechen. Zwar ist durch den Einsatz standardisierter Module ein wenig die Luft aus der klassischen Programmierung heraus, dafür wachsen die Anforderungen für Integration und Konfiguration die nun früher als in traditionellen Softwareprojekten die Weichen für die einwandfreie Funktion des Endproduktes stellen. An Stelle von Programmierspezialisten treten System- und Integrationsingenieure, die meist auch Spezialisten für Teilfunktionen sind und als Team die Software im Fahrzeug zum Laufen bringen.
Autosar baut auf einem klassischen Hardware Abstraction Layer auf - hier ECU abstraction genannt weil der Anwendungsbereich von AUTOSAR beschränkt sich zunächst auf Steuergeräte im Automobil. Durch die Hardware-Abstraktion wird der Wechsel eine Microcontrollerfamilie möglich, wo es früher ein lebenslanges Lock-In durch den Halbleiterhersteller gab. Die Microcontroller Abstraction ist ein ziemlich universelles Stück Code weil sie alle Optionen der Controller-Peripherie abdeckt. Die ECU abstraction layer definiert dann was davon wirklich gebraucht wird. Die unteren Schichten werden durch den Services Layer abgeschlossen, dahinter verbergen sich Betriebssystem-Services, Kommunikationsprotokolle und auch Speicherverwaltung.
Das AUTOSAR RTE (Run Time Environment) ist die Schicht auf der die OEMs "programmieren", soll heissen dort werden weitere Softwaremodule eingehängt. Dieser Level ist bereits weit von realer Hardware entfernt, so dass es kaum eine Rolle spielt, woher diese Hardware kommt, wer sie baut oder wo sie sich im Auto befindet. Die AUTOSAR Philosophie funktioniert gut mit scharf abgegrenzten statisch definierten Peripherieeinheiten so wie CAN, Speicherzellen, oder ADC Wandlern. Komplexere, gar sich zeitlich verändernde Peripheriefunktionen sind weniger "portable" auf andere Microcontroller und bedürfen spezieller Tricks und ein wenig Handarbeit um das Puzzle zu vervollständigen.
Modulare Software hat einen weiteren Nebeneffekt, um die verschiedenen Module sauber zu trennen wird mehr Code als bei monolithischer Struktur notwendig. Schnell kommen auch für einfache Aufgaben einige hundert Kilobyte zusammen, die komplexeren Steuergeräte brauchen Megabytes und die Anzahl der Module wird durch Autosar nicht gerade gemindert, eher im Gegenteil. Die Flexibilität in der Auswahl der Sub-Komponenten wird durch Komplexität im Gesamtaufbau erkauft, dies schlägt sich schnell in Bits und Bytes nieder. So betreibt jeder Hersteller und die meisten Zulieferer ein wenig Grundlagenforschung um herauszufinden mit wieviel Kilobytes sich Autosar in ihren Systemen breit macht. Meist wird der Zuwachs an Codegröße und die damit verbundenen offensichtlichen Hardwarekosten mehr als ausgeglichen durch die Vereinfachung der Softwareerstellung und einen geringeren Testaufwand. Das AUTOSAR-Baukastenssystem ermöglicht die Vermeidung von komplexen Problemen an wenig sichtbaren Stellen, welche in klassischen Projekten oft zu Budgetüberschreitungen geführt haben und dank Autosar nun sicher umfahren werden können.

Liebevolle Handarbeit in der Automobilbranche - gibt es das noch?!?

Ich höre Sie schon schreien, aber lassen Sie mich ein wenig ausholen und setzen Sie sich, denn die Überraschung ist keine angenehme. Also, für größere Kinder und junggebliebene Erwachsene gibt es das Hobby des Modellbaus. Wie bei den meisten Hobbies läßt sich damit kaum Geld verdienen, aber eine ganze Industrie lebt davon. Im Modellbau gibt es im Wesentlichen drei Ansätze:
a) Bausätze.
b) passende Materialien schneiden, kleben, schrauben, löten.
c) Bausteine.

Was gibt es zu tun und warum machen wir das eine und nicht das andere?
a) Generell als Modellbau etabliert ist das Zusamenfügen von industriell vorgefertigten Bausätzen. Dies ist für wenig phantasiebegabte Hobbyisten die sichere Lösung für ein realitätsnahes Modell. In der bildenden Kunst gibt es eine ähnliche Technologie, das sogenannte "Malen nach Zahlen".
b) Womit wir zur zweiten Fraktion der Modellbauer kommen. Fortgeschrittene Hobbyisten sägen in liebevoller Handarbeit aus Holz, Pappe, Kunststoff, Metall, und weiteren geeeigneten Materialien ihre eigenen Bauteile aus, die zusammengefügt, geklebt oder geschraubt, ein optisch nahe der Wirklichkeit entsprechendes Modell ergeben.
c) Bausteinsysteme sind wesentlich einfacher in der Handhabung als b), und wir finden sie in jedem Spielzeuggeschäft! Populäre Marken sind aus Plastik, daneben gibt es Metallbaukästen. Je nach Interesse und Fähigkeiten läßt sich damit sehr schön spielen und es kommen oft überraschende Gebilde dabei heraus. Für eine "ernsthafte" Modellierung wie zum Beispiel eine Modelleisenbahn taugen die meisten Bausteinsysteme wenig, denn die sich ergebenden Automobile und Häuser sind wenig realitätsnah. Wenn es dagegen um Kräne, Fabrikanlagen oder moderne Architektur geht, trumpfen einige Systembaukästen so richtig auf.
Die geneigten Leser werden schon wissen worauf ich hinaus will, denn unsere Embedded Software muss ja irgendwie auf die Beine kommen und ein Produkt zum Leben erwecken. Dies soll natürlich nichts kosten, darf keine Fehler haben und muss sofort verfügbar sein.

Wie würden unsere Modellbauer dies anstellen?

Für eine wirklichkeitsgetreue Kopie ist sicher Ansatz a) der beste, weil alle Teile vorfabriziert sind. Leider können unsere Modellbauer mit einem Bausatz auch nur immer ein und das selbe Produkt nachbauen. Hier gibt es keine wirkliche Möglichkeit für Innovation oder tiefgreifende Veränderungen. Aus einem Flugzeugbausatz kann man kein Auto bauen, und schon gar kein Haus.
Wenn unser embedded Modellbauer ein Haus bauen sollen, greifen die meisten zur Methode b) denn mit etwas handwerklichem Geschick kann man alle Arten Häuser nachbauen, und auch reale Häuser entstehen ja auch meist in Handarbeit.
Wenn es aber darum geht eine Maschine zu bauen, womöglich noch eine neue Maschine, die etwas anders funktioniert und wo man sich noch nicht recht im Klaren ist wie diese Maschine denn genau funktionieren soll, werden unsere Modellbauer zur Methode c) greifen. Nur die Virtuosen mit ausserordentlichem Geschick bringen auch in Handarbeit niedliche Maschinchen zum Laufen, reagieren aber meist mit Schulterzucken, wenn denn etwas zu ändern sei.
Bei den Bausteine-Modellbauern hängt die Art der Bausteine von der Art des Modells ab. Dies ist schon der Einstieg in die Domänenspezifische Modellierung. Autos, Flugzeuge und Häuser lassen sich gut mit Lego bauen. Türme, Brücken und Maschinen dagegen besser mit Fischertechnik. Die eine Art Bausteine legt mehr Wert auf Äusseres, die andere Art konzentriert sich auf funktionelle Aspekte. Softwaretechnisch könnte man sagen: Lego hat ein ansprechendes GUI, während Fischertechnik die Universalität der "C" Sprache mit sich bringt.
Nun wissen wir alle, dass in der "C" Sprache viel Unsinn angestellt werden kann, weshalb man diese Sprache nicht mit der Methode b) kombinieren sollte, denn handwerklich weniger talentierte Softwerker verlieren sehr viel Zeit (und der Firma Geld ..) dabei, ihr aus "C" zusammengekleistertes Haus mit einem wasserdichten Dach und einer schließenden Tür zu versehen. Dabei sind innere Details wie Wände an denen der Putz nicht hält, und Fußböden mit Löchern zum Glück von aussen nicht sichtbar, aber so sieht es erschreckend häufig in ausgelieferter Software aus - das Produkt funktioniert doch!
In Software soll man zwar nicht wohnen, aber so ganz wohl ist einem nicht wenn solche Software in Autos verbaut wird - womöglich noch in sicherheitsrelevante Steuergeräte von Airbags oder ESP. Wie funktioniert der sichere Hausbau in der Wirklichkeit? Jeder Häuslebauer kann ein Lied von schlampigen Handwerkern und billigen Baumaterialien singen, die Abhilfe liegt auf der Hand: Häufige Inspektionen und Gedanken in bessere Materialien und Werkzeuge investieren.
Übersetzt in die Sprache des Softwareprojektes heisst dies zum Beispiel: Regelmäßige Reviews, talentierte und erfahrene Ingenieure - ob für Requirements, Programmierung, oder Testen - anheuern, und einen stabilen Compiler einsetzen. Schön gesagt, aber all dies kostet Zeit und Geld, die in vielen Projekten (zu) knapp bemessen sind - oder wenn man sie denn hätte, würde mit dem Endprodukt kein Geld mehr verdient, sagt das höhere Management.
Häufig ist das zu entwickelnde Endprodukt nur eine Variante oder Verbesserung des vorherigen Produktes. Viele Projekte werden den original Vorgänger-Code übernehmen und ein wenig den neuen Anforderungen anpassen. Dies geht im Allgemeinen über 1..2 Generationen gut, und nur Firmen mit einer guten Personalpolitik schaffen auch die dritte Generation, denn mit jeder Übernahme in ein neues Projekt wachsen die Fehler exponentiell an.
Eine bessere Strategie für eine im wesentlichen gleiche Produktfamilie ist die Platformentwicklung. Hier werden sichere zentrale Bausteine als Fundament hergenommen, um eine kundenspezifische Lösung aufzubauen. Eine weitere Ausbaustufe dieses Prinzips sind dann sicher kombinierbare Softwaremodule die nur noch konfiguriert werden müssen, um die speziell gesuchte Lösung in einer bestimmten Domäne auszubilden.
Ein Beispiel ist die Steuerung des Einspritzvorgangs für Verbrennungsmotoren in Automobilen. Motoren haben zwischen 1 und 12 Zylindern, drehen mit einigen hundert bis einigen tausend Umdrehungen pro Minute, arbeiten auf verschiedene Getriebe, mit verschieden Lasten, aber im Grunde geschieht immer dasselbe: Kraftstoff wird über steuerbare Ventile eingespritzt und verbrannt. Über die Anzahl und zeitliche Abfolge dieser Einspritzungen wird die Verbrennung gesteuert, und Anforderungen wie Laufruhe, Abgasreinheit und natürlich Drehmoment direkt beieinflusst. Es liegt auf der Hand für solche sich zyklisch wiederholenden Vorgänge einmal die optimale Standardlösung auszuarbeiten, und diese dann nur noch auf eine konkrete Anwendung hin anzupassen. Gerade bei der Motorsteuerung gibt es aber eine Vielzahl Parameter, die auf sich teilweise widersprechende Anforderungen gemappt werden müssen.
Einfacher sind die Verhältnisse in einem Body-Controller, der im Wesentlichen das Licht am und im Auto steuert, die Türen und Fenster überwacht. Da sich die Bedienelemente der verschiedenen Automobilmarken immer mehr annähern - Blinker geht über einen Hebel, manchmal links, manchmal rechts vom Lenkrad, aber es ist immer ein Hebel, kein Drehknopf, kein Schieber - bietet sich für Steuergeräte und Hardware ein Standard an, mit dem nur noch konfiguriert wird, ob der Blinker links oder rechts vom Lenkrad sitzt.

Intelligent interfaces for sophisticated multi-media content distribution in the car is where the processing power goes nowadays. But where will it go in 2020? How much entertainment does mankind need, when the real problem is life and death on our roads?
Future Technology for automotive electronic control units (ECU) is needed!

Executive version: In the past and even today, ECU development has been efficiency-oriented with emphasis on assembly language and the like in order to maximize profit. With all that maximizing a modern development philosophy and its benefit for future developments is often neglected while complexity runs havoc on traditional projects. It has been observed in the industry that todays drivetrain is controlled by software which has been developed with methods and tools of the 80s.
In order to safely operate vehicles in the future a change of philosophy regarding development of ECUs is likely to be more revolutionary than based on principles of reuse. Once a car has been driven against a wall at full speed, it is better to replace the car than attempt any repair. Yet repair is happening under the sign of reuse on many embedded projects. Throwing manpower at such projects helps only the supplier of manpower. A modern approach may mean a departure from central points of today's development cycle: abandon of the C language, the in-circuit-emulator, and no more exhaustive testing.
In the long run, and we are talking generations of automobiles, every car driver will become passenger and the necessary system infrastructure for autodrive needs to be up to highest safety standards in order to allow safe travel for humans. The complexity of many embedded software already has reached the point where design for safety is cheaper than design for efficiency.

When embedded software was simple, there was hardly a need for state-of-the-art tools. But the compile-download-debug approach of the 80s has become the bottleneck in today's development cycle. The real reasons for such a sorry state are not well understood. There is a flurry of activities towards the adoption of object-oriented approaches and other syntactically driven methods that have certainly value in cleaning the structure of embedded software but have barely scratched the surface in terms of quality assurance and time-to-market.

Already in use are methods to capture system specifations at higher levels of abstraction and forcing designers to use tools that emphasize mathematical descriptions, making software code an output of the tool rather than an input. The understanding of the mathematical properties of the embedded system functionality will lead to more secure and efficient ways to generate control software in the future. A future development methodology for Electronic Control Units may not be simply derived from the past. Although reusability is a great buzzword, many engineers know better and sometimes there is a real need to build new generations of software applications from scratch. What's so bad with reuse? You may ask yourself, probably sitting most of your time in front of a Personal Computer executing code that has been written 20 years ago?

After a look forward to 2020 we will analyze current ECU development methods - platform based system design, and outline a way for enhancements in software creation for the automotive industry.

Driving a car in 2020 will be a passive activity: you are driven. With several driver assistance systems operational in 2003 (adaptive cruise control, parking radar, pre-brake system, etc.), the road certification of steer-by-wire in 2008 opened the way for more complex automatic drive functions (autodrive). Hand in hand works the networking of every moving object as well as most environmental elements to allow the seamless integration of all transportation systems. In 2004 the head of Microsoft Research was thinking in this direction when talking about an alarm clock that figures out when to wake you up - based on actual traffic conditions.

Following the certification of Autodrive Vehicle Control (AVC) in 2014, in 2020 over 70 percent of vehicles in USA, Asia and Europe are autodrive capable. These vehicles will schedule their road usage without human intervention. What will follow beyond 2020 is difficult to predict, once our environment is completly networked the need for individual transportation may be less of a central point in our lives. Driving a car will transform into a recreational activity much like horse-riding became a leisure activity in the late 20th century.

Embedded control in the 21st century will rely on self-organizing control structures. Goodbye "Kennlinienfelderlangbezeichnerlabeldatenbank", binary arithmetic, instruction sets, and the "C" programming language. Extrapolating from 15 years ago suggests that some of 2020's most popular microprocessors haven't been invented yet. Future generations of processors will cooperate, sharing tasks on- and off-chip and are likely to adapt their features over time, learning and adapting as they adjust to changing workloads.

Platform based Systems Design as a starting point

The state of embedded systems design at the beginning of the 21st century shows a couple of clear trends. The shift towards more flexible hardware architectures that can support a variety of applications via programmability and re-configurability is underlined. Essential to this process is the orthogonalization of concerns, i.e., the separation of the various aspects of design to allow more effective exploration of alternative solutions. In particular, the separation between:
- function (what the system is supposed to do) and architecture (how it does it);
- communication and computation.

The system platform determines the degree of re-usability of the application software and identifies the hardware platform. In fact, the hardware platform may be deeply affected by the software platform as in the PC platform example. The re-usability of the application software made possible by the PC system platform comes at the expense of a very complex layered structure of the Windows O.S. families and of the size and complexity of the microprocessor cores supporting a byzantine instruction set. In the PC domain, we all pay the price of reuse.

After an idea of what the future may be like, how do we get there and what will be the best way? Modern cars with advanced drivetrain schemes (multiple propulsion elements) require distributed control strategies. Intelligent sensors and actuators will constitute self-organizing networks to implement complete drivetrain control. Energy to these devices may be supplied electrically by wire or induction, mechanically by vibration / noise / heat or by light. Communication between subsystems allows for cross-network self-organization. Auto calibration replaces todays manual calibration process and corresponding overhead. In communication with sensors and actuators, a drive manager unit figures out how to run drivetrain control the most efficiently for any usage profile. Usage profiles may contain any requirement, be that driver temperament, vehicle type, or legal restrictions.

In commercial development organizations, increased complexity of products, shortened development cycles, and higher customer expectations of quality have placed a major responsibility on the areas of software debugging, testing, and verification. Today we have exciting improvements in the underlying technology on all three fronts. However, due to the informal nature of software development as a whole, the prevalent practices in the industry are still immature, even in areas where improved technology exists. A key ingredient that contributes to a reliable programming systems product is the assurance that the program will perform satisfactorily in terms of its functional and nonfunctional specifications. In a typical automotive development organization, the cost of providing this assurance easily ranges above 50 percent of the total development cost.

Code generation of the past has been about writing programs, and understanding them as we write them. Most large computer programs, and current ECU software qualifies as per its inherent complexity as large computer program, are never completely understood. If they were, they would not go wrong so often and we would be able to describe what they do in a scientific way. A good programming language should help to improve this state of affairs. There are many ways of trying to understand programs. In 2004 the automotive industry for a large part relies on one way, which is called "testing and debugging" and consists of running a partly understood program to see if it does what is expected. The whole process is deeply linked to quality methodology which generates enormous overhead effort.

Design for Safety beats design for efficiency in the long run

People used to argue that any overhead in code in order to make code more robust and more secure, runs counterproductive to the competitive situation in the marketplace. Within ten years of digital engine control software the execution power of hardware grew by a factor of fifty, the number of injections per revolution by a factor of five, the number of functions by ten and overall complexity grew more than hundredfold! Today even the most advanced quality assurance schemes run short on actual requirements for software product validation.

While in previous ECU generations the prevalent factor was efficiency with limited resources in mind, the future will bring resources plentiful [mobile phones have more processing power and memory than Windows PC 10 years ago], complexity will grow accordingly and needs to be managed tightly. The main emphasis in automotive embedded systems design will shift from efficiency to safety.

The author started designing 32-bit embedded hard- and software in the late 80s. After a couple of years for Bull Engineering he then worked for Texas Instruments European Marketing as DSP specialist. 1996 he became Application Engineer for Embedded Support Tools (EST) at their European office. After successful EST startups in Germany and the UK he was appointed European Support Manager at the US headquarters. With Wind River Systems he took care of the too-much-ahead-of-its-time visionTRACE product line. Back in Germany he became Development Tool Manager for Bosch Diesel Systems and now he coordinates offshore effort to make german cars better and had an active role in Autosar. Since 2010 he promoted QNX with customers and partners as automotive solutions architect for EMEA. In 2017 he was with Intel for a short stint in their Autonomous Drive Group in Karlsruhe. Bernhard holds a MSEE from Ruhr University Bochum.

Need to know - modern car electronics abreviations:

  • AAS Adaptive Air Suspension (Audi) - Elektropneumatische Federung
  • ABC Active Body Control (DC) - Elektropneumatische Federung
  • ABS Antilock Brake System - Anti-Blockier System
  • ACC Automatic Cruise Control - Abstandsgeregelte Cruise Control
  • ACE Advanced Compatibility Engineering (Honda, Acura) - Crashzonendesign
  • ACIS Acoustic Control Induction System (Toyota, Lexus) - Akustikgesteuerte Einspritzung
  • ADBX Automatic Differential Brake (BMW)
  • ADS Adaptive Damping System (DC) - Nobel-ESP
  • AFL Adaptive Forward Lighting - Kurvenfahrlicht
  • AFS Adaptive Frontlight System
  • AFU Assistence de Freinage de Urgence (RSA, PSA) - Notbremshilfe
  • AGCS Active geometry Control Suspension (Hyundai)
  • AHR Active Head Restraint - Unfallhilfe
  • ALC Automatic Lighting Control (Opel)
  • ALS Active Light System (DC) - Kurvenfahrlicht
  • APS Acoustic Parking System (Audi) - Rückfahr-Abstandswarner
  • AQS Air Quality Sensor (GM) - Frischluftzufuhr-Regelung
  • ARTS Adaptive Restraint Technology System (Jaguar)
  • ASA Audi Side Assist - Totwinkelerkennung
  • ASC Automatic Stability Control (BMW) ESP
  • ASG Auto Shift Gearbox - Automatikgetriebe basierend auf Schaltgetriebe
  • ASR Anti Slip Regulator - Traktionskontrolle
  • ATC Automatic Temperture Control - Klimaautomatik
  • AUC / AAR (BMW) - Innenraum-Luftregelung
  • AVS Adaptive Variable Suspension (Lexus) - Luftfederung
  • BA Brake Assist (Toyota) - Notbremshilfe
  • BAS Brake Assist System (DC) - Notbremshilfe
  • BLIS Blind Spot Information System (Volvo) - Totwinkelerkennung
  • BSI Boitier de Servitude Intelligent (PSA) - Verbraucherabschaltung
  • BSW Bremsen antrocknen bei aktivem Scheibenwischer
  • CATS Computer Active Technology Suspension (Jaguar)
  • CBC Cornering Brake Control - Kurvenbremshilfe
  • CDC Continous Damping Control - Pneumatische Fahrwerksregelung
  • CDPF Coated Diesel Particulate Filter (Volvo)
  • CRDI Common Rail Diesel Injection - Common Rail Dieseleinspritzung
  • CST Stability and Traction Control (Ferrari)
  • CVT Continously Variable Transmission - Automatikgetriebe basierend auf Riemen
  • CVTC Continously Variable Valve Timing Control - Ventilregelung
  • DBC Dynamic Brake Control (BMW) - Notbremshilfe
  • D-CAT Diesel Clean Advanced Technologies (Toyota) Kein Kat, aber sauberer Diesel
  • DDE Digital Diesel Electronics - EDC
  • DDS Deflation Detection System - Reifendruckkontrolle
  • DISA Dual Resonance Intake System (BMW) Differenzierte Sauganlage
  • DME Digital Motors Electronics (BMW) Motorsteuerung
  • DOHC Double Over Head Camshaft (Honda) - Doppelte Nockenwelle
  • DPF Diesel Particulate Filter
  • DPNR Diesel Particulate NOx Rduction Filter (Toyota)
  • DRC Dynamic Ride Control (Audi) - ESP
  • DSA Dynamic Steering Angle Control - Dynamische Lenkwinkelregelung
  • DSC Dynamic Stability Control - ESP
  • DSG Direct Shift Gearbox - Getriebe ohne Kraftunterbrechung mit doppelter Kupplung
  • DSR Driver Steering Recommendation (VW) - Lenkhilfe
  • DSR Downhill Speed Regulation (Dc) - Bergabfahrhilfe
  • DSTC, DTC Dynamic Stability and Traction Control - ESP
  • EARS Enhanced Accident Response System (DC) - Unfallhilfe
  • EBA Emergency Brake Assist (Ford) - Notbremshilfe
  • EBD, EBV Electronic Brake Distributor - Elektronische Bremskraft Verteilung
  • EBS Emergency Braking System - Notbremshilfe
  • ECc Electronic Climate Control (Opel) - Klimaautomatik
  • ECU Electronic Control Unit - elektronisches Steuergerät, embedded system
  • EDC Electronic Diesel Control (Bosch)
  • EDC Electronic Damping Control (BMW) Nobel-ESP
  • EGR Exhaust Gas Recirculation - Abgasrückführung
  • EPB Electronic Parking Brake - Elektronische Handbremse
  • EPCD Early Pole Crash Detection - Seitenaufprallschutz
  • ERS Electronic Range System (Jeep) - Gangauswahlhilfe
  • ESBS Electronic Stability Brake System (VW) - Kurvenbremshilfe
  • ESP Electronic Stability Program - Elektronisches Stabilitätsprogramm
  • ETC / ETCS Electronic Throttle Control System - Elektronisches Gaspedal
  • ETS Electronic Traction Support
  • FAP Filtre à Particules (RSA, PSA) - Dieselpartikelfilter
  • FPS Fire Protection System - Unfallhilfe
  • FSI Fuel Stratified Injection (VW) - Benzindirekteinspritzung
  • GPS Global Positioning System - Satellitengestützte Positionierung
  • HAC Hill-start Assist Control (Toyota) - Berganfahrhilfe
  • HBA Hydraulic Brake Assist - Elektrohydraulische Bremshilfe
  • HDC Hill Descent Control (BMW) - Bergabfahrhilfe
  • HDI High pressure Direct Injection (PSA) - Common Rail Dieseleinspritzung
  • HPI High pressure Petrol Injection (PSA) - Benzindirekteinspritzung
  • HSA Hill Start Assist - Berganfahrhilfe
  • HUD Head Up Display (BMW) - Einspiegelung in die Windschutzscheibe
  • IAFS Intelligent Adaptive Front Lighting System (Lexus) - Kurvenfahrlicht
  • ICC Integrated Chassis Control Network (Opel)
  • IDS Interactive Driving System (Opel) ESP
  • IDIS Intelligent Driver Information System (Volvo) Informationsmanagementsystem
  • IPS Intelligent Protection System (Ford) - Unfallhilfe
  • ITS Inflatable Tubular Structure (BMW) - Spezielle Airbag Form
  • LDW Lane Departure Warning - Spurwechselwarnung
  • LEV Low Emission Vehicle - Niederemissionsfahrzeug
  • LKAS Lane Keeping Assist System - Spurhalteassistent
  • LSD Limited Slip Differential (Toyota) - Kurvenstabilisator
  • MCB Multi Communication Bar (Audi)
  • MDS Multi Displacement System (DC) - Kolbenregelung
  • MICS Minimum Intrusion Cabin System (Toyota) - Innenraumschutz
  • MMI Multi Media Interface
  • MMI Man Machine Interface
  • MMS M Mobility System (BMW) - Reifenpannenhilfe
  • MMT Multi Mode Transmission (Toyota) - Automatik basierend auf Schaltgetriebe
  • MSR Motor Schleppmoment Regelung - Antischlupfregelung
  • NRT Noise Reduction Technology - Geräuschdämpfungssystem
  • PASM Porsche Active Suspension Management - ESP
  • PCM Porsche communication Management
  • PDC Park Distance Control - Rückfahr-Abstandswarner
  • PRS Pedal Release System (Opel) - Unfallhilfe
  • PSS Passenger Sensing System (GM) - Unfallhilfe
  • RDC/RDK Reifen Druck Control (BMW) - Reifendrucküberwachung
  • REF Reparticion Electronique de Freinage (PSA) - Elektronische Bremskraft Verteilung
  • RPA Reifen Pannen Anzeige (BMW)
  • RSC Roll Stability Control (Volvo) ESP
  • SBC Sensotronic Brake Control (Dc) - Elektrohydraulisches Bremssystem
  • SCM Secondary Collision Mitigation - Vollbremsung nach Auslösen der Airbags
  • SIPS Side Impact Protection System (Volvo) - Seitenaufprallschutz
  • SMG Sequential Manual Gear (BMW) - Sequentielle Gangschaltung am Lenkrad
  • SOHC Single Over Head Camshaft - Einfache Nockenwelle
  • SRS Supplementary Restraint System - Airbag
  • SSP (RSA) - Gurtstraffer
  • SSPS Speed Sensitive Power Steering - Geschwindigkeitsabhängige Lenkhilfe
  • TCS Traction Control System
  • TDI Turbo Diesel Injection
  • TOD Torque On Demand (Isuzu) - Automatische Lastverteilung
  • TPMS Tyre Pressure Measurment System - Reifendruckkontrolle
  • TPS Total Protection System (Subaru)
  • TSP Trailer Stability Program - ESP für Anhänger
  • ULC Understeer Logic Control - ESP
  • VCP Variable Camshaft Phasing (Land Rover) - Ventilsteuerung
  • VDC Vehicle Dynamic Control (Alfa Romeo) - ESP
  • VDIM Vehicle Dynamics Integrated Management (Lexus) - Nobel-ESP
  • VSA Vehicle Stability Assist (Honda) - ESP
  • VSC Vehicle Skid Control (Toyota) ESP
  • VVL Variable Valve Lift - Ventilsteuerung
  • VTEC / VVT Variable Valve Timing and Lift Electronic Control System - Elektronische Ventilsteuerung
  • WRG Water Repellent Glass (Volvo) - Beschlaghemmende Rückspiegel
  • ZEV Zero Emission Vehicle - Auto ohne schädliche Abgase
Embedded Expert for your Embedded Software Design Process

| Home | Services | Product Manager | Impressum |

EmbeddedExpert 2017 - Alle Marken, Warenzeichen und Handelsnamen sind Eigentum der jeweiligen Inhaber.

© BK media systems 2002, 2016.

All trademarks and registered names are property of their respective owners. German law requires Impressum