Revisionskontrolle für Leiterplatten: Verhindern Sie, dass Änderungen am Prototyp in die falsche Produktionscharge gelangen

Das Schwierige an einem zweiten Prototyp ist oft, genau zu wissen, was sich seit dem ersten geändert hat. Eine Fehlerbehebung, der Austausch eines Bauteils und eine Firmware-Umgehungslösung können an verschiedenen Stellen vorkommen. Ein einfacher Release-Prozess hilft dabei, diese Erkenntnisse in einen eindeutig definierten nächsten Build umzusetzen.

Verleihen Sie jedem Build eine klare Identität

Wählen Sie eine aussagekräftige Leiterplattenrevision aus und verwenden Sie diese einheitlich in den Konstruktionsunterlagen und im Namen des Freigabepakets. Trennen Sie die Hardware-Revision von der Firmware-Version und der Bestückungsvariante. Eine unbestückte Leiterplatte kann mehrere Bestückungsoptionen unterstützen, sodass eine Leiterplattenbezeichnung allein möglicherweise nicht alle darauf montierten Komponenten beschreibt.

Beobachtungen von genehmigten Änderungen trennen

Führen Sie eine Änderungsliste, in der das festgestellte Problem, die vorgeschlagene Korrektur und die als Grundlage für deren Annahme herangezogenen Belege aufgeführt sind. Der Hinweis “Problem mit dem Steckverbinder” lässt sich nur schwer umsetzen. Die Angabe “Die Ausrichtung des Steckverbinders passt nicht zur Öffnung im Gehäuse” gibt dem nächsten Prüfer hingegen einen konkreten Anhaltspunkt für die Überprüfung. Halten Sie ungelöste Fragen als solche fest, anstatt sie in einem scheinbar endgültigen Archiv zu verbergen.

Die Dateien gemeinsam veröffentlichen

Sobald die Änderungen genehmigt sind, erstellen Sie die Fertigungs- und Montageunterlagen auf Basis der vorgesehenen Revision. Bewahren Sie eine Kopie des genauen Pakets auf, das für das Angebot oder die Produktion versendet wurde. Vermeiden Sie es, den Inhalt eines Archivs mit dem Namen “final.zip” wiederholt zu ersetzen, während Sie dessen Namen unverändert lassen.

• Leiterplattenüberarbeitung und Montagevariante.
• Dateinamen für Fertigung und Montage.
• Eine kurze Liste der Änderungen gegenüber der vorherigen Version.
• Etwaige zurückbehaltene Ausnahmen oder nicht gefüllte Komponenten.
• Die zugehörigen Versionen der Firmware und der Testdokumente.

Verwenden Sie eine konkrete Änderungsnotiz

In einer Versionsnotiz könnte beispielsweise stehen: “In Revision B wurde der Steckverbinder J2 an das Gehäuse angepasst; die Baugruppenvariante bleibt unverändert; verwenden Sie die neuen Exporte für die Leiterplatte und die Bestückung gemeinsam.” Das ist hilfreicher als “die neuesten Dateien sind im Anhang”. So erfährt der Empfänger, welche früheren Informationen nicht mehr gültig sind und welche Entscheidungen weiterhin gelten.

Behandeln Sie eine Bestelländerung als separate Anfrage

Eine neue Designversion ersetzt nicht automatisch die Dateien für einen bereits in Bearbeitung befindlichen Auftrag. Wenden Sie sich unter Angabe der Auftragsnummer, der alten Revision und des vorgeschlagenen Ersatzes an DIYIPCB. Bitten Sie um Bestätigung, bevor Sie davon ausgehen, dass das neue Paket verwendet werden kann. Bewahren Sie diese Antwort zusammen mit dem Freigabeprotokoll auf.

Schließe den Kreislauf nach dem nächsten Build

Ordnen Sie die Testergebnisse der tatsächlich getesteten Revisions- und Bestückungsvariante zu. Wenn eine Platine manuell modifiziert wurde, vermerken Sie die Änderung, bevor Sie sie mit einem unveränderten Exemplar vergleichen. Dies macht die nächste Entwurfsüberprüfung produktiver und hilft dabei, zu vermeiden, dass ein Problem, das zuvor nur auf dem Prüfstand behoben wurde, erneut auftritt.

Dies ist eine Original-Anleitung zum DIYIPCB-Workflow. Die Release-Kennungen und die Beispiel-Änderungshinweise dienen lediglich der Veranschaulichung; bitte lassen Sie jede Änderung an einem aktiven Auftrag vom Support-Team bestätigen.