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.

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.
Wprowadziliśmy opóźnienia i problem już nigdy się nie pojawił.
Jak dokładnie to jest zrealizowane to tego nie wiem. Ale np. każdy
losuje liczbę z zakresu 0..15 i odmierza tyle razy 5us jako opóźnienie.
Wiadomo - generator pseudolosowy więc ryzyko synchronizacji. Generator
więc uwzględnia typ i numer urządzenia (czyli niepowtarzalny komplet) i
miesza to (stosujemy procki z hardwareowym AES) aby nie było ryzyka
wiecznie takich samych liczb pseudo-losowych.

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. 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.

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.

> 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.

> 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ł).

> 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 :)
P.G.