W dniu 10.12.2023 o 16:20, heby pisze:
> On 10/12/2023 00:08, titanus wrote:
>> Heby - kiedy wymienialiśmy opinie n/t budowy systemu sterowania HA,
>> bardzo jednak upierałeś się na tym, że należy (przynajmniej w tamtym
>> przypadku) wykorzystać to co zostało już przez kogoś zbudowane,
>> "przepracowane" - bo poprostu - działa.
>
> 1) Hardware sterowanika w pociągu nie jest "przepracowane". Jest
> niszowe. Przeciętny, brodaty nerd, piszący kod w jądrze Linuxa w życiu
> go na oczy nie zobaczy. On pisze kod, który będzie pracował na nieznanej
> architekturze i może nigdy nie zobaczyć buga, który własnie w tej chwili
> implementuje.
>
> 2) Istnieje róznica między miganiem didoami a sterowaniem setką ton.
>

hmmm, a może nie do końca ?
https://drive.google.com/file/d/1-J_Fkjyuc1eNBYxv7JZ
j6X4oDepuQrZg/view?usp=sharing

To tylko przykład tego co robi taki sterownicznek. Widziałem również
program do sterowania i kontroli 100kW turbiny wiatrowej też
zrealizowany na Logo w wersji 8. Wcale nie był bardziej skomplikowany.

Widziałem również jak programuje się całą linię paletyzacji na Siemensie
S7-700. Program miał po kompilacji tylko 4,6 MB - 19 sekcji po średnio
200-300 kb każda, a w każdej tylko kilkanaście prostych funkcji. W tym
przypadku urządzeń, czujników i serwonapędów od groma.

Nie wydaje mi się (choć nie widziałem tego od środka), aby program
sterujący lokomotywą był jakiś super-duper bardziej wymyślny.

>> Kiedy argumentowałem, że nie chcę takich rozwiązań ponieważ nie widzę
>> dla nich zastosowania w moim przypadku kontrowałeś, że chcę "wymyślać
>> koło na nowo".
>
> Jesli robisz domowy projekcik, albo nawet kompercyjny, konsumencki
> projekcik, typu zabawkowego, nalezy jak najwięcej czerpać z gotowców.
> Zawieszenie się tabletu dziacku spowoduje tylko płacz i traumę u
> przedszkolaka, gdy to samo w pociągu może doprowadzić do utraty życia.
>
> Przepychanie wszystkich czujników i sterowania przez jeden, deliktny
> system, jest naiwne. Linux, jako OS, może co najwyżej pełnić rolę
> nadzorcy nad układami, ale układy powinny być autonomiczne i mieć
> niezalezną możliwośc sterowania, pomijającą ten ekran (dotykowy?).
>
> Podobnie, przepytachnie wszystkch ukłądów przez centralny komputer jest
> naiwne. Znacznie bardziej neizawodne były by osobne elementy, pracujące
> autonomiczne i co najwyżej oczujnikowane.
>

Linux - w tym przypadku uważam jedynie za platformę komunikacyjną (hub)
który nie tyle steruje takim pociągiem co interpretuje i przesyła
komunikaty w róznych kierunkach. Tyle.
Tu może być i windows, dos, czy macos - co kto lubi.
Cała reszta i tak jest na różnych systemach i zapewne stąd "potrzeba"
spięcia tego czymś bardziej uniwersalnym.
Wystarczy, że np do sterowania przetwornic zastosowano coś od ABB,
falowniki odpala i kontroluje np LG, kontrolę zespołu prądnic powierzono
Siemensowi a hamulce i zespół napędowy obsługuje gefanuc i ... weź to
pospinaj komunikacyjnie...
Takich podsystemów działających "lokalnie" i niekoniecznie
kompatybilnych komunikacyjnie w takim składzie/pociągu może być dużo.
Nowe technologie wcale nie muszą ze sobą "gadać", a jeśli każdy
producent danego sterownika wymyśli własne protokoły to już się robi
totalny bigos.

>> W tym przypadku (chodzi o sterowanie pociągu) argumentujesz w drugą
>> stronę: dziwisz się, że producent poszedł "na łatwiznę" i zastosował
>> coś co działa (choć jest wykorzystywane w innym zakresie) i jednak
>> (jako producent) powinien zrobić coś całkowicie od nowa.
>
> To nie branża, gdzie wolno iść na łatwiznę.
>
Doprawdy ?

>> Gdzie w tym przypadku leży różnica pomiędzy szarym człowiekiem z
>> konkretnymi wymaganiami i "dużym graczem" który jednak idzie na skróty ?
>
> Bezpieczeństwo.
>
> Aby była 100% jasność: w urządzeniach sterujących, szczególnie typu RT i
> infrastrukturze krytycznej, nie ma miejsca na rozwiązania szybkie i
> tanie, a takim jest Linux.
>
> Może być tak, że wyświetlacz w pociągu nie jest krytyczny i można używać
> pociąg bez niego. Wtedy nie ma problemu. Acz zaczyna wtedy pojawiać się
> pytanie: to po co on tam jest?
>
j/w opisałem

--
Pozdrawiam - titanus