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

Корм проходит четыре точки, и в каждой измеряется своим способом с разной точностью. Вся система построена вокруг того, чтобы эти четыре измерения свести и объяснить разницу между ними.

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

База делится на два уровня, и это единственное архитектурное решение, которое нельзя менять по ходу дела.

Из этого следует ещё одно правило: любая производная цифра хранит ссылки на источники. У рейса есть gross_weighing_id и tare_weighing_id — из карточки рейса можно провалиться в конкретное показание весов и увидеть кадр табло в момент измерения.

PostgreSQL. Сырые события — гипертаблицы TimescaleDB (партиционирование по времени, автосжатие старых данных). Ниже — только значимые поля; служебные created_at, updated_at опущены.

Справочники

Сырые события — append-only

Производные сущности — пересобираются из сырых

Также: alerts (тревоги и подтверждения), storages (силосы), rations (рационы), users, pen_head_history (история поголовья по локам).

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

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

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

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

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

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

Раздача по локам

Самое грубое измерение в цепочке и единственное, где счёт идёт не в килограммах, а в событиях.

1. Техника в зоне — камера лока детектит экскаватор, открывается сессия кормления.
2. Подсчёт ковшей — считается не сам ковш, а цикл: подъём → опрокидывание над столом. Каждый цикл — строка в raw_bucket_events с трёхсекундным клипом.
3. Пересчёт в килограммы — bucket_count × bucket_capacity_kg. Ёмкость ковша калибруется в первые недели: сравниваем сумму по локам с весом партии измельчителя и подгоняем коэффициент.
4. Сверка с планом — план берётся из pens.kg_per_head × head_count на момент кормления.
5. Тревоги — отклонение больше 15 %, либо лок не посещался спустя 45 минут после планового времени.

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

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

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

-- 3. что вынесли на кормовой стол
delivered = Σ feedings.estimated_kg
planned   = Σ feedings.planned_kg

-- 4. объяснимая часть разрыва: пропуски и недокормы
explained = Σ (planned_kg − estimated_kg) WHERE deviation_pct < -15

-- 5. главная цифра отчёта
unexplained = milled − delivered − explained

На примере из прототипа: измельчили 67,90 т, вынесли 59,11 т, разрыв 8,79 т. Из него 7,65 т — это непокормленный лок №12 и недокорм лока №7. Остаётся 1,14 т необъяснённого — при погрешности оценки ковшей ±10 % это шум, а не пропажа.

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

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