{"id":4003,"date":"2026-08-13T11:53:09","date_gmt":"2026-08-13T09:53:09","guid":{"rendered":"https:\/\/essaar.de\/?p=4003"},"modified":"2026-08-17T15:43:27","modified_gmt":"2026-08-17T13:43:27","slug":"elektronikentwicklung-entscheidungen","status":"publish","type":"post","link":"https:\/\/essaar.de\/en\/elektronikentwicklung-entscheidungen\/","title":{"rendered":"Elektronikentwicklung: Entscheidungen"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"Elektronikentwicklung\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Elektronikentwicklung: Fehlentscheidungen sind teuer<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Manche Entscheidungen lassen sich einfach zur\u00fccknehmen, andere nur mit erheblichem Aufwand oder gar nicht. Jeff Bezos nennt letztere Einwegt\u00fcren. In der Software sind die meisten Entscheidungen mit geringem Aufwand revidierbar – Zweiwegt\u00fcren. In der Elektronik die wenigsten: Die Korrektur einer Entscheidung ist hier meist eine Vorw\u00e4rts-Kaskade: Alle Schritte nach dieser Entscheidung m\u00fcssen wieder gepr\u00fcft, abgestimmt und gegebenenfalls neu durchgef\u00fchrt werden. Diese Enscheidungen sind Einwegt\u00fcren. Dieser Artikel zeigt, warum das so ist, wie der Entwicklungsprozess aufgebaut ist, und wie funktionale Anforderungen umgesetzt und mit Performance-Anforderungen abgewogen werden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t

\n\t\t\t\t\"Some decisions are consequential and irreversible or nearly irreversible \u2013 one-way doors \u2013 and these\ndecisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk\nthrough and don\u2019t like what you see on the other side, you can\u2019t get back to where you were before. We can call\nthese Type 1 decisions. But most decisions aren\u2019t like that \u2013 they are changeable, reversible \u2013 they\u2019re two-way\ndoors. If you\u2019ve made a suboptimal Type 2 decision, you don\u2019t have to live with the consequences for that long.\nYou can reopen the door and go back through. Type 2 decisions can and should be made quickly by high\njudgment individuals or small groups.\u201c \t\t\t<\/p>\n\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\tJeff Bezos, 2015, Brief an die Amazon Aktion\u00e4re<\/cite>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/blockquote>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Interdependenzen und teure Revisionen<\/h3>

Die erste Frage: Warum sind in der Software die meisten Umsetzungs-Entscheidungen g\u00fcnstig revidierbar und in der Elektronik nicht? In der Software l\u00e4sst sich eine \u00c4nderung einschlie\u00dfen (nicht immer, z.B. beim Datenbankmodell – aber h\u00e4ufiger als bei Hardware). Ein Fix repariert innerhalb eines Moduls, hinter einem definierten Interface, und was au\u00dferhalb liegt, bleibt unber\u00fchrt. Elektronik l\u00e4sst sich nicht so trennen, jedenfalls nicht vollst\u00e4ndig. Ein Schaltregler mit h\u00f6herer Schaltfrequenz koppelt St\u00f6rungen in die benachbarte Analogschaltung, so sauber der Schaltplan die beiden auch trennt. Ein Kondensator mit gleichem Kapazit\u00e4tswert, aber anderem Innenwiderstand, bringt die Spannungsregelung zum Schwingen. Ein Bauteil mit h\u00f6herer Verlustleistung erw\u00e4rmt seinen Nachbarn, dessen Kennwerte daraufhin driften. Und ein anderer Mikrocontroller ver\u00e4ndert fast alles: Pinout, Peripherie, Firmware, Toolchain.<\/p>

Interdependenzen lassen sich minimieren, nie vollst\u00e4ndig aufl\u00f6sen. Deshalb bleibt eine Korrektur selten nur dort, wo sie gemacht wurde. Ist ein Bauteil gew\u00e4hlt, ein Schaltplan freigegeben, ein Layout geroutet, gibt es selten einen kurzen R\u00fcckweg. Schauen wir uns diesen Weg an.<\/p>

Etappen der Elektronikentwicklung<\/h3>

Elektronikentwicklung ist der Prozess, funktionale Anforderungen in Elektronik umzusetzen und dabei Performance-Anforderungen zu erf\u00fcllen und gegeneinander abzuw\u00e4gen.<\/b><\/p>

Brechen wir diesen Satz auf: Funktionale Anforderungen sind das \u201ewas\u201c. Welche Signale kommen rein, welche gehen raus, mit welcher Versorgung, \u00fcber welche Schnittstelle, mit welcher Steuerung. Performance-Anforderungen sind das \u201ewie gut\u201c. Nicht \u201efunktioniert die Schaltung\u201c, sondern: l\u00e4sst sie sich wirtschaftlich fertigen, zu welchen Kosten, unter welcher Zulassung, wie gut pr\u00fcfbar, wie lange am Markt verf\u00fcgbar. Jede Etappe baut auf der vorherigen auf, sodass ein fr\u00fcher Fehler durch alle Folgenden mitwandert. Agile Methoden funktionieren kaum – ihr Kernprinzip (schnelle, g\u00fcnstige Korrektur) funktioniert hier nicht.<\/p>

Concept<\/strong><\/h5>

Mit einem Konzept als Grundlage kann entschieden werden, ob ein Projekt zur Umsetzung freigegeben wird. In diesem Artikel<\/span><\/a><\/strong> wurde beschrieben, wie die Konzeption abl\u00e4uft. Am Ende stehen vier Dinge: eine strukturierte Anforderungsdokumentation, eine funktionale System-Architektur, der Rahmen f\u00fcr Beschaffung inklusive einer groben Kostensch\u00e4tzung und einem Entwicklungsangebot f\u00fcr die anschlie\u00dfende Umsetzung.<\/p>

Pre-development<\/strong><\/h5>

Ausgangspunkt sind Anforderungen und das Blockschaltbild aus der Konzeptphase. F\u00fcr jede Anforderung und jeden Funktionsblock gibt es mehrere m\u00f6gliche Teill\u00f6sungen: Ein Sensor l\u00e4sst sich \u00fcber verschiedene Schnittstellen anbinden, eine Versorgung \u00fcber verschiedene Wandlertopologien realisieren. Die Vorentwicklung sammelt diese Optionen aus Datenbl\u00e4ttern und Errata Sheets und kombiniert sie zu einer Gesamtl\u00f6sung, die in sich stimmig ist. Teill\u00f6sungen, die einzeln \u00fcberzeugen, passen nicht automatisch zusammen: Eine morphologische Analyse zeigt Konflikte und Kompromisse in Funktion und Performance. Wenn etwa der technisch und wirtschaftlich beste Controller in f\u00fcnf Jahren abgek\u00fcndigt wird, ist er trotzdem keine Option. Am Ende steht eine Festlegung zu Topologien, Bauteilklassen und den zentralen Komponenten. Damit ist diese Etappe die k\u00fcrzeste im Prozess und die teuerste, wenn sie falsch ausgeht. Ein Controllerwechsel sp\u00e4ter kostet nicht ein Bauteil, sondern gro\u00dfe Teile von Schaltplan, Layout und Firmware und erfordert in der Regel eine erneute Zulassungspr\u00fcfung.<\/p>

Circuit diagram development<\/strong><\/h5>

Der Schaltplan wird um die festgelegten Hauptkomponenten herum aufgebaut. Zwischen den funktionalen Bl\u00f6cken liegen Hilfsschaltungen f\u00fcr Schutz, Filterung und Potentialtrennung. Signal- und Leistungspfade werden getrennt, kritische Signale und Versorgungen identifiziert. Kritische Teile werden modelliert und simuliert: Ein Fehler auf dem Papier kostet Stunden, derselbe Fehler in der Fertigung kostet Wochen. Am Ende stehen Schaltplan und St\u00fcckliste, mit konkreten Teilenummern und damit einem Gro\u00dfteil der sp\u00e4teren Kosten.<\/p>

Layout<\/strong><\/h5>

Der Schaltplan wird in eine physische Leiterplatte \u00fcbersetzt: Bauteile werden platziert, Verbindungen gef\u00fchrt, kritische Bereiche simuliert. \u00dcbersetzung hei\u00dft hier aber nicht Abschrift. Eine Verbindung ist im Schaltplan eine Linie ohne Eigenschaften, w\u00e4hrend sie auf der Leiterplatte L\u00e4nge, Impedanz und eine Kopplung zur Nachbarbahn hat. Zwei Layouts desselben Schaltplans k\u00f6nnen sich deshalb v\u00f6llig unterschiedlich verhalten: Das eine funktioniert, das andere zeigt St\u00f6rungen, die im Schaltplan nirgends angelegt waren. Das Layout l\u00e4uft nicht isoliert. Es wird mit der Konstruktion abgestimmt, damit die Elektronik mechanisch ins Geh\u00e4use passt, und es entscheidet mit \u00fcber die sp\u00e4tere Pr\u00fcfbarkeit: Testpunkte und Zug\u00e4nge f\u00fcr den Fertigungstest m\u00fcssen hier vorgesehen werden. Wer sie nicht einplant, kann sie sp\u00e4ter nicht nachr\u00fcsten. Am Ende stehen die Fertigungsdaten. Ab ihrer Freigabe kostet (fast) jede \u00c4nderung einen kompletten Prototypenzyklus: neue Fertigungsdaten, neue Leiterplatten, neue Best\u00fcckung, neuer Test.<\/p>

Nach der\u00a0Elektronikentwicklung\u00a0<\/b><\/h5>

Damit endet die Elektronikentwicklung im engeren Sinn. Was folgt (Prototypenbau, Softwareintegration, Validierung, Markteinf\u00fchrung, Betrieb) geh\u00f6rt formal nicht mehr dazu. Aber genau dort fallen die Fehler auf. Ein falsch gew\u00e4hlter Controller zeigt sich in der Softwareintegration, eine untersch\u00e4tzte St\u00f6reinkopplung erst in der EMV-Pr\u00fcfung, ein Obsoleszenzrisiko erst nach Jahren im Feld. Diese Verz\u00f6gerung zwischen Entscheidung und R\u00fcckmeldung macht Elektronikentwicklung schwer planbar.<\/p>

Performance Anforderungen\u00a0<\/b><\/p>

Performance-Anforderungen widersprechen sich oft. Was schneller fertig wird, ist oft teurer, was billiger wird, ist schlechter pr\u00fcfbar und was pr\u00fcfbar bleibt, braucht Platz, der anderswo fehlt. Es gibt keine L\u00f6sung, die alle Anforderungen zugleich optimal erf\u00fcllt. Es gibt nur eine L\u00f6sung, die bewusst gewichtet. Design for X ist der Sammelbegriff f\u00fcr diese Perspektiven. Eine feste Liste gibt es nicht.<\/p>

Design for Manufacturability (DFM)<\/b><\/h5>

L\u00e4sst sich das Design zuverl\u00e4ssig und wirtschaftlich in Serie fertigen? Ein Design, das im Labor funktioniert, in der Serie aber eine hohe Ausschussrate erzeugt, ist wirtschaftlich unbrauchbar und die Ausschussrate entsteht im Layout, nicht in der Fertigung. Ein Beispiel: Via-in-Pad und Backdrill l\u00f6sen Platzprobleme, die sich bei dicht best\u00fcckten Baugruppen anders kaum l\u00f6sen lassen. Beide Verfahren beherrschen nicht alle Fertiger, beide verl\u00e4ngern die Prozesskette und verteuern die Leiterplatte. Technisch m\u00f6glich sind beide; ob sich der gewonnene Platz \u00fcber die geplante St\u00fcckzahl auszahlt, ist die eigentliche Frage.<\/p>

Design to Cost (DTC)<\/b><\/h5>

DTC ist eine Gratwanderung. Unbewusste \u00dcberdimensionierung ist ein Kostentreiber und unqualifizierte Verbilligung birgt die Gefahr eines Totalausfalls. Es geht also darum, Komponenten- und Fertigungsentscheidungen so zu treffen, dass die Anforderungen mit den geringsten Kosten erf\u00fcllt werden. Ein Design pauschal billiger zu machen, ist damit jedoch nicht gemeint. Ein Beispiel auf der Komponentenseite w\u00e4re ein ADC oder ein Spannungsregler mit Spezifikationen, die keine der Anforderungen tats\u00e4chlich verlangt, oder eine diskret aufgebaute Schaltung, die es integriert g\u00fcnstiger gibt. Umgekehrt kann es auch eine integrierte L\u00f6sung sein, f\u00fcr die drei Bauteile gereicht h\u00e4tten. Auch der Preis elektromechanischer Verbindungselemente wird regelm\u00e4\u00dfig untersch\u00e4tzt: Steckverbinder kosten oft mehr als die Halbleiter, die sie verbinden.<\/p>

Auf der Fertigungsseite: ein Lagenaufbau mit einer Lage mehr als n\u00f6tig, oder eine beidseitige Best\u00fcckung, wo einseitig gereicht h\u00e4tte. Jeder zus\u00e4tzliche Best\u00fcckungsdurchlauf ist ein zus\u00e4tzlicher Prozessschritt in der Serie. PCBA-Dienstleister schlagen regelm\u00e4\u00dfig g\u00fcnstigere Bauteilalternativen aus ihren eigenen Lieferketten vor. Das kann ein legitimer Hebel sein, denn der Dienstleister kauft dort tats\u00e4chlich besser ein. Es erfordert aber eine belastbare Qualifikation: Stimmen Toleranzen, Zertifizierungen und Langzeitverf\u00fcgbarkeit wirklich mit dem spezifizierten Original \u00fcberein? Wer das \u00fcberspringt, spart am ersten Einkaufspreis und zahlt langfristig drauf.
Der Hebel liegt in Vorentwicklung und Schaltplan, nicht im Einkauf: Wer erst beim Angebot des Fertigers \u00fcber Kosten spricht, verhandelt \u00fcber Entscheidungen, die zwei Etappen vorher gefallen sind.<\/p>

Design for Obsolescence (DFO)<\/strong><\/h5>

Jedes Bauteil wird irgendwann abgek\u00fcndigt. Entscheidend ist, was das Produkt dann kostet, wenn es so weit ist. Ein Ger\u00e4t mit zehn Jahren Marktlebensdauer braucht hier andere Antworten als eines mit zwei.
Mit diesem Thema kann man auf drei Arten umgehen: Reaktiv, Proaktiv und im Designprozess. Reaktiv bedeutet, abzuwarten, bis der Hersteller die Abk\u00fcndigung meldet, und dann unter Zeitdruck zu improvisieren, da die Restkaufmenge begrenzt ist. Proaktiv bedeutet, die verbleibende Marktlebenszeit kritischer Bauteile vorab zu sch\u00e4tzen und die Abl\u00f6sung einzuplanen. Datenbanken wie Z2Data oder SiliconExpert liefern daf\u00fcr Lifecycle-Prognosen. Im Design bedeutet es, von vornherein Komponenten mit stabiler Langzeitverf\u00fcgbarkeit auszuw\u00e4hlen. Viele Hersteller bieten daf\u00fcr eigene Longevity-Programme mit garantierten Verf\u00fcgbarkeitszeitr\u00e4umen an.
Ein Redesign wegen eines abgek\u00fcndigten Bauteils kostet Layout, Prototypen, Tests und je nach \u00c4nderung eine erneute Zulassung \u2013 f\u00fcr ein Produkt, das danach exakt dasselbe kann wie vorher.<\/p>

Design for Compliance (DFC)<\/strong><\/h5>

Compliance l\u00e4uft von Anfang an mit; sie ist keine Pr\u00fcfung, die erst am Ende passiert. Welche Normen gelten, entscheidet \u00fcber Isolationsabst\u00e4nde, Filterkonzepte und Materialauswahl. Das sind Entscheidungen, die im Schaltplan und Layout getroffen werden, nicht im Pr\u00fcflabor. Wer die Zertifizierungsanforderungen erst kennt, wenn das Produkt fertig ist, hat sie faktisch schon beantwortet, nur unbeabsichtigt.<\/p>

Wie gut ein Design die geforderten Kennwerte einh\u00e4lt, l\u00e4sst sich mit sehr unterschiedlichem Aufwand vorhersagen. Dies reicht von Daumenregeln \u00fcber Simulationen bis hin zu Feldversuchen. Dabei sollte der Aufwand proportional zur Bedeutsamkeit der Stelle wachsen: Nicht jede Leiterbahn braucht eine Impedanzsimulation, aber wenn man die falsche ungepr\u00fcft l\u00e4sst, kostet das einen Pr\u00fcftermin. Eine belastbare Aussage ergibt sich ohnehin erst durch eine Messung am realen Aufbau.<\/p>

Precompliance vor der Zertifizierung:<\/strong> Eine Voruntersuchung unter vergleichbaren Bedingungen kostet Zeit, aber sie kostet keinen Pr\u00fcftermin. Ein Redesign nach gescheiterter Precompliance ist \u00e4rgerlich. Ein Redesign nach gescheiterter offizieller Pr\u00fcfung ist teurer und kostet zus\u00e4tzlich die Wartezeit auf den n\u00e4chsten freien Termin.<\/p>

Funk als Sonderfall: <\/strong>Bei Funkanwendungen gibt es einen Hebel, der Kosten und Risiko deutlich senkt: Statt eine eigene Funkschaltung zu entwickeln und vollst\u00e4ndig zertifizieren zu lassen, wird ein bereits zertifiziertes Modul eingebunden. Der Hersteller gibt daf\u00fcr ein Integrationsverfahren vor, zum Beispiel die Leiterbahnf\u00fchrung, Antennenanbindung, Abst\u00e4nde. Wird es eingehalten, l\u00e4sst sich die bestehende Zertifizierung meist \u00fcbernehmen. Wird davon abgewichen, verf\u00e4llt der Vorteil vollst\u00e4ndig, und die Funkpr\u00fcfung beginnt bei null.<\/p>

Design for Testability (DFT)<\/strong><\/h5>

Wie gut l\u00e4sst sich ein Fehler in der Entwicklung, in der Fertigung, im Feld finden? Testbarkeit hei\u00dft, gezielt zu platzieren, statt alles messbar zu machen. Kritische Signale, Versorgungsspannungen und Kommunikationsschnittstellen brauchen Testzugang, nicht jedes Netz auf der Leiterplatte. Wird das erst mitgedacht, wenn das Layout steht, bleibt oft nur Platz f\u00fcr Testpunkte an Stellen, die diagnostisch wenig hergeben. Von Anfang an geplant, reichen wenige, gut gew\u00e4hlte Punkte f\u00fcr eine hohe Fehlerabdeckung.<\/p>

Der entscheidende Punkt: Die Testverfahren sind nicht die Designentscheidung. Sie existieren unabh\u00e4ngig davon, ob ein Design f\u00fcr sie vorbereitet wurde. DFT ist die Vorleistung, die ins Design investiert werden muss, damit ein Verfahren sp\u00e4ter \u00fcberhaupt funktioniert. Und diese Vorleistung ist von Verfahren zu Verfahren v\u00f6llig unterschiedlich.<\/p>

Optische Inspektion und R\u00f6ntgen lassen sich sp\u00e4ter zuschalten und stellen kaum Anforderungen an das Design. In-Circuit-Test und Boundary Scan hingegen schon: Wer keine Testpunkte gesetzt und keine Scan-Kette geroutet hat, kann beide Optionen nicht nachtr\u00e4glich nachr\u00fcsten. Diese Option f\u00e4llt dann weg. Die eigentliche Frage lautet deshalb nicht \u201eWelches Verfahren?\u201c, sondern \u201eWie viel Designvorleistung rechtfertigt die geplante St\u00fcckzahl?\u201c.<\/p>

Testbarkeit endet nicht am Fabriktor:<\/strong> Die gleiche Diagnosef\u00e4higkeit, die in der Fertigung Fehler erkennt, ist sp\u00e4ter daf\u00fcr verantwortlich, wie gut sich ein Ger\u00e4t warten, reparieren oder wiederaufbereiten l\u00e4sst. Ein Testpunkt, der beim Fertigungstest hilft, ist Jahre sp\u00e4ter derselbe Punkt, an dem sich ein Garantiefall nachweisen oder die Frage „Reparieren oder verschrotten?“ beantworten l\u00e4sst. Eine maschinenlesbare Serialisierung auf der Leiterplatte (etwa in Form eines Data-Matrix-Codes) macht daraus eine \u00fcber den gesamten Lebenszyklus hinweg nachvollziehbare Historie. Wer Testbarkeit nur f\u00fcr die eigene Fertigungslinie plant, verschenkt diesen zweiten Nutzen.<\/p>

Fazit<\/h2>
Elektronikentwicklung ist eine Kette von Entscheidungen, die sich nur mit erheblichem Aufwand revidieren lassen. Von der Vorentwicklung, in der die weitreichendsten Entscheidungen getroffen werden, bis hin zum Layout, bei dem sich die Pr\u00fcf- und Fertigbarkeit entscheiden.<\/div>
Design for X ist keine Pr\u00fcfliste f\u00fcr das Ende. Fertigbarkeit, Kosten, Obsoleszenz, Zulassung und Pr\u00fcfbarkeit werden in denselben Etappen mitentschieden, in denen die Funktion entsteht. Was dort nicht bedacht wird, l\u00e4sst sich sp\u00e4ter nur noch teuer nachholen und manches gar nicht.<\/div><\/div>

Erschwerend kommt die Verz\u00f6gerung hinzu. Die R\u00fcckmeldung auf eine Entscheidung kommt Monate oder Jahre sp\u00e4ter. Schwer zu planen macht die Elektronikentwicklung deshalb weniger die technische Komplexit\u00e4t als die Balance widerspr\u00fcchlicher Anforderungen und der Abstand zwischen Entscheidung und Konsequenz.<\/p>

Daraus folgt eine Konsequenz f\u00fcr die Planung: Die Zeit, die vor den ersten Prototypen liegt, ist kein Vorlauf, den man verk\u00fcrzen sollte. Sie ist der Teil des Projekts, in dem die Kosten der n\u00e4chsten zehn Jahre festgelegt werden. Wer hier Wochen spart, zahlt sie sp\u00e4ter in ganzen Entwicklungszyklen zur\u00fcck.<\/p>

Deshalb ist die Konzeption bei uns eine eigene Phase, die genau diese Planung vorbereitet. Wir kl\u00e4ren dort nicht nur die Anforderungen, sondern sch\u00e4tzen den Entwicklungsaufwand, den dieser Beitrag beschrieben hat.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Elektronikentwicklung funktioniert nicht wie Software: Eine Korrektur kaskadiert vorw\u00e4rts durch den Prozess: alles, was nach der Entscheidung entstanden ist, muss neu gepr\u00fcft werden.<\/p>\n

    \n
  • Interdependenzen lassen sich minimieren, nie vollst\u00e4ndig aufl\u00f6sen. Deshalb bleibt eine Korrektur selten nur dort, wo sie gemacht wurde.<\/li>\n
  • Jede Etappe fixiert, was die vorherige entschieden hat. Ab Freigabe der Fertigungsdaten kostet jede \u00c4nderung einen kompletten Prototypenzyklus.<\/li>\n<\/ul>\n
      \n
    • Elektronikentwicklung ist der Prozess, funktionale Anforderungen in Elektronik umzusetzen und dabei Performance-Anforderungen zu erf\u00fcllen und gegeneinander abzuw\u00e4gen.<\/li>\n<\/ul>\n

      <\/div>\n
      Elektronikentwicklung ist eine Kette von Entscheidungen, die sich nur mit erheblichem Aufwand revidieren lassen  – Entscheidungen m\u00fcssen \u00e4u\u00dferst sorgf\u00e4ltig getroffen werden.<\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"

      Manche Entscheidungen lassen sich zur\u00fccknehmen, andere nicht. Jeff Bezos nennt letztere Einwegt\u00fcren, f\u00fcr uns passt das Bild der Stra\u00dfe besser. In der Software ist fast jede Stra\u00dfe zweiseitig befahrbar. In der Elektronik nicht. Eine Korrektur bedeutet, die Strecke noch einmal zu fahren, und das kostet Wochen. Dieser Artikel zeigt warum das so ist, wie der Entwicklungsprozess aufgebaut ist, und wie funktionale Anforderungen umgesetzt und mit Performance-Anforderungen abgewogen werden.<\/p>","protected":false},"author":2,"featured_media":4052,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"elementor_header_footer","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"post_folder":[],"class_list":["post-4003","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein"],"_links":{"self":[{"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/posts\/4003","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/comments?post=4003"}],"version-history":[{"count":103,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/posts\/4003\/revisions"}],"predecessor-version":[{"id":4128,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/posts\/4003\/revisions\/4128"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/media\/4052"}],"wp:attachment":[{"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/media?parent=4003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/categories?post=4003"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/tags?post=4003"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/essaar.de\/en\/wp-json\/wp\/v2\/post_folder?post=4003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}