Embedded Software Engineeringfiles.vogel.de/vogelonline/vogelonline/issues/ep/2016/642.pdf · ©ARM Ltd |AD468 i.MX7 ARMCortex-A7 ARMCortex-M4 Linux kernel RTOS system Linux application

Wissen.Impulse.Kontakte. Dezember 2016

Entwicklung und Zertifizierungdeutlich vereinfachtPikeOS von SYSGO ermöglicht die Entwicklung sicherheitszertifizierter Anwendungen aufeiner einzigen gemeinsamen Hardware-Plattform.

User ExperienceDesign und agileMethodenWie sich Scrum mit dem De-sign grafischer Oberflächenkombinieren lässt. Seite 14

IoT-Sicherheitmuss auf VertrauenbasierenGerätesoftware im IoTbedarf einer mehrstufigenSicherheitsstrategie.Seite 18

So sieht zukunfts-fähige Embedded-Entwicklung ausMulticore, Architekturdesignund Agilität kommen aufdie Teams zu. Seite 24

EMBEDDED SOFTWARE ENGINEERING

www.elektronikpraxis.de

Sponsored by

document4214446086628791133.indd 1 15.11.2016 09:46:45

http://www.elektronikpraxis.de

160830_BURST_EP_DE.indd 1 8/26/16 1:04 PM

3

EDITORIAL

ELEKTRONIKPRAXIS Embedded Software Engineering November 2016

Es gibt kein Allheilmittel für dieSicherheit im Internet of Things

Wennman aufMessen geht, sindmanchmal nicht so sehr die aus-gestellten Exponate entschei-dend, sonderndieMenschen, denenmanbegegnet. So ging es mir auf der diesjäh-rigen electronica mit Yossi. Mit vollemNamen heißt er Yossi Har-Nov, und er istVice President of Engineering eines Em-bedded-Board-Herstellers mit Sitz in Flo-rida und in Israel.Ich lernte Yossiwährendder Embedded

Platforms Conference, der Begleitkonfe-renz zur electronica, kennen, und es ergabsich, dasswir uns amTag nach demKon-ferenz-Track noch einmal zum Essen tra-fen. Tags zuvor hatte er einenVortrag zumThema IoT-Security gehalten, der beimPublikum sehr gut ankam. Als wir denVortrag Revue passieren ließen, sagteYossi, dass er sich bewusst nicht als Se-curity-Experte sehe.AufmeineNachfrageerläuterte er, das ThemaSecurity habe soviele Facetten, vondenenmannur einigewenige komplett überschauen könne.Das ergab Sinn. Yossi hatte in seinem

Vortrag unter anderem über Safe-Boot-Techniken und über die TrustZone-Tech-nikmodernerARM-Chips referiert – zwei-felloswichtigeAspekte, die aber ebennurTeile der Problematik beleuchten.

„Auch wenn eine Sicher-heitslücke gestopft wird:Meist gibt es noch eineweitere unentdeckteHintertür“

Franz Graser, [email protected]

Werdas ThemaSecurity imZusammen-hang mit dem Internet der Dinge ernstnimmt, kann deshalb nicht umhin, sichmit dem kompletten Problem auseinan-derzusetzen. Unser Artikel zum Thema„Sicherheit von IoT-Geräten“ auf Seite 18versucht, Ihnen denUmfang der Angele-genheit näherzubringen. Denn der großeDenial-of-Service-Angriff auf namhafteUS-Internetdienste vom Oktober 2016 er-folgte mit Hilfe von Tausenden von ver-netztenGeräten, darunter digitaleVideo-rekorder, die über undokumentierteUser-Schnittstellen gekapert werden konnten.Und auch wenn eine Lücke gestopft wur-de – es gibt in der Regel immer noch eineHintertür. Seien Sie daher skeptisch,wenn Ihnen eine Lösung versprochenwird, die angeblich alle Sicherheitspro-bleme löst. Vertrauen Sie lieber auf einenmehrschichtigen Ansatz.

Herzlichst, Ihr

Entwicklungslösungfür heterogene

Systeme

MDK-Professional unterstützt jetztauch die Softwareentwicklung fürheterogene Systeme:

• Bare-Metal Cortex-M Debug

• RTOS Awareness

• Debug des Linux Kernels

• Debug von Linux Applikationen

• CMSIS-Pack Support

• Unterstützt NXP i.MX6und i.MX7

© ARM Ltd | AD468

i.MX7ARM Cortex-A7ARM Cortex-M4

Linuxkernel

RTOSsystem

Linuxapplication

Bare-metalapplication

Cortex-A Cortex-M

www.keil.com/ds-mdk

document3188122269189591181.indd 3 16.11.2016 12:53:28

mailto:[email protected]://www.keil.com/ds-mdk

4 ELEKTRONIKPRAXIS Embedded Software Engineering November 2016

SCHWERPUNKTEEchtzeitbetriebssystemeTITELTHEMA

9 Entwicklung und Zertifizierung deutlich vereinfachtDas Echtzeitbetriebssystem (RTOS) und Virtualisierungs-system PikeOS ermöglicht die Entwicklung und den Betriebsicherheitszertifizierter Anwendungen auf einer gemeinsa-men Hardware-Plattform.

Softwarekomponenten12 Die richtige Wahl des OS für die Zugsteuerung

Auf den Eisenbahnstrecken in der EU kommt es jeden zwei-ten Tag zu einer Kollision oder Entgleisung. ZuverlässigeSoftwaresysteme können diese Rate senken. Der Wahl desSystems kommt daher hohe Bedeutung zu.

Implementierung14 User Experience Design in der agilen Entwicklung

In der Software User Experience kommen iterative Prozes-se zum Einsatz: Dieser Artikel beleuchtet Möglichkeiten,Software User Experience mit dem agilen VorgehensmodellScrum zu kombinieren.

Security18 Sicherheit von IoT-Geräten basiert auf Vertrauen

Der Denial-of-Service-Angriff auf namhafte Internetdienstevom Oktober 2016 wirft Fragen nach der Sicherheit vonIoT-Geräten auf. Am effektivsten ist eine mehrschichtigeStrategie.

Implementierung20 Multiplattform-Entwicklung mit dem Qt-Framework

Plattformunabhängigkeit wird in zunehmendem Maße vonAnwendungen gefordert. Das C++-Framework Qt erlaubtes, Applikationen zu entwickeln, die gleichermaßen unterWindows und Linux laufen.

Projektwissen24 So sieht zeitgemäße Embedded-Softwareentwick-

lung ausDie Experten von MicroConsult diskutieren die Bedeutungvon Softwarearchitekturen und Frameworks. Dabei wirddas Thema Software Engineering aus verschiedenen Blick-winkeln beleuchtet.

RUBRIKEN3 Editorial

6 Aktuelles

23 Impressum

INHALT

ECHTZEITBETRIEBSSYSTEME

Entwicklung undZertifizierung deutlichvereinfachtFahrerassistenzsysteme und autonomes Fahrenstellen völlig neue Anforderungen an die Entwick-lung elektronischer Systeme und Anwendungen fürAutomobile. Hersteller streben nach Konsolidierungvon Hard- und Software-Plattformen, müssen aberkritische Anwendungen strikt von angreifbaren tren-nen. PikeOS von SYSGO stellt eine Umgebung zurVerfügung, die eine solche Trennung gewährleistetund die sich in der Luftfahrtindustrie mit ihrenhohen Sicherheitsanforderungen bewährt hat.

8

document8709939533262513534.indd 4 16.11.2016 14:16:45

160811_WYN_EP_DE.indd 1 8/10/16 2:17 PM

6

AKTUELLES // TECHNIK UND ETHIK


Die Frage nach der Ethikim autonomen FahrzeugDie Entwicklung autonomer Fahrzeuge hat schwerwiegende ethischeund rechtliche Konsequenzen. Als einer von wenigen Philosophen be-

fasst sich Professor Julian Nida-Rümelin mit diesem Thema.

Entwickler und Konstrukteure autono-mer Fahrzeuge stehen vor einemschwierigen Problem: Was passiert,wennein sich selbst steuerndesVehikel einerGefahrenquelle ausweicht, etwa einemKin-derwagen, der in die Straße rollt, und da-durch andereVerkehrsteilnehmer gefährdet?Menschliche Autofahrer, die mit einer sol-chen Situation konfrontiert sind, reagiereninstinktiv. Sollen aber autonomeSysteme soprogrammiert werden, dass sie eine Abwä-gung vornehmen, ob etwa ein Kind oder einälterer Verkehrsteilnehmer verletzt odereventuell getötet werden?Als einer der wenigen Vertreter seines Fa-

cheshat sichder Philosophieprofessor JulianNida-Rümelin, der anderMünchner Ludwig-Maximilians-Universität lehrt, mit solchenFragen imGrenzbereich zwischenEthikundTechnik beschäftigt. Aus seiner Sicht verbie-ten es Recht und Ethik, Menschenleben ge-geneinander aufzurechnen.DerArtikel 1 desGrundgesetzes, der dieWürdedesMenschenin denVordergrund stellt, untersagt die Ver-letzung dieser Würde auch dann, wenn da-durch andere Menschenleben gerettet wer-den könnten.

Weder Justiz noch Technikhaben klare AntwortenIn einem Interview mit der ZDF-Sendung

„Aspekte“ illustrierte Nida-Rümelin diesesDilemma an einemBeispiel: Ein schwer ver-letzter Motorradfahrer, der in ein Kranken-haus eingeliefertwird, könntemöglicherwei-se alsOrganspendermehrerenMenschendasLeben retten. Dennoch sei es unethisch,diesenVerletzten zuTode zubringen. ImGe-genteilmüssemanalles dafür tun, das Lebendes Motorradfahrers zu erhalten.In dem Interview gab Nida-Rümelin, der

am 1. Dezember beim ESE Kongress in Sin-delfingendie Keynote zumThema „Philoso-phie trifft Elektronik: Menschliche Verant-wortung und technologische Praxis“ hielt,auch zu, dass weder die Philosophie nochdieRechtswissenschaft nochdie Technik aufdieses Dilemma eine klare und schlüssige

Antwort besäßen. Falls es jedoch soweitkommen sollte, dass in autonomeFahrzeugederartige Entscheidungsmechanismen ein-gebautwürden,müsstendieseKriterien aberoffengelegtwerden.DennKäufer oder Benut-zer solcher Fahrzeuge müssten über dieseEntscheidungsmechanismen informiertsein. Er forderte daher die Gesellschaft auf,sich dieser Debatte zu stellen.Zusammenfassend sprach sich der Philo-

sophieprofessor in dem„Aspekte“-Interviewdafür aus, den menschlichen Fahrer selbst-verständlich in jeder Formdurch technischeSysteme zu unterstützen, um ihm seine Auf-gabe zu erleichtern. Vongänzlich autonomenFahrzeugen riet er jedoch ab.Bereits imvergangenen Jahr hatte die ESE-

Keynote der JuristinDr. Elke LuiseBarnstedt,der früheren Direktorin des Bundesverfas-sungsgerichts, dieVerantwortlichkeit inWis-senschaft und Technik thematisiert. Barn-stedt hatte unter anderem im Zusammen-hangmit demVW-Abgasskandal die Einhal-tung ethischer Leitlinien in technischenUnternehmen angemahnt. // FG

www.ese-kongress.de

Professor Dr. Julian Nida-Rümelin: Der Philosophieprofessor der LMU München hat sich intensiv mit denethischen Problemen des autonomen Fahrens befasst.

Bild:A

ndreas

MüllerFotografie

Mün

chen

Biografie von JulianNida-RümelinJulian Nida-Rümelin gehört nebenJürgen Habermas und Peter Sloterdijkzu den renommiertesten Philosophenin Deutschland. Er studierte Philoso-phie, Physik, Mathematik und Politik-wissenschaft, wurde in Philosophiepromoviert, war dann wissenschaftli-cher Assistent in München und habi-litierte dort 1989. Nach einer Gastpro-fessur in den USA übernahm er einenLehrstuhl für Ethik in den Bio-Wissen-schaften an der Universität Tübingen,dann für Philosophie an der Universi-tät Göttingen. Anschließend folgte ereinem Ruf an das Geschwister-Scholl-Institut für Politikwissenschaft derLudwig-Maximilians-Universität Mün-chen, dessen Direktor er von 2004 bis2007 war. Von 2001 bis 2002 war erzudem Kulturstaatsminister im Kabi-nett von Gerhard Schröder.

document6747077342574678452.indd 6 16.11.2016 14:16:28

http://www.ese-kongress.de

Rückblick 2016 und Newsletter unter: www.ese-kongress.de

Hauptsponsoren 2016 Veranstalter

Der Embedded SoftwareEngineering Kongress 2017:

4. bis 8. Dezember

Sehen wir uns?

ESE Kongress – Ideen entwickeln, Profis treffen, Lösungen finden.Der Embedded Software Engineering Kongress mit über 1100 Teilnehmern ist die größte deutschsprachige Veranstaltung,die sich ausschließlich der Entwicklung von Geräte-, Steuerungs-, und Systemsoftware für Industrie, Kfz, Telekom sowieConsumer- und Medizintechnik widmet. Vom 4. bis 8. Dezember trifft sich die Embedded-Software-Branche wieder inSindelfingen – wir freuen uns auf Sie!

Danke an alle Aussteller und Sponsoren 2016:AdaCore, agosense, aicas, ARM, Avnet Silica, Axivion, bbv Software Services, Eclipseina, ELEKTRONIKPRAXIS,Embedded Tools, Embedded Wizard, emmtrix Technologies, emtrion, EVOCEAN, Express Logic, froglogic, GreenHills Software, Hitex, IAR Systems, IBM, IMACS, Infineon Technologies, iSyst Intelligente Systeme, iSYSTEM,Lauterbach, LieberLieberSoftware, linutronix, Logic Technology, Luxoft,MathWorks,MentorGraphics,MicroConsult,MicroSys, Model Engineering Solutions, oose Inovative Informatik, Parasoft, PikeTec, PLS Programmierbare Logik &Systeme, PROTOS, QA Systems, QNX Software Systems, Razorcat Development, Renesas Electronics, RST IndustrieAutomation, RTI Real-Time Innovations, SMDS /Universität Augsburg, Synopsys, SYSGO, Tasking, Vector Software,Verifysoft Technology, Verum, Willert Software Tools, WITTENSTEIN, XiSys Software

20174. bis 8.12.2017 in Sindelfingen

11118

10JAHRE

11118_ANZ_OMI_ESE_Kongress_2017_Tagungsband_210x297.indd 111118_ANZ_OMI_ESE_Kongress_2017_Tagungsband_210x297.indd 1 10.11.2016 11:42:4610.11.2016 11:42:46

http://www.ese-kongress.de


TITELSTORY // ECHTZEITBETRIEBSSYSTEME

8

TITELSTORYFahrerassistenzsysteme und autono-mes Fahren stellen völlig neue Anfor-derungen an die Entwicklung elektro-nischer Systeme und Anwendungenfür Automobile. Hersteller strebennach Konsolidierung des bisherigenWildwuchses bei Hard- und Software-Plattformen, müssen aber kritischeAnwendungen strikt von angreifba-ren trennen. Mit PikeOS von SYSGOsteht Entwicklern eine Umgebung zurVerfügung, die eine solche Trennunggewährleistet und sich in der Flug-zeugindustrie mit ihren mindestensebenso hohen Sicherheitsanforde-rungen bewährt hat. Die modulareSoftware-Architektur PikeOS inte-griert mehrere Embedded-Anwendun-gen auf einer Hardware-Plattform.


document5561821220024802588.indd 8 16.11.2016 10:30:51

9



Entwicklung und Zertifizierungdeutlich vereinfacht

Das Echtzeitbetriebssystem (RTOS) und Virtualisierungssystem PikeOSermöglicht die Entwicklung und den Betrieb sicherheits-zertifizierter

Anwendungen auf einer gemeinsamen Hardware-Plattform.

THOMAS HERTEL *

* Thomas Hertel... ist freier Journalist.

FahrerassistenzsystemeundautonomesFahren sindnebender Elektromobilitätderzeit die wichtigsten Schwerpunktein der Automobilentwicklung. Schon heutesind viele Funktionen in Automobilen voll-ständig oder teilweise automatisiert; Fah-rerassistenzsysteme wie Abstandswarner,Rückfahrkameras oder Einparkhilfen findenZugang in die Serienproduktion selbst klei-ner undmittlerer Fahrzeuge. Komplett auto-nom fahrende PKW, Busse und auch LKWsindauf öffentlichenStraßen imTestbetrieb;erste Serienfahrzeuge können sich zumin-dest teilautonom bewegen.Allerdings ist es noch ein großer Schritt

hin zur komplettenAutonomie, die nicht nurentsprechendeSysteme imAuto voraussetzt,sondern auch eine intelligente Infrastruktursowie eine standardisierteVehicle-to-Vehic-le-Kommunikation (V2V). Zudemsind recht-liche Fragen zuklären, etwa zurVerantwort-lichkeit bei Unfällen, und weitere großeThemen sind Datenschutz und Sicherheit.Das autonome Fahrzeug kommuniziert

intensiv und produziert eineVielzahl perso-nenbezogenerDaten.Dabei geht es nicht nurum Bewegungsprofile – schon heute gibt esInnenkameras, die anhandderMimik erken-nen, wann der Fahrer müde wird. EinigeHersteller testen Sensor-Arrays, die anhandder Reaktionen des Fahrers oder auch derBeifahrer einen reduziertenBlutzuckerspie-gel und ähnliches diagnostizieren sollen.Diese Daten müssen ebenso geschützt wer-denwie privateDaten ausdem trautenHeim.Bei der Cybersicherheit geht es dagegen

vor allem darum, kritische Systeme vor un-erlaubten Zugriffen und vor allem vorMani-pulation zu schützen. Diese Anforderungwirdumsowichtiger, jemehr sicherheitskri-tischeundunkritischeAnwendungen inner-halb des Fahrzeugs betrieben werden und

miteinander logisch oder physisch verbun-den sind. So basieren viele Entertainment-Systemeauf demvergleichsweise unsicherenBetriebssystem Android.Sollte ein Angreifer Zugriff auf solche Sys-

teme erlangen, ist das zwar lästig, aber nicht

gefährlich. Kann er über dieses Einfallstoraber auf sicherheitskritische Systeme zugrei-fen, ändert sich das sofort dramatisch. Es istdaher unabdingbar, solche Anwendungenmit unterschiedlichen Kritikalitäts-Levelsstrikt zu trennen.

document5561821220024802588.indd 9 16.11.2016 10:30:57

10



Schaubild 1: Basierend auf dem Separation Microkernel können unterschiedliche Betriebssysteme und Anwendungen strikt getrennt ablaufen.

Bild:SYSGO

Allerdings läuft dies einemanderenwich-tigenBestrebenderHersteller diametral ent-gegen. SiewollendenderzeitigenWildwuchsin der Automobilelektronik dramatisch ver-ringern undmöglichst einheitliche Plattfor-men und Kommunikationskanäle für dieunterschiedlichen elektronischen Kompo-nenten einführen. Damit verfolgen sie dasZiel, Hardware- undauchEntwicklungskos-ten zu sparen, denn jede Plattform benötigtunterschiedliche Tools undExpertise. Inter-essant ist es für sie zudem, elektronischeKomponentenmodellübergreifend einsetzenzu können, vergleichbar mit den seit etwaAnfang des Jahrtausends populären Platt-formstrategien bei mechanischen Kompo-nenten.

Hersteller streben nach Konso-lidierung und StandardisierungHeutige Automobile besitzen bis zu 100

verschiedene Prozessoren für die unter-schiedlichstenFunktionenundbis zu siebenBusse für die Kommunikation zwischen ih-nen und den Sensoren bzw. Aktoren. Ent-sprechend komplex ist die Software-Umge-bung – 100 Millionen Codezeilen sind imPKW keine Seltenheit. Die KonsolidierungaufwenigeHardware-PlattformenundEther-net als einheitlichenKommunikationskanalbietet daher ein erhebliches Einsparpotenti-al. Allerdingsmussbei dieser Konsolidierung

„Es muss gesichert sein, dass einzelne Anwendungen, spezi-ell die sicherheitskritischen, strikt von allen anderen getrenntsind, selbst wenn sie auf der gleichen Hardware laufen.“

Franz Walkembach, Sysgo

gesichert bleiben, dass einzelneAnwendun-gen, insbesondere die sicherheitskritischen,strikt vonallen anderen getrennt sind, selbstwenn sie auf der gleichen Hardware laufen.

PikeOS zur sicheren Trennungvon AnwendungenMit PikeOS von SYSGO steht Entwicklern

eine Umgebung zur Verfügung, die eine sol-che Trennunggewährleistet und sichbereitsin der Flugzeugindustrie mit ihren mindes-tens ebenso hohen Sicherheitsanforderun-gen bewährt hat. PikeOS stellt einemodula-re Software-Architektur dar, die mehrereEmbedded-Anwendungenauf einer einzigenHardware-Plattform integriert. PikeOS um-fasst sowohl ein volles Echtzeit-Betriebssys-tem (Hard RTOS) als auch ein Virtualisie-rungs- und Partitionierungssystem, um diebesonderenAnforderungenvonAnwendun-gen in der Automobilindustrie zu unterstüt-zen. Die Basis der PikeOS-Plattform ist einkleiner, zertifizierbarerMicrokernel, der eineVirtualisierungs-Infrastruktur zurVerfügungstellt. Damit ist es möglich, verschiedeneAnwendungen und Ressourcen in sicheren,individuellen Partitionen zu platzieren.Da Automotive-Anwendungen von nicht-

kritischen Infotainment-Systemenbis hin zuhochkritischen Steuerungsfunktionen imAuto reichen, bietet PikeOS entsprechendeine breite Palette anGastbetriebssystemen,

sogenannten „Guest-OS“: von POSIX überLinuxundAndroid bisAUTOSARoderGENI-VI. Dank der strengen Trennung der einzel-nen Partitionen voneinander können An-wendungen verschiedener Kritikalitätsni-veaus und mit unterschiedlichen Sicher-heitsniveaus in einer gemischtenUmgebungauf einer einzigenStandard-Hardware-Platt-form laufen. Dank der integrierten Zeit-Par-titionierung ist es dabei unerheblich, ob essichumEchtzeit-Applikationenhandelt odernicht.

Hypervisor und Echtzeit-betriebssystem (RTOS)PikeOS basiert auf einemMicrokernel mit

der Leistung einesherkömmlichenEchtzeit-betriebssystems. Der Hypervisor bietet Par-titionen, die verschiedene Anwendungenhosten können - von einer einfachen, aberhöchst kritischenSteuerungsaufgabebis hinzu einem vollwertigen Betriebssystem wieLinux oder Android. Infolgedessen könnensichere undnicht sichereAnwendungenaufder gleichenPlattformkoexistieren. Komple-xe Systeme, für die in der Vergangenheitmultiple Geräte benötigt wurden, könnendamit auf einer einzigen Hardware konsoli-diert werden. Das reduziert Gewicht, Ener-gieverbrauch sowie Verkabelungsaufwandund verkleinert die Stückliste. Der PikeOS-Hypervisor läuft auf x86 sowie ARM, Power-PC, SPARC V8 / LEON oder MIPS und kannleicht an andere CPU-Architekturen ange-passt werden.Sehr interessant ist der Einsatz vonHyper-

visorenwie PikeOSaufMulticore-CPUs. Zumeinenunterstützenmultiple Cores byDesigndie TrennungvonAnwendungen, zumande-ren bieten sie auch die Performance, die da-

document5561821220024802588.indd 10 16.11.2016 10:31:01

ELEKTRONIKPRAXIS Embedded Software Engineering November 2016 11


für benötigt wird. Allerdings ist die Zertifi-zierung von Multicore-Systemen sehr kom-plex, und viele zertifizierte Systeme nutzentatsächlich nur einen Kern. Werden aller-dings unterschiedliche Funktionen in einereinzelnen Software gebündelt, die unter ei-nem Echtzeit-Betriebssystem auf nur einemCPU-Kern läuft, können sehr leicht Interfe-renzen zwischen den Funktionen auftreten–die strikte Trennung ist nicht gewährleistet.Beispielsweise kanndieAuswirkung einer

Anwendung auf das Laufzeitverhalten eineranderen Anwendung zu Sicherheitsproble-men führen, etwa das Überschreiten vonFristen bei Echtzeitanwendungen. Auf ähn-licheWeise könnenTiming-Effekte aufgrundder gemeinsamen Nutzung der Systemres-sourcen, wie Caches und Speicherbusse, zuverborgenen Informationskanälen führen,die gegendieVertraulichkeitsanforderungender Anwendung verstoßen.

Sicherheit und Zertifizierungvon AnwendungenDer PikeOS-Hypervisor selbst ist nach

höchsten Industriestandards zertifiziert unddamit eine geeigneteGrundlage für kritischeSysteme, in denen sowohl funktionale Si-cherheit als auch IT-Sicherheit gewährleistetsein müssen. Die Schutzmechanismen ba-sieren dabei im Wesentlichen auf zweiGrundsätzen: strikte Trennung der Anwen-dungen durch Zeit- und Ressourcen-Partiti-onierung sowie Steuerung der Kommunika-tions-Kanäle. Die einzelnen Anwendungeninnerhalb desGesamtsystemskönnendabeiunterschiedlicheKritikalitäts-Level besitzen.Aufgrunddieser Schutzmechanismenvon

PikeOS kann die Zertifizierung nach bran-chenspezifischenSafety- undSecurity-Stan-

dards für jedeAnwendung separat durchge-führt werden – ein wesentliches Merkmal,um die Kosten unter Kontrolle zu halten.Zudem war PikeOS die erste Plattform, dieauch eine SIL 4-Zertifizierung in Multicore-Umgebungen erhielt.

ISO 26262 und SEooC (SafetyElements out of Context)Die ISO 26262 ist ein internationaler Stan-

dard, der den Sicherheitslebenszyklus vonelektrischen, elektronischen und Software-basierten Komponenten in PKW definiert.Basierend auf der IEC 61508 reduziert ISO26262 die Gefahr des Auftretens von gefähr-lichen Betriebssituationen und definiert Si-cherheitsmaßnahmen, die dasAusfallrisikoreduzieren.Um die Anforderungen der ISO 26262 zu

erfüllen, wird PikeOS optional mit einemAutomotive Certification Kit angeboten, indas die langjährige und umfassende Zertifi-zierungs-Expertise von SYSGO eingeflossenist. Das Zertifizierungskit enthält einen ISO26262 Teil 6 konformen PikeOS-HypervisorsowieumfassendeDokumentationshilfen fürEntwicklung und Test. Weiterhin könnenzusätzliche Sicherheitsinformationenbereit-gestellt werden, um ISO 26262-konformeSysteme zu erreichen.WichtigeBestandteiledieser Zertifizierungskits sind ein Sicher-heitshandbuch mit Richtlinien für die Ver-wendung von PikeOS in sicherheitskriti-schen Designs von Systemen sowie eineFallstudiemit charakteristischen funktiona-len Sicherheitsanforderungen entsprechendder jeweils erforderlichenAutomotive SafetyIntegrity Levels (ASIL). // FG

SYSGO

Schaubild 2: Unter-schiedliche Anwen-dungen auf einerHardware-Plattformund ein deterministi-scher Kommunikati-onskanal ermöglichenein einfaches, abersicheres Systemde-sign.

Bild:SYSGO

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

document5561821220024802588.indd 11 16.11.2016 10:31:06

12

SOFTWAREKOMPONENTEN // ECHTZEITBETRIEBSSYSTEME


Bin ich auf der richtigen Bahn? DieWahl des OS für die Zugsteuerung

Auf den Eisenbahnstrecken in der EU kommt es jeden zweiten Tag zueiner Kollision oder Entgleisung. Um diese Rate zu senken, finden zu-

nehmend Normen für funktionale Sicherheit Anwendung.

TERRY STAYCER *

* Terry Staycer... ist Business Development ManagerGeneral Embedded bei QNX SoftwareSystems

Für denErfolg bei sicherheitskritischenProjekten im Schienenverkehr ist derWissensstandüber funktionale Sicher-heit und Zertifizierung einer der entschei-denden Faktoren. Anforderungen bei derZertifizierung für funktionale Sicherheitbestimmen allgemein oft über Erfolg oderMisserfolg eines Projekts, denn diese Anfor-derungen können die Projektdauer und denAufwand für das Projekt ganz schnell ver-doppeln oder gar verdreifachen.Die Normen für funktionale Sicherheit

können auf Neueinsteiger verwirrend wir-ken. Die EN 50128 beispielsweise ist einemarktspezifische Norm für funktionale Si-cherheit im Schienenverkehr, die von derweiter gefassten IEC 61508 abgeleitet ist, ei-ner Norm für die funktionale Sicherheit vonelektrischen, elektronischen und program-mierbaren elektronischen sicherheitsrele-

vantenSystemen.Die Sicherheitsintegritäts-level der EN 50128 reichen von der niedrigs-ten Stufe SIL 1 bis zur höchsten Stufe SIL 4.

Sicherheit lässt sich nichtnachträglich draufsattelnUm ein Gefühl dafür zu vermitteln, wie

hoch die Anforderungen sind: Bei einemnach SIL 3 zertifizierten System muss dieWahrscheinlichkeit für gefährliche Ausfällepro Betriebsstunde bei unter 1 in 10 Millio-nen liegen. Es ist fast unmöglich, derart strik-te Anforderungen zu erfüllen, wenn funkti-onale Sicherheit nicht von Anfang an imDesign verankertwird. Sicherheit kannnichteinfachnachträglichdraufgesatteltwerden.Umeinen sicherenundeffizientenBetrieb

zugewährleisten, implementierenEisenbah-nen rund um die Welt Systeme wie die kon-ventionelle Zugbeeinflussung (AutomaticTrain Protection – ATP), das US-amerikani-sche Zugleitsystem „Positive Train Control“(PTC) oder die funkbasierte Zugbeeinflus-sung (Communications-BasedTrainControl– CBTC). U-Bahnen und andere Züge im öf-fentlichen Personennahverkehr setzen zu-

nehmend auf vollautomatischen Zugbetrieb(AutomatedTrainOperations–ATO)–Züge,die keine Fahrer haben oder bei denen dieRolle des Zugführers hauptsächlich auf Un-terstützung bei Ausfällen und Notfallsitua-tionenbeschränkt ist. Bei jedemsicherheits-relevantenSystemkommt es ganz offensicht-lich auf Verlässlichkeit an, also sollte dasBetriebssystemdesign Garantien für Verfüg-barkeit und Zuverlässigkeit bieten können.SolcheBetriebssystemewerdenals Echtzeit-Betriebssysteme (RTOS–RealtimeOperatingSystem) bezeichnet. Es gibt unterschiedlicheRTOS-Architekturen, und eines ihrer Haupt-unterscheidungsmerkmale ist, wie gut einRTOS die EN 50128 für sicherheitskritischeApplikationen unterstützt.Die EN50128behandelt drei sehrwichtige

Punkte für Software:1.Architektur: Die Softwarearchitektur ist

die Stelle, an der die grundlegende Sicher-heitsstrategie für die Software und den Si-cherheitsintegritätslevel der Software entwi-ckelt wird.2. COTS: Soll in Systemen, die nach SIL 3

oder SIL 4 zertifiziert sein müssen, COTS-

Ein komplexes System: Lokomotive mit vorab zertifizierten Hardware- und Softwaremodulen und Netzwerktechnologien zur Kommunikation mit und zum Steuernvon diversen Systemen

Bild:Q

NX

document1867469983718917431.indd 12 16.11.2016 14:05:14

SOFTWAREKOMPONENTEN // ECHTZEITBETRIEBSSYSTEME

Zusammenfassung und AusblickZugsteuerungssysteme sind sicherheits-relevant. Also müssen sie die Verläss-lichkeitsanforderungen aus der NormIEC 61508 und der Normenreihe EN5012x erfüllen. Die Wahl eines OS wirktsich, bedingt durch seine Architekturund Features, welche Echtzeitgarantien,Fehlerisolierung und die Wiederherstel-lung nach Komponentenausfall unter-

stützen, direkt auf die Verlässlichkeitdes Systems aus. Weitere zu beachten-de Faktoren sind etwa Netzwerkstacks,HMI-Techniken, Multicore-Unterstützung(einschließlich Prozessor- oder Kernaf-finität) oder die Verwendung zertifizier-ter COTS-Komponenten wie etwa einesgemäß IEC 61508 SIL 3 zertifizierten Be-triebssystemkernels.

Software (Commercial off-the-shelf – Stan-dardkomponenten) eingesetzt werden, somuss „eine Strategie definiert sein,wieAus-fälle der COTS-Software erkanntwerdenunddas System davor geschützt werden kann.“3.Sicherheitsdesign und Validierung: Die

EN 50128 sagt explizit aus, dass „kein Wegbekannt ist, auf demsich ab einemgewissenKomplexitätsgrad die Fehlerfreiheit sicher-heitsrelevanter Software beweisen ließe.“Anders gesagt:Wennwir ein sicheres Systembauen, könnenwir nicht beweisen, dass dasSystem keine Fehler enthält, sondern ledig-lich Belege liefern, die unsere Aussage un-termauern, dass unser Systemso verlässlichist, wie wir es von ihm behaupten.Verlässlichkeit ist bei einem Softwaresys-

temeineKombination ausVerfügbarkeit (wieoft das System rechtzeitig auf Anfragen re-agiert) undZuverlässigkeit (wie oft die Reak-tionenkorrekt sind). Beides hängt stark vomgewählten Betriebssystem ab und, wie dieEN50128 erwähnt, speziell vonderArchitek-tur des Betriebssystems und dessen Fähig-keit zur Isolierung vonKomponentenausfäl-len zum Schutz des Systems. Ein wichtigerAspekt für den Einsatz in betriebskritischenAnwendungen ist die Fähigkeit, auch beiAusfällen die Sicherheit zu gewährleisten.Die Architektur des OS ist nicht nur ent-

scheidend für die Verlässlichkeit des Ge-samtsystems, sondern bestimmt auch, wieschwierig undkostspielig es ist, Komponen-ten mit unterschiedlichen SIL-Anforderun-gen voreinander zu isolieren oder. zu schüt-zen. Weiterhin können vorab zertifizierteKomponenten das Risikoprofil des System-herstellers insgesamt reduzieren, indemmitbewährter Technik gearbeitet wird.

Es sollte klar geworden sein, dass bei kom-plexenHardware- undSoftwareplattformendas Betriebssystem eine der wichtigstenKomponenten ist. Ein vorab zertifiziertesOSbietet hohe Zuverlässigkeit und einniedrige-res Risiko für sicherheitskritische Systeme.

Zertifizierung ist Gretchenfragebei „Make or buy“Eine zertifizierte industrielle Steueranwen-

dung ohne ein zertifiziertes Betriebssystemerscheint kaumvorstellbar. DieVorabzertifi-zierung stellt eine wichtige Dimension beider Entscheidung „Make or buy“ dar. EinigeSystemhersteller verfügenüber selbst entwi-ckelte Legacy-Komponenten, vielleicht auchein OS. Doch meist sind die Kosten für dieWartung, Entwicklung und Zertifizierungdieser Komponentenhöher als der Preis einervorab zertifiziertenLösung–wegendesAus-maßes der möglichen Einsparungen.Bei derHardware liegendieDinge anders.

Vorab zertifizierte Hardware ist schwer zufinden.MENMikrohat eine attraktive Lösung

hierfür vorgestellt. MEN hat für Kunden ent-wickelteHardware indenZertifizierungsum-fang eingebundenunddadurchdasProblemderVorabzertifizierung vonHardware für dieEisenbahnbranche effektiv gelöst. DasMENModular Train Control System (MTCS) kom-biniert vorab zertifizierte Hardware mit dervorab zertifiziertenQNXNeutrinoRTOSSoft-ware (zertifiziert nach IEC 61508 SIL 3) undbietet dadurch einen sehr hohen Grad anZuverlässigkeit und Risikoreduzierung fürsicherheitskritische Systeme. Durch Wahldes vorab zertifizierten QNX RTOS konnteMEN das Projekt um ca. 2 Jahre verkürzen,die Projektkosten um ungefähr 2 MillionenDollar senken und jegliches Zertifizierungs-risiko auf Ebene von OS, Board-Support-Pa-ckage und Hardware eliminieren. Mit vorabzertifiziertenHardware- undSoftwaremodu-len fällt es leichter, den Projektumfang unddie Kosten im Griff zu behalten. MEN Mikrohat das mit demMTCS bewiesen. // FG

QNX Software Systems

www.lauterbach.com/1701

Automotive Spezialistenvom Debugger für

vomfür RH850

Automotive SpezialistenvomvomRH850

MulticoreTracing

Code Coverage(ISO 26262)

Onchip,Parallel

und AuroraTracing

RH850,ICU-M und

GTMDebugging

AUTOSAR /Multicore

Debugging

Laufzeit-messung

(PerformanceCounter)

Multicore Onchip, Parallel

Laufzeit-messung

(Performance Counter)

NEXUS TRACING

DEBUGGING

RH850RH850

document1867469983718917431.indd 13 16.11.2016 14:05:15

http://www.lauterbach.com/1701

14

IMPLEMENTIERUNG // AGILE METHODEN


User Experience Designin der agilen EntwicklungIn der Software User Experience kommen iterative Prozesse zum Ein-

satz: Dieser Artikel beleuchtet Möglichkeiten, Software User Experiencemit dem agilen Vorgehensmodell Scrum zu kombinieren.

DANIEL FRANK *

* Daniel Frank... arbeitet seit 2006 für Method Park.Seine Schwerpunkte liegen in denBereichen Qualitätssicherung, Pro-zessoptimierung und User Experience.

Scrum ist heute das agileVorgehensmo-dell mit der weitesten Verbreitung. EskommtmitwenigenRollen,AktivitätenundArtefakten aus. Ein sogenannter ProductOwner übernimmt die Position des Kunden.Er bestimmt die Richtung der Entwicklungund macht auch die Vorgaben zur Beschaf-fenheit des Endproduktes. Der ScrumMasterkümmert sich darum, dass sein Team in Ru-he arbeiten kann. Er überwacht die Einhal-tung der Regeln, plant und moderiert Mee-tings und dient dem Team als Coach, ohnein die Arbeitsweise einzugreifen. Das Teamkonzentriert sich auf die Entwicklung.DieVorgabendesProductOwnerswerden

in Form kurzer User-Stories notiert. Eine

User-Story ist ein Satz, der eine Handlungdes Users mit dem Produkt beschreibt. JedeStory enthält die Nutzergruppe, die Hand-lungunddasZielderHandlung.Beispiel:„AlsReisender will ich eine Fahrkarte kaufen,damit ich den Bus nutzen darf.“ Die Samm-lung allerUser-Stories eines Projektes nenntman Product Backlog. Der Product Ownerdarf die User-Stories priorisieren.Das Team schätzt die nötigen Aufwände,

um die einzelnen Stories umzusetzen. EsübernimmtStories aus demProduct Backlogin einen Sprint Backlog. Dieser enthält dieStories, die das Team in einem festgelegtenZeitraum (Sprint) umsetzen wird. Die Dauereines Sprints liegt in einem festen Intervallvon zwei bis vier Wochen. Während desSprints kommtdas Team täglich zusammen;jedes Teammitglied berichtet vomStand sei-ner aktuellen Tätigkeit. Am Ende jedesSprints erfolgt ein Sprint Review. Das Team– der Product Owner, sowie eventuell Kun-

dendesProductOwners –bewertenhier daslauffähige Ergebnis des Sprints.Das Feedbackder Stakeholderwird gesam-

melt und fließt in das Product Backlog ein.Um seine Effizienz zu steigern, nimmt dasTeameineRetrospektive vor.Hierbei sinddasTeam und der Scrum Master anwesend. Esgeht darum, Probleme zu identifizieren, diewährend des letzten Sprints aufgetauchtsind. Diese werden diskutiert, damit dernächste Sprint effizienter verläuft. Anschlie-ßend plant das Team den folgenden Sprint.

Grundlagen der Software UserExperienceAlle Software User Experience (kurz: UX)

Designer haben ein Schema, nachdemsie inProjekten vorgehen. Sie entwickeln diesesSchema in ihrerAusbildungoder spätestenswährend ihrer Praktika inder Industrie. Vie-le Designer machen sich formal wenig Ge-danken über Prozesse. Einen formalisiertenAnsatz liefert dieNorm ISO9241:210 "Humancentered design for interactive systems" [1].Sie beschreibt einen Prozess, in dessen Mit-telpunkt der Nutzer steht. Die Entwicklungder Mensch-Maschine-Schnittstellen orien-tiert sich also an den Bedürfnissen der User.Das Produkt muss diesen Bedürfnissen ent-sprechen. Daher wird der Nutzer in die Ent-wicklung einbezogen.Ein Projekt beginntmit der Planungspha-

se. Hier wird der Grundstein für das weitereVorgehen gelegt. Man wählt geeignete Me-thoden aus, sucht passende Nutzer und legtTermine fest. Darauf folgen die Analyse unddie Beschreibung des Nutzungskontextes.Dieser umfasst die Benutzer, deren Ziele,Arbeitsmittel, Umgebung sowie das sozialeUmfeld. Die UX-Designer verwenden etwaBeobachtungenoder kontextuelle Interviews[2], um den Nutzungskontext zu ermitteln.Untersucht man lediglich die vorhandenenSystemeoder greift auf ErfahrungendesPro-duktmanagers zurück, erhält man ein lü-ckenhaftes Gesamtbild. Auf Basis des Nut-

Bild 1: Einfache Integration der Prozesse

Bild:M

etho

dPark

document6393342606692518392.indd 14 16.11.2016 10:19:41



zungskontextes spezifizieren die DesignerNutzungsanforderungen. Dabei gehen sievon sogenannten Erfordernissen aus. Dieseberuhenauf der Frage:Wasbraucht derNut-zer? Die daraus resultierendenNutzungsan-forderungen beantworten die Frage: Waskann der Nutzer mit dem System tun?Nun müssen die Gestalter Lösungen ent-

wickeln, die alle Nutzungsanforderungenabdecken sollen. Der erste Grobentwurf ent-hält zumBeispiel eine Informationsarchitek-tur, die alle nötigen UI-Komponenten unddieNavigation festlegt. Dieser erste Entwurfwird dann imweiterenProjektverlauf bis insletzte Detail verfeinert. Allerdings ist jederSchritt zu evaluieren.HierfürmüssenProto-typen erstelltwerden. Zunächst bedientmansich einfacher Prototypen aus Papier. DasTeam entwickelt diese Prototypen immerweiter, um die Gestaltungslösung für denBenutzer erlebbar zumachen. Sowird sicher-gestellt, dass das Ergebnis optimal auf dieNutzer abgestimmt ist. Stellen die GestalterProbleme fest, danngehen sie dazuüber, denNutzungskontext anzupassen oder die An-forderungen zu überarbeiten. Der Prozessendet, sobald eine Gestaltungslösung alleNutzungsanforderungen erfüllt.Liefergegenstände legt die ISO 9241 nicht

explizit fest. DieArbeitsergebnisse vonDesi-gnern sind normalerweise gut durchdachtund visuell gut aufbereitet. Außenstehendeerwarten genau dies. Allerdings ist der Zeit-bedarf für eine derartige Arbeitsweise hoch.Diese Zeit ist innerhalb einer agilenEntwick-lung nicht verfügbar. Damit die Zusammen-arbeit mit der Entwicklung funktioniert,müssen Designer im agilen Umfeld umden-ken. Diese Denkweise ist auch fester Be-standteil von Lean UX [3].

Strategien: Mit Iterationen dieideale Lösung findenDie beschriebenenVorgehensmodelle ha-

ben viel gemeinsam. Zum einen verfolgenbeide einen iterativenAnsatz. In Scrumbautjedes Inkrement auf dem vorhergehenden,aus dem letzten Sprint auf. Im UX-ProzesswerdenPrototypen erstellt. DieDesigner eva-luierendiesemitUsernund lassendie Ergeb-nissewieder in denProzess einfließen.Auchhinsichtlich der engen Zusammenarbeit derStakeholder undder entstehendenTranspa-renz stimmen die Modelle überein.Ein großer Unterschied liegt allerdings in

der Zielgruppe. Bei Scrum ist der ProductOwner der Ansprechpartner für das Team,wenn es um die User-Stories geht. Bei derErstellung eines UX-Konzeptes hingegen er-hebendieGestalter dieAnforderungendirektmit Nutzern. Ein weiterer Unterschied sind

die Interessen der Stakeholder: Entwicklersind oft nicht an Design interessiert, Desig-ner nicht an Fragen der Implementierung.Die größte Differenz besteht in der Zielset-zungderModelle. UX-Design lotetmöglichstviele Ideen aus, um eine für den Nutzer ide-ale Lösung zu finden. Scrumdagegen ist einInstrument, ummittels von Iterationen einetechnisch optimale Lösung umzusetzen.

Einfache Integration der UX-Aktivitäten in ScrumEine erste Möglichkeit, beide Modelle zu

vereinen, liegt in der Integration der UX-Aktivitäten in den Sprint. Der UX-Designerwird also Teil des Scrum-Teams. Er ist wäh-rend der Sprints dafür verantwortlich, dieUser-Storiesmit den entsprechendenMetho-den inDesigns zuübersetzen.Die Entwicklerimplementieren das User Interface nachseinen Vorgaben und das Inkrement einesSprints wächst. Dieser Ansatz ist mit ver-schiedenen Problemen behaftet. ZunächstkönnenunterschiedlicheUser-Stories andiegleichen Bedienelemente gebunden sein.Das Scrum-Team setzt die Stories Sprint fürSprint um,wodurchderDesigner immerwie-der Hand an dieselben Elemente anlegenmuss. Ein konsistentes Gesamtbild kommtso nur schwer zustande; gleichzeitig erlebtderDesigner bei dieserVorgehensweise Ent-täuschung und Unzufriedenheit.Die Entwickler wollen direkt mit der Um-

setzung der User-Stories beginnen. Für dasUser Interface benötigen sie dieVorgabendesDesigners. Diesermuss zunächst einKonzepterstellen. Durch Nutzertests mit Prototypenerhält er Klarheit darüber, ob das KonzeptErfolg verspricht. Dadurch vermeidet dasTeam unnötige Iterationen. Indem man dieEntwickler einbezieht, stellt man zusätzlichdie Machbarkeit sicher. Allerdings kann dieImplementierung erst erfolgen, wenn dasKonzept für eine oder mehrere User-Storiesfertig ist. Soll eine Story innerhalb einesSprints abgeschlossen werden, dann bleibt

Bild 2: Vorgelagerter Design-Sprint (sogenannterSprint Zero)

Bild:M

etho

dPark

www.elektronikpraxis.de/newsletter

Tages-Newsletterdie Nachrichten derletzten 24 Stunden

0728

3_01

Jetzt

anmelden

MIKROFLAMM - LÖTEN

Videoclips undBeispiele aufwww.spirig.tv

Kostenlose

Anwendungsversuche

Linutronix GmbH telefon 07556 / 25999 0www.linutronix.de [email protected]

Linux Schulungen 2017Wissen ist Macht!Januar 2017:industrie & Echtzeit 17. - 18. 01.tracing 19. 01.Yocto 24. - 25. 01.Februar 2017:iot und Security 07. - 08. 02.industrie & Echtzeit 21. -22. 02.tracing 23. 02.März 2017:netzwerke & Security 13. - 16. 03.Linux Advanced 21. - 23. 03.Yocto 28. - 29. 03.April 2017:industrie & Echtzeit 25. -26. 04.tracing 27. 04

Kundenspezifische und inhouse Schulun-gen gerne auf Anfrage.mehr info unter:www.linutronix.de

document6393342606692518392.indd 15 16.11.2016 10:19:44

http://www.linutronix.dehttp://www.linutronix.demailto:[email protected]://www.elektronikpraxis.de/newsletterhttp://www.spirig.tv

16



für die Implementierung folglichwenig Zeit.Dies setzt sowohlDesigner als auchEntwick-ler unter Druck.Gothelf und Seiden [3] beschreiben die

Integration vonLeanUX inScrum. IhrAnsatzsieht vor jedem Sprint ein Kick-off-Meetingfür dieGestaltung vor. Darin sucht das TeamIdeenunderstellt Skizzen.Diese zusätzlicheAktivität sorgt dafür, dass die Gestalter zuBeginn der Sprints konkrete Aufgaben be-kommen. Während der Iterationsplanungleitet man nämlich aus den Skizzen User-Stories ab, diemanwieüblich indasBacklogübernimmt. Im Sprint werden die Ideen va-lidiert. Dafür reichen zwei Terminepro Sprintaus, wobei der zweite Termin noch vor demEnde des Sprints liegen muss. So kann dasTeamdie Ergebnisse derValidierungnoch indas Ergebnis des Sprints aufnehmen.

Sprint Zero als vorgelagerteDesignphaseUm die Modelle abzugleichen, kann man

alternativ eine vorgelagerte Designphaseeinführen, also innerhalb eines sogenanntenSprint Zero [4]. Im ersten Sprint arbeitet dasTeam am Design. Dies geschieht, bevor dieEntwicklung des Codes beginnt. Das Teamdes Sprint Zero kann speziell für diesenZweckgebildetwerden. Ideal ist ein interdis-ziplinäres Team aus UX-Experten, Produkt-managern und Entwicklern. Sie sollen einGrobkonzept erstellen. Im weiteren Projekt-verlauf verfeinert das Teamdieses inkremen-tell. Dazumuss ein UX-DesignerMitglied imregulärenScrum-Teamsein.Dieser detailliertdas anfängliche Konzept und testet es mittatsächlichenNutzern. EinwesentlicherVor-teil: Elemente, die über den Scope einzelnerStories hinausgehen, etwadie Informations-architektur undNavigation, sind schon fest-

gelegt. So hat das Entwicklungsteam einenRahmen, in dem es sich bewegt. Zugleichwird Konsistenz sichergestellt.DiesesVorgehenbildet jedoch eineBrücke

zum linearen Wasserfallmodell. Wer Scrumeinsetzt, will sich genau davon lösen. DieReaktion auf Änderungen im Projektverlaufwird schwieriger, da die Anpassung des ur-sprünglichenDesign-Konzeptesweitreichen-deFolgenhat. Somüsste eventuell ein erneu-terDesign-Sprint eingeschobenwerden,wasden Projektverlauf verlangsamen würde.Als dritte Variante lassen sich Design und

Entwicklungparallel ausführen [5]. DieswirdalsDual Track Scrumbezeichnet.Man formtzwei Scrum-Teams mit unterschiedlichenAufgaben.DasDiscovery-Teamwird interdis-ziplinär aufgestellt. Es kümmert sich umdieGestaltung der Software User Experience.Seine Ergebnisse erhält das Delivery-Team.Dieses zweite Teambesteht aus Entwicklern,die aus demDesignneueUser Stories formenund implementieren.Bei diesem Vorgehen muss auf den Infor-

mationsfluss zwischen den Teams geachtetwerden. Ein einfachesÜbergeben vonDoku-menten ist nichtwünschenswert. Die Teams

müssen viel kommunizieren, damit hiernichtwieder ProblemederWasserfall-Taktikauftauchen. Stories ausdemDiscovery-Teammüssen stets rückverfolgbar sein. Nur sokann ein Chaos bei Änderungswünschenoder notwendigen Verfeinerungen verhin-dert werden. Haben die Gestalter im Projektvorübergehend nichts zu tun, so kann dasDiscovery-Team ohne weiteres einen odermehrere Sprints lang pausieren.

Best Practicesfür die EntwicklungDie Gestalter pflegen einen allgemeinen

User Experience Styleguide. Er beinhaltetVorgaben für Standard-Komponenten derUser-Interfaces, Layouts, Icons, Farben, Re-sponsive Design und Interaktionen. DieserStyleguide muss für alle Mitarbeiter einseh-bar sein. Änderungen werden von den Ge-staltern laufend eingepflegt, so dass die ak-tuellste Version stets zugänglich bleibt. An-passungen für konkrete Projekte sind zuläs-sig,müssenallerdings inderDokumentationfestgehalten werden. Der größte Vorteil die-ser Strategie besteht in der Zeitersparnis undVermeidung von Redundanz. Alle Projektekönnen auf die Erfahrungen und Vorgabenaus dem Styleguide zurückgreifen.Agile Prozesse leben vom Informations-

austausch. Dies gilt speziell bei interdiszip-linären Teams. Die Verteilung von Teamsüber verschiedene Gebäude oder gar ver-schiedene Standorte schadet dem Kommu-nikationsfluss. Diskussionen, Ideenaus-tausch und schnelle Problembeseitigungfunktionieren am besten durch kurzeWege.Daher sollen Gestalter und Entwickler mög-lichst nahe beieinander sitzen.Die Zusammensetzung der Teams ist sta-

bil. Ein eingespieltes Team von Gestalternund Entwicklern sollte nicht verändert wer-den. Wird ein Designer temporär nicht imProjekt benötigt, sollte er später nicht durcheinen Kollegen ersetzt werden. Dies stärktden Zusammenhalt des Teams und verhin-dert Wissensverluste im Projekt. // FG

Method Park

Bild 3: Dual Track Scrum

Bild:M

etho

dPark

PRAXISWERT

Es gibt nicht den einen KönigswegEs gibt diverse Möglichkeiten, Scrumund Software User Experience zu ver-einen. Allerdings gilt: Es gibt nicht deneinen Königsweg. Die Verbindung vonScrum und UX muss sich stets an dieGegebenheiten einer Organisation an-passen. Nur so finden die Beteiligtenam Ende einen für alle optimalen Weg.Die Mitglieder der Teams brauchen einehohe Flexibilität.

Kein Platz für HeldenDer Typus des Helden ist hier völlig fehlam Platz. Das gilt für Entwickler genau-so wie für Designer. Wichtig sind Team-geist und die Bereitschaft, sich auch anAufgaben zu beteiligen, die jenseits dereigenen Domäne liegen. Dies entsprichtwiederum den Prinzipien des agilen Ma-nifests: Kommunikation, Kollaborationund die Annahme von Veränderungen.

Quellenverzeichnis[1] http://www.din.de/de/mitwirken/normenaus-

schuesse/naerg/normen/wdc-beuth:din21:135399380

[2] http://www.usabilitybok.org/contextual-inquiry[3] Lean UX; O'Reilly and Associates; ISBN-10:

1449311652[4] Sprint Zero: https://www.scrumalliance.org/

community/articles/2013/september/what-is-sprint-zero

[5] Adapting Usability Investigations for AgileUser-centered Design; Desirée Sy; Journal ofUsability Studies; Vol. 2 Issue 3; 2007

document6393342606692518392.indd 16 16.11.2016 10:19:46

http://www.din.de/de/mitwirken/normenaus-schuesse/naerg/normen/wdc-beuth:din21:135399380http://www.din.de/de/mitwirken/normenaus-schuesse/naerg/normen/wdc-beuth:din21:135399380http://www.din.de/de/mitwirken/normenaus-schuesse/naerg/normen/wdc-beuth:din21:135399380http://www.din.de/de/mitwirken/normenaus-schuesse/naerg/normen/wdc-beuth:din21:135399380http://www.din.de/de/mitwirken/normenaus-schuesse/naerg/normen/wdc-beuth:din21:135399380http://www.usabilitybok.org/contextual-inquiryhttps://www.scrumalliance.org/

10875

www.vogel.de

--> elektronikpraxis.de/hired

POWERED BY

SUCHENSIE NOCHDENPASSENDEN?

Dann findenSie hier die bestenArbeitgeber in der Elektronik!

Jetzt kostenlos online bestellen!

THEMEN: Karriere&Bewerbungstipps

Die attraktivsten Arbeitgeber in derElektronik & Elektrotechnik

GehaltsreportElektronik & Elektrotechnik

„HIRED! Engineer your Career“ist dasKarrieremagazin speziell fürElektronikingenieure –unddamit einzigartig inDeutschland.

INKLUSIVE

GehaltsreportElektronik

2016

http://www.vogel.de

SECURITY //MEHRSCHICHTIGE STRATEGIEN


Angriff auf Data-Center: Die Attacke auf großeInternetdienste im Oktober 2016 ging vonvernetzten Kleingeräten mit zum Teil undoku-

mentierten Sicherheitslücken aus. Herstellersolcher IoT-Geräte müssen ein besseres Sicher-

heitsbewusstsein entwickeln.

Management-Unternehmen, konnte damitnicht Schritt halten.Wer steckte hinter der weitreichenden At-

tacke? Hunderttausende von Geräten imInternet derDinge (IoT), diemit demBotnetz-Virus „Mirai“ infiziert waren – darunter di-gitale Videorekorder, Netzwerk-Videorekor-der und IP-Kameras. Das Ereignis war zwarnichtmit dem„AufstandderMaschinen“ ausdemTerminator-3-Filmvergleichbar, aber erzwingt Gesetzgeber und Produktentwicklergleichermaßen dazu, die Bedeutung der Si-cherheit in IoT-Geräten zu überdenken.Nur weil ein Interface nicht im Benutzer-

handbuch aufgeführt wird, heißt das nicht,dass es nicht vorhanden ist. ImFall derDYN-Attackewar eine IoT-Management-Plattforman zahlreiche Produktentwickler verkauftworden. Das eingebaute Web-Interface er-laubte es denBenutzern, ihre Passwörter zu

ändern, aber die SSH- und Telnet-Interfaces akzeptierten im-

mer nochdaswerks-seitig voreinge-

stellte Passwort, sogar nachdem der Benut-zer seinPasswort geändert hatte. DasBotnetzspähte das Internet nach Produkten mitdieser sperrangelweit geöffneten Hintertüraus und lud das Programm zum Angriff aufden DYN-Server darauf, während es weiternach anderen Geräten suchte, um diese zuinfizieren.DieDYN-Attacke ist auf einige Fehler in der

Entwicklung zurückzuführen.Hättemannureines der nachfolgend genannten Problemebehoben, dann hätte die Attacke komplettverhindert werden können:Debug-Ports abschalten: Ein Port-Scan,der nur ein paar Sekunden dauert, zeigtalle offenen Verbindungen auf, darunterauch undokumentierte wie Telnet und SSH.Debug-Ports sind zwar gut für Diagnose-zwecke, aber eben ein Zugangspunkt, dergeschützt werden muss. Systemweite Passwörter: Das Benutzer-konzept sollte das gesamte System um-fassen. Wird ein Passwort an einem User-Interface geändert, dann sollte es für alleanderen ebenfalls gelten. Individuelle werksseitige Passwörter:Systemweite Passwörter sind effektiv, so-lange die Benutzer die werksseitig einge-stellten Passwörter auch ändern. Aber diemeisten Anwender tun das nicht. Die Ge-fahr globaler Passwörter und Schlüsselliegt darin, dass alle Geräte kompromit-tiert werden, sobald ein Geheimnis be-kannt wird. Hätte man während derFertigung pro Gerät ein individuellesPasswort generiert, dann wäre dieDYN-Attacke von vornherein ausge-schlossen gewesen.

Sicherheit von IoT-Geräten mussauf Vertrauen basierenDer Denial-of-Service-Angriff auf namhafte Internetdienste vom Ok-tober 2016 wirft Fragen nach der Sicherheit von IoT-Geräten auf. Am

effektivsten ist eine mehrschichtige Strategie.

GREGORY RUDY *

* Gregory Rudy... ist Direktor für Business Develop-ment für Integrity Security Servicesbei Green Hills Software.

Am 21. Oktober 2016 lähmte eine großangelegte Distributed-Denial-of-Ser-vice-Attacke den Internetzugang inden USA und blockierte einige Onlinediens-te, darunter Twitter, Netflix, Spotify, Airbnb,Reddit und die New York Times. Die Unter-brechungwurdedurch eine anhaltendeFlutvonheimtückischenNachrichtenverursacht,diemehrerenMillionen von IP-Adressen aus-ging. Der Domain-Namensservice von DYN,demCloud-basierten Internet-Performance-

Bild: © sonjanovak/Fotolia.com

document1342039286701991277.indd 18 16.11.2016 13:15:37

SECURITY //MEHRSCHICHTIGE STRATEGIEN

Ein Unterschied zwischen IT-Netzwerksi-cherheit undEmbedded-Security im IoT liegtimWert der Daten imGegensatz zur Compu-ting-Ressource. Die Motivation, ein IT-Netz-werk zu hacken, liegt in den gespeichertenInformationen – Kreditkartendaten, Sozial-versicherungsnummern, intellektuelles Ei-gentum. IoT-Geräte sind anders, denn diemeisten Daten sind unverfänglich. Mit eini-genAusnahmen sind IoT-Datenwie die Zim-mertemperatur oder der Status des Kühl-schranks nur für den Betreiber der Gerätewichtig.Wennaber dieAngreiferwie bei derDYN-Attacke die Software auf einem IoT-Gerät verändernkönnen, dann ist das Ergeb-nis, dassHunderttausende kleiner ComputerDaten abgreifenundProzesse störenkönnen.Alle IoT-Geräte sind eingebettete Systeme.

Unter den Softwareschichten liegen In- undOutput-Schnittstellen, Zustandsautomatenund Daten. Betrachten Sie Ihr neuestes undbestes IoT-Spielzeug. Was ist drin? WLAN,eine Kamera oder Mikrofone? Alles ist zu-gänglich, wenn die Software durch bösarti-gen Code ersetzt wird.

Es gibt immer nochunentdeckte HintertürenEine naive Lösung wäre es, das unmittel-

bare Problemzubeheben, indemDebugging-Schnittstellen abgeschaltet werden oder in-dividuellewerksseitige Passwörter vergebenwerden. Das ist ein wichtiger Anfang, aberwas ist mit dem nächsten Botnetz? Es gibtimmer noch eine Hintertür, sie ist nur nochnicht entdeckt worden. Jede Software hatFehler. Der industrieweiteDurchschnitt liegtzwischen einem und 25 Defekten auf 1000Codezeilen. Einschließlich der Anwendun-genunddem typischenAllzweckbetriebssys-tem befinden sich über 10 Millionen Code-zeilen in jedem IoT-Gerät. Nehmen wir alsoeine Fehlerrate von 0.05 Defekten an, dannlautet das Resultat immer noch: Über 500

Defekte in jeder Gerätesoftware. Alle habendas Potenzial für eine Zero-Day-Attacke.Experten für Embedded-Security, etwa

Integrity Security Services, eine Tochterge-sellschaft vonGreenHills Software, empfeh-len eine Lösung, die auf Vertrauen basiert.Damit ist nicht blindes Vertrauen gemeint,sondern eine systematische Überprüfungjeder Softwareschicht, die sicherstellt, dasssie vor der Ausführung nicht verändert wur-de. Defekte existieren zwar weiterhin, abersie können nicht dazu ausgenutzt werden,umProgrammeauszuführen, die derHerstel-ler nicht beabsichtigt hatDer Secure-Boot-Prozess verwendet digi-

tale SignaturenundKryptographie, umnichtautorisierte Software-Modifikationen zu ent-decken.Hardware spielt einewichtige Rolledabei, damit dieser Prozess nicht unterlaufenwerden kann. Während des sicheren Boot-vorgangs gibt es zwei Risiken: Bösartiger Code überspringt die Prüfungoder täuscht die Verifikation vor. Kryptographieschlüssel werden ausge-tauscht, was die Verifikation von bösarti-gem signiertem Code erlaubt.Hardwaremildert dieseRisiken, indemsie

für eineunveränderlicheRoot-of-Trust sorgt.Nach dem Einschalten schützt das ROM dieKryptographieschlüssel und verhindert,dass die anfänglicheVerifikationübersprun-genwird. Sobalddie Software authentifiziertist,wird ihr vertraut und sie kannausgeführtwerden. Es können zwar noch Defekte vor-handen sein, aber es wird nur Code ausge-führt, der vom Produkthersteller stammt.Bestimmte IoT-Geräte wie etwa Überwa-

chungskameras sind für eine lange Zeit inBetrieb. In diesen Fällen ist der Nutzen dessicherenBootens zwar gering, aber nötig, umerst einmal ein vertrauenswürdiges Systemherzustellen. Sobald dies gewährleistet ist,kann sich das System dann selbst überwa-chen, umEingriffe von außen zu entdecken.

Das Betriebssystem Integrity ist dafür be-kannt, nicht vertrauenswürdigeundmit demNetz verbundene Software von sicherheits-kritischen Komponenten zu trennen. WirdderAspekt der TrennungbeimSystemdesignberücksichtigt, dannverringern sichdieAus-wirkungen jedes Defekts.

Entwickler müssen Softwareschnell aktualisieren könnenWerden Defekte entdeckt, dann müssen

IoT-Entwickler schnellmitUpdates reagierenkönnen. Es gibt eine Reihe von Möglichkei-ten, die Updates zu verteilen, aber in jedemFall muss die neue Software zuerst authen-tifiziert werden, bevor sie akzeptiert werdenkann. Automatische Updates über das Netz-werk können Service-Kosten reduzieren,wenn sie korrekt ausgeführt werden. Dabeiwerden sowohl das Gerät als auch die End-punkte der ClouddurchgegenseitigeAuthen-tifizierung und Verschlüsselung geschützt.Die daraus resultierende mehrschichtige

Sicherheitsarchitektur bietet eine tiefgreifen-de Abwehr gegen das Mirai-Botnetz sowiegegenall dieDefekte, die nochnicht bekanntsind. Von derHardware erzwungenes siche-res Booten verhindert das Einschleusenbös-artigen Codes durch Zero-day-Attacken.Durch Over-the-network-Updates kann

Software ausgebessertwerden, sobald Fehlerentdecktwurden. Investitionen inKryptogra-phie mögen zwar manchen Managern wieeine Versicherungspolice erscheinen, abererfolgreiche Unternehmen profitieren vonvertrauenswürdigen Plattform-Designs, in-demsie zusätzlicheEinnahmendurchLizen-zierung, Feature-Kontrolle und In-App-Käu-fe erzielen.DenRat vonExperten für End-to-End-Security zu suchen, ist ein klugerSchachzug, der allenEmbedded-Entwicklernhilft, ihre Geräte zu schützen. // FG

Green Hills Software

Risiken in Ihrem Projekt?Embedded Safety- und Security-Experten helfen!

Mit der Erfahrung aus hunderten

Projekten und erfolgreichen

Produktentwicklungen sind wir

der richtige Partner, wenn es um

die Entwicklung von sicherer und

verlässlicher Software geht.

www2.hitex.com/safety

document1342039286701991277.indd 19 16.11.2016 13:15:39

IMPLEMENTIERUNG // FRAMEWORKS

Multiplattform-Entwicklung mitdem Qt-Framework

Plattformunabhängigkeit wird in zunehmendem Maße von Anwendun-gen gefordert. Das C++-Framework Qt erlaubt es, Applikationen zuentwickeln, die gleichermaßen unter Windows und Linux laufen.

HENDRIK SATTLER *

* Hendrik Sattler... arbeitet bei Mixed Mode in Gräfel-fing bei München. Er befasst sich mitBuildsystemen, Qt, Cross-Platformsowie Embedded-Themen.

Das FrameworkQt erlaubt es, Program-me zu erstellen, die gleichermaßenunterWindowsundLinux laufenkön-nen.Dies bedeutet Plattformunabhängigkeitimweitesten Sinne. Szenarien für denBedarfund Einsatz dieserMöglichkeit gibt es viele,etwadie grafischeBenutzeroberfläche (UserInterface, UI) eines unter Linux laufendenGeräts, die alsWindows-Programmsimuliertwird und so auch Windowsusern zur Verfü-gung steht, oder Kollaborationswerkzeuge,die ebenfalls nicht auf Windows-Nutzer alsZielgruppe beschränkt bleiben sollen. ZurSicherstellungdieser Plattformunabhängig-keit werden verschiedene Ansätze zur An-wendung gebracht. Während für die UI-Si-mulation ein möglichst gleiches Aussehensinnvoll erscheint, sollen Kollaborations-werkzeuge sich gut in die Desktop-Umge-bung einpassen.

Startet man in der Softwareentwicklungmit einem neuen Projekt oder portiert einvorhandenesProgrammauf andereCompileroder Plattformen, dann stehen am Anfangoft schon die Compiler selbst imWeg.

Compiler und andereEntwicklungswerkzeugeDer Compiler von Visual Studio C++ bei-

spielsweise ist nur unterWindows verfügbar,währendunter Linux eher derGNU-Compiler(gcc) oder alternativ LLVM/clang verwendetwird. Bei allen diesen Compilern kann esvorkommen, dass im zu portierenden CodeFehler an bestimmten Stellen angemerktwerden, die bei anderen Compilern an-standslos durchlaufen. Weitere Komplikati-onen könnendurchdieVerwendung compi-lereigener Features imzuportierendenCodeentstehen. Für solche Probleme bietet Qt ingewissem Umfang Hilfsmakros an, da Qtselbst den Anspruch hat, mit einer Vielzahlunterschiedlichster Compiler arbeiten zukönnen. Der Weg von Qt5 hin zur Nutzungvon modernem C++11 ändert diese Ausrich-tung einwenig,wasdie erforderlichenCom-

piler-Features angeht, somit auch die unter-stützten Versionen.Für einen komplexen Build-Prozess zur

Generierung von Programmen muss auchdessen Verwaltung betrachtet werden. Mitdem unter Windows gebräuchlichen VisualStudiowerdenMSBuild-Projekt-Dateien ver-wendet, während das unter Linux üblicheGNU make mit Makefile-Dateien arbeitet.Hier bieten sich als Abstraktionsschicht dieMeta-Build-Tools qmake oder CMake an, dasie beide sowohl Makefiles als auch Visual-Studio-Projekte generieren können. Wäh-rend qmake mit Qt direkt mitgeliefert wird,wird CMake seit Qt5 explizit unterstützt undwird in vielenQt-basiertenProjekten verwen-det. Mit diesen Meta-Build-Tools ist es mög-lich, die Build-Regeln für verschiedenePlatt-formen nur an einer Stelle zu verwalten. DieKommandozeilen-Frontends der Compiler,Linker undanderer SDK-Tools unterscheidensich in der Regel deutlich. Die Programmeund ihre Parameter zur Erstellung statischeroder dynamisch gelinkter Bibliotheken, zurLaufzeit geladener Module oder Programm-dateien können stark variieren. Auch hier

20

Multiplattform-Entwicklung: Viele Ent-wickler programmieren ihre Embedded-

Applikationen für verschiedene Zielsysteme.Mit dem Qt-Framework lässt sich der Aufwandhier deutlch reduzieren.

Bild: ©hvostik16/Fotolia.com

document2200552619313839082.indd 20 16.11.2016 13:55:03



sind solche Meta-Build-Tools hilfreich, in-dem sie die Nutzung der SDK-Tools abstra-hieren und damit vereinheitlichenZusätzlichwerdenoft eigeneTools verwen-

det, um z.B. Code zu generieren. Bei diesenToolsmussman sichwährendder Portierungebenfalls um die Plattformunabhängigkeitkümmern, kanndafür aber durchaus zuden-selben Mitteln greifen.

Aushängeschild von Qt:Grafische ElementeDie Bibliotheken für die graphischen Ele-

mente sind das buchstäblich augenfälligsteundwohl bekannteste Beispiel für die Prob-lematik der Plattformunabhängigkeit. Lautetdie Aufgabe, in C++ eine native GUI fürWin-dows zu erstellen,war lange Zeit dieMFCdieeinzigeMöglichkeit,während esunter LinuxmehrereBibliothekengab.Mit neuerenWin-dows-Versionenkamenauchhier neueMög-lichkeiten hinzu, aber das Grundproblemblieb bestehen: Diese GUI-APIs gibt es nurunter Windows. Möchte man dieselbe GUIauch unter Linux anbieten können, kommtmanumeine für beidePlattformenverwend-bare Bibliothek nicht herum, möchte mannicht zwei GUIs pflegen. Qt ist eine dieserMöglichkeiten.Die grafischen Elemente sind der wohl

bekannteste Teil vonQt. Die klassische Formsind die mit C++ programmierbaren QWid-gets fürDialogeundAnwendungsfenster. Siekönnenalternativ auchdeklarativ überXMLangesprochen werden, sodass etwa Dialogemit einemmitgelieferten grafischenDesignererstellt werden können. Die neueste Formder Anwendungsgestaltung, QML mit Qt-Quick, lehnt sichdagegen eher anWeb-Tech-nologien an. Es gibt jedoch verknüpfendeElemente zur C++-Welt von Qt.Die Grafikoberflächen unter Linux gestal-

ten sich indes recht unterschiedlich. Wäh-rend auf dem Desktop aktuell ein X-Servervon X.org genutzt wird, wird es zukünftigwohl eher Wayland sein. Embedded-Gerätenutzen dagegen oft direkt auf einem Frame-buffer aufbauende Techniken. Die meistendieser Möglichkeiten werden auch von Qtunterstützt, die Reife der Umsetzung ist je-doch recht unterschiedlich und damit imEinzelfall zu prüfen.AuchdieVerwendungvon 3-D-Elementen

ist unter Windows und Linux möglich, Qt-intern wird dazu jedoch immer auf OpenGLzurückgegriffen. Während unter LinuxOpenGL der Systemstandard für 3D ist, istdie Unterstützung von OpenGL unter Win-dows nicht immer gegeben. Daher wird beiQt5 die ANGLE-Bibliothek mitgeliefert, dieautomatisch nach DirectX 9 oder 11 konver-

tieren kann. Alternativ,wenn etwa eineGra-fikkarte kein DirectX unterstützt, wird allesin Software gerendert,was aber sehr zeitauf-wändig ist. Die Unterstützung für OpenGLwird bei Programmstart geprüft oder durchden User vorgegeben.Je nach Anforderung kann der Darstel-

lungsstil der integrierten Elemente ange-passt werden, so dass sie etwa zur Desktop-Oberfläche passen. Dabei werden nicht dienativenWidgets der Plattformverwendet, sodass eine einfache Oberfläche auch unterLinux einer nativen Windowsanwendungzumindest sehr ähnlich sehenkann, etwa fürden oben genannten Fall derUI-Simulation.Alternativwähltman je nachPlattformeinenanderen Stil zur besseren Desktop-Integra-tion.Mit dieser Vielseitigkeit kann sichQt zwar

vielen Umgebungen anpassen, doch gehenmit dieser Flexibilität auchProbleme einher.Auch wenn man auf jeder Plattform densel-benStil verwendet, sinddie Elemente in ihrerGröße leicht variabel, da beispielsweise daszugrunde liegende Font-Rendering unter-schiedlich ist oder die verwendeten Fontseben doch nicht komplett gleich sind. DieseProbleme sind jedoch lösbar, da die in Qtenthaltenen Widgets ihre benötigte Größemeist selbst berechnen können. Dies solltemanauchbei eigenenWidgets beachten, umDarstellungsfehler zu vermeiden.DieseGrö-ßeninformationen werden von Layouts inKombination mit weiteren Layout-Regelngenutzt, umWidgets inDialogenundAnwen-dungenmöglichst optimal anzuordnen. Sol-che Regeln beinhalten den Platz zwischenWidgets und die Größenänderung der Wid-gets, einzeln und relativ zueinander. Wid-gets, die nicht zu einem Layout gehörenwieetwa Dialoge, bestimmen ihre Größe selbstund damit auch den verfügbaren Platz füralle ihnen untergeordneten Widgets. Dieskann leicht zuWidgetsmit abgeschnittenemText führen.

Multimedia-Inhalteund -HardwareIn einer Gegenüberstellung der QWidgets

und der Unterstützung von Multimedia-In-halten in Qt zeigt sich deutlich, wie unter-schiedlich die Plattformunabhängigkeitumgesetzt werden kann.Während die grafi-schenDialogelemente dies durchkompletteseigenes Zeichnen erreichen, werden nurMultimedia-Inhalte unterstützt, die durchdie Plattform verarbeitet werden können.Unter Linux wird das Gstreamer-Backendverwendet, unterWindowsgibt es dasDirect-Show-Backend. Sollen Inhalte auf beidenPlattformen laufen,müssendie verwendeten

www.vogel.de

facebook.com/elektronikpraxis

youtube.com/elektronikpraxistv

gplus.to/elektronikpraxis

www.analog-praxis.de

xing.com/net/elektronikpraxis

twitter.com/redaktionEP

document2200552619313839082.indd 21 16.11.2016 13:55:06

http://www.analog-praxis.dehttp://www.vogel.de

22



len Features bieten, insbesondere durchManipulation von Elementattributen undAusführung von JavaScript.AuchdieAusgabe aufDruckern ist einfach.

VorhandeneDrucker sind enumerierbar unddieAusgabe erfolgtwie auf anderenWidgets.Die Unterstützung für das Drucken (oder Er-stellen) in einePDF-Datei ist direkt integriertundkannauchprogramminternwie einDru-cker angesprochen werden.Oft möchte man in Programmen auch auf

Dateien zugreifen. Auch dafür hält Qt Klas-senbereit. Sie reichen von einfacherVerwal-

tung von Dateien und Verzeichnissen überausgefeilte Abstraktionen als Input- oderOutput-Streamundnutzendie auf der jewei-ligenPlattformverfügbarenAPIs.Manmussjedochbeachten, dass diese Implementatio-nen inQt teilweise stark abstrahiert sindundnicht immer alle Informationender Plattformzur Verfügung stellen. So sind die Fehler-codes und Fehlertexte beim Zugriff auf Da-teien nicht zugänglich und nur stark verein-facht etwa durch QFile::FileErrors-Enumdargestellt. Es ist jedoch nicht schwierig,Alternativen inFormeigenerKlassen zu ent-wickeln, die auf die eigenen Bedürfnissebesser zutreffen und trotzdem die Qt-I/O-Streams unterstützen, somit letztlich auchins übrige Qt voll integrierbar sind.

Dateien und Input-/Output-Streams mit Qt nutzenQt stellt auch ein QFileSystem-Modell für

die Ansicht von Dateibäumen bereit, dasviele Prozessschritte in einen separaten Th-read auslagert und es somit vermeidet, denGUI-Thread zu blockieren. Das ist für vieleAnwendungszwecke ausreichend schnell.Bei Einsatzszenarienmit vielenTausendVer-zeichniseinträgenkannaber eineAlternativewünschenswert sein. Aktuell lässt es auchnoch die Handhabung von Hotplugging-Unterstützung unter Windows vermissen,währenddies unter Linux implizit durchdasBeobachten vonVerzeichnisänderungenge-geben ist.Die Nutzung von Qt-I/O-Streams ist auch

mit Netzwerkprotokollen möglich. Direktunterstützt werden HTTP und FTP als High-Level-Protokolle. Hier ist jedoch nur dieFunktionalität zur Handhabung des Inhaltsvon URLs enthalten. Insbesondere die Ver-waltung von FTP-Verzeichnissen gibt es seitQt5 nicht mehr direkt. Die Erweiterung umweitere Protokolle ist jedoch leichtmöglich.Dazukannmandie vorhandenenKlassen fürdie Low-Level-Protokolle TCP und UDP fürServer- und Client-Anwendungen verwen-den, auch ohne den aktuellen Thread zublockieren. Erfordert das Protokoll ver-schlüsselte Kommunikation mit TLS, so istauch dies integrierbar.Wenn man abseits von Netzwerkkommu-

nikation schaut, so gibt es in Qt5 auch Klas-sen, mit denen serielle Ports angesprochenwerdenkönnenoder der Bluetooth-StackderPlattform genutzt werden kann. Der Win-dows-Bluetooth-Stack von Microsoft wirdjedoch nicht unterstützt und die generelleAusrichtungder Implementierung scheint inRichtung Mobile Devices zu gehen. // FG

MixedMode

Verschiedene Qt-Stile: Die Fenster-Inhalte sind auf unterschiedliche Desktop-Oberflächen anpassbar

Bild:M

ixed

Mod

e

Codecs entsprechend gewählt oder zusätz-lich installiertwerden.DieAbhängigkeit vonexternen Implementationendürfte in diesemFall dieMöglichkeitenbezüglichunterstütz-ter Formate eher verbessert haben.Natürlich kannmanauch separateBiblio-

theken zumDekodieren auf beiden Plattfor-men nutzen. Für die Tonausgabe als rohenPCM-Stream stehen in der QtMultimedia-Bibliothek die passenden Klassen bereit.Leider variiert hier die Qualität der Imple-mentation stark. Insbesondere unter Linuxist sie nicht ganz unproblematisch, wennALSA und PulseAudio gleichermaßen gutunterstützt werden sollen. Auch auf die Er-kennungderHardware-Möglichkeiten sollteman hier nicht explizit setzen, da etwa dieSamplerate nur eine Auswahl üblicherWer-te testet und nicht den kompletten UmfangderHardware abdeckt. Dies schränkt jedochdie generelle Funktionalität nicht ein.MöchtemannichtMedien abspielen, son-

dern Audio- oder Videodaten aufzeichnen,so ist auch das einfachmachbar. Vorhande-neMikrofoneingänge oder Kameras könnenenumeriert werden und entsprechende Da-ten ausgelesen werden, um sie entwederdirekt wieder auszugeben oder passend ko-diert abzuspeichern. Wie beim Dekodierenvon Inhalten ist man beim Encodieren vondenverfügbarenCodecs imSystemabhängigoder nutzt zum Encodieren die passendenBibliotheken.Bilddateien sind deutlich einfacher zu in-

tegrieren. Alle wichtigen Formate wie BMP,JPG und PNG werden ohnehin direkt unter-stützt. HTML-Inhalte können durch den in-tegriertenBrowser direkt verarbeitetwerden.Die Technikdazu lieferte bis vor kurzemnochQtWebKit, während bei den neueren Qt5-VersionenQtWebKit vonQtWebEngine abge-löst wurde. Es basiert auf Chromium, derOpenSource-Variante von Chrome. BeideMöglichkeiten unterscheiden sich leicht inder Handhabung, sollten aber die essentiel-

PRAXISWERT

Erst prüfen, dannimplementierenMöchte man Plattformunabhängig-keit in einer Anwendung erreichen, sostellt Qt sehr viele Funktionen bereit,die das Erreichen dieses Ziels verein-fachen. Dennoch ist das Prüfen allereigenen Anforderungen auf allen ge-wünschten Plattformen unabdingbar.

Es gibt keinen KönigswegIn manchen Situationen hängt diePlattformunabhängigkeit nicht nurvon Qt selbst ab, sondern wird vonweiteren Komponenten maßgeblichbestimmt. In anderen Fällen bedie-nen verschiedene, plattformspezifi-sche Implementationen die eigenenAnforderungen unter Umständenbesser oder erweitern die vorhande-ne Implementation in Qt um weitereSpezialitäten oder Plattformen.

document2200552619313839082.indd 22 16.11.2016 13:55:08


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;Kristin Rinortner (kr), Analogtechnik, Mixed-Signal-ICs, Elektromechanik, Relais, Tel. -30 86;Margit Kuther (mk), Bauteilebeschaffung, Distribution, E-Mobility, Embedded Computing,Tel. -30 99;Freie Mitarbeiter: Prof. Dr. Christian Siemers, FH Nordhausen und TU Clausthal; Peter Siwon,MicroConsult; Sanjay Sauldie, EIMIA; Hubertus Andreae, dreiplusVerantwortlich für die FED-News: Jörg Meyer, FED e.V., Alte Jakobstr. 85/86, D-10179 Berlin,Tel. (0 30) 8 34 90 59, Fax (0 30) 8 34 18 31, www.fed.deRedaktionsassistenz: Eilyn Dommel, Tel. -30 87Redaktionsanschrift:München: 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: Agentur Print/Online

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

VERLAGVogel Business Media GmbH & Co. KG, Max-Planck-Straße 7/9, 97082 Würzburg,Postanschrift:Vogel Business Media GmbH & Co. KG, 97064 WürzburgTel. (09 31) 4 18-0, Fax (09 31) 4 18-28 43Beteiligungsverhältnisse: Vogel Business Media Verwaltungs GmbH,Kommanditistin: Vogel Medien GmbH & Co. KG, Max-Planck-Straße 7/9, 97082 WürzburgGeschäftsführung: Stefan Rühling (Vorsitz), Florian Fischer, Günter SchürgerPublisher: Johann Wiesböck, Tel. (09 31) 4 18-30 81, Fax (09 31) 4 18-30 93Verkaufsleitung: Franziska Harfy, 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.2016.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: 37.801 Exemplare (IV/2015).Angeschlossen der Informationsgemeinschaft zur Feststellung der Verbreitung vonWerbeträgern – Sicherung der Auflagenwahrheit.Bezugspreis: Einzelheft 12,00 EUR. Abonnement Inland: jährlich 235,00 EUR inkl. MwSt.

Abonnement Ausland: jährlich 266,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 elektromobilität PRAXIS

MitThemen aus

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

...von den Rahmenbedingungenzum technischen Fachwissen

...vom Leistungshalbleiterzur Ladeinfrastruktur

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

0869

1

www.vogel.de

document1765871993600980472.indd 23 16.11.2016 11:22:01

http://www.fed.demailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://www.datam-services.dehttp://www.elektronikpraxis.dehttp://www.vogel.dehttp://www.genios.demailto:[email protected]:[email protected]:[email protected]://www.vogel-europublishing.comhttp://www.mycontentfactory.dehttp://www.elektromobilit�t-praxis.dehttp://www.vogel.de

24

PROJEKTWISSEN // TRENDS


So sieht zukunftsfähige Embedded-Softwareentwicklung aus

Die Experten von MicroConsult diskutieren die Bedeutung vonSoftwarearchitekturen und Frameworks. Dabei wird das Thema Soft-

ware Engineering aus verschiedenen Blickwinkeln beleuchtet.

PETER SIWON *

* Peter Siwon... ist für das Business Developmentder MicroConsult GmbH verantwort-lich.

Ohne Zweifel wurde der Entwicklungvon Embedded-Software noch nie soviel öffentliche Aufmerksamkeit ge-schenkt wie heute.Internet of Things, Industrie 4.0, autono-

mes Fahren, Smart Building, Smart City,Smart Healthcare, und dergleichen, derSmartphone-Boom mit seinen Apps, aberleider auch der VW-Abgasskandal wecktenauch außerhalb der Fachmedien viel Auf-merksamkeit für Embedded-Software.Embedded-Software ist allgegenwärtig

und stellt einen wichtigen Faktor dar, wenn

es um Komfort, Sicherheit, Nachhaltigkeitund Innovation geht. Keiner kommtmehr anihr vorbei. Sogar in der Bekleidungsindustriebestimmt sie Funktion,NutzenundAttrakti-vität der sogenanntenWearables.Doch worauf kommt es bei all diesen

Trends vor allem an, wenn es um das Soft-ware-Engineering geht?Wir fragtenThomasBatt,MarcusGößler, FrankListingundRemoMarkgraf, die als Trainer und Berater fürEmbedded-Technologien seit vielen JahrenKundenaus allen Industriebranchenbeglei-ten.Ambesten fangenwir bei unserer Betrach-

tung ganz unten an, beim Mikrocontroller:Marcus Gößler ist Spezialist für Mikrocont-roller beiMicroConsult und sammelte vorherumfassende Erfahrungen als Field Applica-tion Engineer und Leiter der Field Applica-

tion bei großen Halbleiterherstellern. Seinbesonderer Fokus liegt auf der Multicore-Technologie, die mehr und mehr bei denMikrocontrollern an Bedeutung gewinnt.

Das Potenzial von Multicoreerschließen„Mit demThemaMulticoremuss sichüber

kurz oder lang wohl jeder Embedded-Ent-wickler beschäftigen,wenn er nicht denAn-schluss verlieren will. Die Frage ist wenigerob, sondernwanndas ersteMulticore-basier-te Projekt realisiert wird. Multicore ist Reali-tät undmehr Kerne undmehr Hersteller mitMulticore-Derivaten werden den Markt be-treten. Eine Abstrahierung der Hardware istdabei von großer Bedeutung, damit die Ver-teilung und Verwaltung von Software aufdiese komplexe Hardware effizient möglichist. Gerade hier gibt es aktuell allerdingsnoch Nachholbedarf“, so sein Tenor.Doch was bedeutet „beschäftigen“? Mar-

cus Gößler ist davon überzeugt, dass der ef-fiziente Einsatz vonMulticore ein sehr gutesVerständnis der Hardware-Architektur vor-aussetzt. Sie ist der Grundstein für die Ent-wicklung einer Software-Architektur, die dasLeistungspotenzial von Multicore auch tat-sächlich erschließt und die Unabhängigkeitund damit auch die Sicherheit gleichzeitigablaufender Tasks gewährleistet. Maßnah-men, um diese Unabhängigkeit und Sicher-heit auch überprüfen bzw. Fehler diagnosti-zieren zu können, kommen ins Spiel. Fallsdie einzelnenKernenicht völlig unabhängigoperieren, sondern interagieren, müssenMaßnahmenergriffenwerden, um fehlerhaf-te gegenseitige Beeinflussungen zu vermei-den. Dies spielt üblicherweise bei Datenzu-griffen eine Rolle, beispielsweise im Zusam-menhang mit verwendeten Caches. DesWeiteren sind multicore-spezifische Dingewie Code- und Datenallokation zu betrach-ten. Die optimale Abstimmung von Hard-warearchitektur undSoftwarearchitektur imSinne von Leistungsgewinn und Sicherheit

Alte, gewachsene Architektur hat durchaus ihren Reiz: Bei Software können wir uns Nostalgie in der Regelnicht leisten.

Bild:Siwon

document8837191211663072454.indd 24 16.11.2016 14:16:09

25



erfordert ein fundiertes Verständnis dieserbeiden Aspekte.Der Blick indieGegenwart unddie Zukunft

zeigt deutlich, dass die Embedded-Welt unddie IT-Weltmiteinander verflochten sindundsich immer mehr verflechten werden. Em-bedded-Systemewerden zumBestandteil desInternet of Things, das sich zu einem Internetof Everything entwickelt.

Interdisziplinäre Kooperationist gefragtFrank Listing betont, wie sehr klassische

Embedded-Systeme (etwa Produktionsma-schinen) bereits heute mit Smartphones,Tablets, PCs und Servern interagieren. Er istSpezialist für denEinsatz vonPC- undSmart-phone-Technologien im Embedded-Umfeldund war vorher selbst viele Jahre als Soft-wareentwickler undSoftwarearchitekt in derKommunikationsbranche tätig. DieMensch-Maschine-Kommunikation läuft zum Bei-spiel über SmartphonesundTablets, die sichmehr und mehr zu universellen Kommuni-kationsschnittstellen in allen Richtungenmausern. Doch der Komfort und die Vernet-zung hat seinen Preis: Das Thema Security,also der Schutz gegen unautorisierte Zugrif-fe auf die Maschinen oder was immer überdas Internet of Everything erreichbar seinwird, gewinnt massiv an Bedeutung.Eine sehr viel höhere Kompetenz und en-

gere Zusammenarbeit von Embedded- undIT-Spezialistenunter demAspekt Security istnötig, um keine Einfallstore für Cyberkrimi-nalität zu öffnen.Auchhier sinddurchdach-te Systemarchitekturen erforderlich, diediese Sicherheit gewährleisten und gleich-zeitig genügendFlexibilität für Systemerwei-terungen und Innovationen bieten.Frank Listing betont außerdem, dass die

Projektteams neben C/C++ auch C#, JavaoderHTML5mit JavaScript beherrschenmüs-sen, um den neuen Anforderungen gerechtzuwerden. Die Gräben zwischen IT undEm-bedded müssen schnellsten zugeschüttetwerden, interdisziplinäre Projektarbeit istgefragt.

Softwarearchitektur-Design istein MussThomas Batt, der bei MicroConsult das

Thema Softwareengineering und Prozesseverantwortet, schlägt in dieselbe Kerbe. Ersieht, dass immer mehr Firmen den Nutzeneiner definierten Softwarearchitektur zwarerkennen, doch derWeg aus demSumpf derSoftwarealtlasten ist beschwerlich.Die Art, wie Embedded-Software sehr oft

in derVergangenheit entwickeltwurde (odersollteman sagenverwickeltwurde?) führt in

eine Sackgasse und stellt ein wachsendesSicherheitsrisikodar. Die steigendeKomple-xität in Verbindung mit wachsenden Anfor-derungenanSafety (Betriebssicherheit) undSecurity (Systemschutz) stellt hohe Ansprü-che an die Softwarearchitekturen und dieQualität der Implementierung. Dies wieder-um spricht für den Einsatz bewährter Soft-warekomponenten (Betriebssysteme, Stacks,

Ökosysteme:Embedded-Software istBestandteil immer kom-plexerer Ökosysteme,die sich sehr dynamischverändern.B

ild:M

icroConsult

Filesysteme, etc.) unddieAnwendungobjek-torientierter Methoden mit Hilfe von Hoch-sprachen wie C++.Ziel muss es sein, der schleichenden Soft-

ware-Erosion vonAnfang an entgegenzuwir-ken.Ausder Sicht vonThomasBatt, der überlangjährige Projekterfahrung inder Industrieverfügt, hat diese Erkenntnis auch dazu ge-führt, dass dem Requirements-Engineering

H

SIG

HPE

ED

ROBU

ST

FLEX

IBLE

TriCore PowerArchitecture•

Cortex M/R/ ARM7/9/11A •

RH850 • XC2000/XE166

Anzeige

document8837191211663072454.indd 25 16.11.2016 14:16:11

26



Die Zukunft des Embedded-DesignsDie rasante Entwicklung vom Internet ofThings zum Internet of Everything machteine enge Zusammenarbeit von Embed-ded und IT überlebenswichtig. Systemeund Software müssen den Ansprüchendieser dynamischen Zukunft gewachsensein, in der wir heute noch nicht wissen,

welche Applikation, Funktion oder Tech-nologie morgen wettbewerbsentschei-dend sein werden. Der professionelleEntwurf von flexiblen und sicheren Sys-tem- und Softwarearchitekturen sowieEmbedded-taugliche, agile Frameworkswerden eine Schlüsselrolle spielen.

und -Management sowie der Softwaremodel-lierung mehr Aufmerksamkeit geschenktwird. Der Umstieg auf höhere Abstraktions-ebenen inKombinationmit professionellemSoftwareengineering ist unerlässlich, umderKomplexität Herr zu werden.Ein weiteres Mittel, um Komplexität, er-

höhte Sicherheitsanforderungenund schnel-le Produktzyklen in den Griff zu bekommensindBetriebssysteme, die denApplikationender Hersteller zuarbeiten. Es kommt nichtvon ungefähr, dass sich Embedded Linuxgroßer Beliebtheit erfreut. Das liegt nicht nurdaran, dass die Lizenzkosten entfallen. Eswird immerwichtiger, dass dieApplikations-entwickler sich vondenDetails derHardwarelösenundaufwichtige

Documents

Embedded Software Engineeringfiles.vogel.de/vogelonline/vogelonline/issues/ep/2016/642.pdf · ©ARM Ltd |AD468 i.MX7 ARMCortex-A7 ARMCortex-M4 Linux kernel RTOS system Linux application