askcust розробляє аграрні IT-системи, які збирають дані з техніки, датчиків, ваг і супутників у спільну базу, обробляють їх і показують агроному та керівнику. Для агропідприємств, де обладнання вже працює, але кожен постачальник тримає дані у своєму кабінеті.
Розробка аграрних IT-систем — це створення програмного забезпечення, яке збирає дані з техніки, датчиків, контролерів, ваг і супутникових знімків, зберігає їх у спільній моделі з привʼязкою до полів і техніки та перетворює на показники й події для людей і облікових систем. На відміну від розробки облікових програм, тут головне — надійний збір і обробка даних від пристроїв і зовнішніх сервісів.
Система забирає дані з телематики, датчиків, ваг і супутникових сервісів через їхні API та протоколи й зводить у спільну базу. Трек техніки, рівень палива, вологість ґрунту й вагу партії видно поруч — із привʼязкою до поля та операції.
Пропуски, дублікати й стрибки показань відфільтровуються за правилами, а сирі записи зберігаються окремо від оброблених. Будь-який розрахунок — оброблену площу, витрату палива, залишок — можна простежити до першоджерела або перерахувати після зміни налаштувань.
Термінали, шлюзи й мобільні додатки буферизують записи й досилають їх, щойно зʼявляється мережа. Сервер упорядковує дані за часом вимірювання, а не надходження, тож звіт за день збирається повністю навіть після кількох годин без звʼязку.
Кожне джерело підключається через окремий адаптер до спільної моделі даних. Новий бренд трекерів чи датчиків означає новий адаптер, а не нову систему: історія, звіти й інтеграції з обліком лишаються на місці.
Правила подій безперервно перевіряють дані: зупинка насоса, виїзд техніки за межі поля, різке падіння рівня палива. Сповіщення отримує відповідальна людина — у Telegram або push-повідомленням у додатку, з посиланням на подію на карті.
Архітектура одна — збір, зберігання, обробка, інтерфейси; модулі добираються під обладнання господарства.
Інтеграція з Wialon і API телематики виробників техніки: координати, швидкість, мотогодини, рівень палива й дані CAN-шини (J1939), які передають термінали. Трек розкладається на операції по полях.
Датчики надсилають показання через MQTT, а контролери насосних, сушарок і метеостанцій опитуються за протоколом Modbus RTU/TCP через шлюз. Система стежить, чи кожен пристрій на звʼязку, і фіксує, коли він замовк.
Знімки Sentinel-2 через Copernicus або Sentinel Hub, маскування хмар, вегетаційні індекси в межах контурів полів та історія за сезони — окремим шаром на карті поруч із даними техніки.
Обмін із ваговими терміналами та ваговим ПЗ, імпорт результатів лабораторних аналізів, привʼязка ваги й якості до ТТН, партії та поля, з якого приїхало зерно.
Нормалізація одиниць і часу, фільтрація викидів, розрахунок обробленої площі, витрати й простоїв; правила подій і маршрутизація сповіщень за ролями в Telegram та push.
Web-панель для агронома й керівника, мобільний додаток для роботи в полі, API для обліку та BAS, експорт у CSV та ISOXML для інших систем і терміналів техніки.
Ролі з правами на поля, техніку й дії, журнал змін, шифровані зʼєднання. Контролери з Modbus, який у класичному варіанті не має автентифікації, не виставляються в інтернет напряму: дані йдуть через шлюз або VPN.
askcust пише ПЗ та адаптери до джерел даних; трекери, датчики, контролери й підписки на сервіси постачає й обслуговує їхній постачальник.
| критерій | Кабінети постачальників | Власна система від askcust |
|---|---|---|
| Дані | Кожен постачальник показує лише своє обладнання — у своєму інтерфейсі. | Техніка, датчики, ваги й супутникові дані зведені в одну модель із привʼязкою до полів. |
| Привʼязка до поля | Трек, паливо й вагу доводиться зіставляти з полем і операцією вручну, у таблицях. | Події привʼязуються до поля, техніки й операції автоматично, щойно дані надходять у систему. |
| Зміна обладнання | Новий постачальник — це новий кабінет, а історія лишається в старому. | Новий постачальник — це новий адаптер; історія, звіти й інтеграції зберігаються. |
| Звіти | Набір звітів і формат експорту визначає постачальник. | Звіти будуються під процеси господарства, а дані вивантажуються в облік і BAS. |
| Зберігання | Історія зберігається на серверах постачальника в межах його тарифу. | Сирі й оброблені дані зберігаються на сервері або в хмарі власника. |
| Коли обирати | Один тип обладнання, і стандартних звітів постачальника вистачає. | Кілька джерел даних, потрібні спільні звіти, власні правила подій або інтеграція з обліком. |
Перелік обладнання, сервісів, протоколів і API, перевірка якості даних на реальних вибірках. Результат — карта джерел: що можна підключити одразу, а для чого потрібен доступ від постачальника.
Схема збору, зберігання й обробки, модель даних (поле, техніка, пристрій, подія) і прототип ключових екранів, погоджені до початку розробки.
Одна група техніки, одна насосна чи одне поле з датчиками: перевірка звʼязку, буферизації й точності розрахунків на живих даних.
Підключення решти обладнання й кластерів за схемою, перевіреною в пілоті, правила подій і сповіщень, обмін даними з обліком і BAS.
Моніторинг надходження даних від кожного джерела, оновлення адаптерів, коли постачальники змінюють API, і розвиток системи під нове обладнання.
приклади робіт askcust →не агро, але той самий тип задач: облік, CRM, автоматизація
Ні. askcust розробляє програмне забезпечення та інтегрує обладнання, яке постачає й встановлює його виробник або інтегратор. На етапі аудиту askcust допомагає сформулювати вимоги до обладнання: які дані, з якою частотою і за яким протоколом має віддавати пристрій, щоб система могла ними користуватися. Так вибір постачальника не обмежує систему.
Так, якщо воно віддає дані через API, стандартний протокол або файли. Телематика з доступом до API, датчики з MQTT, контролери з Modbus і вагові термінали з вивантаженням підключаються через адаптери без заміни обладнання. Якщо пристрій даних не віддає, це видно ще на аудиті, до початку розробки.
На сервері замовника або в хмарному акаунті, яким він володіє. Сирі дані з пристроїв зберігаються окремо від оброблених, тож будь-який показник можна перевірити або перерахувати. Код системи й адаптерів передається в репозиторій замовника, а доступ askcust обмежується часом розробки і супроводу за домовленістю.
Дані не губляться, а надходять пізніше. Телематичні термінали й шлюзи буферизують записи, мобільний додаток працює офлайн і синхронізує чергу змін, а сервер упорядковує записи за часом вимірювання й відкидає дублікати. Звіти за період перераховуються, коли дані за нього надійшли повністю.
За вимогами до даних і супроводу: скільки даних надходить і як часто, де працює система, хто її підтримуватиме. Типовий набір askcust — Node.js і TypeScript для сервісів збору та API, PostgreSQL для даних, Python для обробки супутникових знімків, Next.js для web-панелі, Swift і Kotlin для мобільних додатків.
Вартість розробки залежить від кількості джерел даних і протоколів, обсягу обробки та інтерфейсів, а не від кількості техніки чи гектарів. Почати варто з пілоту на одному обʼєкті: після аудиту askcust оцінює його з фіксованим обсягом, а масштабування на решту обладнання оцінюється окремо, коли пілот підтвердив, що дані надходять і рахуються правильно.
Відповідь протягом робочого дня; дзвінок — лише якщо домовимось.