Integracja sprzętu legacy do bowlingu: wyzwania i rozwiązanie

# Inżynieria odwrotna pinsettera: jak zintegrowaliśmy stare wyposażenie do bowlingu z aplikacją mobilną

Po trzech latach bezskutecznych prób wyciągnięcia danych z mechanicznych maszyn do bowlingu (pinsetterów), zespół Brooklyn Bowl przeszedł do inżynierii odwrotnej krytycznego bloku digitalizacji sensorów. Główne przeszkody to proprietary interfejs, przestarzały stos technologii i brak dokumentacji. W tym artykule przeanalizujemy architekturę systemu, przyczyny niepowodzenia standardowych metod integracji oraz rozwiązanie, które mimo braku elegancji, działa.

Architektura pinsettera i przepływ danych

Mechaniczny pinsetter to skomplikowana maszyna przypominająca system automatycznego ładowania czołgu. Po rzucie kulą uruchamia się sensor optyczny, który rejestruje przejście obiektu. Następnie opuszcza się rama pomiarowa z otworami, sprawdzająca obecność kręgli w każdej pozycji za pomocą fotodiod lub sond kontaktowych. Dane z sensorów trafiają do bloku NextGen, który przekształca je w zdarzenia gry (np. liczbę zbitych kręgli). Ten blok jest podłączony do serwera Dell OptiPlex 3020 (z 2014 roku) przez proprietary interfejs szeregowy oparty na pętli prądowej. Serwer przetwarza status gry i wyświetla wyniki na monitorach nad torami.

Ważne jest zrozumienie, że sama maszyna nie digitalizuje sygnałów — robi to zewnętrzny blok NextGen. Dane są przekazywane w surowym formacie hex bez standardowego protokołu. System nie wspiera nowoczesnych technologii typu IoT czy MQTT, co czyni integrację z zewnętrznymi systemami (np. aplikacją mobilną) ekstremalnie trudną.

Trzy fundamentalne problemy integracji

Próby wyciągnięcia danych napotkały trzy nie do pokonania bariery:

• Ograniczenia komercyjne Brunswick i AMF. Producenci celowo blokują integracje zewnętrzne, by monopolizować sprzedaż dodatkowych modułów (np. do wyświetlania wyników na stronie czy integracji z kartami klubowymi). Jakikolwiek obejście wymaga zakupu licencji, co czyni rozwiązanie nieopłacalnym ekonomicznie.

• Przeżyty stos technologiczny. Serwer Dell działa z bazami danych FoxPro i Sybase SQL Anywhere. FoxPro blokuje bazę podczas zapisu, co powoduje awarie oprogramowania przy jednoczesnym odczycie. Dla Sybase potrzebne są sterowniki ODBC, a dane logowania są przechowywane w binarnych plikach Brunswick, co uniemożliwia dostęp bez dekompilacji.

• Brak mechanizmu push i niestabilność danych. System nie wysyła danych na zdarzenia, lecz jest stale sondowany przez serwer. Co więcej, status gry może być korygowany: np. najpierw rejestrowane jest zbicie dwóch kręgli, a po chwili wszystkich dziesięciu. Te korekty przychodzą asynchronicznie, powodując rozbieżności w danych i uniemożliwiając stworzenie niezawodnego strumienia zdarzeń.

Nieudane podejścia: analiza porażek

Zespół i zaproszeni inżynierowie przetestowali cztery metody, wszystkie okazały się niewykonalne w warunkach produkcyjnych:

• Odczyt bazy danych na serwerze Dell. Próby połączenia z FoxPro lub Sybase prowadziły do konfliktów blokad i awarii głównego oprogramowania. Nawet przy udanym odczycie dane aktualizowały się z opóźnieniem, nieodpowiednim dla aplikacji mobilnej w czasie rzeczywistym.

• Integracja z blokiem NextGen. Bezpośrednie podłączenie do pętli prądowej dało dostęp do surowych danych hex, ale bez dokumentacji ich dekodowanie było zagadką. Analiza ruchu pokazała, że format danych zmienia się w zależności od stanu maszyny, a korekty statusu tworzyły „szum” w strumieniu.

• Wizja komputerowa nad torem. Instalacja kamery i rozpoznawanie pozycji kręgli za pomocą OpenCV wymagała idealnego oświetlenia i kalibracji. W warunkach rzeczywistych (ruch graczy, cienie, odblaski) dokładność spadała poniżej 70%, co czyniło rozwiązanie nieakceptowalnym.

• Pełna przepisanie NextGen. Próba emulacji bloku okazała się technicznie złożona: dla poprawnego działania trzeba było odtworzyć wszystkie niuanse interakcji z pinsetterem, w tym obsługę korekt statusu. Projekt zatrzymano na etapie prototypu z powodu zbyt wysokiej złożoności.

Nie testowano metod typu OCR z monitorów przez splitter HDMI czy emulacja drukarki — ich skuteczność oceniono jako niską ze względu na dodatkowe punkty awarii.

Działające rozwiązanie: wymiana bloku digitalizacji

Aktualna implementacja opiera się na inżynierii odwrotnej bloku NextGen. Zamiast próby integracji z istniejącym systemem, inżynierowie stworzyli własny moduł podłączany bezpośrednio do sensorów pinsettera. Ten moduł:

• Zbiera sygnały analogowe z fotodiod i sond kontaktowych.
• Digitalizuje dane z częstotliwością 100 Hz, filtrując fałszywe wyzwolenia.
• Tworzy zdarzenia w formacie JSON i wysyła je na serwer przez MQTT.

Kluczową zaletą jest izolacja od legacy systemu: nowy moduł nie komunikuje się z Dell ani NextGen, omijając wszystkie ograniczenia. Wadą jest konieczność fizycznej modyfikacji każdej maszyny, co wymaga zatrzymania toru na 2-3 godziny. Jednak dla sieci 12 bowlingów Brooklyn Bowl okazało się to optymalnym rozwiązaniem.

Co ważne: kluczowe wnioski dla inżynierów

• Nie marnujcie czasu na obchodzenie blokad komercyjnych. Jeśli producent celowo ogranicza dostęp (jak Brunswick), skupcie się na izolacji kluczowych komponentów, a nie integracji z legacy systemem.

• Surowe dane sensorów to wasz najlepszy przyjaciel. W systemach bez cyfrowego interfejsu bezpośrednie podłączenie do sensorów analogowych jest często prostsze niż dekodowanie proprietary protokołów.

• Inżynieria odwrotna wymaga cierpliwości. Analiza ruchu w pętli prądowej zajęła 6 miesięcy, ale pozwoliła zidentyfikować wzorce w danych hex, które stały się podstawą filtracji korekt statusu.

To rozwiązanie nie jest idealne, ale działa. Dla innych właścicieli bowlingów z podobnym sprzętem chętnie podzielimy się doświadczeniem — kontakty na końcu artykułu.

— Editorial Team