INITASK Опис рішення · агровиробництво МХП

Повернутись до переліку агентів

Опис рішення: Контроль напрацювання вузлів

Документ описує, що саме робить агент, на яких даних, за якими правилами і як ви перевірите результат. Розробка за цим агентом починається після вашого письмового підтвердження цього опису.

Агент у кабінетіm2 (production-61)
БлокТехніка і ремонти
Основний користувачІнженер з надійності
Кабінетmhp-agro-app.initask.com
Статуспроєкт опису, відкритий для правок

1. Задача

Питання «чи доживе вузол до кінця жнив» вирішується на око. Агент рахує дату ймовірної відмови за темпом напрацювання з телеметрії і одразу перевіряє, чи встигає запчастина.

2. Як агент працює

Рахує дату ймовірної відмови за темпом напрацювання з телеметрії і перевіряє, чи встигає запчастина.

Порядок один для всіх агентів кабінету: агент читає ваше вивантаження і перевіряє його по рядках, рахує за явними правилами і вашими нормативами, показує результат таблицею, у якій кожне число розкривається до рядків вашого файлу, і піднімає сигнали. Вигаданих цифр немає: якщо даних для показника бракує, агент так і пише і не рахує.

3. Що потрібно від вас

Техніка і вузли (tehnika.csv)

Парк з напрацюванням по вузлах. Основа для ТО і прогнозу відмов.

КолонкаЩо в нійОбовʼязкова
idІнвентарний номер або позивнийтак
modelМодельні
kindТип: комбайн, трактор, обприскувач, автоні
nodeВузол, за яким рахуємо ресурстак
hours_sinceНапрацювання від останньої заміни, мотогодинтак
resource_hПаспортний ресурс вузла, мотогодинтак
load_kПоправка на навантаження, за замовчуванням 1ні
last_serviceДата останнього обслуговуванняні

Телеметрія (telemetriia.csv)

Вивантаження з трекера або MyJohnDeere. Приймаємо і оброблені показники, і сирий кадр CAN.

КолонкаЩо в нійОбовʼязкова
machineМашинатак
tsЧас записутак
engine_hМотогодини на момент записуні
fuel_lПальне, літрівні
speedШвидкість, км/годні
overlapПерекриття, %ні
error_codeКод помилкині
can_idІдентифікатор кадру CAN, напр. 0x18FEE900ні
can_dataСирі байти кадру, hexні
can_maskМаска фільтрації кадру, hexні
isobus_app_idІдентифікатор ISOBUS-агрегатуні
isobus_dataДані процесів ISOBUS, hexні
latШиротані
lonДовготані
satsСупутників захопленоні
alt_mВисота, мні
voltНапруга живлення, Вні
paramsПараметри трекера, як у файліні

4. Нормативи і пороги

Це значення за замовчуванням. Їх міняє ваш відповідальний прямо у кабінеті, без нашої участі і без релізу, кожна зміна лягає у журнал з автором і датою. Частина нормативів спільна для кількох агентів: вона задається один раз і діє скрізь, де на неї спираються.

НормативЗа замовчуваннямДопустимі межі
Спрацювання ресурсу вузла8510 до 100

5. Що агент видає

Показники на екрані

Таблиці, у які можна провалитись з будь-якого числа

Ризик відмови у пік: прогноз за фактичним напрацюванням
Колонки: Машина, Вузол, Вироблено, Днів лишилось, Дата, Склад, Поставка, дн, Встигає

Сигнали, які агент піднімає

РівеньЯк це звучить
критичнийCL-01, молотильний барабан: 102,3% ресурсу, ресурс уже вичерпано

Формулювання у колонці праворуч це приклад на демонстраційному наборі: на ваших даних агент назве ваші обʼєкти і ваші цифри. Кожен сигнал перетворюється на задачу з виконавцем за правилом маршрутизації, яке ви правите у кабінеті.

6. Межа відповідальності

Дата відмови це продовження темпу, а не інженерний розрахунок надійності: вона рухається з кожним новим вивантаженням телеметрії. Машина без темпу напрацювання дати не отримує, і це видно на екрані.

7. Як ви перевірите, що агент працює

Перевірте на вузлі, який справді відмовив: дата, яку агент дав би за місяць до цього, має лягти у розумний інтервал.

8. Порядок погодження

1. Ви читаєте цей опис і позначаєте коментарем усе, що зрозуміли інакше або що описано неповно.

2. Ми правимо опис за вашими коментарями і надсилаємо оновлену версію.

3. Ви підтверджуєте опис письмово поштою. З цього моменту він є підставою для технічного завдання і для приймання.

4. Далі йде розробка. Будь-яка зміна після підтвердження оформлюється окремо, з новою оцінкою строку.

Initask. Сторінка закрита від індексації. Правки і коментарі: через Катю.