Protokół do szeregowego portu RS-232/RS-485

Chciałbym ulepszyć połączenie z stm32 ale bez zmiany sprzętu.
To urządzenie jest połączone przez RS-232/RS-485 z media konwerterami RS-232/RS-485 na Ethernet/fiber do routera.
Media converter działa jako tcp client I jest połączony z moim serwerem.
Czasem media converter I router to jedno urządzenie na LTE ale zasada działania jest taka sama.
Obecnie protokół jest taki:
pytanie #(parametry oddzielone przecinkami):(crc8)\n
odpowiedź $(parametry oddzielone przecinkami):(crc8)\n
Główne problemy to:

1. Brak retransmittion, marnowanie czasu na ponowne pytanie w przypadku uszkodzenia którejkolwiek ramki.
2. Nie da się sprawdzić w prosty sposób czy jeden z przewodów np. rx nie jest uszkodzony. Urządzenie po prostu nie dostanie odpowiedzi.
3. Niski baudrate i dużo danych do przesłania w jedynej chwili.

Pomysł:

1. Rezygnacja z wysłania surowych ramek przez internet.
2. Dodanie jakiegoś protokołu, który będzie zajmował obsługę linii między urządzeniem a seryjnym portem w media converter.
3. Wysyłanie danych do serwera już normalnie przez cokolwiek(soap, rest, websocket). Na media converter mogę uruchomić własny program, który by to robił.
4. Monitoring seryjnego połączenia i wysyłanie ostrzeżeń na messenger jak coś będzie nie tak, całkowita blokada a nie, że działa w jedną stronę a w drugą już nie.

Co możecie zaproponować w kwestii protokołu?
Ten obecny pseudo protokół mógłby zostać gdyby pod nim była jakaś warstwa co pilnuje wyżej opisanych spraw.

Proponowałbym jakąś formę keep-alive'a w tym protokole, tzn. co pewien czas wysyłasz komunikat kontrolny w jedną i w drugą stronę typu: "ja żyję i jestem osiągalny przez połączenie". Dzięki temu software'owo możesz sprawdzać połączenie i działanie określonego softu po drugiej stronie. Dochodzi tu watchdog jakiś oczywiście do kontrolowania tych keep-alive'ów. Jeśli taki keep-alive nie zostanie odebrany kiedy nie ma innej transmisji w określonym okienku timeoutu to wiadomo - coś się stało z połączeniem albo z drugą stroną połączenia. Czyli keep-alive'a wysyłasz tylko kiedy nie ma innej transmisji. Jeśli jest transmisja w ramach okienka timeoutu - to odświeżasz watchdoga. Mówiąc inaczej każdy pakiet odebrany restartuje watchdoga.

Każdemu pakietowi możesz dorzucić dodatkowe pole w protokole do potwierdzania, który numer ramki (sekwencji) udało się odczytać. Oczywiście wtedy ramki musiałyby mieć dodatkowo numer sekwencji.

Tak na szybko to tyle.

Pytasz dość nieprecyzyjnie. Chcesz protokół do komunikacji klienta z tym media converterem czy media convertererm z urządzeniem? No i musisz się zdecydować, czy chcesz protokół z założeniem, że jesteś z urządzeniem podłączony bezpośrednio po kablu czy chcesz też się uodpornić na jakąś internetowo-bezprzewodową entropię?

Co możecie zaproponować w kwestii protokołu?

Z założeniem, że łączymy się bezpośrednio po kablu, tak jak teraz, to modbus jest bardzo popularnym protokołem do komunikacji z różnymi urządzeniami odczytowymi bądź sterującymi, gdzie ramkę danych PDU owija się w odpowiednie ADU (RTU/ASCII/TCP) w zależności od potrzeb. Jest na tyle popularny, że możesz kupić gotowe gatewaye konwertujące modbusa na coś innego z albo do urządzenia. Albo możesz załatwić sprawę czysto programistycznie. W każdy bądź razie, jakby Twoje urządzenie używało modbusa dało by Ci to na pewno jakąś swobodę przy modyfikowaniu całego rozwiązania. Masz też gotowego klienta, który ułatwi dewelopment https://www.modbusdriver.com/modpoll.html

Inną opcją jest wybranie któregoś IEC, jak po kablu to pewnie IEC 60870-5. Powszechny ale za pełną specyfikację chyba trzeba zapłacić, chociaż w dzisiejszych czasach może już nie, musiałbyś sprawdzić. Jest jeszcze IECowy profibus, albo profinet ale z tymi nie miałem osobistej styczności.

Problem w tym, że masz jakieś dość konfudujące albo nierealne wymagania.

1. Brak retransmittion, marnowanie czasu na ponowne pytanie w przypadku uszkodzenia którejkolwiek ramki.

Przeca "retransmition" polega właśnie na ponownym odpytaniu, także się zdecyduj czy chcesz odpytać jeszcze raz by dostać poprawną odpowiedź czy nie chcesz marnować na to czasu?

2. Nie da się sprawdzić w prosty sposób czy jeden z przewodów np. rx nie jest uszkodzony.

No nie da się. Koniec. W jaki sposób programistycznie chciałbyś sprawdzić fizycznie uszkodzony przewód? Nie sprawdzisz i nie jest to wina protokołu. Ustawiasz timeout, retransmisję, zapalasz czerwoną lampkę w aplikacji, że nie masz połączenia i to tyle co możesz zrobić.

Co do prędkości RS232 to ile razy na sekundę i jakie dane masz zamiar pobierać? Bo przy 19200bps (taką prędkość powinno wspierać każde urządzenie) masz realnie 2kB danych co sekundę a przy 115kbps masz 10kB. Przy założeniu, że chcesz odczytywać coś 10 razy na sekundę to masz spokojnie 200 bajtow do 1kB na każdy odczyt.

Dodając program na media converter, który będzie odpowiadał za zbieranie i buforowanie danych z STMa oraz wystawi jakiś serwer po TCP (np. rest) odpada Ci wiele z ww. bolączek.

Pytasz dość nieprecyzyjnie. Chcesz protokół do komunikacji klienta z tym media converterem czy media convertererm z urządzeniem? No i musisz się zdecydować, czy chcesz protokół z założeniem, że jesteś z urządzeniem podłączony bezpośrednio po kablu czy chcesz też się uodpornić na jakąś internetowo-bezprzewodową entropię?

Dobre pytanie. Widzę to tak.
Pytanie i odpowiedź: $(długość url);(url);(długosć json);(json)
Mega prymitywny protokól. TCP server po prostu kopiuje url i json i tworzy żadanie http. Czeka na odpowiedź i odsyła robiąc z odpowiedzią na odwrót.
To jest wartstwa aplikacji a pod nią jest protokół X, który zajmuje się tym wszystkim czego chciałem uniknąć żeby nie wymyslać koła na nowo.
Czyli ja to obsługje jak bym nawet nie wiedział, że gdzieś tam jest rs232 a w zamian dostaję: sumy kontrolne, sprawdzanie błędów i retransmisje, dzielenie na ramki.

W zależnosci od potrzeby chwili mogę zrobić to tak jak opisałem powyżej i wtedy wezmę najtańszy media oonverter np. https://allegro.pl/oferta/usr-tcp232-302-rs232-to-ethernet-10680850437
Albo po prostu kupię coś droższego, co ma pythona i wtedy taki ten protokół X będzie terminowany na miejscu a przez internet będzie normalnie http.

Przeca "retransmition" polega właśnie na ponownym odpytaniu, także się zdecyduj czy chcesz odpytać jeszcze raz by dostać poprawną odpowiedź czy nie chcesz marnować na to czasu?

Załóżmy, że jest tak jak do tej pory. Urządzenie wysyła pakiet, czeka, nie dostaje odpowiedzi albo dostaje jakieś zakłócenia, znowu wysyła pakiet... po którymś razie się udaje.
Za tym pytaniem w logice servera idzie do bazy jakieś skomplikowanie żadanie SQL, które trwa dłużej, bo jest nieoptymalne, nie ma indeksów ani cache .itp.
Są marnowane zasoby serwera, bo każde kolejne żadanie jest trakowane jak nowe.
Czas leci, użytkownik się irytuje, że nie działa.
Gdyby serwer miał taki protokoł X to będzie wiedział, że nie dostał potwierdzenia odbioru od urządzenia, zignoruje kolejne identyczne pytania i podejmie kolejne próby dostarczenia odpowiedzi.

No nie da się. Koniec. W jaki sposób programistycznie chciałbyś sprawdzić fizycznie uszkodzony przewód? Nie sprawdzisz i nie jest to wina protokołu. Ustawiasz timeout, retransmisję, zapalasz czerwoną lampkę w aplikacji, że nie masz połączenia i to tyle co możesz zrobić.

Zapomnij o tym punkcie. To był luźny pomysł, bo switche od cisco mają możliwość sprawdzania kabla. Zastanawiałem się czy da się tak zrobić dla rs232. Nie ważne.

Problem w tym, że masz jakieś dość konfudujące albo nierealne wymagania.

Myślę, że jest to wykonalne.