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
:
Verschoben durch User
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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
projektmanagement.jpg
70 KB
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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?
:
Bearbeitet durch User
@souleye: danke für die Nemen Wir haben keine eigenen EMV Tests gemacht, es war ein Mitarbeiter von uns mit dabei.
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.
zum Schluss dann schon mittels einem Haufen teurer Ferrite.
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.