Embedded Software Engineering 2/2015 - files.vogel.defiles.vogel.de/vogelonline/vogelonline/issues/ep/2015/202.pdf · Beispiel soll hier der normale Produkt-Le-benszykluseinerSoftware-Anwendungdie-

Wissen.Impulse.Kontakte. Mai 2015

Wege zur Sicherheitim Internet der Dinge

Codequalität – derSchlüssel für dieIndustrie 4.0Grundzüge einer ganzheit-lichen Software-Qualitäts-strategie Seite 10

Software-Kompo-nentenschutz nachISO 26262Lösungsansätze zur Modul-trennung in Automotive-Systemen Seite 12

Roboterentwick-lung für die DARPA-ChallengeEin Studententeam des MITmeistert den Robotik-Wett-bewerb Seite 20

EMBEDDED SOFTWARE ENGINEERING

www.elektronikpraxis.de

Sponsored by

Kommt der Hacker bald aus dem Kühlschrank oder aus dem Fitness-Armband?Experten plädieren für ein Umdenken in der Systementwicklung.

document405640802042557462.indd 1 05.05.2015 10:41:07

http://www.elektronikpraxis.de

http://www.ghs.com/index_main.html

http://www.digikey.de/

150410_SUPR_EP_DE.indd 1 4/3/15 3:44 PM

http://www.digikey.de/

3

EDITORIAL

ELEKTRONIKPRAXIS Embedded Software Engineering Report Mai 2015

Wenn's schnell gehen soll, mussman manchmal langsam arbeiten

Manchmal sind gerade die einfa-chenDinge amschwersten. BeimletztenESE-Kongress erntete der

emeritierte Stuttgarter Informatik-Profes-sor Jochen Ludewig stürmischen Beifallfür seine Keynote-Ansprache, die er mitden Worten einleitete: „Ich werde Ihnenjetzt nichts Neues erzählen.“ Er sprachüber handwerklich saubere Entwick-lungsarbeit, riet zu klaren Begrifflichkei-ten und dazu, Checklisten zu führen. Ermahnte dasKISS-Prinzip an (keep it smalland simple) und warnte eindringlich vorangeblichenWundermitteln, die verspre-chen, alle Problemeder Softwareentwick-lung über Nacht zu lösen.Alles also ganz einfach? Alles gut im

Embedded-Land? Jederweißdoch eigent-lich, wie es richtig geht, sollte man mei-nen. Aber Ideal und Wirklichkeit sindoffensichtlich nicht immer so leicht zurDeckung zu bringen. Beim alltäglichenProjektwahnsinn ist es oft eben nicht soeinfach, den Schritt zurück zu tun, dasGesamtbild auf sichwirken zu lassenundin aller Ruhe zu überlegen, wo es dennhakt.Ich glaube, der Schlüssel ist dieses klei-

ne Wörtchen „Ruhe“. Wir alle sind imInternetzeitalter auf Hektik program-

„Vielleicht ist gerade inder Projektarbeit dannund wann etwasEntschleunigung nötig.“

Franz Graser, [email protected]

miert. Wenn geliefert werden soll, dannsofort. ASAP ist das durchgängigeMotto:As soonaspossible – sobaldwiemöglich.Und wenn es geht, sogar noch früher!Vielleicht ist gerade inder Projektarbeit

dann und wann so etwas wie Entschleu-nigung nötig, um wieder zu Atem kom-men zu können, um trotz aller Einzelpro-bleme wieder den Überblick über dasGanze zu bekommen. Ich erinnere michan einen CSI-Forensiker aus demFernse-hen, der immer wieder sagte: „Wenn esschnell gehen soll, muss ich langsam ar-beiten.“ Er meinte damit: Langsam, be-dächtig und überlegt vorgehen – Schrittfür Schritt, um Flüchtigkeitsfehler zuvermeiden, die dazu führen, dass manwieder von vorne anfangenmuss. Das istdoch ein ganz guter Ansatz. Ich sage Ih-nen damit bestimmt nichts Neues. Aberich wünsche Ihnen, dass es klappt.

Herzlichst, Ihr

Was Geschäftsführer über Embedded-Software wissen solltenReferent: Professor Dr. Jochen Ludewig,Universität Stuttgart

Die Zukunft des Embedded SoftwareEngineeringReferent: Prof. Dr.-Ing. Peter Liggesmeyer,Fraunhofer IESE

Geschäftsmodelle IoT – erfolgreich imInternet der DingeReferent: Alois Schwarz,Flexera Software

8. Juli 2015 · Würzburg · Vogel Convention Center VCC

arz,

JETZTANMELDEN

PROGRAMMHIGHLIGHTS:

Eine Veranstaltung von:

Hauptsponsor:

Themensponsoren:

10680

www.ese-summit.de

Axivion GmbHemlix GmbHHitex GmbH

WIBU-SYSTEMS AGWillert Software Tools GmbH

document2209027748580413407.indd 3 05.05.2015 13:57:08

mailto:[email protected]

http://www.ese-summit.de

4 ELEKTRONIKPRAXIS Embedded Software Engineering Report Mai 2015

INHALT

FACHARTIKELInternet of ThingsTITELTHEMA

6 Wege zur Sicherheit im Internet der DingeKommt der Hacker bald aus dem Kühlschrank oder ausdem smarten Thermostat? Experten plädieren für ein Um-denken in der Systementwicklung.

Softwaretest10 Softwarequalität – der Schlüssel zu Industrie 4.0

Durch das Internet der Dinge enthalten immer mehr Pro-dukte eingebettete Software. Dabei wird Softwarequalitätzu einem der Kriterien, die über Erfolg und Misserfolg einesGeschäftsmodells entscheiden.

Automotive12 Softwarekomponenten-Schutz nach ISO 26262

Die Automobil-Entwicklungsnorm ISO 26262 sieht dieIsolation der Softwarekomponenten gegen gegenseitigeBeeinflussung als wichtigste Aufgabe an. Der Artikel zeigtAnsätze zum Komponentenschutz auf.

Cyber-Physische Systeme16 Entwicklungsbeschleuniger: Zeit als neue Währung

(Teil 2)LabVIEW im Serienprodukt: Echtzeit-Linux und C-Genera-tor ermöglichen Echtzeit-Software auf eigener Embedded-Hardware.

Robotik und Kybernetik20 Nichtlineare Feedbackregelung für die DARPA Ro-

botics ChallengeDie DARPA Robotics Challenge dient zur Forschung anRobotern an, die autonom in Gefahrenbereichen arbeiten.Der Bericht zeigt, wie ein Team des MIT den Wettbewerbmeisterte.

Projektmanagement24 Anforderungsmanagement und Rückverfolgbarkeit

Qualitätssicherung kann nicht nur Code-Analyse und Testbedeuten. Denn weder Analyse-Lösungen noch Tests stel-len sicher, dass Systemanforderungen korrekt umgesetztwurden. Hierfür bedarf es einer integrierten Strategie.

RUBRIKEN3 Editorial

15 Aktuelle Produkte

26 Impressum

Automatische Identifikation mit RFIDwww.elektronikpraxis.de/specials

Das Magazin als E-Paper lesenwww.elektronikpraxis.de/epaper

INTERNET OF THINGS

Wege zur Sicherheit imInternet der DingeWer Systeme für das Internet der Dinge konzipiert,muss sich dessen bewusst sein, dass die Anbindungan das Netz nicht nur die Funktionalität verbrei-tert - Geräte, die vormals für sich standen, werdenmit einem Mal angreifbar. Sichere Systeme für dasIoT müssen daher nach klaren Kriterien entworfenwerden und Security-Vorgaben erfüllen. Entwicklersowie Geräte- und Diensteanbieter müssen dasentsprechende Bewusstsein entwickeln.

Bildcollage: Gleam/iconimage (Fotolia)

6

document6422519969420102927.indd 4 05.05.2015 10:53:33

http://www.elektronikpraxis.de/specials

http://www.elektronikpraxis.de/epaper

150421_MYS_EP_DE.indd 1 4/17/15 3:10 PM

http://www.digikey.de/de/resources/design-tools/design-tools?WT.z_vanity=designtools


TITELSTORY // INTERNET OF THINGS

6

TITELSTORYKommen die Hacker bald aus demKühlschrank, der mit dem Internetvernetzt ist oder der intelligenten Kü-chenmaschine, die täglich aus demNetz aktuelle Rezepte lädt (und dieschädliche Malware gleich mit)? WerSysteme für das Internet der Dingekonzipiert, muss sich dessen be-wusst sein, dass die Anbindung andas Netz nicht nur die Funktionalitätverbreitert – Geräte, die vormals fürsich standen, werden mit einem Malangreifbar. Sichere Systeme für dasIoT müssen daher nach klaren Krite-rien entworfen werden und wichtigeSecurity-Vorgaben erfüllen. Entwick-ler sowie Geräte- und Diensteanbietermüssen das entsprechende Bewusst-sein entwickeln.


Bildcollage:G

leam

/iconimage(Fotolia)

document4231856635345254796.indd 6 05.05.2015 10:43:00

7



Wege zur Sicherheitim Internet der Dinge

Kommt der Hacker bald aus dem Kühlschrank oder ausdem smarten Thermostat? Experten plädieren für ein

Umdenken in der Systementwicklung.

FRANZ GRASER

Es ist ein ungewöhnlicher Ort, an demich David Kleidermacher treffe: SeitJahren kenne ich ihn als Cheftechno-

logen des Embedded-Software-HerstellersGreenHills Software. Diesmal – es istwiederEmbeddedWorld inNürnberg – setzt er sicham Stand von QNX zu mir. Erst beim Blickauf die Visitenkarte fällt der Groschen: Klei-dermacher ist jetzt Chief SecurityOfficer desMobilgeräte- und Cloud-Spezialisten Black-Berry, zu dem QNX gehört.Es ist eineÜberraschung.AberDavidKlei-

dermacher ist ein Mann mit einer Mission.Durch die Entwicklungen bei Green HillsSoftware hat er die Embedded-Welt mitge-prägt. Das Buch „Embedded Systems Secu-rity“ über Methoden zum Bau robuster undzuverlässiger Systeme, das er zusammenmitseinem Vater Mike geschrieben hat, ist einStandardwerk [1]. Jetzt also ist die Cloud ander Reihe. Das ergibt Sinn: Im Internet derDinge finden eingebettete Systeme und

Cloud-Dienste zusammen, erst im Zusam-menspiel der Geräte am Rande des Netzesund den Services im Zentrum ergeben sichdie potenziellen Mehrwerte.

2014 wurden 117.000 Cyber-Attacken registriert. Pro Tag.Denn bei dem Hype um das Internet der

Dinge und die Industrie 4.0, die neue Wirt-schaftswunder verspricht,wird einProblemmeist ausgeklammert: Wie steht es mit derSicherheit der Daten, die von den GerätenamRanddesNetzes gesammelt undvondenBig-Data-Diensten verarbeitet werden?Nicht gut. Denn Frank Melber, der beim

TÜV Rheinland das Business DevelopmentimBereich IT-Sicherheit leitet, sagt: „Ist eineKaffeemaschine oder eine Glühbirne inter-netfähig, dann handelt es sich faktisch umeinen Computer, der Kaffee kocht oder denRaumbeleuchtet. EinComputer, der amNetzhängt, ist immer ein potenzielles Ziel für

Cyber-Angriffe. DieKernfrage imZusammen-hang mit dem Internet der Dinge ist: Sindsich die Hersteller der Internet-fähigen Ge-räte der Tatsache bewusst, dass sie es An-greifern ermöglichen, weitere Schäden zuverursachen, deren Kanäle noch schwierigzu detektieren sind und die derzeit bekann-ten Bedrohungsszenarien noch überschrei-ten können?“Dazu ein paar Zahlen: Im vergangenen

Jahr wurden laut Pricewaterhouse Coopersweltweit rund 43 Millionen Cyber-Attackenregistriert – einneuerHöchststand.Das sind117.000 Angriffe pro Tag. „Angriffswerkzeu-ge, die bisher vonStaaten eingesetztwurden,sind heute für jedermann im Internet freizugänglich“, sagt TÜV-Experte Melber.Für David Kleidermacher steht fest: Ver-

netzte Embedded-Geräte undCloud-Servicessind im Kontext des IoT jeweils zwei Seitenderselben Münze: „Damit das Internet derDinge funktioniert, muss das Gerät selbst

Bild:©

DenysPrykho

dov-Fotolia

document4231856635345254796.indd 7 05.05.2015 10:43:09

8



Potenzielle Einfallstore fürDatendiebe: Smarte Fern-sehgeräte und intelligenteKühlschränke, die mit demInternet verbunden sind,verfügen in der Regel nichtüber Schutzmechanismengegen Angreifer. Zudemwerden sie in aller Regelnicht mit aktuellen Sicher-heits-Updates versorgt.

Bild:©

chesky

-Fotolia

Teil einer größeren Geschichte sein. Manbraucht Datensicherheit und die Fähigkeit,vomGerät bis hinauf zur Cloud zu skalieren.Es ist außerdemwichtig, eine Ende-zu-Ende-Lösung anzubieten, die sowohl die Daten-analyse als auch eine robuste Cloud-Lösungeinschließt, die überall auf der Welt laufenundunglaubliche Informationsmengenver-arbeiten kann.“Wieman sichere und zuverlässige Embed-

ded-Systemebaut,weißder jetzige Security-Chef von BlackBerry. Unter seiner Mitarbeitentstand bei Green Hills mit Integrity-178Bdas bisher einzige Echtzeitbetriebssystem,dasnachdemCommon-Criteria-KatalogdenEvaluation Assurance Level 6+ aufweist.

Klare Prinzipien für sichere IoT-SystemeAußerdem hat Kleidermacher mit dem

PHASE-Modell (PHASE steht für Principle ofHigh Assurance Security Engineering) fünfPrinzipien für die Entwicklung robuster undsicherer Lösungen definiert. Diese Kriterienpassen quasi auf einen Bierdeckel: Minima-le Implementierung, komponentenbasierteArchitektur, das Principle of Least Privilege(Softwareprozesse und -module sollten le-diglich Zugriffe auf die Systemressourcenerhalten, die sie für ihreAufgabe tatsächlichbenötigen), ein sicherer Entwicklungspro-zess undValidierungdurch externeExpertensind die Grundlagen sicherer Systeme.

„Damit das Internet der Dinge funktioniert, muss das ver-netzte Gerät selbst ein Teil einer größeren Geschichte sein.“

David Kleidermacher, Chief Security Officer, BlackBerry

Die Grundsätze sollen aber nicht nur denEntwicklern klar sein. Kleidermacher for-dert, dass diese Prinzipien imganzenUnter-nehmenverstandenundvomVorstandschefabwärts von der gesamten Belegschaft um-gesetztwerden: „Manmussdiese Prinzipienauf alles anwenden, was man tut – darauf,wie man den Quellcode verwaltet und dasNetzwerkmanagt,wiemandenZugang zumComputerraum regelt – und auch auf denProzess für die Softwareentwicklung.“

Mikrokernel als Plattform zurVirtualisierungNatürlich lesen sich die fünf PHASE-Prin-

zipien einfacher, als sie sich umsetzen las-sen. Das Aufbrechen von Software in Kom-ponenten sei zum Beispiel zeitaufwendigund kostenträchtig, „aber es muss gemachtwerden“, insistiert Kleidermacher. Am bes-ten sei es,wenngenau einePerson für genaueine Komponente verantwortlich ist. Da-durch sei gewährleistet, dass der Code derbetreffenden Komponente überschaubarbleibe. Das gegenteilige Extrem sieht Klei-dermacher dagegen als Horrorvorstellungan: „Wenn50Personenan einerKomponen-te arbeiten, ist keiner verantwortlich. Daskann nicht klappen.“DieseGrundsätze gilt es nunauf die große

IT, also auf Unternehmenslösungen undCloud-Dienste zuübertragen. BlackBerry, soKleidermacher, habehier gegenüber anderen

KonkurrentendenVorteil, dass es bereits voneiner tiefgreifendenSicherheitskultur durch-drungen ist: „Wenn Leute 15 Varianten desSpielsAngryBirds auf ihr Smartphone laden,dannbesteht eine reelle Chance, dass sie sichmit Malware infizieren. Wennman aber An-gry Birds in einem abgeteilten Bereich [desSmartphones] spielt und der geschäftlicheBereichdavonkomplett getrennt und isoliertist, dann spielt das keine Rolle. BlackBerrywar das erste Unternehmen, das dies ver-standen hat.“Diese Aufteilung der Gerätesoftware in

geschäfts- oder sicherheitskritische und all-gemein zugänglicheBereiche spielt aus Sichtvon David Kleidermacher eine nicht zu un-terschätzende Rolle im Internet der Dinge.Virtualisierungstechniken, bei denen Echt-zeitbetriebssysteme als Hypervisor-Plattfor-men dienen und Anwendungsbereiche ge-geneinander isolieren,werdenanBedeutungzunehmen. Insbesondere Betriebssysteme,die auf Mikrokerneln basieren, dürften sichfür solche Plattformen gut eignen, meintKleidermacher. Momentan seien Controlleretwa der Cortex-M-Klasse noch nicht in derLage, solche Systeme zu beherbergen, aberdas werde sich in absehbarer Zeit ändern.„Chipsätze, auf denen Mikrokernel laufenkönnen, werden immer preiswerter. Natür-lich wird es immer winzig kleine Sensorengeben, auf denendasnichtmöglich ist. Aberdie Mikrokernel werden immer breiter an-wendbar, der Trendgeht in die richtigeRich-tung.“

Over-the-Air-Updates sindzentrales QualitätsmerkmalEinweitereswichtigesKriterium für siche-

re Systeme im IoT ist die Fähigkeit, die mitdem Netz verknüpften Geräte „over the air“(OTA)mit Software-Aktualisierungen zu ver-sorgen. TÜV-Experte FrankMelber kritisiert,dass die wenigsten internet-fähigen Gerätemit regelmäßigen Sicherheits-Updates aufden neuesten Stand der Firmware gebrachtwerden. Auch in diesemBereich sieht DavidKleidermacher einen Erfahrungsvorsprungfür seine neue Firma: „Wer sonst hat eineLösung für Over-the-Air-Updates, die gegenMillionenGeräte imFeld getestetwurdeunddie all die unterschiedlichen Softwareversi-onen verwalten kann? Es gibt eine Mengeharter ProblemebeiOTA, undBlackBerry hatsie bereits gelöst.“ // FG

Literaturhinweise:[1] David undMike Kleidermacher: Embedded

Systems Security. Practical Methods for Safeand Secure Software and Systems Develop-ment. Elsevier 2012

document4231856635345254796.indd 8 05.05.2015 10:43:12

ELEKTRONIKPRAXIS Embedded Software Engineering Report Mai 2015 9


INTERVIEW MIT DAVID KLEIDERMACHER, BLACKBERRY

„Wir müssen die Erfahrungen aus demEmbedded-Umfeld auf das IoT übertragen“Das Internet der Dinge wird im Embed-ded- und im IT-Bereich heiß diskutiert.Gleichzeitig sind viele IoT-Ansätzeziemlich vage. Wie sehen Sie die Lage?Historisch gesehen haben sich Firmenwie Green Hills und QNX stets starkauf das Gerät fokussiert. Aber damitdas IoT funktioniert, muss das GerätTeil einer größeren Geschichte sein.Man braucht Datensicherheit und dieFähigkeit, vom Gerät hinauf zur Cloudzu skalieren. Es ist zudem wichtig,eine Ende-zu-Ende-Lösung anzubie-ten, die sowohl die Datenanalyseals auch eine robuste Cloud-Lösungeinschließt, die überall auf der Weltlaufen und unglaubliche Informations-mengen handhaben kann.

Wo sehen Sie BlackBerry in diesem Zu-sammenhang?Eines der Dinge, die fürmich bei Black-Berry attraktiv waren, ist: Sie besitzenbereits eine solche Lösung für Mobil-geräte. Schon seit vielen Jahren habensie ein Data Center, das in der Lage ist,enorme Informationsmengen, Messa-ging, Upgrades für die Geräte im Feldund Ähnliches zu verarbeiten. Undwissen Sie was? Eingebettete Systemebrauchen das alles auch! Insofern istdie Ehe zwischen BlackBerry und QNXquasi im Himmel geschlossen worden.

Worauf konzentrieren Sie sich in IhrerRolle als Chief Security Officer?Eine meiner Aufgaben ist das Konzeptder „High Assurance“. Viele Leute inder Embedded-Branche wissen, dass

hohe Zuverlässigkeits-Level sehrwichtig sind. Ihnen ist klar, dass einSystem, etwa im Falle eines Medizin-geräts oder bei einem Automotive-System mit ASIL-D-Level, die Funktio-nen zuverlässig erfüllen muss, die derGeräteentwickler vorgesehen hat – inBezug auf die funktionale und auf dieDatensicherheit. Aber wenn man sicheinige Cloud-Services ansieht, etwavon Google oder Samsung, dann istdieser Assurance-Gedanke, den Fir-men wie QNX schon lange vertreten,fast nicht vorhanden. Es gibt ihn ein-fach nicht! Man hört ja jeden Tag vonneuen Hacks. Deshalb glaube ich,dass wir viel gewinnen können, wennwir das, was wir im Embedded-Bereichüber High Assurance gelernt haben,auf das IoT übertragen. Meine Strate-gie ist es, diesen Gedanken auf mobi-le Geräte und die Cloud anzuwenden.

Beeinflusst damit der Embedded-Be-reich die allgemeine IT statt umgekehrt?Exakt. BlackBerry ist für diese Ideesehr empfänglich, weil die Firma be-reits über eine Security-Kultur verfügt.Google ist ein tolles Unternehmen –sie planen Sachen wie Ballons für denInternetzugang abgelegener Gebieteund Ähnliches. Aber bei BlackBerrywar die Sicherheitskultur immer Teilder Firmen-DNA. Tausende denkenjeden Tag über Datensicherheit nach– ein großer Prozentsatz des ganzenTeams. Ich würde wetten, dass dieserProzentsatz bei anderen großen Tech-Unternehmen weit kleiner ist.

David Kleidermacher: Der langjähri-ge Cheftechnologe des Embedded-Spezialisten Green Hills Softwareist nun Chief Security Officer beimMobilfunk- und Cloud-AnbieterBlackBerry. Seine Erfahrungen ausdem Embedded-Umfeld bringt er nunins Internet der Dinge ein.

Lesen Sie das gesammelteELEKTRONIKPRAXIS-Wissen aufIhrem PC, Laptop oder iPad undsichern Sie sich kostenlos Ihrgedrucktes Kompendium* unter

--> www.elektronikpraxis.de/starterkits-kompendium

www.vogel.de

*limitierte Auflage

Starterkits &Design-Tipps

Board-Auswahl

Industrie-Boards

Software

Tools & Boards

Jetzt als

ePaper

lesen!

DIGITAL-KOMPENDIUM

Starterkits undDesign-Tipps

1003

2

document4231856635345254796.indd 9 05.05.2015 10:43:15

http://www.elektronikpraxis.de/starterkits-kompendium

http://www.vogel.de

10

QUALITÄTSSICHERUNG // SOFTWARETESTS


Softwarequalität – der Schlüsselzur vierten industriellen Revolution

Im Zuge des Internets der Dinge enthalten immer mehr Produkte einge-bettete Software. Dabei wird Softwarequalität zu einem der Kriterien,die über Erfolg und Misserfolg eines Geschäftsmodells entscheiden.

NIROSHAN RAJADURAI *

* Niroshan Rajadurai... ist Executive Vice President für Europa, den Mitt-leren Osten und Afrika bei Vector Software.

Software durchdringt heute die Gegen-stände, die uns im Alltag umgeben.Dies gilt nicht nur im Büro, sondern

auch bei vielen anderen Dingen – in Autos,in denSpielzeugen, diewir unserenKindernschenken, imBus, denwir täglichbenutzen,inunsererHaushaltsgerätenund inmedizin-technischen Systemen, die unsere Gesund-heit sichern.In den letzten Jahren wanderte Software

zunehmend vom Desktop-Rechner in dieCloud. Dank des Internets der Dinge (IoT –Internet of Things) kommtdie Softwarewie-der zurück andie Peripherie desNetzes, undimmermehr Produkte enthalten eingebette-te Softwareanwendungen. Dabei wird Soft-ware-Qualität zu einemder entscheidendenKriterien, die über Erfolg oder Misserfolgdieser Umstellung bestimmen.Je mehr wir uns auf Produkte verlassen,

deren Funktionsumfang von Software be-

stimmt wird, umso mehr kommt es auf dieQualität der Software an – insbesonderewenn durch Softwarefehler die Daten- oderFunktionssicherheit oder gar menschlichesLeben gefährdet ist.

Balance zwischen Testumfangund Time-to-MarketDie größte Herausforderung für Soft-

wareentwickler ist die Ermittlung einesKom-promisses zwischen der Vollständigkeit desTestumfangs und der Time-to-Market. Vielehalten den Vorteil, als Erster mit einem Pro-dukt auf dem Markt zu sein, für wichtiger.AberQualität zugunsten vonTime-to-Marketzu opfern, ist eine riskante Entscheidung, dieeine Marke beschädigen kann.Wie lässt sich die Balance zwischen Qua-

lität undTime-to-Market quantifizieren?AlsBeispiel soll hier der normale Produkt-Le-benszyklus einer Software-Anwendung die-nen (siehe Schaubild 1). Die mit „1.0“ mar-kierte Linie im Diagramm entspricht demersten Software-Release für Kunden; dieweiteren Linien rechts davon stehen für

nachfolgende Versionen zur Behebung vonBugs bzw. mit zusätzlichen Funktionen, diebei der Vorstellung von Version 1.0 fehlten.Die mit dem Fragezeichen markierte Linieentspricht demPunkt, andemdieAnwendermit Qualität und Features des Produkts zu-frieden sind. Das Qualitäts-Defizit liegt zwi-schen dem ersten Produkt-Release und derVersion, bei der derMarkt die Produktquali-tät als gut einschätzt. DieMinimierung oderBeseitigung des Qualitäts-Defizits sollte je-den, der Software erstellt, ganz oben auf derPrioritätsliste stehen.Die zweite Herausforderung für Entwick-

lerteams ist die Zuweisungder Entwicklungs-Ressourcen für Pflichtenheft, Design, Code-erstellung und Test (siehe Schaubild 2 aufder folgenden Seite).

Erfahrung spielt beim ThemaTest eine wichtige RolleBei den meisten Entwicklungsteams hat

die Codeerstellung die höchste Priorität,während das Application Programming In-terface (API) und die Entwicklung von Test-

Schaubild 1: Die mit „1.0“markierte Linie entsprichtdem ersten Software-Release. Das Fragezeichenentspricht dem Punkt, andem die Anwender mit derQualität zufrieden sind.Dazwischen liegt das Quali-tätsdefizit. es zu minimie-ren, sollte ganz oben aufder Prioritätenlsite stehen.

Bild:Fotolia-©

Mathias

Rosenthal,Schaub

ilder:VectorS

oftware

document7276519728035750674.indd 10 05.05.2015 10:45:38

QUALITÄTSSICHERUNG // SOFTWARETESTS

fällen geringeren Stellenwert haben. Meistübernehmenerfahrenere Teammitglieder dieCode-Entwicklung, und weniger erfahreneKollegen befassen sich mit dem Test. Dabeisollte es genau anders herum sein. Diewert-vollsten Produkte einer Softwareentwick-lung sind eine umfassende und flexible APIsowie die Testfälle zumNachweis der Fehler-freiheit dieser API.

Testfälle sind wertvolleEntwicklungsprodukteEntwickeltmaneineAPI inhoherQualität

zusammenmit denTests zur Formalisierungdes richtigenAPI-Verhaltens, so könnenwe-niger erfahreneKollegendieArbeit der Code-erstellungübernehmen. Trotzdem lässt sichdenCode später ohneBedenken inBezug aufdie Qualität überarbeiten und eine deutlichhöhere Produktqualität erzielen.Die dritte Herausforderung ist, dass die

meisten Gruppen verschiedene Test-Typenpflegen, und dass jeweils eine andere Grup-pe inderOrganisation für einenbestimmtenTest verantwortlich ist. Häufig erzeugenundwartendie Entwickler Low-Level Tests,wäh-rend die Qualitätssicherungsabteilung fürdie anderen Tests verantwortlich ist.Qualitätssicherungs-Tests erfolgen imAll-

gemeinen erst nach einigen Wochen Ent-wicklungsarbeit,wennbereitsHunderte vonQuellcode-Änderungen Teil der Code-Basiswurden. Dies macht das Auffinden der ei-gentlichenFehlerursache eines fehlerhaftenTestlaufs zeitraubend und frustrierend. DieLösungdieses Problems: Testfälle solltemanalswertvolle Ressource für dieOrganisation

behandelnund sie imgesamtenTeamsowieüber den gesamten Lebenszyklus einer Ap-plikationnutzen.Auch sollteman sämtlicheTests allenTeammitgliedern zugänglichma-chen, ihrenEinsatz besonders einfachgestal-ten und sie häufig ausführen.Je nach technischer Vorgeschichte, unter-

schiedlicher Erfahrungoder verschiedensterAnforderungen nutzen Entwicklergruppeneinebreite Palette vonWerkzeugen. InKennt-nis dieser Situation hat Vector Software dieLösung VectorCAST konzipiert, um eine fle-xible Integrationmit denmeistenheute gän-gigen Entwicklungswerkzeugen auf demMarkt zu ermöglichen. Dies umfasst die Ver-waltung von Pflichtenheften und Modell-gestützte Entwicklungswerkzeuge sowieCompiler,Debugger, EmulatorenundBoards.Anwender nutzen diese Werkzeuge in tau-senden unterschiedlicher Kombinationen.

Mangelhafte Softwarequalitätgefährdet eine MarkeDas Fazit kannnur lauten: Softwarequali-

tät gewinnt angesichts der zunehmendenNutzungdes Internet derDingeundder vier-ten industriellen Revolution immermehr anBedeutung. Wer heute seine Entwicklungs-prozesse nicht anpasst, um Anwendungenin höherer Qualität zu erstellen, gefährdetnicht nur den guten Ruf seiner Marke, son-dern sogar seine eigene Existenz. Wer diesberücksichtigt, wird davon auf jeden Fallprofitieren. // FG

Vector Software+49(0)2152 8088808

Schaubild 3: Nicht alle Tests sind gleich. Häufigkümmern sich Entwickler um die Low-Level-Tests,während die Qualitätsischerung für die anderenTestarten zuständig ist. Stattdessen sollte man allenTeam-Mitgliedern alle Tests zugänglich machen.

- supports allTRACE32 ® - supports allTRACE32 ® - supports all- supports all- supports all- supports all- supports all

www.lauterbach.com/1553

Schaubild 2: Klassischer Projektkreislauf zwischenPflichtenheft, Design, Code und Test. Bei denmeisten Teams hat die Codeerstellung die höchstePriorität, während der Entwicklung von Testfällenein geringerer Stellenwert zukommt.

document7276519728035750674.indd 11 05.05.2015 10:45:42

http://www.lauterbach.com/1553

12

AUTOMOTIVE // SYSTEMDESIGN


* Chris Hobbs... ist Senior Developer für SichereSysteme bei QNX Software Systems.

Softwarekomponenten-Schutz ineinem ISO-26262-System

Die Automobil-Entwicklungsnorm ISO 26262 sieht die Isolation derSoftwarekomponenten gegen gegenseitige Beeinflussung als wichtigs-te Aufgabe an. Der Artikel zeigt Ansätze zum Komponentenschutz auf.

YI ZHENG, CHRIS HOBBS *

* Yi Zheng... ist Produktmanagerin für Safe andSecure Systems bei QNX SoftwareSystems.

ImBereich der Automechanik blicken dieHersteller auf ein ganzes Jahrhundert anErfahrungen zurück, so dass in diesem

Bereichnurnoch eine ständigeVerbesserungundRevision vonDetails erforderlich ist. Beider Bordelektronik, die Dutzende elektroni-scher Steuergeräte (ECUs) und eine Head-Unit umfasst, aufwelcher komplexe Infotain-ment-Software ausgeführt wird, stehen dieDinge ganz anders. Diese Systeme entwi-ckeln sichnicht nur sehr schnellweiter, auchdie Nachfrage der Endkunden nach neuen

Die Frage lautet also, wie sich ein Systementwickelnundvalidieren lässt, dasKompo-nenten enthält, die keine Sicherheitszertifi-zierung benötigen (etwa eine 3-D-Anzeige,auf der Consumer-Anwendungen laufen),aber auch Komponenten wie ein Totwin-kelassistenz-Modul, deren VerlässlichkeitundUnabhängigkeit von externenunerwar-teten Beeinflussungen methodisch strengentwickelt und bewiesen werdenmüssen.So ist es kein Zufall, dass die ISO 26262

Road Vehicles—Functional Safety (Straßen-fahrzeuge – Funktionale Sicherheit) alswichtigste Aufgabe die Isolation der einzel-nen Komponenten nennt.

Arten der Beeinflussung derKomponentenDie meisten nach ISO 26262 aufgebauten

Systeme enthalten verschiedene Soft-wareelemente, die gemäßunterschiedlichenASILs entwickelt wurden. Verhält sich einedieser Komponenten nicht korrekt, könnte

Digitaler Instrumentencluster imAutomobil: Die Automobil-Norm ISO26262 fordert als wichtigste Aufgabe dieIsolation der einzelnen Softwarekom-ponenten gegen die gegenseitige Beein-flussung.

Bild:Q

NX

Anwendungen und Diensten setzt die Auto-hersteller unter Druck.Die Autohersteller müssen all diese Fea-

tures liefern, ohnedass dieKostendurchdieDecke gehen. Die Notwendigkeit einerKostenoptimierung treibt die Hersteller da-zu, die inzwischen verfügbaren hochleis-tungsfähigen und kostengünstigen Prozes-soren zu nutzen und zahlreiche bordeigeneSysteme auf einer gemeinsamen Platine zukonsolidieren.Wennauchnur einModulmiteinemKostenpunkt von 50$ je Fahrzeug eli-miniert werden kann, ergibt dies bei 5 Milli-onen produzierten Fahrzeugen bereits einebeträchtliche Einsparung.Eine solche Konsolidierung birgt jedoch

neueHerausforderungen. Insbesondere sindviele Fahrzeugsysteme sicherheitsrelevant,während es sich bei anderen umConsumer-Anwendungenhandelt, für die es unmöglichist, Sicherheit nachzuweisen – doch diesehöchst unterschiedlichen Systeme müssenmöglicherweise auf derselben CPU laufen.

document4223180586823178449.indd 12 05.05.2015 13:34:43

13



dies dasVerhalten einer anderenKomponen-te beeinflussen und so die Sicherheitsanfor-derungen verletzen.Es gibt verschiedenste Arten von Beein-

flussung, je nach dem, ob die Komponentenaktiv zusammenarbeiten oder vollständigunabhängig voneinander sein sollen. EineKomponente könnte etwa: einer anderen Komponente Systemres-sourcen entziehen (Dateideskriptoren,Mutexe, Flash-Speicher); einer anderen Komponente Rechenzeitwegnehmen, so dass sie ihre Aufgabennicht mehr erfüllen kann; auf den privaten Speicher einer anderenKomponente zugreifen;Daten korrumpieren, die auch von eineranderen Komponente genutzt werden;mit einer anderen Komponente, mit dersie interagiert, einen Deadlock oder einenLivelock erzeugen; den Vertrag über die Zusammenarbeitmit einer anderen Komponente verletzen,indem sie etwa zu viele Nachrichten sen-det, Nachrichten ständig wiederholt oderNachrichten mit fehlerhaften Daten sendet.

Komplementäre Ansätze fürden Schutz vor BeeinflussungGenerell ist es das Beste,mit komplemen-

tären Techniken so viele Komponenten wiemöglich voneinander zu isolieren. Betriebssystemarchitektur — Bei einemBetriebssystem mit Microkernel laufen alleKomponenten (auch Dateisystem, Geräte-treiber, Netzwerkstack usw.) in separatenAdressräumen und sind sowohl gegen denKernel als auch gegeneinander isoliert. Adaptive Partitionierung — Bei der soge-nannten adaptiven Zeitpartitionierungwirdeiner Gruppe von Threads ein Mindestan-teil an Prozessorzeit zugewiesen, allerdingsnur dann, wenn die Threads diesen auchbenötigen. Sicherzustellen, dass Prozessenicht mangels CPU-Zeit verhungern, wirddurch adaptive Zeitpartitionierung deutlichvereinfacht. Diese Technik kann bei kom-plexen Systemen eingesetzt werden, fürdie sich RMS (ratenmonotones Scheduling)nicht eignet.Datendiversifizierung und Coded Proces-sors — Unter Datendiversifizierung verstehtman das Speichern von Daten in mehrerenunterschiedlichen Semantiken. Durch einesolche Diversifizierung steigt das Konfi-denzniveau bezüglich der Datenintegrität.Man stützt sich dabei auf die Annahme,dass ein Algorithmus zwar ein falsches Er-gebnis liefern kann, es aber unwahrschein-lich ist, dass zwei unterschiedliche Algo-rithmen dasselbe falsche Ergebnis liefern.

Erkennung von Anomalien — Schon seitLangem kommen Prädiktor-Korrektor-Me-thoden wie etwa Kalman-Filter zum Ein-satz, um Anomalien in Sensordaten zu er-kennen. Für die Erkennung von Anomalienin Systemvariablen, deren Wert nur seltenvon stochastischem Rauschen betroffen ist,eignen sich diese Methoden weniger gut. Fortschrittsüberwachung — Programmezur Überwachung des Fortschritts über-wachen Systemindikatoren und ergreifenMaßnahmen, falls das System stehen bleibtbzw. ins Stocken gerät. Häufig werden Pro-zessausfälle überwacht – die extremsteForm des Ausbleibens von Fortschritt.

Techniken zur Validierung desKomponentenschutzesAuditorenundAufsichtsbehörden verlan-

gen Nachweise dafür, dass die Grenzen zwi-schen den isolierten Komponenten nichtverletztwerden. Es gibt zahlreiche Technikenund Tools, um zu beweisen, dass diese An-forderungen erfüllt sind.Diskrete ereignisorientierte Simulation:Wenn die Korrektheit eines Algorithmus,Protokolls oder der Isolierung nicht bewie-sen werden kann –wenn beispielsweise die

PRAXISWERT

Komponententren-nung ist nicht trivialKein Ansatz kann allein eine Tren-nung zwischen Softwarekomponen-ten – wie in der ISO 26262 gefordert– verwirklichen. Zudem kann auchkein Ansatz für sich einen geeignetenNachweis der Trennung liefern.

Kombination der KräfteSetzt man jedoch einander ergänzen-de Design- und Validierungstechni-ken gemeinsam ein, dann kann dieAussage, dass eine Trennung derKomponenten vorliegt, mit hinrei-chendem Konfidenzniveau getroffenwerden. Einige dieser Ansätze benö-tigen Unterstützung durch das darun-terliegende Betriebssystem; anderelassen sich auf der Applikationsebe-ne implementieren.

document4223180586823178449.indd 13 05.05.2015 13:34:45

http://pls-mc.com/

14



Verteilung von Ereignissen nur empirischermittelt werden kann –, können diskreteereignisorientierte Simulationen (DES) einstatistisches Konfidenzniveau für die Kor-rektheit der Annahmen liefern. Formale Designprüfung: Der Zeitauf-wand für Tests lässt sich deutlich reduzie-ren, wenn sich beweisen lässt, dass einDesign korrekt ist, und aus diesem Designsodann automatisch Code generiert wird. Statische Code-Analyse: Eine Schwächevon statischer Codeanalyse besteht darin,dass sie dazu neigt, Fehler zu entdecken,die bei näherer Betrachtung gar keine sind.Außerdem ist statische Analyse bei den imEmbeeded-Bereich verwendeten Sprachen(zum Beispiel C mit seinen Zeigern) wenigeffektiv. Allerdings sind inzwischen ausge-feilte Tools für statische Analyse verfügbar,die speziell bei der Nutzung von sogenann-ten Codeverträgen sowie symbolischer Aus-führung deutlich verbessert wurden. Flow-Tagging:Mit Flow-Tagging lässt sichbeweisen, dass unter den getesteten Bedin-gungen keine unangemessene Interaktionzwischen isolierten Komponenten aufge-treten ist. Kombiniert man diese Technikmit Assert-Anweisungen, die lineare tem-porale Logikinvarianten enthalten, sindanspruchsvolle Analysen der Interaktionvon Komponenten möglich, die Aussagenbezüglich ihrer Isolation stützen können.

Vermeidung von Deadlocks undLivelocksCoffmann stellte seine vier Bedingungen,

die für einen Deadlock erfüllt sein müssen,bereits 1971 auf.Heute betrachtenwir sowohlDeadlocks als auchLivelocks als FormenvonNichtfortschritt, also als nicht erfüllte Leben-digkeitsbedingungen. Der Beweis der Kor-rektheit von Annahmen über die Lebendig-keit ist per se schwierig, weil der abzusu-chendeRaum imPrinzipunbegrenzt ist:Waskönnte das System in der Zukunft tun? Den-noch können Tools dabei helfen, Deadlocksund Livelocks in diversen Phasen der Syste-mentwicklung zu erkennen.Designphase: Tools, die Deadlocks undLivelocks in der Designphase erkennenkönnen, analysieren meist ein abstraktesModell des Systems, das die Hardware unddie Software einschließt. Einige Tools kön-nen Code aus demDesign generieren, wennseine Korrektheit bewiesen werden konnte.Wird das Design dagegen manuell imple-mentiert, besteht die Gefahr von Fehlern.Die korrekte Implementierung könnte sokompromittiert werden. Codierphase: Statische Analyse-Toolskönnen manchmal mögliche Deadlocks

erkennen. Jedoch ist dies bei Sprachen wieC schwieriger als bei komplett definiertenoder stark und statisch typisierten Spra-chen. Diese Tools führen zahlreiche Ope-rationen aus, die von der Extraktion vonSemantikinformationen aus im Code einge-betteten Verträgen (in Sprachen, die keinevertragsbasierte Programmierung unter-stützen, können diese Verträge als Kom-mentare vorliegen) bis zu symbolischerAusführung reichen – einer Kreuzung ausdynamischem Test und statischer Analyse. Laufendes System: Viele Systeme besit-zen einen Hardware-Watchdog, der regel-mäßig „angestoßen“ werden muss. Die Ent-

scheidung, welcher oder welche Prozess(e)den Wachhund anstoßen sollen, fällt je-doch schwer, weil der Watchdog für Dead-locks von Prozessen blind ist, von denen ergar nicht erwartet, dass sie ihn anstoßen.Es ist daher oft hilfreich, Bedingungen zudefinieren, die garantieren, dass Fortschritterfolgt, und einen Softwareprozess daraufanzusetzen, die Bedingung zu überwachenund im Fall von ausbleibendem FortschrittMaßnahmen einzuleiten.

// FG

QNX Software Systems+49(0)511 940910

Der Mikrokernel alsSchutzsystem: Beieinem Betriebssystemmit Mikrokernel lau-fen alle Komponenten(auch Dateisystem,Gerätetreiber, Netz-werkstack usw.) inseparaten Adressräu-men und sind sowohlgegen den Kernel alsauch gegeneinanderisoliert.

Grafiken:Q

NX

Adaptive Partitionie-rung: Einer Gruppevon Threads wirdein Mindestanteil anProzessorzeit zuge-wiesen, allerdingsnur dann, wenn dieThreads diesen auchbenötigen. Auf dieseWeise wird sicherge-stellt, dass Prozessenicht mangels CPU-Zeit verhungern.

document4223180586823178449.indd 14 05.05.2015 13:34:47

AKTUELLE PRODUKTE // EMBEDDED-WERKZEUGE UND SYSTEME

08345

Ab sofort finden Sie ELEKTRONIKPRAXISauch auf dem Smartphone. News aus derElektronikbranche, Produktinformationenund Bildergalerien – immer aktuell, 24/7verfügbar.

---> mobil.elektronikpraxis.de

www.vogel.de

Für unterwegs

Scannen &

direkt verbunden

werden

Mitmacchina.io hat der österrei-chische Softwarespezialist Ap-plied Informatics eine Entwick-lungsplattform für das Internetof Things (IoT) auf den Marktgebracht. Die auf Open-Source-Techniken aufgebaute Lösungbildet die Basis für die rascheApplikations-Entwicklung fürsogenannte IoT-Gateways.IoT-Gateways fungieren als

Übersetzer zwischen Sensoren,Geräten und Anlagen auf der ei-nen sowie Unternehmensappli-kationen und Cloud-Diensten

OPEN-SOURCE-PLATTFORM

Baukasten für das IoTauf der anderen Seite. Auf dieseWeise ermöglichen sie eineKom-munikation der Dinge unterein-ander.Als flexible, skalierbare Platt-

form mit offenen Schnittstellenund Baukastensystem mit zahl-reichen zuschaltbaren Einzel-komponenten lässt sichmacchi-na.io in bestehende IT-Infra-strukturen integrieren und indi-viduell anpassen.Macchina.io eignet sichdamit

sowohl für große Unternehmenals auch als schlankes Systemzum IoT-Einstieg für Kleinunter-nehmenundkreative Entwickler.Die Entwicklungsplattform ist inder Grundversion kostenlosdownloadbar. Zusätzliche Fea-tures sowie Support-Servicessind in der Pro-Version desFrameworks erhältlich.

Applied Informatics

Green Hills Software hat die Un-terstützung der MIPS-Prozesso-ren von Imagination erweitert.Dazu zählt optimierter Supportfür die Code-Kompressions-Be-fehlssatzarchitekturmicroMIPS.Die langjährige Zusammenarbeitzwischen den beiden Unterneh-men ist die Basis für denSupportneuer und zukünftigerMIPSCPUCores undArchitekturen. Im lau-fenden Jahr wird der kaliforni-sche Softwarespezialist die64-Bit-Cores der Familie MIPSI6400 unterstützen.

ENTWICKLUNGSWERKZEUGE

Erweiterter Support für MIPSDie Prozessoren dieser Reihe

werden in denMärktenMassen-speicher, Netzwerktechnik, digi-tale Unterhaltungselektronikund Consumer-Elektronik zumEinsatz kommen. Auch in ande-ren Bereichen, die hohe Zuver-lässigkeit und produktive Toolserfordern, ist ein Einsatz dieserCores möglich.Der Support von Green Hills

Softwareumfasst eineReihe vonTools, darunter der C/C++-Com-piler, die Assembler und Linker,die Binary Toolchain, die integ-rierte EntwicklungsumgebungMulti, die Analysesonden GreenHills Probe und SuperTrace Pro-be sowie dieDokumentation.Diesicherheitszertifizierten Toolsdienen zum Erstellen von Soft-ware, die auf zuverlässigenkriti-schen Systemen läuft.

Green Hills Software

document113944862158814051.indd 15 05.05.2015 13:36:51

http://www.vogel.de

http://mobil.elektronikpraxis.de/

http://www.mentor.com/solutions/automotive/

16

IMPLEMENTIERUNG // CYBER-PHYSIKALISCHE SYSTEME


Entwicklungsbeschleuniger:Zeit als neue Währung (Teil 2)

LabVIEW im Serienprodukt: Echtzeit-Linuxund C-Generator ermöglichen Echtzeit-Software

auf eigener Embedded-Hardware.

MARCO SCHMID *

* Marco Schmid... ist Diplom-Ingenieur (FH) fürSystemtechnik. Er ist Inhaber desLösungsanbieters Schmid Elektronikin Münchwilen/Schweiz.

Ob intelligenter Sensor am IoT, Mess-netzwerk, Cloud-Lösung oder Reglermit Tablet – der Anwendungsent-

wickler hat dankdemAktor-FrameworkLab-VIEWmit flexiblenRechenmodellen schnellErgebnisse erzielt und die Machbarkeit sei-ner Idee im Labor geprüft. Nun soll das Seri-enprodukt geplant werden – mit Hardware,die auf die Bedürfnisse des Endanwenderszugeschnitten ist. In der Praxis bedeutet diesmeist eine Neuentwicklung von Hard- undSoftware auf der Basis von C mit RTOS aufeinemMikrocontroller. Es geht auchanders!Der hier vorgestellteAnsatz ermöglicht nichtnur die Wiederverwendung bisheriger Soft-ware-Investitionen, sondern gibt dem Ent-wickler zusätzlichdie Freiheit, Hardwareent-scheidungen hinauszuzögern. Genau dieswar beimMessnetzwerk im Zug, beim Solar-kraftwerk und der aktiven Schallbekämp-fung aus Teil 1 diewichtigsteVoraussetzung.Dieser zweite Teil führt jetzt durch die Mög-

lichkeiten von LabVIEW auf Embedded-Boardlevel-Hardware und diskutiert, wiedieser Leitfaden bei zwei Praxisbeispielenangewendet wurde.Was LabVIEW für smarte Embedded-Sys-

teme so interessantmacht, sind erstens seinemächtigenBibliotheken fürMathematik undSignalverarbeitung und zweitens die kom-fortable Abstraktion von Timing, Betriebs-system, Multitasking, Multicore und Zugriffauf unterlegte Hardware. Die Anwendunglässt sich mit wenigen DetailkenntnissenzumUnterbauperKnopfdruck auf die eigeneEmbedded-Hardware ladenunddort in Echt-zeit im 24/7-Betrieb ausführen.WelcheHardware eignet sich nun ambes-

ten?DasGemeinsamealler inBild 1 gezeigtenHardwareplattformen ist die grafische Pro-grammierbarkeit mit LabVIEW. RelevanteUnterschiede zeigen sich imFormfaktor, derLeistungsfähigkeit der CPU und der Unter-stützungdurchdieBibliotheken. Grundsätz-lichunterscheiden sich Singleboard-Compu-ter (Bild 1 rechts) und Einsteckmodule (Bild1 links). Die Wahl hängt unter anderem da-vonab, ob imProjektHardwareentwicklungeingeplant ist. Wenn nicht, bleibt der Sing-leboard-Computer übrig. Sonst bietet sich

vomZweiplatinenansatzmit Einsteckmodulim Baseboard bis zur Kompletthardware(Bild 2) die volle Hardware-Bandbreite an.Ausschlaggebend sind jedochdie eigenen

Anforderungen an die geplante Anwen-dungssoftware (Tabelle 1) und deren BedarfanFunktionalität, RechenleistungundSpei-cher. Es gibt nämlich zwei Wege von Lab-VIEW zur Embedded-Hardware. Der ersteführt über Echtzeit-Linux auf dieDual-Core-ARM9-Architektur mit FPGA. Das SOM-Ein-steckmodul (Bild 3) und die Single-Board-RIO-Familie (Bild 1, Mitte) von National Ins-truments (NI) funktionieren nach diesemSchema. Die anderenModule auf Bild 1 undKompletthardware (Bild 2) folgen dem Wegüber den universellen NI-ANSI-C-Code-Ge-nerator mit Mikrokernel. Damit ließe sichLabVIEWauf einenbeliebigen 32-Bit-Prozes-sor portieren. Softwarefunktionalität undLeistung sind eingeschränkt. Dafür punktetdieser Ansatz bei anderen Aspekten wieBoot-Zeiten unter einer Sekunde, Low-Cost,Low-Power und Lizenzfertigung (Tabelle 1).

Einfach nutzbare Singleboard-ComputerDer Vorteil von Singleboard-Computern

(SBC's) liegt auf der Hand: sie sind sofortbetriebsbereit! DieApplikationsentwicklungkann ohne weitere Vorarbeit beginnen. Dasmacht SBC's interessant für Machbarkeits-studien, RapidPrototypingundKleinserien.Die CPU-Leistungsklassen skalieren vom500MHzFixed-Point-DSPbis zum667MHzFloa-ting-Point-Dual-Core-ARM9 mit FPGA aufFormfaktoren vom Hutschienen- über dasPC-104- bis zum Europaformat (Bild 1,rechts). DieHardware bietet alles,was smar-te Embedded-Systemeheute verlangen: vomAnalog- undDigital-I/Oüber Standard-Kom-munikationskanäle undEmbedded-Filesys-temenbis zumMulti-Touch-TFT. In LabVIEWsteht für jedeHardwarefunktion einVirtuel-les Instrument (VI=Funktionsblock/Treiber)zur Verfügung.

Bild 1: LabVIEW auf eigener Standard-Hardware in unterschiedlichen Formfaktoren und Leistungsklassen.Links: Einsteckmodule als Briefmarken-Coremodul, Scheckkarten-COM oder -SOM. Rechts: Singleboard-Computer als Europakarte, im PC104-Format oder auf der Hutschiene.

Bild:SchmidElektro

nik

document4401685196523557034.indd 16 05.05.2015 13:28:27



EinMix aus einemStandardmodul, das inein kundenspezifisches Baseboard einge-steckt wird, kombiniert die Vorteile vomSingleboard-Computer mit Kompletthard-ware. Die Komplexität der Baseboards istdeutlich geringer als bei Mikroprozessor-Kompletthardware, denn die kritischenSchaltungsteile um CPU und Memory sindschonauf demEinsteckmodul realisiert. Au-ßerdemersetzendieHersteller imProzessor-bereich abgekündigte Bauteile nach Form-Fit-Function.Vonder Funktionalität her bietet der Zwei-

platinenansatz Ähnliches wie bei Single-board-Computern, lässt sich im Vergleichaber beliebig erweitern. Der Vorteil dabei istein nahtloses Anpassen von Hardware inFormund Funktion an jede beliebige Aufga-benstellung. Außerdem müssen zu Beginnder Entwicklung, beispielsweise beimRapidPrototyping, nochnicht alle Anforderungenin Stein gemeißelt sein, denn Baseboards

lassen sich schnell ändern.Diese Flexibilitäthat jedoch auch ihren Preis: im VergleichzumSingleboard-Computermuss beimZwei-platinenansatz immer zuerst Hardware inForm eines Baseboards entwickelt werden.Je nach Anforderungwählt der Designer ein

Bild2 : Bei Kompletthardware (rechts oben) werdenEinsteckmodul und individuelles Baseboard (linksunten) „verheiratet“. Voraussetzung dazu ist einC-Generator mit Mikrokernel.

Bild:SchmidElektro

nik

ANFORDERUNG/FUNKTIONALITÄT SoMEchtzeit-Linux aufMulticore ARM9/FPGA

ZBrainC-Generator auf 32-BitMikrocontroller

Sound & Vibration-, Vision- oder Motion-Toolbox

Data Dashboard (Tablet, Smartphone),Database, Cloud

Gigabit Ethernet, Realtime-TCP/IP, EtherCAT,Feldbusse

Multicore, FPGA

Hohe DAQ-Abtastraten, Rechenleistung,Speicher

LabVIEW-Support, Code-Portabilität,LabVIEW-Architekturen

Komplexe Floating-Point-Algorithmen,Lineare Algebra

μs-Echtzeit, Multitasking

Kommunikation (CANOpen, Webserver,Wireless, Serial)

Flexibilität Hardware-Formfaktor,Miniaturisierung

Bedienung über integriertesCAP-Multitouch

Einfache MSR-Aufgaben

Kostenempfindliche Serienprodukte(< 100 Euro)

Stromverbrauch bis mW, Handhelds,Batteriebetrieb

Bootzeit < 1 Sekunde

Fullcustom-Hardware, Eigenfertigung

Tabelle 1: Die linke Spalte zeigt, was Echtzeit-Linux mit Multi-Core-ARM9/FPGA auf Hardware von NationalInstruments bieten kann. Die Lösung der rechten Spalte mit C-Generator und Mikrokernel auf 32-Bit-MCUvom NI-Allianzpartner Schmid Elektronik vervollständigt die LabVIEW-Möglichkeiten.

Quelle:SchmidElektro

nik

www.elektronikpraxis.de/newsletter

Tages-Newsletterdie Nachrichten derletzten 24 Stunden

0728

3_01

Jetzt

anmelden

Die Fachbücher für Ihre Aus- undWeiterbildung im technischen Beruf.E-Mail: [email protected]: 0931 418-2419

www.vogel-buchverlag.de

1001

2

280 Seiten,zahlr. Bilder,1. Aufl. 2014,ISBN 978-3-8343-3294-3,29,80 €

Reim, Kurt

LabVIEW-KursGrundlagen, Aufgaben,Lösungen

Der Weg zumLabVIEW-Könner

Der Lab-VIEW-Kurs erleichtertallen Einsteigern die erstenSchritte mit der mächtigen Ent-wicklungsumgebung für mess-,steuer- und regelungstechnischeAnwendungen.Mit der Studentenversion NI Lab-VIEW 2013 ein perfektes Paket.

Mit Studentenver

sion

2013 auf CD-RO

M

28za1.IS8329

Der Lab-VIEW-Kurs er

Mit

CelsiStrip®

Thermoetiketteregistriert Maximalwertedurch Dauerschwärzung.

Bereich von +40 ... +260°C

GRATIS Musterset

von [email protected]

Kostenloser Versand ab

Bestellwert EUR 200

(verzollt, exkl. MwSt)

www.spirig.com

document4401685196523557034.indd 17 05.05.2015 13:28:30


http://www.spirig.com


http://www.vogel-buchverlag.de

http://www.elektronikpraxis.de/newsletter

18



Briefmarken-Coremodul, ein Scheckkarten-COM oder ein SOM (Bild 3).Sind nach dem Prototyping alle Anforde-

rungenbekannt, lassen sichdie Einsteckmo-dule mit dem Baseboard verbinden. Das Er-gebnis ist ein kundenspezifisches, komplettintegriertes Mikroprozessorboard (Bild 2),das inmittleren und großen Stückzahlen zuüblichenBestückpreisenhergestelltwerdenkann. Seine spezifische LabVIEW-Hardwarekann der Kunde bei Schmid Elektronik ent-wickeln, produzierenund testen lassenoderdies in Lizenz selber tun.

C-Code-Generator aufeigener Hardware betreibenIn der Embedded-Welt ist die SpracheCder

Quasi-Standard. Genau hier setzt NIs ANSI-C-Code-Generator an. Er übersetzt ein grafi-sches LabVIEW-Diagramm/-Blockschaltbildinklusive Mathematik- und Signalverarbei-tungs-VIs in neutralen ANSI-C-Code für32-Bit-Mikrocontroller. Schmid Elektronikkombiniert diese Technikmit der Funktiona-lität der Singleboard-Computer im Hutschi-enen- und PC104-Format (Bild 1, rechts) so-wie Briefmarken-Coremodulen und Scheck-karten-COMs (Bild 1, links).Der so erzeugte C-Code wird mit dem

Quellcode eines schlankenMikrokernels ver-linkt, mit gängigen Tools (Compiler, Linker,Loader) in eine echtzeitfähige Standalone-Firmware gebaut und als Loader-File auf dieZielhardware geladen. Von dort bootet dieAnwendung in weniger als einer Sekunde,geht in einen robusten 24/7-Echtzeit-Betriebüber und ist gegenEinflüsse vonaußenweit-gehend unempfindlich.DasNI System-On-Module (Bild 3) unddie

NI Single-Board-Computer (Bild 1, Mitte)werden per Echtzeit-Linux betrieben. Da-durch eröffnen sich speziell für vernetzte,smarte Embedded-SystemeneueMöglichkei-ten. Installiert ist die für den Embedded-Bereich ausgelegte Ångström-Distributionmit einem Repository auf den Servern vonNI. Das LabVIEW-Diagrammwird nach demPOSIX-Standard auf das Linux-Betriebssys-

tem abgebildet. Dort lässt sich mit dem Pa-ckage-Manager opkg die Spielwiese des Li-nux-Ökosystems nutzen – ob SQL-Daten-bank, Apache-Webserver oder QT-GUI. AlsBootloader dient U-Boot.Weitere Merkmale von Echtzeit-Linux:

Mit der Busybox steht ein Tool für typi-sche Embedded-Aufgaben zur Verfügung,von Filesystemzugriffen, Abholen der Sys-temzeit und kleinem DHCP-Client bis zumSleep-Modus und System-Reboot. LabVIEW erhält Zugriff auf die Linux-Kommandozeile, womit sich Systembefehledirekt ausführen und so Filesystem- undUser-Berechtigungen live steuern lassen.Mit Technikenwie Python stehenmächti-ge Skriptsprachen zur Verfügung. LabVIEW kann mit TCP/IP über local-host die Dienste weiterer Linux-Prozesse(Daemons) anzapfen.Über das native C-API von LabVIEW kannauf Bibliotheken des Linux-Betriebssys-tems zugegriffen werden (Bild 4).Der versierte Linux-User kann den Linux-Kernel jederzeit individuell konfigurierenund neu kompilieren.Bei vernetzten Embedded-Systems ist Ti-

ming die Herausforderung Nr.1. Hier leistetLinux mit nützlichen Schemas Unterstüt-zung. Mit cron lassen sich bis [min]-Auflö-sung repetitive Tasks wie das Löschen von

Logfiles ausführen. Der «CFS» (CompletelyFair Scheduler) dient vor allem zum Imple-mentierennicht-zeitkritischer, aber trotzdemeffizienter Work-Tasks. Werden Antwortzei-ten in [ms] benötigt, wird der Kernel «pre-emptive» konfiguriert. DankMulticore-Sup-port von LabVIEW lassen sich grafischeTasks direkt einemProzessorkern zuordnen.Bei zeitkritischen Tasks mit gefordertem Jit-ter zwischen 10...100 µs kommt der PRE-EMPT_RT-Patch ins Spiel. Harte Echtzeit imeinstelligen [µs]- oder sogar [ns]-Bereichgarantiert der FPGA.

Messnetzwerk im Hochge-schwindigkeitszugBei der flächendeckendenMessintelligenz

im Hochgeschwindigkeitszug (Teil 1) wurdenach dem Prototyping mit einem Single-Board-RIO das System-On-Module des TypssbRIO-9651 von National Instruments alsCAN-Master gewählt (Bild 3). Neben der ge-forderten hohen Rechenleistung war dieflexible und sichere Netzwerkfähigkeit zumLeitrechner dank Linux ausschlaggebend.Über einfache CAN-Befehle steuert derMas-ter bis zu 256 Knoten. Diese sind je nach TypundAufgabe als Briefmarkenrechner (Bild 1,links) auf Baseboard oderKompletthardware(Bild 2) ausgeführt. EinNetzwerkmit 32Kno-tenwurde schon erfolgreich imFeld getestet.

System-On-Module in der„Sonnenblume“Beim zweiten Beispiel aus Teil 1 handelte

es sich um ein kompaktes Solarkraftwerk,das dank Solarkonzentration effizienter ar-beitet als bisherige Anlagen. Das High Con-centration Photovoltaic Thermal (HCPVT)-System wird „Sonnenblume“ genannt. DasHerzstückder zehnMeter hohenStruktur isteine 40 qm große Parabolschüssel, die einTrackingsystem kontinuierlich zur Sonneausrichtet. Basis dazu sind ein Sonnensensorund zwei bürstenlose DC-Motoren, die alsdezentrale Intelligenz über CAN mit demEmbedded-System verbunden sind. DessenHirn ist das System-On-Module „sbRIO-9651“vonNI (Bild 3). Es ist über dasBaseboardunddezentrale Knoten mit Dutzenden von Sen-soren verbunden, vom Temperatur-, Druck-und Feuchtesensor bis zur Meteostation.Höchste Zuverlässigkeit spielt in der Hard-und Software eine zentrale Rolle. So drehtsich die Schüssel beim Ausfall kritischerKomponenten oder bei Extremwetter immerin eine Sicherheitsposition und hält einenkonstanten Innendruck aufrecht. // FG

Schmid Elektronik+41(0)71 9693590

Bild 4: LabVIEW greift über sein C-API (Application Programming Interface, rechts) auf eine in Eclipse gene-rierte Linux-Bibliothek zu (*.so = Shared Object, links)

Bild:SchmidElektro

nik

Bild 3: LabVIEW programmierbares «System-on-Module» (SOM) mit Echtzeit-Linux auf MulticoreARM-Cortex-A9 und FPGA. Low-Level-Treiber werdenmit Eclipse entwickelt und in LabVIEW eingebunden.Die Administration erfolgt z.B. über die SSH (SecureShell).

Bild:SchmidElektro

nik

document4401685196523557034.indd 18 05.05.2015 13:28:33

Hauptsponsoren 2015 Veranstalter

201530. November bis 4. Dezember 2015

in Sindelfingen

Alle Informationen unter: www.ese-kongress.deJetzt als Referent bewerben und kostenlos zum Kongress!Gestalten Sie Deutschlands größten Kongress für Embedded Software Engineering aktiv mit!Es gibt viele gute Gründe, warum Sie sich mit Ihrem eigenen Vortrag am Programm beteiligen sollten.Diskutieren Sie Ihr Knowhow und Ihre Erfahrung mit einem hochwertigen Fachpublikum.Machen Sie sich als Software-Experte einen Namen. Für Hauptreferenten ist die Teilnahme an dendrei Kongresstagen kostenlos. Wir freuen uns auf Ihren Vorschlag!

Aussteller 2015:AFRA, ARCCORE, ARM, Axivion, bbv Software Services, Corscience, dSPACE, Eclipseina, ELEKTRONIKPRAXIS,emlix, emtrion, enders Ingenieure, EVOCEAN, Express Logic, Flexera Software, froglogic, Hitex, IAR Systems,IMACS, Infineon Technologies, iSyst Intelligente Systeme, iSYSTEM, Lauterbach, LieberLieber Software,linutronix, Logic Technology, MicroConsult, MicroSys, Model Engineering Solutions, National Instruments,Noser Engineering, oose Innovative Informatik, PLS Programmierbare Logik & Systeme, Protos, QA Systems,QNX Software Systems, Razorcat Development, Renesas Electronics, RST Industrie Automation,RTI Real-Time Innovations, Security & Quality Software, sepp.med, SMDS/ Universität Augsburg,Software Quality Lab, Somnium Technologies, Tasking, Vector Software, Verifysoft Technology,Willert Software Tools, XiSys Software

„Wissen ist das einzige Gut,das sich vermehrt,wenn man es teilt.“

(Marie Freifrau von Ebner-Eschenbach, österreichische Schriftstellerin)

Call for Papers noch bis 30. Mai

unter www.ese-kongress.de

ESE_Anzeige_2015-A4.indd 1ESE_Anzeige_2015-A4.indd 1 23.04.2015 13:46:4223.04.2015 13:46:42

http://www.ese-kongress.de



20

IMPLEMENTIERUNG // KYBERNETIK UND SIMULATION


Nichtlineare Feedbackregelung fürdie DARPA Robotics Challenge

Die DARPA Robotics Challenge dient zur Forschung an Robotern an, dieeigenständig in Gefahrenbereichen arbeiten. Dieser Bericht zeigt, wie

ein Team des MIT den Wettbewerb meisterte.

RUSS TEDRAKE *

* Russ Tedrake... ist Dozent in den Fächern Elektrotechnik, Infor-matik, Luft- und Raumfahrt am MIT. Tedrake leitetdort das Robotiklabor für Informatik und KünstlicheIntelligenz.

ImDezember 2013 brach ein humanoiderRoboter durch eine Wand, räumte eineTür frei, rollte einen Feuerwehrschlauch

ab, schloss ihn an und fuhr auf dem Home-stead-Miami Speedway ein Nutzfahrzeugdurch einen Hindernisparcours.Die Regelungsalgorithmen des Roboters

wurden von einemTeamdesMassachusettsInstitute of Technology, das an der DARPARobotics Challenge (DRC) teilnahm, mitMATLAB und Simulink entwickelt. DieserWettbewerb soll die Forschung an Roboternanregen, die in Gefahrenbereichen eigen-ständig arbeiten können.Autonomarbeiten-de Roboter können angewiesen werden,einfache Aufgaben eigenständig zu erledi-gen, wie etwa ein Lenkrad zu drehen odereinen Griff zu fassen.Zwischen dem Erhalt des Roboters und

demWettkampftag bliebendemTeamweni-ger als fünf Monate Zeit, die Regelungsalgo-rithmen zu entwickeln, zu debuggen und zutesten.MATLABundSimulink halfen dabei,diesen engen Zeitplan einzuhalten, denn sokonnte das Team anspruchsvolle, optimie-rungsbasierte Regelungsalgorithmen zügigererstellen, als dasmit C odermaschinennah-en Sprachenmöglich gewesen wäre.

Einen Roboter mit Eleganz undEffizienz bewegenDieArbeit für denDRCwar eineWeiterfüh-

rung der Forschungsaufgabe, Robotern ele-gantere Bewegungen in der echten Welt zuermöglichen. Das Ziel ist es, sowohl Laufro-boter zu entwerfen, die sich so gewandt wieBallerinas bewegen, als auch unbemannteLuftfahrzeuge, diewieVögel fliegen. Bei die-sen Fragestellungen handelt es sich umgrundlegende Probleme der Robotik. Diesezwingen Forscher, schwierige nichtlineare

Regelungsprobleme zu lösen, die in vielenanderen Bereichen Anwendung finden.Ein Vogel beispielsweise überflügelt ganz

nebenbei einige der besten Regelungssyste-me, die je vonMenschen entworfenwurden.Wenn sich ein Vogel auf einen Ast setzt, be-wegt er seine Flügel und seinen Körper so,dass sie fast senkrecht zur Flugrichtungundder anströmendenLuft stehen.DiesesManö-ver steigert den Luftwiderstand des Vogelsdurch die Vergrößerung der dem Luftstromausgesetzten Oberfläche und durch die Er-zeugung einesNiederdruckluftbereichshin-ter dem Flügel (Bild 1).Für das gewünschte schnelle Abbremsen

werdenViskosität undDruckkraft gekoppelt.Das Manöver hat erhebliche Folgen: An denFlügeln kommt es zu einem Strömungsab-riss, was bedeutet, dass es zu einem drama-

tischenAuftriebsverlust undmöglicherweiseauch zum Kontrollverlust kommt. Die Aero-dynamikwird instabil (zeitlich veränderlich)undnicht-linear,wodurch es schwierigwird,die aerodynamischen Kräfte zumodellierenund genau vorherzusagen. Und doch setzenVögel sich scheinbar mühelos auf Äste. He-likopter undFlugzeuge, die senkrecht startenund landenkönnen, benötigen imVergleichdazugeraumeZeit undEnergie, umaneinembestimmten Punkt zu landen. Ebenso sindwohl nur wenige Piloten bereit, zwischenWolkenkratzern hindurchzufliegen; Eulenund Falken jedoch navigieren mit Leichtig-keit durch dichtenWald.Regelungssysteme, die solche Leistungen

nachahmen, müssen anspruchsvolle logi-sche Entscheidungen darüber treffen, wieder Roboter sichbewegt undwohin.Obwohl

Bild 1: Oben: Luftstrom über den Flügel bei zunehmendem Flügelwinkel. Unten: Veranschaulichung desFlügelluftstroms eines Gleitseglers bei steilem Strömungsabriss.

Bild:M

athW

orks

document995303287064272804.indd 20 05.05.2015 13:41:00



die Gleichungen, die die Systemkinematikund -dynamik beschreiben, nicht-linearsind, haben sie doch eine verwertbare Struk-tur. Viele können zum Beispiel in Form vonrationalen Polynomgleichungen beschrie-benwerden. Dadurch könnenwir leistungs-starke Algorithmen schreiben, die zur Beur-teilungder Systemstabilität bei einer großenVielfalt vonEinsatzbedingungennumerischealgebraische Geometrie und konvexe Opti-mierung verwenden.Um einen kleinen Gleitsegler auf einem

Draht zu landen, implementierten die For-schermitMATLABundSimulink einenStan-dardansatz zur Flugbahnoptimierung undeinen linearen zeitlich-veränderbaren Reg-ler. Mit diesem Ansatz erhielten sie Regler,die das Flugzeugdurchgehend landenkonn-ten, so lange es vom gleichen Ort mit dergleichen Geschwindigkeit gestartet wurde.Durch eine rasche Evaluierung der System-stabilität mithilfe des polynomialen Ansat-zes, der als Stabilitätstrichter (Bild 2) darge-stellt wird, entwarfen sie eine Reglerschar,die das Flugzeug aus einer Reihe verschiede-ner Ausgangsbedingungen verlässlich lan-dete. Damit kann das Flugzeug von jederPosition aus in RichtungdesDrahtes gestar-tet werden, und es gelangt immer an seinZiel.

Just-in-Time-Kompilierung undEchtzeit-SzenarienAls das TeamdieArbeit für dieDARPARo-

bot Challenge begann, stellten manche Kol-legendenEinsatz einer interpretierten Spra-chewieMATLAB in einer Echtzeit-Feedback-Regelungsschleife in Frage. Sie hatten Be-denken, dass die Algorithmen nicht schnellgenug ausgeführt würden und dass Unter-brechungen durch Just-in-time-Kompilie-rung, Speicherbereinigung oder Hinter-grundprozesse zu Jitter führen und die Zeit-planung beeinflussen könnten.

Nach sorgfältiger Prüfung dieser Aspektestellte das Team fest, dass die MATLAB-Al-gorithmen auf einem PC mit 300 Hz odermehr ausgeführt werden können und dassdie zeitlicheGenauigkeit denAnforderungenunseres Regelungsansatzes entsprach. Au-ßerdem war bekannt, dass bei Bedarf C++-Code zur Beschleunigung kritischer oderlangsamer Komponenten in den Simulatio-nen verwendet werden konnte. Obwohl hö-here Samplingraten und verlässlicheres Ti-mingdenEntwurf vonRegelungenvereinfa-chen, galt es, Regler mit ausreichender Ro-bustheit zu entwerfen, um niedrigere Ratenundweniger genaues Timing verarbeiten zukönnen.DasmenschlicheNervensystemver-arbeitet komplexe Bewegungen mit relativgeringer Bandbreite und hohen Latenzzei-ten.DasBemühender Forscher ist es, Reglerzu entwickeln, die genaudas leisten können.DieVorteile derVerwendungvonMATLAB

und Simulink wurden mit fortschreitenderEntwicklung offensichtlich, zum Beispiel:MATLAB eignet sich ausgezeichnet zurschnellen Algorithmen-Prototypentwick-lung für lineare Algebra.Die meisten kommerziellen Optimie-rungs-Solver, die das Team benutzt, verfü-gen über eine MATLAB-Schnittstelle.MATLAB und Simulink bieten zahlreicheMethoden zur Visualisierung von Daten,Simulationsergebnissen und der Bewegungvirtueller Roboter. Simulink ermöglicht die Entwicklung an-spruchsvoller Modelle, die Integration vonMATLAB-Klassen als S-Funktionen, die An-wendung von ODE-Solvern und die Simu-lation von Hybridsystemen und Systemen,die diskontinuierliche und kontinuierlicheKomponenten kombinieren. Viele der Studenten im DRC-Team hattenMATLAB im Grund- oder Aufbaustudiumbei Regelungen, Kommunikationssystemenund Signalverarbeitung verwendet.

Bild 2: TrichterförmigerBereich, von dem ausder Gleitsegler verläss-lich sein Ziel erreicht.

Quelle:M

athW

orks

Was Geschäftsführer über Embedded-Software wissen solltenReferent: Professor Dr. Jochen Ludewig,Universität Stuttgart

Die Zukunft des Embedded SoftwareEngineeringReferent: Prof. Dr.-Ing. Peter Liggesmeyer,Fraunhofer IESE

Geschäftsmodelle IoT – erfolgreich imInternet der DingeReferent: Alois Schwarz,Flexera Software

8. Juli 2015 · Würzburg · Vogel Convention Center VCC

arz,

JETZTANMELDEN

PROGRAMMHIGHLIGHTS:

Eine Veranstaltung von:

Hauptsponsor:

Themensponsoren:

10680

www.ese-summit.de

Axivion GmbHemlix GmbHHitex GmbH

WIBU-SYSTEMS AGWillert Software Tools GmbH

document995303287064272804.indd 21 05.05.2015 13:41:03

http://www.ese-summit.de

22



Die Teams, die nicht mit einem eigenenRoboter am DRC-Wettbewerb teilnehmenkonnten, wurden zur Teilnahme an der Vir-tual Robotics Challenge eingeladen. Dabeiwurde unter die Lupe genommen, wie dieSoftwareteams einen simuliertenRoboter beiderAusführungdreierAufgaben in einer vir-tuellenUmgebung regelten. SiebenFinalteil-nehmer dieser Runde rückten dann in dieDRC-Probeläufe auf und konntenmit einemvonDARPAzurVerfügunggestelltenATLAS-Roboter arbeiten. ATLAS ist einhumanoiderRoboter mit Hydraulikantrieb, der von Bos-ton Dynamics entwickelt wurde.

Lenken eines simuliertenRoboters in virtuellem UmfeldDie zu erfüllenden drei Aufgaben waren

ziemlich komplexund standen in engemZu-sammenhangmit den achtAufgaben, die derechteRoboter später imWettbewerb erfüllenmusste. Der Roboter musste etwa über un-ebenes, schwierigesGelände laufenundmiteinem Feuerwehrschlauch umgehen.Für denDRC-Wettbewerbmusstenwir da-

für sorgen, dass Ganzkörperbewegungspla-nung und Regelungsalgorithmen für ATLASschnell genug ausgeführt wurden, um inEchtzeit laufen zu können. Beim Betrieb ineiner unbekannten Umgebung wurde derRoboter angewiesen, eineAufgabe auszufüh-ren. Die Regelungmusste die Bewegung desgesamtenRoboters unmittelbar planen.Daswurde in MATLAB durch die Nutzung desWissens über die Struktur des Roboters unddie zu seiner Beschreibung verwendetenGleichungen erreicht. Über mechanischeSysteme wie Atlas ist bekannt, dass Energieerhalten wird, die Massenmatrix positiv istund dass die Dynamik des Massenschwer-punktes durch den Einfluss der SchwerkraftundderKontaktkräfte zwischendemRoboterundderUmgebung eindeutig bestimmtwird.DieGleichungenhabenwichtige Strukturbe-sonderheiten: Die Dynamik der rechtenHand ist mit der Dynamik des linken Fußesnur über die Massenmatrix verbunden.VomAuftaktmeetingbis zumeigentlichen

Wettbewerbhatte das TeamachtMonate Zeit.Der knappe Zeitplan forderte eine rascheEntwicklung. In MATLAB konnten die Teil-nehmer schnell komplexe Regelungsideenund Prototypen entwickeln und visuell de-buggen. Das war wichtiger, als zwei oderauch 20Prozent schnellerenCode zuhaben.ZweiMonate, nachdemdasTeamals einer

der sieben Gewinner der Virtual RoboticsChallenge feststand, erhielt es einenATLAS-Roboter.Erneut machte die knapp bemessene Zeit

schnelle Entwicklung unerlässlich. In der

zweiten Wettbewerbsphase waren nur fünfMonate Zeit, um den ATLAS-Roboter so zuprogrammieren, dass er acht Aufgaben aus-führen konnte. Dazu gehörten Laufen aufunebenem Untergrund, Erklimmen einerLeiter, Freiräumen einer Tür, Durchbrecheneiner Wand, Aufdrehen eines Ventils, An-schließen eines Feuerwehrschlauchs undFahren einesNutzfahrzeugs.Menschendurf-ten den Roboter zwar lenken, allerdings nurüber einenKommunikationskanalmit nied-riger Bandbreite, wodurch eine gewisse Ei-genständigkeit unbedingt erforderlich war.DieMöglichkeit, Algorithmen schnell um-

zusetzen und zu debuggen, erwies sich alsentscheidenddafür, eineRegelung zu erstel-len, die ATLAS durch derart komplexe Auf-gaben führenkann.Außerdemwardie Tool-box Drake, die das Team zur Analyse derRoboterdynamik und für den Entwurf derSteuerungen in MATLAB gebaut hatte, einwesentlicher Erfolgsfaktor. Die Toolbox un-terstützt Flugbahn- und Bewegungsfeed-backplanung,mehrereHardwareschnittstel-len undMethoden zur Visualisierung, Iden-tifizierung und Schätzung. Drake ist Open-

Source-Software und steht nun zumDownload zur Verfügung.UmdieBewegungenvonATLAS zuplanen

und andere Aufgabenstellungen währenddes Wettbewerbs zu erfüllen, liefen auf PCsfünf oder sechs voneinander getrennteMATLAB- undSimulink-Prozesse. Diese Pro-zesse kommunizierten mit dem ATLAS-Ro-boter überUDPunterVerwendungvonLight-weight Communications and Marshalling(LCM). Dabei handelt es sich um eine Reihevon Programmbibliotheken, die entworfenwurden, ummit Echtzeitsystemen zu arbei-ten, dieDatenmarshallingundMessagePas-sing benötigen.Bei zweiAufgabenkamderWert der durch

MATLABundSimulink erreichtenEigenstän-digkeit besonders zur Geltung. Als der AT-LAS-Roboter eine Tür räumte, fiel ein ebenvon ihmzur Seite geräumtesBrett über seineFüße. ATLAS meistert viele Aufgaben, aberdie Kinematik des Roboters machte das Be-rühren seiner Zehenspitzen zu einer großenHerausforderung. Das Team konnte diesenRückschlag jedoch bewältigen, indem esvom vorgesehenen Ablauf abwich und AT-LAS erfolgreich so steuerte, dass er dasBrettvon seinen Füßen entfernte, bevor er dierestlichenTrümmerbeseitigte (Abbildung 3).Es gabnoch eineweitereHerausforderung.

Das Team wusste, dass der Roboter geradeso in das Auto passte, das er fahren mussteundhatte keinepraktischeMöglichkeit, die-seAufgabe vorher in derNähedesMIT-Cam-pus zu testen. So blieben lediglich 30 Minu-ten Zeit, um mit dem Auto und ATLAS zuexperimentieren, bevor die 30-minütigeAufgabe begann. Keines der vorherigenTeams hatte es geschafft, das Auto über dieStartlinie zubewegen.Das Teamkonnte denRoboter aber dazu bringen, das Lenkrad zudrehen, das Gaspedal zu drücken und dieHälfte der vorgesehenen Strecke zurückzu-legen, bevor die Zeit ablief.

Vorbereitung auf dieDRC-EndrundeIn den DRC-Probeläufen erreichte das

Team den 4. Platz und qualifizierte sich da-durch für die DRC-Endrunde, die für Juni2015 geplant ist. In dieser Phase desWettbe-werbsmuss der Roboter bei reduzierter Kom-munikation zwischendemRoboter unddemTeam,das ihnbedient, eineReihephysischerAufgabenausführen.DARPAhat vor kurzembekannt gegeben, dass dabei noch größererWert auf autonomes Agieren des Robotersgelegt wird. // FG

MathWorks+49(0)241 47576700

Bild 3: Der ATLAS-Roboter entfernt bei den DRC-Probeläufen Trümmer, um eine Tür freizuräumen.

Bild:M

athW

orks

Bild 4:MIT-Teammitglieder überlegen, wie sieATLAS in das DRC-Nutzfahrzeug bekommen.

Bild:M

athW

orks

document995303287064272804.indd 22 05.05.2015 13:41:08

ccoommmmuunniittyy

xing.com

/net/

elektron

ikpraxis

0923

2

Werden Sie MitgliedWerden Sie Mitgliedin der Community!in der Community!

Die Community auf XING für Embedded Software Experten!

Bauen Sie Ihr Netzwerk aus!

Diskutieren Sie mit Referentenund Branchenkollegen!

Profitieren Sie von exklusivenSonderaktionen!

09232_ANZ_EP_Twitter_Facebook_Xing_A4_3.indd 109232_ANZ_EP_Twitter_Facebook_Xing_A4_3.indd 1 04.04.2014 09:30:0304.04.2014 09:30:03

https://www.xing.com/communities/groups/elektronikpraxis-fachzeitschrift-fuer-elektronik-entwicklung-beschaffung-und-fertigung-1066026

24

SYSTEMENTWURF // ANFORDERUNGSDESIGN UND TRACEABILITY


Anforderungsmanagement undRückverfolgbarkeit ganz konkret

Qualitätssicherung kann nicht nur Code-Analyse und Test bedeuten.Denn weder Analyse-Lösungen noch Tests stellen sicher, dass Sys-

temanforderungen korrekt umgesetzt wurden.

SHAN BHATTACHARYA *

* Shan Bhattacharya... fungiert als Business Development Manager undleitet das US Field Engineering Team für LDRA.

Normen wie ISO/DIS 26262 der Auto-mobilindustrie oder die Norm IEC62304 des Medizinsektors verlangen

nachbidirektionaler Rückverfolgbarkeit. Siebetonen die Notwendigkeit, jede Entwick-lungs-Ebene aus der jeweils darüber liegen-denEbeneherzuleiten.DiemeistenAnbieterstatischer unddynamischerAnalyse-Lösun-gen sind jedoch nicht in der Lage, das Benö-tigte zu liefern.Die Lösung liegt in einer Requirements

TraceabilityMatrix (RTM), die sich imMittel-punkt jedes Projekts befindet. Eine RTM istzunächst einmal ein Konzept, sie kann aber

auch Teil einesWerkzeugs sein, das die Ver-knüpfungen zwischen Anforderungen undEntwicklungsartefakten wie zum BeispielCode-Objekten,Modellen oderDokumentenverwaltet. DieVerknüpfungen existierenun-abhängig davon, ob sie real protokolliert undverwaltet werden oder nicht. Ein Entwicklererzeugt etwabereits danneineVerknüpfung,wenn er eine Design-Spezifikation liest undfür die Implementierung heranzieht.

Die RTM im Software-Lebens-zyklusAufgrund dieser zentralen Rolle sollten

Projektmanager den Investitionen in Toolsfür das Erstellen der RTM einen genügendhohenStellenwert einräumen.DieRTMmussaußerdem zum Unterstreichen ihrer Bedeu-

tung in jedem Lebenszyklus-Modell explizitdargestelltwerden. Bedingt durchdiese ver-stärkte Fokussierung wird die RTM effizientund präzise erstellt und gepflegt. Wenn dieRTMzumZentrumdesEntwicklungsprozes-ses wird, beeinflusst sie sämtliche Stadiendes Designs von den übergeordneten Anfor-derungenbis zumzielbasiertenDeployment.Bei den übergeordneten Anforderungen

auf Ebene 1 (siehe Schema rechts) kann essich um eine definitive Beschreibung des zuentwickelnden Systems handeln. Je nachUmfang und Komplexität des Systems kanndiese Ebene auch weiter unterteilt werden.Ebene 2 beschreibt das Design des in Ebe-

ne 1 definierten Systems. Vor allem mussdiese Ebene für Verknüpfungen oder dieRückverfolgbarkeit zur ersten Ebene sorgenund mit dem Erstellen der RTM beginnen.Dazu gehört das Erfassen der untergeordne-ten Anforderungen, die design- und imple-mentierungsspezifisch sind und die Funkti-onalität des Systems nicht beeinflussen.Die Implementierung auf Ebene 3 bezieht

sich auf den inÜbereinstimmungmit Ebene2 entwickelten Quell- bzw. Assemblercode.ZudenVerifikations-Aktivitäten gehörenhierdas Prüfen der Codierungsregeln und dieQualitätsanalyse. Das Pflegen der RTMbirgtauf dieser Ebene viele Herausforderungen,da das Zurückverfolgen der Anforderungenzu den Quellcode-Dateien möglicherweisenicht spezifisch genug ist unddie Entwicklerunter Umständen auf einzelne Funktionenverweisenmüssen.In vielen Fällen dürfte das Systemmehre-

re Funktionen involvieren. Die Rückverfol-gungdieser Funktionen zudenAnforderun-gen von Ebene 2 umfasst aufgefächerte Be-ziehungen, und es passiert nur allzu leicht,dass in einer manuell verwalteten Matrixeine oder mehrere dieser Beziehungen ausdem Blick geraten.In Ebene4 (Host-basierteVerifikation) be-

ginnt die formelle Verifikation. Sobald perAutomated Code Review der Nachweis er-

Die Anforderungen stets im Blick: Rückverfolgbarkeit der Anforderungen stellt sicher, dass alle Require-ments umgesetzt sind und sich sämtliche Entwicklungs-Artefakte auf eine oder mehrere Anforderungenzurückführen lassen.

Bild:©

Sergey

Nivens

-Fotolia

document3243180202476199682.indd 24 05.05.2015 13:44:01

25

SYSTEMENTWURF // ANFORDERUNGSDESIGN UND TRACEABILITY


Rückverfolgbarkeit in der Norm ISO 26262Werden die Anforderungen korrekt ver-waltet, kann die Rückverfolgbarkeit vonder ursprünglichen Anforderung bis zuden untergeordneten Anforderungenverfolgt werden. Umgekehrt lassen sichdie untergeordneten Anforderungen zuihrem jeweiligen Ursprung zurückver-

folgen. Mit dieser Art bidirektionalerRückverfolgbarkeit lässt sich leichter er-mitteln, dass alle Quell-Anforderungenkomplett berücksichtigt sind und dasssämtliche untergeordneten Anforderun-gen auf eine gültige Quelle zurückge-führt werden können.

bracht ist, dass der Codedie relevantenStan-dards erfüllt, können Modul-, Integrations-und Systemtests in eine Teststrategie einge-bundenwerden, die auf demTop-Down- oderdem Bottom-Up-Prinzip oder einer Kombi-nation aus beiden beruhen kann. Soft-warestimulations-Techniken leisten Hilfebeim Erstellen automatisierter Testumge-bungenundTestfall-Generatoren. ExecutionHistories können den Nachweis erbringen,dass der Code getestet wurde.Solche Tests können bei Bedarf durch Ro-

bustheitsprüfungen ergänzt werden – mög-licherweise durch automatische DefinitionderModultest-Vektorenoder durch statischeVorhersage des dynamischen Verhaltens.Die Testfälle von Ebene 4 sollten, falls er-

forderlich, auf Ebene 5 reproduzierbar sein.In diesem Stadium liefern wir die Bestäti-gung, dass die Software in ihrer Entwick-lungsumgebung wie vorgesehen arbeitet.Keine Garantie besteht indes dafür, dass sieauch in ihrer Zielumgebung funktionierenwird. Allerdings gibt das Testen in der Host-Umgebung erstmals die Möglichkeit, mitdemzeitaufwendigenTarget Test einfachdieBestätigung zu liefern, dass die Tests in derZielumgebung solide bleiben.Die zielbasierte Verifikation auf Ebene 5

stellt das auf dem Zielsystem stattfindendeTest-Element der formellenVerifikation dar.Sie beschränkt sich häufig auf die schlichteBestätigung, dass die zuvor ausgeführtehostbasierte Verifikation in der Zielumge-bung wiederholbar ist, auch wenn einigeTests möglicherweise nur in dieser Umge-bung selbst anwendbar sind.Wenn Zuverlässigkeit oberstes Gebot ist

und die Budgets es zulassen, wäre die stati-sche Analyse des dynamischen VerhaltensunterVerwendungder komplettenDatensät-ze ein Hilfsmittel, das bei einem solchenAnsatz eine gute Ergänzung darstellen wür-de.Dennochbliebedie dynamischeAnalyseauch hier zentrales Element des Prozesses.

Welche Herangehensweisensollten gewählt werden?Es gibt schlagkräftige Argumente für die

traditionellen formellen Methoden. Wegendes Entwicklungsaufwands für solch einVer-fahren und der Schwierigkeit, es rückwir-kend auf bereits existierenden Code anzu-wenden, ist es jedoch nur für höchst sicher-heitskritische Anwendungen sinnvoll.Die automatische Codeprüfung stellt fest,

ob die Codierungsstandards eingehaltenwurden.DiesesVerfahrendürfte sich für na-hezu alle Entwicklungsumgebungen eignen.Von den verbleibenden Verfahren stellen

dynamischeAnalysetechniken einePrüfum-

gebung zurVerfügung, die die finaleAnwen-dung wesentlich besser widerspiegelt alsstatische Vorhersagen des dynamischenVerhaltens oder Möglichkeiten für Funkti-onsprüfungen.WenndieRückverfolgbarkeit derAnforde-

rungen in einer gemanagtenundkontrollier-ten Entwicklungsumgebung entscheidendist, passt das progressive Konzept von auto-matischer Codeprüfung, gefolgt vonModul-,Integrations- und Systemtests bestens zudem in mehrere Ebenen gegliederten Kon-zept dermeistenmodernenStandards. Eben-so kommt es der häufig aufgestellten Forde-rung oder Empfehlung nach, den Code inseiner Zielumgebung zu prüfen.Ist eineRobustheitsprüfunggerechtfertigt,

dannkann sie durch automatischeDefinitionder Modultest-Vektoren umgesetzt werdenoder durch statische Vorhersage des dyna-mischen Verhaltens.Jede dieser Techniken hat ihre Meriten.

Erstere führt den Code in seiner Zielumge-bung aus. Letztere bietet eine Möglichkeit,nicht nur einzelne Testvektoren, sonderndengesamtenDatensatz auszuführen.Wennes vomBudget hermöglich ist, könnten die-

se sich gegenseitig ausschließendenVorteiledie Anwendung beider Techniken rechtfer-tigen. Andernfalls könnte dasUnit-Test-Toolwegen seinerMultifunktionalität ein kosten-effektiver Ansatz sein.Besteht einnachgeordnetesBestreben, die

unternehmenseigenen Abläufe in Richtungauf die aktuellen bewährten Methoden zuverändern, müssen die automatische Code-prüfungunddynamischeAnalysetechnikeneinewichtige Rolle imManagement und derRückverfolgbarkeit derAnforderungenüber-nehmen. Letztere ist entscheidend für denNachweis, dass der Code seine funktionalenZielsetzungen erfüllt.Wenn das Ziel im Finden einer pragmati-

schenLösung liegt, die die Zahl der Problemereduziert, die bei einer schwierigenApplika-tion imFeld auftreten, sohat jeder der beidenRobustheits-Tests – also die statischeAnaly-se des dynamischen Verhaltens und die au-tomatische Definition der Modultest-Vekto-ren – das Potenzial, diffizile Probleme aufeffiziente Weise einzukreisen. // FG

LDRA+44(0)151 6499300

Immer im Zentrum: Die Requirements Traceability Matrix (RTM) ist zunächst einmal ein Konzept. Sie kannaber auch ein Tool oder ein Teil davon sein. Die RTM ist die Gesamtheit aller Verknüpfungen zwischen denAnforderungen und den Entwicklungs-Artefakten wie Modellen oder Code.

Schema:LDRA

document3243180202476199682.indd 25 05.05.2015 13:44:04


REDAKTIONChefredakteur: Johann Wiesböck (jw), V.i.S.d.P. für die redaktionellen Inhalte,Ressorts: Zukunftstechnologien, Kongresse, Kooperationen, Tel. (09 31) 4 18-30 81Chef vom Dienst: Peter Koller (pk), Tel. (09 31) 4 18-30 98Verantwortlich für dieses Sonderheft: Thomas Kuther (tk)Redaktion München: Tel. (09 31) 4 18-David Franz (df), Beruf, Karriere & Management, Tel. - 30 97Franz Graser (fg), Prozessor- und Softwarearchitekturen, Embedded Plattformen, Tel. -30 96;Martina Hafner (mh), Produktmanagerin Online, Tel. -30 82;Hendrik Härter (heh), Messtechnik, Testen, EMV, Medizintechnik, Laborarbeitsplätze, Displays,Optoelektronik, Embedded Software Engineering, Tel. -30 92;Holger Heller (hh), ASIC, Entwicklungs-Tools, Embedded Computing, Mikrocontroller,Prozessoren, Programmierbare Logik, SOC, Tel. -30 83;Gerd Kucera (ku), Automatisierung, Bildverarbeitung, Industrial Wireless, EDA,Leistungselektronik, Tel. -30 84;Thomas Kuther (tk), Kfz-Elektronik, E-Mobility, Stromversorgungen, Quarze & Oszillatoren,Passive Bauelemente, Tel. -30 85;Kristin Rinortner (kr), Analogtechnik, Mixed-Signal-ICs, Elektromechanik, Relais, Tel. -30 86;Margit Kuther (mk), Bauteilebeschaffung, Distribution, E-Mobility, Tel. (0 81 04) 6 29-7 00;Freie Mitarbeiter: Prof. Dr. Christian Siemers, FH Nordhausen und TU Clausthal; Peter Siwon,MicroConsult; Sanjay Sauldie, EIMIA; Hubertus Andreae, dreiplusVerantwortlich für die FED-News: Jörg Meyer, FED, Alte Jakobstr. 85/86, D-10179 Berlin,Tel. (0 30) 8 34 90 59, Fax (0 30) 8 34 18 31, www.fed.deRedaktionsassistenz: Eilyn Dommel, Tel. -30 87Redaktionsanschrift:München: Grafinger Str. 26, 81671 München, Tel. (09 31) 4 18-30 87, Fax (09 31) 4 18-30 93Würzburg: Max-Planck-Str. 7/9, 97082 Würzburg, Tel. (09 31) 4 18-24 77, Fax (09 31) 4 18-27 40Layout: Agentur Print/Online

ELEKTRONIKPRAXIS ist Organ des Fachverbandes Elektronik-Design e.V. (FED).FED-Mitglieder erhalten ELEKTRONIKPRAXIS im Rahmen ihrer Mitgliedschaft.

VERLAGVogel Business Media GmbH & Co. KG, Max-Planck-Straße 7/9, 97082 Würzburg,Postanschrift:Vogel Business Media GmbH & Co. KG, 97064 WürzburgTel. (09 31) 4 18-0, Fax (09 31) 4 18-28 43Beteiligungsverhältnisse: Vogel Business Media Verwaltungs GmbH,Kommanditistin: Vogel Medien GmbH & Co. KG, Max-Planck-Straße 7/9, 97082 WürzburgGeschäftsführung: Stefan Rühling (Vorsitz), Florian Fischer, Günter SchürgerPublisher: Johann Wiesböck, Tel. (09 31) 4 18-30 81, Fax (09 31) 4 18-30 93Verkaufsleitung: Franziska Harfy, Grafinger Str. 26, 81671 München,Tel. (09 31) 4 18-30 88, Fax (09 31) 4 18-30 93, [email protected]. Verkaufsleitung: Hans-Jürgen Schäffer, Tel. (09 31) 4 18-24 64, Fax (09 31) 4 18-28 43,[email protected] Account Manager: Claudia Fick, Tel. (09 31) 4 18-30 89 , Fax (09 31) 4 18-30 93,[email protected]: Susanne Müller, Tel. (09 31) 4 18-23 97, Fax (09 31) 4 18-28 [email protected] Schlosser, Tel. (09 31) 4 18-30 90, Fax (09 31) 4 18-30 93, [email protected]: Elisabeth Ziener, Tel. (09 31) 4 18-26 33Auftragsmanagement: Claudia Ackermann, Tel. (09 31) 4 18-20 58, Maria Dürr, Tel. -22 57;Anzeigenpreise: Zur Zeit gilt Anzeigenpreisliste Nr. 49 vom 01.01.2015.Vertrieb, Leser- und Abonnenten-Service: DataM-Services GmbH,Franz-Horn-Straße 2, 97082 Würzburg, Thomas Schmutzler, Tel. (09 31) 41 70-4 88, Fax -4 94,[email protected], www.datam-services.de.Erscheinungsweise: 24 Hefte im Jahr (plus Sonderhefte).

EDA

Verbreitete Auflage: 37.999 Exemplare (II/2014).Angeschlossen der Informationsgemeinschaft zur Feststellung der Verbreitung vonWerbeträgern – Sicherung der Auflagenwahrheit.Bezugspreis: Einzelheft 12,00 EUR. Abonnement Inland: jährlich 230,00 EUR inkl. MwSt.

Abonnement Ausland: jährlich 261,20 EUR (Luftpostzuschlag extra). Alle Abonnementpreiseverstehen sich einschließlich Versandkosten (EG-Staaten ggf. +7% USt.).Bezugsmöglichkeiten: Bestellungen nehmen der Verlag und alle Buchhandlungen im In- undAusland entgegen. Sollte die Fachzeitschrift aus Gründen, die nicht vom Verlag zu vertretensind, nicht geliefert werden können, besteht kein Anspruch auf Nachlieferung oder Erstattungvorausbezahlter Bezugsgelder. Abbestellungen von Voll-Abonnements sind jederzeit möglich.Bankverbindungen: HypoVereinsbank, Würzburg (BLZ 790 200 76) 326 212 032,S.W.I.F.T.-Code: HY VED EMM 455, IBAN: DE65 7902 0076 0326 2120 32Herstellung: Andreas Hummel, Tel. (09 31) 4 18-28 52,Frank Schormüller (Leitung), Tel. (09 31) 4 18-21 84Druck: Vogel Druck und Medienservice GmbH, 97204 Höchberg.Erfüllungsort und Gerichtsstand:WürzburgManuskripte: Für unverlangt eingesandte Manuskripte wird keine Haftung übernommen.Sie werden nur zurückgesandt, wenn Rückporto beiliegt.Internet-Adresse: www.elektronikpraxis.de www.vogel.deDatenbank: Die Artikel dieses Heftes sind in elektronischer Form kostenpflichtig über dieWirtschaftsdatenbank GENIOS zu beziehen: www.genios.de

VERLAGSBÜROSVerlagsvertretungen INLAND: Auskunft über zuständige Verlagsvertretungen:TamaraMahler, Tel. (0931) 4 18-22 15, Fax (0931) 4 18-28 57; [email protected]: Belgien, Luxemburg, Niederlande: SIPAS, Peter Sanders, Sydneystraat 105, NL-1448NE Purmerend, Tel. (+31) 299 671 303, Fax (+31) 299 671 500, [email protected]: DEF & COMMUNICATION, 48, boulevard Jean Jaurès, 92110 Clichy,Tel. (+33) 14730-7180, Fax -0189.Großbritannien: Vogel Europublishing UK Office, Mark Hauser, Tel. (+44) 800-3 10 17 02,Fax -3 10 17 03, [email protected], www.vogel-europublishing.com.USA/Canada: VOGEL Europublishing Inc., Mark Hauser, 1632 Via Romero, Alamo, CA 94507,Tel. (+1) 9 25-6 48 11 70, Fax -6 48 11 71.

Copyright: Vogel Business Media GmbH & Co. KG. Alle Rechte vorbehalten. Nachdruck, digi-tale Verwendung jeder Art, Vervielfältigung nur mit schriftlicher Genehmigung der Redaktion.Nachdruck und elektronische Nutzung: Wenn Sie Beiträge dieser Zeitschrift für eigene Veröffent-lichung wie Sonderdrucke, Websites, sonstige elektronische Medien oder Kundenzeitschriftennutzen möchten, erhalten Sie Information sowie die erforderlichen Rechte überhttp://www.mycontentfactory.de, (09 31) 4 18-27 86.

Impressumelektromobilität PRAXIS

MitThemen aus

Forschung | Entwicklung | KonstruktionFertigung | Markt | Politik | Gesellschaft | Umwelt

...von den Rahmenbedingungenzum technischen Fachwissen

...vom Leistungshalbleiterzur Ladeinfrastruktur

---> www.elektromobilität-praxis.de

0869

1

www.vogel.de

document1349289075967452307.indd 26 05.05.2015 14:19:18

http://www.fed.de







http://www.datam-services.de

http://www.elektronikpraxis.de

http://www.vogel.de

http://www.genios.de




http://www.vogel-europublishing.com

http://www.mycontentfactory.de

http://www.elektromobilitt-praxis.de

http://www.vogel.de

Kostenloses DIGITAL-KOMPENDIUM

Starterkits und Design-Tipps

www.vogel.de

Antriebstechnik & Antriebselektronikwww.elektronikpraxis.de/antriebstechnik-kompendium

Leiterplattentechnik & PCB-Designwww.elektronikpraxis.de/leiterplattentechnik-kompendium

Messtechnik-Grundlagenwww.elektronikpraxis.de/messtechnik-kompendium

CompactPCI Serial - der Star auf der Embedded-Bühnewww.elektronikpraxis.de/compactpci-serial-kompendium

Analoge Schaltungstechnikwww.elektronikpraxis.de/analogtechnik-kompendium

Lesen Sie auch unsere anderen Digital-Kompendien:

*limitierte Auflage

1003

2

Starterkits &Design-Tipps

Board-Auswahl

Industrie-Boards

Software

Tools & Boards

Lesen Sie das gesammelte ELEKTRONIKPRAXIS-Wissen auf Ihrem PC, Laptopoder iPad und sichern Sie sich kostenlos Ihr gedrucktes Kompendium* unter

www.elektronikpraxis.de/starterkits-kompendium

Jetzt als

ePaper

lesen!

10032_ANZ_EP_Kompendium_Starterkit_210x297_4.indd 110032_ANZ_EP_Kompendium_Starterkit_210x297_4.indd 1 02.07.2014 11:00:3802.07.2014 11:00:38

http://www.elektronikpraxis.de/antriebstechnik-kompendium

http://www.elektronikpraxis.de/leiterplattentechnik-kompendium

http://www.elektronikpraxis.de/messtechnik-kompendium

http://www.elektronikpraxis.de/compactpci-serial-kompendium

http://www.elektronikpraxis.de/analogtechnik-kompendium

http://www.vogel.de

http://www.elektronikpraxis.de/starterkits-kompendium

INTERNETOF THINGS

Seit über 30 Jahren vertrauen weltweitführende Firmen Green Hills Softwaresicherer, zuverlässigen und performantenSoftware für sicherheitskritische Systeme.

Für das vernetzte Auto, Konsumgüter undMedizinprodukte, Industrieautomatisierung,Netzwerke, Schaltzentralen, etc. bietenunsere Software und Dienstleistungendie sichere und zuverlässige Basis für dasInternet der Dinge.

ABSICHERUNG DES

Copyright © 2015 Green Hills Software. Green Hills Software and the Green Hills logo are registeredtrademarks of Green Hills Software. All other product names are trademarks of their respective holders.

Um Systeme für das Internet der Dinge mit der höchstenQualität und Zuverlässigkeit zu entwickeln, rufen Sie die

folgende Nummer an +49 228 4330 777 oderbesuchen Sie www.ghs.com/secureIoT

MEDIZIN

KONSUMGÜTER

AUTOMOBIL

INDUSTRIE

KOMMUNIKATION

NETZE

MILITÄRSAFE, RELIABLE, SECURE.

http://www.ghs.com/secureIoT

Documents

Embedded Software Engineering 2/2015 - files.vogel.defiles.vogel.de/vogelonline/vogelonline/issues/ep/2015/202.pdf · Beispiel soll hier der normale Produkt-Le-benszykluseinerSoftware-Anwendungdie-