Ich arbeite in einer mittelständischen Firma 200 Angestellte) die
kleinere Gerätschaften entwickelt und baut, ich selber bin die
Schnittstelle zu den Elektronik Lieferanten und erstelle die
Lastenhefte. Es gibt eigene Elektronikentwicklung.
In letzter Zeit haben wir immer wieder Probleme mit der Elektronik und
der Software.
Problem ist wir müssen jedes mal die Baugruppen auf Funktion überprüfen
da die Erfahrung zeigt dass die Firmen nicht sauber arbeiten bzw. die
Fehler nicht herausfinden da sie vermutlich stiefmütterlich testen.
Theoretisch müssten wir als Auftraggeber eigentlich gar nicht oder nur
einmal testen.
würde es Sinn machen einen externen Berater dazwischen zu schalten, der
erst einmal die Hardware auf Fehler überprüft und/oder einen
Softwareprüfer.
Wenn ja wo findet man so etwas ? oder wie geht man da vor ?
Da wir nicht so groß/wichtig sind verstehe ich dass sich die
besseren/größeren Firmen über relativ kleine Aufträge von uns nicht
reißen sind wir auf kleinere Entwicklungsfirmen mit relativ beschränkter
Personaldecke angewiesen.
Was wäre die Alternative
Tim schrieb:> Theoretisch müssten wir als Auftraggeber eigentlich gar nicht oder nur> einmal testen.
Doch, das ist genau die Aufgabe, die dem Auftraggeber zufällt.
Wareneingang muss kontrolliert werden. Fehlerhafte Lieferungen werden
beim Wareneingang reklamiert / abgelehnt.
Nun ja, wir geben ja einen Auftrag an diese Firma.
Entwickle dies und das nach Lastenheftvorgabe. Da erwarte ich als Kunde
schon dass das Gelieferte auch funktioniert wie es das Lastenheft
vorgibt.
Wareneingangsprüfung wird schon gemacht.
Die Probleme sind ja hauptsächlich im Entwicklungsprozess, der wird
durch die mangelnde Qualität zeitlich sehr stark verlängert. Das kostet
ja auch Geld.
Der Zulieferer muß das tun, was im Vertrag steht. Wenn da steht
bestücken und zusammen bauen, wird er auch nur das tun.
Wenn er auch prüfen soll, muß vom Entwickler eine Testanleitung und ein
Prüfprotokoll bereit gestellt werden und das Prüfprotokoll wird dann für
jedes Gerät ausgefüllt.
Dann reicht bei Dir ein einfacher Wareneingangstest (Gerät äußerlich
unversehrt, alle Teile vollständig, Prüfprotokoll: pass).
Tim schrieb:> Entwickle dies und das nach Lastenheftvorgabe. Da erwarte ich als Kunde> schon dass das Gelieferte auch funktioniert wie es das Lastenheft> vorgibt.
Dann sollte zur Entwicklung auch eine Testanleitung gehören, die dann
vom Auftraggeber abgenommen wird.
Tim schrieb:> Die Probleme sind ja hauptsächlich im Entwicklungsprozess, der wird> durch die mangelnde Qualität zeitlich sehr stark verlängert. Das kostet> ja auch Geld.
Daß erstmal grüne Bananen geliefert werden ist heutzutage wohl Standard.
Anderenfalls würden die Kosten und Entwicklungszeiten erheblich höher
sein müssen.
Auch sind die Lastenhefte oftmals nicht so genau, daß es ohne
Nachbesserungen geht. Viele Anforderungen sind unklar bzw. ändern sich
sogar noch nachträglich.
Nun, 'requirement engineering' :)
Wenn das regelmäßig passiert, dann kann das auch am Lastenheft liegen.
Zu jeder Anforderung muss mindestens ein Test festgelegt sein, den der
Auftragnehmer mit Prüfprotokoll (und dem Produkt) abzugeben hat.
Macht das Lastenheft 'etwas' aufwändiger, viele Firmen benutzen dafür
bei komplexen Aufträgen zum Teil extra Software (z.B. DOORS), um bei
Änderungen die Abhängigkeiten im Auge zu behalten (so die Theorie ;) ).
Aber auch um festzustellen, welche Tests bei Änderungen
(Softwareupdate?) nochmal durchzuführen sind.
Befreit einen nicht wirklich davon, alles an Mustern nochmal selbst zu
testen... aber auch die Entwickler wissen dann, was auf sie zukommt.
Tim schrieb:> Problem ist wir müssen jedes mal die Baugruppen auf Funktion überprüfen> da die Erfahrung zeigt dass die Firmen nicht sauber arbeiten bzw. die> Fehler nicht herausfinden da sie vermutlich stiefmütterlich testen.>> Theoretisch müssten wir als Auftraggeber eigentlich gar nicht oder nur> einmal testen.
Der Auftraggeber gibt dem Auftragnehmer vor was er zu liefern hat, wie
er diese Teile zu testen hat und wie das ganze dokumentiert wird.
Prüfprotokoll:
Datum, Teil, Seriennummer, ...
Bauteile beschriftet OK
Lötstellen einwandfrei OK
Ausgangsspannung 12,2V (11,5V-12,5V) OK
(...)
Wenn 100 Baugruppen kommen zB.: 5 stichprobenartig selbst testen
(optisch & funktionell)
Falls nicht OK - alle zurück.
> Was wäre die Alternative
Lieferant wechseln, wenn der es nicht schafft, das zu liefern was
gefordert ist.
Üblich ist es (zumindest in der Medizintechnik) so: Auftraggeber
erstellt ein Lastenheft (Requirement specification) daraus erstellt der
Auftragnehmer ein Pflichtenheft (Design specification). Nachdem die
Entwicklung durch ist wird auf Basis der Design Specification eine
Verifizierung aller dort aufgeführten Punkte vorgenommen. Danach geht
das Design zum Auftraggeber, welcher seinerseits eine Validierung auf
Basis der Requirement Spec vornimmt. Bei Wechsel des Bestückers o.ä.
kommen dann noch entsprechende Erstmusterprüfungen auf euch zu.
Das ist der übliche Weg. Du kannst nicht einfach ein Dokument erstellen
und dann erwarten, daß das genauso gemacht wird ohne es zu Prüfen.
Schlussendlich kann es ja sein, daß einzelne Punkte unterschiedlich
interpretiert werden oder es gibt Nebenabsprachen. Dann muss man die
Dokumente natürlich nachpflegen, was nen heiden Aufwand ist. Aber nur so
kannst du halbwegs sicherstellen, daß du am Ende das bekommen hast, was
du in Auftrag gegeben hast.
So, nun muss ich weiter an meinem Verifizierungsplan schreiben :(
Ich vermute, dass auch Euer Unternehmen bei dem Lieferanten eine
minimalistische Preisdrückstrategie fährt, so wie es heutzutage bei fast
allen Entwicklungsverträgen der Fall ist. Vereinfacht haben wir ein
Dreieck, mit den Eckpunkten Kosten, Zeit und Qualität. Viele Kunden
"optimieren" nun Kosten und Zeit, erwarten dann aber, gleichzeitig auch
die beste Qualität geliefert zu bekommen.
Die Erstellung von Prüfspezifikationen, daraus abgeleiteten Testfällen,
Abnahmekriterien usw. ist eine sehr zeitaufwändige Angelegenheit und
kann durchaus in der gleichen Größenordnung wie die eigentliche
Entwicklung liegen. Und auf die realistischen Liefertermine hat das
natürlich auch einen großen Einfluss. Zudem bedeutet das bloße Testen ja
noch nicht, dass das Produkt alle Tests auch besteht, sondern ggf.
zeitaufwändige Korrekturschleifen mit erneuten Tests vorgesehen werden
müssen.
Aus diesem Grunde verzichten viele Kunden eben darauf, dass all die
Tests gemacht werden. Als Lieferant muss man sich da natürlich
vertraglich absichern. Bei Werkverträgen gibt es da natürlich eine
erhebliche Grauzone, in der der Lieferant ggf. kostenlos nachbessern
muss. Bei einer guten Zusammenarbeit von Kunden und Lieferanten
informieren sich natürlich beide Seiten gegenseitig über den
Entwicklungsstand, d.h. auch als Lieferant kann man durchaus potentielle
Probleme mit dem Produkt zugeben und mit dem Kunden diskutieren. Bei
manchen Anforderungen stellt sich ja auch erst im Laufe des Projektes
heraus, dass diese willkürlich ("Irgendeine Zahl muss da ja stehen.",
"Das stand schon immer in unseren Lastenheften.", "Es könnte ja jemand
unser Gerät auch auf der Rückseite des Mondes verwenden wollen.", "Wir
müssen einfach eine längere Featureliste als die Konkurrenz haben.")
getroffen wurden und entweder gar nicht oder nur mit unverhältnismäßig
hohem Aufwand implementiert werden können oder zu unerwünschten
Auswirkungen an anderer Stelle (Ein Rettungsring aus massivem Metall ist
zwar sehr robust und feuerbeständig, schwimmt aber nicht.) führen
können.
Tim schrieb:> Theoretisch müssten wir als Auftraggeber eigentlich gar nicht oder nur> einmal testen.
Dann musst du deine Baugruppen aber auch so bestellen und den
Funktionstest/Klimatest auch bezahlen. Und die Testparameter vorher
genau spezifizieren.
Tim schrieb:> Nun ja, wir geben ja einen Auftrag an diese Firma. Entwickle dies und> das nach Lastenheftvorgabe.
Und die Produktion bekommt die Firma dann auch gleich? Das würde ich
tendenziell entkoppeln...
> Da erwarte ich als Kunde schon dass das> Gelieferte auch funktioniert wie es das Lastenheft vorgibt.
Funktionieren die Freigabemuster wie erwartet? Hast du mal ein Beispiel,
wie da was spezifiziert wurde, und was hinterher stattdessen passiert?
> Wareneingangsprüfung wird schon gemacht.> Die Probleme sind ja hauptsächlich im Entwicklungsprozess, der wird> durch die mangelnde Qualität zeitlich sehr stark verlängert.
Oder evtl. auch durch eine unzureichende Spezifikation?
Tim schrieb:>>> und erstelle die Lastenhefte. Es gibt eigene Elektronikentwicklung.Wie passt das zu der Aussage die Tim schrieb:> wir geben ja einen Auftrag an diese Firma. Entwickle dies und das
??? Entwickelt ihr jetzt selbst oder lasst ihr das tun?
Tim schrieb:> Was wäre die Alternative
Frage deine Zulieferer nach ihrer ISO9001 Zertifizierung.
Dort muss die Methode aufgeführt sein, wie man sicherstellt, daß immer
dieselbe Qualität das Haus verlässt, also irgendeine Prüfmethode.
Die haben kein ISO9001 ? Da hast du das Problem. Such dir einen anderen
Zulieferer.
Und ja: Deine Firma selbst sollte ebenfalls Prüfmethoden haben, die ISO
gibt da einige Handlungsvorschläge, z.B. Eingangskontrolle bei nicht
zugesicherter Zulieferungsqualität.
Da ist wohl in der Eile ein Fehler unterlaufen, es sollte heißen wir
haben "keine" eigene Elektronik Entwicklung.
Die Produktion haben alle Lieferanten bis auf einen, der hat keine
Eigene.
Es wird für jeden Lastenheftpunkt mindestens ein Nachweis gefordert.
Es sind Dinge wie z.B. Sicherungen so klein gewählt dass bei den EMV
Tests (Spannungseinbrüche) die Sicherung sporadisch rausfliegt.
Oder ich habe 3 Taster am Gerät, funktionieren alle einzeln wunderbar.
drückt jetzt aber ein User, warum auch immer 2 gleichzeitig dann geht
das ganze Gerät nicht mehr.
Oder interner Betriebsstundenzähler speichert die Daten nur wenn man von
Betrieb in Aus-Modus wechselt. Aber das bei einem Sicherungsausfall dann
nicht mehr tut. Brown out Detektor fehlt.
Oder verwendet Grenzen in der Software zu klein dass bei der
Serienstreuung der Hardware ein Gerät von 50 diese Grenze reißt obwohl
es eigentlich noch in der Toleranz wäre.
Viele Dinge sind meiner Meinung nach Schlampigkeit oder dem Zeitdruck
geschuldet.
Ich würde wenn ich Entscheidungsbefugnisse hätte auch anders reagieren,
aber das hilft aktuell nicht viel. Ich versuche das Ganze zu verbessern
in dem Rahmen der möglich ist.
Dass das ganze nichts kosten darf und alles können muss ist ja nicht
wirklich verwunderlich , ist ja fast überall so.
edit:
wir haben hier schon alle QM Sachen, in der Serie funktioniert ja alles
prima, die Produkte der Lieferanten sind dann im normalen Fehlerbereich.
Es geht im Grunde um die Zeit von kick off bis Endabnahme. Da ziehen wir
meiner Meinung nach zu viele Schleifen.
Tim T. schrieb:> Es sind Dinge wie z.B. Sicherungen so klein gewählt dass bei den EMV> Tests (Spannungseinbrüche) die Sicherung sporadisch rausfliegt.
Wechsle den Entwickler.
> Oder ich habe 3 Taster am Gerät, funktionieren alle einzeln wunderbar.> drückt jetzt aber ein User, warum auch immer 2 gleichzeitig dann geht> das ganze Gerät nicht mehr.
Und am besten noch in einer bestimmten Reihenfolge...
Das kenne ich. So eine grottige Software würde ich dem Entwickler ums
Ohr klatschen. Aber tatsächlich steht vermutlich nicht in der Spec, wie
sich das Gerät beim Drücken von mehreren Tasten verhalten soll. Diesen
Freiheitsgrad hat der Programmierer kreativ genutzt.
> Oder interner Betriebsstundenzähler speichert die Daten nur wenn man von> Betrieb in Aus-Modus wechselt. Aber das bei einem Sicherungsausfall dann> nicht mehr tut. Brown out Detektor fehlt.
Nein, da fehlt vielmehr: eine sinnvolle Behandlung des Power-Fails
mitsamt der nötigen Hardware und/oder einer redundanten Datenhaltung des
Betriebsstundenzählers.
> Oder verwendet Grenzen in der Software zu klein dass bei der> Serienstreuung der Hardware ein Gerät von 50 diese Grenze reißt obwohl> es eigentlich noch in der Toleranz wäre.
Wer legt die Grenzen fest? Darf das der Entwickler anhand des Prototypen
selber machen?
> die Zeit von kick off bis Endabnahme. Da ziehen wir meiner Meinung nach> zu viele Schleifen.
Heißt auf Deutsch: da ist zu wenig definiert. Und zu viel wird hinterher
bzw. laufend geändert...
Meine persönliche Meinung: Passt in unsere Zeit.
Investiert (Zeit+Geld) wird in Papier: Warenkontrolle wird zum Lieferant
ausgelagert, statt dessen kommen Prüfpapiere mit. Eigentlich
"selbstverständliche" Dinge werden in Pflichtenhefte geschrieben. Für
Termine gibt's lustige Vertragsstrafen.
Nur: Das alles nützt nichts. Das Problem ist der falsche Invest. Papier
und Verträge lösen keine technischen Probleme und bauen kein Know-How
auf.
Qualität erreicht man durch Know-How und Methodik. Und aus der Methodik
fällt auf natürlicher Weise das Papier an.
Doch statt dessen wird erst Papier produziert und dann erwartet, dass
daraus Methodik und das Know-How anfällt. Und genau das funktioniert
nicht.
Und ja, das hat alles eine Wurzel: Geld.
Man bekommt eben genau das, was man investiert. Wenn Terminpläne knapp
sind und die Ausgaben minimiert werden, nunja, was soll auch heraus
kommen?
Warum werden Aufträge nach Extern vergeben? Weil man kein Know-How hat?
Weil selber fertigen zu teuer ist? Nun, das sind eben die Ursachen: Kein
Know-How und zu kleiner Invest. Das Ergebnis ist mangelnde Qualität.
Tim T. schrieb:> Oder ich habe 3 Taster am Gerät, funktionieren alle einzeln wunderbar.> drückt jetzt aber ein User, warum auch immer 2 gleichzeitig dann geht> das ganze Gerät nicht mehr.
Gibt es genaue Anforderungen wie sich das Gerät dann zu Verhalten hat?
Erfahrungsgemäß sind das immer die Fälle die der Requirement-Schreiber
vergisst und der Entwickler dementsprechend auch nicht testen kann (bzw.
der Entwickler kann nicht beurteilen ob das implementierte Verhalten
richtig ist oder nicht).
Sonder- und Fehlerfälle werden in den Requirements nur allzu oft
vergessen.
Das ist dann euch anzulasten.
Tim T. schrieb:> Oder interner Betriebsstundenzähler speichert die Daten nur wenn man von> Betrieb in Aus-Modus wechselt. Aber das bei einem Sicherungsausfall dann> nicht mehr tut. Brown out Detektor fehlt.
Hier gilt selbiges: gibt es Anforderungen die das gewünschte Verhalten
definieren?
Heutzutage praktiziert man Requirements Engineering. Dein Lieferant
wählt die kostengünstigste Lösung, die Dein Lastenheft erfüllt.
Man kann zwei Taster mit einem Portpin abfragen, wenn man einen nach
Plus und einen nach Minus schaltet. Darf man dann halt nicht
gleichzeitig drücken, aber war das gefordert?
Elkos kosten Geld und der LDO ist auch mit 470nF stabil. Wenn Du keinen
Nachlauf bei Powerfail forderst, in dem Daten weggeschrieben werden
können, dann gibt es auch keinen. Wenn Du kein Prüfkriterium
spezifizierst, dann klappt das Wegschreiben vielleicht nur die ersten
100 Mal, bis dann der NVRAM-Manager Garbage Collection machen muss und
auf einmal der komplette NVRAM-Inhalt platt ist.
Wenn Du keine Laufzeiten und kein Aufstartverhalten definierst wird der
Controller mit einem Klickibunt-Framework in Java programmiert. Ist halt
billiger als Zyklen zählen in Assembler.
soul e. schrieb:> Heutzutage praktiziert man Requirements Engineering. Dein Lieferant> wählt die kostengünstigste Lösung, die Dein Lastenheft erfüllt.
Das hat nicht nur was mit "kostengünstig" zu tun.
Der Lieferant kann einfach nicht hellsehen, im Zweifel will es der Kunde
eh komplett anders als der Lieferant es angenommen hat.
Dagegen helfen nur klare, eindeutige Requirements und laufende
Abstimmungen bzw. Zwischenreleases.
"Das System soll sich im Fehlerfall sinnvoll verhalten." ist zum
Beispiel kein sinnvolles Requirement weil jeder eine andere Vorstellung
von "sinnvoll" hat.
In einem System mag eine schnellstmögliche Notabschaltung, womöglich
sogar ohne Wegschreiben des NvM (weil es auf jede Millisekunde ankommt)
sinnvoll sein, ein anderes System dagegen muss alles mögliche versuchen
um betriebsfähig und verfügbar zu bleiben weil Notabschaltung keine
Option ist.
Sowas kann der Lieferant nicht selbstständig festlegen oder wissen.
Du kannst zwar deine Entwicklung und das Testing aussourcen, aber
Gedanken über das System musst du dir weiterhin selbst machen. Nur du
weißt was du eigentlich haben willst/musst.
Lothar M. schrieb:> Aber tatsächlich steht vermutlich nicht in der Spec, wie> sich das Gerät beim Drücken von mehreren Tasten verhalten soll. Diesen> Freiheitsgrad hat der Programmierer kreativ genutzt.
Hauptsache immer die andern sind schuld.
Unbekannt U. schrieb:> Nun, das sind eben die Ursachen: Kein Know-How und zu kleiner Invest.
Gut beschrieben.
Michael B. schrieb:> Hauptsache immer die andern sind schuld.
Schuld ist hier der Auftraggeber, wenn er nicht definiert, was bei Druck
auf mehr als eine Taste passieren soll. Der Entwickler hätte natürlich
nachfragen können. Aber vermutlich saß ihm der Chef auch im Nacken, weil
das Ding nun endlich fertig werden sollte und da ist so eine
Nebenbetrachtung eben hinten runter gefallen. Shit happens aber so ist
es nunmal. Beim nächsten Projekt darf das aber nicht mehr passieren,
sonst würde ich den Lastenheftschreiber entlassen.
Tim T. schrieb:> Da ist wohl in der Eile ein Fehler unterlaufen, es sollte heißen wir> haben "keine" eigene Elektronik Entwicklung.
Insbesondere deswegen dürfte es eventuell schwierig sein, ein
"wasserdichtes" Lasten/Pflichtenheft zu formulieren.
In der Regel sollte der Entwicklungsdienstleister aus dem Lastenheft ein
Anforderungsdokument erstellen, in dem JEDE einzelne Anforderung
aufgelistet ist. Dieses Dokument MUSS vom Auftraggeber abgenommen und
bestätigt werden.
Das dient zum einen dazu, zu verdeutlichen, dass beide Parteien vom
Gleichen reden.
Zum anderen sind die einzelnen Anforderungen testbar und somit die
Funktion nachweisbar. In der Regel sind Lastenhefte hierfür nicht
brauchbar.
Ich kenne es (leider) so, dass der Auftraggeber sich das
Anforderungsdokument sparen möchte ("kostet Zeit und Geld und bringt
nix") und auf das Lastenheft verweist ("da steht doch alles drin").
Das führt dann zu unspezifiziertem Verhalten und zu diesem hier:
Tim T. schrieb:> Es geht im Grunde um die Zeit von kick off bis Endabnahme. Da ziehen wir> meiner Meinung nach zu viele Schleifen.
Vielleicht wäre das ein Ansatz zur Vermeidung von Schleifen und
"banalen" Fehlern.
Anbei eine Illustration die zeigt, was passiert wenn man sich die
Requirementsphase schenkt.
Und ja, so eine Phase ist teuer und langwierig.
Wenn der Auftraggeber das nicht möchte muss er wohl mit Bananenware
leben.
Lothar M. schrieb:> Aber tatsächlich steht vermutlich nicht in der Spec, wie> sich das Gerät beim Drücken von mehreren Tasten verhalten soll. Diesen> Freiheitsgrad hat der Programmierer kreativ genutzt.
Ich denke mal, Selbstverständlichkeiten muß man nicht ins Lastenheft
schreiben. Ein Programm darf nicht abstürzen, das ist keine Freiheit
mehr.
Vermutlich sind das noch sehr unerfahrene Entwickler und daher wird auch
der Preis sehr günstig gewesen sein.
Sicherer ist daher, alles, was wichtig ist, auch aufzuschreiben.
Das kostet zwar Arbeit, spart hinterher aber umso mehr.
Peter D. schrieb:> Ich denke mal, Selbstverständlichkeiten muß man nicht ins Lastenheft> schreiben
Es gibt keine Selbstverständlichkeiten.
Alles was nicht abgestimmt und festgelegt wurde ist "undefined
behaviour".
Kann ich mir richtig vorstellen wie das lief.
Kunde: "Baut mir mal ein Gerät was dies, das und jenes macht. Achja, und
solches sollte auch drin sein."
Nö, läuft nicht. Sich um die Konzeptphase drücken, schwammige
Anforderungen in ne Email klopfen und hinterher wehklagen, dafür gibts
Null Mitleid.
Edit: Zur Ursprungsfrage:
Ihr könnt natürlich verlangen dass euer Zulieferer irgendwelche
Zertifikate vorweisen muss, z.B. irgendnen SPICE-level.
Dies garantiert aber auch nur dass das Thema "Prozesse und
Qualitätsmanagement" dort grundsätzlich bekannt ist und diese mehr oder
weniger eingehalten werden.
Mehr aber auch nicht.
Wenn ihr schwammig formuliert kommt auch bei einer sauberen,
prozesskonformen Entwicklung nicht das raus was ihr euch wünscht.
Shit in, shit out.
Peter D. schrieb:> Vermutlich sind das noch sehr unerfahrene Entwickler und daher wird auch> der Preis sehr günstig gewesen sein.
Das scheint mir auch so. Jeder verbrennt sich einmal die Finger. Auf der
Auftraggeber- wie auch auf der Auftragnehmerseite. Wenn sich das
allerdings wiederholt, dann sollte man nicht immer gleich weitermachen,
frei nach dem Motto "Man kann einen Fehler nicht oft genug wiederholen,
bis man ihn perfekt beherrscht!"...
Es tut mir leid wenn hier offensichtlich alte Wunden aufgerissen werden,
scheint ja ein sehr emotional besetztes Thema sein!
Aber zu meiner Eingangsfrage zurück.
Würde es Sinn machen ab einer gewissen Phase einmal jemand externes über
die Schaltung (Software ) drüber sehen zu lassen ? Ich selbst besitze
das know how nicht und hätte auch keine Kapazitäten frei. Also ich meine
eine Analyse wie : sind die Bausteine nach den recommended application
ausgelegt oder ist das grenzwertige Auslegung, .... Wir hatten auch
einige Ausfälle bei den Markttestkunden da hing es genau daran, einige
Geräte streckten die Hufe aus Gründen die hätten vermieden werden
können.
Kann man solche Dinge über einen Externen Gutachter minimieren ?
Tim T. schrieb:> Es tut mir leid wenn hier offensichtlich alte Wunden aufgerissen werden,> scheint ja ein sehr emotional besetztes Thema sein!
Es ist ein komplexes Thema, für das es keine Patentlösung gibt.
Die beste Lösung dürfte sein, sich mal an einen Tisch zu setzen und die
Probleme in einem freundlichen Ton zu analysieren.
Nur per E-Mail oder Anwaltsschreiben wird sich keine Lösung finden
lassen.
Tim T. schrieb:> Also ich meine eine Analyse wie : sind die Bausteine nach den> recommended application ausgelegt oder ist das grenzwertige Auslegung
Natürlich kannst du ein anderes Entwicklungsbüro über die Schaltung
drüber schauen und auf offensichtliche Fehler untersuchen lassen. Das
geht aber nur eingeschränkt und am ehesten noch auf Hardwareebene.
Sobald Software analysiert werden muss, braucht der zweite Entwickler
dann für detaillierte Aussagen eben auch das komplette
Systemverständnis. Bestenfalls simple Fehler können mit einem kurzen
Blick in den Code festgestellt werden.
Vor Allem wird dir auch ein weiteres Augenpaar nicht garantieren, dass
die Prototypen auf Anhieb laufen...
> Wir hatten auch einige Ausfälle bei den Markttestkunden da hing es> genau daran, einige Geräte streckten die Hufe aus Gründen die hätten> vermieden werden können.
Das sollte man eigentlich schon vorher durch Überlastungs- und
Temperaturtests ausschließen. Ich bin gerade auch mit ein paar neuen
Steuerungen rausgegangen ins Feld und erwarte dort keine Probleme, weil
ich von kurzgeschlossenen Ausgängen und Schaltreglern über Eingägne mit
4-facher Eingangsspannung bis hin zum vertauschten Anschluss eines
Trafos mit 230V statt 24V und tagelangen Temperaturzyklen von -20°C bis
90°C alles mögliche getestet habe.
Dabei sind natürlich Fehler und Vorkommnisse aufgetreten, die
entsprechend bewertet und ggf. abgeholfen wurden.
Das Problem ist also eher, dass die Entwicklung zu billig verkauft und
solche entwicklungsbegleitenden Tests eingespart wurden. Und nun werden
die Fehler, die ich im Labor gefunden habe, bei euren Prototypen beim
Kunden festgestellt.
Schlimmer wäre es, wenn der Entwickler so von sich überzeugt ist, dass
er solche Tests nicht für nötig hält...
Wurde denn vertraglich vereinbart, dass bestimmte EMV tests bestanden
werden sollen. Wenn nicht ist das Ergebnis richtig. Das sindsin teure
Zusatzaufwendungen.
Der Auftragnehmer ist vollumfänglich für den fehlerfreien Betrieb der
elektronischen Komponenten, auch für die EMV, verantwortlich. Es werden
Temperaturbereiche und Lastfälle definiert, in denen die Komponenten
einwandfrei funktionieren müssen.
Tim T. schrieb:> Es werden Temperaturbereiche und Lastfälle definiert, in denen die> Komponenten einwandfrei funktionieren müssen.
Und, tun sie das?
Falls ja: dann fehlt noch was in der Spec, denn offensichtlich treten
trotzdem Fehler auf. Dann muss es in der Praxis noch andere Ursachen
geben, die bisher nicht untersucht und berücksichtigt wurden.
Falls nein: da muss noch nachgearbeitet werden. Und fürs nächste Proejkt
mit diesem Partner von vorn herein eine Pönale festlegen, wenn durch die
Nacharbeit die Termineinhaltung nicht mehr gewährleistet werden kann.
Tim T. schrieb:> Würde es Sinn machen ab einer gewissen Phase einmal jemand externes über> die Schaltung (Software ) drüber sehen zu lassen ? Ich selbst besitze> das know how nicht und hätte auch keine Kapazitäten frei.
Natürlich kann man das. Neben den üblichen Verdächtigen wie TÜV Nord etc
gibt es Millionen von Ingenieurbüros, die solche Dienstleistungen
anbieten.
Selbst mit Knowhow fehlen gerne mal die Kapazitäten. Wir hatte mal einen
Kunden, der eine worst case circuit analysis haben wollte. Für jeden
relevanten Parameter jedes einzelnen Bauteils den typischen
Arbeitspunkt, die Betriebsgrenzen über Temperatur und Lebensdauer, und
in Relation dazu die Spezifikationsgrenzen und die Marge von
Betriebsgrenze zu Spezifikationsgrenze. Dafür hatten wir uns einen
externen Consultant geholt, der dann ein halbes Jahr mit LTspice und
Excel zugange war.
Alten, Bertrand, Ferchau, Hayes, Solcom -- das sind einige der
Vermittlerbuden in alphabetischer Reihenfolge.
Tim T. schrieb:> Der Auftragnehmer ist vollumfänglich für den fehlerfreien Betrieb der> elektronischen Komponenten, auch für die EMV, verantwortlich.
Und warum habt ihr dann selber EMV Tests gemacht.und nicht die
Pruefprotokolle vom Auftragnehmer?
Tim T. schrieb:> Wir haben keine eigenen EMV Tests gemacht, es war ein Mitarbeiter von> uns mit dabei.
Ok. Und wurden die nach Norm bestanden oder nicht. Das ist doch die
Frage.
Peter D. schrieb:> Ich denke mal, Selbstverständlichkeiten muß man nicht ins Lastenheft> schreiben.
Bloss für jeden ist was andees selbstverständlich.
Schreibe mal ein Lastenheft für einen Inder, du wirst dich wundern.
> Ein Programm darf nicht abstürzen, das ist keine Freiheit mehr.
Sage das mal Microsoft, IBM, Google (Android), eigentlich jedem
Softwareproduzenten jenseits einer Uhrenfirmware.
Abstürze sind nicht nur Stand der technik, sondern werden immer häufiger
weil sich die Hersteller komplett aus der Verantwortung ziehen dürfen
(bei open .
Sie haben Urheberrechtsschutz wie ein Buch (kein Leser darf sich über
eine miese unlogische Story beschweren, der Autor hat keine
Nachbesserungspflicht, man darf sich also auch nicht über
Softwarequalität beschweren) und GLEICHZEITIG wollen sie nicht dem Recht
auf Kopie zu privaten Zwecken unterliegen, also Rechtsbeugung dank
Lobbykorruption vom feinsten, das Beste aus beiden Welten für die
Sowfatrehersteller, die Arschkarte für den Kunden.
Michael B. schrieb:> Softwareproduzenten jenseits einer Uhrenfirmware.
Und selbst bei Uhrenfirmware kann man viele Fehler machen. Gerade erst
vor ein paar Tagen hat meine Frau ihren Radiowecker (Baujahr Mitte der
1980er Jahre) um zwei Minuten vorgestellt. Hierbei wurde er aber
unbemerkt um eine Stunde zurückgestellt, obwohl er gar keine
entsprechenden Knöpfe besitzt.
Den gleichen Effekt hatte ich vor sehr langer Zeit auch schon einmal bei
einem ganz anderen Radiowecker aus den sehr frühen 1980er Jahren
beobachtet. Offenbar gab es damals irgendeinen Uhrenbaustein, in dessen
Firmware der Fehler enthalten war. Ich gehe schwer davon aus, dass es
sich schon um einen Microcontroller handelte und nicht um
festverdrahtete Logik.
