Embedded Software Engineering 4/2014 -...

28
Wissen. Testbarkeit und Automatisierung von Tests Warum Testbarkeit ein Teil der Anforderungsmodellie- rung werden sollte. Seite 12 Strategien für das Konfigurationsma- nagement Wann Sie Ihr Konfigura- tionsmanagement-Tool wechseln sollten. Seite 16 Sichere Systement- wicklung im Inter- net der Dinge Welche Techniken und Methoden das IoT wirklich sicher machen. Seite 22 EMBEDDED SOFTWARE ENGINEERING Sponsored by KOSTENLOSER VERSAND FÜR BESTELLUNGEN ÜBER 65 €! DIGIKEY.DE Impulse. Kontakte. Dezember 2014 www.elektronikpraxis.de Mit intelligenten Tools den Airbus der Zukunft bauen Mit dem NI SoM können Entwicklerteams komplexe Embedded-Systeme schneller im Markt einführen. Airbus nutzt das SoM, um intelligente Werkzeuge zu entwickeln.

Transcript of Embedded Software Engineering 4/2014 -...

Page 1: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

Wissen.

Testbarkeit undAutomatisierungvon TestsWarum Testbarkeit ein Teilder Anforderungsmodellie-rung werden sollte. Seite 12

Strategien für dasKonfigurationsma-nagementWann Sie Ihr Konfigura-tionsmanagement-Toolwechseln sollten. Seite 16

Sichere Systement-wicklung im Inter-net der DingeWelche Techniken undMethoden das IoT wirklichsicher machen. Seite 22

EMBEDDED SOFTWARE ENGINEERING Sponsored by

KOSTENLOSER VERSAND

FÜR BESTELLUNGEN ÜBER 65 €!

DIGIKEY.DE

Wissen.Impulse.Kontakte. Dezember 2014

www.elektronikpraxis.de

Mit intelligenten Tools denAirbus der Zukunft bauen

Mit dem NI SoM können Entwicklerteams komplexe Embedded-Systeme schneller imMarkt einführen. Airbus nutzt das SoM, um intelligente Werkzeuge zu entwickeln.

Page 3: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

3

EDITORIAL

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Geben Sie Trendvokabeln mitVersionsnummer keine Chance

In letzter Zeit fliegen einem die Versi-onsnummern ja nur so um die Ohren.Es fing an mit Web 2.0, dann kam In-

dustrie 4.0, auch vonSocialMedia 2.0wardie Rede – und jüngst hat jemand sogardas Internet of Things 3.0 erfunden. Wiehaltbar diese Begriffe sind, die in der Re-gel aus einer Trendvokabel und einerVer-sionsnummer bestehen, hat man ja (zu-mindest im Prinzip) bei „Second Life“gesehen. Vor ein paar Jahren hieß es al-lenthalben, das sei das nächste großeDing, da müsse man dabei sein, und werzu spät komme, den bestrafe das Lebenmit weit überhöhten Immobilienpreisenfür die virtuellen Ländereien. Inzwischensind die digitalen Korridore des zweitenLebens vermutlich so leer und öde wieeine Geisterstadt imWildenWesten, undnur noch einige unentwegte Desperadosverlieren sich inder pixeligenAnderswelt.Wer die Elektronik- und IT-Branche

schon seit längerer Zeit beobachtet, kenntdasWerden undVergehen solcher Hypeszur Genüge. Manche Marktforscher wid-men sich nachgerade der Erforschungsolcher Hype-Zyklen. Und in aller Regelmacht sich eine alte Lebenserfahrungbe-merkbar: Auf den Rausch folgt oft derKater, auf Euphorie Ernüchterung.

„Schon von Beginn an gutund immer besser ge-worden – das ist der ESEKongress, der heuer zumsiebten Mal stattfindet.“

Franz Graser, [email protected]

Es tut also gut, sichdem jeweils „nächs-ten großenDing“mit einemSchuss Skep-sis zunähern. Es ist ja auch so: TechnischeEntwicklungen müssen oft erst reifen.1.0-Produkte (da haben wir sie wieder,unsere Versionsnummern) sind äußerstselten perfekt.Was dagegen schon von Beginn an gut

war und immer besser geworden ist, dasist der ESEKongress, der heuer nun schonzumsiebtenMal stattfindet.HochwertigeVorträgeundKompaktseminare, guteGe-sprächeundDiskussionen sowie dieAus-stellungen und Entwicklerparties helfenIhnen, denBlick für dieDinge zu schärfen– damit Sie nicht auf die Schlangenöl-Verkäufer hereinfallen, die Ihnen irgend-eine Trendvokabel mit einer Versions-nummer andrehen wollen. Der ESE Kon-gress 7.0 erwartet Sie. Und darauf freuenwir uns.

Herzlichst, Ihr

MDK Professional enthältMiddleware und standardisierteTreiber. Diese Software-Komponenten werden im Run-TimeEnvironmentWindow ausgewählt.

keil.com/mdk5+49 89 456040-20

MDK Core

µVision IDE with Editor

ARM C/C++ Compiler

µVision Debugger withTrace

MDK Professional Middleware

TCP/IP Networking File System

USB Host Stack Graphical UserInterface

USB Device Stack RTX RTOS

MDK-ARM™Version 5Das komplette Software-Entwicklungssystem für alle ARM®-basierten Mikrocontroller.

MDK unterstützt alleCortex-M Prozessoren undführt Softwareentwicklung mitKomponenten ein.

Page 4: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

4 ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

INHALT

AKTUELLES6 Vorschau auf den ESE-Kongress 2014 in Sindelfingen

SCHWERPUNKTECyber-Physische SystemeTITELTHEMA

8 Intelligente Werkzeuge für den Airbus der ZukunftDie Flugzeugfabrik der Zukunft ist ein Forschungsprojekt,das neu aufkommende Fertigungstechniken mit intelligen-ten Tools fördert.

Softwaretest12 Testbarkeit und Testautomatisierung

Vieles spricht dafür, die Testbarkeit und -automatisierungals Teil der Anforderungsmodellierung zu betrachten. Dennstetige Tests sichern letztlich den Entwicklungsprozess ab.

Projektmanagement14 Innovation, Geschwindigkeit und Agilität in der Soft-

wareentwicklungDer Beitrag vergleicht agile Methoden mit dem traditionel-len Wasserfall-Verfahren.

Anforderungsmanagement16 Wann Sie Ihr Konfigurationsmanagement-Tool wech-

seln solltenWenn ein Konfigurationsmanagement-Werkzeug (CM) anGrenzen stößt, sollte die CM-Strategie überdacht werden.

Internet der Dinge20 Sicherstellung des zuverlässigen Betriebs vernetzter

IoT-GeräteEchtzeitbetriebssysteme (RTOS) tragen zur sicherenTrennung wichtiger System-Tasks bei Geräten bei, die ansInternet der Dinge angeschlossen sind.

22 Überlegungen zur Entwicklung sicherer IoT-SystemeEs gibt viele Herausforderungen bei Entwicklung von Lö-sungen für das Internet der Dinge (IoT). Der Beitrag lieferteinige Grundgedanken für den Bau sicherer Systeme.

IT und Recht26 Wie ein aus dem Ruder gelaufenes IT-Projekt wieder

auf Kurs gebracht werden kannSchlichtungen der Deutschen Gesellschaft für Recht undInformatik sind oft nachhaltiger als ein Gerichtsverfahren.

RUBRIKEN3 Editorial

25 Impressum

CYBER-PHYSISCHE SYSTEME

Intelligente Tools für denAirbus der ZukunftFlugzeuge müssen in Tausenden vonSchritten gefertigt und montiert werden.Das Beheben eines einzigen Fehlers könnteHunderttausende von Dollar kosten, sodassder Spielraum sehr gering ist. Werkzeuge undSysteme in der Anlage müssen um Intelligenzerweitert werden, um den Produktionsprozess zuvereinfachen. Durch das System on Module (SOM)von NI kann Airbus schnell Prototypen dieser intel-ligenten Tools unter Einbezug des Systemdesign-Ansatzes von NI erstellen.

8

Intelligente Tools für den

der Spielraum sehr gering ist. Werkzeuge undSysteme in der Anlage müssen um Intelligenzerweitert werden, um den Produktionsprozess zuvereinfachen. Durch das System on Module (SOM)von NI kann Airbus schnell Prototypen dieser intel-ligenten Tools unter Einbezug des Systemdesign-

Intelligente Tools für den

der Spielraum sehr gering ist. Werkzeuge undSysteme in der Anlage müssen um Intelligenzerweitert werden, um den Produktionsprozess zuvereinfachen. Durch das System on Module (SOM)von NI kann Airbus schnell Prototypen dieser intel-ligenten Tools unter Einbezug des Systemdesign-

Automatische Identifikation mit RFIDwww.elektronikpraxis.de/specials

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

Page 6: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

6

AKTUELLES // ESE KONGRESS 2014

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Stars der Embedded-Szenekommen nach Sindelfingen

Auf dem Embedded Software Engineering Kongress (1. – 5. Dezember)geben sich hochkarätige Sprecher die Ehre, unter anderem zu den

Themen Softwarequalität, Security und Human Computer Interaction.

EmbeddedSoftware Engineering gehörtzudengroßenHerausforderungendermodernenElektronikentwicklung.Nur

mit einer planvollen, ingenieurmäßigenHe-rangehensweise und modernen Methodender Informatik und Elektronikentwicklunglassen sichdie durchKomplexität sowie Zeit-undKostendruck steigendenAnforderungenkünftig beherrschen.DieseHerausforderung adressiert seit Jah-

render ESEKongress. Unter demMotto „Wis-sen ist das einzige Gut, das sich vermehrt,wennmanes teilt“ hat sichdieVeranstaltungin nurwenigen Jahren zurwichtigsten Platt-formderBranche inDeutschland entwickelt.In über 100Vorträgenund 16Kompaktsemi-naren vermitteln Experten aus Industrie,ForschungundLehre aktuelle Erkenntnisse,Prinzipien, Methoden und Tools der moder-nen Softwaretechnik sowie aktuelle Trendsinder Embedded-Softwareentwicklung,wieMulticore, Embedded Security, Internet ofThings oder agile Methoden.Die vielen positiven Rückmeldungen der

zurückliegenden Jahre und das hohe Inter-esse vieler Experten und Aussteller, sich zuengagieren, zeigen:DerKongress hat sich alswichtigste Veranstaltung der Embedded-Softwarebranche in Deutschland etabliert.

Kryptoanalytiker zeigtSchwachstellen im System aufNeben den Klassikern wie Modellierung,

Echtzeit oder Testwird es eigeneVortragsrei-hen zu Embedded Security geben. Unter an-deremwirdderBonnerKrypotoanalytikerDr.FrankSchuhmacher, einer derGewinner desrenommiertenKrypto-WettbewerbsDPACon-test 2013/2014, eineEinführung indas Thema„Angriffsziel Embedded System“ geben. DerKompaktkurs liefert eineÜbersicht über ver-breitete Angriffsmethoden, die für Embed-ded Systeme eine Rolle spielen. Es werdenBeispiele aus den Bereichen Automotive,Automatisierung, Elektronischer Zahlungs-verkehr, PayTVundZugangskontrollsystemedargestellt. Der Kurs bietet eine kurze Ein-führung in Seitenkanal-AnalysenundFehler-

Injektionsangriffe und geeignete Software-Gegenmaßnahmen.Zu den jährlichen Highlights zählen die

Keynotes. 2015 konnten zwei renommierteWissenschaftler und ein begehrter Embed-ded-Experte aus denUSAgewonnenwerden.Über gutes Software Engineering als ertrag-reiche Investition spricht Prof. Dr. JochenLudewig, Professor für Softwaretechnik anderUniversität Stuttgart.WieMenschenundComputer künftig interagieren, skizziertProf. Dr. Manfred Tscheligi, ein Pionier derHuman-Computer Interaction.Und für die Tech-Keynote wird Jack Gans-

sle aus USA anreisen und erklären, wie sichin kürzerer Zeit bessere Softwarequalitäterzielen lässt. Ganssle ist ein internationalanerkannter Embedded-Ingenieur, Fachau-tor, Dozent und Berater. Im Lauf seiner Kar-rierewar er anüber 100Embedded-Entwick-lungsprojekten beteiligt. Darüber hinausgründete er drei High-Tech-Firmen.Last but not least: Bei der begleitenden

Ausstellungwerden insgesamt 48Ausstellervertreten sein. Alle Details finden Sie onlineunterwww.ese-kongress.de.Dort ist auchdieAnmeldungmöglich. // MH/FG

Interessierte Zuhörer: Bei den Keynotes des ESE-Kongresses ist der große Saal der Sindelfinger Stadthallestets gut gefüllt.

Bild:VBM

-Archiv

Tech-Keynote alsStream im InternetIn der TechKeynote des ESE-Kongres-ses am 2. Dezember um 12.25 Uhrerklärt der Embedded-Experte JackGanssle aus den USA, wie sich inkürzerer Zeit höhere Softwarequali-tät erzielen lässt. Das Motto seinesenglischsprachigen Vortrages lautet„The Way Ahead in Embedded Soft-ware Engineering: How to achievehigher quality code in less time". FürInteressierte, die nicht nach Sindel-fingen kommen können, wird seine40-minütige Keynote per Livestreamins Internet übertragen. Die Registrie-rung ist unter www.elektronikpraxis.vogel.de/webinare kostenlos mög-lich. Auch für die Podiumsdiskussionzum Thema „Embedded Software En-gineering – Wo geht die Reise hin?“am 2. Dezember um 18.20 Uhr ist eineLive-Übertragung in Planung.

Page 7: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

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!

Page 8: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 20148

TITELSTORYDie Aufgabe: Flugzeuge werden inTausenden von Schritten montiert,die die Bediener befolgen müssen.Da das Übersehen eines Fehlers Hun-derttausende von Dollar kosten kann,muss der Produktionsprozess effizi-enter und einfacher werden.Die Lösung: Werkzeuge und Systemein der Anlage müssen um Intelligenzerweitert werden, um den Produk-tionsprozess zu vereinfachen underhöhte Effizienz innerhalb des Pro-zesses durch Verwalten und Prüfender Aufgaben bereitzustellen, die derBediener ausführt. Durch dasSystem-on-Module (SoM) von NI kann Airbusschnell Prototypen dieser intelligen-ten Tools unter Einbezug des System-design-Ansatzes von NI erstellen.

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

TITELSTORY // CYBER-PHYSISCHE SYSTEME

Page 9: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

9

TITELSTORY // CYBER-PHYSISCHE SYSTEME

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Mit intelligenten Werkzeugen denAirbus der Zukunft bauenFlugzeugwerke von heute sind keine lauten und hektischen Fabrikenmehr. Die Flugzeugfabrik der Zukunft ist ein Forschungsprojekt, das

neu aufkommende Fertigungstechniken mit intelligenten Tools fördert.

SÉBASTIEN BORIA*

* Sébastien Boria... ist Mechatronic Technology Leader bei Airbus inToulouse.

Cyber-Physical SystemsundBigAnalogData schaffendieVoraussetzungen füreine intelligentere, auf den Bediener

ausgerichtete Produktion, die eine Zusam-menarbeit vonBedienernundMaschinen indemselben Umfeld erlaubt. Das Werk derZukunft schließt zudemdieumfassendeNut-zung einer modularen Plattform mit einemhohen Abstraktionsgrad auf Basis handels-üblicher Standardmodule ein.Eine der Schlüsselkomponenten zur Ver-

besserungder Effizienz imWerkder Zukunftsind intelligentere Werkzeuge. Diese Gerätesind so konzipiert, dass sie mit einer Haupt-infrastruktur oder lokal mit Bedienern odermit anderen Werkzeugen kommunizierenkönnen, aber nur dann LagebewusstseinvermittelnundEchtzeitentscheidungen tref-

fen, die auf lokaler und verteilter Intelligenzim Netzwerk basieren, wenn dies nötig ist.Im Fall einer Produktionsanlage können

intelligenteWerkzeugedenProduktionspro-zess vereinfachen und die Effizienz verbes-sern, indem sie physikalische Datenproto-kolle und Handbücher überflüssig machen.Bediener müssen sich auf ihre Aufgaben imBetriebsablauf konzentrieren.Dabeimüssensie ihreHände frei haben, umdie passendenWerkzeuge nutzen zu können. Bisherige In-itiativen, die mit papierlosen Projekten zutun hatten, legten den Fokus zumeist aufPapiereinsparungoder ErsetzendesPapiersdurch Tablet-PCs. Dennoch benötigten sieweiterhin „passive/tote Daten“.IntelligenteWerkzeuge eröffnen einewei-

tereAlternative: Live-Daten. Zur Entwicklungeines Flugzeugs gehörenunzählige Schritte,die Bediener befolgen müssen, und auchzahlreiche feststehende Prüfungen, um dieQualität sicherzustellen.DurchErweiterung

des Systems um Intelligenz erkennen dieWerkzeuge die Aktionen, die der Bedienerals nächstes ausführen muss, und passenautomatisch ihre Einstellungen an. Das ver-einfacht dieAufgabe für denBediener. NachAbschluss der Aktion können die intelligen-tenWerkzeuge auch die Ergebnisse überwa-chen und aufzeichnen. Das verbessert dieEffizienz des Produktionsprozesses.Eine bestimmteTeilbaugruppe eines Flug-

zeugs beispielsweise besitzt in etwa400.000Stellen, die festgezogen werden müssen.Dazu sind gegenwärtig über 1100 einfacheSpannwerkzeuge nötig. Der Bediener musseine Liste mit Schritten genau befolgen unddie passenden Drehmomenteinstellungenfür jede Stelle mithilfe des korrekten Werk-zeugs sicherstellen.Die manuelle Vorgehensweise bedeutet

ein hohes Risiko bei der Produktion: Selbsteine einzige Stelle, die falsch festgezogenwurde, könnte langfristig Kosten von hun-

Page 10: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

10

TITELSTORY // CYBER-PHYSISCHE SYSTEME

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Mittelsektion des Airbus A350: Bestimmte Teilbaugruppen eines Flugzeuges besitzen 400.000 Stellen,die festgezogen werden müssen. Intelligente Spannwerkzeuge begreifen, welche Aufgaben der Bedienerausführen will.

Bild:A

irbus

derttausendenDollar verursachen. Ein intel-ligentes Spannwerkzeug begreift, welcheAufgabeder Bediener ausführenwill, indemBilderfassungund -verarbeitung zumEinsatzkommen, anhand derer dasWerkzeug seineUmgebung verarbeitet und automatisch dasDrehmoment festlegt. Das Gerät kann dasResultat der Aufgabe in einer zentralen Da-tenbank speichern, umsicherzugehen, dassdie Stelle korrekt festgezogenwurde.Mit derDatenbank des zentralen ManufacturingExecution System (MES) und der verteiltenIntelligenz der Geräte können Produktions-leiter die Verfahren und Prozesse präzisebestimmen, die während der Qualitätskont-rolle und -zertifizierung überprüft werdenmüssen.Airbushatmit der Entwicklung intelligen-

ter Werkzeugfamilien begonnen, die ver-schiedene Fertigungsprozesse ausführen:Bohren, Messen sowie hochwertiges Daten-loggen und Festspannen.Bohrwerkzeug:

� Verarbeiten der Umgebung mittels Bild-verarbeitungsalgorithmen,� Verifizieren, welches Material als nächs-tes durchschnitten wird,� Aktualisieren der Schneidebedingungendes Bohrers bei jeder Materialschicht,�Überwachen der Bohrtiefe,� Festhalten der Ergebnisse des Bohrens ander derzeitigen Stelle,�Überwachen des Systemzustands,

„ Wir haben etliche Systems-on-Modules (SoMs) evaluiert,und es gibt nichts, was in Bezug auf die von NI gebotene Soft-

wareintegration mithalten kann.“Sébastien Boria, Airbus

� Automatische Überprüfungen/Kalibrie-rungen.Messwerkzeug:

� Verarbeiten der Umgebung mittels Bild-verarbeitungs-Algorithmen,�Wiederbeschaffen zulässiger Messwerteaus einer Datenbank,� Prüfen, ob die Messung innerhalb der Pa-rameter liegt,� Aufzeichnen von Ergebnissen und beiBedarf Bereitstellen von Folgemaßnahmen,� Automatische Überprüfungen/Kalibrie-rungen.Qualitätsvalidierungswerkzeug (basie-

rend auf menschlicher Entscheidung):� Verarbeiten der Umgebung mittels Bild-verarbeitungsalgorithmen,� Ausüben menschlicher Interaktion (Be-obachtung der Finger/der Augen, Sprach-steuerung),� Aufzeichnen von Ergebnissen und beiBedarf Bereitstellen von Folgemaßnahmen.Festspannwerkzeug:

� Verarbeiten der Umgebung mittels Bild-verarbeitungsalgorithmen,� Festlegen der Drehmoment-/Geschwin-digkeits-/Winkelvorgabe für die Stelle,�Überwachen des auf die Befestigungsele-mente angewandten Drehmoments,� Aufzeichnen des gegebenen Drehmo-ments in einer zentralen MES-Datenbankoder einem unternehmensweiten Ressour-cenplanungssystem,

� Automatische Überprüfungen/Kalibrie-rungen.Wir testeten das NI SoM als Basis für all

diese intelligentenTools,weil dieArchitekturund das Framework, die das System bereit-stellt, um den Entwicklungsprozess vomEntwurf über die Prototypenerstellung bishin zum Serieneinsatz zu beschleunigen,allgegenwärtig sind. Bevor wir auf dem NISoM entwickelten, konntenwir auf Basis ei-nesNI-CompactRIO-Controllers (cRIO-9068)einen Prototyp erstellen, der es erlaubte, IPaus bestehendenAirbus-Bibliotheken sowiequelloffene Algorithmen zu integrieren undso unsere Konzepte schnell zu validieren.

„Wir können Programmcode alsverteilte Lösung nutzen“Die Flexibilität, grafischeund textbasierte

Programmierung nutzen zu können, sowiedieWiederverwendungvonDrittanbieterent-wicklungen, die auf denXilinx-ZynqunddasBetriebssystem NI Linux Real-Time portiertwurden, sorgen für den perfekten Abstrak-tionsgrad für die Entwicklung derWerkzeu-ge. Jetzt könnenwir denProgrammcode, denwir auf demNI SoMentwickelten, als verteil-te Lösungnutzen, anstatt unseren gesamtenEntwurfsprozess neu beginnen zumüssen.Wir haben etliche SoMs und Embedded-

Einplatinenrechner (SBCs) evaluiert. Nichtskonntemit demvonNI gebotenenplattform-basierten Designansatz und der Hard- undSoftwareintegration mithalten. Wir schät-zen, dass unsere Zeit bis zurAuslieferungmitdemNI SoM ein Zehntel der Zeit alternativerAnsätze ausmacht, was auf die Produktivi-tätssteigerungen des NI-Konzepts beim Sys-temdesign zurückzuführen ist, vor allemaufNI Linux Real-Time und das LabVIEWFPGAModule. Dank der vomNI SoMbereitgestell-ten Software können wir uns stärker auf dieSchlüsselfunktionen unseres Systems kon-zentrieren,wie Bildverarbeitung auf FPGAs.Die „Factory of the Future“ bei Airbus ist

ein langfristiges Forschungs- undTechnolo-gieprojekt, das eine entscheidendeRolle fürunsereWettbewerbsfähigkeit bei Fertigungs-prozessen spielt. Eine zügige Entwicklung istfür unseren schrittweisen Ansatz bei neuenTechnologien von zentraler Bedeutung, an-gefangenbei der Entwicklung vonMachbar-keitsstudien bis hin zur Verbreitung realerObjekte. Wir haben diese Initiative über dieletzten Jahre sorgfältig geplant undwir kön-nen – mit NI-Technologien – unseren Ent-wicklungsprozess beschleunigen undunse-re VisionWirklichkeit werden lassen. // FG

National Instruments+49(0)89 7413130

Page 11: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014 11

TITELSTORY // CYBER-PHYSISCHE SYSTEME

INTERVIEW: DANIEL RIEDELBAUCH, NI

„Risiken und Entwicklungszeiten mit dem NISystem-on-Module reduzieren“Was ist das System-on-Module (SoM)von National Instruments und wie kön-nen Systementwickler davon profitie-ren?Mit dem NI SoM können Entwickler-teams zuverlässige und komplexe Em-bedded-Systeme schneller im Markteinführen. Das NI SoM basiert auf derLabVIEW-RIO-Architektur, wobei RIOfür rekonfigurierbare I/O steht, underfüllt die gleichen strikten Design-standards wie für andere Produkteauf deren Basis. Die LabVIEW RIO Ar-chitecture wird bereits in zahlreichenAnwendungen eingesetzt, die hoheZuverlässigkeit erfordern, etwa in un-bemannten Luftfahrzeugen oder in derMedizintechnik, etwa in Geräten zurOperation des grauen Stars. Studienzeigen uns, dass Entwicklerteams, diediese Architektur einsetzen, komplexeProbleme in der Hälfte der Zeit lösenkönnen, verglichen mit Entwickler-teams, die auf klassische benutzerde-finierte Entwicklungsansätze zurück-greifen.

Was bietet das SoM auf technischer Sei-te, wie ist es aufgebaut?Das NI System-on-Module vereint dasZynq All-Programmable SoC (System-on-a-Chip) von Xilinx mit unterstüt-zenden Elementen, wie zum BeispielSpeicher auf einer kleinen Leiterplat-te. Außerdem bietet das SoM einevollständige Middleware-Lösung undverfügt über ein schlüsselfertiges, in-tegriertes Linux-basiertes Echtzeitbe-triebssystem.

Sie haben die integrierte Middlewareangesprochen. Welche Vorteile bringtsie den Entwicklern?Die Middleware erlaubt es, Zeitproble-me und Risiken zu minimieren, die mitder Entwicklung von Embedded-Be-triebssystemen, Softwaretreibern undanderen Softwarekomponenten ver-bunden sind. Außerdem ist das SoMwie gesagt mit einem zuverlässigen Li-nux-basierten Echtzeitbetriebssystemausgestattet, sodass EntwicklerteamsZugang zu vielen Anwendungen und IPaus der Linux-Community haben.

Das SoM enthält auch einen FPGA vonXilinx. Die Programmierung dieserBausteine gilt gelinde gesagt als an-spruchsvoll. Wie können Sie die Ent-wickler hier unterstützen?Das integrierte Werkzeug LabVIEWFPGA sorgt dafür, dass Entwickler dieHardwarebeschreibungssprachennicht mehr beherrschen müssen. Diesmacht die leistungsstarke FPGA-Tech-nologie zugänglicher denn je.

Wie können die Teams ganz konkret Zeitbei der Entwicklung sparen, wenn siedas SoM einsetzen? Können Sie hier einBeispiel nennen?Sehr gern. Die Entwicklerteams kön-nen CompactRIO einsetzen, umschnell Prototypen ihrer Anwendun-gen zu erstellen. Derselbe Code kanndann auch auf dem NI SoM wiederver-wendet werden. Dies ermöglicht einendeutlich niedrigeren Arbeits- und Zeit-aufwand.

Daniel Riedelbauch: Der Diplom-Ingenieur ist Marketing-Managerfür Zentraleuropa bei NationalInstruments.

Beim Test von EmbeddedSoftware profitieren Sievon unserem Know-how:> Modul-, Unit- und

Integrations-Test> Statische Analyse> Code-Coverage-Test> Standards, Normen

und Zertifizierung> Testdienstleistungen

Softwaregetestet?

> Softwaretest Seminar & TrainingNeue Termine: 27.-29.01.2015

Softwaretest-Woche

www.hitex.de/training

Page 12: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

12

SOFTWARETEST // TESTSTRATEGIEN

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

* Giorgio Roselli... ist Senior-Softwareingenieur beider Berner & Mattner Systemtechnikin München.

verlässt sich aufmanuelle Tests oder schreibttrivialeModul-Tests, während komplexe Zu-sammenhänge ungetestet bleiben.SolcheFehler lassen sich vermeiden,wenn

der Testprozess stärker in den Vordergrundder Entwicklung rückt. Ein zentralesKriteri-um ist dabei die Testbarkeit, also das Maß,zu welchem Grad sich ein Softwareartefakttesten lässt. Testbarkeit lässt sich zwar nichtdirekt messen, aber sie lässt sich vomTestaufwand ableiten: je geringer die Test-barkeit, desto größer der Testaufwand.Dabeistellt sichdie Frage:Wie erhöhtmandie Test-barkeit und erreicht zugleich einen hohenGrad an Testautomatisierung?Die Verbesserung der Testbarkeit beginnt

bereits mit der Festlegung der Anforderun-gen. Oft ist es erforderlich, diese präziser zuformulieren, um so Vollständigkeit, Verifi-zierbarkeit und damit Testbarkeit zu erhö-hen. Dieser Ansatz schafft Anforderungen,

die alsGrundlage für Testmodelle verwendetwerden können. Die Zuordnung von Anfor-derungen auf Modellelemente erhöht dasVerständnis dafür, was getestet wird. Test-anforderungen lassen sich so visuell darstel-len und verfolgbar machen. Diesen Ansatznennt manmodellbasiertes Testen.Bereits amModell lässt sichdannabschät-

zen, welcher Teil automatisch und welchermanuell getestetwerdenwird.WodieGrenz-linie zwischen manuellen und automati-schen Tests gezogen wird, entscheidet dermit der Automatisierung verbundene Auf-wand. Wo ein Automatisierungsschritt denEntwicklungsaufwand zu sehr steigert,wirddie Testautomatisierung enden.

Die Rolle desSoftwaredesignsGanz wesentlich für Testbarkeit und Test-

automatisierung ist das Softwaredesign. EinBeispiel wäre die Aufteilung von Benutzer-oberflächeundApplikationslogik nachdemallgemein bekannten Model-View-Prinzip.Dieses erhöht die Testbarkeit beider Kompo-nenten, weil sie unabhängig voneinanderausgeführtwerdenkönnen.Merkmale einesaus Testperspektive guten Softwaredesignssind unter anderem minimale Komplexität,geringe Vernetzung und ausgewogene Auf-gabenverteilung. Einfachheit und Schlicht-heit sind schwer zu erlangen, sind jedochdieHauptzutaten für eine hohe Testbarkeit.Design-Patterns sind in der Regel ein guterRatgeber für simples Design.Am Anfang werden die kleinsten Soft-

wareeinheiten mit Hilfe von Unit-Tests ge-prüft. Bei Unit-Tests handelt es sich umPro-grammcode, der explizit dazudient, anderenProgrammcode zu prüfen. Weit verbreitethaben Unit-Tests den Vorteil, dass sie mitHilfe von Werkzeugen für kontinuierlicheIntegration einfach automatisierbar sind.Die nächste Ebene bilden die Subsystem-

tests. Bei diesenwerdenmehrereModule imVerbund getestet. Auch diese Tests sollten

Testen im Verbund: Dergroße Würfel repräsen-tiert ein Subsystem,das sich wiederumaus Modulen (denkleineren Würfeln)zusammensetzt. DieModule werden imVerbund getestet.

Bild:iStockpho

to/Henvry

* Thomas Sorg... ist Teamleiter Machinery bei derBerner & Mattner Systemtechnik inMünchen.

Jeder weiß, wie wichtig Tests für die Qua-litätssicherung in der Entwicklung vonSoftwaresystemen sind. Ebenfalls eine

bekannte Tatsache: Je später ein Fehler auf-gedeckt wird, desto aufwendiger ist er zubeheben. Dennoch unterlaufen vielen Pro-jekten die gleichen Fehler: Es wird zu spätmit dem Testen begonnen, und wenn Ent-wicklungsaufwändeund -zeitenbereits über-zogen wurden, wird am Test gespart. Man

Testbarkeit undTestautomatisierung

Vieles spricht dafür, die Testbarkeit und -automatisierung als Teil derAnforderungsmodellierung zu betrachten. Denn stetige Tests behebennicht nur Fehler, sondern sichern auch den Entwicklungsprozess ab.

GIORGIO ROSELLI, THOMAS SORG *

Page 13: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

SOFTWARETEST // TESTSTRATEGIEN

automatisiert erfolgen. Subsystemtests sindkomplexer als Tests für einzelne Klassen,weil auchdie getestetenModulverbundebe-reits einehoheKomplexität aufweisen.Den-noch gilt: Subsystemtests lassen sich eben-fallsmit der Technik der Unit-Tests erstellenund vornehmen.Schließlichmuss die gesamteApplikation

getestet werden. Solche Tests werden oft In-tegrationstests genannt. Eine Herausforde-rung dieser Tests sind die externen Schnitt-stellen – die Benutzerschnittstelle, oder be-nachbarte Systeme–derenVerhalten schwernachzubauen ist. Daher werden diese Testsmeist per Hand durchgeführt. Das ist zwaroft nicht ganz zu vermeiden, doch lässt sichdie Technik der Unit-Tests prinzipiell auchauf dieser Ebene anwenden.

Verbesserung der Testbarkeit –Best PracticesEine zentrale Idee, um die Testbarkeit ei-

nes Softwaresystems zu erhöhen, ist dasTeilen und Herrschen. Bekannte Beispieledafür sind die Trennung von Anwendungs-logik undGUI oder die TrennungderAnwen-dungslogik vondenDatenzugriffen. Klassen,die viele statische Abhängigkeiten zu ande-ren Klassen haben, können nur mit großemAufwand isoliert vom Rest des Systems ge-testet werden. Um solche Klassen bessertesten zu können, müssen entweder die Ab-hängigkeiten reduziertwerden, zumBeispieldurch Designprinzipien wie DependencyInjection, oder die Klassen müssen im Ver-bund getestet werden.Da sich erfahrungsgemäß ein Teil der An-

forderungen während der Projektlaufzeitändert, sind iterativeAnsätze sinnvoll. Einer

dieser Ansätze ist das sogenannte Test-Dri-ven Development (TDD), in dem automati-sierte Testfälle bereits vor der eigentlichenFunktion geschrieben werden. Anforderun-genwerdenals Test formuliert. DieserAnsatzist sehr puristisch, kann aber je nach Bedarfangepasst werden. Das Wichtigste ist, dassamEndeder Code automatisch getestetwird.Um Applikationen effizient automatisiert

testen zukönnen, sind gezielteDesignansät-ze erforderlich – etwa die Applikation miteinem internenTestservice auszustatten. EinTestservice versieht dieApplikationmit einerexternen Schnittstelle, die explizit zum Tes-ten verwendet wird. Solch ein Testservicekönnte etwaals zusätzlicheAPI oder alsWeb-service eingerichtet werden.Die Testschnittstelle kannvon einer exter-

nen Testapplikation aufgerufenwerden, dieinnerhalb desselben Test-Frameworks wiedas aller anderenUnit-Tests ausgeführtwird.Damit ist die Basis für den automatisiertenTest der gesamten Applikation geschaffen.

Ein weiterer Vorteil automatisierter Testsliegt in der Möglichkeit, die Applikation inmehrerenKonfigurationen testen zukönnen.EinWegdafür besteht darin, dieApplikationüber ihrenTestservice konfigurierbar zuma-chen. Die externe Testapplikation übergibtvor jedemTestlauf die jeweilige Konfigurati-on. Auf dieseWeise können viele Konfigura-tionen vorbereitet und ausgeführt werden.Diese Konzepte machen deutlich, wie tief

die Qualitätssicherung in die Softwareent-wicklung integriert werden kannund sollte.Die automatische Testbarkeit ermöglichtDauertests, Lasttests und Regressionstests.Wennmanbereits in der Anforderungs- undDesignphase eines Projekts nach Möglich-keiten zur Testautomatisierung sucht und inder Programmierung berücksichtigt, kannman die Qualität von Software in jeder Pha-se der Entwicklung nachweisen. // FG

Berner &Mattner+49(0)89 6080900

Testeditor und Test-plattform in einem: Vorder Entwicklung einerFunktion wird hier ihr Testdefiniert.

Bild:B

erner&

Mattner

www.lauterbach.com/1658

µTrace® for CortexTM-M – Affordable* excellence

* all-included for 1980€

Page 14: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

14

PROJEKTMANAGEMENT // AGILE ENTWICKLUNGSMETHODEN

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Innovation, Geschwindigkeit undAgilität in der Softwareentwicklung

Agilität in den Entwicklungsprozessen hilft Unternehmen, sich an ver-ändernde Anforderungen anzupassen. Dieser Beitrag vergleicht agile

Methoden mit dem traditionellen Wasserfall-Verfahren.

MARKO JAVORNIK*

* Marko Javornik... ist Director of International Servicesbeim Systemhaus Comtrade mit Sitzin Ljubljana/Slowenien.

Das Geschäftsumfeld ist in den letztenJahren sehr instabil undunvorherseh-bar geworden.Aufgrund ihrerGröße,

ihrer komplexen internen Prozesse undRichtlinien reagieren großeFirmennur lang-samaufVeränderungenundgeraten schnellin Schwierigkeiten. Kleine, flexible, agil or-ganisierte Unternehmen, die Innovationenschneller umsetzen, überholen siemit rasen-der Geschwindigkeit.Wie schaffen sie das? Ständige Innovatio-

nen und eine agile Organisation sind derSchlüssel zum Erfolg.

AgileMethoden sind speziell für sehr kom-plexe Projekte und Projekte geeignet, beidenen sichderUmfangwährendder Laufzeitverändert (oder amAnfang nicht exakt defi-niert werden kann). Solche Projekte gibt esimmerhäufiger,weilwir uns auf demWeg ineine auf komplexer Technik basierendeWeltbefinden, die sich anders verhält als die phy-sikalische, an die wir gewohnt sind. Verän-derungen passieren schneller, haben einengrößeren Einfluss und sind weniger vorher-sehbar. Darunter leiden viele Projekte, dieauf einem klassischen Ansatz beruhen.Die Embedded-Software-Entwicklunghat

einigeBesonderheiten, aber letztlich ist auchsie ein Segment der Software-Entwicklung.IhreAbhängigkeit vonHardware bringt eini-ge Probleme mit sich, die aber lösbar sind.Herkömmlichbenutzen viele auf Embedded

spezialisierte Unternehmen das Wasserfall-modellmit der Begründung, simultanHard-ware und Software zu entwickeln. In derheutigen Welt mit Hardware-Simulationenund VHDL-Sprachen wird aber die Hard-ware-Entwicklung rasch beschleunigt. Des-halb sind agile Methoden auch für die Em-bedded-Software-Branche geeignet.

Das Wasserfallmodell versusagile MethodenWir können drei allgemeineUnterschiede

zwischen dem Wasserfallmodell und denagilen Methoden festlegen und zwar im Be-reich der Kundeneinbindung, der Zusam-menarbeit des Entwicklungsteams und derKundenzufriedenheit.Beim Wasserfallmodell werden Kunden

während der Entwicklung üblicherweisenicht einbezogen. Das geschieht erst ab derBetatest-Phase. Bei den agilen Methodensinddie Kunden schon vonAnfang anbetei-ligt – bei regelmäßigenSprint-Review-TreffenoderDemo-Sitzungen, bei denender Projekt-fortschritt gezeigt wird.Das Wasserfallmodell erfordert weniger

Zusammenarbeit im Entwicklungsteam; dieInteraktion istmeist sehr formell und erfolgtüberDokumentationundMemos.WenndasProjekt agil bearbeitetwird, arbeitendieMit-glieder dagegen oft miteinander und eherinformell. Tägliche Besprechungen sind dieRegel, Code-Reviews sindobligatorisch,Dis-kussionenundBrainstorming finden je nachBedarf statt. Es gibt eine enge Zusammenar-beit zwischen den Entwicklungsteams.Die geschilderten Unterschiede spiegeln

sich in der Zufriedenheit der Kunden wider.BeimWasserfallmodell ist erfahrungsgemäßdie Kundenzufriedenheit zuerst sehr hochundbeginnt amEndedesProjekts abzuklin-gen, während bei agilen Methoden die kon-stante Kundenzufriedenheit durch häufigeBereitstellung von funktionsfähigenProduk-ten und durch schnelle Anpassungen angeänderte Anforderungen erzielt wird.

Mit Spaß zu mehr Zufriedenheit: Agile Entwicklungsmethoden sind gut dazu geeignet, die Kundenzufrie-denheit zu steigern, da der Kunde eng in den Prozess eingebunden ist. Aber auch die Arbeitszufriedenheitim Entwicklerteam ist mit agilen Methoden meist höher.

Bild:Erik

Žunec/Comtra

de

Page 15: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

15

PROJEKTMANAGEMENT // AGILE ENTWICKLUNGSMETHODEN

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Das Wasserfallmodell und die agilen Me-thoden unterscheiden sich auch durch dieverschiedenen Projektphasen.� Planung: BeimWasserfallmodell sind dieProjekte durch einen fixen Zeitraum, einfixes Budget und durch fixe Eigenschaftendefiniert, beim agilen Modell kann nur eineSache fix sein – entweder der Zeitraum,das Budget oder die Eigenschaften. Gibt esetwa ein Abgabedatum, dannmuss der Pro-jektumfang sehr flexibel sein. Während desProjekts sind Umplanungen die Regel.� Anfängliche Projektdokumentation: DasWasserfallmodell erfordert eine umfang-reiche Dokumentation, die mit viel Auf-wand verbunden ist und normalerweise imweiteren Verlauf geändert werden muss,während beim agilen Modell das Entwick-lungsteam mit minimaler Dokumentationanfängt – gerade genug, um das Projekt zustarten. Lediglich die groben Anforderun-gen werden zu Beginn festgelegt.� Anforderungen: Beim Wasserfallmodellsind alle Anforderungen im Voraus defi-niert und können später nur mit großemAufwand geändert werden, während beimagilen Modell die Eigenschaften des Pro-dukts im Backlog definiert und währendder Sprints entwickelt werden. Anforde-rungen werden je nach Bedarf hinzugefügtoder verändert. Kundenmüssen sich an derSprint-Planung aktiv beteiligen und die Pri-oritäten regelmäßig im Backlog updaten.� Änderungen und Änderungsanforderun-gen: Im Vergleich zum agilen Modell erfor-dert das Wasserfallmodell hohen Verwal-tungs- und Verhandlungsaufwand. Beimagilen Model werden Änderungen erwartetund können bei jedem neuen Sprint prob-lemlos eingeführt werden.� Entwicklung und Integration von HW/ SW / Firmware: Die Entwicklung beim

Wasserfallmodell besteht aus einer langenmonolithischen Phase, bei der Änderun-gen nicht erwartet werden. Danach folgtdie Integrationsphase. Beim agilen Modellfinden die Entwicklung und die Integrationder Software parallel statt, natürlich unter-stützt von automatischen Überprüfungen.Die Entwicklung und Integration werdenin funktionalen Vertikalen ausgeführt, vonSprint zu Sprint.�Überprüfung: Die Überprüfung findetbeim Wasserfallmodell in einer eigenstän-digen Phase statt, etwa nach der Entwick-lung. Dagegen werden beim agilen Modelleine kontinuierliche Integration und konti-nuierliche Regressionstests vorgenommen,die durch automatisierte Builds und einautomatisches Prüfsystem unterstützt wer-den. Es ist zu empfehlen, dass speziell fürden Zweck des automatischen Prüfens einemaßgefertigte HW entwickelt wird.�Qualitätszusicherung/Programmfehler-quote: Üblicherweise ist beim Wasserfall-modell während der Testphase die Pro-grammfehlerquote sehr hoch. Wegen der

Komplexität des Codes, der noch nie getes-tet wurde, beansprucht die Behebung vonFehlern sehr viel Zeit. Beim agilen Modellwerden die meisten Programmfehler durchdie Regressionstests entdeckt und bereitswährend der Entwicklungsphase behoben.Somit wird schon vor der letzten Testphaseeine hohe Produktqualität garantiert.

Agilität erhöht dieKundenzufriedenheitBei richtiger Anwendung erhöhen agile

Methoden die Kundenzufriedenheit. Dennmehr Gedanken und Energie fließen in denWunsch ein, demKundendas zu geben,waser will. Die Bereitschaft, auf Änderungen zureagieren, steigt. Das führt in der Folge zugrößerer Zufriedenheit.Zuerst könnte es sich einwenigunbequem

anfühlen, da es keinen ausführlichenHaupt-planmit detaillierterAufgliederungderAuf-gaben und entsprechenden Schätzungengibt. Doch man sollte wissen, dass genaueSchätzungen für komplexe Projekte oft sehrunzuverlässig sind,weil sie auf vielen,mög-licherweise auch falschen,Annahmenbasie-ren. Genau diese auf falschen AnnahmenbasierendenAktivitäten könnenverheerendsein.Deshalb schätztmanMethoden, die dieKomplexität erkennen und sich durch itera-tives Denken mit ihr befassen. Damit sinktauchdieWahrscheinlichkeit, dassÄnderun-gen langfristig in die falscheRichtunggehen.Die Bereitschaft, auf Änderungen zu re-

agieren, die Flexibilität und Innovation si-chern nicht nur das Überleben, sondernhelfen Unternehmen, besser zu werden –und verschaffen ihnen einen entscheiden-denWettbewerbsvorteil. // FG

Comtrade+386(0)81605200

Parallelen: Die Embedded-Software-Entwicklunghat einige Besonderheiten, aber letztlich ist auchsie ein Segment der Software-Entwicklung. Daherkönnen agile Methoden durchaus in der Embedded-Software-Branche angewendet werden.

Bild:Erik

Žunec/Comtra

de

Software für Embedded-Systeme

Cert-Kit von Embedded-Office:vorzertifiziertes RTOS für Ihre Hardware

www.embedded-office.de

www.vogel.de

0870

3

analog-praxis.deDer Blog für Analog-Entwickler.

Reinklicken und

mitdiskutieren!

Page 16: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

16 ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Wann Sie Ihr Konfigurations-management-Tool wechseln sollten

Manchmal stößt ein Konfigurationsmanagement-Werkzeug (CM) anseine Grenzen. In diesem Fall ist es anzuraten, nicht einfach nur einneues Tool zu wählen, sondern auch die CM-Strategie zu überdenken.

OLIVER GESING *

* Oliver Gesing... arbeitet seit 25 Jahren in derSoftwareentwicklung. Bei Mixed Modeberät er Kunden zum Thema Konfigu-rationsmanagement.

Wenn das bestehende System zumKonfigurationsmanagement (CM)ersetzt werden soll, kann es dafür

verschiedene Gründe geben: Vormals über-schaubare Projekte können einen Umfangangenommenhaben, der nichtmehr effizientzu verwalten ist. Viele neue Entwickler sinddazugekommen, die sich gegenseitig blo-ckieren, weil paralleles Entwickeln nichtoder nicht ausreichend unterstützt wird.Neue Standorte sollen einbezogen werden,abermit demvorhandenenTool ist ein sinn-volles verteiltes Arbeiten an mehreren Sitesnichtmöglich.Der Entwicklungsprozess sollverbessert oder eine neue Methodik einge-führtwerden,wasmit demaktuellen Systemzu größeren Anpassungen oder Erweiterun-

gen führen würde. Oder das System ist zuteuer, weil hohe Lizenzgebühren zu zahlensind oder die Bedienung zu viel administra-tiven Overhead für die Entwickler bereitet.Doch wann lohnt sich ein Umstieg wirk-

lich? Ist die Entscheidung für einenWechselgefallen, ergeben sich weitere Fragen nachdem geeigneten Tool. Wie wichtig ist dieWahl des CM-Systems überhaupt? Welchesist das Best-In-Class-Tool? Schließlich: Wel-che Daten sollen und könnenmit vertretba-rem Aufwandmigriert werden?Die Umstellung des CM-Tools und die da-

mit verbundeneDatenmigration ist als eige-nes Projekt mit dem dazu gehörenden Pro-jektmanagement zu sehen und zu realisie-ren. Dies ist gerade in größerenOrganisatio-nen unabdingbar, in denen die Umstellungviele laufende Projekte betrifft, die denAufwand für ihre Migration (Schulung, Da-tenmigration, Client-Installation) in ihrereigenenPlanung rechtzeitig berücksichtigenmüssen. Diese Kosten werden sonst oft auf

der Ebene der Entwicklungsprojekte igno-riert.

1. Schritt: Analyse der aktuellenCM-LösungEine der wichtigsten Aktivitäten für die

erfolgreicheUmstellung steht gleich amAn-fangundbesteht in derAnalyse der aktuellenLösung.DazugehörennebenderVerbindungdes Projekts zu Change- und Test Manage-ment die Schnittstellen zu anderen Projek-ten. Die folgenden Fragen können zur Ana-lyse dienen:�Wie groß ist der Projektumfang (Codegrö-ße, Anzahl Entwickler, verteilte Standorte)?�Wie erfolgt die Anbindung an das Build-System?�Wie ist aktuell die Zuordnung vonChangeRequests und Änderungen im Code / Doku-ment realisiert?�Wie erfolgen Übergaben an die Testabtei-lung und an den Kunden?�Wie sind Lieferungen aus anderen Pro-

Code-Management: Die Verwaltung von Programmcode ist die zentrale Aufgabe eines Konfigurationsmanagement-Werkzeugs. Die Wahl des richtigen Tools hängtaber von vielen weiteren Faktoren ab, so etwa der Unterstützung mehrerer Sites oder der Eignung für bestimmte Entwicklungsprozesse.

ANFORDERUNGSMANAGEMENT // KONFIGURATIONSMANAGEMENT

Page 17: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

ANFORDERUNGSMANAGEMENT // KONFIGURATIONSMANAGEMENT

17

jekten, etwa generische Libraries, geregelt?�Wie wird verwendete Third-Party-Soft-ware verwaltet und integriert?

2. Schritt: Analyse der Ziele derCM-UmstellungDie Festlegung der Ziele, die mit der Um-

stellung erreicht werden sollen, zu Beginnder Planung ist eine Selbstverständlichkeit,die aber oft vor derWahl des Tools und seinerFeatures zurücksteht. In vielen ProjektenundOrganisationen ist zu beobachten, dasszuerst das Tool ausgewählt wird und an-schließendderWorkflowandieGegebenhei-ten des Tools angepasst werdenmuss.Wennesmöglich ist, sollte derWegumge-

kehrt sein: Erstwirddas Ergebnis festgelegt,dann suchtmandas für dieses Ziel passendeTool. Gerade in sehr großen Organisationengibt es aber oft oft Richtlinien, nach denenEntwicklungsumgebungenundCM-Systemekonzernweit vorgeschrieben sind. Dann istes besonderswichtig, die erreichbaren Zielezu identifizieren und innerhalb der eigenenOrganisationdarzulegen, umbeimspäterenEinsatz Akzeptanzprobleme zuminimieren.Oft wird eine Verbesserung oder Anpas-

sungdes Entwicklungsprozesses angestrebt,umetwabishermit verschiedenenTools ver-waltete Daten aus dem Requirements Engi-neering, demChangeManagement oder demTest Management zusammenzuführen. Da-durch lässt sichdieNachverfolgbarkeit (Tra-ceability) von Änderungen und des Work-flows von den Requirements bis zum Testverbessern. Oft stellt dies ein angestrebtesQualitätsziel dar, um Vorgaben eines Stan-dards wie SPICE oder CMMI zu erfüllen.Auchdie Steigerungder Performance kann

ein Ziel sein. Zu denken ist dabei nicht nuran die reine Toollaufzeit bei regelmäßigenOperationenwieMergen, Labeln oder Base-lining, sondern auchan effizientere Integra-tion zwischen Standorten und höhere Inter-operabilität mit anderen Tools aus demChangeManagement oder demRequirement

Engineering. Schließlich kann auch die Re-duzierungder Entwicklungskosten eineRol-le spielen.DieNeuausrichtungder CM-Strategie soll-

te immer mit ausreichender Vorbereitungerfolgen und durch Evolution aus der bishe-rigen hervorgehen. Auch in großen Organi-sationen ist schon die radikale Tool-Umstel-lung an der unzureichenden Planung ge-scheitert undhat hoheKostenbeimerzwun-genen Rückschritt auf die vorherige Lösungverursacht. Deshalbmüssen vonBeginnderPlanung an alle Aspekte der Projektland-schaft berücksichtigt werden: Abhängigkei-ten und Lieferbeziehungen zu anderen Pro-jekten, Integration und Test, Standorten,eventuell auch zu Lieferanten und Kunden.

3. Schritt: Entwicklung der CM-StrategieAuch in der neuen Entwicklungsumge-

bung sollte die gelebte Team- bzw.Unterneh-menskultur erhaltenbleiben.Nicht zuunter-schätzen können die Widerstände der Ent-wicklungsmannschaft bei der Einführungeines neuen Tools sein. Dies kann jeder er-fahren, der versucht, von oben herab auchnur einen anderen Editor einzuführen. Hin-zu kommt, dass gerade Entwickler oft denAufwand für die SW-Versionierung als Beein-trächtigung ihrer kreativenArbeitenbetrach-ten und deshalb frühzeitig in den Entschei-dungsprozess eingebunden werden sollten.Information über die Vorteile der neuenUmgebungundAufklärungdarüber,welcheVerbesserungen im Entwicklungsprozessdamit verfolgtwerden, erhöht dieAkzeptanzbei den Anwendern, die es später in ihrertäglichen Arbeit einsetzen.

4. Schritt: Umsetzung der CM-StrategieNachdem die Ausgangslage und die Ziele

bestimmt sind, kann die Entscheidung fürdas CM-Tool getroffenwerden,mit demmanam besten die Ziele erreichen kann. Dabei

Rational Team Concert:Der Screenshot der RTC-Umgebung zeigt dieenge Verknüpfung vonChange Management,Task Management,Source Control undBuild Managementinnerhalb einer einheit-lichen Oberfläche.

Bild:M

ixed

Mod

e

Sehen Sie sich daskostenlose epaper an:

www.elektronikpraxis.de/gehaltsreport

Gehalts-gesprächerichtig

führen

AktuelleGehälterim Überblick

0995

1

Page 18: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

18

ANFORDERUNGSMANAGEMENT // KONFIGURATIONSMANAGEMENT

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

werdenauch Budgetüberlegungen eineRol-le spielen. In vielen Fällen mag eine OpenSource-Lösungwie Subversion,Git oderMer-curial ausreichen. Diese Systeme haben zu-demden Vorteil, dass sie oft auch Berufsan-fängern vom Studium her vertraut sind. Al-lerdings sind diese Tools meist auf die Auf-gabe der Versionierung beschränkt; eineModellierung des eigenen Workflows erfor-dert zusätzlichen Aufwand. Aktuelle kom-merzielle Tools gehen in die Richtung integ-rierter Entwicklungsumgebungen, dieUnter-stützung und eine gemeinsame Datenhal-tung für verwandte Disziplinen wie ChangeManagement, Requirements Engineeringund Test Management bieten –mit dem Zieleines umfassenden Application-Lifecycle-Managements (ALM) oder Product-Lifecycle-Management (PLM).Die Hersteller versuchen dies auch bei ih-

ren schon länger auf dem Markt erfolgreichvertretenen Produkten durch die Entwick-lung von Integrationen zwischen den Diszi-plinen. Jedochbleibt dabeimeist die tatsäch-liche Integrationsfähigkeit der unterschied-lichen Tools beschränkt. Hier lohnt sich eingenauerer Blick in Verbindung mit einerTestinstallation, obderDatenaustauschundder Workflow zwischen den Disziplinen rei-bungslos funktionieren, da selbst Produkteeines Tool-Herstellers nicht immerursprüng-lich aus einerHandkommenunddurch ihreEntstehungsgeschichte nicht selten auf in-kompatiblen Architekturen beruhen. Neue-re, konsequent auf Integration setzendeKonzepte wie das auf der Jazz-Plattform ba-sierende Rational Team Concert von IBMgehen hier deutlich weiter.Bei der Vielzahl der angebotenen Lösun-

gen sollte bei der Entscheidung auch dieFlexibilität gegenüber zukünftigenStrategie-änderungen berücksichtigt werden, wennspäter einmal weitere Disziplinen integriertwerden sollen. Auf der anderen Seite stellt

das ConfigurationManagement eine so zen-trale und in alle Entwicklungsbereiche hin-ein wirkende Funktion dar, dass auch einelängerfristige, also aufmehrere Jahre ausge-richtete, stabile Tool-Umgebunggesucht ist.Das CM-Tool wechselt man ja sicher nicht(ohne größte Not) jährlich!Die Einführung des Tools muss nun mit

den Leitern der aktuellen Projekte abge-stimmt werden, um die aus dem alten Tool

zuübernehmendenDaten abzustimmenundeinen geeigneten Zeitpunkt für die Umstel-lung zu finden.Aufgrundder unterschiedlichenDatenhal-

tungen gibt es nur zwischen den wenigstenCM-Systemen Transfer- oder Importverfah-ren, die nebendemeigentlichen Inhalt aucheine komplette Übernahme der Metadatenwie Label, Kommentare, VerknüpfungenundÄhnliches erlauben. Deshalb sollte mit denProjekten eine möglichst geringe Zahl anwichtigenBaselines identifiziertwerden, diein dasneueSystemmigriertwerden. Bei län-ger laufenden Projekten kann dies ein güns-tiger Zeitpunkt sein, um alte Daten zu ent-rümpelnunddie Projekthistorie zu entschla-cken, was in vielen CM-Systemen sonst nurmit größerem Aufwandmöglich ist.

Der Umstiegstermin muss kluggewählt werdenDa die mehr oder weniger umfangreiche

Datenmigration zwischenmehrerenStundenund einigen Tagen in Anspruch nehmenkann, ergibt sich für die Projekte eine Zeit-spanne, in der nicht eingecheckt werdenkann. Der Umstiegstermin muss daher sogewählt werden, dass er nicht gerade miteiner hektischen Freigabephase kollidiert.Auchandieser Stelle ist gelegentlich Finger-spitzengefühl gefragt, denn einen idealen,unkritischen Zeitpunkt gibt es im laufendenProjekt naturgemäß nie.Für besonders kritischeProjekte empfiehlt

sich neben den nötigen internen Tests eineTestmigration auf einen Testserver, mit derbei der Migration auftretende Fragen oderProbleme in Zusammenarbeitmit einzelnenKey-Usern aus demProjekt frühzeitig analy-siert und geklärt werden können.Zum Rollout auf dem Produktivsystem

werden die neuen Tool-Clients zur Installa-tion verteilt und Trainings für die Anwenderabgehalten.Die Schulungen solltennicht zufrüh stattfinden, sondern zeitnah zum tat-sächlichen Einsatz des neuen Tools und ne-ben dem reinen Tool-Gebrauch auch denneuenWorkflow darstellen undmotivieren.Wenn die genannten Punkte berücksich-

tigt worden sind, hat man in der Vorberei-tung alles für eine erfolgreiche Tool-Einfüh-rung getan und ist auf die Unwägbarkeitender Umstellungsphase gewappnet.Der Schlüssel zum Erfolg liegt in der Vor-

bereitungundderAnalyse undnicht so sehrin der Funktionalität des Werkzeugs, denndas Tool, das allen Anforderungen optimalentspricht, gibt es nicht. // FG

MixedMode+49(0)89 89868200

Mehr als ein Archiv:Modewrne Konfigurati-onsmanagement-Toolsintegrieren mehrereDisziplinen wie dasRequirements Engi-neering, das ChangeManagement oder auchdas Test-Management.

Bild:W

ikimediaCommons/MarcusGo

ssler/CC-BY-SA

3.0

PRAXISWERT

Vor dem Tool-Kaufsteht die PlanungEin Konfigurationsmanagement-Werkzeug wird man in der Regel nichtallzu oft wechseln. Wenn aber dasTool an seine Grenzen stoßen sollte,empfiehlt es sich, nicht nur das Nach-folge-Werkzeug sorgsam auszuwäh-len, sondern auch die Konfigurations-management-Strategie zu prüfen undgegebenenfalls neu auszurichten. .

Gute Planung tut notVon zentraler Bedeutung ist es, dieKonfigurationsmanagement-Strategieklar zu definieren. Nach Möglichkeitsollten erst die Ziele festgelegt unddann das Werkzeug ausgewählt wer-den. Alle Aspekte der Projektland-schaft sind dabei zu berücksichtigen.Sonst droht die Gefahr, dass die Tool-Umstellung an mangelhafter Planungscheitert und ein Rückschritt auf diealte Lösung nötig ist.

Page 19: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

Fünf Tage EmbeddedSoftware Engineering pur:

Alles, was Sie für IhreProjekte wissen müssen.

1023

1

P R O G R A M M - H I G H L I G H T S

1.–5 . Dezember 2014 , Kongresszentrum, Sindel f ingen

HAUPTSPONSOREN

VERANSTALTER

Keynote: Dienstag, 2. Dezember 2014, 12:35 Uhr

TheWay Ahead in EmbeddedSoftware Engineering

Jack Ganssle,The Ganssle Group

Keynote: Mittwoch, 3. Dezember 2014, 12:35 Uhr

Wie viel, wie wenig Software Engineeringkönnen Sie sich leisten?

Prof. Dr. rer. nat. Jochen Ludewig,Universität Stuttgart

Keynote: Donnerstag, 4. Dezember 2014, 12:35 Uhr

Anytime, Everywhere: Human-ComputerInteraktion im 21. Jahrhundert

Univ.-Prof. Dr. Manfred Tscheligi,Universität Salzburg

Informieren Sie sich unter:--> www.ese-kongress.de

Weitere Informationen:Sabine Pagler | +49 (0)89 4506 1746 | [email protected]

Page 20: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

20

INTERNET DER DINGE // BETRIEBSSYSTEME

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Sicherstellung des zuverlässigenBetriebs vernetzter IoT-Geräte

Konnektivität und Zuverlässigkeit lauten zwei der wichtigsten Anforde-rungen an Geräte, die mit dem IoT vernetzt sind. Echtzeitbetriebssyste-me (RTOS) tragen zur sicheren Trennung wichtiger System-Tasks bei.

ANDREW CAPLES *

* Andrew Caples... ist Product-Marketing-Managerbei der Embedded Software Division(ESD) von Mentor Graphics.

Das Internet der Dinge (Internet ofThings– IoT) umfasst Anwendungenvon sogenannten Wearables über

Smart-Meter und intelligenteHaushaltsgerä-te bis hin zuAutos. FaktorenwieBetriebszeitundZuverlässigkeit spielenbei diesenGerä-ten eine zentrale Rolle. Ein intelligentesHaushaltsgerät und eine Infotainment-Head-Unit imAutomobil stehen für eineKlasse vonIoT-Systemen, die sowohl Konnektivität alsauch zuverlässige Ausführung erfordern.Ein Echtzeit-Betriebssystem (RTOS) mit

einem isoliertenProzessmodellwieNucleusvonMentorGraphics erlaubt es Code-Modu-le mit Hilfe der Memory Management Unit(MMU), die auf vielen System-on-Chips (SoC)verfügbar ist, zu isolieren und zu schützen.Bild 1 zeigt, wie Echtzeit-Steuerungsaufga-ben den geschützten Speicherbereich ge-meinsamnutzen,während sich die anderen

Software-Tasks in ihren voneinander ge-trenntenundgeschütztenSpeicherbereichenbefinden. Die Funktionen für Konnektivitätund ferngesteuerte Aktualisierung nutzendie gleichen Bereiche, während die UI undsonstigeApplikations-Tasks anderen isolier-ten Bereichen zugewiesen werden. DieserAnsatz zur Isolierung der Subsysteme fürAnwendungen schützt Funktionen im Kon-nektivitäts- oder Benutzeroberflächen-Sub-systemdavor, denKernel oder Echtzeit-Steu-erungsaufgaben zu korrumpieren.

Echtzeit-Kernel garantiert Lauf-zeiten für wichtige TasksEiner der Vorteile eines RTOS ist die Echt-

zeit-Natur desKernels. EinRTOSbietet hartesEchtzeit-Scheduling mit garantierten Lauf-zeiten für Tasks mit hoher Priorität. EinProzessmodell-fähiges RTOS bewahrt beimHinzufügen des Speicherschutzes determi-nistisches Echtzeit-Scheduling. Der Spei-cherschutz verändertweder die Priorität derAufgaben noch die Reaktionsfähigkeit desSystems. Bild 2 zeigt, dass die Benutzeran-wendung (Task 7) und die Remote-Update-

Task, obwohl sie sich in verschiedenen, iso-lierten Speicherbereichen befinden,mit dergleichen Prioritätsstufe ausgeführt werdenkönnen. Steuerungs- und Konnektivitäts-Tasks werden dagegen mit einer höherenPriorität ausgeführt. Dies ist eine erheblicheAbweichungvonderArt undWeise,wie Pro-zesse bei einem Allzweck-Betriebssystemimplementiert sind. In der geschütztenRTOS-Umgebung kann der Entwickler diePrioritätenderAufgaben individuell einstel-len, ohne dass sie in einer gemeinsamenSpeicherregion kombiniertwerdenmüssen.Ein RTOS, das auf einem Prozessmodell

basiert, erlaubt den Prozessmodulen (eineSammlung aus Tasks oder Bibliotheksfunk-tionen innerhalb eines gemeinsamen isolier-ten Speicherbereichs), dass siewährenddesSystembetriebs dynamisch geladenundent-laden werden. Neben der Möglichkeit einesSystem-Updates kann der Entwickler einGerät für verschiedene Betriebsarten dyna-misch neu konfigurieren und zwischen di-versen Konfigurationen der Task-Isolierungund Priorität hin und her wechseln.Die Mehrkern-Prozessoren in heutigen

Embedded-Gerätenmachen die Konsolidie-rung mehrerer Betriebssysteme zu einempraktikablen und sicheren Ansatz für dieSicherstellung der Konnektivität sowie derordnungsgemäßen Ausführung von wichti-geren Funktionen. Selbst im Automobil, wodie Sicherheit extrem wichtig ist, erwartendie Verbraucher, dass ein IVI-SystemZugriffauf Applikationen bietet, die auf Smartpho-nes und Tablets zu finden sind.Vor dem IoT und vernetzen Fahrzeugen

wurdenSicherheit undZuverlässigkeit durchmehrere getrennte Prozessoren erreicht. Dasgarantierte ein robustesDesign. Bei denheu-tigen konsolidierten Embedded-Systemenempfiehlt sich die Verwendung mehrererBetriebssysteme, die durch einenType-1-Hy-pervisor getrennt sind.DerHypervisor trenntund virtualisiert die Geräteressourcen undgewährleistet, dass wichtige Fahrzeugfunk-

Bild 1: Trennung der Steuerungsaufgaben von der Konnektivität und den Remote-Updates durch ein Pro-zessmodell

Quelle:M

entorG

raph

ics

Page 21: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

21

INTERNET DER DINGE // BETRIEBSSYSTEME

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

tionen eine höhere Priorität als vernetzteAnwendungen erhalten.Ein Hypervisor geht über die einfache

Trennung hinaus. Er bietet auch einen Me-chanismus, um den Zugriff von Peripherie-komponenten auf bestimmte Anwendungs-bereiche zu beschränken. Im Falle einesIVI-Systems kann man den Zugriff auf denCAN-Busdes Fahrzeugs beschränken, indemdem Fahrzeug-Infotainment-System nur Zu-griff auf CAN-Daten erlaubt wird und beivernetzten Apps in Android der Zugriff aufDatennur über die Interprozesskommunika-tion (IPC)mit demLinux-basiertenFahrzeug-Infotainment-Applikationen erfolgt. Gleich-zeitig sollen sowohl Linux als auch AndroidZugriff auf die lokale SD-Cardmit denMulti-media-Daten haben. Ein Hypervisor kannPeripheriekomponentendirekt abbildenundparavirtualisieren, also eine Schnittstelle zuihnenbereitstellen. Dies erlaubt es Entwick-lern, den Zugriff auf den CAN-Bus zu be-schränken und andere Ressourcen wie dieSD-Karte gemeinsam zu nutzen.

Over-the-Air-Aktualisierungmuss eingeplant werdenWir haben zwei mögliche Ansätze für das

Design von IoT-Systemendargestellt: dieVer-wendung eines RTOS und eines Type-1-Hy-pervisors. Der idealeAnsatz hängt vomkon-kreten Gerät ab. Alle vernetzten Systemeprofitieren jedoch von Tests, die das korrek-te Arbeiten im Feld sicherstellen. Automati-sierte Sicherheitstests und Stresstests anvernetzten Geräten sind ein Beispiel, umAusfälle im Protokoll-Stack oder in Prozess-steuerungsfunktionen festzustellen. Zudemlässt sich das Funktionieren eines GerätesmitHilfe simulierterAngriffe ermitteln.Wei-tere notwendige Tests sind das Senden vonungültigen oder fragmentierten Paketen so-wie die Ausführung von Test-Frameworks,die bekannte Schwachstellen im Software-Stack ausnutzen. Diese Tests können dieRobustheit der vernetzen IoT-Geräte wäh-rend des Betriebs erhöhen.Benutzer vonMobilgeräten sinddamit ver-

traut, dass sie ihr Gerät häufig aktualisierenmüssen, umFehler zu patchen, Sicherheits-updates vorzunehmenoder die Performancezu erhöhen. All dieswirdmühelos „über dieLuft“ erreicht. Sowohl das Prozessmodell-basierte RTOSals auchdieVerwendung einesType-1-Hypervisors erleichtern das DesignvonEmbedded-Systemen, die sicher über dieLuft aktualisiert werden können. Durch dieAbtrennung des Anwendungs-Subsystems,das dynamisch geladen und entladen wer-denkann, erlaubenbeideAnsätze dasUpda-ten spezieller Subsysteme, dasBehebenvon

Fehlern oder das Lösen vonZuverlässigkeits-problemen während des Einsatzes im Feld.Die Bandbreite der IoT-Geräte erfordert

häufig, dass Entwickler Code aus diversenQuellen wie eigenen, kommerziellen undOpen-Source integrieren. All diese QuellenerhöhendasRisikonegativerAuswirkungenauf die Reaktionsfähigkeit und Zuverlässig-keit eines vernetzten IoT-Gerätes. Ein RTOSmit einemProzessmodul zurAbtrennungderAnwendungs-Subsysteme und einem Type-1-Hypervisor zur Konsolidierung mehrererBetriebssysteme ist ein sinnvollerAnsatz zur

Vernetzung von Anwendungen und Syste-men, die einen hohen Sicherheitslevel oderZuverlässigkeit in derAusführung erfordern.NebenderAuswahl der Systemarchitektur

und Technik müssen Designer auch die Zeitfür Tests zur Gewährleistung des Betriebseinplanen, die Betriebsdauer des Geräts be-denken und die Möglichkeit berücksichti-gen, die Software möglichst schnell, naht-undmühelos zu aktualisieren. // FG

Mentor Graphics+49(0)89 570960

Bild 2: Das Prozess-modell trennt kritischeBereiche innerhalbeines Echtzeitbetriebs-systems

Quelle:M

entorG

raph

ics

Page 22: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

22

INTERNET DER DINGE // ENTWICKLUNGSSTRATEGIEN

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Fünf Überlegungen zurEntwicklung sicherer IoT-Systeme

Es gibt zahlreiche Herausforderungen bei der Konzeption und Entwick-lung von Lösungen für das Internet der Dinge (IoT). Der Beitrag liefert

einige Grundgedanken für den Bau sicherer Systeme.

DAVID KLEIDERMACHER *

* David Kleidermacher... ist Chief Technology Officer vonGreen Hills Software.

Zahlreiche Herausforderungen bedro-hen das immense Potenzial des Inter-net der Dinge (IoT). Die Entwickler der

intelligenten „Dinge“ müssen sich folgendeFragen stellen:�Wie lässt sich die Privatsphäre und Si-cherheit (Safety & Security) der Informatio-nen und Funktionen schützen, die den IoT-Einrichtungen anvertraut werden?�Wie kann eine neue Generation von Ent-wicklern – viele davon mit wenig oder kei-ner Erfahrung im Bereich Embedded-Soft-

wareentwicklung – zuverlässige, effizienteund sichere Produkte entwickeln?�Wie können erfahrene Embedded-Ent-wickler die technischen und geschäftlichenHerausforderungen meistern, die mit derIntegration von Systemen in die Cloud ein-hergehen?

1. Wenden Sie eine Zero-Trust-Datenschutzstrategie anEiner der Irrtümer bei IoT-Sicherheit ist,

dass Lösungsanbieter ihre Investitionen aufdie Stärkung des Cloud-Rechenzentrumsausrichtenkönnen.Dabei ignorieren sie aberdie Sicherheit der einzelnen IoT-Einrichtun-gen. Im Cloud-Zeitalter ist diese Denkweisegefährlich und im IoT-Zeitalter geradezu tö-richt. Angreifer suchennachdemschwächs-ten Glied. Und wenn IoT-Einrichtungen nur

schwach geschützt sind, sind sie ein Ziel. Isteine dieser Einrichtungen erst einmal in Be-schlag genommen, können Angreifer damitZugriff auf die zentralen Informationen ineinem Rechenzentrum erlangen.Ein weiterer Irrtum ist, dass es an den

Cloud-Grenzen nicht viel Schützenswertesgäbe. IoT-Einrichtungen erzeugen aber um-fangreiche,wertvolle undprivate Informati-onen – über den Gesundheitszustand, sozi-aleAktivitäten, denAufenthaltsort etc. –undsind daher ein wertvolles Ziel für Hacker.Da das IoT immer komplexer wird, ist es

für Entwickler praktisch unmöglich zu wis-sen, wie Daten über das Internet transpor-tiert werden, geschweige denn, den Daten-fluss zu steuern und ob die verschiedenenSysteme entlang des Weges vertrauenswür-dig sind. IoT-Entwickler und deren Kundenmüssen eine Null-Vertrauen-Strategie an-wenden, die dieDatenschutzverantwortungvon Geräten, Einrichtungen, Kommunikati-onsprotokollen und Cloud-Diensten ab-trennt. IoT-Datenschutz ähnelt demContent-Protection-Problem bei digitalen Medien.Dateneignermüssenüber Tools verfügen, dieflexible Richtlinien für autorisierten Zugriff,Verteilung und Zugriffskontrolle erstellen –unabhängig davon, wie sie das Internetdurchqueren. Ein amKörper getragenesme-dizintechnisches Gerät kann zum Beispieldie vor Ort erzeugten Informationen ver-schlüsseln. Der Code-Schlüssel wird überden Nutzer gesteuert und nur mit demDienstanbieter des Geräts ausgetauscht.

2. Verwenden Sie eine sicherePlattform-ArchitekturDie Plattform-Sicherheit von IoT-Einrich-

tungen beginnt mit einer Hardware Root ofTrust unterhalb jeglicher Softwareebene.Dabei handelt es sich imeinfachstenFall umeinen manipulationssicheren Code-Schlüs-sel-Speicher, der zumindest ein sicheresBooten der Firmware und der zugehörigensicherheitskritischen Komponenten garan-

Schaubild 1: Eine Architektur für IoT-Geräte wie etwa Point-of-Sale-Systeme. Die PoS-Architektur nutzt eineleichtgewichtige kritische Applikation, den Tokenizer, um die personenbezogenen Informationen zu verar-beiten. Der Tokenizer läuft direkt auf einem hochsicheren Mikrokernel-Hypervisor.

Bild:G

reen

Hills

Softw

are

Page 23: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014 23

INTERNET DER DINGE // ENTWICKLUNGSSTRATEGIEN

tiert. Die Boot-Sequenz muss Hardware-rootedCode-Schlüssel verwenden, umdieseKomponenten vor dem Start einer Signatur-prüfung zuunterziehen.AnschließendkanndieHardwareRoot of Trust auch für die Fern-abfrage und zumSchutz der Code-Schlüsselfür die Authentifizierung und Verschlüsse-lung verwendet werden. Falls ein Angreiferversucht, kritische Software mit Schadcodezu überschreiben, wird der Beglaubigungs-prozess dies erkennen.NachdemsicherenStart ist die ausführen-

de Software (Betriebssystem, Hypervisoroder TEE) der wohl wichtigste Baustein fürsichere IoT-Einrichtungen. Es lassen sichkeine sicheren Anwendungen oder IoT-Ein-richtungen auf einem unsicheren Betriebs-system oder Hypervisor entwickeln. DieseSoftware Root of Trust hat idealerweise fol-gende Eigenschaften:�Hohe Sicherheit: design- und implemen-tierungs-zertifizierbar nach strengsten Si-cherheitsstandards (etwa Common CriteriaEAL 7), einschließlich formalem Sicher-heitsnachweis;� Skalierbar: in der Lage, einfache Echt-zeit-Lasten bis hin zu umfassenden Linux-Betriebssystemen und Stacks zu unterstüt-zen (und beides gleichzeitig);

�Offen: mit einer Laufzeitumgebung undAPI, die offenen Standards entspricht undInteroperabilität sowie Software-Wieder-verwendung fördert.Diese Prinzipien zur Plattform-Architektur

geben Entwickler ein leistungsfähiges Tool-Paket an die Hand, mit dem sie sichere IoT-Systeme erstellen können. Um dies zu de-monstrieren, dient derHackerangriff auf dieTarget Corporation als Beispiel (der zweit-größte Discount-Einzelhändler in denUSA).Wie hätte man diesen Angriff verhindernkönnen? Indie PoS-Terminals (Point of Sale)von Target und Home Depot (größte Bau-markt-Kette in den USA) wurde Schadsoft-ware eingeschleust, die Kontrolle über dieSpeicherinhalte (RAM) übernahm und sopersönliche Informationen abgriff.Eine fortschrittliche PoS-Architekturwür-

de ein depriviligiertes OS und eine einfachesicherheitskritischeAnwendung (Tokenizer)nutzen, um persönliche Informationen zuverarbeiten. Der Tokenizer läuft direkt aufeinemThingvisor, einemhochsicherenMik-rokernel-basiertenHypervisor, undverwaltetdas Kartenlesegerät, über das die Zahlungerfolgt. Der Tokenizer nutzt eine sichereVer-bindung zu einemBackend-Web-Service, umpersönliche Informationen abzugleichen,

Schaubild 2: Die Grafik zeigt den gesamten IoT-Firmware-Stack. Sie zeigt deutlich das Konzept mehrerersicher gegeneinander abgeschotteter Web-Service-Komponenten, ein Linux-Gastbetriebssystem (rot) sowieEchtzeit- und sicherheitskritische Komponenten.

Bild:G

reen

Hills

Softw

are

Sichere Software entwickeln mit PHASEÜberlegungen zur Architektur sind imHinblick auf sichere Systeme im Inter-net der Dinge äußerst wichtig. Abersie sollten von der richtigen Entwick-lungsmethode begleitet werden. DavidKleidermacher, der CTO von Green HillsSoftware, empfiehlt einen integrierten

Ansatz namens PHASE (Principles ofHigh Assurance Software Engineering).Er basiert auf den Grundsätzen: 1) mini-male Implementierung, 2) Aufteilung inKomponenten, 3) Least-Privilege-Prin-zip, 4) sicherer Entwicklungsprozess und5) Validierung durch externe Experten.

www.vogel.de

facebook.com/elektronikpraxis

youtube.com/elektronikpraxistv

gplus.to/elektronikpraxis

www.analog-praxis.de

xing.com/net/elektronikpraxis

twitter.com/redaktionEP

Page 24: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

24

INTERNET DER DINGE // ENTWICKLUNGSSTRATEGIEN

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

führt eine virtuelle Kartenabfragedurchunderstellt ein Token. Dieseswird andasOSdesPoS-Systemweitergeleitet. DasOSkann zwardurch Schadsoftware infiltiert sein, es kön-nen jedoch keine persönlichen Informatio-nen gestohlen werden.Die Thingvisor-basierte PoS-Architektur ist

in Schaubild 1 dargestellt undwurde auf derNRF Big Show (US National RetailFederation's Annual Convention & EXPO)demonstriert. Target hat diesesKonzept ver-passt, aber es ist noch nicht zu spät für dasUnternehmen und andere Einzelhändler,einen solchen vertrauenswürdigen Ansatzfür PoS-Systeme zu installieren.

3. Nutzen Sie professionelleEntwicklungswerkzeugeFür das IoT interessiern sich unterschied-

lichste Entwickler, vondenenviele nurwenigprofessionelle Erfahrung imBereichEmbed-ded-Programmierung haben.Viele Entwick-ler habenwenigAhnungdavon,wie richtigesDebugging erfolgt und folgen keinenRegelndes Entwicklungsprozesses zur Erstellungeines zuverlässigen Produkts. Das mag fürHobby-Projekte genügen, wird sich aber fürdie Serienfertigungoder für einenMarktein-tritt, bei demhöhereQualität oder sogar eineZertifizierunggefordert ist, nicht etablieren.Bei einer professionellen Entwicklungs-

umgebung für IoT-Systemekommt es daraufan, dass sie leicht zu erlernenundanzuwen-den ist. Man sollte die langfristigen Auswir-kungen einer optimierten Entwicklung, Er-probung undWartung nicht unterschätzen.Das Gleiche gilt für die Hardwareplatt-

form: Ein Mikroprozessor, der JTAG-Debug-ging und Laufzeit-Programm-Trace-Funkti-onen bietet, um komplizierte Fehler zu fin-den, sorgt für geringere Entwicklungskosten

und eine schnellere Markteinführung. Daswird oft übersehen, da der Fokus meist aufderWahl der CPU-Taktfrequenz, RAM-GrößeundMaterialkosten liegt.Geradedie beliebtesten IoT-Anwendungen

wie der Nest-Thermostat und verschiedeneSmartwatches laufenunter Linux.Mit seiner

Open-Source-Lizenzierung sowie breitenVerfügbarkeit von Entwicklern und Anwen-dungen hat Linux eine zentrale Position inder Laufzeit-Strategie für das IoT.

4. Linux implementieren – abermit VorsichtAllerdings bereitet LinuxProblemebei der

Skalierung auf Low-End-Designs (Platzbe-darf, Batterielebensdauer undPerformance).Es weist Echtzeit-Einschränkungen auf undbietet nicht die Sicherheit (Safety & Securi-ty), die man für eine zukunftssichere IoT-Strategie benötigt. Auchhier ist der Thingvi-sor von Vorteil. Er wandelt Linux in eineIoT-optimierte Linux-Version um, wobei Li-nux oberhalb der Software Root of Trustläuft. In Automotive-Designs kann sicher-heitskritische Software (CAN-Treiber, Rück-fahrkamera, etc.) auf dem Mikrokernel ge-hostet sein, undLinuxwirdnur für dieGrafikund Kommunikations-Stacks verwendet.VieleMiddleware-Lösungen erheben ihren

Anspruch, die Informationsschaltzentrale(Backbone) des IoT zu sein. KonkurrierendeKonsortien wie AllSeen und Open Intercon-nect Consortium, sowie die Vielzahl an Pro-tokollen – MQTT, XMPP, AMQP, COAP, DDS– sorgen fürVerwirrungbei denEntwicklern.

5. Web-orientierte Kommunika-tionsstrategien nutzenZu berücksichtigen sind Faktoren wie das

Kommunikationsmodell (PubSub, Peer-to-Peer, Client-Server), das Service-Discovery-Modell, die Datendarstellung, Overwrite vs.Queue, die Abhängigkeit von einem zuver-lässigen Transport (TCP), QoS-Funktionen(Quality of Service) etc. Eine weitere Vertie-fung würde den Rahmen dieses Beitragssprengen. Letztlich verwenden die meistenIoT-Einrichtungen die lingua franca des In-ternets, RESTful Web Services über HTTPund COAP (für eingeschränkte Funkanwen-dungen), da sie IoT-Einrichtungen erlaubt,die sich schneller und nahtlos in das Webintegrieren lassen.Schaubild 2 zeigt den IoT-Firmware-Stack

auf einen Blick, einschließlich mehrerer si-cher partitionierterWeb-Service-Komponen-ten, Linux-Gastbetriebssystemenund sicher-heitskritischen Komponenten.Die Zahl der ans Internet angeschlossenen

Geräte hat inzwischen die Zahl der Internet-Nutzer überschritten.Dies ist nur derAnfangeiner Ära, die von intelligenten Objektendominiert seinwird, die neueGeschäftsmög-lichkeiten für Entwickler eröffnen. // FG

Green Hills Software+49(0)228 4330777

Target-Einkaufszentrum in West Hollywood, Kalifornien: Im Herbst 2013 wurde die Supermarkt-Kette Targetzum Opfer des bisher umfangreichsten Hacker-Angriffes auf ein Handelsunternehmen in den USA. Es ge-lang, Malware in die Sicherheits- und Bezahlsysteme einzuschleusen. 40 Millionen Kreditkarten-Datensätzewurden auf diese Weise entwendet.

Bild:W

ikimediaCommons/CC-BY-SA

3.0

PRAXISWERT

Für ein sicheresInternet der DingeIn naher Zukunft dominieren smarteObjekte das Internet, die unser Lebeneinfacher machen und bedeutendegeschäftliche Chancen erschließenwerden. Um aber diese Vision zu er-füllen, ist es wichtig, methodischeund technische Ansätze für die Ent-wicklung sicherer Applikationen imInternet zu berücksichtigen.

Eine kombinierte StrategieEntwickler und Produktmanager soll-ten sich darüber klar sein, dass An-greifer immer nach dem schwächstenGlied in der Kette suchen. Außerdemgenerieren Geräte, die im Internet derDinge genutzt werden, eine Menge ansensiblen Daten. Zero-Trust-Strategi-en, sichere Architekturen, die richti-gen Werkzeuge und eine web-orien-tierte Kommunikationsstrategie sinddeshalb unerlässlich.

Page 25: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

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: Franz Graser (fg), Tel. (09 31) 4 18-30 96Redaktion 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;Volontärin: Lea Drechsel (ld), Tel. (09 31) 4 18-31 03Freie Mitarbeiter: Prof. Dr. Christian Siemers, FH Nordhausen und TU Clausthal; Peter Siwon,MicroConsult; Sanjay Sauldie, EIMIA; Hubertus Andreae, dreiplusVerantwortlich für die FED-News: Dr. Stephan Weyhe, 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:Michaela Deppe, Joachim Haselmann, Meike Herkersdorf, Sigrid Rau, Elena Anetzberger

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. 2014.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).

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

Abonnement Ausland: jährlich 228,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-2857; [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, 3321 Ashbourne CircleSan Ramon, CA 94583, 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.

Impressum

EDA

1001

2

Die Fachbücher für Ihre Aus- und Weiterbildung imtechnischen Beruf.E-Mail: [email protected], Tel.: 0931 418-2419

www.vogel-buchverlag.de

Der Weg zumLabVIEW-Könner

Reim, Kurt

LabVIEW-KursGrundlagen, Aufgaben, Lösungen

280 Seitenzahlreiche Bilder1. Auflage 2014ISBN 978-3-8343-3294-329,80 €

Ein Fachbuch der

Mit Studentenv

ersion

2013 auf CD-

ROM

28za

29

Der Lab-VIEW-Kurs erleichtert allen Einsteigern dieersten Schritte mit der mächtigen Entwicklungsum-gebung für mess-, steuer- und regelungstechnischeAnwendungen. Klar und übersichtlich werden diewesentlichen Bausteine der Programmierspra-che vorgestellt. Nach einer kurzen theoretischenZusammenfassung bieten in jedem Kapitel daraufabgestimmte Übungsaufgaben die Möglichkeit, dasErlernte zu sichern und zu festigen. Fortgeschritte-ne Anwender nutzen die Zusammenfassung vielerEigenschaften und Funktionen. Mit der Studenten-version NI LabVIEW 2013 ein perfektes Paket.

25ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Page 26: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

26

IT UND RECHT // SCHLICHTUNGSVERFAHREN

ELEKTRONIKPRAXIS Embedded Software Engineering Magazin Dezember 2014

Wie ein IT-Projekt wieder auf Kursgebracht werden kann

Im Konfliktfall sind Schlichtungsverfahren der Deutschen Gesellschaftfür Recht und Informatik (DGRI) nachhaltiger als ein Gerichtsverfahren.

PROFESSOR DR. LAMBERT GROSSKOPF

Die deutsche Rechtsordnung hält we-nig bereit, umKonflikte in der IT effi-zient und nachhaltig beizulegen, da

die gesetzlich geregeltenKonfliktbeilegungs-verfahrenkonfrontativ sind. Sie führen zwarzu einer Entscheidung eines Rechtsstreits,die nachhaltige Konfliktbeilegung erfolgtjedoch eher zufällig. ZudemverfügenGerich-te in der Regel nicht über IT-Fachwissen.Mitkeinem oder nur rudimentärem IT-Wissenkann aber kein komplexes IT-Projekt beur-teilt werden. So gehen die Parteien amEndeeines lang andauernden Verfahrens häufignur mit einem Urteilsspruch auseinander,aber nichtmit einer Lösung ihresKonfliktes,zumal gerichtliche Verfahren auch nur we-nigen Gestaltungsraum bieten: Einer Klagekannvollständig oder teilweise stattgegebenoder sie kannebenabgewiesenwerden. Zwargibt es inzwischen die gerichtliche Mediati-on, die durch einen ansonsten mit demStreitfall nicht befassten Richter bei Kaffeeund Keksen erfolgt. Jedoch fehlt auch in derMediation der IT-Sachverstand.Nachhaltiger als ein gerichtliches Verfah-

ren sind Schlichtungsverfahren der Deut-schenGesellschaft für Recht und Informatik(DGRI), in denen auch nicht justitiable Be-ziehungs- und Teamkonflikte gelöst werdenkönnen. Getroffenwerden die Entscheidun-gendurchExpertenteamsaus einem IT-Sach-verständigen mit besonderen Kenntnissenindem relevantenKonfliktthemaundeinemRechtsanwalt, spezialisiert auf Schlichtungim IT-Recht. Als unabhängiger SchlichterkanndasExpertenteam IT-Projekte begleitenund Entscheidungen für den weiteren Fort-gang des Projektes treffen, die für die Pro-jektdauer verbindlich sind und erst späterdurch ein (Schieds-)Gericht geprüft werdenkönnen. Sie betreffen etwa Fragen� der Fortführung von Arbeiten, die füreine geordnete Vertragsdurchführung er-forderlich sind;� der Erbringung von Leistungen, die füreine geordnete Vertragsdurchführung er-forderlich sind und bei denen über eine zu-sätzliche Vergütungspflicht gestritten wird;

� der Durchführung von Beschleunigungs-maßnahmen, um Verzögerungen zu verhin-dern oder zu verringern.Die Expertenteams können aber auch

nicht justitiable Beziehungs- und Teamkon-flikte lösenundunorthodoxeLösungsansät-ze zur Erzielung eines für beide Parteientragfähigen Kompromisses vorschlagen, dasie nicht an das Korsett des Zivilprozess-rechts gebunden sind.Kommt auf Vorschlag oder unter Mitwir-

kung des Schlichtungsteams keine Verein-barung zwischen den Parteien zustande,dann unterbreitet das Schlichtungsteam ei-nen schriftlichen Schlichtungsspruch mitkurzer Begründung,wobei einem fairenAus-gleichder Interessen, insbesondere auchderkaufmännischen Belange beider Parteien,der Wahrung einer weiteren Kooperations-möglichkeit und dem mutmaßlichen Aus-gang einesGerichtsverfahrens zwischendenParteien Rechnung getragen werden soll.Wird der Schlichtungsspruch von beiden

Prof. Dr. Lambert Grosskopf von der UniversitätBremen: Der Jurist plädiert dafür, in Konfliktfällendie Schlichtungsstelle der Deutschen Gesellschaftfür Recht und Informatik anzurufen.

Bild:Jim

Rakete Parteien akzeptiert, können sie auch verein-

baren, das Schlichtungsteammit der endgül-tigen Entscheidung über den Streitgegen-standals Schiedsgericht zubeauftragen.DerSchlichtungsspruch wird dann zu einerSchiedsentscheidung, die vom zuständigenOberlandesgericht für vollstreckbar erklärtwerden und dann ebensolche Wirkungenentfalten kann wie ein Gerichtsurteil.Der Erfolg der DGRI-Schlichtung liegt in

der Bestellung von Schlichterteams aus IT-Sachverständigen und Juristen begründet.Juristen haben gewöhnlich keine IT-Fach-kenntnisse, die jedoch benötigt werden, umein aus dem Ruder gelaufenes IT-Projektwieder aufKurs zubringen.Diese Fachkennt-nisse bringen die IT-Sachverständigen einund zwar von Beginn der Schlichtung an. Ingerichtlichen Verfahren werden IT-Sachver-ständige hingegen nicht zu Beginn einesProzessverfahrens eingeschaltet.Eine Schlichtung ist in jeder beliebigen

Sprachemöglich. Sie eignet sichdaher nichtnur für nationale, sondern auch für grenz-überschreitende IT-Projekte. Schlichtungenhaben sich nicht nur bei Streitigkeiten zwi-schenAnbieternundKundenvon IT-Leistun-genbewährt, sondern auch zwischenAnbie-ternundKundenvonOnlinediensten. Selbstbei Verletzung von gewerblichen oder sons-tigenSchutzrechten eignet sich eine Schlich-tung, um etwa Streitigkeiten um die Rechtean Softwarecode auszuräumen.Eine IT-Schlichtung ist in der Regel nicht

billiger als ein gerichtliches Verfahren, abersicher schneller und unbürokratischer. Dereventuell höhere Aufwand wird aber kom-pensiert durch die in der Regel fruchtbareHilfe der Schlichter, verhärtete Fronten auf-zubrechen und ein IT-Projekt doch noch zueinem erfolgreichen Ende zu bringen. // FGSchlichtungsstelle der Deutschen Gesell-

schaft für Recht und Informatik e.V.Schöne Aussicht 3061348 Bad Homburg v.d.H.Homepage: http://www.dgri.de

Prof. Dr. Lambert Grosskopf

Page 27: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

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!

Page 28: Embedded Software Engineering 4/2014 - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2014/213.pdf · 4 ELEKTRONIKPRAXISEmbeddedSoftwareEngineeringMagazinDezember 2014 INHALT

Come andvisi

t us at

Seit 30 Jahren vertrauen weltweit führende Firmen Green Hills Software’s sicherer undzuverlässiger Software für sicherheitskritische Systeme.

Für Luftfahrt- und Automobilindustrie, für Telecom-, Medizin- und Industrietechniksowie für intelligente Energienetze hat Green Hills Software erprobte und zuverlässigeTechnologie geliefert.

Wenn Sie wissen möchten, wie eines der weltweit sichersten und zuverlässigstenBetriebssysteme und dessen Entwicklungstools das Risiko aus Ihrem nächstenProjekt nehmen kann, kontaktieren Sie uns per Telefon unter+49 (0)228 43 30 777 oder besuchen Sie uns auf www.ghs.com/s4e

Copyright © 2014 Green Hills Software. Green Hills Software and the Green Hills logo are registered trademarks ofGreen Hills Software. All other product names are trademarks of their respective holders.

VERTRAUENSWÜRDIGE SOFTWAREFÜR EMBEDDED DEVICES

SAFERELIABLE

SECURE