Forum: FPGA, VHDL & Co. Projektverzug und Bugdichte in der FPGA-Entwicklung


von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Angehängte Dateien:

Lesenswert?

Slide von der diesjährigen FPGA Conference:
84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der 
FPGA-Entwicklungen liegen hinter dem Zeitplan.

Bei aller selbstkritischen Betrachtung, zeigt es IMHO eher das 
Planungen/Aufwandsabschätzungen sehr unrealistisch sind und bug-freiheit 
nicht unbedingt ein Kriterium für den Erfolg ist.

(Die Angabenwurden zum Anfang eines Vortrages über "Debug/Verification 
FPGA - Lint" gemacht.)

von Klaus (feelfree)


Lesenswert?

Außerdem sind 100% aller Statistiken, die ich nicht selbst erstellt 
habe, entweder gefälscht oder frei erfunden.

von Michael B. (laberkopp)


Lesenswert?

Bradward B. schrieb:
> zeigt es IMHO eher das Planungen/Aufwandsabschätzungen sehr
> unrealistisch sind

Na ja, das Ergebnis von Scrum halt.

Vorher keine Ahnung und dann nachreichen, dazuwünschen, dranflicken.

Wenn vorher klar beschrieben wäre, was implementiert werden soll, dann 
wurde man auch ein Ergebnis in den Händen halten.

Früher gab es den Begriff der "eleganten Lösung": Die war dann gegeben, 
wenn mit minimalem Zeit- und Kostenaufwand die bestmögliche Lösung 
erzielt wurde.
Bei den heutigen Schlipsträgern und Anzugständern ist genau das aber 
nicht
erwünscht, kostet es doch Monate satten Gehalts, wenn ein Problem 
vorzeitig und womöglich zur Zufriedenheit des Auftraggebers gelöst wird. 
Unser Land lebt mittlerweile davon, Probleme zu züchten und zu 
verwalten, anstatt sie erfolgreich zu lösen.

von Klaus (feelfree)


Lesenswert?

Jaha, früher war alles besser.
Da haben wir monatelang Pflichtenhefte erstellt, dann 
Architekturdokumente geschrieben, darausndann Grob- und 
Feinspezifikationen abgeleitet. Nach 2 Jahren wussten wir dann ganz 
genau, dass wir noch 1 Jahr für die Implementierung und ein weiteres für 
alle Compliance-Tests brauchen würden. Und waren dann auch fast 
pünktlich.
Nach weiteren 2 Jahren war das Produkt dann auch so, wie es der Kunde 
wirklich haben wollte.

Heute sind wir nach einem halben Jahr mit einem MVP auf dem Markt und 
nach 2 Jahren ist das Produkt etabliert.

V-Modell vs Agile halt.

: Bearbeitet durch User
von Martin S. (strubi)


Lesenswert?

Bradward B. schrieb:
> Slide von der diesjährigen FPGA Conference:
> 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der
> FPGA-Entwicklungen liegen hinter dem Zeitplan.

Was soll ich mit so einer Aussage/Zahl jetzt anfangen?
Ein Marketing-Aufknuepfer fuer eine statische Analyse-Methode?

Ansonsten ist das Phaenomen relativ allgemeingueltig auf Software 
anwendbar, ob V-Modell oder agil spielt vermutlich nicht mal mehr gross 
die Rolle, es wird halt einfach nicht ausreichend getestet, oder noch 
besser, der Kunde streicht diese rund 50% an im Projekt allozierter Zeit 
fuer Testphase weg, damit's weniger kostet.
Dazu kommt halt auch noch, dass die HDL-Verifikationsmethoden modernen 
Testansaetzen 20 Jahre hinterherhinken.
Gottseidank gibt es immer noch Firmen, die klassische Meilensteine 
abfruehstuecken und die Grenzen zwischen Prototyp und Produkt ganz klar 
definieren. Aber wehe, es rueckt da die naechste Generation ins 
Management vor...

von Georg S. (randy)


Lesenswert?

Bradward B. schrieb:
> Slide von der diesjährigen FPGA Conference:
> 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der
> FPGA-Entwicklungen liegen hinter dem Zeitplan.

Das heißt dass 16% der Impementierungen fehlerfrei sind und 30% der 
Projekte innerhalb des Zeitplans angeschlossen werden? Von solchen 
Zahlen kann man hier in der Firma nur träumen.
Hier sind alle Projekte hinter dem Zeitplan und in jeder Implementierung 
findet man den einen oder anderen Bug.

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

> Was soll ich mit so einer Aussage/Zahl jetzt anfangen?

Die zeigen halt wie gut und zuverlaessig FPGA sind weil 99% aller 
Anwendungen mit Microcontrollern bei der Auslieferung noch Bugs 
enthalten. Da sind FPGAs schonmal deutlich besser. :-D

> Hier sind alle Projekte hinter dem Zeitplan und in jeder Implementierung
> findet man den einen oder anderen Bug.

Yep! Aber da braucht man sich gar nicht an die eigene Nase packen. Ich 
brauch nur ein beliebiges von mir in den letzten 5Jahren gekauftes 
Geraet, TV, Radio, Handy, Messgeraete, usw anschauen und finde IMMER 
Bugs.

Der Welt war noch okay als es nur maskenprogrammierte Controller gab. 
Weil da allen vor der Bestellung der Arsch auf Grundeis ging und sie 
SEHR genau ueber Fehler nachgedacht haben. Heute: Oh koennte ein Bug 
drin sein? Egal, naechste Firmware...

Vanye

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Vanye R. schrieb:
> Der Welt war noch okay als es nur maskenprogrammierte Controller gab.
> Weil da allen vor der Bestellung der Arsch auf Grundeis ging und sie
> SEHR genau ueber Fehler nachgedacht haben.

Vielleicht auch weil in diese Controller auch einfach nur sehr simple 
Programme rein passten? So eine heutige Megabytes große Firmware mit 
Frameworks, RTOS, Protokollstacks hat einfach viel mehr Möglichkeiten 
für Fehler, gerade auch wenn diese externen Komponenten proprietär sind 
und man sie nicht prüfen/reparieren kann.

Vanye R. schrieb:
> Ich brauch nur ein beliebiges von mir in den letzten 5Jahren gekauftes
> Geraet, TV, Radio, Handy, Messgeraete, usw anschauen und finde IMMER
> Bugs.

Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät 
(nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch 
wirklich nicht der Spezifikation entsprechen?

von Vanye R. (vanye_rijan)


Lesenswert?

> Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät
> (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch
> wirklich nicht der Spezifikation entsprechen?

ABS nutzt man ja wenig, aber jetzt wo du es sagst, ich hab mich letztes 
bei Regen mal um 360Grad gedreht wegen Aquaplaning, (mir ist aber nix 
passiert) da hat das System wohl verwirrende Info vom Drehratensensor 
bekommen und auch die Raeder werden sich mal kurz rueckwaerts gedreht 
haben und ABS und DSC haben sich bis zum naechsten Motorstart 
abgeschaltet. Aber sowas mach ich natuerlich nicht jeden Tag.

Aber mein Regensensor hat einen lustig Bug. Man kann/muss den ueber 
einen Hebel einschalten und er macht dann was er soll, also die Scheiben 
wischen. Macht man das Auto aus und wieder an ist die Funktion weg. Man 
muss dann den Hebel einmal auf aus und dann wieder auf an stellen damit 
es wieder geht.

Vanye

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Vanye R. schrieb:
> da hat das System wohl verwirrende Info vom Drehratensensor bekommen

Na dann ist es aber kein Software Bug.

Vanye R. schrieb:
> Aber mein Regensensor hat einen lustig Bug

Na das ist aber eine Komfort Funktion

von Philip S. (psiefke)


Lesenswert?

Na, warum heißen die wohl field programmable gate array und nicht 
factory programmable gate array?

„Lass mal erstmal ausliefern. Den Fehler können wir dann im nächsten 
Release beheben.“

von Vanye R. (vanye_rijan)


Lesenswert?

Da kann man natuerlich nicht widersprechen. :-D

Vanye

von Klaus (feelfree)


Lesenswert?

Philip S. schrieb:
> Lass mal erstmal ausliefern. Den Fehler können wir dann im nächsten
> Release beheben.“

Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert 
wurden, nur um den vertraglichen Termin einzuhalten.
Die ersten Nachfragen kamen aber erst ein Vierteljahr später, solange 
hat sich der Kunde nicht um seine Lieferung gekümmert....

von Georg S. (randy)


Lesenswert?

> Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert
> wurden, nur um den vertraglichen Termin einzuhalten.

Haha, bei sowas war ich auch mal dabei. (nicht in meiner aktuellen 
Firma)


> Die ersten Nachfragen kamen aber erst ein Vierteljahr später

In meinem Fall war der Kunde darüber informiert und wollte das auch so, 
wegen seltsamer Budget-Regelungen beim Staat...

von Michael B. (laberkopp)


Lesenswert?

Niklas G. schrieb:
> Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät
> (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch
> wirklich nicht der Spezifikation entsprechen?

Ein paar hundert.

Kommt halt drauf an, wo man arbeitet.

von Klaus (feelfree)


Lesenswert?

Michael B. schrieb:
> Ein paar hundert.
>
> Kommt halt drauf an, wo man arbeitet.

In Laberstadt können das leicht auch ein paar Tausend werden.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Michael B. schrieb:
> Ein paar hundert.

Im finalen Produkt, nachdem alle Tests abgeschlossen sind?

von J. S. (engineer) Benutzerseite


Lesenswert?

Bradward B. schrieb:
> 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der
> FPGA-Entwicklungen liegen hinter dem Zeitplan.

Hm, wo kommen denn die Daten genau her ? bzw. wer kennt denn die genauen 
maturity states aller FPGA-Designs, die so umherschwirren?

Abgesehen davon stimme ich dem generellen Tenor der Aussage zu und 
liefere eine Begründung für die häufigen Zeitüberzüge: Die meisten 
Planer in dem Bereich sind Projektleiter, die selber nur kurz in dem 
Thema selber aktiv waren, oft ein fachfremdes Studium hatten, sich das 
selber beigebracht haben und die Details gnadenlos unterschätzen. Das 
kennt man.

Zu der Bugdichte muss man mal die Frage stellen, wo die denn liegen: In 
der Umsetzung (würde man ja mit dem Simulator am Arbeitsplatz abfangen 
können) oder doch eher in den Konzepten und der Zusammenarbeit mit 
anderen Komponenten? Da heute viel SW obendrauf kommt und hier 
komplexere Handlungsabläufe eine Rolle spielen, kommt es da auf einen 
guten (Echzeit-)Systementwurf an. Den können aber viele nicht, weil sie 
das nie erlernt haben, da "selber reingearbeitet". Das wird auch nicht 
an allen Unis gemacht. Als Folge liefert da jeder Insellösungen und es 
bedarf sehr aufwändiger Verifikationen um Probleme zu finden. Oft genug 
sind die Leute auch nicht in der Lage, die Fälle zu antizipieren und zu 
modellieren. Dann fällt es eben erst im Betriebsfall beim Kunden auf. Da 
fehlt es auch einfach ein wenig an der Ausbildung und den Fähigkeiten 
der FPGA-Systemplaner.

: Bearbeitet durch User
von Nemopuk (nemopuk)


Lesenswert?

Fehlerfreie Softwareprojekte gibt es praktisch nicht. Und was den 
Zeitplan angeht, ist es in der Regel so, daß er anfangs auf zahlreichen 
unklaren Annahmen beruht, die im Laufe des Projektes geändert werden. 
Oft werden zwischendurch auch die Anforderungen geändert. Ein gerissener 
Zeitplan ist selten ein Indiz für mangelhafte Umsetzung, sondern für 
falsche Einschätzung im Vorfeld.

: Bearbeitet durch User
von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

>> Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert
>> wurden, nur um den vertraglichen Termin einzuhalten.

>> Die ersten Nachfragen kamen aber erst ein Vierteljahr später
>
> In meinem Fall war der Kunde darüber informiert und wollte das auch so,
> wegen seltsamer Budget-Regelungen beim Staat...

Hm, vielleicht weil manche Projekte über den "Geldmittelabfluss" 
gesteuert überwacht werden. Da ist irgendwann mal vereinbart wurdendas 
jedes Quartal xy Mio überwiesen werden und Nachweis über deen Verbrauch 
(Stundenabrechnung) zu erbringen ist. Wird das Budget nicht über den 
Mittelabluss wie gaplant entlerrt sorgt man sich über Terminverschiebung 
...

Terminplanung ist IMHO mehr Werkzeug als leistungs-kennziffer ... die 
Softwareabteilung muss halt in der Lage sein zeitnah das von der 
Hardware-abteilung zugeliefrete FPGA-Board zu übernehmen resp. an den µC 
etc darauf/daran weiterzuentwickeln. Und nicht, das die HW-Abteilung 
grad mit Produktion und Inbetriebnahme fertig zu sein hat, wenn die SW 
und andere folgenden Gewerke grad Zeit dafür haben könnten.

Liefer-Termine sind IMHO besser als "IST-Wert" denn als "SOLL-Wert" 
anzusehen.

: Bearbeitet durch User
von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

J. S. schrieb:
> Bradward B. schrieb:
>> 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der
>> FPGA-Entwicklungen liegen hinter dem Zeitplan.
>
> Hm, wo kommen denn die Daten genau her ? bzw. wer kennt denn die genauen
> maturity states aller FPGA-Designs, die so umherschwirren?

Die stammen wohl von sehr geduldigen Papier; Unis und staatlich nahe 
Unternehmen erzeugen sowas immer mal wieder, wobei viel Statistik noch 
aus der Ära stammt in der man die "Softwarekrise" thematisierte, also 
vor etlichen Jahrzehnten.

> Zu der Bugdichte muss man mal die Frage stellen, wo die denn liegen: In
> der Umsetzung (würde man ja mit dem Simulator am Arbeitsplatz abfangen
> können) oder doch eher in den Konzepten und der Zusammenarbeit mit
> anderen Komponenten?
...
> Dann fällt es eben erst im Betriebsfall beim Kunden auf. Da
> fehlt es auch einfach ein wenig an der Ausbildung und den Fähigkeiten
> der FPGA-Systemplaner.

Ja, eigentlich sind andere Kriterien im Fokus zu halten: Testabdeckung, 
Systemkomplexität, Fehlertoleranz

Manche Projektleiter gehen davon aus das man fehler "heraustesten" kann, 
also egal wie "shitty" Spec und Architectur ist, lang genug getestet 
kriegt man schon Kundenzufriedenheit rein.

Andere dagegen setzen eher auf einfache Systeme bei denen nicht viel 
schief laufen kann und legen die "Architektur" soaus, das im "Brandfall" 
nicht viel passiert resp. man sich in Sicherheit bringen kann.
Beispielsweise "reset" - der Bediener muss in der Lage sein, bei 
Fehlverhalten der Maschine zügig neu anfangen zu können resp. die 
Maschine in einen Zustand zu versetzten in der diese auf 
Benutzereingaben reagiert.

von Richard W. (richardw)


Lesenswert?

Ich habe mittlerweile einiges an (Software)-projekten begleitet und die 
größte Gefahr für Terminverzug und Bugs war meistens die 
Selbstüberschätzung und Verbohrtheit von Entwicklern. Da wird gemauert 
und Projektpläne werden sabotiert weil man der Meinung ist man wüsste 
besser was wie und warum implementiert werden soll. Da werden die 
eigenen Aufwände völlig unrealistisch eingeschätzt und falsche 
Rückmeldungen an die Projektleitung gegeben. Da werden vorhandene 
Lösungen ignoriert und einfach weggeschmissen weil einem irgendwas nicht 
passt oder weil es jemand anderes implementiert hat. Alles schon gehabt, 
auch ich selber. Manche lernen und werden erwachsen, manche ändern sich 
nie. Projektleiter sein bei solchen Entwicklern ist dann echt kein Spaß.

von Michael B. (laberkopp)


Lesenswert?

Richard W. schrieb:
> Projektleiter sein bei solchen Entwicklern ist dann echt kein Spaß

Vor allem, wenn man, so wie du, nicht die leiseste Ahnung von 
Programmieren hat.

Die korrekte Antwort, wenn man einen Programmierer fragt, wie lange es 
dauert, den Fehler zu beheben oder das feature zu implementieren, lautet 
nämlich 'keine Ahnung, weisst du wir lange die Suche nach der Nadel im 
Heuhaufen dauert'.

Aber so was akzeptieren die dümmsten der dummen Projektleiter ja nicht, 
also bekommen sie irgendeine Zahl genannt, UND ZWAR MEIST EINE ZU 
NIEDRIGE, man will den Projektleiter ja nicht verärgern.

Und an statt dass der Projektleiter aus Erfahrung die Zeit mit 10 
multipliziert (90% schafft man in 10% der Zeit aber die letzten 10% 
brauchen 90% der Zeit), addiert er optimistisch  5+5+5=10, man muss halt 
bloss die Peitsche stärker schwingen.

Richard W. schrieb:
> gemauert und Projektpläne werden sabotiert weil man der Meinung ist man
> wüsste besser was wie und warum implementiert werden soll

Sie wissen es besser. Dein Projektplan ist das Dumme.

Fremder code ist meist so schwer zu verstehen, dass es 10 x länger 
dauert ihn einzusetzen, als neu zu schreiben. Allerdings nur für die 
ersten 90% (siehe oben). Die restlichen 10% dauern dann eben wieder, 
aber da jeder Projektleiter so geil ist gleich Ergebnisse zu sehen, 
fährt man mit abgelieferten 90% besser.

Du bist wirklich ein Paradebeispiel dafür, was in der 
Softwareentwicklung falsch läuft.

von .● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

So sehen Bilder aus, die von russischen Spionen kommen,
die schnell im Vorbeilaufen noch eben rasch einen Schnappschuss...

von Martin S. (strubi)


Lesenswert?

Auch wenn das Niveau oben wieder ins unterguertelige absinkt: Lasst die 
designierten Projektleiter halt einfach das Testen, aber nicht die 
Vorgabe eines Zeitplans uebernehmen. Dann sind sie immerhin verstaendige 
Projektleiter.
Ein guter Projektleiter wiederum nimmt Ruecksicht auf die Belange 
aelterer Entwicklerkollegen, die mit modernen Softwaremethoden nicht 
klarkommen und holt sich notfalls ein paar Human Interfaces dazu, die 
zwischen retro und Industrie 4.0 die Bruecken schlagen und ab und an 
eine Runde Eis spendieren.
NB: Ich hatte eine Weile lang den Spass, als externer Feuerwehrmann 
solche kraenkelnden Projekte zum Abschluss zu bringen, damit keine 
dicken Konventionalstrafen eines riesigen A-Konzerns faellig wurden. 
Wirklich, viele Probleme loesen sich mit einer Runde Eis, und damit, 
dass bestehende Hierarchien/Blockaden durch die Externen umgangen werden 
koennen.

Alles andere ist einfach nur polemisches Gelaber aus dem 
Frustrationsbuero/Besserwisseretage, mit Verlaub.

Viel mehr wuerde mich interessieren, wer noch ausgiebig statische 
Code-Analyse a la lint in der HDL benutzt, reicht jetzt aber auch wieder 
mit der Trollwiese.

von Markus F. (mfro)


Lesenswert?

Vanye R. schrieb:
> Aber mein Regensensor hat einen lustig Bug. Man kann/muss den ueber
> einen Hebel einschalten und er macht dann was er soll, also die Scheiben
> wischen. Macht man das Auto aus und wieder an ist die Funktion weg. Man
> muss dann den Hebel einmal auf aus und dann wieder auf an stellen damit
> es wieder geht.

VW, oder? Meiner macht das auch.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Martin S. schrieb:
> Human Interfaces dazu, die zwischen retro und Industrie 4.0 die Bruecken
> schlagen

Sowas wie RFC 1149?

von Vanye R. (vanye_rijan)


Lesenswert?

> VW, oder? Meiner macht das auch.

Noe, BMW. Aber vielleicht kommt ja beides von Bosch oder so...

Vanye

von Vancouver (vancouver)


Lesenswert?

Mein alter Citroen, den ich kürzlich nach 16 Jahren verkauft habe, hatte 
das selbe Feature mit dem Regensensor. In der Werkstatt hatte mir einmal 
jemand erklärt das sei Absicht, damit sich der Fahrer nicht erschreckt, 
wenn plötzlich unerwartet der Scheibenwischer anspringt...

von Markus F. (mfro)


Lesenswert?

Vancouver schrieb:
> In der Werkstatt hatte mir einmal
> jemand erklärt das sei Absicht, damit sich der Fahrer nicht erschreckt,

Vielleicht um den Fahrer vor Regressansprüchen von 
AnDerAmpelUngewolltScheibenPutzern zu schützen, wie man sie in manchen 
Ländern sieht?

von Klaus (feelfree)


Lesenswert?

Bei meinem VW (BJ 2016) funktioniert der Regensensor immer, der wird nur 
in der Waschanlage ausgeschaltet.

Er hat aber einen anderen lustigen Bug:
Um von Stellung "P" des Automatikgetriebes wegezuschalten, muss man auf 
der Bremse stehen.
Das funktioniert auch. Löst man die Bremse aber dann zu früh, dann fährt 
das Auto schlicht nicht los, weil es nicht einkuppelt. Sieht immer blöd 
aus wenn man Gas gibt und nicht vom Fleck kommt.
Nochmaliges Bremsenbetätigen hilft dann.

von Markus F. (mfro)


Lesenswert?

Klaus schrieb:
> Das funktioniert auch. Löst man die Bremse aber dann zu früh, dann fährt
> das Auto schlicht nicht los, weil es nicht einkuppelt. Sieht immer blöd
> aus wenn man Gas gibt und nicht vom Fleck kommt.
> Nochmaliges Bremsenbetätigen hilft dann.

... und löst beim Hintermann Panik aus ;)

von Nemopuk (nemopuk)


Lesenswert?

Markus F. schrieb:
> und löst beim Hintermann Panik aus

Wieso? Ist es so überraschend, dass jemand auf dem Parkplatz stehend die 
Bremse betätigt?

von Markus F. (mfro)


Lesenswert?

Nemopuk schrieb:
> Markus F. schrieb:
>> und löst beim Hintermann Panik aus
>
> Wieso? Ist es so überraschend, dass jemand auf dem Parkplatz stehend die
> Bremse betätigt?

Auf dem Parkplatz stehend nicht. Aber durch die Waschanlage geht man ja 
normalerweise auf N und muß am Ende erst auf die Bremse, um nach D zu 
kommen und loszufahren.

Das kann durchaus den Hintermann etwas überraschen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.