Embedded Software Engineering - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2017/...Portalembedded-software-enginee-ring.debietetEntwicklernaktuelle EinblickeindieSoftwarewelt

Wissen.Impulse.Kontakte. Februar 2017

Warum Maschinen nichtverantwortlich handelnAutonomes Fahren, Roboter in der Fabrik, Algorithmen in der Medizin:Philosophieprofessor Julian Nida-Rümelin über das Verhältnis von Technik und Ethik

Warum sich Jail-house für Echtzeit-Aufgaben eignetSystemkonsolidierung mitdem Open-Source-Hyper-visor Seite 14

TechnischeDokumentation imScrum-TeamWie die Technische Redak-tion in die agile Entwicklungintegriert wird Seite 18

Ein Modell für einfunktionalesSicherheitskonzeptNicht-zertifizierte SoCs imsicherheitskritischenUmfeld einsetzen Seite 24

EMBEDDED SOFTWARE ENGINEERING

www.elektronikpraxis.de

Sponsored by

document2194285486655832528.indd 1 10.02.2017 12:51:45

http://www.elektronikpraxis.de

170206_FUEL_EP_DE.indd 1 2/2/17 2:13 PM

3

EDITORIAL

ELEKTRONIKPRAXIS Embedded Software Engineering Februar 2017

Das Internet of Things hat mehrals nur ein Image-Problem

Das Internet of Thingswird sterben“lautet der Titel des Beitrags, mitdemder „Wired“-AutorKlint Finley

dem IoT das Totenglöcklein läutet. FürdieseVorhersage führt derAutor eineRei-he von Gründen an: Etwa die massiveDDoS-Attacke, bei der im vergangenenHerbst ein gigantisches Botnetz aus ver-netztenGeräten namhafte Internetporta-le mit Traffic überflutete. Dazu kommenabsurde Produktideen wie die „Selfie-Bottle“, entwickelt vonCoca-Cola in Isra-el: Ein Mini-Fotoapparat wird ans untereEnde einer Coca-Cola-Flasche eingeklinktund schießt bei einem bestimmten Nei-gungswinkel der Flasche ein Bild. Dieseswird dann sofort auf Internetportale wieSnapchat oder Instagram hochgeladen.Dazu kommt, dass bestimmte Ge-

schäftsmodelle, die mit dem Internet derDinge verknüpft sind, bei denbetroffenenKunden nicht unbedingt auf Gegenliebestoßen. Viele dieser Geschäftsmodellegründenauf der Bereitstellung vonServi-ces, so etwavonDiagnose- undWartungs-diensten.Was aber,wenndieKundendiesgar nichtwollen,weil sie es gewohnt sind,selbst Hand anzulegen? US-Landwirtekämpfen inzwischen für ihr Recht, ihreTraktoren selbst reparieren zu dürfen.

„Das Internet der Dingewird nicht sterben – eswird aber zu schmerzhaf-ten Häutungen kommen.“

Franz Graser, [email protected]

Nicht zuletzt zeichnet sich ab, dass dieFormel „Internet of Things“ eine immerdünnere Klammer darstellt, die viele un-terschiedliche Anwendungsgebiete um-fasst, darunter das vernetzte Auto, dasindustrielle Internet, Smart Home oderSmartHealthcare, die in denkommendenJahren an Eigenständigkeit gewinnenwerden. Das könnte bedeuten, dass diemomentan umfassende Klammer IoT anBindekraft verliert unddie einzelnenAn-wendungsfelder anBedeutunggewinnen.Dennoch: Das IoT wird im Gegensatz

zur eingangs genanntenSchlagzeile nichtsterben. Wie bei den meisten Technolo-giewellen folgt auf den Hype ein Tal derErnüchterung. Der Begriff „IoT“ alleinwird bald schonnichtmehr alsMarketing-Argument taugen.DerNutzendermit denIoT realisierten Anwendungen wird ent-scheiden, was sich amMarkt behauptet.

Herzlichst, Ihr

Wir helfen, innovativeund energieeffizienteARM-basierte Systeme

zu entwickeln.

Halle 3 / Stand 342developer.arm.com

document7296046376296655501.indd 3 13.02.2017 09:08:42

mailto:[email protected]

4 ELEKTRONIKPRAXIS Embedded Software Engineering Februar 2017

SCHWERPUNKTEESE KongressTITELTHEMA

9 Warum Maschinen keine Verantwortung übernehmenWie hängen Technik und Ethik zusammen? Der PhilosophJulian Nida-Rümelin skizzierte auf dem ESE Kongress einKoordinatensystem, das eine Grenze zwischen humanerund Maschinenintelligenz zieht.

Test und Betrieb12 Gerätehersteller werden zu Softwareanbietern

Im Zeitalter des Internet der Dinge ist die Software derentscheidende Wachstumstreiber. Geräte- und Systemher-steller müssen deshalb zu Softwareanbietern werden, wennsie nicht an Marktbedeutung verlieren wollen.

Systemvirtualisierung14 Jailhouse – ein Hypervisor für Embedded

Auch im Embedded-Umfeld lassen sich viele Vorteile derHypervisor-Technik anwenden. Die Open-Source-LösungJailhouse hat hierfür zahlreiche Trümpfe im Ärmel fürMulti-Core, Embedded und Echtzeit.

Entwicklungsprozess18 Technische Dokumentation im Scrum-Team

Auch die Technische Dokumentation lässt sich in die agileSoftwareentwicklung mit Scrum einbeziehen. Der Beitragerläutert, was dabei unbedingt bedacht werden sollte undwie die Zusammenarbeit im Team aussehen kann.

Softwareplattformen22 Im sicherheitskritischen Umfeld zuhause

Der Mainzer Echtzeitsoftware-Spezialist SYSGO blickt mitt-lerweile auf 25 Jahre Unternehmensgeschichte zurück undhat als Hersteller von Betriebssystemen für sicherheitsre-levante Anwendungen eine europäische Erfolgsgeschichtegeschrieben.

Systemdesign24 Ein Ansatz für ein funktionales Sicherheitskonzept

Kann ein nicht-zertifizierter SoC in einer Sicherheitsanwen-dung zum Einsatz kommen? Der Beitrag deckt wichtigeArchitektur- und Design-Abwägungen moderner Sicher-heitseinrichtungen ab.

RUBRIKEN3 Editorial

6 Aktuelles

21 Impressum

INHALT

TECHNIK & ETHIK

Warum Maschinen keineVerantwortungübernehmen könnenEin Höhepunkt des ESE Kongresses 2016 war dieKeynote von Professor Julian Nida-Rümelin, der sichmit dem Thema „Technik und Ethik“ befasste. Auchsonst war der Kongress wieder ein Rekord-Event.Mit 1132 Teilnehmern wurde die Bestmarke aus demVorjahr (1120 Personen) noch einmal übertroffen.Zum Gelingen der Konferenz trugendie hochwerti-gen Vorträge, das gut eingespielte Konferenzteamund die gute Stimmung bei.

9Titelbild: © the_lightwriter/Fotolia.com [M]

document3080206597745241063.indd 4 13.02.2017 13:10:31

170206_Logo17_EP_DE.indd 1 2/2/17 2:23 PM

6

EMBEDDED SOFTWARE ENGINEERING // AKTUELLES


MIKROFLAMM - LÖTEN

Videoclips undBeispiele aufwww.spirig.tv

Kostenlose

Anwendungsversuche

Zum ESE Kongress gestartet: DasPortal embedded-software-enginee-ring.de bietet Entwicklern aktuelleEinblicke in die Softwarewelt.

ENTWICKLERPORTAL

embedded-software-engineering.de öffnet ihre PfortenDie ELEKTRONIKPRAXIS-Medi-enfamilie hat Zuwachs bekom-men: Seit wenigen Wochen istdas Internetportal embeddedsoftware engineering (Webadres-se: www.embedded-software-engineering.de) online, das de-zidiert den Informationsbedarfder Softwareentwickler im Em-bedded-Umfeld befriedigenmöchte.Aktuelle und nutzwertige

Fachartikel, Anwenderberichtesowie spannende InterviewsmitBranchengrößen und -kennernbilden das Herzstück des Infor-

Bild:ELEKTRR

ONIKPRA

XIS mationsangebots. Das Portal

bietet darüber hinaus WebinareundLive-Mitschnitte vonVorträ-gen, etwa vomalljährlichenESEKongress in Sindelfingen.Angelehnt an den Software-

Lebenszyklus ist die Website indie Hauptrubriken „Planung &Analyse“, „Entwurf“, „Software-Implementierung“, „Test&Qua-lität“, „Betrieb & Wartung“,„Software EngineeringManage-ment“ sowie „Forschung“unter-teilt. Darüber hinaus spielenwichtigeAnwendungsfelderwiefunktionale Sicherheit und Da-

tensicherheit, Echtzeit, Zertifi-zierung sicherheitskritischerSoftware sowie Internet ofThings und Industrie 4.0 einezentrale inhaltliche Rolle.Die Webseite ergänzt damit

das bestehende Informationsan-gebot der ELEKTRONIKPRAXISund der ESE-Sonderhefte sowiederDiskussionsgruppe „Embed-dedSoftware“ aufXing.Wir freu-enuns auf IhrenBesuchauf demneuen Embedded-Software-En-gineering-Portal! // FG

embedded-software-engineering.de

Galileo-Navigationssatelliten in23.222 Kilometern Höhe: Das Be-triebssystem RTEMS bildet die Basisder Systemsoftware.

BETRIEBSSYSTEME

Symmetrisches Multiprocessing für Echtzeitbetriebssystem RTEMSMulticore-Prozessoren sind dieAntwort auf den steigenden Be-darf an Rechenleistung beigleichbleibenden Taktraten. Ei-ne optimaleNutzungder verfüg-barenRechenleistungbei gleich-zeitig garantierter Reaktionszeit,wie sie imEmbedded-Bereich oftvon Bedeutung ist, erfordert je-doch eine ausgeklügelte Zutei-lung der Prozesse. Mit der kürz-lich vorgestellten SMP-Erweite-rung (Symmetric Multiproces-sing) des EchtzeitbetriebssystemRTEMSwurdederGrundstein fürdie Bearbeitung leistungsinten-

Bild:ESA

-OHBsiver Rechenaufgaben inEchtzeit

gelegt. Egal, ob auf einem klei-nen Mehrkernprozessor oder ei-nem Multicore-Giganten, sorgtdas SMP für die bestmöglichePerformance. Hierzu wurde dasBetriebssystem im Inneren fastkomplett neu aufgesetzt, bleibtaber weitgehend struktur- undbefehlskompatibel zudenbishe-rigen Versionen.Der Betriebsystemkern von

RTEMSbietet Clustered-Schedu-ling, moderene Locking-Proto-kolle sowie skalierbare Timer,Timeouts und Timestamps. Es

bietet einen SMP-fähigen IPv4/IPv6/IPsecNetzwerkstack,USB-Stack und SD/MMC-Card-Stacksowie eine Vielzahl von Schnitt-stellen, wie C11, C++11, Ada,Google Go, POSIX Threads,OpenMP und EMB².RTEMS ist ein Open-Source-

Betriebssystem, die SMP-Ent-wicklung erfolgte durch embed-ded brains in Puchheim im Auf-trag der europäischen Raum-fahrtagentur ESA (EuropeanSpace Agency). // FG

embedded brains

CODE-OPTIMIERUNG

Interaktive Anwendungs-ParallelisierungUm das Leistungspotenzial voneingebetteten Mehrkernprozes-soren ausnutzen zu können,müssen Anwendungen sinnvollparallelisiert werden. Der Tool-Hersteller emmtrix Technologies

Für die Parallelisierung wirdder Eingangscode bei Bedarf insequentiellen C-Code übersetztund in eine hierarchische Pro-grammdarstellung gebracht.Diese stellt auf der X-Achse dieZeit und auf der Y-Achse die Ver-schachtelungstiefe dar, diedurch Kontrollstrukturen wieSchleifen oder Funktionsaufrufeentsteht. Neben einer statischenAbschätzungwirddie Ermittlungder Ausführungszeiten in Simu-latoren oder bei der Ausführungauf dem Zielsystem unterstützt.Ein automatischer Algorithmus

erledigt die Zuweisung auf dieProzessoren sowie eine sinnvolleUmsortierungdesProgrammab-laufs. Diese Verteilungwird gra-fisch veranschaulicht und kanndurch die tatsächliche Ausfüh-rung evaluiert werden. Dieschnelle Rückmeldung ermög-licht demAnwender eine iterati-veVerbesserungder Performanz.So können Blöcke oder Pro-grammteile mit einem Klick aufeinen anderen Prozessor ver-schoben werden. // FG

emmtrix Technologies

aus Karlsruhe stellt mit dememmtrix Parallel Studio einWerkzeug bereit, das den Paral-lelisierungsprozess deutlich ver-einfacht undbeschleunigt. Dazusetzt es auf die beiden SäulenAbstraktion und Automatisie-rung: Die Abstraktion beginntbei der Wahl der Eingangsspra-chen. Bevorzugt werden die Ar-ray-basierten Sprachen Matlabund Scilab verwendet, umAlgo-rithmen auf mathematischerEbene ohne Betrachtung derspäteren Zielarchitektur zu be-schreiben.

Anzeige

document5450735035171768545.indd 6 13.02.2017 13:04:58

http://www.spirig.tv

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



www.vogel.de

www.embedded-software-engineering.de

#C/C++

#Multicore

#Safety/Security

#Open Source

#Test &Qualität

#Forschung

#SoftwareEngineering

11788

Embedded Software Engineering Online ist die einzige deutsch-

sprachige digitale Fachinformation, die sich ausschließlich und tief-

gehend den Themen und Herausforderungen bei der Entwicklung

von Embedded Software widmet. Software-Professionals finden hier

fundiertes Fach- und Expertenwissen für ihre tägliche Berufspraxis,

von Anforderungsmanagement bis Test, von Technologie-Trends bis

Software Engineering Management.

Jetzt reinklicken!

11788_ANZ_EP_Embedded-Software-Engineering-Website_A4.indd 211788_ANZ_EP_Embedded-Software-Engineering-Website_A4.indd 2 13.02.2017 13:40:5713.02.2017 13:40:57


http://www.vogel.de


TITELSTORY // ESE KONGRESS – TECHNIK UND ETHIK

8

TITELSTORYFür die Organisatoren des ESE Kon-gresses war 2016 wieder ein Rekord-jahr. Mit 1132 Teilnehmern wurde dieBestmarke aus dem Vorjahr (1120 Per-sonen) noch einmal übertroffen. Ein-mal mehr zeigte sich die Bedeutungdes Kongresses als Branchentreff fürdie deutschsprachige Embedded-Community. Zum Gelingen der Konfe-renz trugen wie immer die hochwer-tigen Vorträge, das gut eingespielteKonferenzteam, die Party-Abendeunddie gute Stimmung bei, die auch denRekord-Kongress zu einem familiärenEreignis werden ließ. Ein Höhepunktwar die Keynote von Professor JulianNida-Rümelin, der sich mit dem The-ma „Technik und Ethik“ befasste.


Bild:©

the_lightwriter/Fotolia.com

[M]

document4822085534826575554.indd 8 13.02.2017 11:14:48

9


WarumMaschinen keine Verant-wortung übernehmen können

Wie hängen Technik und Ethik zusammen? Der Philosoph Julian Nida-Rümelin skizzierte auf dem ESE Kongress ein Koordinatensystem, das

eine Grenze zwischen humaner und Maschinenintelligenz zieht.

Unter demMotto „Philosophietrifft Elektronik“ setzte dieKeynote von Professor Ju-

lian Nida-Rümelin die ReiheinterdisziplinärerVorträgebeimESE Kongress fort, die 2015 mitdem Beitrag der Juristin ElkeLuiseBarnstedt vomKarlsruherInstitut für Technologie ihrenAnfang nahm.Für ProfessorNida-Rümelin, der

an der Münchner Ludwig-Maximi-lians-Universität lehrt, sind techni-sche Entwicklungen und die Kulturmiteinander verwoben. Als Beispielnennt er den griechischen Ma-thematiker und IngenieurArchimedes (um 287

- 212 vor Christus), der unter anderem imBe-reichderHydraulik (sogenannteArchimedi-sche Schraube) und bei den HebelgesetzenErstaunliches leistete.Archimedes, so Nida-Rümelin, entwarf

sogar Automaten, die in der Lagewaren, beieinemBankettWeinnachzuschenken. Es istleicht auszumalen, dass manche techni-schenEntdeckungenweitaus früher gemachtworden wären, hätten sich die Erfindungendes Archimedes durchgesetzt. Warum aberentfalteten diese Entwicklungen so wenigWirkung? „Diese technische Extrembega-bung fand in einer Kultur statt, die dafürwenig übrig hatte“, erklärt der MünchnerPhilosoph.

Wie hängen nun aber Technik undmenschliche Verantwortung zusam-men? Nida-Rümelin verwies hier aufdendeutsch-amerikanischenPhilo-sophen Hans Jonas (1903 - 1993),der in seinem Hauptwerk „DasPrinzipVerantwortung“ einepes-simistisch gestimmte Technik-Philosophie entwarf. Jonas ge-brauchte hierfür die Formel„Handle so, dass durch deineHandlungen menschlichesLeben auf diesem Planetennicht gefährdet wird.“

Jonas' Gedanke hat un-ter anderem in die Be-wertung der Gentech-nik Eingang gefun-den. Aber auch imHinblick auf moder-ne Trends wie denTranshumanismus(der diemenschlicheExistenz unter ande-remdurch technischeImplantate zu verbes-sern sucht) ist er hoch-aktuell. Nida-Rümelin

sieht solche Entwicklun-gen durchaus nicht nur ne-

gativ, aus seiner Sicht ist es

Professor JulianNida-Rümelin: Derehemalige Kul-turstaatsministerlehrt Philosophiean der Ludwig-Ma-ximilians-Univer-sität in Münchenund beschäftigt sichunter anderem mitden Grenzbereichenzwischen Technik undEthik.

Bild: Copyright: (c) Bernd Euring 2010

document4822085534826575554.indd 9 13.02.2017 11:14:54

10



Bundesverkehrsminister Alexander Dobrindt (CSU) testet das pilotierte Fahren: Professor Nida-Rümelinwarnte in seinem Vortrag davor, die Kontrolle über ein Fahrzeug an einen Algorithmus zu übergeben.

Bild:AUD

IAG

jedochwichtig, die „conditio humana“, alsodiemenschlicheNatur, nicht aus demBlick-feld zu verlieren. Er befürwortet es, neueTechniken zu verfolgen, aber es dürfe nichtdazu führen, „dass alles ins Rutschenkommt“.

Verantwortung heißt Rechen-schaft ablegenIn diesemZusammenhangkommtder Be-

griff derVerantwortung ins Spiel. Der Termi-nus selbst ist laut Nida-Rümelin zwar erstrunde 300 Jahre alt, das Prinzip ist jedochbereits in der „Nikomachischen Ethik“ desgriechischen Philosophen Aristoteles (384bis 322 vor Christus) enthalten. Verantwor-tung zu übernehmen, bedeutet hier gegen-über anderen – möglicherweise gegenübereiner höheren Instanz – Rechenschaft fürseineHandlungenabzulegen.Unddies setzteine zutiefmenschliche Fähigkeit voraus: dieFähigkeit zu deliberieren, also zu überlegenund zu bedenken.Maschinen seien dazu nicht in der Lage,

urteilt derMünchner Philosoph.Nida-Rüme-lin erteilt damit den Verfechtern einer soge-

„Dass Computer gewaltige Rechenleistungen vollbringenoder Siri auf dem iPhone alle mögliche Fragen beantwortet,bedeutet nicht, dass etwas Persönliches vor sich geht.“

Professor Julian Nida-Rümelin

nannten „starken KI“ eine Absage, die kei-nen grundsätzlichen Unterschied zwischendenKapazitäten vonMenschenundCompu-tern sehen. Nach deren Auffassung könnepraktisch jedwede Entscheidung an einenAlgorithmus ausgelagert werden.Dies verneintNida-Rümelin vehement. Der

Philosoph stellt sich auf die Seite der Ver-fechter der sogenannten „schwachenKI“, diedie technischenFähigkeiten vonComputernzwar anerkennen, aber dennoch eineGrenzezwischen den den Möglichkeiten vonmenschlichen undmaschinellen Intelligen-zen ziehen.

Vorgänge simulieren bedeutetnicht unbedingt verstehen„Die Tatsache, dass Computer unglaubli-

che Rechenleistungen vollbringen oder Siriauf dem iPhone alle möglichen Fragen be-antwortet, bedeutet nicht, dass etwas Per-sönliches vor sich geht. Es fehlen einfachmentale Zustände“, stellt Nida-Rümelin fest.Als Beleg hierfür führt er das Gedankenex-periment des sogenannten chinesischenZimmers an, das der amerikanische Philo-

soph John Searle (*1932) formuliert hat. Da-bei handele es sich um einen Raum, in demsich einMenschaufhält, der die chinesischeSprachenicht beherrscht. Durch ein Fensterwerden ihm immer wieder Schrifttafeln ge-zeigt, die auf Chinesisch formulierte Fragenenthalten.Da die Tafeln auch Nummern enthalten,

kann die Person im Zimmer durch das Fens-ter seinerseits die passenden Tafeln anzei-gen, die die entsprechenden Antworten aufChinesisch enthalten.Wird zumBeispiel dieFragetafel 21 gezeigt, kann die Person imZimmer die entsprechende Antwort-Tafelheraussuchen und hochhalten.Dadurch entstehe zwar der Eindruck, die

Person im Zimmer verstünde Chinesisch,was aber nicht der Fall ist. Damit zeigt Sear-le nach Ansicht von Nida-Rümelin auf, dassdas Bestehen des sogenannten Turing-Testsnoch nicht beweist, dass es sich um echtesDenken handelt: Ein Computer könne zwarProgramme ausführen und Zeichenreihenausführen; allerdings sei er nochnicht in derLage, das Gesagte auch zu verstehen.Die Fähigkeit zur Deliberation, also zum

Überlegen und Bewerten, sieht Nida-Rüme-lin deshalb bei aufAlgorithmenbasierendenSystemen nicht gegeben. Deshalb verfügensie auchnicht über die Fähigkeit zurWillens-freiheit und Verantwortung. Deshalb könneVerantwortlichkeit nicht an Computer über-tragen werden.

Verantwortung kann nicht dele-giert werdenÜbertragen auf aktuelle technische Ent-

wicklungen wie das autonome Fahren be-deutet dies, dass die Verantwortung für dieHandlungen im Straßenverkehr letztlichnicht an einen Computer übergebenwerdenkann. BestimmteAbwägungen, etwadas oftzitierteDilemma, ob ein autonomgesteuertesFahrzeug, das in einer Notsituation nichtmehr anhalten kann, ehermit einemälterenVerkehrsteilnehmer oder mit einer jungenMutter mit einem Kinderwagen, kollidierensolle, sind lautNida-Rümelin in einer zivilenOrdnung unzulässig.Daher warnt der Münchner Philosophie-

professor und bekennendeAlfa-Romeo-Fandavor, komplexe Abwägungen an einen Al-gorithmus zu übergeben. Er rät deshalb vonautonomen Fahrzeugen ab. Stattdessenspricht er sich für die Regelung der völker-rechtlich verbindlichen Wiener Konventionaus,wonachder Führer eines Fahrzeugs stetsdie Kontrolle über das Fahrzeug behaltenmüsse. Das könne in der Praxis so aussehenwie in der Luftfahrt, bei der Piloten häufignur eineüberwachendeTätigkeit ausführen,

document4822085534826575554.indd 10 13.02.2017 11:14:59

ELEKTRONIKPRAXIS Embedded Software Engineering Februar 2017 11

während der Autopilot fliegt. Der Fahrermüsse eben jederzeit in der Lage sein, einzu-greifen.EineAlternativewäre eineArt öffentliches

Verkehrsmittel, das zentral betrieben wirdundbei demdie autonomenFahrzeuge qua-si auf Abruf bereitstehen. Eine Delegation,daswiederholte der Professor andieser Stel-le noch einmal, funktioniere nicht.

Eine weitere Folge der technischen Ent-wicklung, nämlichdie unaufhaltsamvoran-schreitende Digitalisierung, führt aus SichtvonProfessorNida-Rümelinnicht dazu, dassdenMenschendieArbeit ausgehe.DieseKla-gehabe es seit Beginnder Industrialisierunggegeben, sagte der Professor. Diese Einschät-zungenhätten sich stets als falschherausge-stellt, das Arbeitsvolumen sei im Gegenteil

insgesamt gestiegen. Natürlich werde dieDigitalisierung viel verändern, sagte Nida-Rümelin; zu glauben, dass die Maschinenden Menschen letzten Endes die Arbeit ab-nähmen, kämeallerdings einer „Unterschät-zung des ökonomisch-sozialen-kulturellenSystems“ gleich. // FG

ESE Kongress

Das Runde muss ins Eckige: Beim Kickerturnier amDienstagabend stieg die Stimmung der Kongress-teilnehmer.

Bild:ElisabethWiesner

Streng unparteiisch:Michael Ruprecht und AndréSchmitz von Green Hills Software führen akribischBuch über das Turniergeschehen.


Ruhe vor dem Besucheransturm: Das Team vonAxivion. In der Mitte Geschäftsführer SebastianRummler.


Druckfrisch:Mit dem Entwickler-Leitfaden für dieHard- und Softwareplattform Synergy warteteRenesas auf.


Introvertiert oder extrovertiert: Die Kommunikati-onsexpertin Dr. Sylvia Löhken hatte in ihrer Keynotegute Tipps für beide Mitarbeiter-Typen.


Begeistertes Auditorium: Die Zuhörerinnen und Zuhörer spendeten den Keynotes enthusiastischen Beifall.


Die Jubiläumstorte zum 20-jährigen Bestehen vonMicroConsult: Links: Ingo Pohle, MicroConsult,rechts: EP-Publisher Johann Wiesböck.


document4822085534826575554.indd 11 13.02.2017 11:15:09

12

TEST UND BETRIEB // SOFTWARE-MONETARISIERUNG


Gerätehersteller werden zu Soft-wareanbietern – oder obsolet

Im IoT-Zeitalter ist die Software der entscheidende Wachstumstreiber.Geräte- und Systemhersteller müssen deshalb zu Softwareanbietern

werden, wenn sie nicht an Marktbedeutung verlieren wollen.

ANSGAR DODT *

* Ansgar Dodt... ist Vice President für den BereichGlobal Sales – Software Monetizationbei Gemalto.

Weder für Hardwareprodukte nochfür Embedded-Systeme ist Soft-ware ein neues Kapitel. Geändert

hat sich jedochdie Tatsache, dass die bislangeher tröpfelnde Produkt-Evolution mit demIoT zu einer Flutwelle in Richtung zu soft-warebasiertenGeschäftsmodellen gewordenist. Marktführende Hardware- und Embed-ded-Systemhersteller wie General Electricoder Rockwell Automation, aber auchCisco,die eine Transformation hin zum Software-Business vollzogen haben, profitieren ammeisten davon, denn sie treiben dadurchauch den Erfolg ihrer Kunden voran.Für traditionelle Embedded-Board- und

Embedded-Systemhersteller sowie Steue-rungs- und Automatisierungsanbieter hatdas enorme Konsequenzen. Wenn sie sichnämlich nicht hin zum Software-Unterneh-men wandeln, riskieren sie fallende Gewin-

ne, wegbrechende Marktanteile und laufenGefahr, in die Bedeutungslosigkeit abzurut-schen. Die Gründe dafür wollen wir uns imFolgenden genauer anschauen.

Gesteigerte Profitabilität, hoheAgilitätDer Übergang zu Software-Geschäftsmo-

dellen steht in direkter Korrelation zu erhöh-ten Gewinnen, in erster Linie aufgrund dergeringen Stückkosten und Variantenvielfaltder Hardware sowie auch durch sinkendeKosten für die Herstellung und den laufen-den Betrieb. Software ist zudem von Naturaus rentabler als Hardware. Die Bruttomar-gen für reine Software-Unternehmen über-steigen oftmals 50 Prozent, während dieHardware-Margen in losgrößenstarkenBran-chen oft sogar unter 10 Prozent liegen.Der Paradigmenwandel hin zur Software

führt aber auch zur Bestandsbereinigung,KonsolidierungderBestände, zu schnellerenVerkaufszyklen und damit insgesamt auchzu einer operativ höheren Effizienz. DieseTransformation aber für Endanwender trans-parent, zuverlässig und sicher sowie ohne

Einnahmeverluste durch Piraterie umzuset-zen, ist dabei eine große Herausforderung.Diese Herausforderung kann jedoch rechtelegant und effizientmit professionellenMo-netarisierungslösungenaktuellerAuslegunggemeistertwerden.UndhatmandiesenPro-zess erst einmal imGriff, kannman ihnauchmehrfach nutzen, und beispielsweise Up-grades für bereits bereitgestellte Produkteanbieten.Softwaregetriebene Geschäftsmodelle er-

möglichen es auch, sehr flexibel auf sichänderndeKundenbedürfnisse unddie damiteinhergehenden Funktionsanforderungenzu reagieren. Außerdem lassen sich in derEntwicklung agileVorgehensmodelle einset-zen. Anbieter können Software-Funktionenschnell ein- undausschalten oder aufAnfra-ge beispielsweise über Clouds zusätzlicheKapazitäten freischalten.Wenn sie von einem entsprechenden Be-

reitstellungs- und Monetarisierungs-Layerunterstütztwerden, können solcheVorgängeauch ohne manuelle Auftragsbearbeitungoder physikalische Neukonfigurationenmitwenigen Klicks ausgeführt werden. Um die

Abbildung 1: Die Auswirkungen des IoT-Trends in Zahlen (Quellen: Cisco Systems, GE und Frost & Sullivan)

Bild:G

emalto

document2899513939440884729.indd 12 13.02.2017 09:33:12

TEST UND BETRIEB // SOFTWARE-MONETARISIERUNG

Vorteile von solchen softwaregetriebeneGe-schäftsmodellen voll und ganz nutzen zukönnen, müssen Unternehmen jedoch ler-nen, ihre Lösungen auf Basis einer einzigenCommon-of-the-Shelf-Hardware aufzubau-en, sodass Features und Funktionen reinelektronisch durch Lizenzierung aktiviert,parametriert und optional auch aus der Fer-ne jederzeit auch aktualisiert werden kön-nen.

IoT und kontinuierlicheVerbesserungenIoT-basierte Applikationen setzen oft auf

die Philosophie umsetzungsorientierterKennzahlen und Messgrößen, aus derenAnalysemanEntscheidungen zur Verbesse-rung ableiten kann. Es gibt viele reale Bei-spiele, bei denen eine Datenerfassung undAnalyse zu eindrucksvollenVerbesserungenbei Unternehmen geführt hat.Analysten vonFrost&Sullivan fandenbei-

spielsweise heraus, dass 82 Prozent der Un-ternehmen, die einen intelligenten Ferti-gungsprozess implementiert haben, auchdieEffizienz ihres Produktentwicklungsprozes-ses steigern konnten. Viele verzeichnen zu-demdurchdie Einführungvon IoT-Technikenin ihre Fertigungslinien eine Zunahme desProduktionsausstoßes, der nicht selten bei20 bis 30 Prozent liegt.Es gibt außerdem einen Trend weg von

statischen Vorab-Verkäufen hin zu Abonne-ment-basierten Preisgestaltungsmodellen,Pay-per-Use-Abrechnungen und bedarfsge-rechter Feature-Aktivierung. Anbieter profi-tieren von der nutzungsbasierten Abrech-nungdurch einen vorhersehbarenund inderRegel höchst stabilen Cashflow, den klassi-sche SaaS-Anbieter (SaaS: Software as a Ser-vice) schon seit einigen Jahren genießen.Dazudemnurdie tatsächlicheNutzung inRech-

nung gestellt wird, werdenUnter-nehmen auch dazu ermutigt,zusätzliche Features zu er-proben oder ihrePakete upzu-graden, diesie sonst nor-malerweiseniemals käuf-lich erworbenhätten. Anbieterjeder Größe und ausjedem vertikalenMarkt entwickelndeshalb zunehmendflexiblere Lizenz-undPreisgestaltungs-modelle. Es sind alsonicht nur Unternehmenwie Adobe, Cisco Systems undMicrosoft in Richtung softwarezentrierterGeschäftsmodelle unterwegs, sondern auchviele kleinereUnternehmenmit Spezial- oderNischenprodukten, die dieVorteile der flexi-blen Preis- und Angebotsgestaltung nutzenwollen.

Flexibilität bei Feature-Bundlesund LagerwareAnbieter von Hardware und Embedded-

Systemen wissen, dass ihre Kunden nur soviel vom Produkt erwerben und bezahlenwollen, wie sie tatsächlich brauchen. WennHardwareunternehmen anfangen, ihre Pro-dukte auf die gleiche Weise wie Software-unternehmen zu bauen, zu lizenzieren undzumonetarisieren, sind sie zunehmendbes-ser aufgestellt, den Prozess der Bereitstel-lung und Parametrierung von Features zuautomatisieren,wasdemBedarf der Kundenoder Endanwender, unmittelbare Lösungenzu erhalten, entgegenkommt.

Mit Hilfevon Soft-

warearchitektu-ren lässt sich hier einhohesMaßanFlexibi-lität erreichen, dasheute auch zuneh-mendvoneinermehrund mehr standardi-

sierten Hardware un-terstützt wird. Das Ergeb-

nis: bessere Produkte, niedrigereForschungs- undEntwicklungskosten sowieeine höhere Differenzierung vom Wettbe-werb durch Software.Aufgrund der Wachstumschancen, die

sowohl durch die objektive Analysen vonMarktforschern als auchdurchBest-Practice-Beispiele belegbar sind, sollten sich Unter-nehmen offensiv in Richtung Software-ba-siertes Feature-Management, nutzungsba-sierte Preisgestaltungen und virtualisie-rungsfreundliche Cloud-Architekturenbewegen.Moderne Systemlösungen zur Software-

Monetarisierung unterstützen Anbieter da-bei umfassend. Gleichzeitig bieten sie denZusatznutzen, Herausforderungen wie denSchutz vor IP-Diebstahl, Produktfälschungund Umsatzverlusten meistern zu können,die bei Software-basiertenProduktenunwei-gerlich auftreten. // FG

Gemalto

Abbildung 2:Gegenüber klassischer Hardwarebietet die Softwareorientierung

fünf klare Vorteile fürUnternehmen

Bild: Gemalto

document2899513939440884729.indd 13 13.02.2017 09:33:16

14

SYSTEMVIRTUALISIERUNG // HYPERVISOR


Jailhouse: Ein Hypervisor für Multi-Core, Embedded und Echtzeit

Auch im Embedded-Umfeld lassen sich viele Vorteile der Hypervisor-Technik anwenden. Die Open-Source-Lösung Jailhouse hat hierfür zahl-

reiche Trümpfe im Ärmel.

HEINZ EGGER *

* Heinz Egger... ist seit 2006 Geschäftsführer vonLinutronix. Er hat mehr als 20 JahreErfahrung im Embedded- und Auto-matisierungsbereich.

Inden letzten Jahren sind IT-Technologienimmer schneller in der Industrie akzep-tiert worden. Bei dem ThemaHypervisor

(oft auch Virtual Machine Manager, kurzVMM, genannt) hat es dennoch etwas gedau-ert. Hypervisor Lösungenwerden seit ihremersten Auftreten in den 70er Jahren des letz-ten Jahrhunderts in Type I (bare–metal) undType II (host based hypervisor) Lösungenunterschieden. BeidenAnsätzen gemein ist,dass sie virtuelle Maschinen für die einzel-nenGastsystemevorhalten. Dazubenötigensie Emulationen der Hardware, um jedemGastsystem ein vollständiges Hardware-System zur Verfügung stellen zu können.Hypervisor-Lösungen in der IT erlauben

es, Systeme einfach zu skalieren, zu migrie-

ren und zu portieren. Damit können die IT-Systemedynamisch andie aktuelle Lastsitu-ation angepasst werden und bei Problemenan der HW oder dem Einsatz neuerer Hard-ware einfach „umziehen“, also auf die neueHardwareübertragenwerden.Nebenbeiwirddie Sicherheit verbessert, da alle virtuellenSysteme untereinander abgeschottet sind.Alte Software kann länger genützt werden,da sie nun in einer eigenen virtuellen Ma-schine weiterhin auf der neuen Hardwarezum Einsatz kommen kann.

Warum Virtual Machine Mana-ger einsetzen?ImEmbedded-Bereich könnenviele dieser

Vorteile ebenfalls genutztwerden. Bisher aufunterschiedliche Hardware verteilte Lösun-gen können auf eine Maschine konsolidiertwerden. Alte Systeme (bare metal oder alteBetriebssysteme) können weiterhin genutztwerden, HMI (GUI), Echtzeit und SPS oderzertifizierte Programme können nebenein-

ander auf einer Hardware zumEinsatz kom-men. Der Einsatz von dynamischer Lastver-teilung ist bei Echtzeitanforderungen aller-dings kontraproduktiv.Die vornehmlich das Thema Security be-

treffendenAnforderungen aus dem IoT-Um-feld anEmbedded-Systemekönnenmit demVirtualisierungsansatz gelöst werden, ohnedass die zugrundeliegende Embedded-Ap-plikation neu erstellt werden müsste. Unddurch die Aufteilung in mehrere virtuelleMaschinen hat man auch die Probleme, diebei einer Anwendung mit zertifizierter unddaher nicht einfach änderbarer Software aufder einen Seite und den ständigen Update-Anforderungen auf der IoT-Seite aufkom-men, elegant gelöst.

Welche Hypervisor-Typen gibtes?Seit den erstenHypervisor-Lösungenwer-

den diese prinzipiell in zwei große Kategori-en, Type I und II, unterteilt. Hier eine kurzeBeschreibung der beiden Typen:Type-I-Hypervisoren (bare-metal) laufen

direkt auf derHardwareundbenötigendahereine komplette Unterstützung sämtlichervorhandener physikalischer Schnittstellenauf demSoC.Dennhier ist es derHypervisor,der die Hardware initialisieren muss und inBetriebnimmt. Eswundert daher nicht, dasshier oftMikrokernel-Lösungenwie beispiels-weise L4 zum Einsatz kommen. Nur so lässtsichdie komplexeAufgabenstellung einiger-maßen sinnvoll lösen. Type-I-Hypervisorenkönnen zwar dieHardware-basiertenUnter-stützungennutzen, die Intel-VToderAMD-Vbieten, aber spätestens bei der Nutzung vonvirtuellen CPUs oder anderen virtuellen Ge-rätenmussderHypervisor aktivwerdenunddie Ressourcen verwalten und zuteilen.Und das verursacht eine zusätzliche,

durch die Software bedingte Latenz im Sys-tem.Bei Industriesystemen, die auf Echtzeit-verhalten (sprich: eine verlässliche, determi-nistischeReaktion) angewiesen sind, ist das

Bild 1: Systemkonsolidierung mit dem Jailhouse-Hypervisor. Für jede „Cell“, in der ein Gastsystem residiert,ist mindestens ein Prozessorkern erforderlich.

Bild:Linutronix

document8656083008537660303.indd 14 13.02.2017 11:31:25

15



kontraproduktiv. Auch ist die Skalierbarkeitbeziehungsweise Portierbarkeit bei derarti-gen Type-I-Hypervisoren aufgrund IhrerKomplexität eingeschränkt oder mit hohemAufwand verbunden.Type-II-Hypervisoren setzen imGegensatz

dazu auf einemHost-Betriebssystem (BS) auf.Das vereinfacht denHypervisor undverleihtihm eine einfachere Portierbarkeit, soferndas Host-OS einfach zu portieren ist oderbereits auf vielen Systemenunterstütztwird.Allerdingsmüssenhier Zugriffe auf dieHard-ware, sofernnicht durchdieHardware direktauf das Gast-OS routbar, durch das Host-OSbehandelt werden. Virtuelle CPUs und I/O-Devices benötigen auchhier ein Scheduling,um den Zugriff durch die diversen Gast-Be-triebssysteme zu regeln. Auch hier gilt, wasschon bei den Type-I-Hypervisor-Lösungenin Bezug auf die Echtzeit gesagt wurde: die-ses Verhalten ist kontraproduktiv, da es zu-sätzlicheVerzögerungen (Latenzen) einführtund so den Jitter des Systems vergrößert.EinWeg, umEchtzeit-Verhalten imGast zu

erreichen, wäre es, das Gast-OS so anzupas-sen, dass es nicht alleHardware benötigt undihmdie benötigeHardware exklusiv zurVer-fügung zu stellen. Das geht nur bei Betriebs-systemen, auf deren Quellcode man Zugriffhat oder die per se so konfigurierbar wären.Das komplette Gast-OSwäre nun außerhalbdes Zugriffes des Hypervisors. Bei diesemAnsatzwürdemandieVergrößerungder La-tenzzeitendurchweitere (Verwaltungs-)Soft-ware vermeiden. Der Nachteil bei diesemAnsatz ist, dass ein Monitoring dieses Gast-systems nicht mehr gegeben ist. Im KontextvonSecurity undSafety einnicht akzeptablerZustand, dadieserGast vollkommenunkon-trolliert auf dem SoC laufen würde und einnicht autorisierter Zugriff auf einGerät nichterkannt werden würde.Zusammengefasst: Betrachtet man die

spezifischen Anforderungen eines Embed-ded- (Industrie-) Systemsunddie Erwartun-gen an einen Hypervisor, dann würde mansich ein System wünschen, bei dem es zukeinemOverheadaufgrundderVMMkommt(wie bei denobengenanntenSystemen), da-mit die Echtzeitfähigkeit gegebenbleibt. Aufder anderen Seite muss das System in sichgegeneinander komplett abgeschottet blei-ben, damit keine gegenseitigeBeeinflussungmöglich ist, da sonst die notwendige Sicher-heit (Datenintegrität etc.) beziehungsweisefunktionale Sicherheit nicht realisierbar ist.Hier setzt Jailhouse auf. Der Hypervisor

nutzt die Tatsache, dass moderne SoCs be-reits eine vielfältigeHardwareUnterstützungfür Virtualisierungstechnologien (Intel-VT,AMD-V, ARM-V Technologie) mitbringen.

Jailhouse nutzt zur erstmaligen Initialisie-rung beim Bootvorgang ein Linux-System,wasdieGrößedesHypervisors unddamit dieGröße der vertrauenswürdigen Codebasis(TCB = trusted code base) deutlich limitiert.

Jailhouse – ein etwas andererAnsatzJailhouse ist ein Open-Source-Soft-

wareprojekt. Der Code steht unter der LizenzGPLv2.Ursprünglichwurdedie Entwicklungvon Siemens gestartet, heutewird Jailhousevon vielenUnternehmenunterstützt. So hatbeispielsweiseAMDdie Portierung auf seineCPUs beigesteuert, ARM die auf die ARM

Bild 2:Hardware-Initialisierungmit Linux.

Bild:Linutronix

Wir stellen aus: Embedded World 2017 * Halle 4 * Stand 4-310

Technologie ab ARM v7 aufwärts. Und vonHuawei kam die Portierung auf ARM64.Das Linux-Systemverbleibt nachdemStart

von Jailhouse auf demSystemundbildet diesogenannte root cell. Sie übernimmtdieVer-waltungund erlaubt den Zugriff auf das Sys-tem und die VMs. VMs können hierüber ge-stoppt oder neu gestartet werden. Dies allesohneNebenwirkungenauf die anderenVMs.Damit ist eine kritischeMindestfunktionali-tät für Security und Safety gegeben.Jailhouse ist also von der Art und Weise,

wie der SoC initialisiert wird, ein Type-II-Hypervisor. Auf der anderen Seite ist es aberauch ein Bare-Metal-Hypervisor, da er wäh-

Anzeige

document8656083008537660303.indd 15 13.02.2017 11:31:27

16



rend der Nutzung des SoCs direkt auf derHardware sitzt und diese verwaltet.Jailhouse erzeugt maximal so viele VMs,

in Jailhouse „cell“ genannt, wie physikali-scheCPUs vorhanden sind. Es könnendabeimehrere CPUs zu einer VM kombiniert wer-den. Jede Zelle bekommt ihren eigenenSpeicherbereich, ihre eigenen Interrupts,ihre eigene I/Ounddergleichen zugeordnet.Prinzipiell kommt ein Jailhouse-SystemohnevirtuelleGeräte aus. Die Zuordnungund spä-ter dann auch die Kontrolle, dass die Konfi-guration eingehaltenenwird, erfolgtmit deneingebauten Hardware-Features der SoCs(MMU, IOMMU, PCI pass through …). Imgünstigsten Falle muss der Hypervisor beieinemkorrekt laufendenSystemnie eingrei-fen, dennalleVorgängewie IRQ-Behandlungund dergleichen laufen ohne einen Eingriffdes Hypervisors ab. Dies hat zum Vorteil,dass echtzeitkritischeAufgabenohneVerzö-gerung durch Software abgearbeitet werdenkönnen. Die Kontrolle über die einzelnenCells wird auch in diesem Fall von der „rootcell“ ausgeübt.DieKonfigurationdes Systemskann jeder-

zeit geändert werden. Wenn etwa eine VMnichtmehr benötigt undgestopptwird, dannkönnen die Ressourcen dieser VM neu auf-geteilt werden. Dazu ist die Konfigurations-datei entsprechendanzupassenundvonder„root cell“ danach auszuführen. Auf dieseWeise kann das Gesamtsystem dynamischangepasstwerden. In einer Zelle könnenun-terschiedliche Systeme zurAusführungkom-men, vom„historischen“OSbis hin zu einerbare-metal Applikation.Dadurch eignet sichein Jailhouse-Ansatz sowohl zurKonsolidie-rung als auch zur Migration bestehenderSysteme [siehe Bild 1].Wenn Ihr bisheriges SystemeineMigration

auf eine „Teil-CPU“ nicht zulässt und Sieauch keinen Zugriff auf den Code haben, soist das keinBeinbruch. Sie können für diesenFall entweder in einer VM einen Hypervisorwie kvm (Virtualisierungslösung unter Li-nux) und einenEmulator (Qemu) laufen las-sen oder Sie partitionieren Ihr SoC bereits

von Anfang an in einen Teil mit kvm undQemuundeinenTeilmit Jailhouse. In beidenFällen können Sie Ihre bisherige Lösung,etwa für das HMI, wiederverwenden.Der Ansatz von Jailhouse, die Hardware-

Ressourcen für dieVirtualisierung zunutzen,erlaubt einen sehr schlanken Hypervisor.SeineCodegrößeunddamit die TrustedCodeBase (TCB) liegt sowohl für x86- als auch fürARM-basierte Systeme unter 10k LoC. DerzweiteVorteil ist die kompletteAbschottungder Cells untereinander. Im Falle eines An-griffs auf eine VM ist dies ein großer Vorteil,da alle anderen Zellendavonnicht betroffensindundeineAusbreitung auf andere Zellennicht möglich ist.

Virtualisierung undSystemsicherheitZum Thema Sicherheit gehört aber auch,

dass man eine vertrauenswürdige Kette vonSoftware besitzt, vomFirst StageBootloader(FSBL) über den eigentlichenBootloader bishin zudenSystemen, die in einerVM laufen.Die Kette aus FSBL, Bootloader wie Uboot,Linux usw. kann signierte Module erzeugenund verwalten. Damit kann sichergestelltwerden, dass nur vertrauenswürdige undauthentifizierte Software ausgeführt wird.Für den Fall, dass eine rein software-mä-

ßige Absicherung nicht ausreicht, könnenHardware-basierte Methoden wie TPM oder

Trust Zone zusätzlich genutzt werden. Sorgtmandafür, dass einUpdate der System-Soft-ware auch nur mit signierter Software erfol-gen kann, so bekommt man ein sicheresSystem.WeitereMöglichkeiten zur Erhöhungder Sicherheit wie ständige Selbstüberwa-chung der „root cell“ sind denkbar. Es liegtam Kunden und am Einsatzfall, um zu ent-scheiden,welches Sicherheitsniveau erreichtwerden muss und damit auch, welcher Auf-wand investiert werden soll.Wichtig: Der Einsatz des Hypervisors

schließt die Verwendung von Technologienwie Trustzone nicht aus!

Echtzeit-Eigenschaften unterJailhouseNicht nur dasDesigndesHypervisors kann

die Echtzeiteigenschaften beeinflussen.AuchdieHardwaremuss beimodernenCPUsin Betracht gezogen werden. Um etwa dieEnergiebilanz eines SoCs zu verbessern,wiees bei einembatteriebetriebenenSystemnot-wendig sein mag, haben die CPU Herstellerviele intelligente Details in ihre Systeme in-tegriert. Dazu gehören beispielsweise dieReduzierungder CPUFrequenz, die Reduzie-rung von CPU Spannungen oder das Schla-fenlegen der CPUs. Oder das Übertakten ei-nes Cores, während gleichzeitig ein andererCore verlangsamtwird.Unddas kann,wenndas Echtzeitsystemauf diesemzweitenKernläuft, schlecht für die Latenz des Systemssein. Der Hypervisor muss also ein solchesschädliches Verhalten verhindern und auchalle anderenMöglichkeiten einesmodernenSoCs abschalten, die negativen Einfluss aufdie Reaktionsfähigkeit haben könnten.Wenn der Hypervisor nicht eingreifen

muss, wie es bei Jailhouse der Fall ist, wenndas Echtzeitbetriebssystem in einer sauberkonfigurierten VM läuft und damit auch aufeiner odermehrerennur demRTOS zugeord-neten CPUs, dann sollte das zu Ergebnissenführen, die optimal sind. Und in der Tat zei-gen unsere Messungen, dass auf einem x86System der Unterschied in der Latenz zwi-schen einem echtzeitfähigen Linux in der„root cell“ und in der VM nur gut 1 Mikrose-kundebeträgt [sieheBild 4]. Ein vernachläs-sigbarerWert. Und das bei einem RTOS, dasvoll gekapselt ist und unter kompletter Kon-trolle desHypervisor bzw. derHardware aus-geführt wird. Echtzeit ist also in einer virtu-ellenMaschinedarstellbar bei gleichzeitigermaximaler Sicherheit des Systems.Die Latenzmessung erfolgte mit dem Pro-

gramm cyclictest, das im Linux-Umfeld in-zwischen generell als Messverfahren zurFeststellung von Latenzen bei zyklischenAnwendungen zum Einsatz kommt und an-

Bild 3: Jailhouse konfiguriert den SoC.

Bild:Linutronix

Bild 4: Latenzen in der „root cell“ (rot) und dervirtuellen Maschine (blau).

Bild:Linutronix

document8656083008537660303.indd 16 13.02.2017 11:31:28

17



Eine Übersicht über Hypervisor-TypenBegonnen hat es in den sechziger Jahrendes letzten Jahrhunderts, als IBM mit denersten Forschungsarbeiten über virtuelleMaschinen auf dem Mainframe-RechnerIBM 360 begann. Um die virtuellen Ma-schinen verwalten zu können, wurde derVirtual Machine Manager (VMM), auchHypervisor genannt, eingeführt.1974 veröffentlichten Popek und Gold-berg eine Arbeit [1], die wesentliche Ei-genschaften eines Hypervisors definiertund seitdem Gültigkeit besitzt. Danachmuss ein Hypervisor in der Lage sein,eine virtuelle Umgebung mit folgendenEigenschaften zur Verfügung zu stellen:�Wiedergabegenauigkeit: eine Software,die in einer virtuellen Maschine (VM) aus-geführt wird, muss sich genauso verhal-ten, als wenn sie auf der physikalischenHardware ausgeführt werden würde� Das Ergebnis der Ausführung einerSoftware in einer virtuellen Maschinedarf sich nicht von dem Ergebnis bei einerAusführung auf der physikalischen Hard-ware unterscheiden� Leistungsfähigkeit: die Mehrheit derInstruktionen des Gastsystems werdenohne Eingriff des Hypervisors von derHardware ausgeführt

� Sicherheit: Der Hypervisor managt alleverfügbaren Hardware-Ressourcen.Goldberg hat in seiner Doktorarbeit von1972 (Principles for Virtual Computer Sys-tems) die noch heute gültige Unterschei-dung von Hypervisoren nach der Art undWeise, wie sie auf einer Hardware instal-liert werden, in Type I und Type II einge-führt.� Ein Typ-1-Hypervisor (native oder bare-metal) setzt direkt auf der Hardware aufund benötigt keine vorherige Betriebssys-tem-Installation. Das setzt allerdings vor-aus, dass die Hardware des Hostsystemsvom Typ-1-Hypervisor durch entsprechen-de Treiber unterstützt wird. [2]� Ein Typ-2-Hypervisor (hosted) setzt aufeinem vollwertigen Betriebssystem, aufdem Hostsystem, auf und nutzt die Gerä-tetreiber des Betriebssystems, um auf dieHardware des Hostsystems zuzugreifen.Typ-2-Hypervisoren sind daher auf allenHostsystemen lauffähig, auf denen vomHypervisor unterstützte Hostbetriebssys-teme lauffähig sind. [2]Typ-1- und Typ-2-Hypervisoren könnennoch weiter unterteilt werden in Voll-Virtualisierung, Para-Virtualisierung undDynamic-Binary-Translation- (DBT) Tech-

niken. Bei einer vollständigen Virtuali-sierung präsentiert der Hypervisor jedemGastsystem, unabhängig von der realenHardware des Host-Systems, eine emu-lierte Hardware. Bei einer Para-Virtuali-sierung wird das Gastsystem so geändert,dass es nunmehr nicht mehr mit der rea-len Hardware, sondern nur noch mit demHypervisor kommuniziert.Das hat den Vorteil, dass nicht für jedeVM eine HW emuliert werden muss, dasSystem wird dadurch deutlich performan-ter. Ein idealer Ansatz für Serversysteme,bei denen mehrere VMs gleichzeitig lau-fen sollen.Daneben gibt es noch Betriebssystem-Virtualisierungen, bei dem das Betriebs-system die Hardware in virtuelle Ma-schinen aufteilt, in denen diese nur ihreeigenen Daten mitzubringen haben, alsoähnlich wie bei einer Container Lösung.

Quellen:[1] G. J. Popek and R. P. Goldberd, “Formalrequirements for Virtualizable Third-Ge-neration Architectures,” Communicationsof the ACM, 1974.[2] Quelle: https://de.wikipedia.org/wiki/Hypervisor

erkannt ist. Umeinen realistischenMesswertzu erhalten, wird das System mit dem Toolhackbenchmit einer hohenLast beaufschlagt(rund 1600Prozesse kommunizieren ständiguntereinander, damit auch die CPU-Cache-speicher immer neu gefüllt werden müssenund dergleichen). Cyclictest setzt zyklischverschiedene Timer auf und misst kontinu-ierlich die Abweichung zum gewünschtenAufwachzeitpunkt. Hiermit wird der kom-plette Codepfad abgedeckt, der auch für je-den anderen Interrupt relevant ist (Timer-Interrupt schlägt zu und in der Folge musseineApplikation aufgewecktwerden). Dahersind die gemessenen Latenzen mit denenanderer physikalischer Interrupts, wie zumBeispiel von einem GPIO, vergleichbar.

Kommunikationseigenschaftenunter JailhouseEin sicheres System, das in einer virtuellen

Umgebung Echtzeit erlaubt, ist ein riesigerSchritt für die Industrie. Aber die Kommuni-kation fehlt noch. Die Zellen müssen sichuntereinander verständigen können, wenndie Konsolidierung erfolgreich sein soll.

Ein Blick auf die bisherige Landschaft inder Industrie zeigt, dass die unabhängigenSysteme sich meist über Ethernet basierteMechanismen (TCP/IP) ausgetauscht haben.Daher liegt es nahe, dies auch als zuverläs-sige Kommunikation in Jailhouse zu integ-rieren. Dies erleichtert die Portierung exis-tierender LösungenumeinVielfaches. Dafürmüssen virtuelle IOs geschaffenwerden, dieein virtuelles Netzwerk ermöglichen.Daneben benötigt solch ein System eine

Interrupt-basierte Kommunikation überShared-Memory-Bereiche, diemittels Sema-phoren verwaltet wird. Auch muss die Sys-temzeit undÄhnliches unter allenCells aus-getauscht werden können.

Portierbarkeit und Skalierbar-keit von SystemenIndustrielle Anwendungen werden oft

über einen Zeitraum von vielen Jahren ge-nutzt. Die zugrundeliegendeHardware stehtjedoch nur für einen begrenzten ZeitraumzurVerfügung. Es ist daherwichtig, dass dieAnwendung einfach portiert werden kann.Und falls dieAnwendungwächst, dannmuss

auch eine einfache Skalierbarkeit gegebensein.Jailhouse kanndieseAnforderungen spie-

lend erfüllen. Mit Linux steht ein (Host-)System zur Verfügung, das auf jeder neuenSoC-Lösung zum Einsatz kommt. Damit istdie Skalierbarkeit und Portierbarkeit gege-ben. Und die Einfachheit dieser Portierbar-keit ist durch die Nutzung der offenenSchnittstelle libvirt (populäreBibliothek zurVerwaltung von Virtualisierungslösungen)zumManagement desHypervisors gegeben.Schaut man etwas weiter in die Zukunft,

dann sieht man bereits heterogene Multi-Core-LösungenamHorizont. Diese eierlegen-denWollmilchsäuebenötigendefinitiv einenHypervisor wie Jailhouse, damit all ihre Fä-higkeiten sinnvoll genutzt werden können.Hier dient derHypervisor auf der einenSeitezur Verwaltung der „großen“ CPUs, auf deranderen zur Kommunikation mit den ande-renCPU-Architekturenoder FPGA-Einheiten.Auch das sichere Update erfolgt über denHypervisor. // FG

Linutronix

document8656083008537660303.indd 17 13.02.2017 11:31:29

https://de.wikipedia.org/wiki/

18

ENTWICKLUNGSPROZESS // DOKUMENTATION


Technische Dokumentationim Scrum-Team

Auch die Technische Dokumentation lässt sich in die agile Softwareent-wicklung mit Scrum einbeziehen. Dieser Beitrag erläutert, was dabei

bedacht werden sollte.

HEIKE BATHE *

* Heike Bathe... ist Mitinhaberin von people text –Technische Dokumentation. Im Teamist sie Spezialistin für Business-Kom-munikation.

Sobald sich ein Unternehmen dazu ent-schließt, nach der Scrum-Methode zuentwickeln, betrifft dies auch die Kol-

legen aus der Technischen Dokumentati-on. In diesem Zusammenhang stellensich einige Fragen: Sollendie Technischen Redak-teure auchmit dieserMe-thode arbeiten?Wie siehtdie Zusammenarbeit aus?WelcheVortei-le hat es, wenn Technische Redakteure imTeam mitarbeiten und an den regelmä-ßigen Scrum-Meetings teilnehmen?

Wie sieht die Zusammen-arbeit im Team aus?Ein Scrum-Team

besteht aus unge-fähr neunKollegenmit unterschiedli-chen Qualifikatio-nen, die zusammenfür Design, Entwicklung, Test undTechnische Dokumentation verantwortlichsind. Teamwork steht dabei imVordergrund:Alle erledigen ihre Aufgaben in enger Ab-stimmung mit den anderen Teammitglie-dern.Das gilt auch für die TechnischeDoku-mentation. Im Rahmen von agiler Entwick-lung ist die Dokumentation ein integralerBestandteil des Produkts. Ohne Dokumen-tation gibt es kein Produkt.

Technische Redakteure sindjetzt Teil des TeamsFür TechnischeRedakteure, die früher der

Marketingabteilung oder einer eigenen Ab-teilung angehörten, bedeutet dies eine gra-vierende Veränderung. Die Redakteure ha-ben im Scrum-Team mehr Einblick in die

Produktentwicklung und kommunizierenöfter mit den Entwicklern, auch informell.Der Rückhalt des Doku-Teams fehlt, die Re-dakteuremüssen selbstständig arbeitenundEntscheidungen treffen.DadieseArbeitswei-se hoheEigenverantwortung erfordert, kannScrum für Mitarbeiter, die an hierarchischeStrukturen gewöhnt sind, schwierig umzu-setzen sein.Durch die tägliche Kommunikation im

Scrum-Meeting erhalten alle TeammitgliedereinenEinblick indieArbeit der anderen.Da-durch können Redakteure unkompliziertweitere Aufgaben übernehmen, beispiels-weise User-Interface-Texte korrigieren oder

Verbesserungen vorschlagen. Wennregelmäßiger Kundenkontakt vorge-sehen ist, können auch Redakteuredavon profitieren: Sie bekommeneindirektes Feedback auf ihreDo-kumentation und können diese

dann anpassen,umdieUser Experi-ence zu verbessern.Spezielle Werk-

zeuge helfen denTeams dabei, die Arbeitspakete zu

planen und jederzeit nachzuvollziehen.Die Arbeit ist transparent im Backlog ein-getragen und in einzelne Items aufgeteilt,so dass Entwickler und Redakteure ihreAufwände gut einplanen können.

Agile Entwicklung an verschie-denen Standorten

Wenn nicht alle Teammitgliedervor Ort zusammenarbeiten, bietenheutige InformationstechnologieneffizienteKommunikationsmöglich-

keitenwie zumBeispiel Videokonferen-zen oder Web-Meetings, um nur zwei zunennen. Dies ist auch für Redakteure wich-tig, weil sie meistens nicht auf die Entwick-lungsumgebung zugreifen können und dar-auf angewiesen sind, am Informationsflussteilzuhaben.ImRahmender agilenEntwicklung stehen

den Redakteuren nur noch wenige Spezifi-kationen als Informationsquelle zur Verfü-gung. Deshalb ist es wichtig, dass alle vor-handenen Informationenverfügbar sind. EinDokumentenmanagement-System hilft da-bei, Dokumentemit Kommentaren,Webina-re und andere Formate zu verwalten.Darüber hinaus ist das Scrum-Meetingdie

ideale Gelegenheit, um auf dem Laufendenzu bleiben. Aus diesem Grund sollten Tech-nischeRedakteure vonSprint 1 an imScrum-Team integriert sein. Die regelmäßigeDurch-sicht der Backlog-Items liefert Redakteurenebenfalls Statushinweise für ihreDokumen-

Die technische Redaktion und das Scrum-Team: Dietägliche Kommunikation erlaubt allen Teammitglie-dern einen Einblick in die Aufgaben der anderen.Dadurch können Redakteure unkompliziert weitereAufgaben übernehmen, beispielsweise User-Inter-face-Texte korrigieren.

Bild: peopletext

document8272924452375226005.indd 18 13.02.2017 11:49:54



tation. Redakteure sollten jederzeit Zugriffauf den aktuellen Build oder das Produkthaben, umdie eigeneDokumentation zu tes-ten und zu verifizieren.

Wie ändert sichdie Arbeitsweise?Durch die Prozesse der Scrum-Methode

könnenRedakteure dasArbeitspensumbes-ser einschätzen,weil sie nicht auf einen ein-zigen Abgabetermin hinarbeiten, sondernentlang von Backlog-Items dokumentieren.Unter Umständen ist es sinnvoll, das Doku-mentieren einer Funktion in einen späterenSprint zu verschieben, wenn beispielsweisedie Entwicklung noch nicht so weit fortge-schritten ist, dass die Software lauffähig istund getestet und beschriebenwerden kann.DasProdukt unddieDokumentationwerdenzeitnah getestet, so dass Fehler schnellerentdeckt werden und die Arbeit der Redak-teure kalkulierbar ist.Iterative Entwicklung: Zu den Prinzipien

agiler Entwicklunggehört es, besonders frühund kontinuierlich Ergebnisse an den Kun-den zu liefern. Änderungswünsche vonKun-denseite setzt das Team so schnell wie mög-lich um.Diese Anforderungen der iterativen Ent-

wicklungmachendeutlich, dass es nicht nurdarum geht, innerhalb eines festgelegtenZeitraums regelmäßig zu liefern, sonderndass der Entwicklungsprozess selbst diesenAnforderungen folgenmuss. Die technischeRedaktion muss sich ebenso an diese Ar-beitsweise anpassen.Projektplanung:DieProjektleitung entwi-

ckelt einenProjektplan, der Sprints,Meilen-steine und Deadlines umfasst. Dazu gehörtbeispielsweise einRedaktionsschluss für dieDokumentation. An den regelmäßigenScrum-Meetings sollten auchdieRedakteureteilnehmen. So erfahren sie, welche Aufga-ben abgeschlossen sind,welche verschoben

werdenmüssen undwo eventuell Problemeaufgetreten sind, die auch sie betreffen.Arbeitspakete schnüren: Bei der Arbeit

nach dem Wasserfallprinzip haben die Ent-wickler oft keine Möglichkeit, ihre Bespre-chungen mit den Redakteuren zeitlich zuerfassen. Oft genug fällt diese Zeit einfachunter den Tisch. Im Scrum-Modus ist die Er-stellung einzelner Texte ein Backlog-Item,mit demauchdie PositiondesRedakteurs imTeam gestärkt wird: Review, Test und Aktu-alisierungderDokumentation sollte in jedemSprint berücksichtigt werden.Die Erstellung der anfallendenDokumen-

tation kann nicht immer innerhalb einesSprints abgedecktwerden. Es fallenArbeitenan, die komplett unabhängig von zu pro-grammierenden Funktionen sind, etwa dieInformationsarchitektur derDokumentationzu entwickeln oder organisatorische Aufga-ben, die das Publizieren, Ausliefern oderArchivieren betreffen. Diese Aufwände soll-ten ebenfalls als Backlog-Item indenProjekt-plan aufgenommen werden.Es kann jederzeit zu kurzfristigen Ände-

rungen kommen, die berücksichtigt werdenmüssen. Die Zeit für ein Backlog-Item sollteso bemessen sein, dass dieRedakteure dieseÄnderungen noch in ihre Dokumentationeinarbeiten können.FolgendeDokumentationsaufgabenmüs-

sen erledigt sein, damit ein Backlog-Itemgeschlossen werden kann:�Die Funktion ist beschrieben.� Software sowie Dokumentation sind ge-testet.� Fehler, die vom Systemtest gemeldetwurden, sind entweder behoben oder dieBehebung ist geplant.Dann ist zu überlegen, welche Stände an

denKunden geliefert werden, so dass dieseroptimale Informationen erhält. Für das Pu-blizieren der Dokumentation werden Back-log-Items zum Ende eines Sprints angelegt,

Kontrolliertes Chaos: Scrum (Gedränge) ist ursprünglich ein Begriff aus dem Rugby und beschreibt eineSituation, in der das Spiel neu gestartet wird.

FITS INANYENVIRON-MENTby Garz & Fricke

Garz & Fricke GmbH

Hamburg | Germany

[email protected]

www.garz-fricke.com

ReliableQualityMade in Germ

any

Single BoardComputer and

Human Machine Interface

Complete system with

CPU board, display, touch,

front glass and housing

NXP ARM®i.Mx6

architecture

Scalable CPU

performance

Ready-to-runsystems

Industrial solutions

Board support

packages with drivers

for all interfaces

Operating systems:

Windows Embedded

Compact®, Linux and

Android™Visit uson

Embedded

World2-240

document8272924452375226005.indd 19 13.02.2017 11:49:57



http://www.garz-fricke.com

http://www.garz-fricke.com

20



so dass korrekte Inhalte andenKunden aus-geliefert werden.

Fortschritte machen und dabeiden Überblick behaltenRedakteure müssen Inhalte auf eine Art

und Weise erstellen und verwalten, die eserlaubt, die Dokumentation jederzeit anzu-passen und zu liefern. Wenn Redakteure je-doch einzelne Kapitel oder Abschnitte ausdemGesamtzusammenhangdesHandbuchsan den Kunden abliefern, dann erscheinendiese oft zusammenhanglos. Darüber hinausist es mit einigem Aufwand verbunden, einsolches Handbuch überhaupt in einen ak-zeptablen Zustand zu bringen, um auch nureinen Draft zu liefern.In der Praxis legenRedakteure leere Kapi-

tel oder Bausteine an, die dann imLaufe derSprintsmit Inhalten gefüllt werden.Mit Sta-tuszuweisungen können Redakteure denÜberblick darüber behalten,welcheThemenerledigt sindundwelchenochnicht. Folgen-de Status sind denkbar:� Leer� In Arbeit� Im Review� Final� In ÜbersetzungHier bietet sich der Einsatz eines Redak-

tionssystems an, das den gesamten Lebens-zyklus Technischer Dokumentationen viel-fältig unterstützt.

Gut organisiert imRedaktionssystemEin Redaktionssystem bietet spezielle

Funktionen, die Redakteure bei der Erstel-lung,VerwaltungundPublikationunterstüt-zen.Umdiese Funktionenbei der Erstellungvon Inhalten im Scrum-Modus sinnvoll zunutzen, sollte eine Informationsarchitektur

entwickelt werden. Eine Informationsarchi-tektur ist eine Struktur, die Informationensinnvoll gestaltet und damit im Ergebnis dieNutzungder Information für eine bestimmteZielgruppe vereinfacht.Im Zusammenhang mit Scrum sind die

folgendenFunktionen, die agileAnforderun-gen umsetzen, besonders interessant:� Single Source Publishing: Wiederver-wendbare Bausteinewerden in einer Daten-

bank abgelegt. Diese Bausteine erlaubenes, Dokumente flexibel zusammenzustellenund zeitnah zu publizieren.� Variantenmanagement: Bausteine, Grafi-ken und andere Medien wie Videos werdenklassifiziert und mit den entsprechendenMetadaten versehen. So können Redakteu-re einem Baustein einen Status zuweisen,zum Beispiel eine länderspezifische Zuord-nung. Eine zielgruppenorientierte Publika-tion ist so jederzeit möglich.� Versionsmanagement: Pro Sprint wirdeine Version generiert und archiviert, sodass zu jeder Zeit nachvollziehbar ist, wel-che Funktionen dokumentiert sind und anden Kunden geliefert wurden.Der Einsatz vonMetadatenbei Single Sour-

ce Publishing und Variantenmanagementerfordert ein Konzept, das alle Anforderun-gen an den Lebenszyklus von Dokumentati-onen oder anderen Inhalten abbildet. Solchein Konzept garantiert zudem den sicherenEinsatz von wiederverwendbaren Baustei-nen und den dazugehörigenMetadaten. Miteiner FilterfunktionkönnenSie zudem jeder-zeit einen aktuellen Draft publizieren. // FG

people text

Der Scrum-Prozess im Aufriss: Das Softwareprodukt entsteht iterativ. Dabei kann es jederzeit zu kurzfristigen Änderungen kommen, die berücksichtigt werdenmüssen. Die Zeit für ein Backlog-Item sollte so bemessen sein, dass die Redakteure diese Änderungen noch in ihre Dokumentation einarbeiten können.

Bild:peopletext

PRAXISWERT

Scrum hilft auch beider DokumentationDie Scrum-Methode bietet viele Vor-teile. Das gilt nicht nur für Entwick-ler während der Produktentstehung,sondern auch für Technische Redak-teure. Die gute Organisation der an-fallenden Aufgaben in Sprints undItems macht die Arbeit außerordent-lich transparent und gut planbar.

Aufwände erfassenVoraussetzung dafür ist allerdings,dass die Aufwände typischer Aufga-ben der Redakteure wie Informations-gespräche mit Entwicklern oder mitder Qualitätssicherung auch erfasstwerden. Für qualitativ hochwertigeDokumentations-Drafts zu Sprint-Ende helfen professionelle Redak-tionssysteme bei der Verwaltung derDokumentationen.

Quellen:[1] Baker, Mark: Toward an Agile Tech Comm, in:

intercom November/December 2014, Seite 25– 28

[2] Burkhardt, Remo Aslak, Informationsarchitek-tur, Januar 2008, DOI: 10.1007/978-3-540-69818-0_12 Source: OAI, https://www.research-gate.net/publication/36381063

[3] Gale, P. & Smith, K., Agile for Technical Commu-nication, in: intercom November/December2014, Seite 7-9

[4] http://agilemanifesto.org/iso/de/principles.html, (abgerufen 20.12.2016)

[5] International Standard ISO/IEC/IEEE26515:2012(E): Systems and software enginee-ring – Developing user documentation in anagile environment.

document8272924452375226005.indd 20 13.02.2017 11:49:59

https://www.research-gate.net/publication/36381063



http://agilemanifesto.org/iso/de/principles


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 97Redaktion München: Tel. (09 31) 4 18-Sebastian Gerstl (sg), ASIC, Entwicklungs-Tools, Mikrocontroller, Prozessoren,Programmierbare Logik, SOC, Tel. -30 98;Franz Graser (fg), Prozessor- und Softwarearchitekturen, Embedded Plattformen, Tel. -30 96;Martina Hafner (mh), Produktmanagerin Online, Tel. -30 82;Hendrik Härter (heh), Messtechnik, Testen, EMV, Medizintechnik, Laborarbeitsplätze,Displays, Optoelektronik, Embedded Software Engineering, Tel. -30 92;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

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

VERLAGVogel Business Media GmbH & Co. KG, Max-Planck-Straße 7/9, 97082 Würzburg,Postanschrift:Vogel Business Media GmbH & Co. KG, 97064 WürzburgTel. (09 31) 4 18-0, Fax (09 31) 4 18-28 43Beteiligungsverhältnisse: Vogel Business Media Verwaltungs GmbH,Kommanditistin: Vogel Medien GmbH & Co. KG, Max-Planck-Straße 7/9, 97082 WürzburgGeschäftsführung: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) 41 70-4 73, Fax -4 94,[email protected], www.datam-services.de.Erscheinungsweise: 24 Hefte im Jahr (plus Sonderhefte).

EDA

Verbreitete Auflage: 38.108 Exemplare (III/2016).Angeschlossen der Informationsgemeinschaft zur Feststellung der Verbreitung vonWerbeträ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

Spezial-Newsletterfür Elektronik-Profis

Tages- Wochen-

Beschaffung& SCM

Jobs &Karriere

Themen- Elektro-mobilität

document8001337076585209137.indd 21 13.02.2017 10:36:57

http://www.fed.de







http://www.datam-services.de


http://www.vogel.de

http://www.genios.de




http://www.vogel-europublishing.com

http://www.mycontentfactory.de

http://www.vogel.de

22

SOFTWAREPLATTFORMEN // ECHTZEITBETRIEBSSYSTEME


Im sicherheitskritischenUmfeld zuhause

Der Mainzer Softwarehersteller SYSGO hat als Hersteller von Betriebs-systemen für sicherheitsrelevante Anwendungen eine europäische

Erfolgsgeschichte geschrieben.

Der Mainzer Echtzeitsoftware-Spezia-list SYSGO blickt mittlerweile auf 25Jahre Unternehmensgeschichte zu-

rück. 1991 gegründet, fokussierte sich dasHaus zunächst auf die Anpassung von Be-triebssystemen an Hardwareplattformen.Ende der 90-er Jahre bildete das unixoideEchtzeitbetriebssystemLynxOSdesUS-Her-stellers LynxSoftware Technologies (vormalsLynuxWorks) denHauptumsatzträger für dieMainzer.Die Kompetenz, die sich SYSGO in diesem

Bereich erwarb, führte einesAbends im Jahr1999 zu einem Anruf des amerikanischenAvionikspezialistenRockwell Collin bei KnutDegen, demGründer desMainzerUnterneh-mens. SeinGesprächspartner kamohneUm-schweife zur Sache: „Wir habengehört, dassSie LynxOS-Spezialisten sind;wirmöchtenes gerne im Flugzeug nutzen und wirmöchten es gernenachdemStandardDO178 zertifizieren. Hätten Sie Interesse?"Degen war interessiert, aber auch

skeptisch: SYSGObesaßbereits aus derZusammenarbeitmit Airbus Erfahrungmit demSicherheitsstandardDO 178. Erhielt es jedoch für schwierig, ein relativumfangreichesBetriebssystemmit rund50.000Codezeilennachdemanspruchs-vollen Standard zertifizieren zu lassen.Der Interessent ließ jedoch nicht lo-

cker: „Das war eine schöne Situation füreinen Verkäufer – wenn der Kunde ver-sucht, einen zu überreden, dass man eswirklich schafft“, erinnert sich Degen.Schließlich kam der Auftrag, und im Zugedieser Aufgabe „haben wir sehr viel gelerntüber Avionik-Anforderungen: Es geht

letztendlich immer nur um Partitionierung,darum, dassman sichere und unsichere Sa-chen auf einem Rechner voneinander tren-nen kann. Bis dahin war es ja im Flugzeugso, dass jede Funktion ihren eigenenRechnerhatte.“

Airbus suchte dezidiert eineeuropäische LösungDer Auftrag erforderte 52Mannjahre. Dar-

aus resultierte die Erfahrung, dass es un-glaublich aufwendigwar, ein bereits vorhan-denesBetriebssystemandieAnforderungender Luftfahrtindustrie anzupassen. Und ein

Zweites: Der Markt der Betriebssysteme be-gann zu erodieren. „Wir haben gesehen, esgibt nur noch nach formalenMethoden ent-wickelte hochkritischeBetriebssystemeundLinux. Das war unsere Sicht auf den Marktzu dieser Zeit, und wir haben uns entspre-chend ausgerichtet.“Glücklicherweise wurde gerade in

Deutschland intensiv an Mikrokernel-Be-triebssystemen geforscht. Unter anderemwar die Forschungsarbeit von Professor Jo-chen Liedtke (1953 - 2001) an derUniversitätKarlsruhewegweisend. Die von ihmdesign-te L4-Kernelfamilie darf als geistigerVorfahrder PikeOS-Betriebssystemplattform vonSYSGOgelten, die ab 2000entwickeltwurde.VonAnfang an standbei der Entwicklung imVordergrund, die Software zertifizierbar zugestalten.2007 war die primäre Entwicklung abge-

schlossen. Allerdings hatte das Projekt diefinanziellenMöglichkeitendesMainzer Soft-warehauses aufs Äußerste strapaziert. Im-merhin erkannte der FlugzeugherstellerAirbus das Potenzial der Technologie undevaluierte den PikeOS-Hypervisor gegenzwei namhafte Konkurrenzprodukte ausden USA.„Airbus hat diese Technologie gesucht“,

erinnert sichKnutDegen. „Es ist schon einegroße Ehre, dass sozusagen einAlpha- oderBeta-Release von einem Betriebssystem inder Entwicklung gegen die beiden Großenevaluiert wird.“ Der europäische Flugzeug-bauer erteilte schließlichdenAuftrag. SYSGO

war jedoch „eigentlich pleite“. DieMit-arbeiter verzichtetendreiMonate

lang auf ihr Gehalt, dieBrückenfinanzierungwurde aus eigenenMit-teln gestemmt. „So ei-ne Erfahrung schweißtnatürlich auch zusam-men“, berichtet CEODegenüber diese span-nende Zeit. Späterzahlte sichdas Engage-ment der Mitarbeiter

Knut Degen, CEO des Main-zer Softwarehauses SYS-GO: Die Anstrengungenbei der Zertifizierung desEchtzeitbetriebssystemsLynxOS für die Luftfahrt ließden Entschluss reifen, aufMikrokernel und Hypervi-soren zu setzen.

Bild:SYSGO

document9045620002365859112.indd 22 13.02.2017 12:49:14


auch finanziell aus: Jeder der Kollegen, diedamals ihr Gehalt gestundet hatten, bekamdas Zwölffache zurück.Die Entscheidung von Airbus für die SYS-

GO-Plattformhatte neben technischen auchpolitischeGründe:Der Flugzeugbauer such-te nicht zuletzt eine europäische Lösung.Dieser Aspekt kommt den Mainzern nunauch imAutomotive-Bereich zugute,wo sichmittlerweile ähnliche Anforderungen etab-liert haben wie im Luftfahrtsegment. Auchdort ist die Konsolidierung der Steuergerätedas Thema der Stunde. Deshalb wird auchdort nachLösungen zur PartitionierungundSeparierung von kritischen und nichtkriti-schen Anwendungen gesucht.

Unabhängigkeit dank französi-schem Partner2012 stieg das französische Unternehmen

Thales als Investor ein.Derwichtige Zuliefe-rer für Airbus und Spezialist für Sicherheits-anwendungen–unter anderem fürKommu-nikations- und Bezahlsysteme – kannteSYSGO bereits und überlegte, das selbstentwickelte BetriebssystemdurchPikeOS zuersetzen.Die Franzosen stiegennicht zuletztdeshalb bei denMainzern ein, um sicherzu-stellen, dass die Technologie in Europa er-haltenbleibt. Unter denFittichen vonThaleshat sich der Softwerker seine Unabhängig-keitweitgehendbewahrt; das EingreifendesKonzerns beschränke sich laut SYSGO-CEODegendarauf, dassman sich viermal im Jahrbei der Aufsichtsratssitzung sehe: „Wir kön-nenweitermachenwie bisher, sindunabhän-gig,wasunsereGeschäfte angeht,wir habeneine stabile Basismit Thales undbekommenunser Wachstum finanziert.“Ein Vorteil des technischen Ansatzes der

Mainzerwar, dass PikeOS vonAnfang an alsHypervisor konzipiert wurde. „Wir habendiesenHypervisorweiterentwickelt, undderHypervisor, der für die Avionik zertifiziertwurde, ist exakt der gleiche, der für die Bahnzertifiziertwird und ist auchder gleiche, derjetzt in die Sicherheitszertifizierzung beimBSI (Bundesamt für Sicherheit in der Infor-mationstechnik) geht. Wir haben nicht un-terschiedliche Produkte und nennen diedann nur PikeOS, es ist immer der gleicheKern.“ Echtzeitbetriebssysteme, die in denachtziger Jahren entstanden sind, musstenlaut Degen dagegen oft mühsam für andereAnwendungszwecke modifiziert werden.„Wir haben es einfacher gehabt,weilwir spä-ter angefangenhaben;wir haben einfachnurvomHypervisor nach oben gebaut.“Mittlerweile ist das SYSGO-Betriebssystem

für viele Hardwareplattformen erhältlich,von der Power-PC-Plattform über x86 und

ARM bis hin zur Sparc-Architektur, die vonSun Microsystems entwickelt worden war.Ein Sparc-Derivat namens LEON wird bei-spielsweise in Satelliten eingesetzt, da dieseHardware eine hohe Strahlungsresistenzaufweist, die unter den gnadenlosen Bedin-gungen desWeltraums unabdingbar ist.

„Sobald es um Sicherheit geht,sind wir im Spiel“Wer mit einem Airbus A350 fliegt, ist mit

der Software aus Mainz unterwegs, darüberhinaus sind mittlerweile auch schon einigeSerien-Automobile mit PikeOS ausgestattet.Was aber das allgegenwärtige Buzzword In-ternet of Things betrifft: In den Endgeräten,die zukünftigmilliardenfach ansNetz ange-schlossen sein werden, sieht CEO Knut De-gendie Softwareplattformnicht: „Ich glaubenicht, dasswir in denTemperaturfühlernderHeizung drin sind Aber dann kommt derStromzähler. Der arme Stromzähler hat dreiFeinde: den Benutzer, der natürlich gerneseine Stromkosten reduzieren möchte unddasGerät hackenwill, danndie Stromanbie-ter, denen man vielleicht auch nicht trautund zuletzt die Hacker, die das als Interfacenehmen. Das Gerät muss hoch sicherheits-kritisch sein. Sobald es also um Sicherheitgeht – im Sinne von Safety und Security –sind wir im Spiel.“DieHypervisor-Technik zwingedieGeräte-

hersteller zudem,die Sicherheitsanforderun-gen zu strukturieren: „In einem klassischenBetriebssystem ist das alles ein Brei. Da ist

SOFTWAREPLATTFORMEN // ECHTZEITBETRIEBSSYSTEME

23

alles in einem Prozess drin oder wird voneinemKernel gemanagt. Allein schon zu sa-gen: "Dumusst das aufmehrere Partitionenverteilen", zwingt dieArchitektendazu, sichüber die Sicherheit Gedanken zumachen.“Darüber hinaus kann sich Degen vorstel-

len, dass die ErfahrungenausdemVolkswa-gen-Skandal dazu führen, auf Steuergerätemit mehreren Partitionen zurückzugreifen:„Heute ist es ja so, dass der Tier-One-Zulie-ferer für jedenOEMdie Customization selberübernimmt –mit demEffekt, dasswenn derOEMMist baut, auch der Tier One im Kreuz-feuer steht.“ Künftig könnte die Lösung soaussehen: Der Tier-One-Zulieferer könntedem Automobilhersteller das Gerät mit derGrundfunktionalität zur Verfügung stellen,die sich in der einen Partition befindet. Inder zweiten Partition befindet sich die vomAutohersteller entwickelte Steuerlogik. Bei-de können miteinander kommunizieren,aber die vomZulieferer entwickelte Funktio-nalität ist von der des OEM klar getrennt.Insgesamt hat SYSGO eine deutsche, aber

mehr noch, eine europäische Erfolgsge-schichte imBereichder Embedded-Softwaregeschrieben – auch deshalb, weil Airbus alsEarlyAdopter dasPotenzial der Technik früh-zeitig erkannt hatte. Das Ziel für die kom-menden Jahrehat CEOKnutDegenauf jedenFall klar vor Augen: „Unser Ziel ist es, dasswir 2020dieNummer-1-Alternative zu ameri-kanischen Anbietern sind.“ // FG

SYSGO

Der erste Airbus A350 der Lufthansa: Der Neuzugang der Langstreckenflotte der deutschen Airline fliegt mitPikeOS von SYSGO.

Bild:O

liverRoesler/Lufth

ansa

document9045620002365859112.indd 23 13.02.2017 12:49:17

24

SYSTEMDESIGN // FUNKTIONALE SICHERHEIT


Ein Ansatz für ein modernesfunktionales Sicherheitskonzept

Kann ein nicht-zertifizierter SoC in einer Sicherheitsanwendung zumEinsatz kommen? Der Beitrag deckt wichtige Architektur- und Design-

Abwägungen moderner Sicherheitseinrichtungen ab.

PETER HOOGENBOOM *

* Peter Hoogenboom...ist als EMEA Engineering Managerbei Green Hills Software mit Sitz inden Niederlanden tätig.

Sicherheit wird definiert als die Gewiss-heit, vor inakzeptablen Risiken wieKörperverletzungoderGesundheitsbe-

einträchtigungen entweder direkt oder indi-rekt infolge von Sach- oder Umweltschädengeschützt zu sein [1]. Funktionale Sicherheitist Teil der Gesamtsicherheit, die von einemSystem abhängig ist, das eine Sicherheits-funktion als Reaktion auf seine Eingabenausführt. Beispiele für Sicherheitssystemeund die entsprechenden Sicherheitsfunk-tionen in der Automobilelektronik sind eineWarnanzeige auf einem Grafikdisplay einesInstrumenten-Clusters und ein Fahrerassis-tenzsystem (ADAS).

Funktionale Sicherheit basiert auf zweiSäulen: Fehlervermeidung und Fehlerkon-trolle. Die Fehlervermeidung handhabt sys-tematische Fehler, die durch Fehler verur-sachtwerden, die vor der Systeminstallationentstehen. Diese werden durch Standardsabgedeckt, indem ein Off-Target-Entwick-lungsprozess spezifiziert wird. Das entspre-chende Zertifikat ist der Nachweis, dass dasSicherheitselement für denEinsatz geeignetund frei von systematischenFehlern ist. Diesist jedoch nur die eine Seite der Medaille.Die Fehlerkontrolle ist die andere Seite

und muss sich sowohl mit systematischenHardwarefehlern (Hard-Errors, defekterHardware) als auch mit zufälligen Hard-warefehlern (Soft-Errors, z.B. temporäre Bit-Wechsel aufgrund von Strahlung) befassen.Beide werden durch Fehler verursacht, dienach der Systeminstallation entstehen undvon der Hardware und Software im Zielsys-

tem (Target) adressiert werden müssen. DieStandards beschreibenDiagnostik undTech-niken, die angewendet werden sollen.Tabelle 1 (S. 26) listet eine Reihe von Tech-

niken auf, einschließlich der entsprechen-den Diagnose-Abdeckung: Niedrig (60 Pro-zent), Mittel (90 Prozent) oder Hoch (>= 99Prozent). Je höher die erforderliche Sicher-heitsintegritätsstufe (SIL, Safety IntegrityLevel; ASIL für ISO26262), desto strenger istder Entwicklungsprozess (Fehlervermei-dung) und die Diagnoseabdeckung (Fehler-kontrolle) durchzuführenbzw. anzuwenden.

Trends bei Geräten, Einrichtun-gen und SystemenSoftware wird immer mehr zum Unter-

scheidungsmerkmal eines Produkts. Sie istoft weniger teuer als Hardware, erlaubt es,mehr Funktionen in einer flexibleren undskalierbarenWeise hinzuzufügenund ist oftdie erste sichtbareBenutzerschnittstelle. ImAutomotive-Bereich zeigt sich noch einwei-terer Trend: Konsolidierung. In einer Super-ECU werden eine Reihe kleiner ECUs (elek-tronische Steuergeräte) zusammengefasst.Der (sicherheitskritische) Instrumenten-Clusterwirdmit dem (nicht-sicherheitsbezo-genen) Infotainment-System kombiniert.Beide Trends erfordern leistungsfähige,mo-derne Multicore-SoCs (System-on-Chip).In derVergangenheit konntenur das kom-

plette Systembzw. Gerät zertifiziert werden.Mit den aktuellen Sicherheitsnormen [1], [2]und [3] ist esmöglich, eine Komponentewieeine CPU (Hardware) oder ein Echtzeit-Be-triebssystem (RTOS, Software) zu zertifizie-ren. Die ISO 26262 nennt dies ein Safety Ele-ment out of Context (SEooC). Der Entwicklerder Sicherheitseinrichtungkann sich auf denBewertungsbericht der gekauften Kompo-nente beziehen und nachweisen, dass dasSicherheitshandbuch des SEooC erfüllt ist.Die IEC 61508 schreibt Störungsfreiheit in

Bezug auf die „Unabhängigkeit der Ausfüh-rung“ zwischenSoftware-Elementen vor, die

Funktionale Sicherheit: Für die Betriebssicherheit gibt es zahllose Normen und Richtlinien. Die Zertifizie-rung von Softwareprodukten nach diesen Normen ist in der Regel ein aufwendiger Prozess.

Bild:G

reen

Hills

Softw

are

document822713994136742023.indd 24 13.02.2017 10:26:08



auf einem einzigen Computersystem gehos-tet sind. Der Begriff „Unabhängigkeit derAusführung“ bedeutet, dass Elemente dasAusführungsverhalten anderer Elementenicht nachteilig beeinflussen, so dass einpotenziell gefährliches Versagen auftretenwürde. DieUnabhängigkeit der Ausführungsoll sowohl auf räumlicher als auch zeitlicherEbene erreicht und nachgewiesen werden.All dies kann durch einen zertifizierten Se-parationskernel erreicht werden, wie etwadas INTEGRITY RTOS von Green Hills Soft-ware.Die Vorteile dieser Trennung sind vielfäl-

tig: nicht-kritische und kritische Software-Partitionen könnennebeneinander auf demgleichen System laufen. Damit erübrigt sichdie erneute Zertifizierung des Systems/Ge-räts, wenn nicht-kritische Partitionen aktu-alisiertwerden. Zusätzlich können standard-mäßige (nicht zertifizierte) Kommunikations-Stacks (TCP/IP, CAN) aus nicht-kritischenPartitionen betrieben und Daten über einen„grauen Kanal“ an eine Sicherheitsanwen-dung in einer kritischenPartitionübergebenwerden. Letztere führt alle erforderlichenSicherheitsüberprüfungendes verwendetenSicherheitsprotokolls durch (End-to-End-Schutz vom Sensor bis zum Computer). Da-mit muss weniger Software zertifiziert wer-den, was die Entwicklungskosten erheblichverringert, ohne das erforderliche Sicher-heitsniveau zu beeinträchtigen.

Halbleitertrends und zuneh-mende Soft-ErrorsIn den 1980er Jahren waren CPU-Kerne

relativ einfach aufgebaut. Die höchsteWahr-scheinlichkeit eines Soft-Errors lag imexter-nen Speicher. Moderne SoCs verfügen übererheblich mehr Logik auf ihrem Chip: n-stufige Pipeline, intelligente Crossbars,Caches, TLBs für die MMU etc. Dies erhöhtdasRisiko eines Soft-Errors in der komplexenLogik, der nur schwer zu erkennen und zukorrigieren ist. Durch die höhere Dichte derProzessknoten (<65nm [1]), niedrigere Span-nungen (<1,8 V [1]) und höhere Taktratennimmt die Wahrscheinlichkeit von Soft-Er-rors weiter zu.Für dieAnwendungvonHalbleiterbaustei-

nen in Sicherheitsanwendungen zeigen sichdrei Trends: 1) spezielle sicherheitszertifizier-te CPUs (Hardware Lock-Step-Technologie);2) reguläre, nicht-zertifizierteMulticore-SoCsund 3) eine Mischung aus 1 und 2.

Zertifizierte Hardware: Lock-Step MCUBei der Hardware-Lock-Step-Technik re-

pliziert spezielles Silizium die Cores (und

optional andereKomponentenwie dieMMUund den Interrupt-Controller). Dabei syn-chronisiert dieHardware die nachgebildetenKomponenten ständig und überprüft derenÜbereinstimmung. Diese Art von MCUs [4][5] stimmthäufig auchmit denobengenann-ten Bedingungen wie 65-nm-Technologie,mindestens 1,8VundeinermaximalenTakt-frequenz von einigenhundertMHzundASIL-D-Einhaltung überein. Aus Sicht der Soft-ware (RTOS Scheduling) ist diese Art vonMCU dann mit einem einzigen Core ausge-stattet.

Nicht-zertifizierter Highend-SoCAmanderenEndedes Spektrums steht z.B.

einCortex-A57 [6] in 14- bis 28-nm-Technolo-gie zur Verfügung. Er bietet eine 15-stufigePipeline, eineOut-of-Order-Ausführung, einezweistufige Branch-Prediction undwirdmiteiner Taktfrequenz von >1GHzbetrieben.Wirwissen, dass Soft-Errors auftreten werden.Entscheidend ist: KanndieseArt komplexer,nicht-zertifizierter SoCs [6] [7] in Sicherheits-systemen eingesetzt werden? Die Antwortlautet: ja, solange der Baustein die in denStandards festgelegten Fehlerkontrollmaß-nahmen anwendet.In der Praxis bedeutet dies eine begrenzte

Menge an zusätzlicher Hardware und einebeträchtlicheMenge an zusätzlicher Sicher-heitssoftware, umdiese Techniken zu imple-mentieren. Da diese Sicherheitsebene freivon systematischenFehlern sein sollte,musssie bezüglichdes erforderlichen (A)SIL-Stan-dards zertifiziert bzw. bewertet werden.Für ASIL C und D ist eine hohe diagnosti-

sche Abdeckung erforderlich. Betrachtetman die nachstehende Tabelle, stellt manfest, dass der traditionelle „Hardwaretest“-Ansatz nur eine mittlere diagnostische Ab-deckungaufweist. EinRAM-Test (Zeile 13) istauf die Erkennung defekter RAM-Zellen be-schränkt, erkennt aber keine Soft-Errors. DasGleiche gilt für den Selbsttest der HardwareundSoftware (Zeile 9, 10). AufgrundderKom-plexität der heutigen SoCs ist sogar eine ge-ringediagnostischeAbdeckung zu erwarten.Eine zertifizierte Sicherheitsebene, die ei-

ne hohe diagnostische Abdeckung wie Zeit-überwachung, Terminüberwachung, Se-quenzanzeige (Zeile 3), sichere Speicherung(Zeilen4.1, 5), unveränderlicherRAM-Schutz,MMU-Seitentabellenprüfung (Zeile 4.2), si-chere Interprozess-Kommunikation (Zeile6.6) bietet, ist für denEntwickler, dermit derSicherheit betraut ist, besonders hilfreich.Auf der Treiberebene muss das Safety

Board Support Package die Sicherheitsinte-gritätsfunktionenauf unterer Ebeneundden

www.vogel.de

1173

11737

Halle 3AStand 417

Besuchen Sie unsauf der

embedded world:

www.elektronikpraxis.de

WIR

ZURÜCK!SIND

document822713994136742023.indd 25 13.02.2017 10:26:12

http://www.vogel.de


26



Konfigurationsregistertest (Zeile 12) imple-mentieren.

Im Gleichschritt: Software Lock-StepEine zertifizierte Sicherheitsebene, die für

den Betrieb auf einem Multicore-SoC geeig-net ist, kann die Sicherheitsalgorithmenparallel auf mehreren Cores ausführen. Da-beiwerdendie Zwischenergebnisse automa-tisch überprüft, wenn ein Core seinen Syn-chronisationspunkt erreicht hat. Dieser Ab-laufwird Software Lock-Step genannt und isteine äußerst leistungsfähige (HighCoverage)Technik zumErkennenvonSoft-Errors (Zeile11). Die Compiler-Technologie kann dabeihelfen, verschiedene (A/B)Anweisungen fürdenselben zertifizierten Sicherheitsalgorith-mus zugenerieren, der in Software Lock-Stepausgeführtwird.Dadurch verringert sichdasRisiko möglicher systematischer Hard-warefehler im Core.

Reguläre homogene Multicore-CPUs wer-den durch das RTOS (Scheduling) ebenfallsals Multicore behandelt, wobei mehrereTasks gleichzeitig auf verschiedenen Coresausgeführtwerden (symmetrischesMultipro-cessing, SMP). Bezüglich der Störfreiheitzwischen kritischen und nicht-kritischenSoftware-Partitionenmuss eineneueDimen-sion berücksichtigt werden: die Cores. Sieteilen sich Ressourcenwie Crossbars, Cacheund Speicher, könnten sich also gegenseitigstören. Das heißt, die zertifizierte Software(Separationskernel, Sicherheitsebene)mussdie Störfreiheit der Cores garantieren undtrotzdem Soft-Errorsmit hoher Diagnoseab-deckung (mittels Software Lock-Step) erken-nen.

Einsatz nicht-zertifzierter SoCsin einem SicherheitssystemBei der Entwicklung eines Sicherheitssys-

tems auf Basis störfreier Software-Partitio-

nen ist ein zertifizierter Separationskernelerforderlich. Kommt zusätzlich noch einezertifizierte Sicherheitsebene zum Einsatz,die alle erforderlichen diagnostischen Ab-decktechnikenunterstützt, kann einmoder-ner, nicht-zertifizierter Multicore-SoC ver-wendet werden. // FG

Green Hills Software

Literaturhinweise:[1] IEC 61508:2010, Functional safety of electrical/

electronic/programmable electronic safety-related systems, Parts 1-7

[2] EN 50128:2011, Railway Applications - Commu-nications, Signalling and Processing Systems- Software for Railway Control and ProtectionSystems

[3] ISO 26262:2011, Road Vehicles – FunctionalSafety, Part 1-10

[4] Renesas’ RH850-Familie[5] Infineons AURIX-Familie[6] Cortex-A57 – https://en.wikipedia.org/wiki/

Comparison_of_ARMv8-A_cores[7] Intels Denverton-Familie

# TECHNIK/METHODE/TEST ISO-26262-ABSCHNITT

ANNEX IEC- 61508-ABSCHNITT

ANNEX DIAGN.ABDECKUNG

1 Watchdog mit separater Zeitbasis und Zeitfenster 5 D.2.9.2 7 A.9.2 Mittel

2 Überwachung des logischen Programmflusses 5 D.2.9.3 37

7.4.2.7A.9.3

Mittel

3 Kombination der zeitlichen und logischen Überwachungdes Programmablaufes

5 D.2.9.4 7 A.9.4 Hoch

4 Erkennung von Informationsänderungen im unveränderlichenSpeicher

5 D.2.4 7 A.4

4.1 Blocknachbildung 5 D.2.4.4 7 A.4.5 Hoch

4.2 Speichersignaturen auf Blöcken 5 D.2.4.3 7 A.4.4 Hoch

5 Erkennen von Fehlern beim Adressieren, Schreiben, Speichernund Auslesen des variablen Speichers

5 D.2.5 7 A.5 Niedrig – Hoch

6 Erkennen von Ausfällen in der Informationsübertragung 5 D.2.7 7 A.7

6.1 Vollständige Hardware-Redundanz 5 D.2.7.3 7 A.7.3 Hoch

6.2 Übertragungsredundanz 5 D.2.7.5 7 A.7.5 Mittel

6.3 Informationsredundanz 5 D.2.7.6

6.4 Frame-Zähler 5 D.2.7.7 Mittel

6.5 Timeout-Überwachung 5 D.2.7.8 Mittel

6.6 Kombination aus Informationsredundanz, Frame-Zähler undTimeout-Überwachung

5 D.2.7.6,D.2.7.7,D.2.7.8

Hoch

7 Stapel-Over-/Under-Flow-Erkennung 5 D.2.3.8 7 C.2.6.4 Niedrig

8 Integrierte Hardware-Konsistenzüberwachung 5 D.2.3.9 Hoch

9 Selbsttest durch Software 5 D.2.3.1 7 A.3.2 Mittel

10 Selbsttest unterstützt durch Hardware 5 D.2.3.2 7 A.3.3 Mittel

11 HW-Redundanz (z.B. Dual-Core) 5 D.2.3.6 7 A.2.5 Hoch

12 Konfigurationsregistertest 5 D.2.3.7 Hoch

13 RAM-Musterprüfung 5 D.2.5.1 7 A.5.1/3/4 Mittel

Tabelle 1: Beispiel-Techniken/Methoden/Tests für eine höhere diagnostische Abdeckung [1] [2]

document822713994136742023.indd 26 13.02.2017 10:26:14

https://en.wikipedia.org/wiki/

Begeben Sie sich auf Zeitreise!In diesem Jahr feiert ELEKTRONIKPRAXIS 50. Geburtstag. Aus diesem Anlass berichten wirin jeder Heftausgabe bis Frühjahr 2017 und online auf der Meilensteine-Webseite über dieführenden Unternehmen der Elektronikbranche. Was waren ihre wichtigsten Leistungen,wo stehen die Unternehmen heute und wie sehen die Pioniere der Elektronik die Zukunft?

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

Analog

RTOS & Tools

Verbindungstechnik

Power Management

Embedded

Passive Bauelemente

Elektronik-Händler

Messen & Veranstaltungen

Distribution

Labormesstechnik

Begeben Sie sich auf Zeitreise!

Schaltschränke/Klimatisierung

Displays Stromversorgungen

Messen Steuern Regeln

HF-Messtechnik LED/Lighting

EMS

EDA

Eine Serie von

Mikrocontroller

1105

0

Relais

11050_ANZ_EP_Meilensteine_der_Elektronik_MATRIX_210x297_12.indd 1 19.01.2016 10:08:53

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

Halle4, Sta

nd325

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

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

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

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

Documents

Embedded Software Engineering - Vogelfiles.vogel.de/vogelonline/vogelonline/issues/ep/2017/...Portalembedded-software-enginee-ring.debietetEntwicklernaktuelle EinblickeindieSoftwarewelt