Niestandardowe źródło danych

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.

W ramach Behavior Extensibility niestandardowe źródła danych nie są odrębnym komponentem infrastruktury — są wzorcem określającym, w jaki sposób kontrole i skrypty Python uzyskują dostęp do danych zewnętrznych. Kontrola napisana w Pythonie może wywołać dowolne dostępne API, wykonać zapytanie do dowolnej osiągalnej bazy danych i użyć wyniku jako części swojej logiki walidacji. System zewnętrzny pozostaje źródłem prawdy. Altium wykonuje do niego zapytania; nie utrzymuje jego kopii.

To właśnie konkretyzuje deklarację Customizability w roadmapie: „Kontrola może odwołać się do Twojej wewnętrznej bazy danych części, listy zatwierdzonych dostawców, systemu ERP i zwrócić wynik”. Niestandardowe źródło danych to wywołanie, które to umożliwia.

Dlaczego dostęp do danych na żywo ma znaczenie

Kontrola, która weryfikuje zatwierdzenie komponentu na podstawie statycznej listy osadzonej w logice kontroli, będzie poprawna w chwili napisania i błędna już po kilku tygodniach. Listy zatwierdzonych części się zmieniają. Listy materiałów objętych ograniczeniami się zmieniają. Statusy cyklu życia się zmieniają. Kontrola, która odwołuje się do systemu działającego na żywo, za każdym uruchomieniem otrzymuje aktualną odpowiedź.

To jest różnica między zakodowaniem reguły a zakodowaniem wiedzy. Statyczna lista koduje stan wiedzy w danym momencie. Wywołanie źródła danych na żywo koduje regułę, zgodnie z którą bieżący stan autorytatywnego systemu określa zgodność. Drugie podejście starzeje się lepiej.

Typowe zewnętrzne źródła danych

• Approved Vendor / Manufacturer Lists (AVL/AML) — zespół zakupów lub inżynierii komponentów utrzymuje autorytatywną listę zatwierdzonych producentów i dostawców. Kontrola, która wykonuje zapytanie do tej listy na żywo, zapewnia, że komponent oznaczony w Altium jako zatwierdzony rzeczywiście był zatwierdzony w systemie autorytatywnym w momencie uruchomienia kontroli — a nie w chwili, gdy ktoś ostatnio zaktualizował lokalny plik.

• Component qualification databases — organizacje z dojrzałymi procesami kwalifikacji komponentów utrzymują wewnętrzne bazy danych statusów kwalifikacji, danych testowych, ograniczeń zastosowań i zatwierdzonych przypadków użycia. Podłączenie tych danych do kontroli w Altium sprawia, że status kwalifikacji jest widoczny i egzekwowany już na etapie projektowania, a nie odkrywany dopiero podczas przeglądu przed wydaniem.

• ERP and inventory systems — kontrole weryfikujące terminy dostaw, poziomy zapasów lub status zakupowy względem danych ERP na żywo pozwalają inżynierom podejmować decyzje uwzględniające sourcing już podczas projektowania, zamiast odkrywać problemy z dostępnością dopiero po zakończeniu projektu.

• Compliance and restricted materials databases — listy ITAR, EAR, RoHS, REACH oraz wewnętrzne listy kontroli własności intelektualnej są utrzymywane przez zespoły ds. zgodności i zmieniają się w czasie. Kontrola, która wykonuje zapytania do bieżących danych zgodności, egzekwuje aktualny stan polityki bez konieczności aktualizowania samej kontroli przy każdej zmianie polityki.

• Internal parametric and specifications data — standardy inżynierskie, preferowane specyfikacje komponentów, wewnętrzne datasheety i wyniki testów utrzymywane przez organizację mogą być prezentowane w kontrolach i panelach Altium, dając inżynierom dostęp do wewnętrznej wiedzy w punkcie podejmowania decyzji.

Aspekty implementacyjne

• Accessibility — kontrola działająca po stronie serwera musi mieć możliwość dotarcia do systemu zewnętrznego z kontekstu sieciowego serwera. Kontrola działająca po stronie klienta w Altium Designer musi mieć możliwość dotarcia do niego z komputera inżyniera. Przed tworzeniem kontroli zależnych od wywołań zewnętrznych potwierdź dostępność sieciową.

• Latency — kontrole po stronie desktopa działają podczas pracy inżyniera. Kontrola, której odpowiedź zajmuje kilka sekund z powodu wolnego zewnętrznego API, powoduje tarcie, które inżynierowie będą omijać. Utrzymuj wywołania zewnętrzne jako szybkie, ukierunkowane i — tam, gdzie dane nie zmieniają się często — możliwe do buforowania.

• Failure handling — projektuj kontrole tak, aby bezpiecznie kończyły się niepowodzeniem, gdy system zewnętrzny jest niedostępny. Kontrola, która nie może połączyć się z AVL, powinna fail closed — zgłosić, że nie mogła zostać ukończona, a nie że komponent jest zatwierdzony. Ciche zaliczanie kontroli dlatego, że źródło danych było nieosiągalne, jest awarią niezawodności z konsekwencjami dla zgodności.

• Authentication — zewnętrzne wywołania API z logiki kontroli wymagają poświadczeń. Przechowuj poświadczenia jako sekrety Workspace lub konfigurację środowiskową, a nie na stałe zakodowane w skryptach kontroli. Traktuj kod kontroli tak, jak każdy kod produkcyjny obsługujący poświadczenia.

Czym niestandardowe źródła danych nie są

Niestandardowe źródła danych w tym kontekście to wywołania z logiki kontroli i skryptów — a nie osobna warstwa integracji danych ani mechanizm synchronizacji. Nie zastępują one wbudowanych źródeł danych komponentów w Altium (Octopart, SiliconExpert, Z2Data) dla danych łańcucha dostaw i danych parametrycznych od zewnętrznych dostawców. Są wzorcem dostępu do własnych systemów wewnętrznych z poziomu własnej niestandardowej logiki walidacji.

W przypadkach użycia wymagających dwukierunkowej wymiany danych między Altium 365 a systemami zewnętrznymi na poziomie platformy — a nie tylko odczytów z logiki kontroli — odpowiednimi narzędziami są interfejs API Altium 365 oraz PLM Integration SDK.