Sposób na zablokowane funkcjonalności ISOBUS.

Od wielu lat problemem rolników i firm modernizujących opryskiwacze, jest konieczność montażu w ciągnikach kilku sterowników komputerowych - dla każdej maszyny osobno, nawet jeśli komputery i sterowane nimi urządzenia pracują w standardzie ISOBUS. Sprzedawcy dość często narzucają takie rozwiązania swoim klientom pomimo wiedzy, że w dobie technologii ISOBUS oraz wirtualnych terminali opracowywanych przez producentów maszyn - komputer, a właściwie wyświetlacz - mógłby być zastosowany tylko jeden. Następnym problemem i dużym wyzwaniem dla użytkowników jest blokowanie funkcji ISOBUS komputerów i maszyn przez ich producentów i oferowanie odblokowania za dodatkową opłatą.

Nad takimi rozwiązaniami, aby umożliwić rolnikom swobodną pracę z ISOBUS pracuje prezes firmy Rootsey - Paweł Rutka. Jednym z nich jest wirtualny terminal ISOBUS (tzw. virtual terminal). VT to oprogramowanie pozwalające na sterownie zdecydowaną większością maszyn i narzędzi rolniczych poprzez zaimplementowanie go do komputerów wyposażonych w ISOBUS. Dzięki temu oprogramowaniu możemy posługiwać się np. jednym komputerem (niezależnie od marki), do obsługi różnych maszyn, różnych marek. System ISOBUS w założeniu umożliwić ma zarządzanie różnymi maszynami jednym urządzeniem sterującym, w tym także sterowanie/ maszynami z terminali ciągnikowych, poprzez generowany przez agregowane z nim maszyny tzw. virtual terminal. VT to rodzaj „nakładki” na ciągnikowy wyświetlacz, którą tworzy komputerowy sterownik maszyny, a wywołuje podłączenie maszyny z gniazdem komputera ciągnika. Taką nakładkę można by, w uproszczeniu, nazwać dziś w sposób „tabletowy” – aplikacją.

Jednym z rozwiązań nad którym pracuje prezes Paweł Rutka jest oprogramowanie, które będzie w stanie „wgryźć się” w protokół CAN, aby przetłumaczyć go i spowodować nie tylko lepsze porozumiewanie się pomiędzy maszynami i komputerami różnych marek (mimo organizacji AEF utworzonej w tym celu i dużych starań firm rolniczych – nie zawsze to działa), ale będzie także w stanie, uaktywnić funkcje dotychczas zablokowane przez danego producenta urządzenia.

Jak to działa?

Wyobraźmy sobie sposób działania magistrali CAN. Jedną z funkcji i zasad jej działania jest komunikacja pomiędzy wszelkimi urządzeniami podłączonymi do magistrali. Wymiana informacji musi być zawsze poprzedzona „przedstawieniem się” pomiędzy współpracującymi w magistrali CAN urządzeniami, nie mogą one być anonimowe. Załóżmy, że wpinamy w maszynową sieć czujnik, który będzie wysyłał informację o poziomie paliwa lub temperaturze płynu w chłodnicy. Załóżmy, że komputer „pyta” czujnik o pomiar. Czyli komputer ECU wysyła informację, że jest komputerem ECU i prosi o odesłanie danych pomiarowych do siebie. - Magistrala CAN jest tak skonstruowana, że wiele wpiętych urządzeń oraz czujników może wzajemnie wymieniać się informacjami w czasie rzeczywistym. W „systemie” CAN - każdy z każdym wymienia informacje i - co ciekawe - nie ma błędów – skrótowo objaśnia działanie magistrali Paweł Rutka. ECU musi także przedstawiając się podać swoją markę (np. XYZ) i w momencie kiedy wysyła żądanie podania np. temperatury, to czujnik wie z kim „rozmawia” i wysyła informację o sobie i wyniku pomiaru (jestem czujnikiem marki AAA i wysyłam ci pomiar). Wtedy ECU 'wie' jaka jest np. temperatura płynu w chłodnicy i wysyła tę informację do wyświetlacza na pulpicie pojazdu czy maszyny itp. Dzisiejszy problem z komputerami maszyn rolniczych polega na , specyficznych algorytmach jednostek zarządzających posiadających jakby filtry, które zawężają i ograniczają obsługę np. czujników spoza dedykowanych producentów, określonych numerów ID (numerów seryjnych), czy też określoną funkcjonalność (np. GPS, ...). Dlatego komputer danej marki, niekoniecznie jest w stanie przyjąć informację od czujnika czy skorzystać z wyświetlacza innej marki. Zatem mamy sytuację, że taki komputer ma filtr nie tylko na markę, ale i na funkcjonalność, chyba że za nią zapłacimy – to wtedy dostaniemy kody do odblokowania danej funkcji. „Mam pomysł na to, aby legalnie komputer czy virtual terminal był w stanie dogadywać się z czujnikami i innymi podzespołami róznych marek. Komputer ma zainstalowany system z moją aplikacją do której dopisuję sterownik rozsiewacza, siewnika, opryskiwacza itp. Rolnik po wejściu do ciągnika i podjęciu decyzji, że dziś pracuje z rozsiewaczem, klika funkcję rozsiewacza w mojej aplikacji i może pracować bez powyżej opisywanych uciążliwości czy komplikacji. Tak samo z innymi funkcjami z ISOBUS, pochodzącymi od różnych marek. Wyobrażam sobie, że może być jeden terminal, w którym możemy mieć wszystkie definicje maszyny, pól, itp. w chmurze, czyli możemy mieć kilka komputerów w jednym” – reasumuje swoje dążenia Paweł Rutka.

Oprogramowanie systemów w ISOBUS to język tzw. wysokiego poziomu. Aktualnie Paweł Rutka opracowuje takie rozwiązania dla rolniczego sterowania ISOBUS. Powstają one na podstawie nie tylko gotowych bibliotek, ale również własnych, które zapewniają wysoką łączność i skuteczność pracy systemów opartych na ISOBUS z urządzeniami marki Rootsey i Quartmann. Ten „wysokopoziomowy” język oprogramowania wykorzystuje m. in. nawigacja Quartmann TOO-NAV GP-10. Do tego języka Paweł Rutka dodaje różne opcje tłumaczenia protokołu CAN (używanego w systemach CAN BUS). Warto zauważyć, że CAN BUS jest usystematyzowanym i ustandaryzowanym pod kątem rolniczym protokołem, który istnieje pod nazwą ISOBUS.