On Mon, 22 Aug 2022 20:21:52 +0200, Piotr Gałka wrote:
> W dniu 2022-08-22 o 14:32, J.F pisze:
>> Co zaraz powoduje problemy pod tytulem kolizje.
>> Wykrywacie?
>
> Przyjmujemy, że nie ma pewności wykrycia kolizji. Jak oba nadajniki są
> kawałek od siebie to może być tak, że każdy widzi to co sam nadaje.
> Dlatego nie usiłujemy wykrywać kolizji - minimalizujemy szansę na
> kolizje i przy braku potwierdzenia powtarzamy.

A jaki timeout dla potwierdzenia? Ile trzeba czekac az drzwi sie
otworzą ? :-)

> Nie ja pisałem oprogramowanie - mogę mylić drobiazgi.
> Wszystkie drivery fail-save.
> Każdy wypracowuje flagę - linia wolna/linia zajęta. Z tym, że jak uzna,
> że linia jest wolna to odmierza jeszcze losowe opóźnienie zanim ustawi
> sobie flagę linia wolna. Każde 0 na linii powoduje natychmiastowe
> ustawienie flagi na linia zajęta.
> Jeden postanawia nadawać - szykuje ramkę, szyfruje ją podpisuje i jak ma
> flagę linia wolna to wchodzi na linię (czyli jak już dawno była wolna to
> wchodzi bez żadnego opóźnienia).
> Wchodzi na linię - po rzędu 0us od decyzji.
> Odczekuje chwilkę (aby zbocze było relatywnie tak samo opóźnione jak
> potem kolejne) - np 0,7us.
> Czas propagacji scalaka (HVD72) - typ. 0,7us.
> Czas propagacji w linii (do 300m, 2E8) - 1,5us.
> Czas propagacji odbiornika 0,1us.
> Czas reakcji na przerwanie w tej skali - 0us.
> Razem 3us. Czyli mogą się zderzyć tylko gdy różnica momentów decyzji o
> wejściu na linię jest mniejsza niż 3us. Często mniejsza różnica momentu
> decyzji też nie spowoduje zderzenia, bo przecież nie zawsze linia ma
> 300m i nie każda para urządzeń jest na przeciwległych końcach.
>
> Na początku nie mieliśmy tych opóźnień i trafiliśmy raz (może 1996) na
> parę urządzeń, które wiecznie się zderzały - mijało kilka sekund (wiele
> ramek) zanim któremuś udało się być pierwszym.

Tak tak, ethernet mial ciekawy pomysl :-)

> Zaokrąglając. Prędkość 100k, bit = 10us, bajt =100us, mała ramka = 1ms.
> Czyli na tej losowości możemy maksymalnie marnować 15x5us=75us - mniej
> niż bajt przerwy. Ale to dotyczy tylko sytuacji maksymalnego obciążenia
> linii, które nigdy nie występuje.
>
> Załóżmy mały system - 5 urządzeń podległych na szynie. Norma wymaga, aby
> najdalej po 5s wykryć brak urządzenia. Czyli np raz na 4s kontroler
> wysyła 5 ramek (nie broadcast, bo każdy ma inny klucz sesji) i potem
> niezależny proces zbiera odpowiedzi.

Ale to juz brzmi jak polling.

> Możliwe, że jak chce wysłać 3-ą
> ramkę to odpowiedź pierwszego urządzenia wetnie się przed nią - zależy
> co kto wylosuje. Czyli w stanie normalnym raz na 4s leci 10 ramek.
> Typowa zajętość linii 10ms/4000ms = 0,25%.
>
>> Przy niewielkiej ilosci szybkich urzadzen - moze to nie problem.
>> Bedą odpytywane co poł sekundy ...
>
> A pro po szybkich. Ten ich system powoduje, że tylko kontroler może
> optymalizować czas szyfrowania robiąc to w czasie gdy inna ramka leci.
> Urządzenie po odebraniu musi sprawdzić podpis, rozszyfrować, wypracować
> odpowiedź, zaszyfrować, podpisać i w tym czasie na szynie cisza - się czeka.

No ale i tak to robisz. Tyle tylko, ze jak rozumiem - to sluzy do
sprawdzania obecnosci - zdarzenie urządzenia przekazują w miare
natychmiast.

> Pół sekundy to sporo czasu. Norma przewiduje, że atakujący system grade
> 3 i grade 4 ma praktycznie dowolne wyposażenie jakie mu tylko potrzebne.
> Norma nie specyfikuje, że taki tamper ma trafić momentalnie. My po
> prostu uważaliśmy, że jak coś da się zrobić lepiej to nie ma sensu robić
> gorzej.
> Są dwa tematy:
> 1.
> Niektóre instalacje muszą mieć dużo urządzeń. Wyobraź sobie pokój
> centralny i od niego promieniście śluzy. Każda ma 4 drzwi: do tego
> pokoju, na zewnątrz, do śluzy po prawej i do śluzy po lewej (jeszcze 2
> lata temu nie wiedziałem, że takie rzeczy istnieją). Nie da się
> wydzielić żadnego podzbioru drzwi niezależnych od innych. Z tego powodu
> wprowadziliśmy kontroler obsługujący 16 drzwi. Czytnik po każdej stronie
> - już 32 urządzenia. Dodatkowo ileś modułów rozszerzeń aby dodać wyjść i
> wejść i mamy rzędu 40.
> 2.
> Jak urządzenie typowo nadaje 1ms na 4s to przyjąłem, że z dopuszczalnego
> zasilania do 24V robię 3V3 liniowo. A jak się puści odpytywanie
> najszybciej jak się da to ilość wydzielanego ciepła wzrośnie radykalnie.
> Nie przewidywałem po prostu tak idiotycznego sposobu pracy. A poza tym w
> czytniku RFID wolę nie mieć DCDC bo może będzie zakłócało odczyt.

No fakt, moglby byc problem ... wiekszy radiator :-)


>> Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
>> "na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(
>
> Chyba nawet norma wymaga, że w przypadku odcięcia komunikacji z serwerem
> wszystko ma nadal działać. W każdym razie u nas wszystkie informacje są
> w kontrolerze (mała skrzyneczka na szynę DIN) zasilanym zasilaczem
> buforowym.

Pisząc "serwer" mam na mysli jakis "kontroler systemu".
Gdzies tam macie przeciez zapisane ktore karty sa aktywne, jakie maja
uprawnienia itp.

>> Np wspolny protokół, zeby można było urządzenia mieszać, brak kolizji,
>> brak programowania w sensie - brak adresu "serwera". Choc mozna by
>> dac jakis staly adres np 1 czy jakis brodcastowy "do wszystkich
>> serwerow/kontrolerow".
>
> W normie jest opisany rozkaz broadcastowy, ale piszą, że jest założenie,
> że jest używany tylko, gdy jest połączenie jeden do jeden. Ja jej
> dokładnie nie znam. To ma chyba służyć do tego aby można było wywołać
> urządzenie, które nie ma przydzielonego numeru i mu ten numer
> przydzielić. Łącząc tak po jednym potem można połączyć wszystkie.
> U nas wszystko łączy się jak ma być i potem wszyscy się dogadują (też
> nie wiem dokładnie jak, bo to brat pisał).

Podejrzewam, ze i tamta norma podobnie zaklada, bo to troche glupio
wiekszy system po jednym montowac i uruchamiac.

>> Byc moze tez przy okazji znika problem zajetosci kontrolera, choc
>> odbior portu szeregowego i tak na przerwaniach przeciez ...
>>
>> A warstwa fizyczna jest tam podana?
>> Bo moze i tak na ethernet przeszli :-)
>
> W tej chwili nie umiałbym tego udowodnić, ale to dotyczy RS485.
> Standardu Wiegand też nikt nie przenosi na ethernet :)

Jak widac jednak sporo elementow Ethernetu sie w koncu w systemie
znalazlo :-)

J.