Тепличный комплекс «Иванисово» внедрил систему цифровой аналитики операций на базе видеонаблюдения Trassir и алгоритмов компьютерного зрения Matller. Результат — плюс 20% к производительности фасовки без расширения мощностей и закупки нового оборудования. Звучит как новость из отраслевой ленты, но для выпускника ИТ-направления это готовый полигон для диплома: потоковая обработка видео, инференс модели на периферии, интеграция с уже работающей инфраструктурой и — главное — измеримый результат, который можно защищать цифрами, а не общими словами. Ниже разберём, как вытащить из этого кейса тему ВКР, чем наполнить три главы и какие метрики приложить, чтобы комиссия не спрашивала «а где практическая значимость».
Актуальность: в кейсе «Иванисово» аналитика работает рядом с камерой, а не в дата-центре — иначе задержка и канал связи убивают смысл решения. Это ровно тот тренд, который стоит обосновать во введении.
Цель: разработать архитектуру распределённой системы видеоаналитики для производственной линии.
Задачи: проанализировать существующие платформы (Trassir, Ivideon, открытые стеки); обосновать выбор edge-платформы; спроектировать конвейер «камера → инференс → событие → хранилище»; оценить задержку и пропускную способность.
Структура: Глава 1 — обзор рынка и постановка задачи; Глава 2 — архитектура, диаграммы развёртывания и последовательностей; Глава 3 — нагрузочное тестирование и расчёт эффекта.
Актуальность: ключевая ценность кейса не в детекции объектов как таковой, а в превращении видеоданных в управленческие показатели — темп фасовки, простои, брак.
Цель: построить модуль, который считает метрики линии в реальном времени и отдаёт их в BI-панель.
Задачи: формализовать KPI (OEE, темп, доля брака); спроектировать схему событий; реализовать агрегацию временных рядов; валидировать расчёты против ручного хронометража.
Структура: Глава 1 — теория KPI и обзор подходов; Глава 2 — проектирование хранилища и API; Глава 3 — сверка с эталоном и оценка точности.
Актуальность: на предприятиях уже стоят камеры и регистраторы — новая система должна встроиться, а не заменить всё. Именно так и поступили в «Иванисово»: использовали существующий контур Trassir.
Цель: разработать интеграционный слой между подсистемой видеонаблюдения и сервисом аналитики.
Задачи: выбрать протокол обмена (RTSP/ONVIF для видео, MQTT или Kafka для событий); спроектировать идемпотентную обработку; обеспечить устойчивость к обрывам потока; описать развёртывание в Kubernetes.
Структура: Глава 1 — сравнение протоколов и стандартов; Глава 2 — схемы интеграции и контракты API; Глава 3 — тесты отказоустойчивости и деградации.
Первая глава у многих превращается в реферат. Чтобы этого не случилось, привяжите обзор к конкретному решению из статьи и постройте сравнительную таблицу. Критерии берите не «нравится / не нравится», а измеряемые и привязанные к ISO/IEC 25010: производительность, надёжность, сопровождаемость, переносимость.
| Критерий | Готовая платформа (Trassir + Matller) | Собственный стек (OpenCV + YOLO + Python) | Облачный сервис видеоаналитики |
|---|---|---|---|
| Срок внедрения | Недели | Месяцы | Дни, но зависит от канала |
| Задержка инференса | Низкая (edge) | Зависит от железа | Высокая (сеть + очередь) |
| Гибкость сценариев | Средняя, в рамках вендора | Максимальная | Низкая |
| Стоимость владения | Лицензии + сопровождение | Разработка + поддержка | Подписка по потокам |
| Соответствие требованиям ИБ | Видео не покидает контур | Полный контроль | Требует обоснования |
Отдельно стоит разобрать, почему на производстве не выбрали «чистый» облачный вариант: видеопоток с десятка камер — это десятки мегабит в секунду постоянно, а простой линии стоит дороже, чем сэкономленные на железе деньги.
Вторая глава — это место для схем. Минимум, который ждёт комиссия: контекстная диаграмма (по ГОСТ 34.602-89), диаграмма развёртывания, схема алгоритма обработки кадра (ГОСТ 19.701-90 допускает привычные блок-схемы) и спецификация API. Ниже — упрощённый каркас конвейера, который можно взять за основу описания.
Камера (RTSP/ONVIF)
→ буфер кадров (ring buffer, drop policy при переполнении)
→ препроцессинг (resize, нормализация)
→ инференс модели (ONNX Runtime / TensorRT на edge-узле)
→ трекинг объектов (сопоставление по IoU + идентификатор)
→ бизнес-правило (событие «упаковка прошла» / «линия встала»)
→ публикация события (MQTT/Kafka)
→ хранилище (TimescaleDB / ClickHouse) → BI-панель
Обратите внимание на два узла, которые чаще всего забывают в дипломах. Первый — политика сброса кадров: при перегрузке лучше потерять кадр, чем накопить очередь и получить задержку в минуты. Второй — идемпотентность обработки событий: если брокер доставит сообщение дважды, KPI не должен удвоиться. Обе темы дают отличный материал для обоснований во второй главе.
Если нужен код, ограничьтесь ключевым фрагментом, а не всем проектом — обычно комиссии достаточно чтения захвата потока и экспорта метрик:
from prometheus_client import Counter, Histogram
import cv2, time
frames = Counter("pipeline_frames_total", "Обработано кадров")
infer = Histogram("pipeline_infer_seconds", "Время инференса")
cap = cv2.VideoCapture("rtsp://camera-01/stream", cv2.CAP_FFMPEG)
while cap.isOpened():
ok, frame = cap.read()
if not ok:
time.sleep(0.5) # не крутимся в busy-loop при обрыве
continue
frames.inc()
with infer.time():
result = model.predict(frame)
Третья глава — самая «защищаемая» и одновременно самая слабая у студентов. Здесь недостаточно фразы «система работает стабильно». Нужны метрики, метод их замера и условия эксперимента. Хорошая новость: реальное производство не обязательно. Достаточно стенда с записанными видеопотоками и явно заданных допущений.
| Группа метрик | Что замеряем | Как получить | Норма-ориентир |
|---|---|---|---|
| Производительность CV | FPS, задержка кадр→событие, mAP | Прогон на размеченном датасете, замер времени инференса | ≥ 15 FPS на поток, задержка < 1 с |
| Надёжность | Доля потерянных событий, RTO, RPO | Обрыв потока, падение узла, рестарт сервиса | Потери < 0,5%, RTO < 30 с |
| Точность бизнес-логики | Расхождение с ручным хронометражем | Сверка за смену: система vs человек | Расхождение < 5% |
| Наблюдаемость | Полнота трассировок и метрик | OpenTelemetry + Prometheus + Grafana | Покрытие ключевых сервисов 100% |
Расхождение с ручным хронометражем — самый убедительный аргумент. Если вы покажете, что система насчитала 9 800 упаковок за смену, а оператор вручную — 9 650, и объясните разницу погрешностью трекинга на перекрытиях, вопрос о достоверности снимается.
Типичные ошибки студентов
Не обязательно в промышленном объёме, но прототип сильно повышает вес работы. Минимальный вариант: скрипт захвата потока, инференс готовой модели и выгрузка событий в таблицу. Этого хватает, чтобы защитить архитектурные решения практикой.
Нет. Возьмите предобученную модель детекции, дообучите на нескольких сотнях размеченных кадров вашего сценария и честно опишите метрики. Комиссия ценит обоснованный выбор и оценку качества, а не архитектуру «с нуля».
Подойдут открытые датасеты похожих сцен, съёмка на телефон с имитацией конвейера, синтетические последовательности. Главное — зафиксировать допущения и указать, чем искусственный стенд отличается от реальной линии.
Контекстную и функциональную схемы — по нотациям, близким к ГОСТ 34.602-89. Алгоритмы — по ГОСТ 19.701-90. UML (развёртывание, последовательности) допустим, если научрук не требует строго ЕСПД, но подпишите каждую диаграмму и сошлитесь на неё в тексте.
Если тема нравится, но не хватает времени на реализацию прототипа, расчёты или оформление — наша команда помогает студентам с 2010 года. Можем взять на себя разработку темы, подготовку расчётной части или привести работу к требованиям кафедры. Первая консультация — бесплатно, 120 часов — стандартный срок сопровождения до защиты.
Источник: Trassir и Matller помогли тепличному комплексу «Иванисово» увеличить производительность фасовки на 20% (опубликовано 2026-03-26)
```