Embedded Software Engineering - Vogel · 6 OPENSOURCESOFTWARE//RECHT ELEKTRONIKPRAXIS...

Wissen.Impulse.Kontakte. November 2017

Gründliches Software-Designfür gute Codequalität

Software wider demSchichtensalatWarum der klassischeAnsatz, Software in Schich-ten anzulegen, nicht immerzielführend ist. Seite 12

Tracking undTracing im RTOSUm Echtzeitbetriebssyste-me zu debuggen muss manbesseren Einblick in ihrVerhalten gewinnen.Seite 22

Elektromobilität –Alles gut geladen?Damit Elektromobilität ihrenSiegeszug antreten kann,muss die Ladeinfrastrukturgesichert sein. Seite 28

EMBEDDED SOFTWARE ENGINEERING

www.elektronikpraxis.de

Guter Code ist Code, der offensichtlich korrekt ist. Dieser ist einfach lesbar, einfach zuwarten und einfach überprüfbar. Wie erstellt man also offensichtlich korrekten Code?

document7401503466162650945.indd 1 20.11.2017 07:36:11

http://www.elektronikpraxis.de

171114_TRCS_EP_DE.indd 1 11/14/17 10:23 AM

3

EDITORIAL

ELEKTRONIKPRAXIS Embedded Software Engineering November 2017

Mehr Leistung für ihrpersönliches Fahrerprofil

AlsHurrikan Irma inFloridawütete,überraschte Tesla Motors seineKunden mit einem Service: Um

den teilweisen Ausfall der Lade-Infra-struktur auszugleichen, bekamenBesitzereines Tesla Model S ein kostenloses Soft-ware-Update spendiert. Dieses hob dieBatteriekapazität ihrer Modelle vorüber-gehend von 60 auf 75 kWh an. Eine vollgeladene Tesla-S-Batterie hatte nun eineReichweite von 240Meilen statt zuvor 200.Wie ist das möglich? Nun, Tesla hatte

in seinen Model-S-Fahrzeugen von An-fang an Batterien mit 75 kWh Leistungverbaut. Käufernwird aber dieseVariantenur gegen Aufpreis angeboten. Wer sichfür die günstigere 60-kWh-Version ent-scheidet, bekommt keine neue Batterie.Statt dessen wird die Leistung per Soft-ware gedrosselt. Wer später das stärkereModell will, kann sich die zusätzlicheLeistung weiterhin per Update freischal-ten lassen. GegenAufpreis, versteht sich.Hieran kann man gut sehen, welche

Macht Embedded Software immodernenAutozeitalter besitzt. Aber warum hieraufhören? AuchMotorleistung ließe sichper Software-Update drosseln. Fahrzeug-anbieter könnten Aktionswochen anbie-ten: Für die nächsten 14Tagehat IhrMotor

„In Zukunft legen Sie sichFahrerprofile an, welcheeffektiv Reichweite undLeistung Ihres Fahrzeugsbestimmen.“

Sebastian Gerstl, [email protected]

40 PSmehr. So können Sie prüfen, ob siedie zusätzliche Power haben wollen.Oder Sie legenprivate Fahrerprofile an,

die über individuellen FahrzeugschlüsseloderDaumenabdruck abgerufenwerden:Während Papa die vollen 200 PS des na-gelneuen PKW ausnützt, gibt sich Mamavielleicht mit 140 zufrieden. Der 18-jähri-ge Sprössling kriegt dagegen nur 80 - dasfreut dann auch die Versicherung. NachAblauf der Probezeit kann das Profilschließlich aktualisiert werden - undschondarf auch Juniormit Vollgas auf dieAutobahn. Apropos Vollgas: NotorischeRaser bekämen vielleicht künftig Over-the-Air eine Motorbremse verpasst, stattweiter Punkte in Flensburg zu sammeln.Wegweisend oder Horrorvision? Eines

ist jedenfalls klar: Software wird in Zu-kunft deutlich mehr Aspekte unseres Le-bens entscheidendmitbestimmen.

Herzlichst, Ihr

Innovativer,

ultra-kompakter

Debug Adapter

Energiemessung

Isolation

Test Automatisierung

keil.com/ulinkplus

Besuchen Sie

document3753407673904667139.indd 3 20.11.2017 14:02:51

mailto:[email protected]

4 ELEKTRONIKPRAXIS Embedded Software Engineering November 2017

SCHWERPUNKTESoftware-EngineeringTITELTHEMA

8 Software-Design für gute CodequalitätGuter Code ist Code, der offensichtlich korrekt ist. Einoffensichtlich korrekter Code ist einfach lesbar, einfachzu warten und einfach überprüfbar. Wie erstellt man alsoguten Code?

Architektur12 Architektur für moderne Applikationen

Software-Architektur ähnelt oft einem Schichtensalat. Dochdas, was Sie auf eine Party mitbringen würden, eignet sichnicht als Basis für moderne Anwendungen. Mit „Ports andAdapters“ hat Alistair Cockburn ein Architekturmuster de-finiert, das genau diesen Problemen begegnen soll.

Implementierung16 Vorteile für Embedded-IoT durch NAND-Flash

Datenunsicherheiten und Vibrationsprobleme disqualifi-zieren klassische Speicher oft für Embedded-IoT-Anwend-ungen. NAND-Flash ist meist besser, doch gilt es auch hiereinige Designaspekte zu beachten.

Test & Qualität20 Chaos vermeiden mit Deploy-and-Destroy-Strategie

Software ist oft die primäre Schnittstelle zwischen Un-ternehmen und ihren Kunden. Einbußen in der Qualitätzugunsten der Durchlaufzeit sind hier keine Option. Wie istalso hohe Qualität zu garantieren?

Echtzeit-Betriebssysteme22 Debugging von RTOS-Firmware

Echtzeit-Betriebssysteme sind in Embedded Systemenlängst fest etabliert. Um RTOS-basierte Systeme vernünf-tig zu debuggen, bedarf es aber besserer Einblicke in ihreEchtzeitverarbeitung.

Softwareentwicklung26 Best Practice für Continuous Delivery

Versäumte Liefertermine oder mangelnde Qualität werdenin der Embedded-Branche immer seltener toleriert. Hilfeverspricht hier die Entwicklungsmethode ContinuousDelivery.

28 Nutzfahrzeuge und ElektromobilitätElektrische PKWs, Busse oder LKWs haben gemeinsameProbleme: Reichweite, Ladegeschwindigkeit und Lade-infrastruktur. Wichtige Schritte sind gemacht. Doch wiefunktioniert das Laden im Detail?

RUBRIKEN3 Editorial

6 Aktuelles

32 Kolumne

INHALT

SOFTWARE-ENGINEERING

Software-Design für guteCodequalitätUm guten, korrekten und sauber lesbaren Code zugenerieren, ist vor allem gutes Design essentiell.Eine Systemanforderung lässt sich in logischeFunktionen aufspalten, jede Funktion ist einzeln zucodieren. Dies ist eine pragmatische Herangehens-weise. Aufgrund des kombinatorischen Effekts ausdem Zusammenfügen mehrerer Logik-Sätze lässtsich aber kaum garantieren, dass alle Pfade socodiert werden, dass sie offensichtlich richtig sind.Hier sind Kompetenz, Erfahrung und die Wertschät-zung des künstlerischen Aspektes der Softwareent-wicklung entscheidend.

8

document6928655703352610164.indd 4 21.11.2017 09:21:24

170705_Test3_EP_DE.indd 1 6/26/17 4:54 PM

6

OPEN SOURCE SOFTWARE // RECHT


Die Einführung eines sogenanntenSoftware-Asset-Management-Systems(kurz SAM-System) hat sich in den

vergangenen Jahren großer Beliebtheit er-freut. Allerdings bezieht sich SAMnur seltenauf Open-Source-Software. (Der Begriff‚OpenSource Software‘wirdhier stellvertre-tend für ‚Freie Software‘ bzw. ‚Freie undOpenSource Software‘ verwendet.)Meist sollmit einemSAM-System lediglich

dasRisiko vonFehl- oder Falschlizensierun-gen bei der Nutzung von proprietärer Soft-ware vermieden werden. Dabei ist nebenproprietärer Software auch der Einsatz vonOpen-Source-Software bereits selbstver-ständlicherAlltag geworden: Laut einer Stu-die des Unternehmens SerNet aus dem Jahr2016 setzen alle im Dax vertretenen Unter-nehmen Open-Source-Software ein.

Während es bei der Nutzung proprietärerSoftware allgemein bekannt ist, dass diesenur nach den Vorgaben der jeweiligen Li-zenzbedingungen, wie beispielsweise derZahlung von Lizenzgebühren, genutzt wer-den darf, wird beim Einsatz von Open-Sour-ce-Software häufig übersehen, dass auchderenNutzungnurunter bestimmtenBedin-gungenmöglich ist.Die Tatsache, dass für dieVerwendungvon

Open-Source-Software keine Lizenz-gebüh-ren verlangt werden können, darf nicht zuder Annahme verleiten, dass die Rechtein-haber auf sämtliche Rechte oder derenDurchsetzung verzichten. Im Gegenteil, diemeisten Open-Source-Lizenzen enthaltenneben der weitreichenden Einräumung vonNutzungsrechten konkrete Vorgaben undBedingungen, die beim Einsatz der jeweili-

Software Compliance Academy: Die Bedeutung der Open Source Compliance im Unternehmen steigt stetig.Wenn Sie ihr Unternehmen hier gut aufstellen wollen, dann empfehlen wir Ihnen das FOSS-Compliance-Seminar der Software Compliance Academy in Berlin (www.scompliance.com).

Bild:Tho

rben

Wengert

genOpen-Source-Software zubeachten sind.So verlangen beinahe alle Open-Source-Li-zenzen, dass entsprechendeUrheber-rechts-undLizenzvermerke beiWeitergabeder Soft-ware mitgeliefert werden. Eine häufig zufindendeweitere Verpflichtung besteht dar-in, den Quellcode bei Weitergabe der Soft-ware offenzulegen und auch zugänglich zumachen.Einige Open-Source-Lizenzen verbinden

diese Voraussetzung mit dem sogenannten‚Copyleft‘ und verlangen, dass derNutzer vonihm veränderte Software nur unter den fürdie ursprüngliche Software geltenden Li-zenzbedingen weitergeben darf. Die Viel-schichtigkeit der Lizenzbedingungenunddieletztgenannte Verpflichtung zurWeitergabeunter den ursprünglichen Lizenzbedingun-genwirft in der Praxis die oft vernachlässig-te Frage der rechtlichen Kompatibilität mitanderen Softwarekomponenten auf.

Verletzungen der Lizenz-pflichten haben KonsequenzenAuch die Rechtsfolgen einer Verletzung

der unterschiedlichen Lizenzpflichten sindnicht zu unterschätzen und können zuweit-reichenden Konsequenzen führen.Grundsätzlich sindOpen-Source-Lizenzen

so konzipiert, dass eine Verletzung der Li-zenzpflichten automatisch zumWegfall derRechte unddamit zu einerUrheberrechtsver-letzung führt (sog. auflösende Bedingung).Als Konsequenz sieht das Urheberrecht

neben den Ansprüchen auf Unterlassungund Schadensersatz sowie auf Auskunft inBezug auf Vertriebsketten und Anzahl derEndgeräte, vor allem auch die Vernichtungund den Rückruf entsprechender Produkteaus der Lieferkette vor. Auch strafrechtlicheKonsequenzen können folgen.Damit kommt den Open-Source-Lizenzen

eine zunehmendeBedeutung imBereichderCorporate Compliance zu. Denn die Pflichtzur Einhaltung gesetzlicher Bestimmungenumfasst auchdie gesetzlichenVorgabendes

Wie Open Source CompliancezumWettbewerbsvorteil wird

Ein Compliance-Prozess zum Umgang mit Open-Source-Softwareschützt nicht nur Unternehmen vor rechtlichen Konsequenzen.

Er führt auch zu eindeutigen Wettbewerbsvorteil.

DR. CAHTARINA MARACKE

document8826365204932045402.indd 6 21.11.2017 09:22:01

http://www.scompliance.com

7

OPEN SOURCE SOFTWARE // RECHT


Urheberrechts. Dass eine Urheberrechtsver-letzung aufgrund der Nichtbeachtung vonOpen-Source-Lizenzen auch zur persönli-chenHaftungderUnternehmensleitung füh-ren kann, wissen da-bei die wenigsten.Nicht nur in den U.S.A., sondern auch in

DeutschlandhabendieGerichte bereits Vor-standsmitglieder persönlich in die Haftunggenommen, weil diese es versäumt hatten,ein funktionierendes Compliance-Manage-ment-System einzuführen. Damit ist bestä-tigt, dass nebendemUnternehmenals juris-tische Person auch dieMitglieder der Unter-nehmensleitung als natürliche Personenselbst haften, sofern es aus dem Unterneh-men heraus zu Gesetzesverstößen kommt.

Der Compliance-Prozess wirdzum VorteilDie Bedeutung eines Compliance-Prozes-

ses sollte allerdingsnicht nur imKontext derGefahrenabwehr und Risikominimierungeiner persönlichenHaftung verstandenwer-den, sondern vor allem als echter Wettbe-werbsvorteil. Geschäftspartner undKundenlegen zunehmend Wert auf gesetzeskonfor-mesHandeln. Ein funktionierender Compli-ance-Management-Prozess vermeidet Folge-kosten vonVerstößen, verbessert denRuf desUnternehmens und fördert damit letztend-lich die Umsätze.Untersuchungen zeigen, dass die Kosten

für Rechtsverstöße höher sind als der Auf-wand zur Sicherung der Compliance: Buß-gelder undSchadensersatzforderungenkön-nen dem besten Jahresumsatz leicht dasGenick brechen. Auch Investoren sind eherbereit in Unternehmen mit nachweisbarenCompliance-Prozessen zu investieren, umdas Risiko von Sanktionen zu vermeiden.Finanzierungskosten sinken damit ebensowie die Prämien für Haftpflichtversicherun-gen der Unternehmensleitung (D&O-Versi-cherung).Gleiches gilt für einenwirksamenCompli-

ance-Prozess zumUmgangmitOpen-Source-Software. Es geht nicht nur darum, Unter-nehmen und Unternehmensleitung vorrechtlichen Konsequenzen im Fall einer Li-zenzverletzung zu schützen, sondern vorallemdarum, einen echtenWettbewerbsvor-teil zu schaffen.Bereits heutewerden inAusschreibungen

undAuftragsverhandlungen entsprechendeNachweise zum Umgang mit Open-Source-Software verlangt. Diese reichen vom soge-nannten Scanning einzelner Software Kom-ponenten oder ganzer Produkte bis hin zumNachweis detaillierter Compliance-Prozesse,um die rechts-konforme Nutzung von OpenSource Software darzulegen.

Es ist zu erwarten, dassmit der zunehmen-den Bedeutung von Open-Source-Softwarein kommerziellen Produkten zunehmendstrengere Anforderungen an den Nachweiseiner rechtskonformen Nutzung der jeweili-genOpen-Source-Komponentengestelltwer-den.Auchhier gilt, dass einnachvollziehbarfunktionierender Compliance-Prozess einenVertrauensvorsprungunddamit eine gegen-überWettbewerbern verbesserte StellungbeiAusschreibungen,Verhandlungenmit Inves-toren oder anderen Geschäftspartnern mitsich bringt.

Ihr Weg zu einem Open-Source-Compliance-ProzessWelcheAnforderungen sindnunan einen

solchen Open-Source-Compliance-Prozesszu stellen?DieKomplexität der Softwareent-wicklung und der damit ein-hergehendenrechtlichen Rahmenbedingungen stellt dieUmsetzung eines Compliance Prozesses vorgroße Herausforderungen. Es gilt in einemersten Schritt die Verwendung von Open-Source-Software zu erkennen und in einemzweiten Schritt die entsprechenden Lizenz-pflichten zu erfassen, nachvollziehbar zuverwalten und diese Verwaltung zu doku-mentieren.Der erste Schritt wird vor allem dann er-

schwert,wennSoftwarenicht nur imeigenenUnternehmenhergestelltwird, sondern auchdurchdie Einbettung extern bezogener Soft-ware in eigeneProdukte und indennachfol-genden Vertrieb gelangt. Dabei sollte Open-

Source-Software erkannt, dokumentiert undeinem den Vorgaben des jeweiligen Unter-nehmens angepassten Arbeitsablauf zuge-führtwerden. Zur ErkennungderOpen-Sour-ce-Komponentenwerdenderzeit verschiede-ne Programme angeboten, die je nach Aus-gestaltung auch bestimmte Funktionen desLizenzmanagements übernehmen können(sogenannte Scanning Tools).Der zweite Schritt, in dem die Open-Sour-

ce-Lizenzen erfasst, verwaltet unddokumen-tiert werden, sollte über den Einsatz eineseinfachen Lizenzmanagement-systems hin-ausgehen. Erforderlich ist hier ein Compli-ance-Prozess nach dem Vorbild andererCompliance-Management-Systeme, wobeivor allem auch die interne Verteilung derVerantwortlichkeiten im Unternehmen, dieunternehmensinterne Kommunikation undDokumentation sowie die SchulungderMit-arbeiter eine tragende Rolle spielen.Als Vorbild kann der in Zusammenarbeit

mit der Linux Foundation entwickelte Stan-dard einesOpen-Source-Compliance-Prozes-ses ‚OpenChain‘ dienen. Gefordert wird dortneben der Kenntnis der Verpflichtungen beiderNutzung vonOpen-Source-Software, diedurch interne Richtlinien und regelmäßigeSchulungen nach-gewiesen werden muss,vor allem auch die nachvollziehbare Zuwei-sung der Verantwortlichkeiten, inklusivejuristischer Expertise, das Bestehen einesinternen Prüfungs- und Genehmigungspro-zesses bei Produkten, die für den Vertriebbestimmt sind, und einGrundverständnis imUmgang und der Zusammenarbeit mit derOpen-Source-Software-Entwicklergemein-schaft (Open Source Community).Festzuhalten bleibt, dass mit dem zuneh-

menden Einsatz von Open-Source-SoftwareinProduktenundVertriebskettendieBedeu-tung einesOpen-Source-Compliance-Prozes-ses weiter steigenwird. Langfristig kann dieeffiziente Umsetzung und Qualitätssiche-rung solcher Prozesse nur über externe Zer-tifizierungsaudits erreicht werden.Bis dahin sollten sichUnternehmenanden

Vorgaben des OpenChain-Standards orien-tieren und vor allem die dort geforderteKenntnis der unterschiedlichenO-pen-Sour-ce-Software Lizenzen, die Frage der unter-nehmensinternen Verantwortlichkeit unddes Software-Prüfungs- und Dokumentati-onsprozesses umsetzen. Je effizienter undtransparenter diese Vorgaben umgesetztsind, desto größer sind der Vertrauensvor-sprung, die Kostenersparnis und damit derWettbewerbsvorteil schonheute.Mehr Infosunter www.scompliance.com. // JW

Software Compliance Academy

Dr. Catharina Maracke ist Rechtsanwältin undLeiterin der Software Compliance Academy inBerlin (www.scompliance.com), die Schulungenzu unterschiedlichen Themen im Bereich SoftwareCompliance anbietet.

Bild:JoiIto

document8826365204932045402.indd 7 21.11.2017 09:22:06




TITELSTORY // SOFTWARE-ENGINEERING

8

TITELSTORYUm guten, korrekten und sauber les-baren Code zu generieren, ist vor al-lem gutes Design essentiell. Eine Sys-temanforderung lässt sich in logischeFunktionen aufspalten, jede Funktionist einzeln zu codieren. Dies ist einepragmatische Herangehensweise.Aufgrund des kombinatorischen Ef-fekts aus dem Zusammenfügen meh-rerer Logik-Sätze lässt sich aber kaumgarantieren, dassalle Pfadesocodiertwerden, dass sie offensichtlich richtigsind. Hier sind Kompetenz, Erfahrungund die Wertschätzung des künstleri-schen Aspektes der Softwareentwick-lung entscheidend. Dieser Beitrag be-leuchtet im vorliegenden ersten Teileinige der wichtigsten Elemente, diehierfür entscheidend sind.


document7852603611799281808.indd 8 20.11.2017 13:35:41

9



* Steve Norman... ist Manager Global Ecosystems beiRenesas Electronics Europe.

Software-Design für guteCodequalität

Guter Code ist Code, der offensichtlich korrekt ist. Offensichtlichkorrekter Code ist einfach lesbar, einfach zu warten und einfach

überprüfbar. Wie erstellt man also guten Code?

DR. VAL LYNCH UND STEVE NORMAN *

* Dr. Val Lynch... ist CEO bei AND TechnologyResearch.

Umeingutes Software-Design zu errei-chen, bestimmen drei Definitionendas Umfeld:

Software-Architektur: Die Definition derOrganisation eines Softwaresystems, das dieAnforderungen erfüllen kannundÄnderun-gen sowie eine zukünftige Wiederverwen-dung erlaubt.Objekte: Code-Blöcke, die bestimmte

Funktionen innerhalb der Software-Archi-tektur ausführen. Objekte lassen sich kom-binieren. Diesewerdenoft auch als Funktio-nen, Prozeduren oder Module bezeichnet.DieBenennung solcher Blöcke ist oft abhän-gig von der verwendeten Software-Sprache.Software-Schnittstellen:Spezifikationen,

die Definitionen darüber enthalten, wie einTeil der Software-Architektur mit einem an-deren verknüpft ist. Schnittstellen gibt es aufallen Ebenen der Architektur, zwischen ein-zelnen Code-Blöcken, zwischen diesen Blö-cken und High-Level-Funktionen sowie zuexternen Systemen oder Anwendern.Die mit der Softwareentwicklung einher-

gehenden Herausforderungen sollten nieunterschätztwerden. Selbst das kleinsteDe-tail, von der genauen Benennung eines Ob-jektes bis zur erforderlichen Zeit für dieAus-führung einzelner Instruktionen, spielt eineRolle. Der wohl wichtigste Merksatz imSoftware-Design lautet: Es gibt keinKonzept,das universell passt. Fasst man jedoch allerelevanten Daten, Eingaben und Anforde-rungen zusammenundüberprüft ihr Zusam-menspiel, bildet dies die Grundlage für ein

praktikablesKonzept. Diesesmuss vor allemdas Geschäftsszenario für die Entwicklungerfüllen. In der Literatur gibt es reichlichBeispiele für Konzepte wie etwa Software-Pattern, die sich in solchenFällen als beson-ders nutzbringend erwiesen haben. Sie bil-den einen nützlichen Ansatzpunkt für denAufbau einer Architektur.Pattern beschreiben gängige Code-Merk-

male wie Zustandsmaschinen, Model ViewController und Objekt-Observer. Ein nacheinembestimmtenPattern aufgebauter Codeist in der Regel einfacher nachzuverfolgenund zu validieren. Er lässt sich auch für eineDefinition zum Aufbau von Code-Objektennutzen. Pattern sollten allerdings nur ver-folgt werden, solange dies angemessen ist.Letztendlichmuss der Entwickler sicherstel-len, dass der gesamte Code gut organisiertund klar verständlich ist. Nur dann kann erals offensichtlich richtig bewertet werden.Besondere Aufmerksamkeit ist dabei denSchnittstellen zwischen den verschiedenenObjekten zu widmen.

Nach gängiger Praxis ist stets zu berück-sichtigen, welchen Zweck jede Schnittstellehat und wie diese in die Gesamtarchitekturpasst. Schnittstellen sollten schriftlich undklar in allen Entwicklern zugänglichen Do-kumenten definiert werden. Vor einer Ent-scheidungüberDetails sindbeide SeitenderSchnittstelle zuuntersuchen.Dies gilt beson-ders,wennder CodedurchunterschiedlicheEntwickler oder sogar verschiedene Unter-nehmen für beide Seiten zu schreiben ist.

Dokumentation, Sprachwahlund Nutzen vorhandener IdeenDokumentation ist oft das Stiefkind der

Softwareentwicklungundetwas,wovor Pro-grammierer zurückschrecken. Eine gut ge-schriebene Spezifikation kann aber vieleArbeitsstunden einsparen. Die Kunst derSchnittstellen-Entwicklung besteht darin,dass man sie so generisch wie möglich an-legt, ohne dass dabei Stabilität oder Zielset-zung verloren gehen. Nur dann bietet dieSchnittstelle die Möglichkeit, von beiden

Bild:©

maciek905

-stock.ado

be.com

document7852603611799281808.indd 9 20.11.2017 13:35:51

10



Seiten aus erforderliche Änderungen vorzu-nehmen.Dabei ist vor allemsicherzustellen,dass der Code immerder Schnittstellen-Spe-zifikation folgt und nicht andersherum.Die Entwicklung von Software für Mikro-

controller wie etwa der Renesas SynergyPlattform erfordert besondere Sorgfalt auf-grundder betroffenenHardware-Schnittstel-len. Jede Peripherieschaltung in derMCU istso zu konfigurieren, dass sie die von derSoftware benötigten bzw. genutzten Datenliefern kann. Zudemmüssen sämtlichenichtverwendeten Pins angesprochen werden.Betrachtetman jedePeripherieschaltung alsein Objekt innerhalb des Systems, lässt sichdie Schnittstelle effektiv adressieren.Die Wahl der Sprache für die Codierung

wirkt sich auf das Software-Design aus. DieEntscheidung für eine dieser Optionen istdaher Teil derArchitektur-Überlegungen. Siesollte sich weniger danach richten, womitder Entwickler vertraut ist. BeiwebbasiertenAnsätzen ist oft Java, bei anderen Anwen-dungenSkript-basierte SprachenwiePythonangemessen. Für die meisten auf der Syner-gy-Plattform ausgeführten Embedded-An-wendungen empfiehlt sich eine Kodierungin C undC++. C++ bietet die nötige Flexibili-tät für denUmgangmit komplexenArchitek-turen,während esC erlaubt, kompaktenundzielgerichteten Code zu schreiben, wennEffizienz wichtig ist. Bei besonders an-spruchsvollen Anwendungen mit eng defi-niertem Timing für einzelne Instruktionensollte auch Assembler in Betracht kommen.BeimEinstieg in eineDesign-Aufgabe ent-

wickeln Ingenieure innovative Ideen, umdasBeste bzw. wenigstens das Nächstbeste er-

„Selbst das kleinste Detail, von der genauen Benennung einesObjektes bis zur erforderlichen Zeit für die Ausführung einzel-

ner Instruktionen, spielt bei der Entwicklung eine Rolle.“Dr. Val Lynch, AND Technology Research, und Steve Norman, Renesas Electronics

stellen zu können. Die Ziele umfassenmehrQualität, besseren Funktionsumfang odereinengünstigerenPreis. Dies kannneueMe-thoden oder Techniken hervorbringen.Manchmal besteht aber die Gefahr, dass diegeleistete Entwicklungsarbeit frühere Ergeb-nisse wiederholt und es scheint, als ob nur„das Rad neu erfunden“ wurde.Wiederverwendung oder Rekonfigurie-

rung vorhandener Software ist eine guteMöglichkeit, dasBeste aus einem Investmentzumachen.Meist trifft dies nur zu,wenn sichnach den folgenden Definitionen nachwei-sen lässt, dass sichdie Software bewährt hat:COTS (Commercial-off-the-Shelf): Kom-

merzielle, einsatzbereite Komponenten, diesich in ein System einbinden lassen.Bewährt (Proven): Getestet undverifiziert,

um zu belegen, dass ein vorgegebener Stan-dard erreicht wurde.Wert: RelativerWert oderNutzen einer Sa-

che. Dies umfasst unter anderem den Geld-wert. GewonnenesWissen, eingesparte Zeit,Qualität oder Erfahrung sind Beispiele füralternative Maßstäbe.

Bewährter Code und Wissens-ArchiveWeiterhin ist noch ein anderer wichtiger

Punkt zu beachten: Im Laufe jedes Projektsentsteht ein Archiv mit Code, Designs undWissen. Dieses Archiv sollte am Ende desProjekts nicht außer Acht gelassen werden,da es darüber hinaus vonWert sein könnte.Softwareentwickler generieren vielWissen

zu bestimmten Technologien und Struktu-ren, das auch für zukünftige Projekte nütz-lich sein kann. Bewährter Code ist eine Er-

weiterung dieses Wissens, wobei der Code(womöglich innerhalb eines Systems) bereitsim Feld validiert wurde und für spätere Ar-beiten nutzbar ist. Der Einsatz von bewähr-tem Code ist eine attraktive Option für Ent-wicklungsprojekte, da er frühere Investitio-nen in Softwareentwicklungnutzt. Hier lässtsich Zeit und Geld sparen, die Qualität ver-bessern und Mehrwert erzeugen. Um maxi-malen Mehrwert zu erzielen, sollte jedochbewährte Software und die Art ihres Einsat-zes sorgfältig ausgewählt werden.Beim Import von bewährtem Code – ent-

weder aus einem früheren Archiv innerhalbder Firmaoder als COTSvon externenAnbie-tern ist am wichtigsten, dass sich der Codenicht nur für dieAnwendungeignet, sondernauch geltende Richtlinien erfüllt. Materialwieder zu verwenden ist zwar verlockend,doch die Auswirkungen eines solchen Ein-satzes in einer neuenUmgebung sollten stetsevaluiert werden. Auch wenn sich für be-währtenCode ein bestimmterQualitätsstan-dard belegen lässt, so kann kein Code100-prozentige Fehlerfreiheit garantieren.Realistischerweise sollte man akzeptieren,dass jeder Code Fehler enthält und daher ineiner neuen Umgebung Tests durchlaufenmuss. Dies kann eineHerausforderung sein,insbesondere wenn der Quellcode nicht im-mer verfügbar ist, doch es ist nicht unmög-lich. Es kommt darauf an, welche Testabde-ckung sich erreichen lässt, und ob dieseakzeptabel ist. In jedem Fall sollten seineVor- und Nachteile untersucht werden.Kommt jedoch bewährte Software zum Ein-satz, so kann ein sonst kaum tragfähigesGeschäftsszenario realisierbar werden.

Open-Source-Code odervalidierter Code?AlsUnterstützungbeimStart eines Projek-

tes oder um wichtige Funktionen wie Hard-ware-Schnittstellen und Betriebssystemebereitzustellen, nutzen Ingenieure oft Open-Source-Code oder lizenzgebührenfreienCode aus anderen Quellen wie etwa vonHalbleiterherstellern. Dabei ist stets zu be-rücksichtigen, dass dieser Code nicht unbe-dingt schonvalidiertwurde.DerUnterschiedzwischen validiertemund nicht-validiertemCode ist die Evidenzbasis. Code ohne nach-gewiesene Validierung kann für ein Projektimmer noch nützlich sein, erfordert jedocheine Qualitätsbewertung und bei seinemEinsatz ist Vorsicht geboten. Bei derNutzungvonoffenemQuellcode könnendieGrößederCommunity, die diesen Code nutzt, und derUmfang der seitens der Community gebote-nenWartung undUnterstützung als Indika-tor für dieQualität des Codes dienen.Weiter-

Software-Qualitätsichern: Nicht nur auf dieEntwicklung, sondernauch auf ordentliches,gründliches Testingkommt es bei gutem Codean.

Bild:©

REDP

IXEL

-stock.ado

be.com

document7852603611799281808.indd 10 20.11.2017 13:36:07

ELEKTRONIKPRAXIS Embedded Software Engineering November 2017 11


Die Renesas SynergySoftware: Das Software-Paket ist bereits für denEinsatz auf den Synergy-Mikrocontrollern vomHersteller vorab verifiziertbzw. qualifiziert.

Bild:Renesas

hin ist zuüberlegen, obdasunternehmensin-terne Wissen durch die Erstellung einesneuen Codes erweitert werden soll, anstattCode wieder zu verwenden oder extern zubeschaffen. Neuer Code, den Entwicklerselbst validieren können, bietet langfristigwomöglich einen größeren Mehrwert. Auchdiese Entscheidung muss mit der eigenenGeschäftsstrategie im Einklang stehen.Wenn die Implementation einer Lösung

für eine bestimmteProblemstellungkomplexist und die Expertise des internen Teamsüberschreitet, oder wenn die Herausforde-rung Spezialwissen außerhalb des Schwer-punkts der eigenenGeschäftstätigkeit erfor-dert, könnte dieBeschaffung vonvalidiertemCode aus externen Quellen wirtschaftlichersein. Würde andererseits die Entwicklungs-arbeit den internen Erfahrungsschatz desUnternehmens erhöhen oder gäbe es dieMöglichkeit zur Nutzung des Codes für wei-tere Projekte, dannwäre die Erstellung einesneuen Codes wirtschaftlich vertretbar. Letz-tereswürde zwar eine größereAnfangsinves-tition erfordern, langfristig aber den größe-ren Mehrwert bieten. Für einen Wirtschaft-lichkeitsnachweismuss ermitteltwerden,woWert geschaffen und sichergestellt wird,damit sich der erzeugte Wert erfassen undkommunizieren lässt.Renesas hat das „Make-or-Buy“-Dilemma

erkannt, vor dem Unternehmen am Beginneiner jedenProduktentwicklung stehen, undstellt validierte Software zum Einsatz aufRenesas Synergy Komponenten bereit. Dievalidierte Software umfasst Code für Hard-ware-Treiber, Betriebssystem und Security-Funktionen. Diese Software-Bereiche sindüberall in der Entwicklung von elektroni-schen Produkten zu finden und adressierenbeispielsweise keine spezifischen Produkt-Funktionen.DurchdenEinsatz dieses Codesgewinnen Entwickler die Freiheit, sich ganzauf ihr Produkt und die Anwendungsberei-che des Systems zu konzentrieren. Dies ent-lastet Unternehmen außerdem von den Ge-

samtbetriebskosten dieser Software. Für dieSoftware-Komponenten bietet Renesas um-fassende Gewährleistung, die zu denen derHardware-Komponenten passt, und liefertbei Bedarf auch Software-Updates. Senkun-gen der Betriebskosten und EinsparungenbeimEntwicklungsaufwand setzenwertvol-le Kapazitäten frei. So können sich Entwick-ler auf die Erstellung von Software für denKernbereich ihres Geschäfts konzentrierenund größeren Mehrwert erzielen.Der Schlüssel zur Sicherstellung dieses

Wertes heißt Testen. Tests beweisen die kor-rekte Implementierung validierter Softwareund machen eine Validierung der neu ver-fassten Software möglich.Unabhängig vonDesign,Architektur oder

Sprache ist ohnedie Einhaltungguter Codie-rungsrichtlinien alles vergeblich. Codierungals Disziplin unterscheidet sich von der Ar-chitekturerstellung und Entwicklung. Oftsind daran verschiedene Entwickler betei-ligt. Codierungsstandards und -Richtliniensind daher besonders wichtig. Klarheit desCodes lässt sichmit sorgfältiger Benennungder Daten verbessern. Durch gut benannteDaten und verständliche Erklärungen, war-um der Codierer die Software auf eine be-stimmte Weise geschrieben hat, lassen sichspäter bei Überprüfung und Wartung vieleArbeitsstunden sparen. Darüber hinaus er-möglicht die Bereitstellung vonausreichendDebugging- undTestpunkten erhebliche Zeit-einsparungen – ebenso wie eine stringenteVerwaltung unterschiedlicher Code-Versio-nen. Eine zielgerichteteArchitektur und einerobuste, mit prüfbarem, konsistentem undkontrolliertemCode implementierte Schnitt-stelle helfen dem Entwickler, offenkundigkorrekte undwartbare Software zu erstellen.Im zweiten Teil dieses Artikels wird näher

auf den Bereich Software-Testing eingegan-gen. Sie finden diesen Beitrag online unterhttp://bit.ly/2AqR0ve . // SG

Renesas Electronics

PERFECTCUSTOMIZATIONWemake it yours

Single Board Computer undHuman Machine Interfaces

Komplett-Systeme mitCPU Board, Display,Touch, Front-Glas undGehäuse

NXP ARM® i.Mx6Architektur

Ready-to-Run Systeme

Board Support Packages(BSPs) mit Treibernfür alle Schnittstellen

Betriebssysteme:Windows EmbeddedCompact®, Linux undAndroid™

Vielfältige Möglichkeitenfür kundenspezifischeAnpassungen auf Anfrage

Tempowerkring 2 | 21079 Hamburg+49 (0)40 79 18 99 [email protected] | www.garz-fricke.com

Reliable

Quality

Made in Germ

any

document7852603611799281808.indd 11 20.11.2017 13:36:13

http://bit.ly/2AqR0ve


http://www.garz-fricke.com

12

ARCHITEKTUR // STRUKTUR & AUFBAU


Ports and Adapters – Architekturfür moderne Applikationen

Klassische Software-Architektur ähnelt oft einem Schichtensalat. Dochdas, was Sie auf eine Party mitbringen würden, eignet sich nicht als

Basis für moderne Anwendungen.

BENJAMIN KLÜGLEIN *

* Benjamin Klüglein... ist Senior Software Engineer beiMethod Park

Erist auf Partysmeist ein gerngesehenerGast. Optischmacht Eindruck,wie sichderMais andieMayonnaise schmiegt,

wie der Sellerie mit dem Kochschinken eineSymbiose eingeht, unddoch jedeEbene ver-lockend getrennt ist. Dank seines meist glä-sernen Gefäßes kann ihn jeder von Außenbewundern - den Schichtsalat!AmnächstenMorgen jedochoffenbart sich

ein anderes Bild. Aus den einst fein säuber-

lich eingezogenen Schichten ist eine klum-pige Masse geworden. Was einmal appetit-lichund einladendaussah, erinnert nur nochvage an den Star des gestrigen Buffets.Wer Anwendungen entwickelt kennt viel-

leicht ein ähnliches Problem. Was vor Wo-chen undMonaten noch eine gute Architek-tur schien und deutlich als einzelne Schich-ten abzeichnete, erscheint plötzlich in einemganz anderen Licht. Es fällt schwer die ein-zelnen Schichten noch als solche zu erken-nen. Zu sehr sind Details aus der Geschäfts-logik in die Darstellung eingeflossen. DieWahl der Datenbank bestimmt über dieFunktionalitäten. DieAnwendung lässt sichnur unter Schwierigkeiten in Teilen, ge-

schweigedenn in ihrerGanzheit testen.Manstellt sich die Frage, was ist noch Mais, wasist schon Datenbank?Mit „Ports andAdapters“ hatAlistair Cock-

burn ein Architekturmuster definiert, dasgenau diesen Problemen begegnen soll. DervorliegendeArtikel beschreibt seinenEinsatzin der Praxis.

Houston, haben wir einProblem?Sind inunseremSalat-Beispiel die Proble-

me mehrheitlich ästhetischer Natur, so zei-gen sich bei Anwendungen nach einemSchichtenmuster handfeste Probleme. Zu-nächst wollen wir die klassische Schichten-architektur betrachten. Sie besteht zumeistaus drei Schichten:�Der Datenhaltungsschicht, die für dieSpeicherung der Anwendungsdaten zu-ständig ist,� der Logikschicht, die das Herzstück derAnwendung darstellt,� und zuletzt der Darstellungsschicht, zu-ständig dafür die Daten anzuzeigen undmitdem Benutzer zu interagieren.Umdie drei Teile der Anwendung nun ko-

ordiniert miteinander kommunizieren zulassen, legtmanmeist fest, dass eine Schichtnur mit der unter ihr liegenden Schichtenkommunizieren darf. In der Praxis werdenjedoch häufig Geschäftslogik undBenutzer-oberflächen-Code vermischt. Daraus resul-tieren folgende Hauptproblemfelder:�Die Anwendung kann nicht ohne größe-renAufwand automatisiert getestet werden.� Es ist knifflig die Anwendung ganz oderin Teilen wiederzuverwenden beziehungs-weise zu ersetzen.�Die Entwicklung der einzelnen Anwen-dungskomponenten lässt sich nur schwerunabhängig voneinander vorantreiben.Hinzu kommt, dass Anwendungen häufig

stark an eine Datenbank, eine Darstellungs-form (wieHTML) oder einen externenServicegekoppelt sind. Ändert sich das Datenbank-Klassische Schichtenarchitektur: Idealvorstellung; jede Schicht kennt nur die jeweils darunterliegende.

Bilder:M

etho

dPark

document7347405734583432973.indd 12 20.11.2017 14:56:18



schema odermuss die Datenbank gar durcheine andere ersetztwerden, könnenEntwick-ler in ihrer Arbeit blockiert werden und sounnötige Kosten entstehen.Ein Beispiel aus der Praxis: Eine Anwen-

dung des Kunden nutzte einen proprietärenSQL-Datenbank-Server für dieDatenhaltung.Für bestimmte Anwendungsfälle wurde dieFunktionalität als sogenannte „Stored Pro-cedures“, also als in der Datenbank hinter-legte Funktionen, realisiert.Wann immer einBenutzer gewisse Anwendungsfälle durch-führen wollte, rief er von der Darstellungs-schicht über die Persistenzschicht eine ent-sprechende Prozedur auf. Die Anwendungwar somit direkt abhängig vonder gewähltenPersistenzlösung. Details aus der eigentlichuntersten Schicht übertrugen sich bis fasthinauf in die oberste.Zunächst stellte sichdieserUmstandnicht

als Problem dar. Doch nach Jahren der Ent-wicklung änderten sich die Anforderungenan die Software. Die Anwendung sollte nunvom Datenbank-Server unabhängig sein.Bisher musste zu jeder Installation der Soft-ware auch der Datenbank-Server auf demRechner installiertwerden.Das führte dazu,dass die Rechner mit der entsprechendenLeistung - ausreichend für Datenbank undAnwendung - ausgelegt seinmussten. Güns-tige Laptops waren demnach keine Alterna-tive. Zudem ging es nicht zuletzt darum Li-zenzkosten für jede Installation einzusparen.DurchdieVermischungvonAnwendungs-

logik und Datenhaltung ließ sich die Persis-tenzschicht nicht ohne Weiteres auszutau-schen. Zur Lösung des Problems wurde einService entwickelt, der die Interaktion mitder Datenbank übernahm.Wäre die Anwendung ursprünglich nach

dem„Ports andAdapters“Muster entwickeltworden, hätte man nicht in eine komplettneue zusätzliche Anwendung investierenmüssen. Ein einzelner neuer Adapter wäreausreichend gewesen.Im folgenden wird das Prinzip der „Ports

andAdapters“ genanntenArchitektur in vierSchritten näher erläutert.

Definieren von Adaptern undPortsAnstatt der üblichen Schichten wird die

Anwendung in die Namen gebenden Portsund Adapter eingeteilt. Adapter sind Kom-ponenten nach dem klassischen Adapter-Pattern der Gang of Four. Das Wort „Port“wurde gewählt, um an die Ports eines Com-puters zu erinnern. An einen solchen Portkann ein beliebiges Gerät angeschlossenwerden.Dazumuss es lediglichdasProtokolldes Anschlusses verstehen. Für jedes Gerät

gibt es einen Adapter, der zwischen der APIund den Signalen übersetzt, die das Gerätbenötigt. Ein passendesBeispiel hierfür sinddie USB-Anschlüsse an einem Rechner. VonAbschussrampendie Schaumstoffpfeile ver-schießen, bis zu Tastaturen und Mäusenkann man dank einheitlicher Schnittstellealles anschließen und betreiben.Dieses Bildnis aus Anschlüssen und Ad-

aptern lässt sich leicht auf Teile vonAnwen-dungenübertragen:DieBenutzeroberfläche(GUI - Graphical User Interface) ist ein Bei-spiel für einenAdapter, der dieKommunika-tion zwischen Nutzer und Anwendung er-möglicht. Eine Datenbank ist ein Adapter,der die Datenhaltung verwaltet.Eine Anwendung nach dem „Ports and

Adapters“-Muster lässt sich generellwie folgtdarstellen: Ein Sechseckwird verwendet, umzu verdeutlichen, dass eine Innen- und Au-ßenasymmetrie besteht und dass verschie-dene, in ihrer Funktion ähnliche Ports gibt.Es soll zudemdarstellen, dass es eineAnzahlunterschiedlicher Ports vorhanden ist. Dabeigeht es nicht um die Zahl Sechs im Speziel-len. Vielmehr erhalten Entwickler beimEnt-wurf Platz, um die verschiedenen Ports undAdapter einzuzeichnen. Der alternative Na-me desMusters (“Hexagonale Architektur“)leitet sich von dieser Darstellung ab.Bei Ports werden primäre und sekundäre

Ports unterschieden. Primäre Ports sind sol-che, die die Anwendung anbietet und vonaußen aufgerufen werden. Die eigentlicheAnwendungslogik ist z.B. ein primärer Port.Sekundäre Ports werden von der Anwen-

dung selbst aufgerufen. Der Port für die Da-tenhaltung ist ein solcher sekundärer Port.

Vorgehen und Vorteile von„Ports and Adapters“Beim Entwurf von Anwendungen nach

dem „Ports and Adapters“-Muster beginntman üblicherweise mit der Definition dereinzelnenPorts. Eine „klassisch aufgebaute“

Hexagon: Die Anwendung ist das zentrale Bauteilund bietet Ports für eine Vielzahl von Adaptern. Security

Bahnhofstraße 3D-88690 Uhldingen

Telefon +49 7556 25999 [email protected]

Konzepterstellung

HAB / Secure Boot

Container

Hypervisor

Secure Update

Update/

Management Server

Life Cycle Support

Security

L I N U X F O R I N D U S T R Y

document7347405734583432973.indd 13 20.11.2017 14:56:19


http://www.linutronix.de

14



AnwendungmitDatenhaltung,Geschäftslo-gik und Benutzeroberfläche besitzt zu-nächst, vereinfacht dargestellt, zwei Ports:zum einen den Benutzer- und zum anderenden Datenhaltungsport.Der Benutzer soll die Anwendung durch

eine HTML-Oberfläche steuern können. An-deren Clients bzw. Tests sollen die Möglich-keit haben unsere Anwendungmittels einerREST-Schnittstelle zu steuern.DieDatenderAnwendung sollen in einer Postgres-Daten-bank gespeichert werden können. Und zuTestzwecken soll esmöglich seindieAnwen-dung ohne eine Datenbank zu betreiben.Daraus ergeben sich effektiv vier Adapter,

die Sie der entsprechenden Abbildung ent-nehmen können (siehe „Systermaufbau imÜberblick“). Im Anschluss an die DefinitionderAdapter undPortswerdenderenSchnitt-stellen beschrieben. Dies kann entweder inUMLgeschehenoder direkt durchdie Erstel-lung von Interfaces,wieman sie ausC#oderJava kennt.Nach dem Entwurf der einzelnen Ports

beginntmanmit der Implementierung. Ent-scheidender Vorteil: Die Implementierungder Adapter kann ab diesem Zeitpunkt par-allel erfolgen, denn die Subsysteme der An-wendungkommunizierennur über die zuvordefinierten Ports. Daraus ergeben sich fol-gende Vorteile:1. Klare Einteilung der Komponenten:Der

Einsatz des Patterns führt zu einer eindeuti-gen Einteilung der unterschiedlichen Kom-ponenten. Alle Objekte, die beispielsweisefür die Darstellung der Anwendung ge-braucht werden, existieren lediglich im ent-sprechenden GUI-Adapter, während die fürdie Kommunikationmit der Datenbank not-wendigenObjekte nur demDatenbankadap-ter bekannt sind.2. Eine Anwendung in mehreren Ausprä-

gungen: Ähnlich wie in einem Baukasten-prinzip lassen sich in der Hexagonalen Ar-chitektur verschiedene Varianten einer An-wendung zusammenfügen. Sowäre es denk-bar den Postgres-Datenbank-Adapter durcheinen Android-SQLite-Adapter und den HT-ML-UI-Adapter durch einennativenAndroid-UI-Adapter zu ersetzen. Mit dem Austauschvon lediglich zwei Komponenten wandeltman die Anwendung zu einer nativen And-roid-Anwendung, ohne dass die eigentlicheGeschäftslogik geändert werdenmuss.3. Parallele Entwicklung:Die klare Eintei-

lung in Komponenten und in wohldefinier-ten Schnittstellen ermöglicht es verschiede-nen Teams oder Einzelpersonen parallel ander jeweiligen Implementierung zu arbeiten.ZumZeitpunkt des Entwicklungsstarts ist eseinfach das Verhalten noch fehlender Kom-

ponentenmit „Test-Adaptern“ zu simulieren.So muss man nicht auf die Fertigstellungetwa der Datenhaltungsschicht warten.4. Austauschbarkeit der Adapter:Sollte es

notwendig sein Funktionalität auszutau-schen, beispielsweise dasDatenbanksystemzu ersetzen, darf sich aus Anwendungssichtnicht zwangsweise auch das Protokoll zwi-schen der Anwendung und der Datenhal-tungskomponente ändern. Durch den Ein-satz von „Ports and Adapters“ kann mandiesesRisikominimieren.Adapter sind leichtaustauschbar; daher ist ein Wechsel zwi-schen Datenbanken nichts weiter als einWechsel des entsprechenden Adapters.5. Einfache Erweiterbarkeit und Skalier-

barkeit:Durch das konsequente Entwickelngegen Ports lässt sich die grundlegende Ad-apterstruktur leicht ändern. Sowäre es denk-bar die einzelnen Adapter des Systems alsMicroservices zu realisieren. Ohne größerenAufwand ist es somöglich eine Anwendungvon einem lokalem zu einem verteilten Sys-tem zumigrieren.6. Keine Festlegungauf eineZulieferform:Da die Hexagonale Architektur keinerlei

Annahmen über die Darstellung der Datenunddie EntgegennahmederBenutzereinga-ben trifft, ist man folglich an dieser Stelleauchnicht festgelegt. Hatman seineAnwen-dung ursprünglich als schichtenbasierteWebanwendungentworfen, so ist esmitunterschwer ihre Funktionalität einer mobilenAnwendung zur Verfügung zu stellen. ImFalle der Hexagonalen Architektur stellt diemobile Anwendung nur einen weiteren Ad-apter für die Entgegennahme der Benutzer-eingaben dar.

7. Keine Festlegung auf eine Architektur-form innerhalb der einzelnenKomponenten:Innerhalb derHexagonalenArchitekturwer-den keinerlei Annahmen über den Entwurfder einzelnen Adapter getroffen. Um bei-spielsweise einewebbasierte Oberfläche alsAdapter für die Benutzerinteraktion zu ent-wickeln, kann man sich problemlos einesMusters für dieOberflächenentwicklung,wieetwa MVC (Model-View-Controller), bedie-nen.

Höhere Komplexität und Or-chestrierung der AnwendungWie jede Architekturentscheidung bringt

auch die Hexagonale Architektur Nachteilemit sich. ZumEinen resultiert die Implemen-tierung in einer höherenKomplexität: Durchden Einsatz jeder Abstraktion erhöht sichzwangsläufig die Komplexität der betroffe-nenAnwendung.Anders als bei einermono-lithischen Anwendung befinden sich dieeinzelnenKomponentendesGesamtsystemsmitunter nicht mehr an einem Ort. Mögli-cherweise sind sie übermehrere Projekte undSubprojekte verteilt, was dazu führt, dasssich neue Kollegen zunächst mit der Orien-tierung etwas schwerer tun.ZumAnderenwird eineOrchestrierungder

Anwendung notwendig. Um die einzelnenTeile der Anwendung zusammenzufügen,bedarf es einer Komponente für dieseAufga-be. Diese kann ihrer Aufgabe manuell oderper Dependency Injection nachkommen.Letzteres wiederum erhöht die Komplexitätzusätzlich.Die Hexagonale Architektur hat wie jedes

Architekturmuster ihren Preis undmag sichfür sehr kleine Projekte nicht lohnen. Ist je-doch abzusehen, dass es sich bei einer neuzu entwickelnden Anwendung ummehr alsnur einenPrototyphandelt oder dass sie übereinen langen Zeitraum imEinsatz seinwird,lohnt sich die Investition sicherlich.Erfahrungsgemäß eignet sich das Muster

in der Praxis hervorragendundbereitet demSchichtensalat erfolgreich ein Ende. Nichtnur lassen sich Anwendungen ganzheitlichund inTeilen sehr einfach testen, dasMusterist auch eine echte Investition in die Wart-und Erweiterbarkeit der zu entwickelndenAnwendung.Man möchte eines schönen Tages seine

bisherigeDesktopanwendungauch imWeb,auf Smartphones oder Tabletts anbieten?Wohl dem, dessen Anwendung nach „PortsandAdapters“ entwickeltwurde - die brand-neuemobileAnwendung ist nurwenigeneueAdapter entfernt. // SG

Method Park

Vereinfachte Darstellung: Eine Anwendung mit zweiPorts.

Systemaufbau im Überblick: Eine klassischeAnwendung mit UI und Datenbank im Stil der hexa-gonalen Architektur

document7347405734583432973.indd 14 20.11.2017 14:56:21

Deutschlands größter Kongressfür Embedded Software

Professionals

1168

5

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

4. bis 8. Dezember, Sindelf ingen

GOLDSPONSOREN

VERANSTALTER

Keynote:

Wenn Maschinen lernen – Chancen undHerausforderungen des Machine Learning

Prof. Dr. Oliver Niggemann,Fraunhofer IOSB-INA

Vortrag:

C++ 17 –Was gibt’s Neues?

Rainer Grimm,Modernes C++

Kompaktseminar:

Echtzeitbasiertes Software Engineering

Prof. Dr. Christian Siemers,TU Clausthal

Informieren Sie sich unter:

www.ese-kongress.deWeitere Informationen:Sabine Pagler | +49 (0)89 4506 1746 | [email protected]

Hören Sie 2017 unter anderem:

10JAHRE

Jetztanmelden!

11685_ANZ_EP_ESE_Kongress_2017_a4_d_highlights_ja_EP_22.indd 1 24.10.2017 09:36:40

http://www.ese-kongress.de


16

IMPLEMENTIERUNG // DATEISYSTEM


Vorteile und Herausforderungen fürEmbedded-IoT durch NAND-Flash

Datenunsicherheiten und Vibrationsprobleme disqualifizieren klas-sische Speicher oft für Embedded-IoT-Anwendungen. NAND-Flash istmeist besser, doch gilt es auch hier einige Designaspekte zu beachten.

DAVE HUGHES *

* Dave Hughes... ist CEO von HCC Embedded.

NAND-Flash ist die zentrale Technolo-gie in einer Vielzahl von Speichernvon SSDs über SD-Cards bis zu

eMMCs, in denen eine große SpeicherdichteundeinhohesPerformance-Niveaugefordertwerden. Kennzeichnend für NAND-Flashsinddie niedrigenKostenproBit, die kurzenLösch- und Schreibzeiten und der auf denDatenbus gemultiplexteAdressbus,wodurchdie Elektronik weniger komplex wird.NAND-Flash-Speicher sind in Blöcke un-

terteilt, die wiederum in physische Seitengegliedert sind. Jede Seite enthält einen Be-reich für die Daten und einen Reservebe-reich, der für NAND-Managementdaten ge-nutztwird. Eswird immermehr üblich, dassNAND-Flash-Speicher ausmehrerenEbenenbestehen, die sich unabhängig adressieren

und parallel programmieren oder löschenlassen. Bild 1 zeigt einen traditionellen, ineinen Mikrocontroller eingebauten NAND-Flash-Controller.

Design-Herausforderungen beiNAND-Flash-SpeichernBeim Einsatz von NAND-Flash-Speichern

ergeben sich mehrere Herausforderungen.Die verschiedenenArten vonNAND-Baustei-nen weisen unterschiedliche Fehlercharak-teristika auf, beispielsweisewasdie Zahl derdefekten Blöcke, die Bad-Block-Marker unddie ECC-Anforderungen (Error CorrectionCode) angeht. Die ECC-Anforderungenmüs-sendeshalb andieNAND-Controller-Schnitt-stelle des jeweiligen Mikrocontrollers ange-passt werden. Darüber hinaus erfordertNAND-Flash auch komplexe Management-funktionenwie dasBad-Block-Managementund dasWear-Leveling.Error Correction Code (ECC): Die im un-

günstigsten Fall auftretende Verschleißratewird durch den Flash-Hersteller definiert.

Mit ECCs wird dabei sichergestellt, dass dieDaten beim Einsatz unter Einhaltung derChipspezifikationen stets konsistent sind.Die Stärke (d. h. die Zahl der Bits) des benö-tigten ECC richtet sich nach derWorst-Case-Bitfehlerrate.Bad-Block-Management: Schonwennein

Flash-Speicher neu ist, kann er Blöcke ent-halten, die fehleranfällig oder nicht nutzbarsind.WährenddesBetriebs könnenDaten ineinwandfreienBlöcken später verfälschtwer-den– sei es durchdasAbfließen vonLadungoder durch Störungen infolge von Schreib-vorgänge in benachbarten Teilen des Chips.Spezielle Software verwaltet die defektenBlöcke und verzeichnet nicht nutzbare Be-reiche, umeinVerfälschen derDaten zu ver-hindern.Wear-Leveling: Flash-Zellen haben eine

begrenzte Lebensdauer, d. h. sie könnennicht unbegrenzt häufig gelöscht und neuprogrammiertwerden, bevor sie unzuverläs-sig werden. So genannte Wear-Leveling-Al-gorithmen erhöhen die Lebensdauer desChips insgesamt, indem sie die Daten sozwischendenphysischenBlöcken verlagern,dass die Zellen möglichst gleich abgenutztwerden. Diese Algorithmen lassen sich aufdie Performance-Anforderungenabstimmen.

Softwarebasierter FTL gegendas Wear-Leveling-ProblemWegenderNotwendigkeit zurUmbelegung

defekter Blöcke kommt es in den meistenAnwendungen nicht in Frage, einen NAND-Baustein wie eine lineare Anordnung vonSpeicherzellen zubehandeln.Notwendig istdeshalb eine logischeUmsetzungder physi-schen Blöcke, wofür ein softwarebasierterFlash Translation Layer (FTL) eingesetztwird. Der FTL präsentiert eine Anordnunglogischer Sektoren, die die Komplexität desdarunter befindlichenphysischenBausteinsverbirgt, sodass er vom Designsystem wiejeder andere Medientreiber behandelt wer-den kann.

Traditioneller Wasserzähler: Designer von digitalen, mit dem Internet verbundenen Zählerinstrumentensollten auf NAND-Flash-Speicher setzen. Das hat Konsequenzen für die Wahl des Dateisystems.

Bild:gem

einfrei

document6801819603087235641.indd 16 20.11.2017 14:13:02



InAnwendungen, indenenFlash-Speichersehr oft gelöscht und neu beschrieben wer-den, nimmt sich der FTL auch des Wear-Le-veling-Problems an, umdie Lebensdauer desProdukts zu erhöhen. Man unterscheidetzwischen dem dynamischen und dem stati-schen Wear-Leveling. Beim dynamischenWear-Leveling wählt das System für dennächstenSchreibvorgangdenbisher amwe-nigsten genutztenBlock aus. DieseMethodeist relativ wenig wirkungsvoll, da sie keineDatenblöcke berücksichtigt, deren Inhaltunverändert bleibt.Beim statischen Wear-Leveling dagegen

werden zuwenig genutzte Blöcke getauscht,um die Abnutzung gleichmäßig auf den ge-samten Baustein zu verteilen. Das statischeWear-Leveling bedarf allerdings einer sorg-fältigen Abstimmung um sicherzustellen,dass das Tauschen der Blöcke nicht unnötigzur Abnutzung des Bausteins beiträgt. Manerreicht dies üblicherweise durchdie Festle-gung sinnvoller Grenzwerte für das Tauschenvon Blöcken. Ein Vergleich zwischen dyna-mischemunddemstatischemWear-Levelingist in Tabelle 1 aufgeführt.

Herausforderungen für dasDateisystem bei Flash-EinsatzWerden das Dateisystem oder sein Inhalt

verfälscht, kann dies für ein Embedded-System ein gravierendes Qualitätsproblemdarstellen. Um Tests und Verifikationen inder Design- und Implementierungsphaseeinzurichten, muss sich der Designer mitgrundlegenden Designherausforderungenauseinandersetzen. Unter anderem geht esum den Umgang mit Dateioperationen undOrdnerstrukturen undmit der Integrität derDaten beim Ausfall der Stromversorgungoder bei unerwarteten Resets sowie um dieVerifikation, dass der Flash-Speicher ord-nungsgemäß funktioniert.Traditionell wird die Abwicklung von Da-

tei- und Ordner-Operationen an ein einge-bettetesDateisystemdelegiert. DasDateisys-tem allein kann aber nicht die Integrität der

DatenunddesDateisystems selbst garantie-ren. Ganz gleich, welche Fail-Safe-Methodeverwendet wird, ist das System zur Realisie-rung des geforderten Service-Levels auf dasSpeichermedium angewiesen. Ein System,das gesicherte Zuverlässigkeit bieten soll,muss ein klares Verständnis der kritischenAusnahmesituationen (z. B. unerwartete Re-sets oder Stromausfälle) beinhalten und be-rücksichtigen,wie jeder Teil des SystemsdieAnforderungen der Komponenten, von de-nen es genutzt wird, beim Auftreten dieserSituationen erfüllt. Die einfache Verwen-dung eines Dateisystems, das angeblich ei-nen ausfallsicheren Betrieb oder Journalingbietet, kann in keiner Weise einen zuverläs-sigenBetrieb garantieren, solangedieseDin-ge nicht definiert sind.

Stromausfall, unerwarteterReset und SystemausfallWerden die vom Dateisystem verwalteten

Daten verfälscht, können die Folgen katast-

Bild 1: Beim Vergleich von NAND-Flash-Speichernohne bzw. mit Gehäuse sind verschiedene wichtigeAspekte zu beachten, wie etwa die ECC-Anforderun-gen und die Forderung nach komplexen Manage-mentfunktionen wie Wear-Leveling und Bad-Block-Management.

Bilder:H

CCEm

bedd

ed

WEAR-LEVELING-METHODE

VORTEILE NACHTEILE

Statisch • Maximale Lebensdauer • Erhöhter Controller-Aufwand

• Effiziente Nutzung des Speichers • Komplexere Implementierung

• Langsamere Schreibzugriffe

• Höherer Stromverbrauch

Dynamisch • Einfache Implementierung • Unsicherer Abnutzungsvorteil

• Wenig Aufwand

Tabelle 1: Vor- und Nachteile der beiden Wear-Leveling-Methoden

www.embedded-tools.de

Cross-CompilerPowerPC, TriCore, RH850, ARM

UI Design +Development

RTOS-Trace

IoT, EmbeddedInternet

RTOS +Middleware

Requirements

x86 BIOS / UEFI

software inc.

SU

PP

OR

T

VE

RT

RIE

B

document6801819603087235641.indd 17 20.11.2017 14:13:05

http://www.embedded-tools.de

18



rophal sein. Ein ausfallsicheresDateisystemgarantiert, dass die von ihm im Flash-Spei-cher verwaltetenMetadaten stets konsistentsind und dass alle von einer Applikation anden Flash-Speicher gerichteten Schreibzu-griff ‚atomar‘ (im Sinne von ‚nicht weiterunterteilbar‘) ausgeführtwerden.Das bedeu-tet also, dass die betreffende Schreibopera-tion entweder vollständig abgeschlossenwird oder der Speicher in dem Zustand ver-bleibt, in dem er sich vor der Veranlassungdes Schreibzugriffs befand. Sowirddie Inte-grität der vom Dateisystem übergebenenDaten gewährleistet. Um wirkliche Ausfall-sicherheit zu garantieren, muss jede Ebene

von der Applikation bis zum physischenTreiber spezifizieren,was sie vonder benach-barten Ebene verlangt.Folgende Eigenschaften sind von einem

ausfallsicheren System gefordert (Bild 2):�Nach einem System-Reset befindet sichdas Dateisystem stets in einem konsisten-ten Zustand.� Jede Datei, die beim Auftreten eines un-erwarteten Resets geöffnet war, wird in denZustand vor dem Öffnen zurückversetzt,sofern keine Flush- oder Schließoperationmit dieser Datei erfolgreich beendet wurde.�Die Ausfallsicherheit eines Dateisystemskann nur dann garantiert werden, wenn

der zugrundeliegende Treiber eine definier-te Dienstqualität garantiert.Für das Dateisystem folgt hieraus:

� Jede Schreiboperation muss entweder er-folgreich beendet werden oder eine Fehler-meldung erzeugen, oder das Dateisystemmuss neu gestartet werden.� Sämtliche Schreibzugriffe auf das Medi-um sind in der Reihenfolge auszuführen, inder sie an den Treiber gerichtet wurden.� Jede Löschoperation muss entweder er-folgreich beendet werden oder eine Fehler-meldung erzeugen, oder das Dateisystemmuss neu gestartet werden.In der Praxis bedeutet dies, dass dieHard-

ware ein gewissesMaßanSpannungsschutzbieten muss, um sicherzustellen, dass dasSystem entsprechende Maßnahmen ergrei-fen kann, wenn die Versorgungsspannungdes Flash-Mediums unter die spezifizierteProgrammierspannung sinkt.

Performance und Effizienz desSystemsUmmit einem komplexen Flash-Baustein

wie einem Multi-Plane-NAND oder einemArray mehrerer NAND-Chips ein hohes Per-formance-Niveau zu erzielen, muss ein FTLmehrereBausteine parallel lesen, schreibenund löschen. Im Interesse einer effizientenFlash-Nutzungund echterAusfallsicherheitist es besser, dieses Problem auf der FTL-anstatt auf der Treiber-Ebene anzugehen.

Überlegungen zum Power-Ma-nagementDas Power-Management verhindert, dass

der Flash-Speicher gelöscht oder geschrie-ben wird, wenn sich die Stromversorgungaußerhalb derHerstellerspezifikationenbe-findet. Ein sorgfältig entwickelter FTL spezi-fiziert dieAnforderungendesuntergeordne-ten Treibers einschließlich der Stromversor-gungs-Anforderungen, um einen ausfallsi-cheren Betrieb zu gewährleisten. Designersollten die entsprechenden Spezifikationenvom Softwarezulieferer anfordern. Wennbeispielsweise dieVersorgungsspannungaufden spezifizierten Mindestwert fällt, solltedie Brown-out-Erkennung das System ent-sprechend informieren, damit es mit dieserSituation umgehen kann.NAND-Flash ist eine ideale Speicheroption

für viele Embedded- und IoT-Anwendungen,solange sich die Designer der damit verbun-denenHerausforderungenbewusst sindundgeeigneteHilfsmittel undTechniken anwen-den, um einen langen und zuverlässigenBetrieb zu gewährleisten. // SG

HCC EmbeddedBild 3: HCC Embedded bietet ausfallsichere Dateisysteme für alle Flash-Typen. Es handelt sich dabei um dashocheffiziente SafeFlash für Produkte, in denen es auf die Datenintegrität ankommt.

Bild 2:Kein Dateisystemkann für sich alleinAusfallsicherheit re-klamieren. Stattdessenwird ein systemweitesDesign benötigt.

document6801819603087235641.indd 18 20.11.2017 14:13:09

19

AKTUELLE PRODUKTE // TESTING & RTOS


PLS UDE 4.8.3

Vereinfachte Fehlersuche bei S32K1 Automotive-MikrocontrollernDie S32K1-Plattform kombinierteine skalierbare Familie vonARM Cortex-M-MCUs mit spezi-ellen, für künftigeAutomobilan-wendungen optimierten Funkti-onen. Dank ihrer extrem niedri-gen Leistungsaufnahme, 128KByte bis 2 MByte Flash-Spei-cher, ISO CAN FD, speziellenHardware-Sicherheitsfunktio-nen wie CSEc (CryptographicService EngineCompressed) undASIL-B-Unterstützung sind dieAutomotive-MCUs vielseitig ein-setzbar. DurchdieUnterstützungaller internenDebug-Funktionen

Step-Betrieb etwaauchdie inter-nenSystemzustände zur Laufzeitvisualisieren. Die Darstellungvon Applikationsvariablen, deruneingeschränkte Zugang zuden Core- und Peripheral-Regis-tern sowie die grafische Darstel-lung von Systemwerten in Dia-grammen erlauben es dem An-wender, komfortabel und effizi-ent das Laufzeitverhalten seinerApplikation zu beurteilen.Für eine effiziente Test-Auto-

matisierung und die Kopplungvon Testtools Dritter ist die UDE4.8.3mit einer,auf demMicrosoft

Common Object Model (COM)basierenden Automatisierungs-schnittstelle ausgestattet. Diesermöglicht Entwicklern auch einumfangreiches Scripting derUDE 4.8.3. Ein kombinierter Tar-get-Adapter für die Zugangsgerä-te der Universal Access Device-(UAD-) Familie von PLS stellt si-chere, schnelle Kommunikationzwischen der UDE 4.8.3 und denS32K1-MCUs via JTAG oder überdie ARM-spezifische SDW-Schnittstelle sicher.

PLS

der S32K1-Plattform ist die UDE4.8.3 ein ideales Werkzeug zurFehlersuche und System-Analy-se. Über die Bedienoberflächeder UDE 4.8.3 lassen sich nebender traditionellen BenutzungvonBreakpoints unddemSingle-

PARASOFT C/C++TEST UND DTP

Erweiterte Entwicklungstestplattform für Embedded IoTParasoft hat zwei seiner Test-Toolsetsmit zahlreichenVerbes-serungen speziell für Embedded-IoT-Anwendungen ausgestattet:Parasoft C/C++test, die Softwarezur statischen Analyse und fürModultest in C und C++, und dieReporting- und Analyseplatt-formParasoft DTP (DevelopmentTesting Platform), die Einblickein den SDLC (Software Develop-ment LifeCycle) bietet.Als Teil der Parasoft Suite er-

leichtern diese Lösungen diebewährten Methoden bei Ent-wicklung, Fehlererkennungund

Dieses Update von C/C++testund DTP rundet das Update dergesamten Suite an Entwick-lungstesttools von Parasoft ab.Mit Schwerpunkt auf der Soft-

ware-Qualität unterstützt Para-soft weiterhin viele Plattformenund Compiler. Das neue Releaseenthält nunSupport fürWindRi-verGCC4.8.x, IAR fürARM8.11.xund Microsoft Visual C++ 14.1x.Parasoft treibt seine Innovatio-nen mit der Weiterentwicklungder Schlüsseltechnologie zurstatischen Analyse voran, beiOptimierung bestehender und

Schaffung neuer Regeln, die so-wohlMISRA2008als auch siche-re Codier-Richtlinien für Ent-wickler und Embedded IoT-An-wendungen abdecken.

Parasoft

Behebung von Sicherheits-schwachstellen.Die Technologi-en für statische Analyse undModultests vonC/C++test lassensichmühelos in intelligenteAna-lysen von Parasoft DTP integrie-ren, um Qualitäts- und Compli-ance-Initiativen effizienter zugestalten.Die neueVersionopti-miert dieArbeitsabläufe der Ent-wickler, indem der Fokus aufdem Support für die Umgebungund Infrastruktur liegt. Zudemerleichtern ausgestaltete Dash-boards und Reports den Nach-weis derKonformitätmitMISRA.

ECHTZEITBETRIEBSSYSTEM

Integrity-Lösungen für den Zynq Ultrascale+ MPSoCGreen Hills Software bietet absofort sein betriebs- und daten-sicheres (Safe&Secure) Echtzeit-betriebssystem (RTOS) Integrityinklusive zugehöriger Produkte/Dienste für das ZynqUltraScale+MPSoC von Xilinx an. Die kom-binierte Plattform vereint dieSoftware-Programmierbarkeiteines 64-Bit-Prozessors und dieHardware-Programmierbarkeiteines FPGAs in der bewährtenLaufzeitumgebung.Kunden können somit ab so-

fort die umfassenden Green-Hills-Funktionen für ihre auf

Störungen bei der Datenverar-beitung und Kommunikationzwischen Prozessen. Ebenfallsenthalten sind der Multi 64-BitIDEundDebugger, optimierendeGreenHills C/C++-Compiler und64-Bit-Toolchain, Profiler und

vieleweitere integrierte, zeitspa-rendeTools. Die Integrity-Lösun-gen für den Zynq Ultrascale+MPSoC bieten eine integrierteÜberprüfungder Code-Qualität,einschließlichMISRAC/C++Ad-herence Checker und Double-CheckStaticAnalyser. EinCloud-basiertes Device Lifecycle Ma-nagement (DLM) verwaltet siche-re Anmeldeinformationen überdie gesamteWertschöpfungsket-te hinweg, sogar über nicht ver-trauenswürdige Netzwerke.

Green Hills Software

dem Zynq UltraScale+ MPSoCbasierten kundenspezifischenProdukte erstellen. Dazu zähltdas etablierte RTOS Integrity, dieleistungsorientierte Unterstüt-zungder 64-Bit Cortex-A53-Coresvon ARM nutzt dabei NEONSIMDundHardware-Virtualisie-rung. Als optionale zukünftigeFunktion betreibt die sichereVirtualisierung des INTEGRITYMultivisor Gastbetriebssystemewie Linux und Android sowieechtzeitkritischeAnwendungen,die Betriebs- und Datensicher-heit erfordern. Dies vermeidet

document1992843822488808849.indd 19 21.11.2017 09:20:57

20

TEST & QUALITÄT // ENTWICKLUNGSSTRATEGIE


Test-Chaos vermeiden mit derDeploy-and-Destroy-Strategie

Software ist oft die primäre Schnittstelle zwischen Unternehmen undihren Kunden. Einbußen in der Qualität zugunsten der Durchlaufzeitsind hier keine Option. Wie ist also hohe Qualität zu garantieren?

ARTHUR HICKEN *

* Arthur Hicken... ist Chief Software Evangelist beiParasoft

EinewichtigeVoraussetzung ist der un-gehinderte Zugang zu realistischen,vollständigen Testumgebungen (z.B.

die Anwendung und ihre abhängigen Kom-ponenten unter Test). Er verhilft zu einerhöheren Durchsatzgeschwindigkeit und er-möglicht auch die Risiko-Einschätzungeines Freistellungskandidatenwährend desCI/CD (Continous Integration / ContinuousDelivery)-Prozesses und somit die Identifi-zierung von Kandidaten mit einem hohenRisiko bereits früh in der Lieferkette.Moder-ne Technologie ermöglicht dieBereitstellungrealistischer simulierter Testumgebungen

auf Bedarf. DankderVerfügbarkeit vonTech-nologienwie z.B. Cloud (für flexible Skalier-barkeit), Container (für schnellen Einsatz)und Service-/ Anwendungs-Virtualisierung(für das Simulieren und den Zugriff auf ab-hängige Systeme) besteht kein Grundmehr,warumeine realistischeTestumgebungnichtverfügbar sein sollte. Hier setzt die „Deployand Destroy“ Strategie an.

Was versteht man unter„Deploy and Destroy“?Im Wesentlichen handelt es sich hierbei

um die Fähigkeit, eine vollständige Testum-gebung in weniger als 10 Minuten bereitzu-stellen (to deploy). Die meisten abhängigenKomponenten (wie u.a. APIs, Services vonDritten, Datenbanken, Anwendungen), diezu einem bestimmten Zeitpunkt verfügbarseinmüssen,werden in einemzentralenRe-

pository zusammengefasst und dann auto-matisch bereitgestellt. Typischerweise isteine Deploy and Destroy Umgebung leichtund Cloud-kompatibel, also einfach undnach Bedarf skalierbar. Und sie ist auchleicht wieder zu entsorgen. Sie kann direktvon einem Golden Template generiert, ge-nutzt und anschließend wieder verworfenwerden (to destroy). Die Testumgebung undTestdaten lassen sich sofort und ohne zeitli-chen Aufwand wieder in ihren ursprüngli-chen Zustand versetzen.Der erste Schritt einerDeploy andDestroy

Umgebung ist das Erstellen einer Bibliothekan Service Virtualisierungsassets. Üblicher-weise erfolgt dies durch die Aufnahme desZusammenspiels einer tatsächlichenAnwen-dungen, aber auchandereMethodenkönnenzum Einsatz kommen (z.B. durch das Kreie-ren von Swagger oder anderer Definitionen,durch Traffic Dateien). Falls gewünscht,können diese Assets mit weiteren Daten,Leistungsprofilen oder Response Logik er-weitert und verbessert werden.Ist ein Fundament an virtuellen Assets er-

stellt, lassen sich diese in einer ‚Umgebung‘zusammenfassen. Ausgehend von einemKernsystemplan definiert eine Umgebung,welche Zustände die Abhängigkeiten derAnwendung unter Test (AUT) einnehmendürfen. Um den Bereitstellungsprozess zuverfeinernund zubeschleunigen, ist dieVer-knüpfungder bereitgestelltenUmgebungenmit einer Containertechnologie (z.B. Docker)sinnvoll. Das ermöglicht das Verpacken derUmgebungen und deren Bereitstellung auflaufendeContainer,wodurchkomplette Test-umgebungen in Sekundenschnelle zur Ver-fügung stehen.

Die Wertschöpfung von „Deployand Destroy“Frühes und kontinuierliches Testen – So-

bald ein Anwendungsfall (User Story) voll-ständig ist, kann mit dem Testen begonnenundeineVielzahl vonUser Stories gleichzei-

Bild 1: Eine der Möglichkeiten, wie Container zur Umsetzungeiner Deploy & Destroy Strategie genutzt werden können.

Bild:Parasoft

document3684979012400368332.indd 20 20.11.2017 13:45:56


tig während des Continuous Testing Prozes-ses validiertwerden, jede inder für die jewei-ligen Tests benötigten spezifischen Testum-gebung.Größere Flexibilität - ImVergleich zu einer

realen, physischen Testumgebung erlaubtdie Simulation (z.B.mithilfe der Service Vir-tualisierung) die flexiblere Bereitstellungvon Testumgebungen. So können auch ext-remenFälle getestetwerden, z.B. Concurren-cy, Resiliency, Failover oder Load BalancerProbleme.Realistischer als die echte Testumgebung

- Oft sind reale, physisch eingerichtete Um-gebungen von Hardware-Restriktionen ge-prägt und ihre Leistung ist beschränkt. Ser-viceVirtualisierung verleiht Testern bessereKontrolle darüber, wie die abhängigen Sys-teme und Anwendungen reagieren. Indemeine Deploy and Destroy Umgebung denVerkehr auf simulierte Endpunkte umleitet,ermöglicht sie die Durch-/Fortführung derTests, alswärendie realen SystemeoderAn-wendungen verfügbar.Datensicherheit undPrivatsphäre - Durch

die simulierteUmgebungwirdder Zugriff aufDatensätze gewährt, die bereits gesäubert,bzw. verdeckt sind, daher spielen Sicher-heitsbedenken keine Rolle – auch nicht beiunbefugtemZugriff oderAngriff einesAssets.Konsistenz und Genauigkeit - Deploy and

Destroy stellt sicher, daß alle Beteiligtenübereinstimmend ihreAktivitätendurch Zu-griff auf die neuestenTestobjekte /Datenundvirtuellen Artefakte koordinieren können.JedesMal bei der Bereitstellung einer neuenTestumgebung wird diese über den Zugriffauf den Masterdatensatz, die virtuellen As-sets und Testobjekte in der Repository vongrundauf neu kreiert. Das verhindert, dassTests in „verunreinigten“ Umgebungen aus-geführt werden, und veraltete Daten odernicht autorisierte Versionen von virtuellenAssets zum Einsatz kommen.Die Implementierung einer Deploy and

Destroy-Strategie wirkt sich schnell auf dieGeschäfte vonEntwicklungs- undTestunter-nehmenaus. In einer Zeit, in derAnwendun-gen immer schneller und fehlerfrei abgelie-fert werden sollen, spielt die Service-Virtua-lisierung eine zunehmendwichtigeRolle, umEngpässe während der Testphase zu verrin-gern. Das macht Deploy and Destroy zurStrategie für Unternehmen und Anwen-dungsanbieter, um sich von Mitbewerbernzu unterscheiden, und um den eigenen fi-nanziellen Erfolg abzusichern.Eine ungekürzte Fassung dieses Beitrags

finden Sie online unter bit.ly/2j7RzpC. // SG

Parasoft

mit einer riesigen Auswahl

mit bester Qualität

mit einzigartigem Service

buerklin.com

Das funktioniert

document3684979012400368332.indd 21 20.11.2017 13:45:57

22

ECHTZEIT-BETRIEBSSYSTEME // TRACKING & TRACING


Trace-Visualisierung beimDebugging von RTOS-Firmware

Echtzeit-Betriebssysteme sind in Embedded Systemen längst festetabliert. Um RTOS-basierte Systeme vernünftig zu debuggen, bedarf

es aber besserer Einblicke in ihre Echtzeitverarbeitung.

DR. JOHAN KRAFT *

* Dr. Johan Kraft... ist CEO und Gründer von PercepioAB.

ZurZeit befindenwir uns inmitten einerbedeutenden Umstellung in der Firm-wareentwicklung: die zunehmende

VerwendungvonEchtzeit-Betriebssystemen(Real-Time Operating Systems – RTOS) ver-körpert die dritte Generation der Entwick-lung von Embedded-Software. Ein RTOS istein schnelles, deterministischesBetriebssys-tem zum Einsatz in Embedded- und IoT-An-wendungen. Seine Hauptaufgabe ist Multi-threading, um die Aufteilung der Software-funktionalität inmehrere ‚parallel‘ laufendeTeilprogrammeoder‚Tasks‘ zu ermöglichen.RTOS sind kein Hype wie noch vor 10 bis

15 Jahren. Im Embedded Market Survey istdies klar erkennbar. Auf die Frage nach der

‚größten technologischenHerausforderung‘wird am häufigsten das RTOS genannt. DerAnteil dieserAntwortwuchs von 12% im Jahr2013 auf 26 % im Jahr 2015. Der historischsehr fragmentierteMarkt scheint sich jetzt ineiner Konsolidierungsphase zu befinden, inder sichdie Entwickler zunehmendden füh-renden Akteuren zuwenden.

Herausforderungen bei derAnwendung eines RTOSEin RTOS übernimmt die Kontrolle über

die Programmausführungundbringtmit denTasks einenneuenAbstraktionsgrad ein.DerKontrollfluss eines Programms lässt sichnunnichtmehr aus demQuellcode ersehen; dasRTOS entscheidet, welche Task ausgeführtwird.Während einRTOSdieKomplexität desQuellcodes einer Applikation verringernkann, reduziert es die derApplikation selbstinnenwohnendeKomplexität nicht. EineAn-sammlung scheinbar einfacher RTOS-Tasks

kann, wenn sie gemeinsam als System aus-geführt wird, zu einem überraschend kom-plexen Laufzeitverhalten führen. Der Ent-wickler muss festlegen, wie die Tasks mitei-nander interagieren und die Daten mit denDienstfunktionen des RTOS teilen sollen.Dem Entwickler obliegt außerdem die Ent-scheidung über wichtige RTOS-Parameterwie die Task-Prioritäten (also die relativeDringlichkeit der Tasks), die durchaus nichtselbstverständlich seinmüssen. SelbstwennSie Ihren gesamten Code nach den bewähr-ten Verfahrensweisen des RTOS-basiertenDesigns geschrieben haben, können andereTeile des Systems, ob es sich nun um Kom-ponenten aus dem eigenen Unternehmenoder von Drittanbietern handelt, in dersel-ben Umgebung laufen, aber sich nicht andieselben Prinzipien halten.Das grundlegendeProblembesteht darin,

dass es sich bei den RTOS-Tasks um keineisolierten Entitäten handelt. Zwischen denTasks gibt esmindestens eineArt vonAbhän-gigkeit, nämlich die von ihnen geteilte Pro-zessorzeit. BeimpräemptivenSchedulingmitfeststehender Priorität können praktischjederzeit Tasksmit höherer Priorität erschei-nen, die dieVerarbeitungder Tasks geringe-rer Priorität verzögern.Andere Arten geteilter Ressourcen (z. B.

globaleDatenoderHardwareperipherie) füh-ren ebenfalls zu Abhängigkeiten zwischenden Tasks und können unvorhersehbareVerzögerungenbewirken,wenndie Synchro-nisationnicht korrekt geplant ist –unabhän-gig von den Task-Prioritäten.Zu einer Prioritätsinversion kann es kom-

men,wenneine Taskhoher Priorität (TaskHin der folgenden Abbildung) auf eine geteil-te Ressource (z. B. eine Kommunikations-schnittstelle) zugreifen will, die gerade voneiner Task mit geringerer Priorität (Task L)belegtwird. TaskHwürdenormalerweise fürkurze Zeit blockiert, bis Task L die geteilteRessource freigibt. Eine Prioritätsinversiontritt dannauf,wennandieser Stelle eine Task

Bild 1: Prioritätsinversion in einer Darstellung von Percepio Tracealyzer.

Bild:Percepio

document2607686280591741862.indd 22 20.11.2017 11:44:16



mittlerer Priorität (TaskM)TaskLunterbrichtunddie hochpriore Taskdadurchweiter ver-zögert. Bei der Pathfinder-MissionderNASAführte dieses Verhalten zu System-Resets,zumVerlust vonDaten undbeinahe auch zueinem Fehlschlag der gesamten Mission.Task-Abhängigkeitenwie Scheduling und

geteilte Ressourcen werden durch Verarbei-tungszeitenunddasEingangs-Timingbeein-flusst. Diesmacht es nahezuunmöglich, reinaufGrunddesQuellcodesAussagenüber dasEchtzeitverhalten einesRTOS-basierten Sys-tems zu machen. Unter dem Einfluss vielerFaktoren können die Tasks langsamer alsvorgesehen laufen, zufällige, unerwarteteVerzögerungenaufweisenoder auchniemalsausgeführtwerden. Selbst,wenndas Systemscheinbar arbeitetwie imLabor vorgesehen,kann es zahllose andere Verarbeitungs-Sze-narien mit mehr oder weniger bedeutendenTiming-Unterschieden geben, die potentiellProbleme bergen. Im schlimmsten Fall be-steht das System die Tests, stürzt aber imPraxiseinsatz beimKunden immerwieder ab.

Das Debugging RTOS-basierterSystemeUm Debugging auf derselben Abstrakti-

onsebene durchzuführen wie die Entwick-lung, haben sichdieDebugging-Tools auf denRTOS-Trendnochnicht entscheidendweiter-entwickelt. EinigeDebuggerwurden zwarmitso genannten ‚RTOS Awareness‘-Featuresaufgewertet, die Ihnen beim Debugging dasInspizieren des Status von RTOS-Objektenwie etwa Tasks und Semaphoren ermögli-chen. Hierbei handelt es sich jedoch nur umNachbesserungenandenQuellcode-Debug-gern der zweiten Generation, deren Fokusstrikt auf Quellcode und Debugging nachdemRun/Halt/Single-Step-Prinzip liegt. EinRTOS-basiertes System mit einem traditio-nellen Source-Level Debugger zu debuggen,ist vergleichbar mit dem Versuch, einen aufderAssembler-Ebene arbeitendenDebuggerbei der C-Programmierung einzusetzen.Um das Laufzeitverhalten eines RTOS-

basierten Systems umfassend zu verstehen,müssen Sie das Echtzeitverhalten auf derRTOS-Ebenebeobachtenkönnen.Dafürwirdein auf RTOSausgerichtetes Tracing-Tool be-nötigt. Dieses operiert als Ergänzung zu tra-ditionellen Debugging-Tools und stellt eineZeitachse auf der RTOS-Ebene bereit.Es gibt zweiArtendes Tracings, die jeweils

geringfügig unterschiedlichenZweckendie-nen.Dashardwarebasierte Tracingwird vomProzessor selbst generiert. Es liefert ein de-tailliertesVerarbeitungs-Trace auf derQuell-code- oder Assembler-Ebene, allerdingsmitwenig oder gar keiner RTOS-Orientierung. Es

wird hauptsächlich für die Überdeckungs-analyse unddasDebuggingbesonders kniff-liger Problemeverwendet, für die einmaschi-nennahes Instruction-Tracingbenötigtwird.Beim softwarebasierten Tracing werden

dagegen kleine Tracecode-Abschnitte in dieZielsoftware eingefügt, um wichtige Ereig-nisse imRTOS sowie optional auch imAppli-kations-Code aufzuzeichnen. Meist mussman den RTOS-Trace-Code aber nicht selbsteinfügen, dennviele RTOS-Kernels enthaltenan strategischen Punkten bereits Trace-Ma-

Bild 2:Screenshot der Haupt-Trace-ansicht (Main Trace View) desPercepio Tracealyzers.Bi

ld:Percepio

kros. Das softwarebasierte Tracing kanndes-halb auf jedem Prozessor genutzt werden,beliebige Arten von Software-Ereignissenspeichernund jegliche relevantenDaten ein-schließen. Nachteilig ist der Verarbeitungs-aufwand des Tracing-Codes, allerdings ver-braucht das RTOS-Tracing auf einer moder-nen 32-Bit-MCU nur ein paar Prozent derProzessorzeit, da nur sehr wenige Datenaufgezeichnet werden müssen und die er-fassten Ereignisse nicht sehr häufig auftre-ten.Hierdurch ist ein kontinuierliches Strea-

Anzeige

document2607686280591741862.indd 23 20.11.2017 11:44:18

24



men der Daten über gängige Debug-Schnitt-stellen oder auch über Interfaces wie USBoder TCP/IP möglich. Die geringe Datenratelässt ebenfalls das Tracing in einen RAM-Puffer zu. Schon wenige Kilobyte reichenaus, um ein brauchbares Trace der jüngstenEreignisse zu bekommen. Somit ist ein Tra-cing auch außerhalb des Labors möglich –zum Beispiel im Zuge von Feldtests oder anschon im Einsatz befindlichen Systemen.Für das Begreifen der Traces ist die Visua-

lisierung entscheidend. Viele Embedded-Systeme legen ein mehr oder weniger zykli-sches Verhalten an den Tag, sodass es sichbeimGroßteil der Trace-Datenum irrelevan-te Wiederholungen der ‚normalen‘ Verhal-tensweisen handelt. Interessant sind dage-gen meist die Anomalien, die jedoch unterUmständen schwierig zu finden sind, wennman nicht genau weiß, wonachman eigent-lich sucht. Das menschliche Gehirn leistetallerdings Außerordentliches, wenn es umdas Erkennen visueller Muster und Anoma-lien geht. Voraussetzung hierfür ist jedochdie korrekte Visualisierung der Daten.Es gibt viele Tools, die ein RTOS-Trace als

klassischesGantt-Diagrammdarstellen. Die-se Visualisierung eignet sich aber nicht, umweitere Ereignisse (z. B. API-Aufrufe oderUser-Logging) in derselbenAnsicht anzuzei-

gen. Ein vertikales Execution Trace dagegenkannderartige Ereignissemit Beschriftungs-feldern anzeigen, die auf das grafische Exe-cution Trace verweisen. Die alleinige Anzei-ge eines Execution Trace ist außerdem einesehr eingeschränkte Perspektive, da aus ei-nem RTOS-Trace deutlich mehr Informatio-nen extrahiertwerdenkönnen. ZumBeispiellassen sich die Interaktionen von Tasks undISRs als Abhängigkeitsgraph visualisieren,und ebenso können Trace-Ansichten ange-zeigt werden, die sich auf weitere relevanteRTOS-Objekte wie Semaphoren, Warte-schlangen undMutexe konzentrieren.

Trace-Visualisierung mit demTracealyzerMit dem Tracealyzer können Sie die Ge-

schwindigkeit Ihrer Entwicklung deutlichsteigern: Sie erhaltenbessereMöglichkeitenfür dasDebugging, die Optimierung unddieVermeidungpotenzieller Probleme schon ineiner frühenPhase.DasVisualisierungs-Toolbietetmehr als 25 interaktive Ansichten, diezahlreiche Aspekte des Echtzeitverhaltensoffenbaren. Sie stützen sichdabei auf RTOS-Ereignisse, Speicherzuweisungs-Ereignisseund kundenspezifische User-Ereignisse imApplikations-Code. Die Spanne der Visuali-sierungen reicht vondetaillierten grafischen

Traces und Test-Logs bis zu individuellenDaten-Plots, Task-StatistikenundAbhängig-keitsgraphen. Sämtliche Ansichten sind zu-demmiteinander verknüpft, sodass Sie sichvonAnomalien indenabstraktenDarstellun-gen zu den einzelnen Ereignissen vorarbei-ten können. Auch ein Wechsel zwischenverschiedenen Perspektiven ist problemlosmöglich, ohne die Fokussierung auf das je-weilige Problem aufzugeben.Tracealyzer ist ein eigenständiges Tool, das

parallel zu einem vorhandenen Debuggerverwendet werden kann. KontinuierlichesStreaming ermöglicht eine Verfolgung IhresSystems über lange Zeitspannen, währenddas Tracing an einen RAM-Puffer das Sam-meln vonSpurenohneDebugger-Verbindungim Rahmen von Feldtests zulässt.DieHaupt-Traceansicht (MainTraceView)

visualisiert alle Daten entlang einer vertika-len Zeitachse und fokussiert sich auf dieAusführung von Tasks, sowie auf Interrupt-handler und Ereignisse wie etwa RTOS-API-Aufrufe. Jeder Task und jedem Interrupt-handlerwird abhängig vonder Priorität eineeigene Farbe zugewiesen, die übereinstim-mend in allen Ansichten benutzt wird. Miteinem Doppelklick auf eine Task, eine ISRoder ein Ereignis öffnet sich eineweitereAn-sicht, die relevante Ereignisse zeigt.‚User Events' ist ein explizites Logging, das

ähnlich wie der klassische ‚printf‘-Aufruf indenApplikations-Code eingefügtwird. Aller-dings geht dieVerarbeitungdeutlich schnel-ler und dauert auf den meisten 32-Bit-MCUsnur wenige Mikrosekunden. User Eventswerden in der Hauptansicht mit gelben Be-schriftungsfeldern angezeigt und lassen sichnutzen, um für das Debugging oder die Per-formance-Analyse weitere Details über denApplikations-Kontext beizusteuern.Tracealyzer wird für führende RTOS-Pro-

dukte und Linux-Systeme angeboten. Es un-terstützt diemeisten 32-Bit-Prozessoren (ein-schließlich ARM) und lässt sich einfach aufandere Architekturen portieren.Der Trend zum RTOS in der Embedded-

Branche ist unübersehbar. Das Multithrea-ding eines RTOS bietet aber einen höherenAbstraktionsgrad und weniger Kontrolleüber die Verarbeitung. Dies birgt erheblicheFallstricke, die nach besserer Debugging-Unterstützung auf der RTOS-Ebene verlan-gen. Vereinfachen lässt sich das DebuggingRTOS-basierter Systeme mithilfe bessererEinblicke in ihre Echtzeitverarbeitung.Hier-zu bedarf es des Tracings auf der RTOS-Ebe-ne, wobei die Visualisierung entscheidendfür das Begreifen der Daten ist. // SG

Percepio

Bild 3:Der CPU Load Graph gibt aufeiner horizontalen Zeitachsean, wie viel Prozessorzeitdie einzelnen Tasks undInterrupts verbrauchen. Diesbietet einen Überblick überden Trace und ermöglicht dieFokussierung auf die Haupt-Traceansicht durch eineneinfachen Doppelklick imDiagramm.

Bild:Percepio

Bild 4:Im User Event Log könnenEntwickler mitverfolgen, wasinnerhalb eines Mikrocont-rollers wärend der Testphasevorgeht.

Bild:Percepio

document2607686280591741862.indd 24 20.11.2017 11:44:20


AKTUELLE PRODUKTE // EMBEDDED SOFTWARE

PRQA ist nun AUTOSAR (AUTo-motive Open SystemARchitecture)-Entwicklungs-partner undTeil derArbeitsgrup-pe, die für die Entwicklung die-ser Richtlinien verantwortlich ist– vor allemaufgrundvonPRQAsKnow-how rund um die Pro-grammiersprache C++ und sei-ner Best-Practice-Softwareent-wicklung. In diesemZusammen-hang präsentiert das Unterneh-men das erste kommerziellerhältliche Tool zur automati-schen Anwendung der neuenAUTOSAR-C++14-Kodierungs-

KODIERUNGSSTANDARDS

Codeanalyzer für AUTOSAR-C++14

standard.DasAUTOSAR-Compli-ance-Modul ist eineErweiterungdes automatisierten statischenCodeanalysetools, QA·C++ 4.2.

QASystems

Der SGS TÜV Saar hat die ISO-26262-Konformität der Tool-Qua-lifizierungsberichte der folgen-denElemente derVeloce-Strato-EmulationsplattformvonMentorGraphics zertifiziert: das VeloceStratoOS für qualitativ hochwer-tige Verifikation von System-Le-vel-, RTL- und GL-Hardwarebe-schreibungen, die Veloce FaultApp zur Emulation umweltbe-dingter Fehler, um die Anfällig-keit von Designs hinsichtlicheines Ausfalls des Sicherheits-systems zu testen, die VeloceCoverage App zur Auswertung

VELOCE STRATO

Zertifiziert nach ISO 26262

von Statistiken während einesEmulationslaufs, sowie dieVelo-ce DFT App für beschleunigteDesign-for-Test-Verifikation.

Mentor Graphics

Cantatawurde inVersion 7.2 vonder unabhängigen Zertifizie-rungsstelle SGS-TÜV Saar als„Einsetzbar für die Entwicklungsicherheitsrelevanter Software“für die höchsten Sicherheitsle-

CANTATA 7.2

Zertifizierte Software-Sicherheitvels aller wichtigen sicherheits-relevantenStandards zertifiziert.Dazu zählen: IEC 61508: 2010(Industrie), ISO 26262: 2011 (Au-tomotive), EN 50128: 2011 (Bahn-technik), IEC 60880: 2006 (Ato-mindustrie) und IEC62304: 2006(Medizintechnik). Damit kanndie Software in allen relevantenMartkbereichen für die Entwick-lung von Anwendungen, diehöchsten Ansprüchen der funk-tionalen Sicherheit genügenmüssen, eingesetzt werden

QASystems

Thomas Schulz (Hrsg.)

Industrie 4.0Potenziale erkennenund umsetzen1. Auflage 2017, 378 SeitenISBN 978-3-8343-3394-059,80 EUR

Das Trendthema wird umfassendund in allen Facetten beleuchtetund analysiert. Dabei liegt dasHauptaugenmerk der Beiträgenicht nur auf dem möglichenPotenzial, sondern auch auf derkonkreten Umsetzung der Indus-trie 4.0-Anwendungen. Somitwird dem interessierten Leser einpraxisbezogener Leitfaden an dieHand gegeben, mit dessen Hilfeer das Konzept der industriellenDigitalisierung verstehen undumsetzen kann.

Weitere Informationenund versandkosten-freie Bestellung unter

www.vogel.de

Der Fitmacher fürdie digitale

Transformation!

Eine Empfehlung von

JETZTbestellen!

www.vbm-fachbuch.de

25

document6011671930251327775.indd 25 20.11.2017 11:08:31

http://www.vbm-fachbuch.de

http://www.vogel.de

26

SOFTWAREENTWICKLUNG // ENTWICKLUNGSMODELLE


5 Best Practices für ContinuousDelivery bei Embedded-Entwicklung

Versäumte Liefertermine oder mangelnde Qualität werden in derEmbedded-Branche immer seltener toleriert. Hilfe verspricht hier die

Entwicklungsmethode Continuous Delivery.

SVEN ERIK KNOP *

* Sven Erik Knop... ist Principal Solutions Engineer beiPerforce Software.

Ursprünglich ein Ansatz aus der klas-sischen Softwareentwicklung, kannContinuousDelivery auch inderWelt

der Embedded-Systeme die Entwicklungs-prozesse und Qualitätssicherung vereinfa-chen und beschleunigen. Mithilfe von Con-tinuousDelivery könnenUnternehmendafürsorgen, zu jedem gewünschten Zeitpunkteine auslieferbareVersion ihrer Software zurVerfügung zuhaben, die in genauderselbenArt undWeise installiertwird, in der sie auchgetestet wurde. Die Vorteile dieses Verfah-rens liegen auf der Hand: Die auslieferbareVersion lässt sich fehlerfrei installieren, so-dass sich neue Releases mit höherer Ge-

schwindigkeit bei gleichzeitig hoherQualitätausliefern lassen.Trotz aller Vorteile zögern viele Unterneh-

men nach wie vor, ihren gesamten Entwick-lungsprozess auf Continuous Delivery um-zustellen.Dabei ist eine erfolgreicheNutzungin der Praxis in vielen Fällen nur eine Frageder richtigen Voraussetzungen.

Mut zur Transparenz über diegesamte UmgebungZunächst gilt es, die Transparenz über die

gesamte Produktionsumgebung hinweg si-cherzustellen.Mithilfe eines zentralen Infor-mationsdepots erhalten Unternehmen einevollständigeÜbersicht zu allenÄnderungenüber die einzelnen Teams und Projekte hin-weg und können so die Auswirkungen eineszukünftigen Updates besser abschätzen so-wie potentielle Konflikte früh erkennen.AuchdasGemeinschaftsgefühl der Entwick-ler kannhiervonprofitieren: Für siewird das

große Ganze erkennbar und damit leichterersichtlich, wie alle Hand in Hand an derErreichungder gemeinsamenZiele arbeiten.Ebenso wird deutlicher, wie der eigene Bei-trag das Projekt insgesamt voranbringt.Am besten eignen sich dafür Monitoring-

undReporting-Funktionen etwa einerVersi-onsmanagementlösung, die für die Samm-lung und Analyse von Daten über verschie-dene Umgebungen und Infrastrukturenhinweg sorgen kann. Die damit erzielteTransparenz hilft somit, die Qualitätssiche-rung zu optimieren und zu beschleunigen.

Keine Lücken in der Beweis-ketteAus Gründen der Fehlerbeseitigung und

Compliancemüssen die Aktivitäten der ein-zelnen Entwickler mitprotokolliert werden.Treten unerwartete Fehler auf, muss sich zujedemZeitpunkt unmittelbar nachvollziehenlassen,wer eineÄnderungwann,woundvor

Nicht nur der Quellcode:Alle bestehenden Objekte eines Projekts müssen zuverlässigversioniert und verwaltet werden.

Bild:PerforceSo

ftware

document3142681111079019864.indd 26 20.11.2017 11:31:03

SOFTWAREENTWICKLUNG // ENTWICKLUNGSMODELLE

allemauchwarumdurchgeführt hat. Nur aufBasis dieser Informationen lässt sich imschlimmsten Fall ein notwendiges Rollbackauf eine frühere Version vornehmen.Die idealeVorgehensweise, umeine solche

„lückenlose Beweiskette“ zu erreichen, be-steht darin, einen einzigen, zentralen Refe-renzbestand aller Informationen zu pflegen– in vielen Fällen ebenfalls eine Funktioneiner Versionsmanagementplattform. Diesesorgt für die Protokollierung des gesamtenProduktlebenszyklus und macht damit zujeder Zeit transparent, welcher Anwenderwann welche Änderung eingecheckt hat –Informationen, die übrigens auch bei recht-lichenAuseinandersetzungenvonunschätz-baremWert sein können.

Manuelle ProzesseautomatisierenGerade manuell durchgeführte Builds,

Tests und Updates bergen ein erhöhtes Risi-ko, instabil zu sein, da sichbei jedemSchrittpotenziell neue Fehler einschleichen kön-nen. Daraus resultiert die Abneigung vielerEntwickler, neue Versionen aufzuspielen,um ein bestehendes System nicht zu desta-bilisieren. Ist aufgrund eines schwerwiegen-den Fehlers ein Update jedoch unvermeid-lich, kann die mangelnde Erfahrung undfehlende Infrastruktur für rasche UpdatesUnternehmen schnell in die fatale Situationbringen, in der weder ein Rollback auf eineältereVersionnochdasAufspielen einer neu-en Version möglich sind.Um dies zu vermeiden, sollten Unterneh-

men ihre Entwicklungsumgebungweitestge-hend automatisieren. Alle Commits solltenumgehend einen Build-Prozess sowie an-

schließend Tests auslösen, die prüfen, obdiese Fehler erzeugen. Eine solche sofortigeProblemlösung stellt nicht nur funktionie-rende Versionen sicher, sondern ist auchkostengünstiger als die Fehlerbehebung ineiner späterenPhasederQualitätskontrolle.

Nicht beim Quellcode bereitsaufhörenFür eine jederzeit releasefähige Software

genügt es heutzutage zudem längst nichtmehr, allein den Quellcode im Auge zu be-halten. Die meisten modernen Soft-wareprojekte beinhalten darüber hinausunterschiedlichste Arten von Assets wieChip-Architekturen, CAD-Designs, Konfigu-rationsskripte, Binärdateien oder Rich-Me-dia-Inhaltewie Sounds oderGrafiken, die fürdas finale Softwareprodukt unerlässlichsind.Werden solche zusätzlichenObjekte nicht

gemeinsam mit dem Rest der Anwendungverwaltet undversioniert, laufenEntwicklerGefahr, ein unfertiges oder unvollständigesProdukt zu veröffentlichen. Um dies zu ver-hindern, müssen Versionsmanagement-Tools in der Lage sein, mehr als nur reineQuellcode-Dateien indieVersionierungmit-einzubeziehen. Dann und nur dann habenEntwicklungsteamsbei Bedarf alle korrektenAssets unmittelbar zur Hand, um eine aktu-elle, lauffähige Version zu generieren – vomSoftwarecode über Grafikelemente bis hinzur Dokumentation.

Mit einem zentralen Referenz-bestand arbeitenAuchwennEntwicklungsprojekte zusam-

mengehörige Einheiten darstellen, sind die

einzelnen Entwicklungs-Assets nicht seltenüber unterschiedliche Speicherorte verteilt.Die Gefahr hierbei besteht darin, dass mög-licherweise entstandeneFehler erst zu einemspäten Zeitpunkt entdeckt werden und ge-plante Auslieferungstermine in der Folgenicht eingehalten werden können.Um dies zu vermeiden, sollten Unterneh-

men ihre gesamtenAssets in einemeinzigen,zentralen Repository pflegen. Dieses mussetwa inder Lage sein, Teamsunabhängig vonihrer Größe oder ihrem Standort einzubin-den, ohne dass Barrieren die Zusammenar-beit behindern. Zudemmuss die LösungmitunterschiedlichenDateiartenumgehenkön-nen, umdieArbeit unterschiedlichsterGrup-pen wie Softwaretechniker, Grafiker undAdministratoren gleichermaßen zu unter-stützen. Schließlich sind auchSicherheitsas-pekte zu bedenken. UmRisiken zuminimie-ren, ist etwa eine konfigurierbare Zugangs-kontrolle sinnvoll, die konsistent über diegesamte Umgebung angewendet wird.

Mit Continuous Delivery einegute Ausgangslage schaffenModerneEntwicklungsmethodenwieCon-

tinuousDelivery könnenUnternehmendabeiunterstützen, den gestiegenen Anforderun-gender heutigen Zeit gerecht zuwerden.DieGrundlage für eine effiziente Umsetzung inder Praxis könnenUnternehmen selbst legenund damit die optimalen Voraussetzungenschaffen, den Anforderungen ihrer Kundenauch künftig gerecht zu werden und weiter-hin im gestiegenen Wettbewerbsdruck derDigitalisierung zu bestehen.. // SG

Perforce Software

Wir sind bereit für Ihr nächstes Projekt!

www.lauterbach.com/hypervisor.html

TRACE32®

HypervisorDebugging

document3142681111079019864.indd 27 20.11.2017 11:31:04

http://www.lauterbach.com/hypervisor.html

28

SOFTWARE ENGINEERING // IMPLEMENTIERUNG


Nutzfahrzeuge und Elektromobilität– Alles gut geladen?

Elektrische PKWs, Busse oder LKWs haben gemeinsame Probleme:Reichweite, Ladegeschwindigkeit und Ladeinfrastruktur. WichtigeSchritte sind gemacht. Doch wie funktioniert das Laden im Detail?

B.ENG. JONAS LESERER *

* B.Eng. Jonas Leserer... ist Business Development Manager im BereichEmbedded Software and Systems bei Vector Infor-matik.

Die Deutsche Post möchte ihre Kurz-streckenflotte mittelfristig komplettauf elektrisch betriebene Fahrzeuge

umstellen und hat sich als Partner dieStreetscooter GmbH gesichert. Doch nichtnurKonzerne richten ihrenBlick auf die Elek-tromobilität, auch Kommunen stehen voreiner großen Herausforderung. In vielenStädten werden seit Jahren die Abgasgrenz-werte nicht eingehalten und daher Fahrver-bote diskutiert. Die Folgen vonFahrverbotenwärenweitreichend:Der öffentlicheNahver-kehr dürfte keine Personen mehr befördernund Geschäfte würden nicht mehr beliefert.Um die Umwelt zu schonen und mit gutemBeispiel voranzugehen, haben die Nieder-lande sich selbst auferlegt, ab 2020nurnoch

Elektrobusse für den Stadtverkehr zuzulas-sen. Die niederländische Stadt Eindhovenbetreibt aktuell circa 50 elektrische Gelenk-busse und möchte diese Flotte in Zukunftnoch weiter ausbauen. Kommunen inDeutschland ziehen nach: In Hamburg sindbereits Elektro-Gelenkbusse im Einsatz. Bis2020 sollen bis zu 60Weitere folgen. Und inder historischen Altstadt von Regensburgverkehren bereits kleine Stromer zur Perso-nenbeförderung.

Herausforderungen derElektromobilitätUmdiehoheNachfragenach elektrischen

Nutzfahrzeugen, wie etwa Bussen, befriedi-gen zukönnen, sindHersteller imZugzwang.Studien und Prototypen sind vorhanden,doch der Markt fordert Fahrzeuge für dentäglichen Einsatz. Diese müssen den Anfor-derungen an Reichweite, Fahrkomfort undBedienung gerecht werden und so zuverläs-

sig funktionieren wie Verkehrsmittel mitkonventionellem Antrieb. Genau darin be-steht die Herausforderung der Elektromobi-lität. Geht zumBeispiel bei einemDieselfahr-zeugderKraftstoff zurNeige, kannder Fahreran jeder Tankstelle schnell und unkompli-ziert nachtanken. Die Reichweiten von E-Fahrzeugen sind aktuell noch sehr begrenzt,die Ladeinfrastruktur ist noch dürftig. Dochwer stellt sicher, dass ein Fahrzeughalterauch an jeder Ladesäule aufladen kann?Darum kümmern sich Gremien, welche

das standardisierte Ladenunter Berücksich-tigungmarkttypischerGegebenheiten spezi-fizieren. Europa und Nordamerika folgendem Standard Combined Charging System,während China auf GB/T 27930 und Japanauf CHAdeMO setzen (Bild 1). Die größtenUnterschiede zwischen den Standards sinddie Kombination aus Stecker und Inlet, diezugrundeliegendephysikalischeVerbindungsowie das angewendete Protokoll für die La-

Bild 1:Weltweit kommen drei unter-schiedliche Standards für daselektrische Laden zum Einsatz(Quelle: CharIN e.V.).

Bild:The

WorldFactbo

ok,bearbeitetdurch

VectorInform

atikGm

bH

document597206988805424680.indd 28 20.11.2017 10:45:22



dekommunikation zwischen Fahrzeug undLadeinfrastruktur.WährendGB/T 27930undCHAdeMOauf demFahrzeugbus CANbasie-ren, setzt der CCS-2-Standard auf ein Ether-net-basiertes Protokoll namens PowerlineCommunication (PLC).

Verschiedene Stecker für AC-und DC-LadenEine weitere Herausforderung bei der

Standardisierung ist die Spezifikation einesgenormtenSteckers. ImGegensatz zummitt-lerweileweit verbreitetenAutomotive-Ether-net-Standard 100BASE-T1 kommt für diePowerline-Kommunikation keine verdrillteZweidrahtleitung zum Einsatz. Stattdessenverwendet das sogenannte Control Pilot (CP)Signal eine Eindrahtleitung.Die Stecker unddie Inlets für das AC- und DC-Laden enthal-ten immer drei identische Pins:� Control Pilot (CP): Pulsweitenmodulier-tes Signal mit aufmoduliertem höheremProtokoll� Protective Earth (PE): Schutzleiter sowieMasse des CP� Proximity Pin oder Plug Present (PP): Einanaloges Signal, welches das Vorhanden-sein eines Steckers im Inlet bestätigt sowiedie Stromtragfähigkeit des Kabels kodiert(relevant für AC-Laden)Dazu kommen Pins für Laden mit Wech-

selstrom (AC) und das schnellere Gleich-stromladen (DC). Der für Europa relevanteCCS-2-Stecker (Bild 2) enthält folgende Pins:� Für das Laden mittels Wechselstrom:Control Pilot, Protective Earth, ProximityPin, L1, L2, L3, GND� Für das Laden mittels Gleichstrom: Con-trol Pilot, Protective Earth, Proximity Pin,DC+, DC-Alternativ kann ein L-Leiter sowie dieMas-

se (GND) des AC-Steckers zum Gleichstrom-ladenmit geringer Leistunggenutztwerden.DieHigh-Level-Protokolle für dieKommu-

nikation sind beim AC- als auch beim DC-Laden identisch. Es ist somit möglich, einFahrzeug sowohlmitWechselstromals auch

mit Gleichstrom zu laden, solange der Stan-dard auch vom Fahrzeug unterstützt wird.Aufgrund der Geometrie des Steckers ist einfalsches Laden nicht möglich. Dies wird zu-dem auf Protokollebene verhindert.

Freigabe zum Laden: DasControl Pilot SignalDie eigentliche Freigabe zum Laden gibt

das CP-Signal (Bild 3). Als Trägersignal dientdas 1 kHz PWM-Signal. Im korrekten DutyCycle verweist es auf die High-Level-Ether-net-Kommunikation, welche als aufmodu-liertes Signal in der Bandbreite von 3 – 30MHz über die Powerline realisiert ist.Warum ist dieserAufwandnotwendig?Das

Fahrzeugmuss sich initial an der Ladesäuleidentifizieren, um Daten über Bezahlinfor-mation, Ladezustand, Art des Ladens unddie Stromabnahme auszutauschen. Sobalddie Authentifizierung erfolgreich abge-schlossen ist, bezieht das Fahrzeug (Master)von der Ladesäule (Slave) Strom.Der Tankstandard für Autos mit Verbren-

nungsmotor ist durch die Zapfhahndurch-messer gegeben. Für das Laden von Elektro-fahrzeugen muss der Fahrer aber noch die„richtige“ Ladesäule suchen.Umdie Intero-perabilität zwischen dem Fahrzeug und derInfrastruktur sicherzustellen, gibt es in Eu-ropa und Nord-Amerika die Standards ISO/

Bild 2: Aufbau des Ladesteckers für das Laden mitWechsel- beziehungsweise Gleichstrom.

Bild:VectorInformatikGm

bH

Bild 3: Low-Level-Kommunikation für das AC- und DC-Laden über den Control Pilot.


bH

www.elektronikpraxis.de/newsletter

MAGAZIN-NEWSLETTER

1082

0

JETZT

ANMELDEN

Aktuelle Ausgabendigital und

kostenlos lesen.

11113

Erweitern SieIhren Horizont

333Besuchen Sie uns im Internet unter:

www.vbm-fachbuch.de

mit den Fachmedienvon

Vogel Business Media

MIKROFLAMM - LÖTEN

Videoclips undBeispiele aufwww.spirig.tv

Kostenlose

Anwendungsversuche

xing.com/net/elektronikpraxis

youtube.com/elektronikpraxistv

twitter.com/redaktionEP

facebook.com/elektronikpraxis

gplus.to/elektronikpraxis

www.analog-praxis.de

0923

1

document597206988805424680.indd 29 20.11.2017 10:45:26

http://www.spirig.tv

http://www.vbm-fachbuch.de

http://www.elektronikpraxis.de/newsletter

http://www.analog-praxis.de

30



IEC 15118, DIN 70121und SAE J2847/2. Siespezifizieren die Ladekommunikation undsorgen für einen korrekten Datenaustauschvor dem eigentlichen Ladevorgang.

Kommunikation zwischenLadesäule und FahrzeugFür dieUmsetzungder indiesenStandards

definiertenKommunikationsprotokollewirdEmbeddedSoftware benötigt. Vector verfügtüber jahrelange Erfahrung bei der Realisie-rungder fahrzeuginternenNetzwerkkommu-nikationüber beispielsweise CAN, LIN, Flex-Ray und Ethernet. Daher wurde MICROSAR– die AUTOSAR-Basissoftware von Vector –umModule für dieKommunikation zwischenFahrzeug und Ladeinfrastruktur ergänzt.Diese V2G (Vehicle to Grid) genannte Erwei-terung (Bild 4) enthält unter anderem dieSoftwarekomponente vSCC: Vector SmartChargeCommunication.Darin ist der gesam-te Protokollablauf des Smart Charging reali-siert, wie in den oben genannten Standardsdefiniert. Ebenso ist die Ansteuerung derPowerline-Transceiver bereits enthalten. Füralle Fahrzeugherstellerwird dasAC- undDC-Laden mit verschiedenen Profilen unter-stützt,wie z.B. External IdentificationMeans(EIM), Plug`nCharge (PnC) undSignal LevelAttenuationCharacterization (SLAC). Daraufbasierend lassen sich spezifischeFunktionenwie Value Added Services (VAS) über HTTPundDNS realisieren, umeineparallel ablau-fende, proprietäreKommunikation zwischender Ladesäule und dem Fahrzeug herzustel-lenund so zusätzliche Informationenauszu-tauschen. Die Funktionen für diese Vehicle-to-Infrastructure-Kommunikation befindensich oberhalbdes Ethernet-Transport-Proto-kolls und können daher auch mit bestehen-den, OEM-spezifischen Softwarearchitektu-ren, kombiniert werden. So kann die Kom-ponente vSCC eingesetzt werden, ohne diekomplette Kommunikation unbedingt aufAUTOSAR umstellen zu müssen. Die Proto-kolle für das Smart Charging sind vollum-fänglich inderMICROSAR Implementierungenthalten. Sie werden über ein AUTOSAR-Werkzeug konfiguriert und mit weiteren er-forderlichen Komponenten verknüpft.Auf physikalischer Ebene sind für die Po-

werline-Kommunikation spezielle Transcei-ver notwendig. Diese übernehmen die Ver-arbeitung des High-Level-Signals, währendparallel ein digitaler Eingang für die Low-Level-Kommunikation andenMikrocontrol-ler angebunden ist. Hier gebendie Standardsgenaue Werte für die Flankensteilheit derSignale vor. Aufgrund der hochfrequentenÜbertragungsrate auf demControl Pilotmussbereits beim Design der Platine eines Lade-

steuergerätes großer Wert auf die EMV-Ab-strahlung gelegt werden.

Ladesteuergeräte fürNutzfahrzeugeErste Ladesteuergeräte für Nutzfahrzeuge

sind bereits am Markt verfügbar. DasVC36PLC-24 von Vector (Bild 5) realisiert diePowerline-Kommunikation vonFahrzeugenmit der Ladesäule. Es eignet sich vor allemfürKleinserien sowie prototypischeAufbau-ten und Entwicklungen. Das Steuergerätübernimmt verschiedene Funktionen wiebeispielsweise dieVerriegelungdes Steckersmit dem Inlet, die Temperaturüberwachungdes Steckers sowie die Visualisierung desLadezustandes mittels LEDs.

Die Hardware-Plattform des VC36PLC-24ist unabhängig vom Fahrzeughersteller ein-setzbar und eignet sich für kabelgebundenes(konduktives) Ladenper CCS-2 Standard.DasSteuergerät kann entweder mit einer demFahrzeughersteller entsprechenden Soft-ware-Architektur ausgeliefert werden, oderals generisches Steuergerät für Prototypenoder Entwicklungszwecke.Hierin ist sowohldie Low-Level- als auchdieHigh-Level-Kom-munikation realisiert. Somit lässt sich dasSteuergerät einfach in jedes Fahrzeug ver-bauen. Die CAN-basierte J1939-Schnittstellefür die Anbindung an das Netzwerk stehtNutzern uneingeschränkt zur Verfügung.

Laden über Pantographen – derbessere Stecker?Der aktuelle Standard ISO/IEC 15118 fokus-

siert hauptsächlich auf kabelgebundenesLadenper Ladesäule. Dabeimuss der Fahrerselbst handeln, umdieVerbindung zwischendem Fahrzeug und der Infrastruktur aufzu-bauen. Auch elektrisches Laden über einenPantographen, welcher sich auf dem Fahr-zeugbefindet, lässt sichhierüber realisieren.Dazu betätigt der Fahrer einen Schalter, umden Pantograph mit dem vorgesehenen La-demast zu verbinden. Jedoch braucht einsolcher Pantograph auf dem Bus Platz undmuss vomFahrzeugmitgeführtwerden,waszu höherem Gewicht und dadurch höheremVerbrauch führt. Abhilfe soll hier ein inver-tierter Pantograph leisten – ein System, beidem der Hauptanteil auf der festen Infra-struktur liegt unddas Fahrzeugnurmit Kon-takten ausgestattet ist. Genaudieser Fallwirdaktuell von der ISO/IEC 15118 im Teil 2, Edi-tion 2 spezifiziert und soll Mitte 2018 als In-ternational Standard verfügbar sein. In demFall erfolgt der Verbindungsaufbau voll au-tomatisiert über einedrahtloseKommunika-tion. Hierzu kommt das WiFi-Protokoll802.11n zum Einsatz.Für den Erfolg der Elektromobilität ist ne-

ben der Emissionsminimierung die Intero-perabilität aller Fahrzeuge mit den unter-schiedlichenAnbietern von Ladeinfrastruk-tur essentiell. Jedes Fahrzeug „tankt“ mitjeder verfügbarenLadesäule Strom–genau-so einfach, wie aktuell Kraftstoff an Tank-stellen getankt wird. Ziel sollte sein, dassStandards für das Laden denWandel unter-stützen und nicht ausbremsen. Die Stan-dards sindmittlerweile definiert undvondenHerstellern akzeptiert. Passende Lösungensind schon heute vorhanden. Die Industriekannbedenkenlos zugreifenunddie verfüg-baren Komponenten nutzen. // SG

Vector Informatik

Bild 5: Das Vector Steuergerät VC36PLC-24 bieteteine Schnittstelle für die standardisierte Kommuni-kation von elektrisch betriebenen Nutzfahrzeugenmit der Ladeinfrastruktur. Es unterstützt DIN SPEC70121 und ISO/IEC 15118.


bH

Bild 4:MICROSAR.V2G Embedded-Basissoftwarefür Smart Charging Communication nach DIN SPEC70121 und ISO/IEC 15118.


bH

document597206988805424680.indd 30 20.11.2017 10:45:29

www.linux4embedded.de

Wie entwickelt man eigentlich gute Software? Software, die tolleFeatures hat und keine Bugs? Treiber, die das Letzte aus der Hard-ware herauskitzeln? GUIs mit hoher Usability? Und wie könnenTools wie Git, Gerrit oder Jenkins Ihren Entwicklungsprozess per-fektionieren? Die prämierten Referenten der Embedded-Linux-Wo-che geben Antworten auf diese Fragen in den folgenden Seminaren:

5. – 9. Februar, 14. – 18. Mai und 8. – 12. Oktober 2018, Würzburg

12260

Kurse zu den Themen:

Grundlagen/ Einführung Embedded Linux

Systemprogrammierung Yocto Security

Gerätetreiber und Realtime

NEU 2018

Modular buchbare

Seminare

NeuesThema: Realtime

Eine Veranstaltung von

www.vogel-business-events.de

12260_ANZ_EP_Embedded_Linux_210x297.indd 1 16.11.2017 09:03:45

http://www.linux4embedded.de

http://www.vogel-business-events.de

32

KOLUMNE // PROJEKTMANAGEMENT


Was ist entscheidend beiEntscheidungen?

Peter Siwon, ELEKTRONIKPRAXIS-Kolumnist und Experte fürsystemisches Projektmanagement, über Macht und

Verantwortung bei der Arbeit in Projekten.

PETER SIWON *

* Peter Siwon... in seine Arbeit fließt die Erfahrungaus über 25 Jahren Berufspraxis inForschung, Entwicklung, Vertrieb,Coaching und Geschäftsführung.

Gerade die Projektarbeit stellt uns im-mer wieder vor schwierige Entschei-dungen, die oft auch noch schnell

getroffen werden müssen. Wer entscheidet,übernimmt Verantwortung und trägt damitauchdasRisikoder Fehlentscheidung.Damitnominieren sich Entscheider zur Wahl desSündenbocks.Wenwundert es da,wennEnt-scheidungen nicht gefällt werden, sondernwieheißeKartoffeln fallen gelassenwerden?Ein spannendes Thema, vielleicht zu ernstfür eine Kolumne. Egal, ich übernehme die

Verantwortung für meine Entscheidung,über Entscheidungen zu schreiben.Welche Eigenschaften zeichnen eine Ent-

scheidung aus? Wann sind überhaupt Ent-scheidungen notwendig? Denken wir überdiese Fragen anhand einer simplen Wegga-belung im Wald nach, die sich sehr gut alsMetapher für allemöglichenEntscheidungs-situationen nutzen lässt, auch in Projekten.Der Weg teilt sich z.B. in drei Richtungen:links, rechts oderMitte.Wennwirwissen,wowir hinwollenunddort einWegweiser steht,dann brauchen wir nicht zu entscheiden,vorausgesetztwir können lesen.DerWegwei-ser hat uns die Entscheidung freundlicher-weise abgenommen. Wenn der Wegweiserfehlt, dann machen wir plausible Annah-men, z.B. anhand der Himmelsrichtung in

derwir unser Ziel vermuten. Dann entschei-den wir uns für den Weg, der in diese Rich-tung deutet. Doch die erfahrenen Waldspa-ziergänger unter uns wissen, dass dieseplausible Annahme keine Erfolgsgarantieliefert. So manche dieser Da-geht´s-lang-Phantasien führt zu ungewollten und er-staunlich Geländeerkundungen. Ich willnicht abstreiten, dass wir dabei neue undinteressante Entdeckungenmachen, die denMakel der Fehlentscheidung verschleiern.

Entscheidungen ersetzen Unsi-cherheit durch RisikoDer entscheidende Unterschied zwischen

Entscheiden und Wegweiser-folgen ist dasMaßanUnsicherheit. BeimWegweiser ist siepraktischnull,wennnicht irgendein Scherz-keks sichdaran zu schaffen gemacht hat. Beider EntscheidungkanndieUnsicherheit sehrhoch sein. Sie sehen: Unsicherheit ist einenotwendigeVoraussetzung für eineEntschei-dung. Das Risiko einer Fehlentscheidung istin jedeEntscheidungquasi automatisch ein-gebaut.Wir können nicht entscheiden ohneein Risiko einzugehen, denn gäbe es keinRisiko,wäre keineEntscheidungnotwendig.Dieser Zusammenhang wird, so logisch erist, gerneübersehen.Der großeVorteil einerEntscheidung trotz des damit verbundenenRisikos ist, dass nun endlich gehandelt wer-den kann. Beispielsweise entscheiden wiruns rechts abzubiegen, statt ratlos an derWeggabelung zu verhungern (ok, ich gebezu, dass ich hier etwas dramatisiere). Wennwir irgendwann feststellen, dass derWeg insNirgendwo führt, kehrenwir umund treffeneineneueEntscheidungauf Basis der neuenErfahrung. Wer jetzt wieder rechts geht, istnatürlich extrem doof, aber die dümmsteallerVariantenwäre, ausAngst vorweiterenFehlern keine Entscheidungmehr zu treffenund letztlich doch an der Stelle zu verhun-gern.Wir haben immerhinnoch 3Varianten,die eine sinnvolleAlternative zumHungertoddarstellen: Mitte, links oder umkehren.Peter Siwon: Entscheidungen verwandeln Unsicherheit und Stillstand in Risiko und Handlungsfähigkeit

Bild:fotoartElisabethWiesner

document5652285313758504927.indd 32 20.11.2017 14:41:10


Kurz zusammengefasst: Ohne Entschei-dungen kein Handeln, ohne Handeln keineneuenErkenntnisse, ohneneueErkenntnis-se keine neuen Entscheidungsgrundlagen.Der Preis für diesen Nutzen einer Entschei-dung ist das Risiko der Fehlentscheidung.Personen, die eine Entscheidung herbei-

führen können, sind demnach so etwas wieVerwandlungskünstler. Sie transformierenUnsicherheit in Handlungsfähigkeit, dadurch die Entscheidung klarer wird, was zutun ist. Gleichzeitig wird aus der Unsicher-heit ein Risiko, denn die Entscheidung unddie daraus erfolgten Handlungen könnenspäter als Fehler interpretiert werden.Ich sagehier ganzbewusst „interpretiert“,

weil derVorwurf der Fehlentscheidungnach-träglich aufgrund von Informationen konst-ruiert wurde, die weder dem Entscheidernoch dem Ankläger zum Zeitpunkt der Ent-scheidungbekanntwaren.Nachher glaubenviele (vor allem die, die sich gerne vor Ent-scheidungen drücken), dass sie in der Ent-scheidungssituation schlauer gewesen wä-ren. Nachsatz: Aber sie können es nicht be-weisen! 2. Nachsatz:Warumhaben sie nichtalles getan, um eine Fehlentscheidung zuverhindern?

Jeder trägt auf seine WeiseVerantwortungWer hat nun die Verantwortung für eine

Entscheidung, welcher Weg einzuschlagenist? Wenn es einen „Leithammel“ gibt, derautoritär sagt wo es langgeht, ist die Verant-wortung für Entscheidungenklar. Er bezahltseine Entscheidungsmacht mit uneinge-schränkter Verantwortlichkeit für dasSchicksal derGruppe.DieGruppe trägt aller-dings die Verantwortungdafür, dass sie die-ser Führungspersonwie eineHerde Lämmerfolgt. Das ist ja auch eine Entscheidung.Die andereMöglichkeit besteht darin, dass

sich eine Person mit der Gruppe berät, umdann die Entscheidung zu treffen. Die Ver-antwortung für die Entscheidung liegt nunbei ihr, die Verantwortung für die Entschei-dungsgrundlage bei der ganzen Gruppe.Moderiert eine Person den Entscheidungs-prozess, bis ein Konsens in der Gruppe ge-funden ist, so übernimmt sie die Prozessver-antwortung. Die Verantwortung für das Er-gebnis liegt in diesem Fall bei der gesamtenGruppe.Wie immer es auch laufenmag, dieVerant-

wortung, obundwie Entscheidungen fallen,liegt immer bei der gesamtenGruppe, solan-ge eine realistische Wahlfreiheit für die Zu-gehörigkeit zu dieser Gruppe besteht. Dieeinen tragendieVerantwortung für ihre Ent-scheidungen, die anderen die Verantwor-

tung für ihr Nicht-entscheiden-müssen,Nicht-entscheiden-wollen oder Nicht-ent-scheiden-können. Alle Verantwortung los-zuwerden ist also bei genauer Betrachtungin der Praxis sehr schwierig.

Die Fähigkeit, Sicherheit oderUnsicherheit zu erzeugenWas bedeutet in diesem Zusammenhang

Macht? Die Macht einer Person über anderewächst in demMaße, wie sie für diese Men-schenUnsicherheit in Sicherheit verwandelnkann. Leider gilt auch das Umgekehrte. IhreFirmahat dieMacht, Ihre finanzielle Sicher-heit zu verbessern, aber auch die Macht,Ihnen diese Sicherheit unter bestimmtenBedingungen wieder zu entziehen.Auf unsere Wanderer bezogen bedeutet

das, dass die Person mit der besten Orts-kenntnis große Macht besitzt. Sie kann dieSicherheit vonEntscheidungen erhöhenoderdurchdieDrohung, dieGruppe zu verlassen,hohe Unsicherheit erzeugen.Oft wird Macht zu sehr mit Hierarchie in

Verbindung gebracht. Die disziplinarischeMacht in Unternehmen ist aber nur eine un-ter vielen.Wennwir Macht als das Potentialsehen, durch Herbeiführen einer Entschei-dung Unsicherheit in Sicherheit zu verwan-deln, eröffnen sich viele Möglichkeiten derkonstruktiven Machtausübung oder Ein-flussnahme: Transparenz, Klarheit undVer-ständnis schaffen, Entscheidungen treffen,Konflikte lösen, etc. Unglücklicherweisekommtauchdie destruktiveVariante, Sicher-heit in Unsicherheit zu verwandeln, zumEinsatz: Intransparenz, Blockade, Intrigen,etc. Mit wemwürden Sie gerneWandern ge-hen?Wemwürden Sie Ihr Vertrauen und Ihrvolles Engagement schenken?Ichhoffe, ichhabe Ihnen jetzt durchmeine

Überlegungen nicht die Lust am Wandernverdorben.Mein Tipp:NehmenSie sich eineeigene Karte und Ihren Kompass mit. DannkönnenSie jederzeit selbst entscheiden,wieviel Macht Sie anderen über Ihr Schicksalüberlassen wollen.Ich überlasse es nun Ihrer Entscheidung

undVerantwortung, diese Zusammenhängeauf Projekte, Arbeitsteams und Unterneh-men zu übertragen. Natürlich tragen Sie da-für das volle Risiko. Ich bin ja nur ein einfa-cher Kolumnenschreiber.Falls Sie sich für das Thema Entscheidun-

genundandere interessante Zusammenhän-ge in Projekten interessieren, besuchen Siedoch mein Seminar auf dem ESE Kongress2017 (https://www.ese-kongress.de/paper/presentation/id/141 ). // DF

www.systemisches-projektmanagement.info

KOLUMNE // PROJEKTMANAGEMENT

33www.vogel.de

--> facebook.com/elektronikpraxis

document5652285313758504927.indd 33 20.11.2017 14:41:12

https://www.ese-kongress.de/paper/presentation/id/141

https://www.ese-kongress.de/paper/presentation/id/141

http://www.systemisches-projektmanagement.info

http://www.vogel.de


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: David Franz, Ressorts: Beruf, Karriere, Management, Tel. -30 97Koordination redaktionelle Prozesse: Christina RüttingerRedaktion München: Tel. (09 31) 4 18-Sebastian Gerstl (sg), ASIC, Entwicklungs-Tools, Prozessor- und Softwarearchitekturen,Programmierbare Logik, SOC, Tel. -30 98;Michael Eckstein (me), Mikrocontroller, Prozessoren, IoT, 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;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;Margit Kuther (mk), Bauteilebeschaffung, Distribution, Embedded Computing, Tel. -30 99;Kristin Rinortner (kr), Analogtechnik, Mixed-Signal-ICs, Elektromechanik, Relais, Tel. -30 86;Freie Mitarbeiter: Prof. Dr. Christian Siemers, FH Nordhausen und TU Clausthal; Peter Siwon,MicroConsult; Sanjay Sauldie, EIMIA; Hubertus Andreae, dreiplusVerantwortlich für die FED-News: Dietmar Baar, FED e.V., Frankfurter Allee 73c, D-10247 Berlin,Tel. (0 30) 3 40 60 30 50, Fax (0 30) 3 40 60 30 61, www.fed.deRedaktionsassistenz: Eilyn Dommel, Tel. -30 87Redaktionsanschrift:München: Rablstr. 26, 81669 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: Vogel Design Werkstatt, Ltg. Annette Sahlmüller, Tel. (09 31) 418-2160

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

MEDIENGRUPPEVogel 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 Holding GmbH & Co. KG, Max-Planck-Straße 7/9, 97082WürzburgGeschäftsführung:Matthias Bauer, 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, Rablstr. 26, 81669 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: Annika Schlosser, Tel. (09 31) 4 18-30 90, Fax (09 31) 4 18-30 93,[email protected]: Andrea Menzel, Tel. (09 31) 4 18-30 94, Fax (09 31) 4 18-30 93,[email protected] Wittrock, Tel. (09 31) 4 18-31 00, 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. 51 vom 01.01.2017.Vertrieb, Leser- und Abonnenten-Service: DataM-Services GmbH,Franz-Horn-Straße 2, 97082 Würzburg, Marcus Zepmeisel , Tel. (09 31) 4170-462, Fax -4 94,[email protected], www.datam-services.de.Erscheinungsweise: 24 Hefte im Jahr (plus Sonderhefte).

EDA

Verbreitete Auflage: 38.258 Exemplare (II/2017).Angeschlossen der Informationsgemeinschaft zur Feststellung der Verbreitung von Wer-beträgern – Sicherung der Auflagenwahrheit.Bezugspreis: Einzelheft 12,00 EUR. Abonnement Inland: jährlich 240,00 EUR inkl. MwSt.

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

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

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

Impressum

www.vogel.de

11788

11788

#C/C++

#Multicore

#Safety/Security

#Open Source

#Test & Qualität

#Forschung

#Software Engineering

JETZTreinklicken!

11788

Embedded Software Engineering Online ist die ein-zige deutschsprachige digitale Fachinformation, diesich ausschließlich und tiefgehend den Themenund Herausforderungen bei der Entwicklung vonEmbedded Software widmet.

www.embedded-software-engineering.de

Die neue Plattform fürEmbedded Software Professionals

document7695932569178651863.indd 34 20.11.2017 14:31:16

http://www.fed.de







http://www.datam-services.de

http://www.elektronikpraxis.de

http://www.vogel.de

http://www.genios.de




http://www.vogel-europublishing.com

http://www.mycontentfactory.de

http://www.vogel.de

http://www.embedded-software-engineering.de

Begeben Sie sich auf Zeitreise!Im Jahr 2016 feierte ELEKTRONIKPRAXIS 50. Geburtstag. Aus diesem Anlass berichten wirbis Ende 2018 und online auf der Meilensteine-Webseite über führende Unternehmen derElektronikbranche. Was waren ihre wichtigsten Leistungen, wo stehen die Firmen heute undwie sehen die Pioniere der Elektronik die Zukunft?

Entdecken Sie die ganze Geschichte unter www.meilensteine-der-elektronik.de

DC/DC-Wandler SecurityTakterzeugung

Schalter Design-in SupportArbeitsplatzsysteme

Eine Serie von

Leiterplatten

1207

9

12079_ANZ_EP_Meilensteine_der_Elektronik_2018_a4_3.indd 1 10.10.2017 09:14:15

http://www.meilensteine-der-elektronik.de

Seit 35 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 9696 5401 oder besuchen Sie uns auf www.ghs.com/s4e

Copyright © 2017 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

http://www.ghs.com/s4e

Date post:	18-Oct-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Embedded Software Engineering - Vogel · 6 OPENSOURCESOFTWARE//RECHT ELEKTRONIKPRAXIS...

Documents