automotive spice -凯发k8网页登录

automotive spice (software process improvement and capability determination) ist ein reifegradmodell zur bewertung der leistungsfähigkeit von prozessen im bereich der entwicklung von embedded systemen für automotive anwendungen. ziel ist eine hohe produktqualität zu erreichen und entwicklungsprozesse von unterschiedlichen unternehmen vergleichbar und somit auf einen idealisierten prozess bezogen bewertbar zu machen. aus der erfahrung zeigt sich, dass sorgfältig etablierte und gereifte entwicklungsprozesse dazu beitragen, das auftreten von fehlern in den produktimplementierungen zu vermeiden. für den automotiven entwickler beschreibt das prozessreferenzmodell von automotive spice in bild 1 die notwendigen prozessschritte, die einzuhalten sind und im rahmen eines automotive spice audits vom assessor auf vorhandensein bzw. durchführung und deren reifegrad bewertet werden.

software engineering process group - software detailed design

im speziellen beschreibt die prozessgruppe „software engineering process group“ die einzelnen prozesskategorien (swe.1 – swe.6), die bei einem gereiften softwareentwicklungsprozess vorhanden sein müssen. insbesondere die kategorie „software detailed design and unit construction“ (swe.3) beschreibt zusammen mit den sogenannten base practices (bp) und work products, welche aktivitäten im rahmen des software designs durchzuführen sind und welche messbaren artifakte als ergebnis aus den practices zu erstellen sind. unternehmen in der automobilindustrie setzen modellbasierte entwicklung in simulink ein, um ein detailliertes, dokumentiertes und bidirektional nachverfolgbares softwaredesign zu erstellen, das einfach mit anderen gruppen ausgetauscht und kommuniziert werden kann. ein vorteil der modellbasierten entwicklung mit simulink im rahmen des software detailed design von automotive spice besteht darin, dass bereits in der frühen phase designentscheidungen gegen die anforderungen mittels simulation verifiziert werden können. abgeleitet aus den anforderungen können die funktionalen designentscheidungen dann mittels einer ausführbaren spezifikation in form eines simulationsmodells in simulink schrittweise verfeinert und in ein software detailed design in simulink entwickelt werden, welches im anschluß als implementierungsmodell für die finale seriencodegenerierung des steuergerätes verwendet wird.

software engineering process group - software unit verification

die kategorie “software unit verification” (swe.4) beschreibt mit den zugehörigen base practices und work products die anforderungen an die verifikation der zu testenden software unit. dabei ist das ziel die konformität der software unit mit dem zuvor erstellten software detailed design in bezug auf seine funktionalen und nicht-funktionalen anforderungen (z.b. misra c) zu verifizieren. im anschluß an die initiale definition der teststrategie und der festlegung der verfikationskriterien ist vom entwickler nun einem nächsten schritt der zuvor mittels embedded coder generierte softwarecode zu verifizieren. die statische code analyse wird dazu verwendet, um z.b. die konformität mit codierungsstandards with misra c zu verifizieren oder evtl. laufzeitfehler im code aufzudecken. für die statische codeanalyse wird polyspace verwendet. anschließend kann äquivalenztest durchgeführt werden, um die konformität des generierten codes mit dem modell in simulink zu verifzieren. zum einen bietet sich ein back-to-back testing im rahmen einer numerischen äquivalenzprüfung an mit dem eine funktionale äquivalenz verifiziert werden kann. simulink test unterstützt den äquivalenztest sowohl für eine software-in-the-loop als auch eine processor-in-the-loop verifikation mittels einer intuitiver definition, management und ausführung der benötigten unit tests. neben der funktionalen äquivalenz kann aber auch noch einen strukturelle äquivalenzprüfung von modell und generiertem code mittels coverage messung in simulink test durchgeführt werden. welche äquivalenzprüfung im konkreten zu verwenden ist hängt davon ab, welche anforderungen der hersteller an seinen zulieferer im rahmen des software unit tests stellt und welche dann im zuge eines automotive spice assessments vom hersteller überprüft werden. durch verwendung von simulink test, simulink check, simulink coverage und requirements toolbox lässt sich unmittelbar eine bidirektionale nachverfolgbarkeit zwischen testspezifikation und dem detailed design in form des simulink modells herstellen als auch den zugehörigen testergebnissen.