Wie es meines Erachtens laufen sollte:
Das zu entwickelnde Gerät wird hinsichtlich der zu entwickelnden Baugruppen analysiert und es werden entsprechende EMV Vorgaben für die einzelnen Baugruppen aufgestellt. Ebenso spielt bereits das Design des Gehäuses eine Rolle. Denn mit einem guten Gehäuse lassen sich viele Probleme vermeiden (Farraday'scher Käfig). Die Entwickler der einzelnen Baugruppen müssen die Vorgaben erfüllen und ihr entwickeltes Zeug testen.
Wie es leider oft gemacht wird:
Aus Gründen des Zeitdrucks wird darauf losentwickelt. Es gibt lediglich best practices, die sich als funktionierend erwiesen haben und an die sich die Entwickler zu halten haben. Wenn es nun zu einem EMV Problem kommt gibt es verwirrende Gesichter bei den Entwicklern. Nun folgen wiederum EMV-Maßnahmen, die sich ebenso bewährt haben mit denen versucht wird das EMV-Problem zu beheben. Durch diese Art des Vorgehens können die Entwickler jedoch kein tiefgründiges Wissen in der EMV aufbauen. Ganz im Gegenteil es sorgt für noch mehr Verwirrung, wenn die best practices nicht funktionieren.
Die letztere Variante ist oft teurer. Denn EMV Probleme werden teurer und schwieriger zu lösen je später sie entdeckt werden. Wenn der Prototyp bereits steht sind die Lösungsmöglichkeiten beschränkt und oft müssen teure Bauelemente her, um das Problem in den Griff zu bekommen. Das ist die bekannte Kostenexplosion. Viel sinnvoller ist es in das EMV Wissen der Entwickler zu investieren und EMV Probleme bereits früh zu identifizieren und zu vermeiden. Mit einer guten EMV Planung lassen sich 90% der EMV Probleme vermeiden. rant over!!!
Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft, dass es irgendwie mit ein paar Ferriten schon hinhaut >_<
Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft,
dass es irgendwie mit ein paar Ferriten schon hinhaut >_<
Neee, wir bei der Kamera-/Monitor-Entwicklung wissen natürlich um die magische Wirkung eines Weißblechkastens und sperren deshalb die Kamera, Monitor gleich in einen solchen ...
Also HW-Entwicklung heísst schon immer, das man einen Prototypen aufbaut, den ausmisst und anhand der Messergebnisse optimiert. Also ja, man sieht Platz/bauteile für EMV-Entstörmassnahmen vor und freut sich wie ein Schneekönig wenn man diese nicht benötigt. Ist halt Praxis, keine Theorie.
Viel sinnvoller ist es in das EMV
Wissen der Entwickler zu investieren und EMV Probleme bereits früh zu
identifizieren und zu vermeiden.
Das "EMV-Wissen" besteht aber nun mal grösstenteils in der Erfahrung wie Normverletzungen sicher aufspürt und Gegenmassnahmen trifft. 100% vermeiden kann man Probleme/Fehler nur durch Nicht-Tätigkeit. Aber da derjenige befördert wird, der keine Probleme/Fehler schafft ...
Die Entwickler der einzelnen
Baugruppen müssen die Vorgaben erfüllen und ihr entwickeltes Zeug
testen.
Am Ende wird aber das Gesamtsystem getestet und was die Baugruppen machen, ist völlig irrelevant. Leitungsgebundene Störungen interessieren dich innerhalb eines Gerätes zum Beispiel gar nicht.
Bei 5 Baugruppen und z.B. 3 Testdurchgängen sind das 15 Tage in einem EMV-Labor. Als fertiges Gerät nur 3.
Und weder die Entwickler noch die Baugruppen sind unabhängig voneinander. Die arbeiten zusammen als Team und die Erkenntnisse von Team A sind auch für Team B nützlich, natürlich muss da ein Austausch erfolgen und kein Team darf für sich alleine im stillen Kämmerchen arbeiten.
Es gibt lediglich
best practices, die sich als funktionierend erwiesen haben und an die
sich die Entwickler zu halten haben.
Natürlich gibt es best practices. Du möchtest nicht bei jeder Entwicklung komplett von vorn anfangen, sondern das Wissen, das du gesammelt hast, nutzen.
Wenn es nun zu einem EMV Problem
kommt gibt es verwirrende Gesichter bei den Entwicklern.
Entwickler haben immer verwirrende Gesichter. Sind alles kleine Nerds mit Pickeln und dicker Brille.
Entwickler müssen eben über EMV gelernt haben und ihre Erfahrungen gesammelt haben. Wenn EMV nie ein Thema war und es plötzlich wichtig ist, dann muss man eben lernen, was wie getestet wird, welche Kriterien es gibt und wie "EMV gerechtes" Design funktioniert.
Die Entwickler lernen und irgendwann weiß man, was zu tun ist.
Nun folgen
wiederum EMV-Maßnahmen, die sich ebenso bewährt haben mit denen versucht
wird das EMV-Problem zu beheben. Durch diese Art des Vorgehens können
die Entwickler jedoch kein tiefgründiges Wissen in der EMV aufbauen.
Ganz im Gegenteil es sorgt für noch mehr Verwirrung, wenn die best
practices nicht funktionieren.
Es ist doch in einer Entwicklung nicht so, dass Best Practices und EMV-Maßnahmen willkürlich von außen auf das Projekt geworfen werden. Das ist ein interner Prozess, bei dem jeder Entwickler lernt.
Selbst wenn man sich externe Dienstleister ins Haus holt, bezahlt man die nicht dafür, dass das Gerät am Ende die Tests besteht, sondern für den Wissenstransfer an das eigene Team. Alles andere wäre weder sinnvoll noch nachhaltig.
Denn EMV Probleme werden teurer
und schwieriger zu lösen je später sie entdeckt werden.
Immerhin hier hast du mal Recht. Aber wenn EMV wichtig ist und die Entwickler sensibilisiert sind, dann achtet man von vorn herein darauf und versucht alles, so früh wie Möglich zu testen, best practices und erlernte Lösungen anzuwenden.
Viel sinnvoller ist es in das EMV
Wissen der Entwickler zu investieren und EMV Probleme bereits früh zu
identifizieren und zu vermeiden.
Und genau so läuft es auch. Kann es sein, dass du noch nie in einer Entwicklung warst und keine Ahnung hast, wie so ein Entwicklungsprozess mit Wissenstransfer und EMV-Tests abläuft?
Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft,
dass es irgendwie mit ein paar Ferriten schon hinhaut >_<
Nein. In keinem der vielen Unternehmen, in denen ich war (von 50MA-Bastelbude bis 2000-Mitarbeiter-Konzern) wurde so entwickelt, wie du es dir vorstellst.
Geh mal in eine echte Hardwareentwicklung in einem echten Unternehmen und mach da mal ein Praktikum und lerne, wie in der realen Welt entwickelt wird. Du kannst noch viel lernen.
Wie es meines Erachtens laufen sollte:
Das zu entwickelnde Gerät wird hinsichtlich der zu entwickelnden
Baugruppen analysiert und es werden entsprechende EMV Vorgaben für die
einzelnen Baugruppen aufgestellt. Ebenso spielt bereits das Design des
Gehäuses eine Rolle. Denn mit einem guten Gehäuse lassen sich viele
Probleme vermeiden (Farraday'scher Käfig). Die Entwickler der einzelnen
Baugruppen müssen die Vorgaben erfüllen und ihr entwickeltes Zeug
testen.
Und wie sieht dein optimales Gehäuse aus, wenn du WLAN und/oder Bluetooth in dein Gehäuse integrieren musst? Oder Metal aus Gewichts-, Kosten- oder Designgründen nicht gewollt ist? Das Gerät muss für den Anwender am Ende ja auch benutzbar sein.
Und wie sieht dein optimales Gehäuse aus, wenn du WLAN und/oder
Bluetooth in dein Gehäuse integrieren musst?
Natuerlich im Plastik Gehaeuse.
Dann waere Zeit, ein Simulationstool anzuwerfen. Beide Antennen haetten gerne eine passende Impedanz, ausser man hat beliebig zuviel Leistung. Und das schafft man nut bei Co-Simulation von beiden Antennen gleichzeitig.
Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft,
dass es irgendwie mit ein paar Ferriten schon hinhaut >_<
Das ist auch der Grund, warum du nicht im Lotto gewinnst: du bist
schlecht im Raten.
Wer aufs "Raten" angewiesen ist und auch den Kollegen "Raten" als Methode unterstellt, ist IMHO komplett ungeeignet für Jobs mit Verantwortung wie eben als Entwicklungsingenieur.
Da passt "Stand-up comedian" besser in die Berufswahl, vielleicht mal vom Lebenslauf eines Mirco Nontschew inspirieren lassen.
Wie es meines Erachtens laufen sollte:
Das zu entwickelnde Gerät wird hinsichtlich der zu entwickelnden
Baugruppen analysiert und es werden entsprechende EMV Vorgaben für die
einzelnen Baugruppen aufgestellt.
Das allein ist so ohne weiteres gar nicht möglich bzw. sinnvoll. Denn am Ende wird nur das Gesamtgerät geprüft und freigegeben. Klar wird man bei der Suche nach EMV-Problemen dann wieder rückwärts gehen (müssen) und einzelne Baugruppen testen. Die testet man aber meistens nicht gegen eine Norm sondern eher qualitativ.
Ebenso spielt bereits das Design des
Gehäuses eine Rolle. Denn mit einem guten Gehäuse lassen sich viele
Probleme vermeiden (Farraday'scher Käfig).
Im Prinzip schon, aber nicht jedes Gerät kann sich sowas leisten. Und ein HF-dichtes Gehäuse allein löst meistens keine EMV-Probleme, denn ein Großteil koppelt über Zuleitungen aus.
Die Entwickler der einzelnen
Baugruppen müssen die Vorgaben erfüllen und ihr entwickeltes Zeug
testen.
Funktioniert nur teilweise.
Aus Gründen des Zeitdrucks wird darauf losentwickelt. Es gibt lediglich
best practices, die sich als funktionierend erwiesen haben und an die
sich die Entwickler zu halten haben. Wenn es nun zu einem EMV Problem
kommt gibt es verwirrende Gesichter bei den Entwicklern.
So weit, so normal. Wobei jeder weiß, der schon mindestens einmal das Thema komplett durch hat und kein Power Point Traumtänzer ist, daß praktisch kein Gerät beim ersten Versuch die EMV-Prüfung besteht. Irgendwas ist immer.
Nun folgen
wiederum EMV-Maßnahmen, die sich ebenso bewährt haben mit denen versucht
wird das EMV-Problem zu beheben.
Ja und?
Durch diese Art des Vorgehens können
die Entwickler jedoch kein tiefgründiges Wissen in der EMV aufbauen.
Wissen baut man in Seminaren auf. Fähigkeiten in der Anwendung des Wissen in der Praxis.
Ganz im Gegenteil es sorgt für noch mehr Verwirrung, wenn die best
practices nicht funktionieren.
Unsinn.
Die letztere Variante ist oft teurer. Denn EMV Probleme werden teurer
und schwieriger zu lösen je später sie entdeckt werden.
Stimmt.
Wenn der
Prototyp bereits steht sind die Lösungsmöglichkeiten beschränkt und oft
müssen teure Bauelemente her, um das Problem in den Griff zu bekommen.
Stimmt so allgemein nicht. Der größte Aufwand ist erstmal, die Störquelle und den Koppelmechanismus zu finden.
Das ist die bekannte Kostenexplosion.
Geschwätz.
Viel sinnvoller ist es in das EMV
Wissen der Entwickler zu investieren
Mit Seminaren und ähnlichem.
und EMV Probleme bereits früh zu
identifizieren und zu vermeiden.
Sicher. Das gilt aber für alle möglichen Entwurfsprobleme.
Mit einer guten EMV Planung lassen sich
90% der EMV Probleme vermeiden. rant over!!!
Klingt danach, als ob es bei dir mal wieder brennt. Wasser marsch! ;-)
Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft,
dass es irgendwie mit ein paar Ferriten schon hinhaut >_<
Nö. Ich und die meisten meiner Kollege denken schon bissel nach. Trotzdem wird man kaum beim 1. Schuß einen Volltreffer bei der EMV landen, dazu ist das Thema zu komplex.
Denn mit einem guten Gehäuse lassen sich viele
Probleme vermeiden (Farraday'scher Käfig).
Wenn du dir mal "EMV dichte" Gehäuse anschaust, weißt du, weshalb das
nicht praktikabel ist.
Unsinn. Ein HV-dichtes Gehäuse KANN EMV-Probleme vermeiden, ist aber kein Wundermittel, das ALLE Probleme löst!
Die Entwickler der einzelnen
Baugruppen müssen die Vorgaben erfüllen und ihr entwickeltes Zeug
testen.
Am Ende wird aber das Gesamtsystem getestet und was die Baugruppen
machen, ist völlig irrelevant.
Falsch! Denn irgendwo gibt es ja die Störquelle, die man ggf. finden und dämpfen muss.
Leitungsgebundene Störungen interessieren
dich innerhalb eines Gerätes zum Beispiel gar nicht.
Auch falsch! Denn die können über interne Verbindungen dann nach außen gelangen.
Geh mal in eine echte Hardwareentwicklung in einem echten Unternehmen
und mach da mal ein Praktikum und lerne, wie in der realen Welt
entwickelt wird. Du kannst noch viel lernen.
Oder auch viele neue Dilbert-Comis zeichnen! ;-)
Da draußen ist bei weitem nicht alles Gold, was glänzt. Weder technisch und schon dreimal nicht organisatorisch!
Denn mit einem guten Gehäuse lassen sich viele
Probleme vermeiden (Farraday'scher Käfig).
Na, wenn du den Stein der Weisen gefunden hasst, dann nutze ihn und schreibe das Vor! Das funktioniert ja auch, bis auf 3 Sonderfälle:
1.: es gehen Kabel in das Gerät. Kabel sind immer auch: Antennen. Das beste Gehäuse bringt dir nichts, wenn du mit einem Kabel die Störungen nach draußen bringst.
2.: Displays. Displays sind, speziell mit einem Touch screen davor, EMV problematisch, immer. Am besten weglassen.
3.: Manche Geräte sind so wunderbar gebaut, dass sie sich selbst stören. Das kann von stets pfeifenden Lautsprechern bis hin zu sporadischen Abstürzen alles sein, selbst Temperaturempfindlichkeit kann hier auftreten.
Du siehst: EMV ist alles, aber nichts, wofür es DIE eine Lösung gibt. Es ist immer eine Mischung aus verschiedenen Verfahren, die sich teilweise gegenseitig ausschließen. Also muss man sich für jeden Anwendungsfall neu überlegen, welche Lösung hier die passende ist. Das geht nur mit Erfahrung und die erhält man nur, indem man aus Fehlern (gern auch nur denen der anderen) lernt.
Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft,
dass es irgendwie mit ein paar Ferriten schon hinhaut >_<
Die Ferrite sind am Ende die Notlösung, welche die letzten fehlenden 1-2dB zum Grenzwert noch herausholen können. Genausogut kann aber eine Veränderung der Kabelverlegung im Gerät helfen. Das muss man halt in jedem Fall in der Messkammer optimieren.
Einer muss den Durchblick haben, der macht die Vorgaben. Dann passt das
schon.
die Vorgaben kommen aus dem Marketing: sie lauten: CE Kennzeichnung und maximale Herstellkosten (ah und natürlich muss das Gerät bessere Parameter bieten als die Konkurrenz, so vorhanden). Wie man das erreicht, ist dann Aufgabe der Entwicklungsabteilung.
Und am Ende kommt dann ja noch sowas nettes wie: man hat 2 Baugruppen, welche für sich genommen die EMV bestehen, aber zusammen agieren sie wie der Elefant im Porzellanladen. Wenn das nun 2 Zulieferteile sind (z.B. ein Netzteil und eine Funktionseinheit) dann viel Spaß mit dem Einwirken auf die Entwickler... Dann ist es dein Job, nicht nur die Steuerung der Funktionsbaugruppe zu realisieren sondern auch dafür zu sorgen, dass die beiden Störenfriede sich vernünftig benehmen. Das kann manchmal auch bedeuten, dass man einzelne dieser Strolche in ein separates Gehäuse verbannt. Kostet halt wieder Geld und Platz und ist in der Montage und im Service nervig. Also eher die letzte Verzweiflungstat.
