Benutzerdefinierte Datenquelle

Validation logic is only as reliable as the data it validates against. Custom data sources connect your authoritative external systems into Altium platform processes – so that checks run against current, live data, not a snapshot that goes stale.

Innerhalb der Behavior Extensibility sind benutzerdefinierte Datenquellen keine separate Infrastrukturkomponente – sie sind ein Muster dafür, wie Python-Prüfungen und Skripte auf externe Daten zugreifen. Eine in Python geschriebene Prüfung kann jede zugängliche API aufrufen, jede erreichbare Datenbank abfragen und das Ergebnis als Teil ihrer Validierungslogik verwenden. Das externe System bleibt die maßgebliche Quelle. Altium fragt es ab; es verwaltet keine Kopie davon.

Das macht die Aussage zur Anpassbarkeit in der Roadmap konkret: „Eine Prüfung kann auf Ihre interne Teile-Datenbank, Ihre Liste freigegebener Lieferanten, Ihr ERP-System zugreifen und ein Ergebnis zurückgeben.“ Die benutzerdefinierte Datenquelle ist der Aufruf, der genau das ermöglicht.

Warum Live-Datenzugriff wichtig ist

Eine Prüfung, die die Komponentenfreigabe anhand einer statischen Liste validiert, die in die Prüfungslogik eingebettet ist, ist beim Schreiben korrekt und innerhalb weniger Wochen falsch. Listen freigegebener Teile ändern sich. Listen eingeschränkter Materialien ändern sich. Lebenszyklusstatus ändern sich. Eine Prüfung, die Ihr Live-System abfragt, erhält bei jedem Lauf die aktuelle Antwort.

Das ist der Unterschied zwischen dem Kodieren einer Regel und dem Kodieren von Wissen. Eine statische Liste kodiert den Wissensstand zu einem bestimmten Zeitpunkt. Ein Aufruf an eine Live-Datenquelle kodiert die Regel, dass der aktuelle Zustand eines maßgeblichen Systems die Konformität bestimmt. Der zweite Ansatz altert besser.

Häufige externe Datenquellen

• Approved Vendor / Manufacturer Lists (AVL/AML) – Ihr Beschaffungs- oder Komponentenentwicklungsteam pflegt die maßgebliche Liste freigegebener Hersteller und Lieferanten. Eine Prüfung, die diese Liste live abfragt, stellt sicher, dass eine in Altium als freigegeben markierte Komponente zum Zeitpunkt der Ausführung der Prüfung tatsächlich im maßgeblichen System freigegeben war – nicht zum letzten Zeitpunkt, an dem jemand eine lokale Datei aktualisiert hat.

• Component qualification databases – Organisationen mit ausgereiften Prozessen zur Komponentenqualifizierung pflegen interne Datenbanken mit Qualifizierungsstatus, Testdaten, Anwendungseinschränkungen und freigegebenen Einsatzfällen. Wenn diese Daten in Altium-Prüfungen eingebunden werden, ist der Qualifizierungsstatus bereits in der Entwurfsphase sichtbar und wird dort durchgesetzt, statt erst bei der Freigabeprüfung entdeckt zu werden.

• ERP and inventory systems – Prüfungen, die Lieferzeiten, Lagerbestände oder Beschaffungsstatus anhand von Live-ERP-Daten validieren, ermöglichen es Ingenieuren, bereits während des Entwurfs sourcingbewusste Entscheidungen zu treffen, anstatt Versorgungsprobleme erst nach Abschluss des Designs zu entdecken.

• Compliance and restricted materials databases – ITAR-, EAR-, RoHS-, REACH- und interne IP-Kontrolllisten werden von Compliance-Teams gepflegt und ändern sich im Laufe der Zeit. Eine Prüfung, die Live-Compliance-Daten abfragt, setzt den aktuellen Richtlinienstand durch, ohne dass die Prüfung selbst jedes Mal aktualisiert werden muss, wenn sich die Richtlinie ändert.

• Internal parametric and specifications data – Konstruktionsstandards, bevorzugte Komponentenspezifikationen, interne Datenblätter und Testergebnisse, die Ihre Organisation pflegt, können in Altium-Prüfungen und Panels verfügbar gemacht werden, sodass Ingenieure am Entscheidungspunkt Zugriff auf internes Wissen haben.

Implementierungsaspekte

• Accessibility – eine Prüfung, die serverseitig auf der Plattform läuft, muss das externe System aus dem Netzwerkkontext des Servers erreichen können. Eine clientseitig in Altium Designer laufende Prüfung muss es vom Rechner des Ingenieurs aus erreichen können. Bestätigen Sie die Netzwerkzugänglichkeit, bevor Sie Prüfungen erstellen, die von externen Aufrufen abhängen.

• Latency – desktopseitige Prüfungen laufen, während der Ingenieur arbeitet. Eine Prüfung, deren Rückgabe wegen einer langsamen externen API mehrere Sekunden dauert, erzeugt Reibung, die Ingenieure umgehen werden. Halten Sie externe Aufrufe schnell, gezielt und – wo sich die Daten nicht häufig ändern – cachefähig.

• Failure handling – entwerfen Sie Prüfungen so, dass sie sicher fehlschlagen, wenn das externe System nicht verfügbar ist. Eine Prüfung, die die AVL nicht erreichen kann, sollte fail-closed arbeiten – sie sollte melden, dass sie nicht abgeschlossen werden konnte, nicht dass die Komponente freigegeben ist. Prüfungen stillschweigend erfolgreich durchlaufen zu lassen, weil die Datenquelle nicht erreichbar war, ist ein Zuverlässigkeitsfehler mit Compliance-Folgen.

• Authentication – externe API-Aufrufe aus der Prüfungslogik benötigen Anmeldedaten. Speichern Sie Anmeldedaten als Workspace-Secrets oder in der Umgebungskonfiguration, nicht hartkodiert in Prüfungsskripten. Behandeln Sie Prüfungscode wie jeden anderen Produktivcode, der mit Anmeldedaten umgeht.

Was benutzerdefinierte Datenquellen nicht sind

Benutzerdefinierte Datenquellen sind in diesem Kontext Aufrufe aus Prüfungs- und Skriptlogik – keine separate Datenintegrationsschicht und kein Synchronisierungsmechanismus. Sie ersetzen nicht die integrierten Komponentendatenquellen von Altium (Octopart, Silicon Expert, Z2 Data) für Lieferketten- und parametrische Daten von externen Anbietern. Sie sind das Muster für den Zugriff auf Ihre eigenen internen Systeme aus Ihrer eigenen benutzerdefinierten Validierungslogik.

Für Anwendungsfälle, die einen bidirektionalen Datenaustausch zwischen Altium 365 und externen Systemen auf Plattformebene erfordern – nicht nur Lesezugriffe aus der Prüfungslogik –, sind die Altium 365 API und das PLM Integration SDK die geeigneten Werkzeuge.