W projektach związanych z rolnictwem cyfrowym aplikacja jest zwykle tylko ostatnim elementem znacznie większego systemu. Dane trzeba najpierw zebrać z sensorów, maszyn lub innych źródeł, przesłać z gospodarstwa do infrastruktury centralnej, odpowiednio zapisać i przetworzyć, a dopiero później przedstawić użytkownikowi albo wykorzystać do automatycznego podjęcia decyzji.

Właśnie dlatego część IT projektu AGROSTRATEG warto projektować jako jeden spójny system, a nie zestaw niezależnych komponentów zamawianych kolejno u różnych wykonawców.

Ma to szczególne znaczenie w obszarze T3 „Rolnictwo cyfrowe”. NCBR wskazuje tutaj między innymi oprogramowanie do zarządzania gospodarstwem w czasie rzeczywistym, platformy integrujące dane z sensorów, IoT, teledetekcję i analizę obrazu, systemy precyzyjnego nawadniania, geolokalizację oraz rozwiązania pozwalające optymalizować działania wykonywane w gospodarstwie.

Jak więc przejść od pomysłu zapisanego we wniosku do architektury, którą rzeczywiście da się zbudować, przetestować i później wdrożyć?

Zacznij od przepływu danych, nie od wyboru technologii

Jednym z pierwszych pytań w projekcie technologicznym często jest: jakiego frameworka użyć, gdzie postawić backend albo jaką bazę danych wybrać?

To decyzje, które powinny pojawić się znacznie później.

Na początku trzeba opisać pełną drogę informacji przez system. W najprostszym wariancie może wyglądać tak:

pomiar → urządzenie → transmisja → backend → baza danych → analiza → decyzja → użytkownik

Załóżmy, że projekt ma optymalizować nawadnianie upraw. Czujniki znajdujące się na polu mierzą wilgotność gleby. Dane są przesyłane do systemu centralnego, zestawiane z informacjami pogodowymi i historycznymi, a algorytm na ich podstawie wyznacza rekomendowaną ilość wody.

Dopiero na końcu procesu użytkownik widzi komunikat w aplikacji albo system automatycznie przekazuje polecenie do infrastruktury odpowiedzialnej za nawadnianie.

Każdy z tych etapów rodzi inne pytania techniczne. Jak często wykonywany jest pomiar? Czy urządzenie ma stałe zasilanie? Jaki jest zasięg sieci komórkowej? Co powinno wydarzyć się przy braku łączności? Ile urządzeń będzie działało podczas pilotażu, a ile po wdrożeniu? Jak szybko system musi reagować? Czy dane będą analizowane lokalnie, czy wysyłane do chmury?

Dopiero odpowiedzi na takie pytania pozwalają sensownie dobierać technologie.

Jak może wyglądać architektura systemu IoT w projekcie AGROSTRATEG?

Nie istnieje jedna architektura odpowiednia dla każdego projektu rolnictwa cyfrowego. Monitoring warunków w szklarni ma inne wymagania niż system pracujący na setkach hektarów, a jeszcze inne rozwiązanie będzie potrzebne do analizy obrazu przesyłanego przez drony.

Można jednak wyróżnić kilka warstw, które pojawiają się w większości tego typu projektów.

1. Sensory, maszyny i inne źródła danych

Na samym początku znajdują się urządzenia dostarczające informacji o rzeczywistym świecie.

Mogą to być czujniki wilgotności gleby, temperatury, nasłonecznienia, jakości powietrza czy parametrów mikroklimatu. Dane mogą pochodzić również z maszyn rolniczych, urządzeń pomiarowych, stacji pogodowych, kamer, dronów, systemów GPS lub rozwiązań dostarczanych przez zewnętrznych producentów.

Już na tym etapie warto ustalić format danych oraz sposób identyfikacji urządzeń. Jeżeli każdy typ sensora zacznie komunikować się z systemem w zupełnie inny sposób, późniejsza integracja będzie coraz trudniejsza.

Dobrze zaprojektowana warstwa urządzeń powinna też uwzględniać możliwość wymiany konkretnego modelu sensora na urządzenie innego producenta bez przebudowy całej platformy.

2. Warstwa komunikacji

Sensor znajdujący się w polu musi w jakiś sposób przekazać dane dalej. W gospodarstwie nie zawsze można zakładać dostęp do stabilnego Wi-Fi czy infrastruktury przewodowej.

W zależności od zastosowania można rozważyć między innymi:

• LoRaWAN – przydatny przy dużej liczbie urządzeń przesyłających niewielkie pakiety danych i wymagających niskiego zużycia energii;
• NB-IoT – rozwiązanie wykorzystujące infrastrukturę operatora komórkowego, dobrze pasujące do rozproszonych urządzeń telemetrycznych;
• LTE/GSM – gdy potrzebna jest większa przepustowość lub urządzenie przesyła więcej danych;
• Wi-Fi lub Ethernet – często wystarczające w budynkach, halach, szklarniach i innych miejscach z istniejącą infrastrukturą;
• komunikację lokalną i gateway – kiedy urządzenia komunikują się najpierw z lokalną bramką, która dopiero później przesyła dane do systemu centralnego.

Sam zasięg nie powinien być jedynym kryterium wyboru. Trzeba uwzględnić również zużycie energii, koszt transmisji, ilość danych, opóźnienia, możliwość pracy offline oraz późniejszy serwis urządzeń.

LoRaWAN czy NB-IoT?

To jedno z pytań, które często pojawia się przy projektowaniu systemów działających poza miastami.

LoRaWAN pozwala stworzyć własną sieć obejmującą dużą liczbę urządzeń. Sensor może pracować bardzo długo na baterii i przesyłać niewielkie porcje danych do zlokalizowanej w pobliżu bramki.

Ma to sens na przykład wtedy, gdy kilkaset czujników znajduje się na określonym obszarze należącym do jednego gospodarstwa lub grupy gospodarstw.

NB-IoT wykorzystuje natomiast sieć operatora. Każde urządzenie może komunikować się z systemem bez konieczności budowania własnej infrastruktury LoRaWAN, o ile na danym obszarze dostępna jest odpowiednia sieć.

Może to być atrakcyjne w przypadku urządzeń rozmieszczonych w wielu odległych od siebie lokalizacjach.

Nie warto więc zaczynać projektu od stwierdzenia „zbudujemy system na LoRaWAN”. Najpierw trzeba określić warunki, w których system będzie rzeczywiście działał, a dopiero potem dobrać technologię komunikacji.

Backend IoT – centrum całego systemu

Dane odebrane z urządzenia powinny trafić do warstwy backendowej.

W prostym prototypie można przesłać wartości bezpośrednio do bazy danych i wyświetlić je na wykresie. W większym systemie backend zaczyna jednak odpowiadać za znacznie więcej.

Musi rozpoznawać urządzenia, kontrolować ich dostęp do systemu, odbierać komunikaty, walidować dane, obsługiwać błędy, zarządzać konfiguracją urządzeń i reagować na konkretne zdarzenia.

W systemach IoT często wykorzystywany jest MQTT. Protokół dobrze pasuje do komunikacji urządzeń z backendem, szczególnie gdy dane przesyłane są regularnie i system ma obsługiwać dużą liczbę klientów.

Warstwa backendowa może później udostępniać dane aplikacji webowej, aplikacji mobilnej, systemowi analitycznemu oraz zewnętrznym integracjom poprzez API.

To właśnie tutaj warto zadbać o wyraźne oddzielenie urządzeń od pozostałych elementów systemu.

Jeżeli aplikacja mobilna pobiera dane bezpośrednio z rozwiązania konkretnego producenta sensora, każda zmiana sprzętu zaczyna wpływać na aplikację.

Jeżeli natomiast urządzenia komunikują się ze wspólną warstwą backendową, można rozwijać poszczególne elementy znacznie bardziej niezależnie.

Jak przechowywać dane z urządzeń?

Projekt wykorzystujący kilkanaście urządzeń podczas pierwszych badań może generować stosunkowo niewiele danych. Sytuacja wygląda inaczej, gdy rozwiązanie zostanie wdrożone w setkach gospodarstw.

1000 urządzeń wysyłających pomiar co minutę oznacza już ponad 1,4 miliona nowych pomiarów dziennie.

W dodatku dane telemetryczne mają specyficzny charakter. Istotna jest nie tylko sama wartość, ale również czas pomiaru, urządzenie, lokalizacja i często dodatkowy kontekst.

Dlatego przy projektowaniu bazy danych warto od początku zastanowić się nad przyszłą skalą systemu.

Nie oznacza to konieczności budowania niezwykle skomplikowanej infrastruktury już na etapie pierwszego PoC. Architektura powinna jednak pozwalać na późniejsze skalowanie bez konieczności przepisywania całego systemu.

Osobno warto przechowywać dane konfiguracyjne i biznesowe – użytkowników, gospodarstwa, pola, urządzenia, konfiguracje alertów czy uprawnienia – a osobno dużą liczbę danych pomiarowych.

Co powinno wydarzyć się przy braku internetu?

To szczególnie istotne w systemach działających poza dużymi ośrodkami miejskimi.

Aplikacja projektowana przy biurku może zakładać, że każde urządzenie ma stały dostęp do internetu. W rzeczywistych warunkach rolniczych może okazać się, że część gospodarstwa znajduje się poza zasięgiem sieci, transmisja chwilowo przestaje działać albo urządzenie przez wiele godzin nie może połączyć się z backendem.

System powinien mieć na taki scenariusz przygotowaną odpowiedź.

Urządzenie lub lokalny gateway może na przykład przechowywać pomiary i przesłać je później. Backend powinien natomiast potrafić odróżnić brak nowych danych od prawidłowej wartości pomiaru.

W przypadku systemów sterujących urządzeniami trzeba odpowiedzieć na jeszcze ważniejsze pytanie: co urządzenie zrobi bez kontaktu z centralnym serwerem?

Jeśli od odpowiedzi systemu zależy otwarcie zaworu, uruchomienie wentylacji czy wykonanie innej operacji wpływającej na produkcję, podstawowa logika bezpieczeństwa nie zawsze powinna zależeć od dostępu do chmury.

Gdzie w tym wszystkim jest AI?

W projektach technologicznych sztuczna inteligencja pojawia się obecnie bardzo często. Sama deklaracja wykorzystania AI nie rozwiązuje jednak żadnego problemu.

Najpierw warto określić decyzję, którą model ma pomóc podjąć.

Może chodzić o wykrycie choroby na podstawie obrazu rośliny, przewidywanie momentu wystąpienia określonych warunków, identyfikację nietypowego zachowania zwierząt, prognozowanie zapotrzebowania na wodę albo wykrywanie anomalii w danych pochodzących z urządzenia.

Wtedy można określić dane potrzebne do wytrenowania i późniejszej walidacji rozwiązania.

To szczególnie istotne w projekcie B+R. Jeżeli jednym z rezultatów ma być algorytm osiągający określoną skuteczność, dane potrzebne do jego opracowania muszą być częścią projektu od początku.

Nie można zakładać, że najpierw powstanie system, a później „dodamy AI”.

Trzeba odpowiedzieć między innymi na pytania o to, skąd będą pochodziły dane uczące, jak zostaną oznaczone, jaka będzie ich jakość, w jaki sposób zostanie podzielony zbiór treningowy i walidacyjny oraz według jakiej metryki ocenimy skuteczność rozwiązania.

Projekt B+R wymaga innego podejścia niż standardowe wdrożenie IT

W klasycznym projekcie komercyjnym klient określa wymagania, zespół tworzy rozwiązanie, przeprowadza testy i wdraża gotowy system.

Projekt badawczo-rozwojowy ma dodatkową warstwę niepewności.

W trakcie realizacji może dopiero zostać zweryfikowane, czy określony sposób pomiaru zapewnia wystarczającą dokładność, czy wybrana metoda transmisji działa w rzeczywistym środowisku albo czy opracowany algorytm osiąga zakładane parametry.

W I konkursie AGROSTRATEG dofinansowaniu mogą podlegać między innymi badania przemysłowe, eksperymentalne prace rozwojowe oraz prace przedwdrożeniowe. Projekt bez eksperymentalnych prac rozwojowych nie może uzyskać dofinansowania.

Architektura IT powinna więc umożliwiać prowadzenie takich eksperymentów.

W praktyce może to oznaczać możliwość jednoczesnego testowania różnych sensorów, zapisywanie dodatkowych parametrów, porównywanie wersji algorytmu czy zmianę częstotliwości wykonywania pomiarów bez przebudowy całego rozwiązania.

To również argument za tym, żeby już na początku projektu dokładnie rozdzielić warstwę urządzeń, transmisji, przetwarzania danych i aplikacji.

PoC nie powinien być ślepą uliczką

Pierwszą wersję systemu warto zbudować szybko. Jej zadaniem jest zweryfikowanie najważniejszych założeń technicznych i badawczych.

PoC może odpowiedzieć na przykład na pytanie, czy sensor zapewnia wystarczającą jakość pomiaru, czy LoRaWAN osiąga wymagany zasięg albo czy określony model potrafi prawidłowo klasyfikować obraz.

Nie ma sensu budować na tym etapie wszystkich funkcji planowanego produktu.

Jednocześnie warto uważać na drugą skrajność: stworzenie jednorazowego prototypu, którego po zakończeniu eksperymentu nie da się dalej rozwijać.

Dobry proces wygląda raczej tak:

PoC → pilotaż → walidacja → system produkcyjny → skalowanie

Już podczas PoC warto więc określić, które elementy mają charakter eksperymentalny i mogą zostać później zastąpione, a które tworzą fundament przyszłego rozwiązania.

Ma to znaczenie również dlatego, że celem programu AGROSTRATEG jest nie tylko prowadzenie badań, ale wdrażanie nowych rozwiązań poprawiających efektywność polskiego sektora rolnego. NCBR dopuszcza między innymi wykorzystanie rezultatów projektu we własnej działalności przedsiębiorstwa, a w określonych przypadkach również wdrożenie poprzez licencjonowanie lub sprzedaż praw.

Web czy aplikacja mobilna?

Odpowiedź zależy przede wszystkim od tego, kto i w jakich warunkach będzie korzystał z rozwiązania.

Aplikacja webowa bardzo dobrze sprawdza się jako centralny panel do konfiguracji urządzeń, analizy danych, przeglądania raportów, zarządzania gospodarstwami i pracy na większej liczbie informacji.

Aplikacja mobilna może natomiast być wygodniejsza dla osoby pracującej w terenie.

Operator może otrzymać alert o konkretnym zdarzeniu, sprawdzić urządzenie, wykonać zdjęcie, zeskanować kod QR, potwierdzić wykonanie zadania albo zobaczyć dane dotyczące pola, na którym aktualnie się znajduje.

Często najlepszym rozwiązaniem okazuje się więc połączenie obu kanałów.

Panel webowy służy do zarządzania całym systemem, a aplikacja mobilna zapewnia dostęp do najważniejszych informacji i operacji wykonywanych w terenie.

Jeden system może mieć kilka zupełnie różnych typów użytkowników

Podczas projektowania interfejsu nie warto myśleć wyłącznie o „użytkowniku aplikacji”.

W projekcie AGROSTRATEG z systemu mogą korzystać osoby pełniące zupełnie różne role.

Rolnik chce szybko dowiedzieć się, czy sytuacja wymaga jego reakcji.

Osoba odpowiedzialna za badania potrzebuje dostępu do surowych danych i możliwości ich eksportowania.

Serwisant musi sprawdzić, kiedy urządzenie ostatnio przesłało pomiar i jaki jest jego stan.

Administrator zarządza kontami, uprawnieniami oraz konfiguracją urządzeń.

Kierownik projektu może potrzebować podsumowania rezultatów pilotażu i informacji pozwalających ocenić osiągnięcie założonych parametrów.

Próba umieszczenia wszystkich tych informacji na jednym ekranie prowadzi zwykle do skomplikowanego panelu, którego nikt nie używa wygodnie.

Lepiej projektować interfejs wokół konkretnych ról i decyzji podejmowanych przez każdą z nich.

W projekcie B+R trzeba mierzyć więcej niż dostępność aplikacji

Standardowe testy oprogramowania pozostają potrzebne, ale nie wystarczą.

Jeżeli rozwiązanie ma udowodnić określoną hipotezę lub osiągnąć założone parametry, system powinien od początku gromadzić dane pozwalające je później zweryfikować.

Przykładowo celem projektu może być ograniczenie zużycia wody przy zachowaniu określonego poziomu produkcji.

Samo uruchomienie automatycznego systemu nawadniania nie potwierdza osiągnięcia tego rezultatu.

Trzeba móc porównać zużycie wody, warunki środowiskowe, sposób działania systemu i rezultat produkcyjny z odpowiednim punktem odniesienia.

Podobnie wygląda sytuacja z algorytmami.

Zamiast wpisywać jako rezultat „opracowanie algorytmu wykrywania chorób roślin”, warto mieć mierzalną metodę oceny jego skuteczności.

NCBR zwraca uwagę na rolę precyzyjnie zdefiniowanych kamieni milowych, które powinny umożliwiać obiektywną weryfikację postępu prac i osiąganych parametrów.

Warstwa IT może bardzo pomóc w zbieraniu danych potrzebnych do takiej oceny.

Bezpieczeństwo urządzeń IoT trzeba zaplanować od początku

Urządzenia IoT często pracują przez wiele lat i znajdują się poza kontrolowanym środowiskiem przedsiębiorstwa.

Dlatego każde urządzenie powinno mieć własną tożsamość i możliwość bezpiecznego uwierzytelnienia w systemie.

Trzeba również przewidzieć sposób aktualizacji oprogramowania urządzeń, zarządzanie ich konfiguracją oraz możliwość odebrania dostępu konkretnemu urządzeniu.

Warto założyć również, że fizyczny dostęp do sensora może mieć osoba nieuprawniona.

Backend nie powinien więc ufać urządzeniu wyłącznie dlatego, że przesłało wiadomość w odpowiednim formacie.

Osobnym zagadnieniem jest bezpieczeństwo samej aplikacji: konta użytkowników, role, uprawnienia, historia operacji, szyfrowanie transmisji, kopie bezpieczeństwa oraz monitoring infrastruktury.

Znacznie łatwiej uwzględnić te wymagania w architekturze od początku niż dodawać je tuż przed produkcyjnym wdrożeniem.

Jak przygotować specyfikację dla wykonawcy IT?

Nie trzeba przygotowywać kilkusetstronicowej dokumentacji technicznej przed pierwszym spotkaniem z software house’em.

Znacznie bardziej przydatny jest konkretny opis działania systemu.

Warto zebrać w jednym miejscu informacje o urządzeniach i sensorach, sposobie komunikacji, przewidywanej liczbie urządzeń podczas badań i po wdrożeniu, częstotliwości pomiarów, rolach użytkowników, zewnętrznych integracjach, wymaganych alertach, sposobie wykorzystania AI, potrzebie działania offline oraz planowanej skali rozwiązania.

Bardzo pomocne jest również rozdzielenie elementów już ustalonych od tych, które dopiero mają zostać zweryfikowane w ramach prac B+R.

Jeżeli określony sensor został już wybrany, wykonawca powinien o tym wiedzieć.

Jeżeli jednym z celów badań jest dopiero wybór najlepszego sposobu wykonywania pomiaru, architektura musi pozwolić na eksperymentowanie.

Dobry wykonawca nie powinien ograniczać się do wyceny funkcji aplikacji. Powinien najpierw zrozumieć cały przepływ danych oraz zależności pomiędzy sprzętem, komunikacją i software’em.

Kiedy zaangażować software house?

Najlepiej zanim wszystkie decyzje dotyczące urządzeń i komunikacji staną się nieodwracalne.

Częstym błędem jest stworzenie kompletnej części sprzętowej, a następnie przekazanie jej zespołowi IT z poleceniem „teraz potrzebujemy do tego aplikacji”.

Może się wtedy okazać, że urządzenie przesyła za mało informacji, komunikacja nie pozwala na wymagane operacje, format danych utrudnia późniejszą analizę albo firmware nie przewiduje mechanizmu potrzebnego do zarządzania urządzeniami.

Wspólne zaprojektowanie kontraktu komunikacyjnego i przepływu danych na początku projektu pozwala uniknąć wielu takich sytuacji.

Software house nie musi przy tym projektować elektroniki.

Może współpracować z zespołem odpowiedzialnym za hardware i przejąć odpowiedzialność od momentu, w którym dane opuszczają urządzenie: komunikację z platformą, backend, przechowywanie danych, algorytmy, API oraz aplikacje użytkowników.

Jak podzielić rozwój systemu na etapy?

W dużym projekcie lepiej unikać sytuacji, w której wszystkie elementy powstają przez kilkanaście miesięcy niezależnie i zostają połączone dopiero przed końcowym testem.

Pierwsza integracja powinna nastąpić możliwie wcześnie.

Już prosty prototyp może przesłać rzeczywisty pomiar z sensora do backendu i wyświetlić go w podstawowym panelu.

Kolejne iteracje rozbudowują pionowy fragment systemu: dodają urządzenia, reguły, analizę danych, interfejs użytkownika i funkcje związane z eksperymentami.

Takie podejście pozwala znacznie wcześniej znaleźć problemy na styku hardware’u, łączności i oprogramowania.

W IT Hero proces tworzenia oprogramowania rozpoczynamy od odkrywania produktu i wymagań, następnie przygotowujemy projekt interfejsu, przechodzimy do developmentu, a po wdrożeniu zapewniamy dalszy support. Przy projekcie IoT etap discovery można rozszerzyć o projekt architektury urządzeń, komunikacji oraz przepływu danych.

Architektura powinna uwzględniać wdrożenie już podczas prac B+R

To jedna z najważniejszych zasad.

Projekt może rozpocząć się od kilku urządzeń działających w jednym gospodarstwie. Jeśli rezultat ma później zostać wykorzystany komercyjnie albo wdrożony na większą skalę, warto już wtedy wiedzieć, co wydarzy się przy 100, 1000 lub 10 000 urządzeń.

Nie oznacza to, że pierwszy prototyp powinien kosztować tyle co gotowa platforma.

Chodzi o podejmowanie decyzji, które nie zamkną dalszej drogi rozwoju.

Dotyczy to sposobu identyfikacji urządzeń, struktury danych, komunikacji, modelu uprawnień, sposobu konfiguracji, monitoringu infrastruktury i rozdzielenia poszczególnych elementów systemu.

Dzięki temu PoC pozostaje eksperymentem, ale jego wyniki mogą stać się fundamentem produktu, zamiast zostać wyrzucone i napisane ponownie po zakończeniu badań.

AGROSTRATEG i rolnictwo cyfrowe – technologia jest częścią produktu, nie dodatkiem

Program AGROSTRATEG został zaprojektowany z myślą o rozwiązaniach, które mają poprawiać efektywność polskiego sektora rolnego. Jednym z czterech głównych obszarów programu jest właśnie rolnictwo cyfrowe – wykorzystanie technologii oraz analizy danych do optymalizacji produkcji roślinnej i zwierzęcej.

W takich projektach część IT nie powinna być traktowana jako panel dodawany na końcu do urządzenia opracowanego w ramach B+R.

To zwykle właśnie oprogramowanie łączy wszystkie elementy rozwiązania.

Sensor generuje dane. Łączność pozwala je przesłać. Backend zamienia strumień pomiarów w uporządkowaną informację. Algorytmy pozwalają wyciągać wnioski. Aplikacja przekazuje je osobie, która może na tej podstawie podjąć decyzję.

Dopiero cały ten łańcuch tworzy produkt.

Realizujesz część IT lub IoT projektu AGROSTRATEG?

IT Hero tworzy aplikacje webowe i mobilne oraz rozwiązania IoT wykorzystujące między innymi LoRaWAN i NB-IoT. Firma działa od 2021 roku i ma siedzibę w Toruniu.

Możemy dołączyć do projektu jako zespół odpowiedzialny za jego warstwę programistyczną: architekturę systemu, komunikację z urządzeniami, backend IoT, przechowywanie i przetwarzanie danych oraz aplikacje webowe i mobilne.

Możemy również rozpocząć współpracę od konsultacji technicznej i wspólnie przejść przez architekturę planowanego rozwiązania.

Jeżeli masz już opis projektu, urządzenie lub pierwszą koncepcję systemu, prześlij nam materiały. Na pierwszym spotkaniu możemy przeanalizować przepływ danych, główne komponenty oraz miejsca, które będą wymagały decyzji technologicznych.

Porozmawiajmy o części IT Twojego projektu AGROSTRATEG.