Source de données personnalisée

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.

Dans le cadre de Behavior Extensibility, les sources de données personnalisées ne constituent pas un composant d’infrastructure distinct : il s’agit d’un modèle de fonctionnement permettant aux vérifications et scripts Python d’accéder à des données externes. Une vérification écrite en Python peut appeler n’importe quelle API accessible, interroger n’importe quelle base de données joignable et utiliser le résultat dans sa logique de validation. Le système externe reste la source faisant autorité. Altium l’interroge ; il n’en maintient pas de copie.

C’est ce qui concrétise l’affirmation de personnalisation dans la feuille de route : « Une vérification peut interroger votre base de données interne de composants, votre liste de fournisseurs approuvés, votre système ERP, et renvoyer un résultat. » La source de données personnalisée est l’appel qui permet cela.

Pourquoi l’accès aux données en direct est important

Une vérification qui valide l’approbation d’un composant par rapport à une liste statique intégrée à la logique de contrôle sera correcte au moment de sa rédaction, puis erronée quelques semaines plus tard. Les listes de pièces approuvées changent. Les listes de matériaux restreints changent. Les statuts de cycle de vie changent. Une vérification qui appelle votre système en direct obtient la réponse à jour à chaque exécution.

C’est la différence entre encoder une règle et encoder une connaissance. Une liste statique encode l’état de la connaissance à un moment donné. Un appel à une source de données en direct encode la règle selon laquelle l’état actuel d’un système faisant autorité détermine la conformité. La seconde approche vieillit mieux.

Sources de données externes courantes

• Approved Vendor / Manufacturer Lists (AVL/AML) – votre équipe achats ou d’ingénierie des composants tient à jour la liste de référence des fabricants et fournisseurs approuvés. Une vérification qui interroge cette liste en direct garantit qu’un composant signalé comme approuvé dans Altium l’était effectivement dans le système de référence au moment exact de l’exécution du contrôle – et non à la dernière mise à jour d’un fichier local.

• Component qualification databases – les organisations disposant de processus matures de qualification des composants maintiennent des bases de données internes sur le statut de qualification, les données de test, les restrictions d’application et les cas d’usage approuvés. Connecter ces données aux vérifications Altium permet de rendre visible et d’appliquer le statut de qualification dès la phase de conception, au lieu de le découvrir lors de la revue de mise en production.

• ERP and inventory systems – les vérifications qui valident les délais d’approvisionnement, les niveaux de stock ou le statut d’achat à partir de données ERP en direct permettent aux ingénieurs de prendre des décisions tenant compte de l’approvisionnement pendant la conception, plutôt que de découvrir les problèmes de supply chain une fois la conception terminée.

• Compliance and restricted materials databases – les listes ITAR, EAR, RoHS, REACH et les listes internes de contrôle de la propriété intellectuelle sont maintenues par les équipes conformité et évoluent dans le temps. Une vérification qui interroge des données de conformité en direct applique l’état actuel de la politique sans nécessiter de mise à jour de la vérification elle-même à chaque changement de politique.

• Internal parametric and specifications data – les normes d’ingénierie, les spécifications de composants préférés, les fiches techniques internes et les résultats d’essais maintenus par votre organisation peuvent être exposés dans les vérifications et panneaux Altium, donnant ainsi aux ingénieurs accès aux connaissances internes au moment de la prise de décision.

Considérations de mise en œuvre

• Accessibility – une vérification exécutée côté serveur doit pouvoir atteindre le système externe depuis le contexte réseau du serveur. Une vérification exécutée côté client dans Altium Designer doit pouvoir l’atteindre depuis la machine de l’ingénieur. Confirmez l’accessibilité réseau avant de développer des vérifications dépendant d’appels externes.

• Latency – les vérifications côté bureau s’exécutent pendant que l’ingénieur travaille. Une vérification qui met plusieurs secondes à répondre à cause d’une API externe lente crée une friction que les ingénieurs chercheront à contourner. Gardez les appels externes rapides, ciblés et, lorsque les données changent peu souvent, compatibles avec la mise en cache.

• Failure handling – concevez les vérifications pour qu’elles échouent de manière sûre lorsque le système externe n’est pas disponible. Une vérification qui ne peut pas joindre l’AVL doit échouer en mode fermé – elle doit signaler qu’elle n’a pas pu s’exécuter correctement, et non que le composant est approuvé. Laisser silencieusement passer des vérifications parce que la source de données est inaccessible constitue une défaillance de fiabilité avec des conséquences en matière de conformité.

• Authentication – les appels à des API externes depuis la logique de vérification nécessitent des identifiants. Stockez-les en tant que secrets Workspace ou dans la configuration de l’environnement, et non en dur dans les scripts de vérification. Traitez le code de vérification comme tout autre code de production manipulant des identifiants.

Ce que ne sont pas les sources de données personnalisées

Dans ce contexte, les sources de données personnalisées sont des appels effectués depuis la logique des vérifications et des scripts – et non une couche d’intégration de données distincte ou un mécanisme de synchronisation. Elles ne remplacent pas les sources de données intégrées d’Altium pour les composants (Octopart, Silicon Expert, Z2 Data) concernant les données de supply chain et les données paramétriques provenant de fournisseurs externes. Elles constituent le modèle d’accès à vos propres systèmes internes à partir de votre propre logique de validation personnalisée.

Pour les cas d’usage nécessitant un échange de données bidirectionnel entre Altium 365 et des systèmes externes au niveau de la plateforme – et pas seulement des lectures depuis la logique de vérification – l’API Altium 365 et le SDK d’intégration PLM sont les outils appropriés.