Пользовательский источник данных

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.

В рамках Behavior Extensibility пользовательские источники данных — это не отдельный компонент инфраструктуры, а шаблон того, как проверки и скрипты на Python обращаются к внешним данным. Проверка, написанная на Python, может вызывать любой доступный API, запрашивать любую достижимую базу данных и использовать результат как часть своей логики валидации. Внешняя система остается авторитетным источником данных. Altium обращается к ней; копию данных он не хранит.

Именно это делает утверждение о Customizability в дорожной карте конкретным: «Проверка может обратиться к вашей внутренней базе данных компонентов, вашему списку одобренных поставщиков, вашей ERP-системе и вернуть результат». Пользовательский источник данных — это вызов, который делает это возможным.

Почему важен доступ к данным в реальном времени

Проверка, которая сверяет одобрение компонента со статическим списком, встроенным в логику проверки, будет корректной в момент написания и ошибочной уже через несколько недель. Списки одобренных компонентов меняются. Списки ограниченных материалов меняются. Статусы жизненного цикла меняются. Проверка, обращающаяся к вашей действующей системе, каждый раз при запуске получает актуальный ответ.

В этом и состоит разница между кодированием правила и кодированием знания. Статический список кодирует состояние знаний на определенный момент времени. Вызов к источнику данных в реальном времени кодирует правило о том, что соответствие определяется текущим состоянием авторитетной системы. Второй подход устаревает значительно медленнее.

Типовые внешние источники данных

• Approved Vendor / Manufacturer Lists (AVL/AML) — ваша команда по закупкам или инженеры по компонентам поддерживают авторитетный список одобренных производителей и поставщиков. Проверка, которая в реальном времени запрашивает этот список, гарантирует, что компонент, помеченный в Altium как одобренный, действительно был одобрен в авторитетной системе на момент запуска проверки, а не на момент последнего обновления локального файла. 

• Component qualification databases — организации со зрелыми процессами квалификации компонентов ведут внутренние базы данных со статусами квалификации, результатами испытаний, ограничениями по применению и одобренными сценариями использования. Подключение этих данных к проверкам в Altium означает, что статус квалификации виден и контролируется уже на этапе проектирования, а не обнаруживается только при проверке перед выпуском.

• ERP and inventory systems — проверки, которые сверяют сроки поставки, уровни запасов или статус закупки с актуальными данными ERP, позволяют инженерам принимать решения с учетом снабжения прямо в процессе проектирования, а не узнавать о проблемах поставок уже после завершения разработки.

• Compliance and restricted materials databases — списки ITAR, EAR, RoHS, REACH и внутренние перечни контроля интеллектуальной собственности поддерживаются командами по соответствию требованиям и со временем изменяются. Проверка, запрашивающая актуальные данные о соответствии, обеспечивает применение текущей политики без необходимости обновлять саму проверку каждый раз при изменении политики.

• Internal parametric and specifications data — инженерные стандарты, предпочтительные спецификации компонентов, внутренние даташиты и результаты испытаний, которые поддерживает ваша организация, могут быть доступны в проверках и панелях Altium, предоставляя инженерам доступ к внутренним знаниям в момент принятия решения.

Соображения по реализации

• Accessibility — проверка, выполняемая на серверной платформе, должна иметь доступ к внешней системе из сетевого контекста сервера. Проверка, выполняемая на стороне клиента в Altium Designer, должна иметь доступ к ней с машины инженера. Прежде чем создавать проверки, зависящие от внешних вызовов, убедитесь в сетевой доступности.

• Latency — проверки на стороне настольного приложения выполняются во время работы инженера. Проверка, которая из-за медленного внешнего API отвечает несколько секунд, создает неудобства, которые инженеры будут стремиться обходить. Делайте внешние вызовы быстрыми, точечными и по возможности кэшируемыми там, где данные меняются нечасто.

• Failure handling — проектируйте проверки так, чтобы они безопасно завершались при недоступности внешней системы. Проверка, не сумевшая обратиться к AVL, должна завершаться в закрытом режиме — сообщать, что не смогла завершиться, а не что компонент одобрен. Тихое прохождение проверки из-за недоступности источника данных — это отказ надежности с последствиями для соответствия требованиям.

• Authentication — внешние вызовы API из логики проверки требуют учетных данных. Храните учетные данные как секреты Workspace или в конфигурации окружения, а не вшивайте их в скрипты проверок. Относитесь к коду проверок так же, как к любому промышленному коду, работающему с учетными данными.

Чем пользовательские источники данных не являются

Пользовательские источники данных в этом контексте — это вызовы из логики проверок и скриптов, а не отдельный слой интеграции данных или механизм синхронизации. Они не заменяют встроенные источники данных компонентов Altium (Octopart, Silicon Expert, Z2 Data) для получения данных о цепочке поставок и параметрических данных от внешних поставщиков. Это шаблон доступа к вашим собственным внутренним системам из вашей собственной пользовательской логики валидации.

Для сценариев использования, где требуется двусторонний обмен данными между Altium 365 и внешними системами на уровне платформы, а не просто чтение из логики проверки, подходящими инструментами являются API Altium 365 и PLM Integration SDK.