09:45 Uhr
The Challenge of Scalability for Functionally Safe Software Systems
.
Details anzeigen
Autor:in:
Nikola Velinov | Green Hills Software | Germany
Sprache:
English
Zielgruppe:
Embedded Software Developers, Project Managers and Engineering Management
Voraussetzungen:
.
Überblick und Zusammenfassungen:
The number of software driven functions in automotive, medical, industrial, railway and infrastructure that are critical for the safety of mankind is rapidly increasing. The software architectures that implement the safety functions vary widely in their shape and form – from complex data driven autonomous driving to a simple and robust e-fuse. The commonality between these safety functions is the need to fulfil industry safety standards requirements. The session begins by focusing on the simplest of these systems. It discusses an approach to address the requirements using a lean open platform that enables modular application development and deployment. The session will then discuss how these systems fit into an industry trend which aims to establish a homogeneous application development and deployment process across safe and non-safe software functions.
Art der Vermittlung:
Presentation
Nutzen:
.
10:15 Uhr
MISRA C and ISO 26262 – What’s New?
MISRA C and ISO 26262 – What’s New?
Details anzeigen
Autor:in:
Andrew Banks | LDRA
Sprache:
English
Zielgruppe:
Software development and engineering
Voraussetzungen:
None required
Überblick und Zusammenfassungen:
In the automotive software world, ISO 26262 and MISRA C are inextricably linked. So much so, that ISO 26262-6:2018 (like it’s 2011 predecessor) explicitly cites MISRA C as a way of fulfilling many of the requirements.
This topic was addressed in the presentation MISRA C in an ISO 26262 Context at the AESIN ISO 26262 Practitioners’ Workshop, in February 2019.
But MISRA C has continued to evolve, throughout the covid lock-down… this presentation will briefly outline the changes to MISRA C and the road-map ahead, while giving the latest news on the progress to the new MISRA C++.
Art der Vermittlung:
Practical examples and methodologies
Nutzen:
MISRA C has continued to evolve, throughout the covid lock-down… this presentation will briefly outline the changes to MISRA C and the road-map ahead, while giving the latest news on the progress to the new MISRA C++.
10:45 Uhr
5 Schritte zum Erfolg bei der Konsolidierung von Mixed-Criticality Systemen mittels Hypervisor
Heutige 64-Bit-Hardware reicht doch locker, um die Aufgaben mehrerer älterer Systeme zu übernehmen - oder?
Details anzeigen
Autor:in:
Malte Mundt | BlackBerry QNX | Germany
Sprache:
Deutsch
Zielgruppe:
Embedded-Entwickler, Projektleiter
Voraussetzungen:
Grundkenntnisse in der Embedded-Entwicklung mit ARM Cortex A oder Intel x86 Architekturen
Überblick und Zusammenfassungen:
5 Schritte zum Erfolg bei der Konsolidierung von Mixed-Criticality Systemen mittels Hypervisor
In der Embedded-Welt gehört er für einige längst zum Alltag, für andere ist er noch Zukunft: Ein Hypervisor. Im Auto, aber auch in den Bereichen Medizingeräte, Industrie-Automatisierung oder Bahntechnik – häufig werden im Gesamtsystem viele kleine und größere Embedded-Devices eingesetzt. Über Jahre hatten diese wenig miteinander zu tun, dann wurden sie zunehmend vernetzt. Doch heute wird vor allem über eins gesprochen: Konsolidierung. Kostendruck und Lieferengpässe führen immer häufiger dazu, dass der traditionelle Ansatz infrage gestellt wird. Schließlich steht heute 64-Bit-Embedded-Hardware zur Verfügung, deren Leistungsfähigkeit „eigentlich locker“ für die Aufgaben von mehreren älteren Systemen ausreichen sollte.
Für die Konsolidierung wird in der Regel ein Hypervisor benötigt, denn damit lassen sich mehrere Betriebssysteme bzw. OS-Instanzen parallel auf einem SoC betreiben. Da oft auch Ausfallsicherheit bzw. Funktionale Sicherheit eine große Rolle spielt, wird der Hypervisor natürlich auch zum Werkzeug zur Isolation von Applikationen – samt der Betriebssysteme, auf denen diese laufen.
Für QNX als Hersteller von Embedded-OS und -Hypervisor hat dieser Themenkomplex schon längere Zeit immer mehr Bedeutung gewonnen. Ich möchte deshalb zum ESE-Kongress 2022 die Quintessenz aller gemachten Erfahrungen kurz zusammenfassen, die wir mit Großkunden in den letzten Jahren gesammelt haben. Klar ist: Am Whiteboard geplante Visionen mit 8 bis 16 virtuellen Maschinen können schnell zur Utopie werden, wenn vom Unternehmensmanagement aus Kostengründen lediglich ein SoC mit zwei Cortex A53 und schmalbrüstiger Speicheranbindung vorgesehen wird. Denn mit jeder virtuellen Maschine kommt ja ein OS mit Memory-Manager, Scheduler und vielem mehr, welche nicht nur CPU-Zeit, sondern auch Speicher benötigen. Und: Sie müssen gebootet werden, was aber je nach Anwendungsfall sehr schnell zu gehen hat. Damit stehen Entwickler vor einigen Herausforderungen.
Nicht immer jedoch braucht man zur Konsolidierung von Software gleich mehrere virtuelle Maschinen, denn Embedded-Betriebssysteme auf Microkernel-Basis bieten von Haus aus schon mächtige Werkzeuge zur Isolation – Stichwort „Freedom from Interference“. Mit einem zum Hypervisor ausgebauten Microkernel-OS ergeben sich damit für jede Applikation mehrere Optionen: Isoliert in einem virtuellen Adressraum mittels MMU, oder inkl. passendem Betriebssystem in einer virtuellen Maschine, welche wiederum mit einer modernen 2-Stufen-MMU isoliert wird. Idealerweise bietet das SoC zusätzlich noch eine systemweite MMU (SMMU), die nicht nur CPU-Zugriffe, sondern alle Bus Mastering Devices (Stichwort: DMA) überwachen kann.
In der Präsentation wird es um 5 Punkte gehen, die essenziell sind, um beim Konsolidieren mithilfe eines Hypervisors erfolgreich zu sein:
• Evaluierung des existierenden Codes: Welche Abhängigkeiten von OS und Hardware sind vorhanden?
• Device-Sharing: Erst wenn sich virtuelle Maschinen bestimmte Peripherie teilen, werden wirklich Kosten gespart – doch wie funktioniert das?
• Echtzeitanforderungen und schnelles Hochfahren: Was ist diesbezüglich zu beachten, wenn ein Hypervisor eingesetzt wird?
• Welche Chancen für neue, innovative Features des eigenen Systems bietet die Nutzung eines Hypervisors?
• Sicherheitskritische Anwendungen: Wie schützt man sie vor Fehlverhalten von anderen, weniger kritischen Applikationen?
Art der Vermittlung:
Preconference
Nutzen:
Die Erkenntnisse aus diesem Vortrag werden dem Nutzer viel Zeit, Geld und Nerven sparen...
11:15 Uhr
Security im Variantenwald
Wie die Hyper-Coverage versteckten Code aufdeckt
Details anzeigen
Autor:in:
Michael Wittner | Razorcat Development GmbH | Germany
Sprache:
Deutsch
Zielgruppe:
Test und Entwicklung
Voraussetzungen:
keine speziellen Vorkenntnisse
Überblick und Zusammenfassungen:
Bei der Zertifizierung sicherheitskritischer Software wird neben umfangreichen und normgerechten Tests aller Varianten eines Source-Codes ein Nachweis für die vollständige Abdeckung dieses Source-Codes verlangt. Bei der kumulierten Hyper-Coverage wird mit gängigen Coverage-Messungen ein Zusammenhang zwischen Code-Varianten und gemessener Code-Coverage auf der Basis des originalen Source-Codes berechnet. Die natürlichen Grenzen von Coverage-Messungen unterschiedlicher Code-Varianten werden dadurch überbrückt und erlauben eine kumulierte Zusammenfassung auf Quelldateiebene.
Jeglicher Code in einer Programmquelle wird dabei vollständig erfasst, selbst wenn dieser nicht durch Code-Varianten abgedeckt wird. Durch einen Abgleich der ermittelten Coverage-Werte und der Code-Varianten mit der Quelldatei werden versteckte Funktionen und Programmblöcke in der Quelldatei aufgedeckt, was die Security deutlich erhöht.
Art der Vermittlung:
Vortrag mit Projektbeispielen
Nutzen:
Die neue Hyper-Coverage ermittelt auf Basis der Quelldatei alle Funktionen und den enthaltenen Code in jeder einzelnen Zeile, so dass im Hinblick auf Security etwaiger versteckter Programmcode ausgeschlossen werden kann (z.B. durch ein nicht dokumentiertes Define beim Compileraufruf).
Der Vortrag befasst sich mit den folgenden Themen:
- Programmcode (Source-Code), Varianten und was der Compiler letztlich sieht
- Berechnung der durch Tests erfassten Code-Zeilen bereits nach der Analyse
- Zusammenhänge zwischen Flow-Chart und Source-Code
- Wie man die Code-Coverage trotz bedingter Kompilierung dem Code zuordnen kann
- Wie Coverage-Daten aus Systemtests und Object-Code-Coverage mit der Source-Code-Coverage kombiniert werden können
Es werden Möglichkeiten aufgezeigt, wie man mit den gängigen Coverage-Messungen, wie z.B. Branch- oder MC/DC-Coverage, eine vollständige Hyper-Coverage auf Quelldateiebene erreichen und dadurch versteckten Code aufdecken kann.
11:45 Uhr
Warum sollte ich testen?
Meine Software funktioniert, wenn ich sie einchecke!
Details anzeigen
Autor:in:
Marius Schmidt | QA Systems GmbH | Germany
Sprache:
Deutsch
Zielgruppe:
Softwaretester, Softwareentwickler, Entscheider. Insbesondere solche, die mit Funktionaler Sicherheit und sicherheits-relevanten eingebetteten Systemen und Industrie-Standards arbeiten.
Voraussetzungen:
Grundkenntnisse im Testen von C/C++ Code
Überblick und Zusammenfassungen:
Murphys Law - „Alles, was schiefgehen kann, wird auch schiefgehen.“
Wie bekannte und oftmals sehr teure Softwarefehler gezeigt haben, kann es in jeder Software Verhalten geben das vom Entwickler nicht bedacht wurde. Das kann zu kleineren Problemen führen, oder auch in Katastrophalem Fehlverhalten enden. Die Explosion der Ariane 5 oder der Verlust des Mars Climate Orbiters sind dabei nur zwei Beispiele von vielen.
Was können wir also tun, um ein solches unerwartetes Verhalten zu vermeiden? Wie gehen wir am Besten vor, um unsere Software weniger fehleranfällig, besser wartbar und alles in allem robuster zu machen.
Sehen wir uns gemeinsam an, wie die statische Source Code Analyse bzw der Unit und Integrationstest uns dabei unterstützen.
Art der Vermittlung:
Interaktive Präsentation mit PPT Folien / Vortrag
Nutzen:
Tipps und Lösungen für Tester und Entwickler zur Verbesserung der Softwarequalität
12:15 Uhr
Trace Your System with the Smallest Overhead
.
Details anzeigen
Autor:in:
André Schmitz | Green Hills Software | Germany
Sprache:
English
Zielgruppe:
Embedded Software Developers, Project Managers and Engineering Management
Voraussetzungen:
.
Überblick und Zusammenfassungen:
Collecting trace data from an embedded system to analyse bug or performance bottlenecks is common practice. But what kind of “trace” do you want to use to do that? For some engineers trace means thousands and thousands of printf() outputs on the serial console, for others this is hardware trace and in some cases we are talking about analysis by using code instrumentation in conjunction with and a suitable software tool. All these different approaches have their pros and cons, such as their runtime overhead or their memory overhead. This presentation discusses different methods of tracing program flow and compares their overhead. The audience will understand important differences in trace techniques to make the right decisions in the testing and analysis strategy of software projects. It might help to get away from old, inefficient methods of software troubleshooting and towards modern methodologies. The methods and measurement results presented are based on our own studies and experience in supporting complex customer projects.
Art der Vermittlung:
Presentation
Nutzen:
.
13:45 Uhr
Sourcecode besser verstehen durch neue Blickwinkel
Mit Tabellen und Diagrammen einen (schnellen) Überblick gewinnen
Details anzeigen
Autor:in:
Martin Stockl | Willert Software Tools | Germany
Sprache:
Deutsch
Zielgruppe:
Embedded Software Entwickler
Voraussetzungen:
Keine
Überblick und Zusammenfassungen:
Um Sourcecode verstehen, nutzen und warten zu können, benötigen wir vielerlei Informationen. Das sind im Embedded Software Bereich zum Beispiel die Anforderungen nach denen er entwickelt wurde, aber auch Informationen zum Laufzeitverhalten, zum statischen und zum dynamischen Speicherverbrauch, zur Art der Speicherverwendung, zur Initialisierung von Parametern, zu verwendeten Betriebssystemmitteln wie Threads und deren Prioritäten, oder wie Mutexen und die durch sie gelockten Elemente, etc.
Viele dieser Informationen sind in der einen oder anderen Form zwar implizit im Sourcecode enthalten, aber entweder nicht einfach zu entdecken bzw. zu extrahieren, oder aber diese Informationen überfrachten den Code in Form von Kommentaren derart, dass der Sourcecode für den Entwickler beim Debuggen kaum noch lesbar und handhabbar ist.
Daher wäre eine direkte Verknüpfung des Sourcecodes mit diesen dennoch sehr wichtigen Zusatzinformationen, die den Sourcecode dabei aber nicht überfrachtet, sehr hilfreich.
Ich möchte an Beispielen aufzeigen, wie beschreibende Diagramme und Tabellen, sowie eine wirkliche Traceability zu den Anforderungen mit der Hilfe mehrerer Werkzeuge einfach wartbar und dauerhaft nachverfolgbar hergestellt werden können.
Art der Vermittlung:
Präsentation und praktische Demo
Nutzen:
Besseres Verständnis darüber, wie man SourceCode mit weiteren Informationen verlinken kann.
14:15 Uhr
Abgeschätzte Timing-Informationen während der Programmierung nutzen
Beispielhafte Entwicklung eines Kalmanfilters für einen Infineon AURIX®
Details anzeigen
Autor:in:
Oliver Oey | emmtrix Technologies GmbH
Sprache:
Deutsch
Zielgruppe:
Software-Entwickler
Voraussetzungen:
Grundkenntnisse in einer Programmiersprache
Überblick und Zusammenfassungen:
In dieser Präsentation zeigen wir, wie die statische Performanzabschätzung bereits während der Funktionsentwicklung wichtige Informationen liefern kann. Am Beispiel eines Kalman-Filters, der auf einem Infineon AURIX® TC3xx ausgeführt werden soll, wird deutlich gemacht, welche Auswirkungen Optionen wie Genauigkeit, Datentypen oder Implementierungsdetails auf die Laufzeit der Anwendung haben. Dabei wird kein Simulator oder die Hardware eingesetzt, sondern rein auf die Informationen aus dem Quellcode sowie die Optimierungen des Compilers gesetzt.
Art der Vermittlung:
Entwicklung anhand eines Beispiels in einer Präsentation
Nutzen:
Der Vortrag vermittelt den Zuhörern ein besseres Gefühl zur Einschätzung von Codeänderungen auf die Laufzeit auf den späteren eingebetteten Systemen. Zudem wird gezeigt, wie Hotspots in Anwendungen schnell und einfach identifiziert werden können, um Optimierungen gezielt auf diese Bereiche anwenden zu können.
14:45 Uhr
Integration of Safety Related and Non-Safety Related Functionality on the Same HW (Mixed Criticality on a Single HW)
The RTS Safe hypervisor is an OS-independent functional safety-certified Type 1 hypervisor to target mixed-critical workloads based on x86 multicore processor technologies.
Details anzeigen
Autor:in:
Andrea J. Beuter | Real-Time Systems GmbH | Germany
Sprache:
Englisch
Zielgruppe:
Engineering
Voraussetzungen:
keine
Überblick und Zusammenfassungen:
Integration of safety-related and non-safety-related functionality on the same HW (mixed criticality) More functionality in applications, interaction with humans, being connected, work collaboratively as well as autonomously require fast, precise, and deterministic controls with the Functional Safety Requirements and Cybersecurity Demands.
Art der Vermittlung:
Power Point Presentation
Nutzen:
Reduced system costs and physical size through hardware consolidation
Hard real-time performance
Maximum flexibility in system functionality
Increased reliability (MTBF) as no additional hardware is required for additional operating system
Works seamlessly with COTS and proprietary operating systems
Runs on any PC from low-power modules to multi-socket servers
OS independent
Works out-of-the-box without customization
Proven in thousands of systems worldwide