Toppbilden, visa:    


WiFi istf. DCC

Allt om dekodrar, styrsystem, borstlösa motorer, programmering, lödstationer mm.
Användarens profilbild
magnus63
Inlägg: 1042
Blev medlem: 29 dec 2011, 23:35

WiFi istf. DCC

Inlägg av magnus63 »

Nu verkar det röra på sig. Det här var intressant. DWiC som radiobaserat protokoll för modelljärnvägar.
Storlek och pris på WiFi-transcievers är numera så pass att man har testat att stoppa in det i mj-fordon. Fördelarna är att
man slipper boosters/kontrollstationer, man kan använda vanliga surfplattor, telefoner, pc m.m. som körkontroller och man slipper
böket med att generera datasignal överlagrad på körström på spåret. Man kan ha vad sjutton som helst på rälsen, det är helt frikopplat från WiFi-systemet (teoretiskt sett skulle livesteam funka).

http://members.iinet.net.au/~backway/DW ... cation.pdf

ErikB
Inlägg: 1671
Blev medlem: 05 jan 2012, 16:37
Ort: Korsanäs

Re: WiFi istf. DCC

Inlägg av ErikB »

Det där ser riktigt intressant ut Magnus! Nu kanske även en gammal analog-rallare kan få köra sina tåg simultant och trådlöst utan att investera miljoner. Ska bli spännande att följa projektet!
/Erik
Alla dessa hjul som kom och gick, inte visste jag att det var tåget.

Användarens profilbild
cgn1954
Inlägg: 2956
Blev medlem: 04 feb 2012, 10:58
Ort: Tyresö/Trollbäcken
Kontakt:

Re: WiFi istf. DCC

Inlägg av cgn1954 »

Bra/trevligt.... jag skrev faktiskt om detta den 13 december 2010 (det var då ett inlägg/svar och lite OT i tråden så ingen respons direkt då. Men nån kanske nappade. :-) )

Skämt åsido - trodde redan då att det bara är en tidsfråga, DCC och MM/mfx är gammalt och helt enkelt begränsat pga. sin grundstruktur. Med en liten datorkärra typ Linux på ett kort ("dekoder") så blir ju plötsligt möjligheterna oanade. Jämför t ex Axis-kameror och vad man kan åstadkomma med ett enda litet chip som ju är en liten dator med en Webb-server (app). För att hantera den behövs bara en vanlig Webb-läsare i sin vanliga PC med sitt vanliga WiFi. Enkelt - som det ska vara. :-J

http://www.stinsensforum.se/post79961.h ... Fi*#p79961
Med bästa hälsningar
/CGN (Om inga bilder visas så är min server nere - det händer, men inte ofta)
En nästan liten bild - endast 175 px bred
En nästan liten bild - endast 175 px bred

Användarens profilbild
magnus63
Inlägg: 1042
Blev medlem: 29 dec 2011, 23:35

Re: WiFi istf. DCC

Inlägg av magnus63 »

Om man jämför med DCC (det protokoll jag kan bäst) så är ju det här en helt annan frihetsgrad.
Med DWiC gäller egentligen följande. om jag fattat det hela rätt:

En "dekoder" i ett lok eller till en växel, whatever, ska kunna presentera någon form av http-baserat gränssnitt över wifi gentemot vad man nu använder som körkontroll. Bakom gränssnittet kan man ha vilken applikation som helst, det får man tota ihop alldeles själv.
I ett lok vill man förmodligen ha en motorstyrning med effektreglering, lite av- och på-funktioner (diskreta funktioner), kanske simulera vatten/kol/diesel-åtgång m.m.

DCC är synnerligen simpelt, och rätt långsamt. Man skickar i princip 3-5 byte till dekodern, där den sista byten är en checksumma.
Den första och eventuellt delar av den andra byten är adressen till den dekoder som ska svara, den andra och eventuellt den tredje och fjärde byten är vad dekodern ska göra (riktning, motoreffekt, f1-18 av/på, med växeldekodrar ställer man vilka utgångar man ska lägga om).

DWiC är så pass snabbt att man kan skicka rörliga bilder från on-boardkameror, skicka ljudfiler m.m. till loket.

Den stora fördelen är dock att DWiC inte har ett dugg att göra med vad som finns på spåret. Man kan styra DC, DCC, AC, PWM-ad choppad likspänning, helt oelektrifierade räls med livesteam eller ackumulatordrift.
Den andra fördelen är att man kan skicka stora mängder data FRÅN lok till manöverkontrollen, flera Mbit/s strömmat.
Sitter just och funderar på om man skulle kunna kontrolera "autonoma" 1:87-skaliga landsvägsfordon, genom strömmande positionsrapportering.

Användarens profilbild
cgn1954
Inlägg: 2956
Blev medlem: 04 feb 2012, 10:58
Ort: Tyresö/Trollbäcken
Kontakt:

Re: WiFi istf. DCC

Inlägg av cgn1954 »

Jo, helt nya möjligheter. Märklins mfx rapporterar ju oxå från enheten/dekodern till styrenhet men har väl i princip samma begränsningar ifråga om kapacitet och frihetsgrader. Det som rapporteras från en mfx+ dekoder bestäms av Märklin.

En öppen-protokoll-baserad lösning (som IP med ovanliggande protokoll) och en enkel Linux-kod i dekodern ger helt nya möjligheter, man kan förstås ansluta vad man vill till en dekoder - varför inte en HD-filmkamera i förarhytten? :-J
En liten bild - 200 px bred bara

Så - det är bara att heja på DWiC. Vill och kan man delta i utvecklingen så kan man anmäla sig på den länk Magnus skrev ner.
Med bästa hälsningar
/CGN (Om inga bilder visas så är min server nere - det händer, men inte ofta)
En nästan liten bild - endast 175 px bred
En nästan liten bild - endast 175 px bred

Per N
Inlägg: 140
Blev medlem: 08 aug 2012, 23:34

Re: WiFi istf. DCC

Inlägg av Per N »

Hej!

Min spontana kommentar är. "Man kan göra så,...men det är inte rätt!" :=Koko

Varför?
För ordinarie MJ-styrning behöver Du inte bandredden som WiFi ger! För vanlig kontroll är det som att skjuta mygg med kanon - det blir mycket mera komplext och inte bätte.

Jänkarna har ett uttryck som heter "KISS" = Keep It Simple Stupid, som jag tycker passar väl in här. Bara för att man kan göra något komplicerat så innebär det inte att man skall göra det! När jag läser Systembeskrivningen och Specifikationen så får jag intrycket att här är ett par glada programerare som har hittat en ny utmaning för deras programeringskunskaper. :-nord

Tanken att använda "standardmoduler" t.ex. WiFi moduler må vara god. Men så billig som som man påstår (3,5 $) är inte modulen i konsumentledet. Den Wifi-modul som man använder för prototypdekodern (ESP8266) kostar 99,90 hos Kjell & Company. Sedan tillkommer i princip lika mycket elektronik som ingår i dagens DCC-dekoder. Den 1:a dekoderprototyp man har byggt fyller upp en stor del av innandömet på ett HO-diesellok stort som en TMZ / DSB Mz. http://members.iinet.net.au/~backway/DW ... bile1.html

Jag har sysslat med mikroelektronik i 25 år och vet att man kan integrera mycket och hårt. Men för att det skall löna sig så behövs det stora volymer bakom. DCC har nått dessa volymer, och vi kan idag glädjas åt ljuddekodrar som kan klämmas in N-skale lok och små smalspårslok i H0. Om man nu vill addera en WiFi modul som har samma storlek som dagens ljuddekodrar, så kommer den resulterande dekodern att vara större än dagens dekodrar, och det är högst tveksamt om den kommer att få plats i N-skalelok eller smalspårslok. Om någon trots allt investerar i denna integrering, så skall det till väldigt stora volymer för att kostnaden skall komma ned ens i närheten av dagens lokdekodrar. Till skillnad från den fristående WiFi-modulen som kan nå mycket stora volymer för att den är generell, så är DWiC-dekodern applikationsspecifik och kan inte alls räkna med samma volymer.

Sedan kan jag inte låta bli att tycka att om man inte är HTML-programerare så är det otympligt och komplicerat att via en app hämta upp en HTML-sida i loket för att där utföra enkla kommandon för att köra loket. Och om man tycker att det är så roligt att köra tåg via mobiltelefon eller surfplatta så finns den möjligheten redan i DCC från Roco. Själv föredrar jag 8 dagar i veckan ett körvred och funktionsknappar på en Roco Multimus eller motsvarande. "KISS" igen!

Två säkerhetsaspekter;
* Med WiFi så öppnar man upp för att få kontrollen och/eller konfigureringar i dekodern hackade. Vad som kan hackas kommer att hackas, frågan är bara när! Vilket öppnar frågan om brandvägg, VPN-tunnlar och virusskydd i dekodern. Det gör lösningen mer komplex och kommer inte att sänka kostnaden....
* Man tar själva upp utmaningen att WiFi inte lämpar sig för Broadcast. D.v.s. Nödstoppet i dagens DCC-system kan inte hanteras med ordinarie WiFi-kommunikation. Ur Systembeskrivningen och Specifikationen sidan 10;
The only 'fly the ointment' in what I propose is there probably needs to be a way to broadcast an
emergency 'all stop' command. That probably will have to be a 'listener' on each device listening for a particular pattern (binary bits) broadcast on a particular port. http doesn't lend itself to broadcasts.
Här måste man uppfinna och implementera en ny lösning för att möjliggöra nödstoppet, annars får man stoppa loken ett efter ett. Det kan vara OK på en liten hemanläggning, men knappast på en större klubbanläggning. En annan komplex och kostnadshöjande faktor???

Visst, det finns applikationer där WiFi bandbredden behövs så som kameralok. Men då är det bättre att skilja på transmissionen för videosignalen (över WiFi) och kontrollsignalen via DCC. Så som t.ex. Roco löser transmissionen från sina kameralok idag.

Kvar är då styrningen av live-steamlok alternativt batteridrivna lok. Men även här saknas behovet av bandbredd, så standard DCC räcker utmärkt.

Finns det då inga lämpliga applikationer för DWiC? Nja det skulle i så fall vara live-steamlok alternativt batteridrivna lok som framförs på isolerade spår av trä eller plast, eller för den delen landsvägsfordon. Men samtidigt finns här möjlighet att styra med traditionell radiostyrning som nu har nått långt i miniatyrisering och kommit ner långt i kostnad.... "KISS" igen!

My two cents!

MVH / Per N
Senast redigerad av Per N den 21 apr 2017, 14:33, redigerad totalt 1 gånger.

Användarens profilbild
1956
Inlägg: 6065
Blev medlem: 28 dec 2011, 19:13
Ort: Brantevik

Re: WiFi istf. DCC

Inlägg av 1956 »

Har sedan 10 år tillbaka investerat några kronor i detta bolag:
http://digital.di.se/artikel/terranet-t ... rsnotering
Är den tekniken även intressant i MJ-sammanhang?

Per N
Inlägg: 140
Blev medlem: 08 aug 2012, 23:34

Re: WiFi istf. DCC

Inlägg av Per N »

Hej!

Som jag skrev ovan anser jag användandet av WiFi i DWiC vara att komplicera styrningen i onödan eftersom bandbredden som WiFi erbjuder inte behövs. Detta även om tanken är god att använda standardiserad WiFi-teknik som antas vara billig eftersom det är en massprodukt. I praktiken kommer det dock inte att bli billigare än DCC.

Det Terranet utvecklar kombinerar mobilkommunikation med WiFi-liknade teknik för att garantera kommunikation även om man kommer utanför räckvidden på sin närmsta basstation. Det handlar alltså om att dynamiskt ge bästa möjliga uppkoppling över så stora ytor som möjligt (ibland genom att länka via andra "användare") och är alltså ännu mycket mera komplext än standard WiFi-teknik. Personligen har jag mycket svårt att se tillämpningar inom MJ-världen.

MVH / Per N

Användarens profilbild
1956
Inlägg: 6065
Blev medlem: 28 dec 2011, 19:13
Ort: Brantevik

Re: WiFi istf. DCC

Inlägg av 1956 »

Tack Per N för klargörande. Som modelljärnvägar hade jag ju gärna sett att Terranets teknik även kunna tjäna vår hobby.

Användarens profilbild
kjaxne
Inlägg: 85
Blev medlem: 27 aug 2015, 11:51
Ort: Hallsberg
Kontakt:

Re: WiFi istf. DCC

Inlägg av kjaxne »

Även jag ställer mig som Per N lite frågande till detta upplägg. Visst finns det tillämpningar då det är önskvärt med högre överföringskapacitet, men är det egentligen någon fördel att ta sådan trafik över samma gränssnitt som kommunikationen med loken? Personligen skulle jag hellre gärna låta vidoströmmar själva överföras via trådlöst nätverk, medan tågstyrningen förblir genom DCC eller vidareutveckling på detta.

Innan jag tar upp de negativa delar jag sett tänkte jag höra hur vanligt är det egentligen att man styr sina lok med en app i mobilen/surfplattan? Själv föredrar jag en fysisk kontroll av flera anledningar. Dels så upplever jag det mycket smidigare att ha bra kontroll när man får bättre återkoppling från fysiska reglage till skillnad mot en touchscreen som inte alltid reagerar så som man vill på en gång (även om detta är vanligare på budget-smartphones så upplever jag att problematiken finns på kvalitetstelefoner också). Sedan tenderar ju telefonerna idag att dra väldigt mycket batteri när skärmen är igång och man vill ju inte behöva låsa upp telefonen för varje ändring på reglagen. Om man då ska behöva gå runt med laddare inkopplat och kanske tom ha flera usb-uttag längs anläggningen så kan man ju lika gärna ha ett traditionell körhandtag. Dessutom så finns det mycket som kan störa körningen på en uppkopplad telefon. Appar som påkallar uppmärksamhet av händelser när man mottager kommunikation etc lägger sig ju gärna i vägen för det man sysslar med för stunden.
Själv skulle jag enbart använda app i telefonen som ett reservhandtag, tex om man vill låta någon mer person vara med och köra och inte har körhandtag så det räcker. Jag skulle även kunna se fördelarna med att snabbt kunna uppdatera några inställningar genom en app även om jag mycket hellre skulle sitta med en dator för tex uppdatering av cv-värden för att få ett smidigare arbetsflöde än vad telefonens lilla skärm kan erbjuda.
Men det kanske är många som resonerar på annat sätt och verkligen tycker att app är mycket bättre än ett traditionellt körhandtag?

Även om trådlös kommunikation gör livet smidigare på många sätt genom att minska kabeldragning så är det inte alltid enbart fördelar. Vi kan bortse från eventuella hälsorisker med all radiokommunikation i luften eftersom det råder så mycket delade meningar om detta. Men wifi har en del tekniska problem. Framförallt så känns det inte tillräckligt stabilt när det blir många enheter som ska koppla upp sig till en accesspunkt. Om man ska ha flera accesspunkter längs sin anläggning för att fördela resurserna lite så blir det en dyr investering. Bor man sedan i en lägenhet med många grannar så kan det redan vara gott om konflikter om kapaciteten i luften som ställer till det.
Om man tänker hur det skulle bli på modulträffar så blir genast driftsäkerheten ett allvarligt problem med förlorad uppkoppling om det är för många enheter som samsas om anslutningspunkternas kapacitet. Jag har svårt att tro att det skulle fungera bra i praktiken om alla lok ständigt ska vara uppkopplade till en router samtidigt som lika många telefoner är anslutna. Normala accesspunkter har ett begränsat antal noder som kan kommunicera samtidigt.

Säkerhetsaspekten som Per N nämner med hackers är ett större problem än vad många normalt ser. Jag antar att de flesta som idag sätter upp wifi hemma för att styra anläggningen via app har sin accesspunkt ansluten till internet för att telefonen ska kunna ha både internetuppkoppling och anslutning till järnvägen på samma gång. Där uppstår då ett allvarligt problem.
Redan idag är IoT (Internet of Things) ett stort problem då ingen (eller möjligen få) tillverkare lägger någon större energi på säkerheten i detta då det blir en stor kostnad med löpande utgifter för underhåll att täppa till nya säkerhetshål etc. Även om en hacker kanske inte vill sabotera och ändra konfigurationen i loket som är internetanslutet så finns det mycket annat att vinna på att hacka det. Exempel på möjliga anledningar att hacka är att sätta upp en anslutning genom lokets anslutning för att dirigera om trafik för att inte kunna spåras vid tex olagligheter på nätet, eller installera programvara som gör loket till en slav i ett större nätverk. En sådan slav skulle kunna användas vid en sk. ddos-attack när massor av enheter försöker kommunicera med en server för att den ska överbelastas och alla dess tjänster blir därmed icke nåbara.
Kommer skydd mot detta prioriteras? Svaret blir sannolikt nej eftersom det i slutändan medför dyrare dekodrar.

Nästa problem blir att varje lok har en lokal webbserver. Även om det idag inte är så resurskrävande att implementera det i en dekoder så blir det ändå fel tänk. Jag har inte koll på vad som krävs elektroniskt för att implementera en webbserver i en dekoder, men jag skulle gissa på att den kostnaden är låg och att den ökade strömförbrukningen är försumbar i sammanhanget. Men det största problemet blir att en webbserver jobbar med att skicka information i första hand. Loken har ju normalt inte till uppgift att skicka information utan snarare att ta emot information om hur de ska bete sig. Som Per skriver är inte wifi lämpligt för Broadcast eftersom varje varje nod själv har egen kommunikation med accesspunkten. Ett nödstop skulle i praktiken innebära att en förfrågan skickas till var och en av servrarna om detta och det blir helt fel. Varje order till loken blir en förfrågan till dess webbserver och det är först när servern svarar som begäran är utförd och kontroller kan gå vidare med nästa aktivitet.
Hur sedan blir med presentationen av data i appen på telefonen är jag osäker på hur de tänkt. Normalt sett är det ju webbservern som skickar en layout som visas av mottagaren. Detta skulle blir högst opraktiskt då det blir mer data att skicka för varje dataöverföring och om ett lok har senare mjukvara kanske appen skulle se olika ut beroende på vilket lok som körs. Troligen har de tänkt på detta så det enbart är relevant data som skickas och att appen hanterar layout och tolkning av datan.

Men ändå mer logiskt hade varit att låta loken själva ansluta till en webbserver och begära data. Så länge datan de mottager är oförändrad gör de inget men genom appen ändrar man serverns data som loken sedan tar emot. Skulle loken förlora kontakten eller motta felaktig data skulle de enkelt då kunna stoppa som en säkerhetsåtgärd. Även om man här då vänt på server-klient-förhållandet så loken begär information från en server så skulle nödstop ske först när loken begär ny data och ser detta. Men då skulle ju loken begära data så ofta att det skulle ske tillräckligt snabbt eller att de slår av innan dess pga avsaknad av korrekt information om att fortsätta enligt tidigare.
Största problemet här blir var webbserven ska finnas. Så länge det är en telefon enbart som styr borde appen kunna tillhandahålla all information, men så fort det blir flera enheter som ska styra tågen så blir det mer invecklat. Allra smidigast är med en extern enhet som tillhandahåller server och mottager data från telefonerna och skickar vidare till loken på deras förfrågan. Men då blir det en extra enhet som måste finnas någon stans och lagra detta. Central lagring tycker jag känns mer logiskt då alla enheter kan komma åt samma information och man kan få enklare struktur på kommunikationen. Det behöver ju heller inte vara så dyr centralenhet. En Arduino + nätverksanslutning vare sig via kabel eller wifi kostar inte många hundringar.

Strukturen med central lagring och kommunikation mellan appar och noder där igenom har jag själv testat. I mitt examensarbete för ett par år sedan utvecklade jag ett enkelt sådant system där robotar begärde information ur en databas på en webbserver och där jag genom en hemsida anpassad för både dator och telefon kunde skicka instruktioner. I detta fall var det mer som talade för valet av denna struktur då jag skulle kunna förbereda information till robotarna eller gå igenom alla loggar och databasen utan att robotarna skulle behöva vara inkopplade. De hade inget med databaserna att göra mer än att läsa ut vilka uppgifter de skulle hantera och rapportera när det var utfört eller eventuella problem. Men jag lyckades skicka all kommunikation den vägen och jag tror att det tänket skulle fungera bättre även för detta fall.
Rapporten finns att läsa här för den som är intresserad:
https://www.diva-portal.org/smash/get/d ... TEXT01.pdf
Robotarna var byggda med LEGO Mindstorms men där jag körde annan mjukvara på för att kunna programmera mer avancerad kod.

Min slutsats
Ska man sammanfatta mina tankar så tycker jag det är intressant koncept, men finns behovet? Skulle det vara intressant för tillräckligt många för att kunna vara lönsamt att driva kommersiellt? Om så är fallet så finns det mycket kvar att jobba med för att konceptet ska fungera fullt ut. För att lyckas måste de tänka igenom de praktiska begränsningarna mer och hitta mer nytänk än att förlita sig på så gammal teknik som HTTP-protokollet ändå är.
Kör svenskt i N-Re, epok V (-VI).
Dioramabyggare i flera skalor.

Användarens profilbild
magnus63
Inlägg: 1042
Blev medlem: 29 dec 2011, 23:35

Re: WiFi istf. DCC

Inlägg av magnus63 »

Jag har två STORA invändningar mot DCC (och alla andra serieprotokoll på räls) och de är, i tur och ordning dessa:

1) Man överlagrar data på själva strömförsörjningen. DCC är en fyrkantsvågs AC där man blandar 5000 Hz vågor (nollor) med 8333 Hz (ettor). Eftersom denna signal ÄVEN är dirivspänning - man helvågslikriktar den och får en "good enough" DC-källa till motorn - så måsta man vräka ut fyrkantsvåg på 15-20V och flera ampère ström. Man behöver en attans snabb slutstegsförstärkare, och de är DYRA.
För att få en snygg kantig väldefinierad fyrkantsvåg så måste man ha snabba effekttransistorer m.m. i slutstegen, och det är inte gratis.
Alltså, på mj-språk, kontrollstationer och eventuella boosterstationer kostar pengar.

Med själva datatrafiken på ett annat medium än kraftförsörjningen är problemet borta, man kan mata motorerna med precis vad som helst, det behöver inte ens vara elektricitet - man kan ha livesteam. Datatrafiken går över radio.

2) Återrapportering med samma teknik. DCC och liknande är av naturliga skäl förhindrade att återrapportera med DCC.
Skälet är det som anges i punkt 1. Om ett lok skulle återrapportera data med DCC, ska det inte bara skicka datat, det ska dessutom förse X antal andra lok med körström (som sagt, helvågslikriktad DCC blir DC), det innebär 15-20V upp till 2-3A ut ur loket. Omöjligt.
Därmed är DCC designat för att kontrollstationen snackar, dekodrarna lyssnar och lyder.
Ja, jag vet att man mixtrat med att låta DCC tystna nån millisekund och pressa in andra protokoll i pauserna, men det är ju lindrigt sagt att sminka en gris. Dessutom är de protokollen INTE öppen standard.

Argument jag köper
:
3) TCP/IP över WiFi är overkill. Ja, det är det, TCP/IP är avsett för att skicka rätt stora mängder data mellan datorer, dels strömmande (TCP, med "oändliga" datalängder och strömningskontroll) och dels snabba men osäkra paket (UDP, 64 kB paket man kan skicka på vinst och förlust). IP i sig är ett "generellt paketformat" som ska klara paketformaten på olika nätverksteknologier, syftet är just att man ska kunna koppla ihop t.ex. ett TokenRing-nät med ett Ethernet. En metafor är väl ISO-containrar, man kan ställe en sådan på en järnvägsvagn, och lasta över den på en lastbil. Containern kan inte förflytta sig själv, men den är ett "generellt paketformat" som man kan låta olika transportslag hantera utan att lasta om innehållet (innehållet i ett IP-paket är UDP eller TCP, lite generaliserat).

Men nu finns det enklare radioprotokoll än full TCP/IP över WiFi. SiLABS har ett eget protokoll för enkel seriekommunikation t.ex. (har själv använt det för kaffemaskiner, elmätare och kossor i lösdriftsladugårdar) som är betydligt simplare. I princip skickar man 64 byte data, vad man gör med datat är upp till en själv. Lite som DCC (som skickar 3-6 byte i sina paket). Man skulle enkelt kunna porta DCC till SiLabs protokoll EZMacPro. Problemet är att SiLabs är SiLabs, det är deras eget protokoll som ingen annan stödjer, och då är man fast hos SiLabs. Precis som när Märklin satte sig i knät på Motorola.

Det finns förmodligen en uppsjö med företagsspecifika radioprotokoll, liksom branschstandarder som ZigBee (fastighetsövervakning).

4) Säkerheten. Jag har en son som jobbar just med säkerhetslösningar för Internet of Things och PLC/HMI/SCADA system för industrin, och hans åsikt kan väl sammanfattas med "The S in IoT stands for security". Men problemet är på olika nivåer.

http är en nivå - det finns alltså möjligheten att knäcka sig in via webgränssnitt, men nu är inte http något man måste ha.
tcp/ip är en nivå - alltså UNDER http (http som man inte måste ha) men att programmera på sockets för att ställa till fanstyg är
betydligt knepigare. Oftast handlar det om att sänka nätverk med överbelastningar m.m. då folk jävlas med sockets.
Operativsystemet i sig, via öppnade sockets. Avancerad hacking, ofta för att komma åt data. Att komma åt data i mj-lokomotiv känns väl kanske inte så relevant kanske. En klassiker är ju att hacka sig in till ett remote kommandoskal.
Har inte stött på hack på realtidskärnor som OSE eller VxWorks, hört talas om en del rätt klumpiga Linux-hack (Android mest).
Oftast har det varit manicker som på regelbunden basis går ut på nätet och laddar ner nya mjukvaruversioner, och där någon lyckats plantera en infekterad mjukvara på själva servern där manickerna laddar ner ifrån.

Enligt junior så är den vanligaste typen av hack mot IoT-prylar, att komma åt processorkraften, för att bygga botnet. Ett exempel är Mirai, där någon hackat övervakningskameror. Inte för att de är intresserade av kamerorna och bilderna i dem, utan för att på en given signal kunna få hundratals kameror att säta igång att skicka ping till nån journalist i Kanada, så att dennes dator kraschade. Ett ping-botnet alltså! Siemens kylskåp med internetuppkoppling har också varit hackade, i syfte att pinga sönder Aftonbladets sajt.
I Siemens-fallet gjorde man exakt det jag skrev ovan, någon lyckades plantera en infekterad programvara på servern där kylskåpen laddade ner uppgraderingarna... (vilket gör att säkerhetsprobemen hör till hur man sköter sina servrar, inte kylskåpen).
Det är ju inte så bra om 4000 modelljärnvägslok står och pingar sönder svenskt MJ-forum bara för nån löpt amok i nåt flame-war.

5) Http är värdelöst för att styra saker [+exempel med broadcast på nödstopp]. Korrekt, men detta är ett http-problem,
inte ett WiFi eller ens TCP/IP-problem. Http är inte och har aldrig varit avsett att kontrollera eller styra manicker med, det finns bättre protokoll för detta (RTP, real time protocol, som körs på UDP till exempel). Bakom RTP finns ingen websida i nån liten web-server ombord på loket, utan där får man skriva en liten socket-applikation, lämpligen då en vanlig sketen udp-server som lyssnar på en port dedicerad för rtp-trafik. Nackdelen är ju då att man måste skriva lite (riktig) kod själv, inte html-fjoms.

Argument jag inte köper:
6) Dyrt. En DCC-kontrollstation och eventuella slavförstärkare (boostrar) är dyrare

7) Traditionell radiostyrning. Analogt, med servon och junk? Glöm.

8) Modulträffar. Det är problem redan idag med DCC och adresskrockar. Läste på Facebooks modelljärnvägsforum att
några modulträffar gett upp, och körde analogt. Jag tror iofs. mest att det är en samordningsfråga, inte en teknisk dito.

Användarens profilbild
magnus63
Inlägg: 1042
Blev medlem: 29 dec 2011, 23:35

Re: WiFi istf. DCC

Inlägg av magnus63 »

Slutsatser:

[*]Protokollet för att föra över data till fordon ska vara helt separerat, helst oberoende, från kraftförsörjningen till fordonet.
[*]Protokollet ska vara litet. Det behövs inte protokollskikt för internetworking (som IP i OSI-skikt 3), det behövs inte protokoll för strömmar (TCP i OSI 4) eller stora datagram/paket (UDP i OSI 4). Ett enkelt protokoll kan arbeta nere på OSI-skikt 2, där det finns adressering, och där OSI-skikt 1 tar hand om crash detection, bit arbitration/carrier detect eller vad man nu har för teknik att undvika en pladdrande hönsgård av noder.
[*] Protokollet ska vara dubbelriktat, så att man kan skicka data i båda riktningarna. Framför allt ser jag fördelen med detta för att kunna
skicka tillbaka positionsdata från fordon. Skulle alltså även kunna användas för körande landsvägsfordon.
[*] Protokollet ska inte medge att man kan hacka sig in till själva mcu:n (processorn) i en dekoder, för att "stjäla" processorkraft. Men då kan man också fråga sig om det ens är av intresse att göra det om man inte kan använda den processorkraften på internet, läs TCP/IP-uppkoppling.
[*]Inte HTTP (på OSI nivå 5), det är illa designat för att styra manicker med, och det var aldrig avsikten med det heller. Argumentet att det saknas t.ex. broadcast köper jag rakt av.

Hur är det med ZigBee och Z-Wave? Någon som jobbat med dessa protokoll?

Skriv svar

Återgå till "Elverkstaden"