Архитектура, модель данных и логика учёта

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

Три алгоритма, от которых зависит всё

Рейс проходит через конечный набор состояний. Ни одно из них не является тупиком без оператора — любая аномалия либо разрешается автоматически, либо ждёт человека, но не исчезает.

Партия на измельчителе

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

1. Начало партии — вес на табло пошёл вверх от нуля и держит рост дольше 30 секунд.
2. Накопление — OCR читает табло раз в секунду, значения пишутся в raw_weighings с уверенностью каждого кадра.
3. Конец партии — вес перестал расти и держится стабильным 2 минуты, либо табло обнулилось.
4. Итоговый вес — максимальное стабильное значение за партию, а не последнее прочитанное.
5. Проверка доверия — если средняя уверенность за партию ниже 80 %, партия получает review_status = needs_review и всплывает у оператора с кадрами табло.

Раздача корма

Единственный узел цепочки, где счёт идёт не в килограммах, а в событиях — и это сделано намеренно. Важно, что операций здесь две, и вторая не менее существенна.

1. Граница зоны — на кадре с камеры мышью обводится въезд в зону раздачи. Настройка на объекте за десять минут, кода не требует.
2. Два класса объектов — детектор различает трактор и человека. Каждое пересечение границы пишется в raw_zone_events с полем actor и кадром.
3. Сшивание визита — пара enter + exit одного actor превращается в строку zone_visits. Вход без выхода оставляет визит открытым и уходит в тревоги.
4. Сопоставление операций — за каждой выгрузкой трактора должен последовать выход человека не позже spread_lag_minutes. Представление v_unspread_drops возвращает кучи, до которых никто не дошёл.
5. Норма — медиана числа выгрузок, выходов и длительностей за 30 дней. Ферма сама задаёт себе эталон.

В 23:59 фоновая задача собирает суточный баланс. Это единственное место, где три измерения встречаются в одной формуле — и главная ценность всей системы.

-- 1. что реально заехало (только закрытые рейсы)
brought   = Σ truck_visits.net_kg WHERE status IN ('closed', 'closed_manual')

-- 2. что приготовили
milled    = Σ mill_batches.weight_kg

-- 3. главная цифра по массе: обе величины измерены
mass_loss = brought − milled

-- 4. что происходило на раздаче — событиями, не массой
drops     = count(zone_visits WHERE actor = 'tractor')
shifts    = count(zone_visits WHERE actor = 'person')

-- 5. главный признак сбоя: куча, до которой никто не дошёл
unspread  = count(v_unspread_drops WHERE spread_visit_id IS NULL)

На примере из прототипа: привезли 69,85 т, измельчили 67,90 т — потеря по массе 1,95 т, это 2,8 % и обычный уровень для выгрузки и хранения. Дальше масса не считается вовсе. За сутки трактор сделал 11 выгрузок вместо обычных 12, человек выходил разравнивать 5 раз вместо 6, и последнюю выгрузку в 17:01 никто не разровнял — корм остался кучей. Это и есть событие дня, и оно подтверждается кадрами, а не арифметикой.

Железо на площадке

Всё выше спроектировано так, чтобы пережить любой ответ на эти вопросы. Но пока ответов нет, часть цифр в смете будет с диапазоном.