Опубликовано: 20.10.2026 | Источник: SecurityLab (RSS)

Декарбонизация кирпичного производства в ВКР: цифровой двойник печи обжига и метрики выбросов

30 марта 2026 года вышла заметка о том, что декарбонизация добралась до кирпича. Кирпич — самый древний стройматериал, а его обжиг остаётся одной из самых грязных технологий: печь работает круглосуточно, топливо сгорает неидеально, а выбросы CO₂ на тонну продукции почти не измеряются в реальном времени. Появился выход, и, судя по формулировкам, он технологический. Для выпускников ИТ-направлений это важный сигнал: отрасль, которую двадцать лет не трогали цифрой, начинает считать углерод и оптимизировать режимы. Значит, появляются задачи на телеметрию, хранение временных рядов, прогнозные модели и отчётность по стандартам. И каждая из них отлично защищается как ВКР — с измеримым результатом, а не с рассуждениями «о важности экологии».

Четыре темы ВКР, которые вырастают прямо из этой новости

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

Тема 1. Система мониторинга углеродного следа кирпичного завода на базе IoT-телеметрии

• Актуальность: обжиг остаётся грязной технологией, а значит, нужен объективный замер, а не экспертные оценки раз в квартал.
• Цель: разработать систему, которая собирает параметры печи и считает выбросы CO₂ на тонну продукции с погрешностью не выше 5%.
• Задачи: анализ источников данных и протоколов (MQTT, OPC UA); проектирование схемы БД временных рядов; реализация расчётного модуля по ISO 14064-1; нагрузочное тестирование и оценка RTO/RPO.
• Структура: гл. 1 — обзор методов учёта выбросов и стандартов; гл. 2 — архитектура сбора и хранения телеметрии, ER-модель, API; гл. 3 — тестирование, метрики качества по ISO/IEC 25010, расчёт экономии.

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

• Актуальность: снижать выбросы дешевле через режим, чем через замену топлива — но режим нужно предсказывать заранее.
• Цель: построить модель прогноза удельного расхода топлива и CO₂ на 30–60 минут вперёд по текущим показаниям датчиков.
• Задачи: сформировать признаковое пространство (температура по зонам, расход газа, влажность сырца); обучить baseline и основную модель; сравнить по MAE/MAPE; встроить модель в сервис инференса.
• Структура: гл. 1 — физика обжига и обзор ML-подходов; гл. 2 — подготовка данных, генератор синтетики, архитектура сервиса; гл. 3 — эксперименты, метрики, оценка эффекта внедрения.

Тема 3. Модуль ESG-отчётности: расчёт углеродного следа продукции и формирование отчёта

• Актуальность: декарбонизация без отчётности не считается состоявшейся — предприятию нужен документ, а не дашборд для инженера.
• Цель: автоматизировать расчёт и выгрузку отчёта по Scope 1–2 в формате, пригодном для внешнего аудита.
• Задачи: описать методику расчёта и границы охвата; спроектировать модель коэффициентов эмиссии и версионирование; реализовать экспорт и трассируемость расчётов; проверить воспроизводимость.
• Структура: гл. 1 — стандарты ISO 14064-1 и практика отчётности; гл. 2 — проектирование модуля, интеграция с системой мониторинга; гл. 3 — тест-кейсы, валидация на исторических данных, экономика.

Тема 4. Обоснование выбора хранилища телеметрии: сравнительный анализ TimescaleDB, InfluxDB и ClickHouse

• Актуальность: поток данных с печи — десятки тысяч точек в сутки, и «просто PostgreSQL» перестаёт держать агрегации.
• Цель: дать воспроизводимую методику выбора СУБД для временных рядов под конкретный профиль нагрузки.
• Задачи: сформировать критерии и веса; собрать стенд и синтетический набор; прогнать одинаковые запросы; оформить матрицу решений.
• Структура: гл. 1 — теория временных рядов и обзор решений; гл. 2 — методика и стенд, развёрнутый в Docker/Kubernetes; гл. 3 — результаты замеров, расчёт стоимости владения.

Аналитическая глава: где статья превращается в обоснование выбора

Первая глава чаще всего проваливается в пересказ учебника. Здесь она может стать самой сильной частью работы, если построить её вокруг решения, а не вокруг терминов. Логика такая: в статье зафиксирован факт — обжиг кирпича остаётся грязной технологией, и появился технологический выход. Дальше вы показываете, что именно нужно измерить и какими инструментами это делают в смежных отраслях (цемент, стекло, металлургия — там мониторинг зрелее).

Полезно свести сравнение в таблицу и защитить веса критериев. Формулировки вроде «TimescaleDB быстрее» на защите разваливаются первым же вопросом «на каком профиле нагрузки?».

Рядом уместна вторая таблица — сравнение протоколов съёма данных с печи: MQTT (лёгкий, QoS 1, ретеншн), OPC UA (промышленный стандарт, но тяжёлый), HTTP REST (просто, но дорого по накладным расходам на каждом опросе). Тут же — ссылка на статью как на причину: пока выбросы не считались, потребности в плотной телеметрии не было.

Проектная часть: архитектура, схемы и то, что видно на защите

Проектную главу удобно рисовать по C4: контекст (печь → шлюз → платформа → аналитик и эколог), контейнеры (брокер MQTT, сервис ingest, БД временных рядов, сервис расчёта, дашборд), компоненты. Плюс ER-модель и sequence-диаграмма на один сценарий — «пришла порция телеметрии, пересчитался удельный выброс, ушло уведомление при превышении». Одной честной диаграммы с подписями достаточно; пять красивых и несогласованных между собой — худший вариант.

Хорошо работает единый набор сущностей. Например, kiln, sensor, measurement, batch, emission_factor, report. Тогда расчёт углеродного следа становится соединением партии сырца с интегралом расхода топлива за интервал обжига — это можно показать запросом, а не словами.

-- удельный выброс CO2 по партии обжига (PostgreSQL / TimescaleDB)
SELECT b.id AS batch_id,
       sum(m.value * ef.factor_kg_per_unit) / b.weight_t AS co2_per_ton
FROM measurement m
JOIN sensor s         ON s.id = m.sensor_id
JOIN emission_factor ef ON ef.fuel_type = s.fuel_type
JOIN batch b          ON m.ts BETWEEN b.started_at AND b.finished_at
WHERE m.ts > now() - interval '7 days'
GROUP BY b.id, b.weight_t
ORDER BY co2_per_ton DESC;

Интеграция — тоже баллы. Опишите контракт: формат сообщения, QoS, ретраи, идемпотентность при повторной доставке. Если добавляете инференс модели, покажите, как сервис читает последние 30 минут окон и не блокирует ingest. Здесь же уместно упомянуть Kubernetes для развёртывания и CI/CD-пайплайн с прогоном тестов — в тексте на одну страницу, а не отдельной главой.

Тестирование, метрики и мониторинг: без цифр работа не защищается

Третья глава должна отвечать на вопрос «а как вы поняли, что стало лучше?». Ниже — набор, который закрывает почти любую комиссию.

Отдельно проговорите атрибуты качества по ISO/IEC 25010: производительность, надёжность, сопровождаемость. Не нужно оценивать все восемь — выберите три и обоснуйте, почему для системы мониторинга печи важны именно они. Для расчётной части сошлитесь на методику из ISO 14064-1 и объясните, что вы измеряете: Scope 1 — прямое сжигание топлива, Scope 2 — покупная энергия.

Чему вы научитесь на такой теме

• Проектировать поток данных от «железа» до отчёта и не терять сообщения по дороге.
• Обосновывать стек матрицей критериев, а не фразой «широко используется».
• Строить хранилище временных рядов и писать агрегирующие запросы под реальный профиль нагрузки.
• Оценивать модель не «на глаз», а по MAE/MAPE на отложенной выборке.
• Готовить документацию, которая проходит нормоконтроль: ТЗ по ГОСТ 34.602-89, схемы, глоссарий терминов и сокращений.
• Отстаивать экономический эффект — снижение удельного расхода топлива в процентах и в рублях на тонну.

Вопросы, которые задают на консультациях

Обязательно ли писать работающий код?

По требованиям большинства вузов — нет, достаточно проекта и обоснований. Но прототип, который поднимается по README, снимает половину вопросов на защите и даёт материал для третьей главы. Минимально жизнеспособный вариант: ingest через MQTT, запись в базу, один дашборд и один расчётный запрос.

Где брать данные, если доступа к заводу нет?

Три законных пути: открытые датасеты по энергопотреблению и техпроцессам, паспортные характеристики оборудования из документации производителей, генератор синтетики по описанной физике процесса. В работе прямо укажите, что данные синтетические, приведите параметры генератора и проверьте модель на устойчивость. Это честнее, чем «данные получены на предприятии» без справки.

Как обосновать выбор СУБД, чтобы не выглядело вкусовщиной?

Через критерии с весами и одинаковый стенд. Разверните оба варианта в контейнерах, загрузите один и тот же набор, прогоните одинаковые запросы, зафиксируйте время и потребление памяти. Результат — матрица решений и вывод. Такой раздел по сути отвечает и на вопрос «как написать ВКР, чтобы её приняли без споров»: спор заменяется замером.

Что считать практической значимостью, если внедрения не было?

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

Источник: Декарбонизация добралась до кирпича. Кирпич держался дольше многих (опубликовано 2026-03-30)