Ускорение и автоматизация разработки устаревшей прошивки контроллера чистых помещений фармацевтического производства

Описанный опыт вырос из реальной задачи: объединить две кодовые базы контроллеров, которые управляют вентиляцией, давлением, шлюзами и Modbus-интеграцией (промышленный протокол связи между устройствами) на серийных устройствах для чистых помещений. Прикладная логика была перемешана с обработчиками прерываний, регистрами STM32 (семейство микроконтроллеров), GPIO (порты ввода-вывода), таймерами и I2C (шина связи между микросхемами внутри платы). Код не был покрыт тестами, сборка зависела от Windows и устаревшей IDE Coocox. Процесса работы с git (система контроля версий, позволяющая отслеживать изменения в коде) не существовало.

Что понадобится?

• Segger Embedded Studio или аналогичная кроссплатформенная IDE для STM32, заменяющая устаревшую Coocox
• Git-репозиторий и навык работы с ветками
• ИИ-агент с поддержкой работы в кодовой базе (например, Claude Code, Cursor или аналоги, способные читать и редактировать firmware-проект)
• Стенд с контроллером и Wiren Board (или другой промышленный контроллер для автоматизации тестов по Modbus)
• Метрологический стенд для нагрузочного тестирования
• Канбан-доска для отслеживания задач
• Примерное время: три итерации по одной неделе каждая

Пошаговая инструкция: три итерации за три недели

1. Перенесите проект на актуальную IDE и заведите git

Первый шаг: избавиться от привязки к Windows и устаревшему Coocox. Проект переносится на Segger Embedded Studio. Одновременно создаётся git-репозиторий, формализуется работа в ветках. Без этого любой рефакторинг опасен: нет возможности откатиться.

2. Покройте существующий код тестами без его изменения

Главная цель первого этапа: зафиксировать текущее поведение прошивки. Не рефакторинг, а «фотография» логики, чтобы потом любое изменение можно было проверить автоматически.

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

• юнит-тесты для изолируемых модулей бизнес-логики
• интеграционные тесты для связок модулей
• полуавтоматические тесты через веб-интерфейс на физическом стенде

# Пример: запуск тестов на стенде через Wiren Board
# (адаптируйте под свой стенд и протокол)
python3 run_modbus_tests.py --port /dev/ttyUSB0 --baudrate 9600 --report html

3. Подключите ИИ-агента для покрытия тестами

На первом этапе агент не меняет исходный код, а только пишет тесты. Это снижает риск: агент читает «спагетти», генерирует тесты, инженер проверяет их корректность.

# Пример промпта для агента (адаптируйте под свой инструмент)
"Прочитай модуль pid_controller.c. Не меняй код. 
Напиши юнит-тесты, которые фиксируют текущее поведение 
функций pid_init(), pid_update(), pid_reset(). 
Используй фреймворк Unity. Мокай HAL-вызовы."

4. Напишите ADR перед каждым изменением

ADR (Architecture Decision Record, запись архитектурного решения) фиксирует, что именно меняется, почему и какие альтернативы рассматривались. Агент помогает составлять ADR: инженер ставит задачу, агент генерирует черновик, инженер корректирует. Это не бюрократия: ADR становится контекстом для самого агента при следующих задачах.

5. Объедините две кодовые базы (вторая итерация)

Агент переносит код из второй прошивки с сохранением логики. Параллельно запускается стенд на Wiren Board для прогона тестов после каждого слияния. Ручное тестирование проводится по чек-листу, который был написан по итогам первого релиза.

6. Добавляйте новый функционал через агента (третья итерация)

С третьей недели агент уже пишет новый код. Процесс работы с ним выглядит так:

• инженер формулирует задачу и пишет ADR совместно с агентом
• агент разрабатывает код и тесты в отдельной ветке
• инженер проводит код-ревью
• автоматические и полуавтоматические тесты на стенде
• агент готовит пул-реквест и документацию
• инженер делает релиз

7. Запустите метрологический стенд и нагрузочное тестирование

На третьей итерации добавляется нагрузочное тестирование хотя бы одного критического сценария: например, реакция PID-регулятора (алгоритм автоматической подстройки, который удерживает нужный параметр, скажем давление, корректируя вентилятор) на рост сопротивления фильтра.

Итоговый цикл разработки

После трёх недель SDLC (Software Development Life Cycle, полный цикл разработки ПО) выглядит так:

1. Постановка задачи (бизнес, инженер)
2. Написание ADR (инженер совместно с агентом)
3. Создание отдельной ветки (инженер)
4. Разработка и покрытие тестами (агент)
5. Отладка производительности и ошибок на железе (агент и инженер совместно)
6. Код-ревью (инженер)
7. Предрелизное и регрессионное тестирование (автоматические, ручные и полуавтоматические тесты)
8. Подготовка пул-реквеста и документации (агент)
9. Релиз (инженер)

Что это даёт вам по ролям?

Инженеру-прошивочнику в РФ и СНГ. Если вы работаете с контроллерами STM32 на устаревших IDE, переход на Segger и git занимает один день, а не месяц. Агент берёт на себя рутину покрытия тестами: вы ревьюите, а не пишете 14 однотипных тест-кейсов вручную. Modbus-интеграция и I2C-отладка остаются вашей зоной, но агент ускоряет локализацию ошибок по логам.

Руководителю производства или техдиректору. Три недели от «спагетти без тестов» до работающего SDLC с регрессионным тестированием. Это означает, что новый функционал (например, логика УФ-обеззараживания или новый режим шлюзования) добавляется с контролируемым риском, а не методом «залить и молиться».

Автору Дзена, пишущему про промышленный ИИ. Это конкретный кейс для контента: ИИ-агент не заменяет инженера, а встраивается в цикл как младший разработчик с ограничениями. Такие примеры работают лучше абстрактных обещаний.

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