Auswirkungen von PCB-Revisionen auf die eingebettete Software

In den letzten Jahren haben wir einige kleinere Überarbeitungen an unserer Leiterplatte vorgenommen, darunter

  • Unterschiedliche Komponentenauswahl (Widerstände / Kappen / ...) nach Verfügbarkeit / Preis (unter Berücksichtigung ihrer ursprünglichen Eigenschaften)
  • Komponentenlayout auf der Leiterplatte
  • Leiterbahnbreiten / -längen (durch Layout bedingt)

Was wir oft festgestellt haben, ist, dass wir unsere Software nach jeder dieser Überarbeitungen optimieren mussten, obwohl sich diese Änderungen nicht wirklich auf die eingebettete Software auswirken sollten.

Einige Hardware-Revisionen brachten eine Instabilität mit sich, die erst nach Tagen / Wochen / Monaten auftauchte (z. B. die Unfähigkeit, eine bestimmte Komponente auf der Platine umzuschalten).

Wir mussten High/Low-Sequenzen und Timeouts für serielle Leitungen optimieren

Das große Problem ist, dass diese Probleme nicht sofort auftauchen, sondern manchmal Wochen/Monate dauern, bevor sie auftauchen, was es schwierig macht, Korrekturmaßnahmen durchzuführen (insbesondere, wenn eines der Probleme darin besteht, dass das Modem nicht umgeschaltet werden kann ein Firmware-Update durchführen).

Gibt es Richtlinien/Best Practices, um dieses Risiko zu eliminieren? (Eine Art Stresstestverfahren / Dinge, die wir bei solchen Überarbeitungen berücksichtigen müssen?

Diese Richtlinien heißen Testen, in einigen Unternehmen gibt es so etwas wie "QA-Abteilungen".
Und ich denke, ein richtiges anfängliches Design hilft auch ... Sowohl von HW als auch von FW. Überlassen Sie dies erfahrenen Fachleuten oder beauftragen Sie sie zumindest mit der Überwachung des Prozesses.
Wir sind ein kleines Startup und führen interne Bench-Tests durch und versuchen, Stresstests durchzuführen. Aber diese Probleme treten erst im Feld auf (und erst nach Wochen, manchmal Monaten).
Sie müssen Tests und Qualitätssicherung durchführen. Es gibt kein Patentrezept, um ein fehlerfreies Produkt herzustellen oder keine Regressionen über Revisionen einzuführen.
Wie viele tausend Geräte produzieren/verkaufen Sie, bei denen die lästige Änderung des Layouts und der Software den Preisunterschied für passive Komponenten ausgleicht? Vielleicht wäre es billiger, diese Differenz für die Teile zu bezahlen, anstatt die Entwicklungszeit damit zu verbringen, die Dinge ständig neu auszurichten.
@ddewaele: Dann müssen Sie herausfinden, was die Gründe dafür sind, und sie in Ihre Tests einbeziehen.
nicht genau im Zusammenhang mit Ihrer Frage, aber ein Problem, das ich gefunden habe, war die gleichzeitige Softwareversion mit unterschiedlicher Hardware im Feld. 6 Hardwareversionen zu haben, war ein Software-Albtraum. Wir haben einen AT91 verwendet, der einen ADC-Pin hatte, den wir nicht benutzten. Wir haben den ADC an einen Widerstandsteiler angeschlossen, der sich zwischen den Revisionen änderte. Diese $0,01-Änderung hat uns viel Zeit auf der Softwareseite gespart, weil wir verschiedene Codeabschnitte haben könnten, die auf dem Lesen dieses Widerstandsteilers über den ADC basieren.
@bdegnan Guter Rat, aber beachten Sie, dass die HW-Identifikation nur ein kleiner Teil des Problems bei der Unterstützung mehrerer HW-Plattformen ist. Sie müssen immer noch jeden Fix auf allen HW-Versionen testen, und einige Fixes erfordern, dass Sie unterschiedlichen Code für unterschiedliche HW implementieren.

Antworten (1)

Die „Best Practice“ hier heißt Regressionstest . Einfach ausgedrückt, Sie möchten eine Reihe von Tests haben, die

  • decken die Kernfunktionalität aller Komponenten Ihres Systems ab
  • kann mit minimalem menschlichen Eingriff ausgeführt werden

Die zweite Anforderung ist wichtig, wenn Sie intermittierende Probleme erkennen möchten, die erst nach einiger Zeit auftreten. Wenn der Test manuell ist, können Sie ihn ein paar Mal ausführen. Wenn der Test hochgradig automatisiert ist, können Sie ihn rund um die Uhr einige Tage lang wiederholt ausführen und unregelmäßige Ereignisse erkennen, die nicht jedes Mal auftreten (z. B. Ausfälle beim Umschalten der Stromversorgung).

Es ist normalerweise auch eine gute Idee, einen Belastungstest einzubauen, der die maximale CPU-Zeit / Speicherplatz / Kommunikationsbandbreite / elektrische Leistung verwendet.

Wenn das Testen ein Problem für Ihr Team darstellt, sollten Sie schließlich ein System mit höheren Toleranzen entwerfen. Schließen Sie ein Netzteil ein, das 50-100 % zusätzliche Leistung liefern kann. Wenn Sie eine MCU haben, stellen Sie sicher, dass Ihr Stack nie zu mehr als 50 % seiner Kapazität verwendet wird und die CPU mindestens 50 % der Zeit im Leerlauf ist. Das wird das Risiko natürlich nicht eliminieren, aber deutlich reduzieren.

Thx viel für die Kommentare. Wir haben während des Testens eine Reihe von Dingen automatisiert, z. B. die Einrichtung eines Prüfstands, der das zu testende Gerät auf verschiedene Weise manipuliert (Schwankungen der Eingangsspannung, Neustarts, Erzwingen des Ruhemodus / Auslösen des Aufwachens). Aber es ist schwierig, ein Problem zu reproduzieren, das erst nach +1 Monat auftaucht. Und noch schwieriger zu beurteilen, ob die Hardware oder Software zusammenhängt. Wir haben versucht, es fehlertolerant zu machen, indem wir Power-Toggles für alle wichtigen Komponenten (gprs / gps / ...) bereitgestellt haben. Vielleicht hätten wir diesen Teil auslagern sollen und dafür mit einem Fachgeschäft zusammengearbeitet.
Auswirkungen von PCB-Revisionen auf die eingebettete Software
AntwortenHierDatenschutz-Bestimmungen1y, 0v