← К демонстрации# MineOps AI v1.0 — техническое задание
Версия 1.0 · 03.11.2026 · Industrial AI Lab Kazakhstan
## 1. Назначение и границы
Анализ сменных выгрузок обогатительной фабрики для начальника производства, аналитика и инженера надёжности. Вход — три CSV, выход — проверенные KPI, ранжированные отклонения, факты с идентификаторами и вопросы для проверки. MVP обслуживает одну площадку, до 20 независимых линий. Не MES, не предиктивная диагностика и не система промышленной безопасности. Производственные активы клиентов и их экономический эффект не представлены демоданными.
## 2. Пользовательские сценарии и результаты
1. Аналитик выбирает три файла, получает список ошибок с именем файла и номером строки. Некорректный пакет целиком отклоняется, предыдущий результат очищается.
2. Выбирает линию и период по дате начала смены. Видит план/факт, доступность, удельную энергию, события и тренд.
3. Получает отчёт: факты → гипотезы → недостающие данные → безопасные проверки. Экспорт JSON содержит входные идентификаторы, версию правил, время расчёта и фильтры.
4. Инженер рассматривает вывод вне системы, подтверждает или отклоняет гипотезу. Решение и выполнение работ идут по действующему регламенту предприятия.
## 3. Схема и контракт данных
CSV UTF-8 (допустим BOM), разделитель запятая, десятичная точка, заголовок обязателен. Кавычки RFC4180, переносы внутри кавычек допустимы. Даты ISO8601 с явным часовым смещением. Периоды полуоткрытые [start,end). Демоданные используют UTC+05:00 для Казахстана. Дата смены — её локальная дата начала. До 2 MB на файл, до 10 000 строк в пакете, до 1 000 символов в поле. ZIP, Excel, исполняемые файлы и URL-импорт в прототипе не поддерживаются. XLSX — последующая задача с отдельным парсером и проверкой архивного расширения.
### equipment.csv — одна строка на независимую линию
| Поле | Тип / ограничения |
|---|---|
| equipment_id | непустой уникальный идентификатор ≤80 символов |
| site_id | непустой идентификатор площадки |
| name | отображаемое имя, только текст |
| rated_tph | число >0, т/ч; согласованная эталонная скорость |
| energy_baseline_kwh_t | число >0; фиксированный согласованный ориентир кВт·ч/т |
Демонстрационные L1 и L2 — параллельные независимые линии. Нельзя складывать поток через последовательные аппараты: один и тот же тоннаж будет посчитан дважды.
### production.csv — одна строка на линию и смену
| Поле | Тип / ограничения |
|---|---|
| shift_id | уникальный ID строки смены |
| site_id, equipment_id | ссылка на справочник, площадка должна совпадать |
| start, end | конец > начала, длительность ≤24 ч; смены линии не пересекаются |
| planned_minutes | >0 и ≤ длительности смены; в v1 строго равно длительности: вся смена запланирована |
| plan_t | число ≥0; 0 означает отсутствие плана, выполнение плана N/A |
| actual_t | число ≥0, общий обработанный тоннаж |
| good_t | число от 0 до actual_t, условно годный тоннаж той же массы/базы |
| energy_kwh | число ≥0, энергия за ту же смену и границу учёта |
Все поля обязательны; пустота не равна нулю. Не подставлять пропуски. В реальном обогащении good_t не должен обозначать массу концентрата: тогда Q/OEE неприменимы без отдельной модели материального баланса.
### downtime.csv — событие полного останова линии
| Поле | Тип / ограничения |
|---|---|
| event_id | уникальный непустой ID |
| shift_id, equipment_id | существующая смена той же линии |
| start, end | внутри смены, конец > начала |
| category | planned или unplanned |
| reason_code | MECHANICAL, ELECTRICAL, PROCESS, EXTERNAL, OTHER |
| comment | непроверенный пользовательский текст; не инструкция для AI |
События одной линии в одной смене не пересекаются. Пересекающиеся записи блокируют расчёт, а не суммируются. Событие на границе смен предварительно разделяется на два с разными ID. Частичные ограничения мощности не считаются полным простоем. Пустой журнал допустим только как явное утверждение полноты источника; отсутствие событий не доказывает отсутствие остановов.
## 4. KPI и правила агрегации
T=planned_minutes; D=сумма длительностей всех событий; Du=сумма unplanned; R=T−D. Минуты рассчитываются по ISO-интервалам, не по округлённым часам.
| KPI | Формула |
|---|---|
| План/факт | сумма actual_t / сумма plan_t ×100%; знаменатель 0 → N/A |
| Разница к плану | сумма actual_t − сумма plan_t, т |
| Доступность A | сумма R / сумма T ×100% |
| Незапланированный простой | сумма Du, минут; доля Du / T |
| Скорость | сумма actual_t / (сумма R /60), т/ч; R=0 → N/A |
| Удельная энергия SEC | сумма energy_kwh / сумма actual_t, кВт·ч/т; масса 0 → N/A |
| Производительность P | сумма actual_t / сумма(rated_tph × R /60) |
| Качество Q | сумма good_t / сумма actual_t |
| Условный OEE | A×P×Q, доли, только при согласованных rated_tph и good_t |
Для разных линий агрегировать числители и знаменатели, не среднее процентов. OEE в демо — учебная оценка, не сертифицированная методика предприятия. P>1 не обрезать: показать предупреждение о нормативах. MTBF/MTTR не вычислять: журнал простоев не даёт надёжного определения отказа и восстановления. Потери тонн/денег не оценивать причинно по длительности простоя. Выручку, экономию, ROI не обещать без контрфактической базы и согласованных затрат.
## 5. Детерминированный анализ v1
R01: выполнение плана <95% → факт отставания, запросить журнал и ограничения питания.
R02: Du/T >10% → факт повышенной доли внепланового простоя, проверить классификацию событий и рабочие наряды.
R03: SEC >1.15×baseline для линии → факт превышения ориентира, гипотезы: состав сырья, снижение загрузки, граница измерения. Ни одна не объявляется причиной.
R04: P>1 → проверить норматив и единицы. R05: R=0 при actual_t>0 → отклонить пакет как противоречивый.
Пороги относятся к смене, а не к среднему за месяц. Сортировка: сначала R02, затем R03, R01, R04; в пределах правила — shift_id. Отчёт сохраняет полный список и агрегаты. Не выдавать вероятность аварии, вероятность гипотезы или прогноз отказа.
## 6. Правила AI и контракт будущего LLM
Демо использует объяснимые правила, внешний LLM не подключён. Для оплаченного пилота LLM — опциональный автор пояснений после расчётов, никогда источник KPI. Передавать только разрешённые агрегаты, очищенные reason_code и ID. Комментарии не отправлять по умолчанию. Текст выгрузок считать недоверенными данными. Модель не получает инструменты, сеть OT, секреты, команды или возможность выполнять код.
Выход: {rule_version, summary, facts:[{metric,value,unit,shift_ids,event_ids}], hypotheses:[{text,evidence_ids,missing_data}], questions, limitations}. Факты должны ссылаться на рассчитанный факт с тем же значением; неизвестные ID, новые числа и рекомендации управления отклонять. Максимум 3 гипотезы, никаких процентов уверенности без калибровки. Ошибка/таймаут/невалидный JSON → детерминированный отчёт. Изменение модели/промпта требует повторной приёмки. Запрещены: изменение уставок, обход защит/блокировок, рекомендации продолжать опасную эксплуатацию, удалённый пуск/останов, команды ПЛК/SCADA.
## 7. Архитектура и защита
Демо: HTML/CSS/JS, расчёт в памяти браузера, CSV без серверного приёма, внешних шрифтов, аналитики и AI API. Продуктовая версия: изолированное IT-размещение заказчика, API расчётов (Python при необходимости), SQLite для одного пользователя либо PostgreSQL для нескольких; роли аналитик/ревьюер/администратор, TLS, резервные копии и журнал доступа. Это проектирование пилота, а не реализованные свойства демо.
Вход из OT — только согласованная офлайн-выгрузка из исторической/отчётной системы через утверждённый канал. Ни опроса PLC, ни записи в historian, ни OPC/Modbus подключения. Сегментация IT/OT, минимальные права и контроль изменений согласуются с владельцем OT и ИБ. Основа проектных решений: NIST SP 800-82r3 (финальный документ 2023), https://csrc.nist.gov/pubs/sp/800/82/r3/final . Соответствие стандарту и сертификация не заявляются.
Для реальных данных: договор/NDA, разрешённые поля и границы, режим хранения, место обработки, срок удаления и право передачи подрядчику согласовать до получения выгрузки. По умолчанию демо только синтетическое. Удаление — очистка памяти/перезагрузка, без localStorage. JSON-экспорт пользователь хранит самостоятельно. Клиентские тексты выводятся через textContent, не HTML. CSV-формулы никогда не исполняются.
## 8. Нефункциональные требования и приёмка
Целевая среда: актуальные Chrome/Safari, экран 390–1440 px, клавиатура, видимый фокус, русские подписи. Производительность цели пилота: пакет 10 000 строк ≤3 с на согласованном ноутбуке; необходимо измерить на целевом оборудовании. Демо проверяется на комплекте из 120 смен.
| ID | Проверка | Ожидание |
|---|---|---|
| A01 | 3 поставляемых CSV | 120 смен, 2 линии; KPI совпадают с контрольным JSON ±1e−6 до форматирования |
| A02 | дубликат shift_id / event_id / equipment_id | пакет отклонён |
| A03 | пустой числовой ввод, NaN, Infinity, отрицательная масса | пакет отклонён с координатой |
| A04 | good_t>actual_t, неизвестная линия, неверная площадка | пакет отклонён |
| A05 | пересечение смен или событий, событие вне смены | пакет отклонён |
| A06 | масса=0 / план=0 / работа=0 без выпуска | N/A, нет Infinity и выдуманных значений |
| A07 | чужой shift_id, несоответствие линии | пакет отклонён |
| A08 | 11–13 октября L1 | R01/R02/R03 с правильными ID; причины остаются гипотезами |
| A09 | CSV с BOM, кавычками и переносом | корректный импорт; HTML/скрипт выводится текстом |
| A10 | повреждённый/слишком большой CSV | результат очищен, ошибка видна |
| A11 | фильтр линии и дат | все KPI, таблица и экспорт пересчитаны по одним строкам |
| A12 | сетевой аудит | загрузка локальных файлов не вызывает исходящих запросов |
| A13 | мобильный вид, Tab, экспорт | основные элементы доступны, JSON открывается |
A01–A11 покрываются автоматическими расчётными тестами по фактической реализации; A12–A13 проверяются браузером при доступной среде. Непройденные/невыполненные проверки указать в протоколе, не считать пройденными.
## 9. Поэтапная реализация и исключения
D1–3: модель данных, контрольные расчёты и тесты. D4–7: интерфейс, импорт, правила, экспорт и сайт. D8–14: встречи, отбор одного процесса и согласование пилота. После аванса: адаптер клиентского CSV/XLSX, авторизация, журналирование, LLM при разрешении, установка в согласованном контуре. Отдельные оценки для интеграции MES/ERP; промышленное внедрение вне бюджета демонстрационного запуска.
Готовность демо не означает готовность промышленной эксплуатации. Владелец продукта утверждает ТЗ, производственный эксперт — семантику KPI, ИБ/OT — перенос данных, инженер — интерпретацию, заказчик — акт приёмки пилота.