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 >_<
:
Verschoben durch Moderator
> 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 ... https://de.wikipedia.org/wiki/Peter-Prinzip
:
Bearbeitet durch User
Robert G. schrieb: > verwirrende Gesichter Wenn die Gesichter mehr verwirren als die EMV-Probleme hilft vielleicht ein Coaching.
Robert G. schrieb: > 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. Robert G. schrieb: > 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. Robert G. schrieb: > 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. Robert G. schrieb: > 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. Robert G. schrieb: > 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. Robert G. schrieb: > 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. Robert G. schrieb: > 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? Robert G. schrieb: > 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.
Bradward B. schrieb: > 100% > vermeiden kann man Probleme/Fehler nur durch Nicht-Tätigkeit. Aber da > derjenige befördert wird, der keine Probleme/Fehler schafft ... Das entspricht der Regel: "Wer arbeitet macht Fehler, wer viel arbeitet macht viele Fehler, wer keine Fehler macht, wird befördert!". :)
Einer muss den Durchblick haben, der macht die Vorgaben. Dann passt das schon. Ja, der Chefentwickler muss die EMV drauf haben.
Pandur S. schrieb: > Ja, der Chefentwickler muss die EMV drauf haben. Dafür hat man als Chef zu wenig Zeit, das delegiert man an Leute die das noch viel besser drauf haben.
Robert G. schrieb: > 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. Mit freundlichen Grüßen Thorsten Ostermann
> 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.
Robert G. schrieb: > 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.
>> 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. https://www.youtube.com/watch?v=9sXhfyXOiL4
:
Bearbeitet durch User
Angehängte Dateien:
-
EMV.png
11 KB
Robert G. schrieb: > Wie es meines Erachtens laufen sollte: Aha. > > Lasst mich raten bei euch wird darauf losentwickelt und dann gehofft, > dass es irgendwie mit ein paar Ferriten schon hinhaut >_< Da haben klügere Köpfe als Du es bis das in weniger Worten dargestellt (C) Jim Williams in einer seiner vielen ANs von LT... Immerhin hast Du es geschafft mit einem Blabla-Text ein paar Antworten auszulösen... für den Null-Inhalt Deiner Worte bemerkenswert.
Robert G. schrieb: > 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.
Sebastian R. schrieb: > Robert G. schrieb: >> 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!
Falk B. schrieb: > Unsinn. Ein HV-dichtes Gehäuse KANN EMV-Probleme vermeiden, ist aber > kein Wundermittel, das ALLE Probleme löst! Wie kommst du denn von EMV auf HV? Falk B. schrieb: > Falsch! Denn irgendwo gibt es ja die Störquelle, die man ggf. finden und > dämpfen muss. Aber am Ende testest du das Gesamtsystem und das kann wieder anders aussehen als die Baugruppen. Falk B. schrieb: > Auch falsch! Denn die können über interne Verbindungen dann nach außen > gelangen. Sind dann aber nicht mehr leitungsgebunden sondern abgestrahlt. Und es geht auch um Störfestigkeit.
Robert G. schrieb: > 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. Robert G. schrieb: > 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. Robert G. schrieb: > Die letztere Variante ist oft teurer. Denn EMV Probleme werden teurer > und schwieriger zu lösen je später sie entdeckt werden. Das ist wohl so. Deshalb versucht man, mit best practice, dies bereits von Anfang an zu vermeiden, jedenfalls, wenn man etwas davon versteht. Pandur S. schrieb: > 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.
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.