Як ІТ трансформує фермерство: використання супутникових зображень та прогноз врожайності

Всім привіт! Мене звати Іванна Горошко і я Lead Software Engineer в компанії N-iX. Останні 3 роки я працюю над проектом, який використовує супутникові зображення та різноманітну аналітику, щоб допомагати аграріям отримувати кращі врожаї.

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

Наш клієнт — це велика аграрна Група, яка є одним з лідерів агроринку у Великобританії, Ірландії, Польщі, Румунії і навіть Україні (не називаю ім’я компанії, щоб не порушувати політику конфіденційності). До їхньої команди інженерів ми долучилися (працюємо як distributed команда), щоб розробляти та підтримувати веб і мобільні додатки, які використовуються в B2B. З одного боку — компанії, які купили це рішення в Групи, з іншого — аграрії, які працюють з цими компаніями.

Мова йде про два додатки. Відразу розповім, що один ми створили для ринку Африки, і користуються ним банки та благодійні організації, які вкладають гроші у розвиток фермерства на цьому континенті. Другий — для аграріїв з Великої Британії, Польщі, Румунії та України.

Труднощі на початку

Коли ми долучились до проекту, вже існувала desktop-програма, а також почалася робота над розробкою веб версії додатку. В першу чергу ми розбиралися у функціоналі та шукали можливості для покращень.

Вирішили проблему з несвоєчасним надходженням зображень.

Що ми зробили для цього?

Ввели централізовану систему логування

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

Ми зрозуміли, що система логування була не ідеальною — дані були не систематизовані, а тому було майже неможливо знайти потрібні логи про помилку, яка сталась два дні тому. Тому ми поставили собі за мету ввести централізовану систему логування. Оскільки в той час продукти розміщувались на віртуальних машинах (хоча і в докер контейнерах!), було прийнято рішення перемістити їх на Kubernetes кластер в AWS і використати EFK stack (EFK, а не ELK. Fluentd використовується замість Logstash як нативний для Kubernetes).

Навіть така відносно невелика зміна як місце хостингу і централізована система логування (на якій ми зробили дашборди для візуалації логів/помилок) показала хороший результат. Ми змогли ідентифікувати основні та найчастіші помилки.

До того ж, це дало нам змогу швидше відповідати на запити клієнтів, і відповідно покращити наші SLA.

Перевели систему на інший message broker

Основною проблемою, що була причиною більшості помилок, виявився message broker. Тоді клієнт використовував beanstalk (не AWS Beanstalk!): неефективна система retry і error handling, а також складний клієнт для Java. Ми вирішили перевести систему на RabbitMQ. Розробили ефективний підхід до retry, який є дуже важливим для нашої системи, оскільки ми інтегруємось з великою кількістю 3rd-party tools, а вони не завжди працюють стабільно і швидко.

Запустили моніторинг 3rd-party

Потім ми додали моніторинг до 3rd-party, щоб розуміти, як часто в їхніх системах відбуваються збої, і тут вже support tickets полетіли від нас до наших satellite providers. Рішення не технічне, але дало нам змогу проактивно реагувати на великий відсоток майбутніх проблем з доставкою зображень фермерам.

Покращили код, який використовувався

Єдине, що залишилось покращувати далі — це код. Що ми зробили:

Рефакторинг — починаючи від дрібних code smells і закінчуючи зміною логіки (розбиття на менші підмодулі, стандартизація підходів).
Тести двох рівнів — unit та integration. Integration тести запускаються з власним rabbitmq (використовуємо spring containers) і замоканими 3rd-party; Вони перевіряють весь флов від початку до кінця загалом, а також кожну окрему дію саму по собі.
Документацію — як для інженерів з деталями реалізації, так і для саппорт команди, менш детальну, але яка дає добре розуміння системи.

Як результат — ми забули про support tickets з проблемою відсутності зображень.

Написали нову модель security

Наступним викликом стала застаріла система безпеки, яка не була проблемою для юзерів, але однозначно була проблемою для нашого клієнта і для інженерів (які могли оцінити кількість потенційних ризиків).

Перше питання, яке перед нами постало — писати систему самостійно чи використовувати провайдера. Хотілось використати провайдера, наприклад, Auth0. Але, на жаль, він вимагає наявності унікальних, підтверджених email в кожного користувача, яких у нас немає (система працювала з використанням username).

Тому ми прийняли рішення писати самостійно. Оскільки вже тоді ми не відкидали можливості інтеграції з security провайдером, логіка всієї security мала бути інкапсульована в одному місці — щоб при бажанні її можна було легко змінити.

Так ми дійшли до питання API Gateway. Розглядали в осному два варіанти — AWS API Gateway і Ambassador + Istio. Оскільки ми не хотіли мати platform lock, то обрали Ambassador + Istio, які розгортаються на Kubernetes кластері.

Далі створювали нові кластери, використовуючи Terraform, розробили сервіс для авторизації/аутентифікації та підхід для версійності API, зробили міграцію всіх наших сервісів (а в нас їх 20+) на новий кластер з новою моделлю security, створили API документацію.

Впровадження власного auth gateway також дало нам змогу розробити підхід для власних public API.

Про рішення та нашу роботу з супутниковими зображеннями

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

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

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

Перед тим, як ми почнемо надавати інформацію конкретному аграрію, йому (або компанії, з якою працює аграрій) потрібно ввести дані у систему додатку. Створюється новий аккаунт фермера, де фіксуються наступні дані.

Географічне розташування ділянок, де вирощуються культури

Це можна зробити трьома методами. Перший — приїхати на поле, відкрити потрібне меню у нашій програмі та пройтися з телефоном по межі ділянок. Другий — обвести свої ділянки на супутниковому зображенні, яке ми надаємо. Третій — підвантажити «shapefile» файли, які є у компанії, якщо вони вже автоматизували інший процес роботи з полями.

Висаджені культури або дерева (наприклад, яблуні)

У програмі є базовий каталог культур, який ми створили та підтримуємо. Наприклад, аграрій обирає зі списку гречку. Далі система запитує, яку саме гречку ти хочеш посадити — випадає ще один список. Аграрій обирає або додає нову. Така точність важлива, адже потім програма аналізує дані врожайності та видає рекомендації.

У каталозі додатку для Великої Британії є 70 культур. В каталозі України зараз 25 культур. Думаю, це пов’язано з тим, що в Україні у компанії зараз менша кількість клієнтів, і вони працюють саме з тими культурами, що вже є у каталозі.

Тип ґрунту

Як і з каталогом культур, система пропонує обрати або ввести тип ґрунту. Ми взаємодіємо з провайдерами в різних країнах, які надають інформацію про ґрунт. Тому, залежно від розташування поля, система може підказати аграрію, який тип ґрунту саме на його ділянці. Якщо ж інформація про ділянку у нас відсутня — фермер самостійно обирає тип із заданого каталогу.

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

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

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

Після того, як обрано найкраще зображення, ми працюємо з ndvi-індексом (Normalized Difference Vegetation Index). Індекс розраховується за формулою:

Потрібно порівняти між собою значення поглинання і відображення червоних (Red) та інфрачервоних променів (Nir).

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

Приклад зображення, яке бачить користувач додатку

За угодою ми маємо надавати зображення кожній фермі хоча б раз на тиждень. Тому кількість зображень, які ми пропрацьовуємо щодня, залежить від погоди. При тривалій хмарності кількість ферм, які не отримали якісне зображення, щодня зростає. Через це ми маємо опрацьовувати більше зображень — шукаючи те, яке підійде по якості. Так, кількість зображень, які ми пропрацюовуємо щодня, варіюється від до 2-ох до 7-ми тисяч (і це тільки від одного супутникового провайдера).

Якщо у тижні всі дні були хмарні, і супутнику не вдалося зробити хороше зображення ділянки — програма показує фермеру зображення без прорахованого ndvi (його неможливо вирахувати). Таким чином, наші клієнти знають, що дані по їхній ділянці були опрацьовані.

Щодня ми надаємо інформацію про більше, ніж 500 тис. гектарів ділянок у світі.

У додатку аграрій отримує прогнози врожайності.

Програма допомагає аналізувати дані врожайності та підказує, що варто змінити наступного разу, щоб отримати потрібний фермеру результат. Наприклад, залежно від висадженої культури система може підказати, що перед наступною посадкою потрібно підвищити/зменшити показник кислотності грунту.

Післяслово

Мені подобається цей проект не лише через його цікаву технічну складову.

Доступ до супутникових зображень, аналізу ґрунту та іншої інформації, яка дозволяє фермерам стежити за висадженими культурами, виявляти хвороби рослин та лікувати їх до того, як завдано серйозну шкоду — ці та інші рішення трансформують галузь. ІТ вже робить фермерство більш сталим — таким, що відповідає на потребу людства у легшому доступі до достатньої кількості їжі. Цікаво, які ще інноваційні рішення чекають цю галузь у майбутньому.

Теми: IT, розробка