Witaj, Habro! Nasz zespół monitoruje maszyny i różne instalacje na terenie całego kraju. Zasadniczo dajemy producentowi możliwość uniknięcia konieczności ponownego wysyłania inżyniera, gdy „och, wszystko jest zepsute”, ale w rzeczywistości wystarczy nacisnąć jeden przycisk. Lub gdy zepsuł się nie na sprzęcie, ale w pobliżu.
Podstawowy problem jest następujący. Tutaj produkujesz jednostkę do krakingu oleju, obrabiarkę do budowy maszyn lub inne urządzenie dla zakładu. Co do zasady sama sprzedaż jest możliwa niezwykle rzadko: najczęściej jest to umowa na dostawy i usługi. Oznacza to, że gwarantujesz, że sprzęt będzie działał bez przerw przez 10 lat, a za przerwy odpowiadasz finansowo lub zapewniasz rygorystyczne umowy SLA lub coś podobnego.
W rzeczywistości oznacza to, że musisz regularnie wysyłać inżyniera na miejsce. Jak pokazuje nasza praktyka, od 30 do 80% wyjazdów jest niepotrzebnych. Pierwszy przypadek - możliwe byłoby ustalenie, co się stało na odległość. Lub poproś operatora, aby nacisnął kilka przycisków i wszystko będzie działać. Drugi przypadek to „szare” schematy. Dzieje się tak wtedy, gdy inżynier wychodzi, planuje wymianę lub skomplikowaną pracę, a następnie dzieli wynagrodzenie na pół z kimś z fabryki. Albo po prostu cieszy się wakacjami ze swoją kochanką (prawdziwy przypadek) i dlatego lubi częściej wychodzić. Roślinie to nie przeszkadza.
Zainstalowanie monitoringu wymaga modyfikacji sprzętu z urządzeniem do transmisji danych, samej transmisji, pewnego rodzaju jeziora danych do ich przechowywania, analizowania protokołów i środowiska przetwarzania z możliwością przeglądania i porównywania wszystkiego. Cóż, w tym wszystkim są niuanse.
Dlaczego nie możemy obejść się bez zdalnego monitorowania?
To banalnie drogie. Podróż służbowa dla jednego inżyniera - co najmniej 50 tysięcy rubli (samolot, hotel, zakwaterowanie, dieta). Poza tym nie zawsze jest możliwe rozstanie, a ta sama osoba może być potrzebna w różnych miastach.
- W Rosji dostawca i konsument są prawie zawsze dość daleko od siebie. Kiedy sprzedajesz produkt na Syberię, nie wiesz o nim nic poza tym, co powie ci dostawca. Ani jak to działa, ani w jakich warunkach jest używane, ani tak naprawdę, kto nacisnął który przycisk krzywymi rękami – obiektywnie nie masz tej informacji, możesz to poznać jedynie ze słów konsumenta. To bardzo utrudnia konserwację.
- Bezzasadne odwołania i roszczenia. Oznacza to, że Twój klient korzystający z Twojego produktu może w każdej chwili zadzwonić, napisać, złożyć reklamację i powiedzieć, że Twój produkt nie działa, jest zły, jest zepsuty, przyjdź pilnie i napraw. Jeśli masz szczęście i nie chodzi tylko o to, że „materiały eksploatacyjne nie zostały napełnione”, to nie na próżno wysyłałeś specjalistę. Często zdarza się, że użyteczna praca zajęła mniej niż godzinę, a cała reszta – przygotowanie podróży służbowej, przelotów, noclegu – wszystko to wymagało dużo czasu inżyniera.
- Istnieją wyraźnie bezpodstawne roszczenia i aby to udowodnić, należy wysłać inżyniera, sporządzić raport i udać się do sądu. W rezultacie proces się opóźnia, co nie przynosi nic dobrego ani klientowi, ani Tobie.
- Do sporów dochodzi na skutek tego, że np. klient nieprawidłowo obsługiwał produkt, klient z jakiegoś powodu ma do Ciebie pretensje i nie twierdzi, że Twój produkt nie działał prawidłowo, a nie w trybach określonych w specyfikacji technicznej i w paszporcie. Jednocześnie nie można nic z tym zrobić, albo można, ale z trudem, jeśli np. Twój produkt w jakiś sposób loguje i rejestruje te tryby. Awarie z winy klienta - to zdarza się cały czas. Miałem przypadek, gdy kosztowna niemiecka maszyna portalowa zepsuła się w wyniku zderzenia ze słupem. Operator nie ustawił go na zero, w wyniku czego maszyna zatrzymała się w tym miejscu. Co więcej, klient powiedział dość wyraźnie: „Nie mamy z tym nic wspólnego”. Jednak informacje zostały zarejestrowane i można było sprawdzić te logi i dowiedzieć się, który program sterujący został użyty i w wyniku czego doszło do tej kolizji. Dzięki temu dostawca zaoszczędził bardzo duże koszty napraw gwarancyjnych.
- Wspomniane „szare” schematy to spisek z usługodawcą. Cały czas do klienta przyjeżdża ten sam serwisant. Mówią mu: „Słuchaj, Kola, zróbmy to tak, jak chcesz: piszesz, że tu wszystko jest zepsute, dostaniemy odszkodowanie, albo przyniesiesz do naprawy jakiś zamek błyskawiczny. Zrealizujemy to wszystko po cichu, podzielimy się pieniędzmi”. Pozostaje albo uwierzyć, albo w jakiś sposób wymyślić jakieś skomplikowane sposoby sprawdzenia tych wszystkich wniosków i potwierdzeń, co nie dodaje ani czasu, ani nerwów, a nic dobrego się w tym nie dzieje. Jeśli wiesz, jak serwisy samochodowe radzą sobie z oszustwami gwarancyjnymi i jak dużą złożoność powoduje to w procesach, z grubsza rozumiesz problem.
Cóż, urządzenia nadal zapisują logi, prawda? Jaki jest problem?
Problem polega na tym, że jeśli dostawcy mniej więcej rozumieją, że dziennik musi być gdzieś stale zapisywany (lub rozumieli to przez ostatnie kilka dekad), to kultura nie poszła dalej. Dziennik jest często potrzebny do analizy przypadków kosztownych napraw – niezależnie od tego, czy był to błąd operatora, czy rzeczywista awaria sprzętu.
Aby podnieść logi często trzeba fizycznie podejść do sprzętu, otworzyć jakąś obudowę, odsłonić złącze serwisowe, podłączyć do niego kabel i wyjąć pliki z danymi. Następnie uparcie chwytaj je przez kilka godzin, aby uzyskać obraz sytuacji. Niestety, dzieje się to prawie wszędzie (no cóż, albo mam jednostronny punkt widzenia, ponieważ współpracujemy właśnie z tymi branżami, w których dopiero ustalany jest monitoring).
Naszymi głównymi klientami są producenci sprzętu. Zazwyczaj zaczynają myśleć o przeprowadzeniu pewnego rodzaju monitorowania po poważnym incydencie lub po prostu przeglądając swoje rachunki za podróże za cały rok. Jednak najczęściej mówimy o poważnej porażce polegającej na utracie pieniędzy lub reputacji. Postępowi przywódcy, którzy myślą o „cokolwiek się stanie”, są rzadkością. Faktem jest, że menedżer zwykle otrzymuje stary „park” umów serwisowych i nie widzi sensu instalowania czujników na nowym sprzęcie, ponieważ będą one potrzebne dopiero za kilka lat.
Generalnie w pewnym momencie pieczony kogut nadal gryzie i przychodzi czas na modyfikacje.
Sam transfer danych nie jest bardzo straszny. Sprzęt zazwyczaj posiada już czujniki (lub są one montowane dość szybko), dodatkowo logi są już zapisywane i odnotowywane są zdarzenia serwisowe. Wystarczy, że zaczniesz go wysyłać. Powszechną praktyką jest wkładanie jakiegoś modemu, na przykład z wbudowaną kartą SIM, bezpośrednio do urządzenia od aparatu rentgenowskiego do automatycznego siewnika i wysyłanie danych telemetrycznych przez sieć komórkową. Miejsca, w których nie ma zasięgu sieci komórkowej, są zwykle dość odległe i w ostatnich latach stały się rzadkie.
I wtedy zaczyna się to samo pytanie, co poprzednio. Tak, są już logi. Ale trzeba je gdzieś odłożyć i jakoś przeczytać. Ogólnie rzecz biorąc, potrzebny jest jakiś system wizualizacji i analizy incydentów.
A potem pojawiamy się na scenie. A dokładniej, często pojawiamy się wcześniej, bo menadżerowie dostawców przyglądają się temu, co robią ich koledzy i od razu zwracają się do nas po poradę w zakresie doboru sprzętu do przesyłania telemetrii.
Nisza rynkowa
Na Zachodzie sposób rozwiązania tej sytuacji sprowadza się do trzech opcji: ekosystemu Siemensa (bardzo drogiego, potrzebnego przy bardzo dużych jednostkach, zwykle jak turbiny), samodzielnie napisanych mandułach lub pomocy jednego z lokalnych integratorów. W rezultacie, kiedy to wszystko trafiło na rynek rosyjski, powstało środowisko, w którym istniał Siemens z jego fragmentami ekosystemu, Amazon, Nokia i kilka lokalnych ekosystemów, takich jak rozwój 1C.
Weszliśmy na rynek jako ogniwo ujednolicające, które pozwala nam zbierać dowolne dane z dowolnych urządzeń korzystających z dowolnych (no dobra, prawie dowolnych, mniej lub bardziej nowoczesnych) protokołów, przetwarzać je razem i pokazywać osobie w dowolnej wymaganej formie: do tego mamy fajne pakiety SDK dla wszystkich środowisk programistycznych i projektantów wizualnych interfejsów użytkownika.
Dzięki temu możemy zebrać wszystkie dane z urządzenia producenta, przechowywać je w pamięci na serwerze i tam zamontować panel monitorujący z alertami.
Tak to wygląda (tutaj klient zrobił też wizualizację przedsiębiorstwa, to jest kilka godzin w interfejsie):
A tam wykresy ze sprzętu:
Alerty wyglądają następująco: na poziomie maszyny, jeśli została przekroczona siła działająca na korpus wykonawczy lub doszło do kolizji, konfigurowany jest zestaw parametrów, a system poinformuje dział lub służby naprawcze o ich przekroczeniu.
Cóż, najtrudniejszą rzeczą jest przewidzenie awarii węzłów na podstawie ich stanu w celu zapobiegania. Jeśli rozumiesz zasoby każdego z węzłów, możesz znacznie obniżyć koszty w przypadku tych umów, w których obowiązuje opłata za przestoje.
Streszczenie
Ta historia brzmiałaby dość prosto: cóż, zdaliśmy sobie sprawę, że musimy przesyłać dane, monitorować i analizować, więc wybraliśmy dostawcę i go wdrożyliśmy. No to tyle, wszyscy są zadowoleni. Jeśli mówimy o samodzielnie napisanych systemach w naszej własnej fabryce, to, co dziwne, systemy szybko stają się zawodne. Mówimy o banalnej utracie logów, niedokładnych danych, błędach w gromadzeniu, przechowywaniu i odbiorze. Rok lub dwa po instalacji zaczynają być usuwane stare logi, co również nie zawsze kończy się dobrze. Choć jest praktyka - z jednej maszyny rocznie pobiera się 10 GB. Rozwiązuje się to na pięć lat, kupując kolejny dysk twardy za 10 tysięcy rubli... W pewnym momencie okazuje się, że to nie sam sprzęt transmitujący jest najważniejszy, ale system, który pozwala na analizę otrzymanych danych. Ważna jest wygoda interfejsu. Jest to generalnie problem wszystkich systemów przemysłowych: szybkie zrozumienie sytuacji nie zawsze jest łatwe. Ważne jest, ile danych jest widocznych w systemie, ilość parametrów z węzła, zdolność systemu do pracy z dużym wolumenem i ilością danych. Konfigurowanie dashboardów, wbudowany model samego urządzenia, edytor scen (do rysowania makiet produkcyjnych).
Podajmy kilka przykładów, co to daje w praktyce.
- Oto światowy producent przemysłowych urządzeń chłodniczych wykorzystywanych przede wszystkim w sieciach handlowych. 10% przychodów firmy pochodzi ze świadczenia usług serwisowych jej produktów. Trzeba obniżyć koszty usług i w ogóle dać możliwość normalnego zwiększania dostaw, bo jeśli będziemy sprzedawać więcej, to istniejący system usług sobie nie poradzi. Połączyliśmy się bezpośrednio z platformą jednego centrum serwisowego, zmodyfikowaliśmy kilka modułów pod potrzeby tego konkretnego klienta i uzyskaliśmy 35% redukcję kosztów podróży dzięki temu, że dostęp do informacji serwisowych umożliwia identyfikację przyczyn awarii bez konieczności wizyty inżyniera serwisu. Analiza danych w długich okresach czasu – przewiduj stan techniczny i w razie potrzeby szybko przeprowadzaj konserwację na podstawie stanu. Jako bonus wzrosła szybkość reakcji na żądania: jest mniej wycieczek terenowych, a inżynierowie mogą szybciej wykonywać zadania.
- Firma inżynierii mechanicznej, producent pojazdów elektrycznych używanych w wielu miastach Federacji Rosyjskiej i WNP. Jak wszyscy chcą ograniczać koszty, a jednocześnie przewidywać stan techniczny miejskiego taboru trolejbusowego i tramwajowego, aby w odpowiednim czasie powiadomić służby techniczne. Połączyliśmy i stworzyliśmy algorytmy gromadzenia i przesyłania danych technicznych z taboru do jednego centrum sytuacyjnego (algorytmy są wbudowane bezpośrednio w system sterowania napędem i współpracują z danymi magistrali CAN). Zdalny dostęp do danych o stanie technicznym, w tym dostęp w czasie rzeczywistym do zmieniających się parametrów (prędkość, napięcie, przesył odzyskanej energii itp.) w trybie „oscyloskopu”, umożliwił zdalny dostęp do aktualizacji oprogramowania. Efektem jest redukcja kosztów podróży o 50%: bezpośredni dostęp do informacji serwisowych pozwala na identyfikację przyczyn awarii bez konieczności wizyty serwisanta, a analiza danych w długich odstępach czasu pozwala przewidzieć stan techniczny i w razie potrzeby szybko przeprowadzić konserwację „stanową”, obejmującą obiektywną analizę sytuacji awaryjnych. Realizacja umów o przedłużonym cyklu życia w pełnej zgodności z wymaganiami Klienta i terminowo. Zgodność z wymaganiami specyfikacji technicznych operatora, a także zapewnienie mu nowych możliwości w zakresie monitorowania charakterystyki obsługi konsumenta (jakość klimatyzacji, przyspieszanie/hamowanie itp.).
- Trzeci przykład to gmina. Musimy oszczędzać energię elektryczną i poprawiać bezpieczeństwo obywateli. Połączyliśmy jedną platformę do monitorowania, zarządzania i gromadzenia danych o podłączonym oświetleniu ulicznym, zdalnie zarządzając całą infrastrukturą oświetlenia publicznego i obsługując ją z jednego panelu sterowania, dostarczając rozwiązania do poniższych zadań. Funkcje: zdalne przyciemnianie lub włączanie/wyłączanie świateł, indywidualnie lub grupowo, automatyczne powiadamianie służb miejskich o awariach punktów oświetleniowych w celu efektywniejszego planowania konserwacji, dostarczanie danych o zużyciu energii w czasie rzeczywistym, udostępnianie potężnych narzędzi analitycznych do monitorowania i poprawy oświetlenia ulicznego system oparty na Big Data, dostarczający dane o ruchu drogowym, stanie klimatyzacji, integracja z innymi podsystemami Smart City. Rezultaty - zmniejszenie zużycia energii na oświetlenie uliczne nawet o 80%, zwiększenie bezpieczeństwa mieszkańców poprzez zastosowanie inteligentnych algorytmów sterowania oświetleniem (osoba idąca ulicą - włącz dla niej światło, osoba na przejściu - włącz jaśniej oświetlenie tak, aby było go widać z daleka), świadczenie na rzecz miasta usług dodatkowych (ładowanie pojazdów elektrycznych, dostarczanie treści reklamowych, monitoring wizyjny itp.).
Właściwie to co chciałem powiedzieć: dziś, mając gotową platformę (na przykład naszą), bardzo szybko i łatwo można skonfigurować monitoring. Nie wymaga to zmian w sprzęcie (lub minimalnych, jeśli nadal nie ma czujników i transmisji danych), nie wymaga kosztów wdrożenia i osobnych specjalistów. Wystarczy przestudiować temat, poświęcić kilka dni na zrozumienie, jak to działa, a kilka tygodni na zatwierdzenia, uzgodnienie i wymianę danych o protokołach. A potem będziesz mieć dokładne dane ze wszystkich urządzeń. A wszystko to można zrobić na terenie całego kraju przy wsparciu integratora Technoserv, czyli gwarantujemy dobry poziom niezawodności, który nie jest typowy dla startupu.
W kolejnym poście pokażę jak to wygląda od strony dostawcy na przykładzie jednej realizacji.
Źródło: www.habr.com