Folge 123: Testbarkeit ist eine Architekturentscheidung

00:00:13: Herzlich willkommen im wohl innovativsten Schuppen zu unserem Podcast Embedded Vision aus der Gartenhütte.

00:00:18: Heute wollen wir uns mal dem Thema Testparkheit ist eine Architekturentscheidung annehmen, aber zunächst möchte ich natürlich meinen Chorus begrüßen.

00:00:26: Hallo Manuel!

00:00:27: Hallo Stefan schön auch die Woche wieder dabei zu sein.

00:00:29: Genau heute wollten wir uns ja mal den Thema Testen und Testparkkeit annehmen.

00:00:36: am Ende vom Tag wie man natürlich eigentlich zum guten System kommt ... wenn einfach Fehler auftreten, wie ich da in das Urwerk reinschauen

00:00:46: kann.

00:00:46: Ja es ist ja natürlich schon so... Wenn quasi Kunden zu uns kommen ganz oft ist einfach die Standard-Funktionalität steht im Mittelpunkt.

00:00:54: also was will ich bauen?

00:00:55: eine Kammer war und das heißt es wird beschrieben wie soll die ISP sein?

00:01:00: Wie sollen die Interfaces sein usw.

00:01:03: Und dann geht man in die Entwicklung sein und entwickelt Hardware Software FPGA Und am Ende vom Tag steht dann da ein Gesamtsystem.

00:01:14: Das hat das mal die Funktionalität, oder hat sie das?

00:01:19: Das ist immer die Frage!

00:01:20: Habe ich alle Erwartungen erfüllt?

00:01:22: und natürlich muss sich dann während der Entwicklung entsprechend auch schonmal die Weichen legen, dass wenn quasi später das Produkt darliegt... Ich die Möglichkeit habe, auch das Ganze abzutesten.

00:01:37: Das kann ganz viele Auswüchse haben.

00:01:40: Wir haben jetzt im Vorfeld zum Podcast ein bisschen philosophiert, wenn man an das härtes Schnittstelle ist will ich auch mal sehen ob die physikalischen Signale auf meiner Hardware laufen so sind wie ich es mir erwartet habe.

00:01:58: Also ich sage mal, ob die Verbindung zum Beispiel schon da ist.

00:02:01: Eigentlich alles funktioniert aber viel schlechter wie man denkt und da bieten ja auch manche Chips einfach die Möglichkeit, ein bisschen reinzuschauen.

00:02:11: Wie ist denn gerade die Linkqualität?

00:02:14: Das kann man dann zum Beispiel nutzen oder in seiner Architektur einbauen das beim Hochfahren des Systems eine Art Selbstdiagnose anstößt, solche Schnittstellen dann auch analysiert werden können.

00:02:31: Dass man wirklich sieht ja nee scheint alles in Ordnung zu sein oder Ups.

00:02:35: Datenübertragung funktioniert aber viel schlechter wie gedacht.

00:02:38: eigentlich stellt mir gar kein Problem fest aber vielleicht ist es so ein Hinweis dass irgendwo ein Kabel geknickt ist oder man ungünstliche Kabel verwenden.

00:02:46: aber das ist ja nur das eine Thema.

00:02:47: oftmals ist es ja dann so irgendwie die Detektion oder die Detektionsgenauigkeit von Neuronalnetz funktioniert nicht.

00:02:55: Man hat vielleicht sogar das Szenario irgendwie haltwegs im Griff, man hat es ins Labor gebracht.

00:03:01: und jetzt aber trotzdem die Frage warum ist es denn so?

00:03:04: Dann ist es schon clever wenn wir einfach auch mal an den einzelnen Strecken vor der KI die Daten abgreifen kann, wenn man zum Beispiel an die Rohdaten rankommt.

00:03:16: An die Daten rankommt nach der ersten ISP-Stufe.

00:03:20: An den Daten rankommen keine Ahnung.

00:03:21: vielleicht wird irgendwas auch noch komprimiert oder wie auch immer was aber nicht unbedingt heißt dass ich für jeden dieser Punkte jetzt unbedingt in meiner ECU eine Schnittstelle braucht.

00:03:32: Manchmal kann es ja auch sein, dass man mit einem Tool, dem Werkzeug oder der ProFrame einfach eine externe Schnittsstelle mit ein Art T-Link die Rohdaten abgreift.

00:03:40: Oder ich baue wirklich einen Rohdatapuffer im mein System ein.

00:03:45: also da gab's auch viele Fälle in der Vergangenheit.

00:03:48: Ich kann mich dann an einen erinnern von einem prominenten Kamerahersteller Der wirkliche Early Debug Buffer in seiner FPGA Architektur wollte, um einfach die Sensordaten ohne große Verarbeitung rauszubekommen.

00:04:03: Weil dann halt das ganze Pre-Processing mit Deadpixel Korrektur und mit Pixel Calibration so aufwendig war dass er schon vorher und nachher im Zweifelsfall wenn es eben sein muss beobachtbar haben wollte.

00:04:17: Um dann einfach, wenn ganz am Ende irgendwo ein Pixel blinkt diesen Pixel irgendwie nach vorne in der Kette bringen zu können.

00:04:25: Und da gibt es so viele Beispiele, wo man eigentlich immer dran denken muss vielleicht auch hier und dann Formatcheck einzubauen wenn's möglich ist.

00:04:34: ich erwarte von irgendeiner Peripherie von irgen meiner ISP ein Bitformat.

00:04:40: neunzehntzwanzig auf tausend achtzig Auf einmal kommen aber Bilder die viel größer oder kleiner sind je nachdem wie klug meine ISP ist.

00:04:48: kann sie vielleicht damit umgehen?

00:04:50: Die Frage aber, ich sollte es zumindest erkennen dass da gerade irgendwas passiert was sich eigentlich gar nicht will oder wann Daten kommen.

00:04:57: Diese ganze Beobachbarkeit die natürlich dann auch wenn man Software- oder Systemkomponenten integriert muss mir das teilweise auch nachweisen so das Timing von der Bildaufnahme zu der Bildverarbeitung Wann kommt das erste Pixel?

00:05:11: Wann das letzte Pixel und... Da sollte man schon, wenn man eine Systemarchitektur macht.

00:05:17: Wenn der Software-Architekturt macht klar haben wir auch schon mal drüber gesprochen oder kein Over Engineering betreiben aber natürlich so viel rein bringen weil es gibt immer Fehler im System oder Sachen, an die man nicht gedacht hat.

00:05:31: Dass man die einfach schnell sieht, schnell beobachten kann und dann einfach schnell zu reagieren.

00:05:36: Denn oftmals ist es nicht unbedingt das Problem dass ein Fehler auftritt sondern einfach was hat man eigentlich vorgesehen in seinen kompletten Kameradesign um sowas schnell zu erkennen, zu analysieren und beheben zu können?

00:05:48: Genau!

00:05:48: Und genau deswegen ist das ja eine Architekturentscheidung weil am Ende vom Tag so eine Beobachtbarkeit kostet mich irgendwas, entweder Entwicklungszeit oder am Ende vom Tag wie gerade ein Beispiel mit dem Kunden der quasi einen Debugbuffer sehr früh haben will.

00:06:03: Ja.

00:06:03: Kostet es ja auch Hardware-Ressourcen dann an dieser Stelle denn ich muss irgendwie in Speichervorhalten wo ich das Bild einschiebe?

00:06:08: Genau und manchmal ist es auch tatsächlich so.

00:06:10: ne wenn man dann mit einem Kunden das diskutiert dem das klar wird und dann sagt oh nee das ist jetzt sogar ein Musskriterium Dann kann's sogar hier und da sein dass man nochmal eine Entscheidung muss ob im Gewälterprozessor dann tatsächlich das richtige Mittel ist, wo man dann sagt okay wir verstehen nicht.

00:06:27: Das ist für dich wichtig aber an dem Punkt kommst du jetzt nicht dran.

00:06:32: Dann

00:06:32: gibt es manchmal auch Diskussionen wo man wirklich so Technologieentscheidungen zumindest noch mal analysieren muss weil der Kunde gesagt hat oh das ist mir gar nicht klar wenn jetzt da irgendwas passiert dass ich im Zweifel zwar ja auch Handlungs-Gun fähig bin.

00:06:46: also hatten auch einmal einen Kunden der wart man mit einem Black Box Block im Silizium.

00:06:52: Einfach so in Anführungszeichen unzufrieden, weil er nicht stabil lief oder halt einfach nicht so wie er dann in seinem Use Case gedacht hat, dass das Ganze ins Software nachbilden musste.

00:07:03: Weil er quasi an diesen neuereigischen Punkten nicht herankonne.

00:07:06: Er konnte den Fehler nicht richtig analysieren und ihm haben dann auch Werkzeuge gefehlt um es zu tunen.

00:07:14: Das ging damals um eine Blackbox ISP.

00:07:19: Das muss man halt auch irgendwie schon im Griff haben und es kann natürlich bis in die Produktion reingehen.

00:07:26: Also ich sag mal das haben wir ja auch im Griff, dass wir dann auch den Kunden beraten an welchen Videoschnittstellen vielleicht auch Testpunkte ran gehören.

00:07:34: Muss man auch aufpassen wenn man hier Videoschnitt stellen.

00:07:36: Wenn's High-Speed Signale sind sollte man auch irgendwie keine Testpunkten herannehmen.

00:07:41: Dann muss man das halt irgendwie anders testen oder mit anderen Werkzeugen.

00:07:47: aber letztendlich... dieses gesamte big picture nicht nur wie du es gesagt hast von der normfunktion oder sondern von wirklich wenn was ist, wenn irgendwo ein fehler in mein system durchhuscht.

00:08:00: Wie kriege ich den?

00:08:02: Oder in der software im fpga In der isp immer in soz Wie kriege ich mein System beobachtbar?

00:08:11: Wie krieg' ich's testbar, wie krieg ich wirklich relativ schnell ein robustes System durch.

00:08:17: Denn am Ende vom Tag will jeder Kunde das sein System Vierundzwanzig Sieben läuft wo man dann aber sagen muss okay das kann nicht nur eine Platte Anforderung sein.

00:08:26: Das führt auch schon dazu dass man gewisse zusätzliche Funktionen vielleicht einbauen muss, dass man die Beobachbarkeit rein bauen muss und natürlich die Sachen testen muss.

00:08:38: Ich muss dann vielleicht auch überlegen, dass ich hier und da eine Arrow Injection einbauen muss.

00:08:43: Wir hatten gemeinschaftlich ein großes Projekt wo man um gewisse Fusimechanismen zu testen Wirklich etwas komplexeren und aber auch sehr abgesicherten Error Injection Mechanismus, quasi auch gewisse Sachen provozieren konnten.

00:09:01: Weil wir wussten okay es kann da irgendwas mal passieren?

00:09:05: Da muss man da ein Format-Check machen und dann muss man irgendwie die Bildqualität beobachten.

00:09:09: Dann müssen wir einen Timing beobachten.

00:09:12: Aber manchmal muss man natürlich auch solche Fehler provoziert sein, sei es von extern.

00:09:19: Box eine Lösung, wo man auf GMSL-Schnittstellen zum Beispiel einen Aero Injection machen kann.

00:09:24: Aber auch innerhalb von ISP Blöcken dass man manche Sachen einfach mal so verdreht das irgendwelche anderen Checks anschlagen müssen.

00:09:32: aber halt es muss eine Architekturentscheidung sein.

00:09:35: was will man wie tun?

00:09:37: Was will man beobachten und aber auch testen und bewerten können.

00:09:41: Und das sind halt natürlich auch immer, je nachdem wie komplex es ist und wie tief du hast jetzt funktionale Sicherheit auch angesprochen kann man das natürlich unterschiedlich weit dann... auch treiben.

00:09:52: Genau, finde ich total spannend!

00:09:54: Vielleicht können wir da auch mal eine weitere Folge machen.

00:09:56: die heutige Folge jedenfalls wenn ich auf die Urschau ist hiermit beendet.

00:10:01: Ich bin der Hüter der Zeit und am Ende von jeder Folge natürlich der Hinweis an alle Zuhörerinnen und Zuhöhrer.

00:10:08: die email podcast etzoelectrics.de gibt's auch diese Woche noch kann man sich auch gern mal hinwenden wenn es darum geht.

00:10:14: Mensch wie könnte ich denn mein System an dieser Stelle beobachtbar machen?

00:10:20: Genau und ansonsten wünsche mir wieder eine schöne Zeit, ne schöne Woche bis zum nächsten Mal.

00:10:23: Tschüss und

00:10:23: ciao!