Привет. Это канал "Инженерная ИИ-шница".

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

Фокус канала - электроника и системно-драйверный слой ПО:

- микроконтроллеры, периферия, интерфейсы, протоколы;
- embedded Linux, device tree, драйверы, BSP, загрузчики;
- FPGA, SoC, платы, стенды, bring-up и отладка;
- тестирование, валидация, требования, методики, трассировка;
- инженерная документация, ревью, анализ логов, схем, даташитов и кода;
- применение LLM и других ИИ-инструментов в задачах, где важны точность, воспроизводимость и технический контекст.

Мне интересен не ИИ как модная надстройка, а ИИ как инженерный инструмент: где он реально ускоряет работу, где ошибается, где требует контроля, а где пока создает больше шума, чем пользы.

В канале будут разборы практических кейсов: как использовать ИИ при анализе схем, подготовке требований, написании тест-кейсов, поиске дефектов, работе с драйверами, генерации документации, прототипировании и исследовании технических решений.

Отдельная тема - качество результата. В инженерии нельзя просто получить красивый текст или правдоподобный ответ. Нужны проверяемость, источники, критерии приемки, воспроизводимые шаги и понимание границ применимости. Поэтому здесь будет много про то, как встроить ИИ в нормальный инженерный процесс, а не заменить им инженерное мышление.

Если коротко: канал о том, как применять ИИ в разработке электроники и низкоуровневого ПО от микроконтроллеров до тяжеловесных систем, сохраняя инженерную дисциплину, критичность и контроль качества.

Добро пожаловать!

Где реально применим ИИ в разработке и тестировании железа?

ИИ в тестировании железа не заменяет осциллограф, VNA, BERT, тепловую камеру или инженера. Его роль более прикладная: обработка большого объема измерений, поиск аномалий, классификация отказов, прогнозирование риска и автоматизация рутинного анализа.

Для high-speed интерфейсов это особенно актуально. PCIe, USB 3.x, DDR, Ethernet, HDMI, DisplayPort и MIPI дают большое количество данных: S-параметры, eye diagram, jitter, BER, TDR, impedance profile, логи equalization, результаты compliance-тестов, дампы ошибок драйвера и firmware.

ИИ может использоваться в нескольких задачах:

- классификация хороших и плохих каналов по S-параметрам;
- поиск резонансов и anti-resonance peaks в PDN;
- анализ eye diagram и mask violations;
- группировка fail modes по логам;
- прогноз pass/fail по ранним измерениям;
- автоматическое сравнение ревизий плат;
- генерация кратких инженерных отчетов;
- поиск причин отказа по истории тестов, errata и datasheet.

Важно: большинство open-source инструментов сами по себе не являются "AI tools". Они дают данные, расчетный backend или test framework. ИИ обычно добавляется сверху: Python, ML-модель, anomaly detection, RAG, LLM-ассистент, классификатор или оптимизатор.

И практический стек может выглядеть так...

OpenSIPI: open-source база для SI/PI automation

OpenSIPI - один из наиболее близких open-source проектов к задачам signal integrity и power integrity. Его можно рассматривать не как замену коммерческим пакетам уровня Sigrity, HyperLynx или SIwave, а как открытый инженерный слой для автоматизации SI/PI расчетов и извлечения параметров.

Где он полезен:
- работа с S-параметрами;
- извлечение DCR;
- автоматизация повторяемых расчетов;
- подготовка данных для анализа каналов;
- сравнение вариантов топологии или ревизий платы;
- построение воспроизводимого SI/PI workflow.

Где здесь появляется ИИ:
OpenSIPI может быть источником структурированных данных для ML-моделей. Например, можно собрать множество результатов по разным каналам и обучить модель определять риск еще до полной ручной проверки.

Примеры AI-сценариев:
- классификация канала как Pass / Marginal / Fail;
- поиск аномальных S-параметров;
- прогноз проблемного участка интерфейса;
- сравнение ревизий платы с автоматическим выделением деградаций;
- корреляция SI/PI признаков с реальными отказами в тестах.

Практическая ценность OpenSIPI в том, что он может стать частью воспроизводимого процесса. Для QA это особенно важно: результат должен быть не просто "инженер посмотрел график", а "метрика рассчитана, сохранена, сравнена с baseline, получен verdict".

Ограничение: сам по себе OpenSIPI не является готовой AI-системой. ИИ нужно добавлять отдельным слоем.

https://github.com/rivosinc/opensipi

PyVISA: управление приборами как входная точка для ИИ

PyVISA - Python-библиотека для управления измерительными приборами через VISA/SCPI. Она не относится напрямую к ИИ, но без такого слоя сложно построить AI-assisted hardware lab.

Через PyVISA можно управлять всем стеком КИП если у него есть внешний интерфейс управления.
Для high-speed testing это особенно полезно, потому что данные должны собираться автоматически и повторяемо.

Где появляется ИИ:
PyVISA дает ИИ доступ к измерительной инфраструктуре через контролируемый программный слой.

Примеры:
- AI выбирает следующий режим измерения;
- модель оптимизирует sweep;
- алгоритм ищет worst-case combination;
- LLM-ассистент анализирует SCPI-логи;
- anomaly detector проверяет waveform;
- система автоматически маркирует подозрительные результаты.

Практический пример: при тестировании питания модель видит резонанс в PDN impedance. Она автоматически запускает дополнительный sweep с более плотной сеткой частот вокруг подозрительной области. Инженер получает детализированный участок, а не общий график с пропущенным пиком.

Еще пример: при анализе eye diagram модель может управлять температурой, напряжением питания и режимами DUT, чтобы найти область, где margin минимален.

Ограничение: ИИ не должен напрямую управлять опасными режимами без guardrails. Для питания, температуры и предельных режимов нужны жесткие ограничения

Лауреат Нобелевской премии по физике опубликовал новую научную статью, подготовленную при участии Claude: https://arxiv.org/abs/2606.03300

По сути, ИИ помог авторам найти подтверждение исследовательской гипотезы.

В статье прямо указано:

Доказательство было получено в ходе взаимодействия с Claude Sonnet 4.6 и Claude Opus 4.7, после чего было проверено авторами.

Claude анализировал дифференциальные уравнения, написал C++ код для поиска решения, а затем сформировал отчет с логическим обоснованием корректности результата. По словам авторов, для одного из ключевых этапов исследования потребовалось около 40 промтов.

Автор, а ты сам-то чем пользуешься?

Логичный вопрос к автору канала про ИИ в инженерии. И вопрос правильный.
Если я пишу про применение ИИ в разработке электроники, embedded, системном ПО и QA, то разумно спросить: а чем я пользуюсь сам?

Мой текущий рабочий набор такой:
1. ChatGPT 5.5 Pro
Использую его как инженерного ассистента для задач, где важны структура, логика и быстрое превращение сырого материала в рабочий артефакт.

Например:
- продуктовая аналитика требований рынка к электронике;
- подготовка тестовых стратегий;
- разработка методик испытаний;
- составление тест-кейсов;
- разбор стандартов индустрии в части разработки и тестирования электроники;
- поиск слабых мест и белых пятен;
- подготовка черновиков статей и постов;
- построение таблиц, чек-листов, матриц трассировки и мое любимое - схем и диаграмм.

Это инструмент, который помогает быстрее пройти путь от неструктурированной задачи до документа, с которым уже можно работать.

2. Cursor IDE
Cursor использую там, где начинается код и проектный контекст. В основном это:
- embedded/Linux;
- C;
- Python;
- bash/shell;
- device tree;
- userspace-утилиты;
- драйверы;
- конфиги;
который можно потом обернуть в документацию рядом с кодом. В Cursor у меня доступен Claude Opus 4.8.
Для задач с кодом он часто удобен, особенно когда нужно не просто сгенерировать отдельный фрагмент, а пройтись по проекту, понять связи между файлами и предложить аккуратные изменения.

Но здесь важный момент. Я не отношусь к ИИ как к магической кнопке.
- ИИ не заменяет инженера.
- ИИ не заменяет ревью.
- ИИ не является источником истины.

Он может помочь составить методику, но инженер должен понимать, какие риски она закрывает.
Он может помочь написать код, но инженер должен проверить, что этот код реально делает на железе.
Он может быстро собрать таблицу требований, но инженер должен проверить полноту, трассировку и критерии приемки.

Далее, на этом канале я как раз и хочу разбирать не абстрактное "ИИ меняет все", а практическое применение таких инструментов в инженерной работе: от микроконтроллеров и FPGA до Linux, драйверов, QA-документации, тестирования и системной валидации.