Benutzerdefinierte Prüfungen & Validierungen

Standard design rules cover geometry and electrical correctness. Custom checks cover everything else – your company's standards, your industry's requirements, and your organization's institutional knowledge.

Altiums Behavior-Extensibility-Framework ermöglicht es Ihnen, benutzerdefinierte Validierungslogik in Python zu schreiben und sie mit Plattform-Checkpoints über den gesamten Designlebenszyklus hinweg zu verknüpfen: ERC und DRC in Altium Designer, BOM- und Komponentenvalidierung, Release-Gates, Phasen der Designprüfung und Workflow-Schritte auf dem Server. Benutzerdefinierte Prüfungen erscheinen und verhalten sich exakt wie integrierte Plattformprüfungen – gleiche UI, gleiches Fehlerfenster, gleiches Cross-Probing zur betroffenen Komponente oder zum betroffenen Netz.

Prüfungen sind nicht auf Altium-Daten beschränkt. Eine Prüfung kann auf Ihre interne Teile-Datenbank, Ihre Liste freigegebener Lieferanten, Ihr ERP-System oder jede andere externe Datenquelle zugreifen, von der Ihre Validierungspipeline abhängt. Das Ergebnis wird zurückgegeben und in Altium Designer genauso dargestellt wie ein natives Prüfergebnis.

Wofür benutzerdefinierte Prüfungen tatsächlich gedacht sind

Die meisten Unternehmen stellen fest, dass sie benutzerdefinierte Prüfungen benötigen, wenn sie auf eine Problemklasse stoßen, die trotz bestandener DRC immer wieder auftritt. Häufige Beispiele:

• Voltage derating rules – spezifisch für Ihre Produktfamilie oder Ihr Branchensegment. Kondensatoren auf Niederspannungsschienen, Elektrolytkondensatoren in der Nähe von Wärmequellen

• Component qualification gates – Bauteile von nicht freigegebenen Herstellern, ITAR-kontrollierte Komponenten, End-of-Life-Teile, die vom Einkauf markiert wurden

• BOM completeness rules – erforderliche Parameter sind nicht ausgefüllt, freigegebene Alternativen fehlen, Herstellerdaten sind unvollständig

• Release documentation requirements – bestimmte Ausgabedateien, die vorhanden und aktuell sein müssen, bevor ein Release gültig ist

• Organizational standards – Regeln, die nur als implizites Erfahrungswissen existieren und je nach prüfender Person uneinheitlich durchgesetzt werden

Benutzerdefinierte Prüfungen verlagern diese Punkte von einer Review-Aktivität – abhängig davon, dass die richtige Person verfügbar ist und daran denkt, nachzusehen – in ein automatisiertes Gate, das jedes Mal ausgeführt wird.

Der Wert, Wissen in Prüfungen zu codieren

Wenn ein erfahrener Ingenieur eine benutzerdefinierte Prüfung schreibt, passieren zwei Dinge. Die Prüfung läuft künftig automatisch für jedes Design, unabhängig davon, wer es erstellt hat. Und wenn dieser Ingenieur das Unternehmen verlässt, bleibt das Wissen erhalten. Genau diese Eigenschaft ist im großen Maßstab am wichtigsten: Institutionelles Wissen ist nicht länger vom Personalbestand abhängig.

Neue Ingenieure in Ihrem Team profitieren automatisch von Prüfungen, die von Ingenieuren mit jahrelanger Domänenerfahrung geschrieben wurden. Die Regel muss nicht erklärt oder überprüft werden – sie läuft einfach.

Was geprüft werden sollte – und was nicht

Benutzerdefinierte Prüfungen eignen sich gut für deterministische, regelbasierte Validierung: Bedingungen, die bei einem bestimmten Designzustand immer wahr oder immer falsch sind. Sie sind kein Ersatz für fachkundige Designreviews, Simulationen oder beurteilungsbasierte Bewertungen.

Ein guter Kandidat für eine benutzerdefinierte Prüfung ist jede Regel, die sich so ausdrücken lässt: „Markiere diese Komponente / dieses Netz / diesen Parameter, wenn Bedingung X zutrifft.“ Ein schlechter Kandidat ist alles, was Kontextverständnis, Interpretation der Designabsicht oder die Bewertung von Zielkonflikten erfordert. Dafür ist weiterhin menschliche Prüfung nötig. Benutzerdefinierte Prüfungen bilden die automatisierte Basislinie, die alles auffängt, was eine Maschine auffangen kann, damit die Zeit für menschliche Reviews für Dinge verwendet wird, die nur Menschen erkennen können.

Ansätze, die nicht skalieren

• Manual pre-release checklists – funktionieren für kleine Teams mit seltenen Releases. Sie brechen zusammen, wenn das Team wächst, die Release-Frequenz steigt oder die Person, die die Checkliste pflegt, nicht verfügbar ist. Checklisten sind für Ingenieure während des Designs außerdem unsichtbar – das Feedback kommt zu spät, um günstig korrigiert werden zu können.

• Review-only enforcement – sich darauf zu verlassen, dass Design-Reviewer Standardverstöße erkennen, bedeutet, dass dieselben Fehler wiederholt von denselben Personen gefunden werden. Das bindet Expertenzeit für deterministische Probleme, lässt frühe Designphasen ungeschützt und führt zu uneinheitlicher Durchsetzung zwischen verschiedenen Reviewern.